QByteArray::fromHex(QString.toUtf8()) presenting undesired behavior
-
Your hex string has an odd number of characters.
-
@oldevel said in QByteArray::fromHex(QString.toUtf8()) presenting undesired behavior:
The rest of the conversion is corrupt, as all characters are shifted right by 1.
We only have your word for what you say is in the file, we cannot see. For all we know, just maybe there is a byte marker or something.
So help yourself to help us:
while (!textStream.atEnd()) { hexstring = textStream.readLine(); qDebug() << hexString; auto hexstring2 = hexstring.toUtf8(); qDebug() << hexstring2; auto ba2 = QByteArray::fromHex(hexstring2); ba.append(ba2); }
Meanwhile, I would replace your reading from file with a literal
hexstring = "7F46000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F202122232425262728292A2B2C2D2E2F30313233343536373839380";
and confirm behaviour with known input.
UPDATE
Crossed with @Christian-Ehrlicher's observation, obviously that is what needs attending to! -
@Christian-Ehrlicher said in QByteArray::fromHex(QString.toUtf8()) presenting undesired behavior:
Your hex string has an odd number of characters.
Interesting (you are good at counting!) :) Slightly strange that causes it to shift at left rather than at right?
-
@JonB said in QByteArray::fromHex(QString.toUtf8()) presenting undesired behavior:
Slightly strange that causes it to shift at left rather than at right?
The
hedecoding starts from the back. Don't know why though but the documentation is explicit:Input is not checked for validity
-
@Christian-Ehrlicher said in QByteArray::fromHex(QString.toUtf8()) presenting undesired behavior:
he decoding starts from the back.
I sit and stare at
hexstring = textStream.readLine(); ba.append(QByteArray::fromHex(hexstring.toUtf8()));
and just cannot see that!? :(
Though anyway of course it doesn't matter, he needs to fix the character count.
-
@JonB said in QByteArray::fromHex(QString.toUtf8()) presenting undesired behavior:
and just cannot see that!? :(
Forgot a
T
at the start :D -
@JonB said in QByteArray::fromHex(QString.toUtf8()) presenting undesired behavior:
I sit and stare at
hexstring = textStream.readLine();
ba.append(QByteArray::fromHex(hexstring.toUtf8()));and just cannot see that!? :(
when reading from stream, you got an
QByteArray
.
You have to transform it toQString
to be able to useQByteArray::fromHex()
.I would to it with
hexstring.toLatin1()
but it doesn't really matter, because there are only '0'-'9' or 'A'-'F' or 'a'-'f' bytes. -
@KroMignon said in QByteArray::fromHex(QString.toUtf8()) presenting undesired behavior:
when reading from stream
I wouldn't use QTextStream at all but QIODevice::readLine() to avoid the two useless conversions completely :)
-
@KroMignon , @Christian-Ehrlicher
Sorry, I just don't see what either of you are saying. Nothing to do withQByteArray
versusQString
. I simply don't understand where @Christian-Ehrlicher said:[T]he decoding starts from the back.
as an answer to why the OP says the first byte he gets, which he & I expect to be the
7F
at the left-hand side of the string, comes out as0x07
[and the second character is0xF4
]With an odd number of characters in the string, I would have expected the first byte to be
7F
and it to go wrong at the right-hand end of the string.Since you two seem to understand and I do not, we can leave this if you wish...
-
@JonB said in QByteArray::fromHex(QString.toUtf8()) presenting undesired behavior:
Since you two seem to understand and I do not, we can leave this if you wish...
If you take a look at
QByteArray::fromHex()
source code, you will see that the string if read backwards.
This is why he got this. -
@JonB said in QByteArray::fromHex(QString.toUtf8()) presenting undesired behavior:
I simply don't understand where @Christian-Ehrlicher said:
Hehe.
It was the only meaningful explanation for the described problem and when you look at the code (hey, it's opensource ;)) you see that it's the correct one. -
@KroMignon , @Christian-Ehrlicher
If you take a look at QByteArray::fromHex() source code, you will see that the string if read backwards.
Indeed, that makes sense for behaviour reported, I merely expressed my surprise as it was not the direction I expected. I expected it would naturally work left-to-right, that's all!
So with a missing byte at the end the code does not allow decoding of all the bytes up to the last one, so you can mostly see what is in there, instead it makes them all wrong if, say, the input is prematurely curtailed, for whatever reason. Potentially a shame/confusing. That's all. I agree the
the documentation is explicit: Input is not checked for validity
means it can do what it likes with this bad input, as I say I was merely surprised that it does turn out to do right-to-left.....