Jon Nelson <[email protected]> writes:
> I've found what I believe to be a bug in libidn (<= 1.25, didn't check
> more recent versions).
>
> The following IDNA-encoded domain, when run through idn, does not
> result in an error.
>
> xn--9k39ivpi18g4vn.cn
Strings that cannot be decoded are returned as-is. Quoting RFC 3490:
ToUnicode never fails. If any step fails, then the original input
sequence is returned immediately in that step.
Thus, I believe this is expected behaviour.
/Simon
> However, Python does complain:
>
> python -c "'xn--9k39ivpi18g4vn.cn'.decode('idna')"
>
> Traceback (most recent call last):
> File "<string>", line 1, in <module>
> File "/usr/lib64/python2.7/encodings/idna.py", line 193, in decode
> result.append(ToUnicode(label))
> File "/usr/lib64/python2.7/encodings/idna.py", line 131, in ToUnicode
> result = label1.decode("punycode")
> File "/usr/lib64/python2.7/encodings/punycode.py", line 208, in decode
> res = punycode_decode(input, errors)
> File "/usr/lib64/python2.7/encodings/punycode.py", line 195, in
> punycode_decode
> return insertion_sort(base, extended, errors)
> File "/usr/lib64/python2.7/encodings/punycode.py", line 177, in
> insertion_sort
> raise UnicodeError, ("Invalid character U+%x" % char)
> UnicodeError: Invalid character U+160bb4
_______________________________________________
Help-libidn mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/help-libidn
