Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:60908
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 209.85.214.170 as permitted sender)
MIME-Version: 1.0
Date: Thu, 21 Jun 2012 00:21:50 +0200
Message-ID: <CAF+90c-T9hPbuS3bUxnHw-+B+Y2VLu55wQJ8UrtzrcC7TiKyVw@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: json_encode() behavior for incorrectly encoded strings
From: nikita.ppv@googlemail.com (Nikita Popov)

Hi internals!

We currently have a big mess concerning the behavior of json_encode()
with incorrectly encoded UTF-8 strings.

To summarize the situation:

PHP <= 5.3.13, PHP 5.4, master behave as follows when an invalid UTF-8
string is encountered:
 * The invalid string is replaced with "null", thus creating a partial
JSON serialization
 * json_encode() returns the partial serialization, *not* false as it should
 * A warning is thrown, but only if display_errors=off
 * json_last_error() returns JSON_ERROR_UTF8

PHP 5.3.14 behaves as follows:
 * json_encode() returns false, as it should
 * A warning is thrown always, even with display_errors=on
 * json_last_error() returns JSON_ERROR_UTF8
 * 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=on)
appropriate without further discussion.

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 <= 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.

Nikita