php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Request #49366 Make slash escaping optional in json_encode()
Submitted: 2009-08-25 23:32 UTC Modified: 2010-09-16 15:53 UTC
Votes:15
Avg. Score:4.2 ± 1.0
Reproduced:14 of 14 (100.0%)
Same Version:12 (85.7%)
Same OS:6 (42.9%)
From: don at smugmug dot com Assigned: aharvey (profile)
Status: Closed Package: JSON related
PHP Version: 5.3.0 OS: CentOS 5.3
Private report: No CVE-ID: None
View Developer Edit
 [2009-08-25 23:32 UTC] don at smugmug dot com 
Description:
------------
When given a string with slashes in it, despite the JSON docs suggesting 
that's legal, json_encode escapes them anyway.  

http://www.json.org/ says "any-Unicode-character-except-"-or-\-or 
control-character"

JSONLint at http://www.jsonlint.com/ also validates slashes that aren't 
escaped as valid.

This adds response weight, and makes further processing much more 
complex.

Reproduce code:
---------------
$vars['url'] = "http://www.example.com/";
echo json_encode($vars);

Expected result:
----------------
{"url":"http://www.example.com/"}

Actual result:
--------------
{"url":"http:\/\/www.example.com\/"}

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2009-08-26 08:50 UTC] jani@php.net 
It's not incorrect to escape slashes. It's also suggested on the RFC to do so. Just look at the chart on http://www.json.org/ for string..

But since it isn't wrong either NOT to escape them, I'll just reclassify this. We can add another option to that optional bitmask "options".
 [2009-10-21 21:14 UTC] jemptymethod at acm dot org 
I concur with the suggested course of action making the escaping of slashes controllable with a flag as I'm experiencing the same issue as the OP albeit on Debian (rather than CentOS)
 [2010-08-08 14:43 UTC] jd2 at dilltree dot com 
Totally agree.  This is needed for anything such as a REST service that wants to 
return JSON with valid urls.
 [2010-09-16 15:53 UTC] aharvey@php.net 
Automatic comment from SVN on behalf of aharvey
Revision: http://svn.php.net/viewvc/?view=revision&revision=303421
Log: Implemented FR #49366 (Make slash escaping optional in json_encode()).
 [2010-09-16 15:53 UTC] aharvey@php.net
-Summary: json_encode incorrectly escapes slashes (/) +Summary: Make slash escaping optional in json_encode() -Status: Open +Status: Closed -Package: Feature/Change Request +Package: JSON related -Assigned To: +Assigned To: aharvey
 [2010-09-16 15:53 UTC] aharvey@php.net 
This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.

I've implemented this on trunk via a json_encode() option called JSON_UNESCAPED_SLASHES. The default behaviour remains to escape slashes.
 [2011-12-15 22:05 UTC] dtremblay dot fafard at gmail dot com 
Actually, I can't find any reason why is escaping slashes by default and create an option to remove this feature.  Usually, when you want something added (e.g. Escaping Slashes), you use an option to recreate the feature wanted. So why is the option used to REMOVE a feature? Options exists to add features, not remove them?? Where am I wrong?
 [2011-12-16 01:37 UTC] don at smugmug dot com 
I totally agree that this should just be the default, rather than some new 
option. 

Both ways are 100% JSON compliant, but one (the PHP chosen method) is far less 
common, has a significantly larger footprint on lots of common types of data, and 
is harder for humans to read.  I see no benefit t
 [2012-03-02 17:26 UTC] diego dot pasc at tiscali dot it 
I also agree that NOT ESCAPING should be the default
 [2012-12-03 09:31 UTC] php dot net at site dot lanzz dot org 
To me, this issue is just magic quotes being still alive and well, in the year 
2012. I thought the lesson of "don't overquote when you don't have to" has been 
learned already? Granted, this issue is marginally better than the magic quotes 
fiasco, as it doesn't actually change the semantics of the escaped value.
 [2017-11-15 07:59 UTC] d at kjdkj dot cpm 
x
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Tue Dec 31 04:01:29 2024 UTC