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:
- license incompatible with evil
- causes fatal error for input {"\u0000": 1}
- 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:
- does not care about UTF-8 validity at all
(https://github.com/remicollet/pecl-json-c/issues/9) - does not support
JSON_BIGINT_AS_STRING
a) 64bit version causes a warning "optionJSON_BIGINT_AS_STRINGnot
implemented"
b) 32bit version does not support numbers larger than 9223372036854775807 - does not support \u0000 in keys
(https://github.com/remicollet/pecl-json-c/issues/7) - 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:
- 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.
Thanks,
Jan Tvrdik
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:
- license incompatible with evil
- causes fatal error for input {"\u0000": 1}
- does not handle surrogates properly, e.g. "\uD811\uD811" is accepted
and results in invalid UTF-8Problems (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:
- does not care about UTF-8 validity at all (https://github.com/
remicollet/pecl-json-c/issues/9)- does not support
JSON_BIGINT_AS_STRING
a) 64bit version causes a warning "optionJSON_BIGINT_AS_STRINGnot
implemented"
b) 32bit version does not support numbers larger than 9223372036854775807- does not support \u0000 in keys (https://github.com/
remicollet/pecl-json-c/issues/7)- does not support extended numbers syntax which is implemented in
ext/json 2Unfortunately 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:
- does not support extended numbers syntax which is implemented in
ext/json 2However 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.
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.
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