Hi all,

On Mon, Aug 22, 2016 at 7:55 PM, Michael Wallner <m...@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: 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
yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to