Open trim21 opened 4 months ago
apparently dictionary should not have duplicated keys, otherwise after sorting it will have different encoding result for same content.
for example, {"key": 1, b"key": 2}
can be encode as both d3:keyi1e3:keyi2ee
or d3:keyi2e3:keyi1ee
bencode itself has no concept of encoding, that's an artifact of the language you're using.
BEP 52 clarifies this.
bencode itself has no concept of encoding, that's an artifact of the language you're using.
BEP 52 clarifies this.
that's why I'm asking, it doesn't clarify if d3:keyi1e3:keyi2ee
is valid bencode content.
bencode itself has no concept of encoding, that's an artifact of the language you're using.
BEP 52 clarifies this.
encoding itself is a concept of programing language, but bencode content itself is not.
{"key": 1, b"key": 2}
What I mean is the type distinction between string and binary is something that exists in the language. If that didn't exist you couldn't have duplicates there either.
But yes, the word "unique" could be inserted somewhere.
{"key": 1, b"key": 2}
What I mean is the type distinction between string and binary is something that exists in the language. If that didn't exist you couldn't have duplicates there either.
But yes, the word "unique" could be inserted somewhere.
This problem here is just like url query, it's also a key-value pair, but allow duplicated keys. just being key-value pair is not enough.
The spec was written by python developers (python 2 back then) who I figure understood dictionary to mean unique keys.
And yes, other implementations also require unique keys.
The spec was written by python developers (python 2 back then) who I figure understood dictionary to mean unique keys.
And yes, other implementations also require unique keys.
thanks for your clarification, I just send a PR to document this, hope it can get merged.
(I don't know python 2 well but it has a unicode type I think?)
for example:
d3:keyi1e3:keyi2ee
for{"key": 1, b"key": 2}
(python)