Hi Petr,

According to the specification are bencoded strings actually byte strings (encoded in base ten ASCII) so I’d keep it the way it is. Hope I haven’t missed your point - maybe you have thought about that we’re currently storing announces/comments/created by in a QString instead of a QByteArray? I think that we could store these information in a QString and use QByteArray only for “raw bytes” like hashes/checksums (hope there won’t be any problem with utf8 encoding though).

In my understanding it is the string length that is “integer encoded in base ten ASCII”. That would mean that the integer is being represented in text form (ASCII) and its textual representation uses base 10 (the digits 0 to 9).

I was actually referring to this extract from the specs:

“The content of a metainfo file (the file ending in “.torrent”) is a bencoded dictionary, containing the keys listed below. All character string values are UTF-8 encoded.”

Now I realize that some strings like md5sum we would need as a QByteArray and some strings like name we would need as a QString. So it would be better to read the BStrings as QByteArrays (as it is now), but then when we set the QString fields of the Torrent object we should use fromUtf8():

name = QString::fromUtf8 (item->value());


Strings like md5sum need not be converted because the hex string is guaranteed to be the lower half of ASCII, which is a subset of UTF-8.

Good night,

Peter