On Thu, Feb 4, 2016 at 10:43 AM, Eric Grange <zarglu at gmail.com> wrote:
> I have been experimenting with using the json1 extension to generate json > sql-side rather than code-side, but I am hitting an issue with the CR & LF > characters which are not escaped, which results in json that fails > JSON.parse or use as JSONP in browsers. Ideally CR / LF should be encoded > as \r and \n respectively. > > Is it by design or an oversight? > http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf, page 4, section 9 String, states: A string is a sequence of Unicode code points wrapped with quotation marks (U+0022). All characters may be placed within the quotation marks except for the characters that must be escaped: quotation mark (U+0022), reverse solidus (U+005C), and the control characters U+0000 to U+001F. There are two-character escape sequence representations of some characters. \" represents the quotation mark character (U+0022). \\ represents the reverse solidus character (U+005C). \/ represents the solidus character (U+002F). \b represents the backspace character (U+0008). \f represents the form feed character (U+000C). \n represents the line feed character (U+000A). \r represents the carriage return character (U+000D). \t represents the character tabulation character (U+0009). So, for example, a string containing only a single reverse solidus character may be represented as "\\". The wording above doesn't seem to "require" these characters to be escaped. Only double-quote, and backlash need to be. My own JSON serializer does, but the spec doesn't require it apparently. So json1 seems OK and to-spec... Is there a way around using the replace() function to fix it? (though I > guess other control characters will have the issue, so multiple > replace() would be needed) > Many JSON serializers have options, like ascii-only (no UTF-8 encoded char, only \uffff codes), etc... Perhaps json1 could gain such options somehow. --DD
