![]() ![]() It doesn't say anything about prohibiting surrogate sequence for unicode escape. This line specifically shows that: %x75 4HEXDIG String = quotation-mark *char quotation-mark I think you don't understand the RFC and the string ABNF. As you can see, this is a different example and I can't see that PHP violates the spec nor it's own contract here. That's covered by the specs you quote, but not the flaw I reported here. If a string would have been passed json_decode containing the related binary sequence - as what you say would be allowed by the JSON spec - PHP handles it correctly according the documented contract: The binary sequence would qualify as *not* being an UTF-8 string and therefore the result of the function is unexpected: ![]() U D834 is not a character in the Basic Multilingual Plane (see Unicode, compare with a reference, exemplary: ). It's about the strings _represented_ by JSON (not in binary), and more specifically the option to use an \uXXXX (six characters) escape sequence for any character in the Basic Multilingual Plane (U 0000 through U FFFF). You've perhaps been misguided by the internals mailings (haven't read those), the part you quote is about binary string data.īut the report I created is *not* about binary data, you can see, the string presented is US-ASCII without any control characters. Thank you for taking the time to look into it.īut I'm very sorry to highlight that the information you've provided in your comment is best of all only remotely related to this issue and does not touch the root-cause of the flaw reported here. Tklingenberg at lastflood dot net Hi bukka,
0 Comments
Leave a Reply. |