0

Possible Duplicate:
JSON: why are forward slashes escaped?

The function argument below is a string run through json_encode(). I see that the forward slash in http:// is escaped to http:\/\/. Obviously it is a special character when used like this <some_tag></some_tag> but only when used in that structure.

There is no immediate problem..but I need to understand escapes to make some code updates.

<script type='text/javascript'>Arc.ViewHBookmark('[{"id":"1","0":"1","title":"cybercoders","1":"cybercoders","url":"http:\/\/cybercoders.com","2":"http:

php.net - json_encode

Related

JSON: why are forward slashes escaped?

Community
  • 1
  • 1

1 Answers1

4

It is just as a safety net for the </endtag> structure for JSON embedded in <script> elements in HTML documents.

It has no other significance.

Quentin
  • 914,110
  • 126
  • 1,211
  • 1,335
  • In JSON `"\/"` means the same as `"/"`. The escape sequence doesn't depend on being near any other characters. The escape character isn't ignored, it escapes the character that follows it, the sequence just doesn't have any special meaning. – Quentin Feb 20 '12 at 16:10
  • ...the only characters that need to be escaped in an encoding mechanism are the special characters used in the encoding mechanism structure itself( for JSON that would be ", {,},[,], etc.)...all other characters are payload and should be treated as such... –  Jun 01 '12 at 21:02
  • @HiroProtagonist — The developers of PHP's `json_encode` function disagree. – Quentin Jun 01 '12 at 21:15
  • The developers of PHP thought for a _very long time_ that having `magic_quotes` is a good thing; they apparently still do, in the narrower context of `json_encode`, because that's exactly what this is: magic quotes. – lanzz Dec 03 '12 at 09:24
  • 1
    @lanzz — There is a huge difference between adding an escape that never changes the meaning of the data (in the context of JSON) and adding an escape without any regard for what will be done with the data. – Quentin Dec 03 '12 at 09:26
  • @Quentin The only difference is that since it is non-destructive (in contrast with `magic_quotes`), this unjustifiedly overzealous behavior is probably going to linger for _years_ before PHP devs finally agree this is not the correct place to enforce slash escaping, and reverse the default. – lanzz Dec 03 '12 at 09:34
  • It's perfectly justifiable. You put data in, you get JSON out and you get a bonus defence against XSS. – Quentin Dec 03 '12 at 09:36
  • This reasoning would favor `\u####`-escaping every single character in the string — it would still be valid JSON, and will likely be able to survive in more contexts than just the `` context the slash-escaping protects against. The broken behavior is enforcing context semantics in a place where you have no way to know if that context is actually going to apply — this is _exactly_ what magic quotes were doing. It does not matter that one was destructive and the other does not change the semantics — it is wrong because it is doing an unneeded transformation. – lanzz Dec 03 '12 at 09:40
  • `` is a *very* common context. – Quentin Dec 03 '12 at 09:41
  • Yes, and so is dumping unescaped strings in database queries, but magic quotes still kicked the bucket in the end. It does not matter if it is common: escaping for it should be done _only_ when needed, even if it is "harmless" to just always do it — just as bare slash might be an issue in a ` – lanzz Dec 03 '12 at 09:47