> Hi,

> Comments inline...

> On Wednesday, October 31, 2012 8:18:35 AM UTC+2, Antonio Salazar Cardozo
> wrote:

>> Whoopsies, reading too quickly there. Looks like some characters are
>> valid JSON but not valid JavaScript (U+202[89], for example).

>> So the question is, do we:
>> (1) make the user do their own escaping

> I believe the following should work at the moment:

> json transform {
>   case JString(s) => JString(myOwnEscapeFunc(s))
> }

> (2) bake it in so u+202[89] are always escaped by lift-json

> I don't think there should be any Javascript specific behaviour bolted in.
> JSON is often
> used as a transport format in machine-to-machine REST APIs too. There
> Javascript is not relevant.

>> (3) insert some sort of toggle that allows us to enable this escaping, so
>> that it is disabled by default when lift-json is just dealing in plain JSON.

> This is something we can consider. Solution (1) comes with a performance
> hit because
> JSON AST is walked and each String is processed twice. More performance
> optimal
> solution would be to do custom escaping at 'quote' function:

>   private[json] def quote(s: String): String = {
>     val buf = new StringBuilder
>     for (i <- 0 until s.length) {
>       val c = s.charAt(i)
>       buf.append(c match {
>          ....
>         case c if ((c >= '\u0000' && c < '\u0020')) => "\\u%04x".format(c:
> Int)
>         case c => c
>       })
>     }
>     buf.toString
>   }

> We could add a new case expression which would consult implicitly passed
> 'format' to check
> if given character should be escaped:

>    case c if format.shouldEscape(c) => "\\u%04x".format(c: Int)

> If this change feels useful it can be scheduled to Lift 3.0. After all, it
> requires a small API change:

>   def render(value: JValue): Document
>   ->
>   def render(value: JValue)(implicit format: Formats): Document

> Cheers Joni

> Thoughts?
>> Thanks,
>> Antonio

>> On Wednesday, October 31, 2012 12:55:45 AM UTC-4, Matt Feury wrote:

>>> Howdy Hi Hello,

>>> We ran into an interesting issue on our servers tonight, involving the
>>> dreaded u\2028 character. After some research, I learned something new: There
>>> are some characters that are valid javascript but not valid json, including
>>> U+2028 <http://timelessrepo.com/json-isnt-a-javascript-subset>.

>>> Essentially, someone inserted some data to our db with one of these
>>> characters, and once we send this down as json (a JObject), the client
>>> throws an 'Unexpected Token ILLEGAL' error. As the above link describes,
>>> this is character is not valid json.

>>> Now, I could easily escape these characters on my end, but I wonder if
>>> it isn't a better idea to have lift-json handle this case. It would avoid a
>>> lot of potential complications, methinks. Antonio recommended a potential
>>> solution being to have a toggle on the implicit formats value, but I would
>>> go so far as to say, since 'lift-json' handles json, it should *always*
>>> escape these characters since they are invalid json.

>>> Thoughts?

>>> Matt