Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103089
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.15.15 as permitted sender)
To: Andrea Faulds <ajf@ajf.me>, internals@lists.php.net
References: <41b344e5-51ed-4e81-f6a4-b4f2748fb17e@gmx.de>
 <47.96.32660.815707B5@pb1.pair.com>
Message-ID: <d0a8f668-ea3f-9ac7-3c31-cbafd8a8e6c6@gmx.de>
Date: Sun, 12 Aug 2018 23:11:01 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.0
MIME-Version: 1.0
In-Reply-To: <47.96.32660.815707B5@pb1.pair.com>
Content-Type: text/plain; charset=utf-8
Content-Language: de-DE
Content-Transfer-Encoding: 8bit
Subject: =?UTF-8?Q?Re=3a_default=5fencoding_RFC_=e2=80=93_aftermath?=
From: cmbecker69@gmx.de ("Christoph M. Becker")

Hi Andrea!

On 12.08.2018 at 19:57, Andrea Faulds wrote:

> Christoph M. Becker wrote:
>
>> I'm quite happy, though, that this
>> hasn't happened yet, since it seems that the encoding names may be
>> different between the extensions.  At least the php.net manual states[2]:
>>
>> | Some systems (like IBM AIX) use "ISO8859-1" instead of "ISO-8859-1" so
>> | this value has to be used in configuration options and function
>> | parameters.
>>
>> It appears to be worthwhile to review the deprecation of the respective
>> iconv.* ini options.  Not quite sure about the mbstring.* ini options.
> 
> Could this not be solved by making all the extensions support all the
> encoding name aliases or so? That wouldn't be difficult to implement and
> wouldn't break anything.

I think that would only be possible, if we knew how they have to be
mapped.  Consider the AIX example above; I'm not even sure if this is
(still) valid, but should we have special maps for AIX?  Should we try
to detect this during configuration?  I'm not sure if that's even
reliably possible, since some iconv implementations (which ones?) do not
support errno[1], so we can't detect whether iconv_open() failed with
EINVAL, or some other error.  As it is now, it's simply up to the user
to pass a supported encoding name.

[1]
<https://github.com/php/php-src/blob/php-7.3.0beta1/ext/iconv/config.m4#L125>

-- 
Christoph M. Becker