1 person found this helpful
Exactly how do you get the json into extendscript?
I take it that there a web service or asp page that you call. Are you using the socket object in Extendscript?
It reminds me of a problem we've encountered trying to use the socket object with UTF-8 encoding. There is a confirmed bug associated with the utf-8 encoding, at least up to CS6. I do no know whether it's still there in CC.
The following is part of my description of the bug: Using Socket.open with its optional parameter "encoding" set to "UTF-8", we currently get unpredictable results, with "blocks" of data suddenly left out after multiple byte characters, in the middle of the data read.
(I take it that you have checked that the result from the service is all right.)
Message was edited by: Andreas Jansson. Removing a block of text, having read the question again.
I'm bringing in the JSON with HTTPRequest and the encoding is set to UTF-8. Would setting it to something else fix the issue?
You write that you use "HTTPRequest". Then it's perhaps not extendscript? Or is it an object from Bridge that you use? Or Flash? Or calling a vbscript?
Anyway, I wrote my answer (below) before noticing that you might not use the socket object at all. Keep that in mind, when you read the answer:
Most likely so. It was once registered as a bug, and as I interpreted the answer from Adobe earlier this year (spring 2013), they could repeat the bug, but now that I asked for a status update yesterday (due to your question and my newly awakened interest in it), I got an answer from Adobe stating that there was no bug, and that the error is in the web server.
Here my view on it:
We created a test webservice method that returns "IöIöIöIöIöIöIö" (the "ö" to include a character that is encoded as more than one byte using UTF-8)
The web server method always returns the exact same string, and using the "binary" setting on the socket object we also get the exact same result on every call. I don't see how this could it be a problem with the web server...
This is the source code of the test web service call:
<WebMethod(Description:="Returns the same characters Iö repeated 5000 times (10000 characters)> _
Public Function Get10000() As String
Return (String.Concat(Enumerable.Repeat("Iö", 5000)))
The method returns 10.000 characters.
We have also checked that the result from the webservice method is intact when comes back to the calling computer, using a program called Fiddler (http://fiddler2.com/).
We used Fiddler as a "proxy", letting the Adobe socket object make its call through Fiddler to the webservice. Fiddler showed an unbroken sequence of "IöIöIö..." (all 10000 characters) in the result, while the string that came out from the Adobe socket object has "hickups", with blocks of characters missing.
Calls using Adobe socket with the utf8 setting results in different lengths due to chunks of the result missing. In the IöIöIöIöIö...-sequence this can be seen when the same letter comes twice in a row.
The intervals where the error occurs seems to be evenly distributed, with an offset of 683 for the occurrance of "öö", but its not always the same from time to time.
Sample result from out test script:
Double character öö at position :1756 (+1756) Double character öö at position :2439 (+683) Double character öö at position :3122 (+683) Double character öö at position :3805 (+683) Double character öö at position :4488 (+683) Double character öö at position :5171 (+683) Double character öö at position :5854 (+683) Double character öö at position :6537 (+683) Double character öö at position :7220 (+683) Double character öö at position :7903 (+683)
If someone else would like to replicate the errors, feel free to use our test code: