Re: Make Encode.pm support the real UTF-8

[email protected] (Nick Ing-Simmons)
Newsgroups perl.unicode
Message-ID <[email protected]>
Bjoern Hoehrmann <[email protected]> writes:
>
>>> Now that we have this problem, introducing more places where one needs
>>> to carefully check the documentation what is considered UTF-8 does not
>>> seem like the best option, having decode_utf8() and decode(utf8=>...)
>>> mean some- thing different is likely going to cause confusion. Maybe
>>> this could go the other way round, i.e. introduce a new encoding
>>> "UTF-8-Strict" or something.
>>
>>This is certainly more backwards compatible, but do we really want
>>perl applications to exchange illegal UTF-8 by default?
>
>Hmm, maybe I should ask why you proposed to keep the old behavior of
>encode_utf8 in the first place? The change would make more sense to
>me if both encode("UTF-8" => ...) and encode_utf8(...) were changed.

This was sort of discussed way back.
Perl uses 'utf8' (lower case no hyphen) at least partly to allow
UTF-8 (upper case hyphen) to be real one.

So IMHO encode_utf8() can/should stay as hacky but efficent to/from 
perl's internal form. encode('UTF-8',...) can be the "real" one.

Which leaves 'utf-8' 'uTf_8' and other "equivalents" undefined ;-)
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.