incorrect JSON serialization of ascii low values

[jaysmith2020]

If a string contains ASCII non-printable characters, SmartGWT doesn't serialize properly into JSON. We're using Spring/Jackson to parse on the server, and it chokes on the unencoded values. For example, ASCII value DC3, code value of 19 decimal, 13 hex, is serialized directly into JSON. The correct behavior would be to encode it as \u0013. I've worked around the issue with the code at the bottom, but I suspect there might be performance concerns with older browsers.

It's possible to paste these characters in a Textarea field, but not a text field, at least in chrome. Assuming it's not stripped by the forum software, here is DC3: >>><<<

I'm not sure String.asSource is the most appropriate place to make this change, but it seems to be working so far.

*complete* SmartGWT version:
v8.3p_2013-03-15/LGPL Development Only (built 2013-03-15)

browser:
Chromium Version 25.0.1364.160 Ubuntu 12.04 (25.0.1364.160-0ubuntu0.12.04.1)

Spring log entry:
nested exception is org.codehaus.jackson.JsonParseException: Illegal unquoted character ((CTRL-CHAR, code 19)): has to be escaped using backslash to be included in string value

---

// preserve original function
String._asSource = String.asSource;

isc.addMethods(String, {
    encodeLowChars : function (s) {
      var rv = "";
      for (var i = 0; i < s.length; i++) {
        var c = s.charAt(i);
        var code = c.charCodeAt();
        if (code < 16) {
          rv += "\\u000" + code.toString(16);
        } else if (code < 32) {
          rv += "\\u00" + code.toString(16);
        } else {
          rv += c;
        }
      }
      
      return rv;
    },
      // isomorphic's version doesn't support ascii low characters besides tabs and newlines
      asSource : function (string, singleQuote) {
      return String.encodeLowChars(String._asSource(string, singleQuote));
    }
  });

[Isomorphic]

Thanks for pointing this out. We'll get around to addressing this in the framework in a way that takes best advantage of native support (native JSON object where available, avoiding charAt() iteration where it's not, etc).

In the meantime, we think it's unlikely that your hackaround would have any bad side-effects unless you were serializing a really large JSON structure on IE8 or earlier.