Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69974
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.43 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <526F98C1.4040607@php.net>
References: <CAGa2bXYuE0s8eUPrhH+UPtmX2ETkx3afa116+8k3m+FK06Cxmg@mail.gmail.com>
 <526F98C1.4040607@php.net>
Date: Thu, 31 Oct 2013 08:05:52 +0900
Message-ID: <CAGa2bXZvOVBUE5nb_7OJq3CdxDqBMa5-Bex+ftsz5YwHwih-ow@mail.gmail.com>
To: Joe Watkins <krakjoe@php.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1135f79c5830ee04e9fd62e3
Subject: Re: [RFC] Use default_charset As Default Character Encoding
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a1135f79c5830ee04e9fd62e3
Content-Type: text/plain; charset=UTF-8

Hi Joe,

On Tue, Oct 29, 2013 at 8:15 PM, Joe Watkins <krakjoe@php.net> wrote:

> I'm not sure what it is you are actually trying to achieve here ??
>

I have 3 objectives in this RFC.

1. Setting charset in HTTP header is recommended since the first XSS
advisory in 2000 Feb. by CERT and Microsoft.
2. There are too many encoding settings and it is better to consolidated.
3. If we have yet another multibyte string module in the future, the new
settings can be used.

I'll add these if I didn't write them in RFC later.

I proposed "default_charset=UTF-8" years ago, but there were many users
uses "ISO-8859-*"/"EUC-*"/etc at that time and we decided leave the setting
to users.

+1 on the 5.5 changes
>
> But the rest I don't really understand what the aim is, it would seem that
> renaming settings, especially ones that are not actually anything to do
> with the core, is just breaking compatibility for no good reason.
>

Encoding must be specified for proper operation. It's a security risk also.


> What I could understand is a proposal to move the functionality provided
> by mbstring/iconv into core and introduce dot script_encoding complementary
> settings:
>
> zend.input_encoding
> zend.output_encoding
>
> I could understand this kind of proposal being aimed at 6.
>

I don't think Zend engine will have multibyte char handling feature at
least any time soon.

Currently, Zend engine has zend multibyte option, but it's only for
encoding that is not
compatible ISO-8859-1. (e.g. SJIS, BIG5. These encodings has \ in chars and
engine
would not work script written by these encodings with zend multibyte off.)

However, having encoding settings in the engine will work also even if it
does not use
them. It may be a good idea have these settings in the engine. I'm +1 for
this idea.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a1135f79c5830ee04e9fd62e3--