Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73479
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.51 as permitted sender)
MIME-Version: 1.0
Sender: jakub.php@gmail.com
In-Reply-To: <CAEKnhAEx-CCd8mHQOgvXHHw85pBWNXqqti+kBLnTFeQj79LrMw@mail.gmail.com>
References: <CAEKnhAEx-CCd8mHQOgvXHHw85pBWNXqqti+kBLnTFeQj79LrMw@mail.gmail.com>
Date: Sat, 29 Mar 2014 20:02:06 +0000
Message-ID: <CAEKnhAHA4Q6dEoLtCuZqsUzjMVXJYYsJHef9O02ZYWv5Zv3oBg@mail.gmail.com>
To: PHP internals list <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e013cba98e95dc104f5c44ab6
Subject: Re: JSON issues
From: bukka@php.net (Jakub Zelenka)

--089e013cba98e95dc104f5c44ab6
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Mar 29, 2014 at 7:47 PM, Jakub Zelenka <bukka@php.net> wrote:

> Hi,
>
> I found few issues with the current ext/json during jsond testing:
>
> 1. The surrogate pairs for escaped Unicode characters are not handled
> correctly. For example JSON string "\uD811\uD811" (lead surrogate followed
> by lead surrogate) is accepted by the current implementation and converted
> to two ill-formatted UTF-8 characters. I would like to return NULL for such
> cases and set the new last json error code. I'm already using name
> JSON_ERROR_UTF16 for such case in jsond. If anyone thinks about better
> name, please let me know. This is apparently a bug but its fix require a
> new constant. I'm not sure about the version though. 5.6 only?
>
> 2. This is a valid JSON str: '{ "\u0000 key starting with zero": "value"
> }' . The problem is that it won't work when converted to stdClass as
> property name started with '\0' are used for mangled names.
> If you pass such string to json_decode, you will get a fatal error (the
> script is terminated). I would like to add a check to the JSON_Parser and
> return NULL from json_decode. It will requirea a new error code (new
> constant). Not sure about the name (any ideas welcomed) but it could be
> something like JSON_ERROR_MANGLED_PROPERTY_NAME. If user get such error,
> they can use assoc array (set second param for jsond_decode to true) and it
> will work. This should go to 5.6 as it's just an improvement that adds a
> new constant.
>
> 3. There is a small bug with number of digits when checking if it's a big
> number. The minus character is not considered for negative values which
> means that some really low numbers are considered as low even if they could
> be converted to long. It's a quick fix which should go to 5.4+
>
> Any thoughts, comments or objections?
>
> Jakub
>
>
>
Oops. The issue number 3 is fine. Got a bit confused as I was fixing such
case in jsond but the implementation is slightly different... The result is
correct on both.

So the real issues are just 1. and 2. :)

Thanks

Jakub

--089e013cba98e95dc104f5c44ab6--