Re: [RFC][DISCUSSION] Remove utf8_decode() and utf8_encode()

Hi all, On Mon, Aug 22, 2016 at 7:55 PM, Michael Wallner <mike@php.net> wrote: > On 22/08/16 12:44, Rowan Collins wrote: > >> As far as I can see, these functions exist because the XML parser >> infrastructure needed them, and someone thought it might be handy to >> expose them to users. Funnily enough, the internal versions actually >> take a parameter for the target encoding, but only support US-ASCII and >> 8859-1: €¿{ipŸ{ì£ >> €µo£Ähttps://github.com/php/php-src/blob/master/ext/xml/xml.c#L283 >> >> If anything, they should probably have a "str_" prefix, and maybe even >> be moved into the string section of the source, exposed in such a way >> that the XML parser can still make use of them. > > Thanks for looking deeper. That makes even more sense now. Any more comments for prefixing "str_"? str_latin1_to_utf8() == utf8_encode() str_utf8_to_latin1() == utf8_decode() I'm a little uncomfortable to have special new encoding conversion functions for ISO-8859-1 in ext/standard. However, it's better than keeping utf8_decode/encode() as primary function names forever. Although encoding parameter is not exposed to users, but the XML module internal code for utf8_encode/decode() supports ISO-8859-1 and ASCII (convert chars > 127 to '?'). If this resolution is adopted, I'll remove ASCII support and make it work only for ISO-8859-1. No external library is used. New functions can be defined as ext/standard functions. Users cannot specify encoding, so there is no BC in userland. Internal APIs are exposed. 3rd party modules may have BC. Internal APIs are named xml_utf8_encode/decode(). I would not like to keep them in ext/standard nor expose them to 3rd party module developers. Alternatively, we may keep XML module as it is now and add "xml_" prefix functions xml_latin1_to_utf8() == utf8_encode() xml_utf8_to_latin1() == utf8_decodoe() then encourage users to use general encoding conversion functions in the manual. I prefer this way. May I have voting choices? Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net