Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:60914
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.42 as permitted sender)
MIME-Version: 1.0
Sender: laruence@gmail.com
In-Reply-To: <CAEZPtU4tVeMy1h3phgabO1pYnRKfym12WgXkf3VBVYZGRumHog@mail.gmail.com>
References: <CAF+90c-T9hPbuS3bUxnHw-+B+Y2VLu55wQJ8UrtzrcC7TiKyVw@mail.gmail.com>
 <CAEZPtU4tVeMy1h3phgabO1pYnRKfym12WgXkf3VBVYZGRumHog@mail.gmail.com>
Date: Thu, 21 Jun 2012 14:51:15 +0800
Message-ID: <CABBJUpcZ57Z8zvgBV8pNNdGTcsAtPEmnFSBWjNBGFnBMmXszGw@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Cc: Nikita Popov <nikita.ppv@googlemail.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] json_encode() behavior for incorrectly encoded strings
From: laruence@php.net (Laruence)

On Thu, Jun 21, 2012 at 2:47 PM, Pierre Joye <pierre.php@gmail.com> wrote:
> hi,
>
> On Thu, Jun 21, 2012 at 12:21 AM, Nikita Popov
> <nikita.ppv@googlemail.com> wrote:
>
>> We currently have a big mess concerning the behavior of json_encode()
>> with incorrectly encoded UTF-8 strings.
>>
>> To summarize the situation:
>>
>> PHP <=3D 5.3.13, PHP 5.4, master behave as follows when an invalid UTF-8
>> string is encountered:
>> =C2=A0* The invalid string is replaced with "null", thus creating a part=
ial
>> JSON serialization
>> =C2=A0* json_encode() returns the partial serialization, *not* false as =
it should
>> =C2=A0* A warning is thrown, but only if display_errors=3Doff
>> =C2=A0* json_last_error() returns JSON_ERROR_UTF8
>>
>> PHP 5.3.14 behaves as follows:
>> =C2=A0* json_encode() returns false, as it should
>> =C2=A0* A warning is thrown always, even with display_errors=3Don
>> =C2=A0* json_last_error() returns JSON_ERROR_UTF8
>> =C2=A0* If the PHP_JSON_PARTIAL_OUTPUT_ON_ERROR option is specified, the
>> old behavior is restored
>>
>> The reason for this situation is that a patch was applied for all
>> branches, and then reverted, because Stas didn't consider the change
>> towards always throwing a warning (even with display_errors=3Don)
>> appropriate without further discussion.
>
> Well, not sure we have to discuss why such thing is bad.
> display_errors must be respected.

Agree, and it shall be, no any exception.

thanks
>
> Also I suspect that this change should not even be merged in 5.4 nor
> 5.3. At least not without real testing.
>
>> The backout though was done only on PHP 5.4 and master, but *not* on
>> the PHP 5.3 branch.
>>
>> Thus we now have differing behavior between 5.3 and 5.4 (and PHP <=3D 5.=
3.13).
>>
>> So, I'd like to ask whether the patch can be reapplied to 5.4 and
>> master or whether we should do something else to solve this problem.
>
> 5.3 should be brought in line with 5.4.
>
> Cheers,
> --
> Pierre
>
> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>



--=20
Laruence =C2=A0Xinchen Hui
http://www.laruence.com/