Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73478
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.48 as permitted sender)
MIME-Version: 1.0
Sender: jakub.php@gmail.com
Date: Sat, 29 Mar 2014 19:47:25 +0000
Message-ID: <CAEKnhAEx-CCd8mHQOgvXHHw85pBWNXqqti+kBLnTFeQj79LrMw@mail.gmail.com>
To: PHP internals list <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7bf0ec22744a0f04f5c416b0
Subject: JSON issues
From: bukka@php.net (Jakub Zelenka)

--047d7bf0ec22744a0f04f5c416b0
Content-Type: text/plain; charset=ISO-8859-1

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

--047d7bf0ec22744a0f04f5c416b0--