Bug #75986 [Com]: JSON parser not following preposed RFC

From: Date: Tue, 20 Feb 2018 16:21:13 +0000
Subject: Bug #75986 [Com]: JSON parser not following preposed RFC
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-214057@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=75986&edit=1 ID: 75986 Comment by: welfordmartin at gmail dot com Reported by: welfordmartin at gmail dot com Summary: JSON parser not following preposed RFC Status: Not a bug Type: Bug Package: JSON related Operating System: Ubuntu Server 16.04 & Windows 10 PHP Version: 7.2.2 Block user comment: N Private report: N New Comment: If that is the case the PHP parse is still incorrect as "/" is working without escaping and is listed on the escape list as >%x2F / ; / solidus U+002F so it should force me to escape to use a forward slash "\/" (as json_encode does)? also sorry I have just opened up the HTML version of that RFC to see it's been outdated twice now, the Current standard is: https://tools.ietf.org/html/rfc8259 Previous Comments: ------------------------------------------------------------------------ [2018-02-20 15:10:10] nikic@php.net > Please tell me where in that specification it states only it sates "unescaped / escape ( > ... )" that in English means "unescaped or escape ( ... ) " and Javascript engines > agree with that statement as they work in parsing that JSON. even IE. I'm sorry, I don't know how I can explain this to you. There is simply no way for this grammar to accept the sequence "\d". It does not match as "unescaped" because "\" is not allowed in unescaped. It does not match "escaped", because "\" cannot be followed by "d". >The representation of strings is similar to conventions used in the C >family of programming languages. A string begins and ends with >quotation marks. All Unicode characters may be placed within the >quotation marks except for the characters that must be escaped: >quotation mark, reverse solidus, and the control characters (U+0000 through U+001F) This quite explicitly says "[...] except for the characters that must be escaped: [...] reverse solidus [...]". "\" is a reverse solidus. "\" must be escaped. > Since \d is not a valid escape it should be literal the same as the conventions in c family > langs. most if not all including PHP fall back to string escape is not valid use literal. It's nice that you think this way, but this is not what the JSON specification says and consequently not what PHP does. Also, your claim that JavaScript implementations follow the behavior you describe is incorrect. If you write JSON.parse("\"\\d\"") you will receive a syntax error. You need to use JSON.parse("\"\\\\d\"") instead. What you probably tried is to simply parse the JSON as JS, which has entirely different and much less strict rules. If you want to parse JS, please use a JS parser, not a JSON parser. ------------------------------------------------------------------------ [2018-02-20 15:02:25] welfordmartin at gmail dot com >No, "\" may be followed **only** by the characters listed there. Note that the >"unescaped" production explicitly excludes "\". Please tell me where in that specification it states only it sates "unescaped / escape ( ... )" that in English means "unescaped or escape ( ... ) " and Javascript engines agree with that statement as they work in parsing that JSON. even IE. Also to this note the specification of string on page 4, >The representation of strings is similar to conventions used in the C >family of programming languages. A string begins and ends with >quotation marks. All Unicode characters may be placed within the >quotation marks except for the characters that must be escaped: >quotation mark, reverse solidus, and the control characters (U+0000 through U+001F) Since \d is not a valid escape it should be literal the same as the conventions in c family langs. most if not all including PHP fall back to string escape is not valid use literal. ------------------------------------------------------------------------ [2018-02-20 14:50:47] welfordmartin at gmail dot com Also since JSON stands for JavaScript Object Notation it would stand to reason that all of the Javascript engines currently in use do this correctly and don't escape things that are not listed as an escape. so everything else implementing it should do that as well. ------------------------------------------------------------------------ [2018-02-20 14:50:43] nikic@php.net > Since backslash d (\d) is not one of the listed escapes allowed it should be evaluated to > unescaped (literal) "\" and "d"? as that is exactly what that standard. with > unescaped or escape one of this list it is explicitly a / meaning or. No, "\" may be followed **only** by the characters listed there. Note that the "unescaped" production explicitly excludes "\". > also, the UTF-8 encoded was tried after I mean to set it back to bracers before posting it in > the bug. Did you use both \\d and {} or \uXXXX escape sequences? If you still had \d the JSON would still be invalid. ------------------------------------------------------------------------ [2018-02-20 14:44:25] welfordmartin at gmail dot com you mean page 5. But even that says unescaped or escape one of %x22 / ; " quotation mark U+0022 %x5C / ; \ reverse solidus U+005C %x2F / ; / solidus U+002F %x62 / ; b backspace U+0008 %x66 / ; f form feed U+000C %x6E / ; n line feed U+000A %x72 / ; r carriage return U+000D %x74 / ; t tab U+0009 %x75 4HEXDIG ) ; uXXXX U+XXXX Since backslash d (\d) is not one of the listed escapes allowed it should be evaluated to unescaped (literal) "\" and "d"? as that is exactly what that standard. with unescaped or escape one of this list it is explicitly a / meaning or. also, the UTF-8 encoded was tried after I mean to set it back to bracers before posting it in the bug. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=75986 -- Edit this bug report at https://bugs.php.net/bug.php?id=75986&edit=1

« previous php.bugs (#214057) next »