I've escaped control characters and am feeding my validated JSON into JSON.parse and jQuery.parseJSON. Both are giving the same result.

Getting error message "Unexpected token $":

$(function(){
    try{
        $.parseJSON('"\\\\\"$\\\\\"#,##0"');
    } catch (exception) {
        alert(exception.message);
    }    
});

<script src=".8.3/jquery.min.js"></script>

I've escaped control characters and am feeding my validated JSON into JSON.parse and jQuery.parseJSON. Both are giving the same result.

Getting error message "Unexpected token $":

$(function(){
    try{
        $.parseJSON('"\\\\\"$\\\\\"#,##0"');
    } catch (exception) {
        alert(exception.message);
    }    
});

<script src="https://ajax.googleapis./ajax/libs/jquery/1.8.3/jquery.min.js"></script>

Thanks for checking out this issue.

• javascript
• jquery
• json

• The error seems to be in the pattern in '{"id":"M","label":"Price","type":"number","pattern":"\\\\\"$\\\\\"#,##0"}'. – Mörre Commented Jan 18, 2015 at 10:57
• There seems to be another issue after that 'unexpected number'. I can't find these for the life of me. – robbintt Commented Jan 18, 2015 at 11:00
• Interestingly, JSONLint declares the above string correct JSON.parse fails! – Mörre Commented Jan 18, 2015 at 11:02
• That's what I find so interesting. Anyone with eagle eyes that can spot the 'unexpected number' after deleting the value that Someone mentioned in the first ment? – robbintt Commented Jan 18, 2015 at 11:02
• 1 The json es from JSON.stringify !!! – robbintt Commented Jan 18, 2015 at 11:03

2 Answers 2

What's happening here is that there are two levels of backslash removal being applied to the string. The first is done by the browser's JavaScript engine when it parses the single-quoted string. In JavaScript, single-quoted strings and double-quoted strings are exactly equivalent (other than the fact that single-quotes must be backslash-escaped in single-quoted strings and double-quotes must be backslash-escaped in double-quoted strings); both types of strings take backslash escape codes such as \\ for backslash, \' for single-quote (redundant but accepted in double-quoted strings), and \" for double-quote (redundant but accepted in single-quoted strings).

In your JavaScript single-quoted string literal you have several instances of this kind of thing, which are meant to be valid JSON double-quoted strings:

"\\\\\"$\\\\\"#,##0"

After the browser has parsed it, the string contains exactly the following characters (including the outer double-quotes, which are unremoved because they are contained in a single-quoted string):

"\\"$\\"#,##0"

You can see that each consecutive pair of backslashes became a single literal backslash, and the two cases of an odd backslash followed by a double-quote each became a literal double-quote.

That is the text that is being passed as an argument to $.parseJSON, which is when the second level of backslash removal occurs. During JSON parsing of the above text, the leading double-quote signifies the start of a JSON string literal, then the pair of backslashes is interpreted as a single literal backslash, and then the immediately following double-quote terminates the JSON string literal. The stuff that follows (dollar, backslash, backslash, etc.) is invalid JSON syntax.

The problem is that you've embedded valid JSON in a JavaScript single-quoted string literal, which, although it happens to be valid JavaScript syntax by fluke (it wouldn't have been if the JSON contained single-quotes, or if you'd tried using double-quotes to delimit the JavaScript string literal), no longer contains valid JSON after being parsed by the browser's JavaScript engine.

To solve the problem, you have to either manually escape the JSON content to be properly embedded in a JavaScript string literal, or load it independently of the JavaScript source, e.g. from a flat file.

Here's a demonstration of how to solve the problem using your latest example code:

$(function() {
    try {
        alert($.parseJSON('{"key":"\\\\\\\\\\"$\\\\\\\\\\"#,##0"}').key); // works
        alert($.parseJSON('{"key":"\\\\\"$\\\\\"#,##0"}').key); // doesn't work
    } catch (exception) {
        alert(exception.message);
    }    
});

http://jsfiddle/814uw638/2/

Since JavaScript has a simple escaping scheme (e.g. see http://blogs.learnnowonline./2012/07/19/escape-sequences-in-string-literals-using-javascript/), it's actually pretty easy to solve this problem in the general case. You just have to decide in advance how you're going to quote the string in JavaScript (single-quotes are a good idea, because strings in JSON are always double-quoted), and then when you prepare the JavaScript source, just add a backslash before every single-quote and every backslash in the embedded JSON. That should guarantee it will be perfectly valid, regardless of the exact JSON content (provided, of course, that it is valid JSON to begin with).

In your original problem, why do you need to do JSONparse in the first place? You could have easily gotten the object you wanted by just doing

var o = { blah }

by manually removing the single quotes you have around the curly braces rather than doing

$.JSONparse('{blah}')

Is there any reason for evaluating the string first (ie var s = '{blah}' and then doing $.JSONparse(s)) which is what your original code was doing? There shouldn't be a case where this is necessary. Since you mentioned somewhere that the string was produced by JSON.stringify, there shouldn't be a scenario where you need to explicitly store it into a variable (ie copy and paste it and put quotes around it).

The main problem here is the string produced by JSON.stringify, which is properly escaped, has been 'evaluated' once when you manually put braces around it. So the key is to make sure the string doesn't get 'evaluated'

Even if you wanted to pass the stringified variable to database or anything, there is no need to explicitly use quotes. One could do

var s = JSON.stringify(obj);
db.save("myobj",s)
var newObj = JSON.parse(db.load("myobj"))

The string is stored verbatim without getting evaluated, so that when you retrieve it, you would have the exact same string.