Problems recognizing and/or reformatting escapes #37
Comments
|
Can anyone please take a look at this? I have the same problem: in: It works perfect when using the webiste: http://www.jsonlint.com |
|
👍 - this just screwed my config as well, would be great to be fixed. |
|
I'm having the same problem… |
ntdaley
added a commit
to ntdaley/jsonlint
that referenced
this issue
Oct 14, 2014
Previously the different escape characters were being applied one after the other, so that "\\n" in the json will get turned into a new-line instead of "\n". Previously unicode escapes were not being converted resulting in stringifying the parse result turning "\u20AC" getting turned into "\\u20AC". Previously "\/" was not being converted resulting in stringifying the parse result turning it into "\\/" Note: I removed handling of '\v' because this would not be accepted by the lexer anyway, and is not part of the json standard. Note: Because unicode escapes are converted, strings in the input like "\u20AC" will become their unicode equivalent after parsing (e.g. in this case the euro character). Also changed the command line use of JSON.stringify to further process the result to convert non-ASCII printable characters to unicode escapes. While not strictly necessary according to the JSON standard, ascii output is safer for some parsers, and now that the parser processes unicode escapes there is more chance of having non-ASCII characters in the parser output. I would suggest that it would be better to always use formatter.js instead of JSON.stringify, because that way the choice between unicode escaped values and unicode characters would always be the same for input and output. Similar formatting changes should probably be made in the web version.
|
Same problem. Expected output: |
mwittig
pushed a commit
to mwittig/jsonlint
that referenced
this issue
Feb 16, 2019
Previously the different escape characters were being applied one after the other, so that "\\n" in the json will get turned into a new-line instead of "\n". Previously unicode escapes were not being converted resulting in stringifying the parse result turning "\u20AC" getting turned into "\\u20AC". Previously "\/" was not being converted resulting in stringifying the parse result turning it into "\\/" Note: I removed handling of '\v' because this would not be accepted by the lexer anyway, and is not part of the json standard. Note: Because unicode escapes are converted, strings in the input like "\u20AC" will become their unicode equivalent after parsing (e.g. in this case the euro character). Also changed the command line use of JSON.stringify to further process the result to convert non-ASCII printable characters to unicode escapes. While not strictly necessary according to the JSON standard, ascii output is safer for some parsers, and now that the parser processes unicode escapes there is more chance of having non-ASCII characters in the parser output. I would suggest that it would be better to always use formatter.js instead of JSON.stringify, because that way the choice between unicode escaped values and unicode characters would always be the same for input and output. Similar formatting changes should probably be made in the web version. (cherry picked from commit ecf1830)
russaa
added a commit
to mmig/jsonlint-pos
that referenced
this issue
Jun 24, 2020
zaach#54 from ntdaley:master with commits: #ecf1830f21634f2b711b4fd840789ec8ddf01649 #aaf81b140f12cfa20ba9411770fa26f665ba6010
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I've noticed a couple of issues in the reformatted output when there's escapes in the input:
disappearing slashes. This represents a two-character string, not a newline escape:
"\\n""\\n""\n"This also happens for b, r, f, and t.
unexpected slashes.
"\u0066""f"(or"\u0066")"\\u0066"The text was updated successfully, but these errors were encountered: