5

I have a QByteArray which contains bytes in UTF-16 format.

A Java program sends data to a QT program via socket using 

//dos is DataOutPutStream
dos.writeChars("hello world");

On the receiver side in QT program I read the data from socket into QByteArray and I want to convert it to a QString. inspecting the data variable of QByteArray it has 0h0e0l0l0o0 0w0o0r0l0d

When I try to make a QString out of it like this

QString str(byteArray)

The resulting string is empty perhaps because it encounters a 0 byte at the start and ofcouse because the documentation of the constructor I am using says that it internally uses fromAscii and what I am passing is not ascii.

I guess i have to somehow use QString::fromUTF-16 but that requires a ushort* and I have a QbyteArray.

Please advise what is the best way to do it.

Thanks,

Ahmed
  • 14,503
  • 22
  • 92
  • 150

2 Answers2

4

Get a pointer to the QByteArray.data() and cast it to ushort*

Martin Beckett
  • 94,801
  • 28
  • 188
  • 263
  • ok the function worked but did not get the right QString . it contains wired hexadecimals numbers – Ahmed Jul 01 '12 at 03:55
  • I am not sure the data in QbyteArray is something like 0h0e0l0l0o0 0w0o0r0l0d - notice there is no null charcter at end... so I manually specified size in the QString::fromUTF-8 as second param but same thing. My platform in Windows 7 – Ahmed Jul 01 '12 at 04:03
  • guess you seem right I created a temp QString object and converted it to QByteArray like this QByteArray b((const char*) (s.utf16()), s.size() * 2); the contents are like t 0 e 0 s 0 t 0 So how would I fix that – Ahmed Jul 01 '12 at 04:08
  • Use `ntohs(uint16_t net)` - you might need to include the networking headers, I don't remember if there is a qt fucntion for it – Martin Beckett Jul 01 '12 at 04:15
  • I am confused why would a network change byte order of data ? I thought byte order in networks has to do with ports and address only ? so ntohs stuff would probably be need for ports and addresses and not data :( – Ahmed Jul 01 '12 at 05:01
  • Bytes in a short on an intel CPU are stored in the 'wrong' order (little endian = lo byte - hi byte). Because you don't know what brand of CPU is on the other end of a network connection you generally send bytes over a network in network order (big endian, hi-lo) you then convert them to host order (if necessary). I was suggesting that whatever protocol your Java socket is using - it's assuming network order – Martin Beckett Jul 01 '12 at 05:04
  • 1
    Worked it out finally, dos.writeChars("hello world"); was explicitly writting as big endian even though the native endianess on that platform is low-endian. I am now sending bytes from java after converting them to utf-16 which is in low-endian and it translates fine in QT . Thanks for your help – Ahmed Jul 01 '12 at 16:12
3

This would work, assuming your utf-16 data is of the same endianness or has the BOM (Byte Order Mark):

QByteArray utf16 = ....;
auto str = QString::fromUtf16(
                reinterpret_cast<const ushort*>(utf16.constData()));
Kuba hasn't forgotten Monica
  • 95,931
  • 16
  • 151
  • 313
  • Look here: https://stackoverflow.com/questions/14131127/qbytearray-to-qstring/14131215 – FlKo Mar 07 '19 at 15:32
  • @FIKo Using the heavy (ICU-based, typically) text codec when `QString` can do it by itself... why? – Kuba hasn't forgotten Monica Mar 07 '19 at 20:25
  • Just an addition in case when there's a different endianess or the endianess is not known. For standard situations your example should work flawlessly. – FlKo Mar 08 '19 at 18:54
  • Unknown endianness different than that of the system's is not handled anywhere, because any assumption has a 50% chance of being wrong. Known endianness, declared by BOMs, is handled just fine by `fromUtf16`. There's a reason `QString` supports utf16 natively: it'd be rather silly to have to pull the extremely heavy (many megabytes!) ICU or similar machinery just to do what `QString` has written on the box. – Kuba hasn't forgotten Monica Mar 08 '19 at 18:58
  • @ Kuba Ober You're certainly right, so I have nothing to add here. – FlKo Mar 08 '19 at 19:13