The reason for this "escapes" me.
JSON escapes the forward slash, so a hash {a: "a/b/c"}
is serialized as {"a":"a\/b\/c"}
instead of {"a":"a/b/c"}
.
Why?
The reason for this "escapes" me.
JSON escapes the forward slash, so a hash {a: "a/b/c"}
is serialized as {"a":"a\/b\/c"}
instead of {"a":"a/b/c"}
.
Why?
PHP escapes forward slashes by default which is probably why this appears so commonly. I'm not sure why, but possibly because embedding the string
"</script>"
inside a<script>
tag is considered unsafe.This functionality can be disabled by passing in the
JSON_UNESCAPED_SLASHES
flag but most developers will not use this since the original result is already valid JSON.Since JSON is by definition javascript, and in javascript by definition a single backslash cannot be present in a string without being a part of a special encoded symbol (like newline), then it's perfectly logical to add an additional special encoded symbol for a forward slash, because this eases the task of preventing XSS attacks SO MUCH that you might even thank that genious man who managed to pull it off with including this (seemingly) controversal hack into the JSON specification. They could as well add the same special symbols for angle brackets, but there appears no need to do so because with the forward slash neutralized it's no more hostile and they can throw as many angle brackets at the code as they like - it simply won't allow any crazy-ass XSS to succeed.
The JSON spec says you CAN escape forward slash, but you don't have to.
Ugly PHP!
The
JSON_UNESCAPED_UNICODE|JSON_UNESCAPED_SLASHES
must be default, not an (strange) option... How to say it to php-developers?The default MUST be the most frequent use, and the (current) most widely used standards as UTF8. How many PHP-code fragments in the Github or other place need this exoctic "embedded in HTML" feature?
JSON doesn't require you to do that, it allows you to do that. It also allows you to use "\u0061" for "A", but it's not required. Allowing
\/
helps when embedding JSON in a<script>
tag, which doesn't allow</
inside strings, like Seb points out.Some of Microsoft's ASP.NET Ajax/JSON API's use this loophole to add extra information, e.g., a datetime will be sent as
"\/Date(milliseconds)\/"
. (Yuck)I asked the same question some time ago and had to answer it myself. Here's what I came up with: