That doesn't double encode either. That doesn't change the string at all. (Remove the upgrade from your code and you get the same output.)LOL you just won't budge! Now, why doesn't utf8::upgrade 'change' the string if it does the following: Converts in-place the internal representation of the string from an octet sequence in the native encoding (Latin-1 or EBCDIC) to UTF-X
Am I to assume that it won't 'change' the string only if the string is indeed in 'native encoding', which can be Latin-1 or EBCDIC? (but not, say, UTF-8?)
That doesn't seem terribly confusing. Yes, it doesn't do double encoding, as far as I can tell, it looks more like single decoding (perl -MEncode=decode -MDevel::Peek -E 'my $s = "\xff"; Dump decode("Latin-1", $s); utf8::upgrade($s); Dump $s')._utf8_on and utf8::upgrade both end up with an upgraded string, _utf8_one is the one used throughout the docs for Test::utf8, and your comment was wrong whichever function you were talking about.And utf8::upgrade is the one that produces exactly the kind of strings that is_sane_utf8 is intended to catch, so 'upgraded' strings is a good enough description ('decoded from Latin-1' is also good), unlike 'double encoding', where, for is_sane_utf8 purposes, the problem is neither with encoding, nor does something needs to happen twice.
In reply to Re^7: JSON::XS (and JSON::PP) appear to generate invalid UTF-8 for character in range 127 to 255
by Anonymous Monk
in thread JSON::XS (and JSON::PP) appear to generate invalid UTF-8 for character in range 127 to 255
by Ovid
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |