我和我的团队在解析从我们的服务器收到的字符串时遇到了这个令人讨厌的问题。服务器非常简单,在qt中完成的socket函数就是sendData函数:
void sendData(QTcpSocket *client,QString response){
QString text = response.toUtf8();
QByteArray block;
QDataStream out(&block, QIODevice::WriteOnly);
out << (quint32)0;
out << text;
out.device()->seek(0);
out << (quint32)(block.size() - sizeof(quint32));
try{
client->write(block);
}
catch(...){...
客户端是Java版本,也是非常标准的套接字内容,这是我们在尝试从服务器解码响应的许多不同方法之后的现状:
Socket s;
try {
s = new Socket(URL, 1987);
PrintWriter output = new PrintWriter(s.getOutputStream(), true);
InputStreamReader inp = new InputStreamReader(s.getInputStream(), Charset.forName("UTF-8"));
BufferedReader rd = new BufferedReader( inp );
String st;
while ((st = rd.readLine()) != null){
System.out.println(st);
}...
如果与服务器建立连接,它会发送一个字符串“Send Handshake”,其字符串的大小以字节为单位,如第一个代码块所示。这通知客户端它应该向服务器发送身份验证。截至目前,我们从服务器获取的字符串如下所示: S e n d H a n d s h a k ë
我们使用string encode/decode tool之类的工具来尝试评估字符串的编码方式,但在每次配置时都会失败。
我们不知道这是什么编码,如果有的话,或者如何解决它。 任何帮助将非常感激。
答案 0 :(得分:3)
乍看之下,将QString
参数转换为Utf8 QByteArray
然后又转回QString
的行似乎很奇怪:
QString text = response.toUtf8();
当QByteArray
返回的toUtf8()
被分配给text
时,我认为假设QByteArray
包含Ascii (char*)
缓冲区。
答案 1 :(得分:1)
我很确定QDataStream
只能在Qt中使用。它提供了一种与平台无关的序列化数据的方法,然后用另一个QDataStream
对其他地方进行反序列化。正如您所注意到的,除了您的原始数据之外,它还包含许多额外的东西,并且在下一个Qt版本中额外的东西可能会发生变化。 (这就是为什么文档建议在你的流中包含正在使用的QDataStream
的版本......所以它可以使用正确的反序列化逻辑。)
换句话说,您看到的额外内容可能是Qt包含的元数据,并且不保证与下一个Qt版本相同。来自文档:
QDataStream的二进制格式自Qt 1.0以来已经发展,很可能 继续发展以反映Qt中所做的变化。输入或时 输出复杂的类型,确保它是非常重要的 相同版本的流(version())用于阅读和 写入。
如果你要使用其他语言,这是不切实际的。如果它只是您传递的文本,请使用众所周知的传输机制(JSON,XML,ASCII文本,UTF-8等)并完全绕过QDataStream
。