# Replacing ext/json and pecl/jsonc with pecl/jsond

- Thread: https://externals.io/message/73676
- Original archive: https://news-web.php.net/php.internals/73676
- Started by jan.tvrdik@centrum.cz on 2014-04-12T12:02:55+00:00
- Messages: 3
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #73676 — jan.tvrdik@centrum.cz — 2014-04-12T12:02:55+00:00

URL: https://externals.io/message/73676#73676

Hi,

Is there a plan replace ext/json and pecl/jsonc with pecl/jsond? Using two 
implementations is pain in the ass because they are NOT compatible with each 
other and it is unlikely to change in the future.

AFAIK the latest version of **ext/json** has at least the following 
problems:
1) license incompatible with evil
2) causes fatal error for input {"\u0000": 1}
3) does not handle surrogates properly, e.g. "\uD811\uD811" is accepted and 
results in invalid UTF-8

Problems (2) a (3) are bugs (originally pointed out by Jakub Zelenka [1]) 
and can be most likely fixed, however problem (1) can not be solved.

AFAIK the latest version of **pecl/jsonc** has at least the following 
problems:
1) does not care about UTF-8 validity at all 
(https://github.com/remicollet/pecl-json-c/issues/9)
2) does not support `JSON_BIGINT_AS_STRING` 
   a) 64bit version causes a warning "option `JSON_BIGINT_AS_STRING` not 
implemented"
   b) 32bit version does not support numbers larger than 9223372036854775807
3) does not support \u0000 in keys 
(https://github.com/remicollet/pecl-json-c/issues/7)
4) does not support extended numbers syntax which is implemented in ext/json 
[2]

Unfortunately most of those problems are known for a while and there does 
not seem to be the attitude to fix them.

AFAIK the latest version of **pecl/jsond** has at least the following 
problems:
1) does not support extended numbers syntax which is implemented in ext/json 
[2]

However since we dropped in PHP 5.6 the extended literals syntax (e.g. TRUE) 
we may consider dropping the extended numbers syntax (e.g 0xff) as well to 
make it strictly follow the latest JSON RFC 
(http://tools.ietf.org/html/rfc7159, March 2014).


I think that the best long-term solution is to replace ext/json with 
pecl/jsond, preferably in PHP 5.6.0.

[1]: http://news.php.net/php.internals/73478
[2]: https://gist.github.com/JanTvrdik/10277952#file-test-php-L43-L60


Thanks,
Jan Tvrdik

---

## #73677 — Levi Morrison — 2014-04-12T13:33:20+00:00

URL: https://externals.io/message/73676#73677 · In reply to: #73676

> Hi,
>
> Is there a plan replace ext/json and pecl/jsonc with pecl/jsond? Using two
> implementations is pain in the ass because they are NOT compatible with
> each other and it is unlikely to change in the future.
>
> AFAIK the latest version of **ext/json** has at least the following
> problems:
> 1) license incompatible with evil
> 2) causes fatal error for input {"\u0000": 1}
> 3) does not handle surrogates properly, e.g. "\uD811\uD811" is accepted
> and results in invalid UTF-8
>
> Problems (2) a (3) are bugs (originally pointed out by Jakub Zelenka [1])
> and can be most likely fixed, however problem (1) can not be solved.
>
> AFAIK the latest version of **pecl/jsonc** has at least the following
> problems:
> 1) does not care about UTF-8 validity at all (https://github.com/
> remicollet/pecl-json-c/issues/9)
> 2) does not support `JSON_BIGINT_AS_STRING` 
>   a) 64bit version causes a warning "option `JSON_BIGINT_AS_STRING` not
> implemented"
>   b) 32bit version does not support numbers larger than 9223372036854775807
> 3) does not support \u0000 in keys (https://github.com/
> remicollet/pecl-json-c/issues/7)
> 4) does not support extended numbers syntax which is implemented in
> ext/json [2]
>
> Unfortunately most of those problems are known for a while and there does
> not seem to be the attitude to fix them.
>
> AFAIK the latest version of **pecl/jsond** has at least the following
> problems:
> 1) does not support extended numbers syntax which is implemented in
> ext/json [2]
>
> However since we dropped in PHP 5.6 the extended literals syntax (e.g.
> TRUE) we may consider dropping the extended numbers syntax (e.g 0xff) as
> well to make it strictly follow the latest JSON RFC (
> http://tools.ietf.org/html/rfc7159, March 2014).
>

I've never encountered any of these issues so I have nothing more to say on
them.*


> I think that the best long-term solution is to replace ext/json with
> pecl/jsond, preferably in PHP 5.6.0.
>

PHP 5.6 is in feature freeze. You'll have to shoot for PHP 5.7 or 6.0.


> [1]: http://news.php.net/php.internals/73478
> [2]: https://gist.github.com/JanTvrdik/10277952#file-test-php-L43-L60
>
>
> Thanks,
> Jan Tvrdik
>

* As an aside I support the no evil clause. I realize I am in the vast
minority here, but I wanted to say it.

---

## #73683 — Jakub Zelenka — 2014-04-13T19:13:45+00:00

URL: https://externals.io/message/73676#73683 · In reply to: #73676

Hi,

I think that the best long-term solution is to replace ext/json with
> pecl/jsond, preferably in PHP 5.6.0.
>

5.6 is in feature freeze as it was pointed out. I need to do lots of
testing before proposing jsond as a core replacement. 5.7 is the target
though... ;)

Jakub