Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92772
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.195 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAESVnVo-BV7BOWV2H4ie1z48XofKnejArHm++zB9wGRPC4rB6w@mail.gmail.com>
References: <CAESVnVo-BV7BOWV2H4ie1z48XofKnejArHm++zB9wGRPC4rB6w@mail.gmail.com>
Date: Tue, 26 Apr 2016 18:06:41 +0900
Message-ID: <CAGa2bXZSc=RkrBzwMg5K+MLfxc6XAL4ZSBRs7yjzkSLiPXeE2g@mail.gmail.com>
To: Sara Golemon <pollita@php.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] IntlCharsetDetector
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

Hi Sara,

On Tue, Apr 12, 2016 at 7:54 AM, Sara Golemon <pollita@php.net> wrote:
> With a light push from Stas, I've decided to go ahead and put up
> IntlCharsetDetector for discussion.
> https://wiki.php.net/rfc/intl.charset-detector
>
> I'm still not personally convinced this API is trustworthy enough, but
> it's worth a formal discussion period at least.

Things might have been changed, but as you've mentioned encoding
detection is unstable and ICU is poor compared to mbstring's detection
at least for Japanese encodings.

Developers should not rely on encoding detector, but they should validate
encoding.

Problem is there are cases that developers cannot determine used encoding...
If we are going to have this API, it would be better to validate string with
detected encoding by default and disable encoding validation optionally.
There are cases that developers have to deal with broken string data
on occasion.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net