3 Replies Latest reply on Oct 9, 2013 4:44 AM by Andreas Jansson

    External JSON errors


      When the json is checked in the browser or downloaded, it works as expected, however when brought in through Extendscript, some lines will have random characters inserted, ending a line when there are errors; this happens before the json is parsed.


      This error doesn't randomly appear across all files, only and consistantly in the files that have the error. It's a very low percentage around 3 or 4 out fo 50.


      Here's an example of what I get in extendscript:


      "background": {

          "path": "Mac_Desi


      g   "img": "Massey Fergusson_tractor.tif",

          "bounds": [-0.25, 0, 10.75, 8.25]



      when what I should be getting is this:


      "header": {

          "path": "Mac_Design/1_Production Files/Headers/OW/_Slim/",

          "img": "Marsh_Bros_Slim.tif",

          "bounds": [0.2, 0, 0.95, 8.25]



      Has anyone else has something like this happen? We can't find anything wrong with the json, so I'm wondering if this is just a random bug in extendscript.

        • 1. Re: External JSON errors
          Andreas Jansson Level 2

          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.


          Best regards,

          Andreas J.


          (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.

          1 person found this helpful
          • 2. Re: External JSON errors
            fat_cobra Level 1

            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?

            • 3. Re: External JSON errors
              Andreas Jansson Level 2

              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)))

              End Function



              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: