SRP_Json doesn't escape double quotes anymore?

r.od.akker

After upgrading to the latest SRP Utilities, the SRP_Json module doesn't convert double quotes to \" anymore. This was working in the older version.

If SRP_Json(ArrayHandle, "New", "Array") then
   SRP_Json(ArrayHandle, "AddValue", "12345")
   SRP_Json(ArrayHandle, "AddValue", '12345 Iets met \"blabla\"')
   SRP_Json(ArrayHandle, "AddValue", 67890, "Number")
   SRP_Json(ArrayHandle, "AddValue", 1, "Boolean")
   JSON = SRP_Json(ArrayHandle, "Stringify", "Fast")
   SRP_Json(ArrayHandle, "Release")
end

So this produces:

[12345,"12345 Iets met "blabla"",67890,true]

KevinFournier

SRP Utilities 9.x used an open source json library designed for C++. It appears backslash-escaping was a feature, one we never advertised or used. This unintended feature also has an unintended bug: requiring users to use double-backslashes if they want a literal backslash, which is unexpected behavior for OI developers.

That library, however, would not translate to 64-bit, so we rolled out our own, which is why the feature disappeared. Not because we ignored it, but because--as far as we were concerned--it wasn't there in the first place. An oversight, in retrospect, but it helps explain where our design philosophy was at.

The goal of SRP_JSON is to use BASIC+ conventions so OI developers don't have to worry about json-specific encoding. Your example above would have worked just fine in any version of SRP Utilities without the backslashes.

If altering your code is not an option, let me know and I will provide you a download link for version 1.6.

r.od.akker

Ok, I now understand where this change comes from. But especially when you intentionally left this 'feature' out, I think it should at least have been mentioned at the change logs. Now we had to downgrade using trial and error to see when this feature came back.

Also I would expect when a dedicated JSON library is created, that this would follow the official JSON specs. Like you said; the library was created so that developers don't need to worry about json-specific encoding. So in that perspective I'm not sure what you mean with "if altering your code is not an option". Do you mean we have to check out every place where we use the JSON encoder, and first use a SWAP to convert al our double quotes to \" ??

The RFC stated clearly that the double quotation mark should be escaped with a backslash.

Eventually we managed to restore our original SRP Utilities from backups, so our panic situation it over for now. I do like to use latest stable versions though, because usually other bugs are fixed in these versions. So I'd like to know how SRP_JSON behaves in this 1.6 version. If you disagree about the escaping, maybe it's possible to implement it as an option when stringifying?

r.od.akker

Kevin, my collegue mentioned to me that my example code is incorrect. The code that I posted was actually my second attempt to see if I could manually escape the double quotes. I was meaning to post this code instead:

So this code:

If SRP_Json(ArrayHandle, "New", "Array") then
   SRP_Json(ArrayHandle, "AddValue", "12345")
   SRP_Json(ArrayHandle, "AddValue", '12345 Iets met "blabla"')
   SRP_Json(ArrayHandle, "AddValue", 67890, "Number")
   SRP_Json(ArrayHandle, "AddValue", 1, "Boolean")
   JSON = SRP_Json(ArrayHandle, "Stringify", "Fast")
   SRP_Json(ArrayHandle, "Release")
end

produces this output:

[12345,"12345 Iets met "blabla"",67890,true]

.. with unescaped double quotes.

Sorry if this caused confusion, my bad.

So the expected output, was of course:

[12345,"12345 Iets met \"blabla\"",67890,true]

IMHO the SRP_JSON functions should properly escape the characters in the string automatically to comply with the json standards.

KevinFournier

I have confirmed that SRP_JSON was never working the way I had intended it. That is a gigantic oversight on my part. So, after finishing my rather large piece of humble pie, I got this working according to design. So, yes, version 2.0.2 and later will break any code that relies on having to explicitly pass escape sequences.

I always like to provide pre-releases (or Release Candidates) before sending them out into the wild. All my unit tests pass, but I'd appreciate it if you downloaded version 2.0.2 RC1 and confirmed that it works to your expectations as well.

r.od.akker

Thank you for your efforts Kevin. The JSON parts works fine now, but we have a new problem now. I created a seperate topic for that; the problem is within SRP_Com.