Asked  7 Months ago    Answers:  5   Viewed   27 times

I've been using json_encode for a long time, and I've not had any problems so far. Now I'm working with a upload script and I try to return some JSON data after file upload.

I have the following code:

print_r($result); // <-- This is an associative array
echo json_encode($result); // <-- this returns valid JSON

This gives me the following results:

// print_r result
    [logo_url] =>
    [img_id] => 54
    [feedback] => Array
            [message] => File uploaded
            [success] => 1


// Echo result
{"logo_url":"","img_id":"54","feedback":{"message":"File uploaded","success":true}}

Can anyone tell me why json_encode adds slashes?


@Quentin said that something is happening between json_encode and .parseJSON and he's right.

Doing a alert(data.toSource()); gives me the dollowing result:

({response:"{"logo_url":"http:\/\/\/wp-content\/uploads\/gallery\/7f\/3b\/71b9520cfc91a90afbdbbfc9d2b2239b_logo.jpeg","img_id":"62","feedback":{"message":"File uploaded","success":true}}", status:200})

And this is not valid JSON. It also adds the status:200 and I have no idea where this comes from.

Could it be that the Plupload bind does something to my returned data?

This is my js script:

  uploader.bind('FileUploaded', function(up, file, data) {
    $('#' + + " b").html("100%");



Can anyone tell me why json_encode adds slashes?

Forward slash characters can cause issues (when preceded by a < it triggers the SGML rules for "end of script element") when embedded in an HTML script element. They are escaped as a precaution.

Because when I try do use jQuery.parseJSON(response); in my js script, it returns null. So my guess it has something to do with the slashes.

It doesn't. In JSON "/" and "/" are equivalent.

The JSON you list in the question is valid (you can test it with jsonlint). Your problem is likely to do with what happens to it between json_encode and parseJSON.

Wednesday, March 31, 2021
answered 7 Months ago

What a HORRENDOUS debug session.. well there's good news.. I figured it out..

I started looking at it using AJAX and logging it with Firebug... and it turns out json_decode (or eval by the way) cannot handle &quot;, which is what PHPUnit sends back (Come on Sebastian!), so to fix it:

$json = str_replace('&quot;', '"', $json);

Now I thought they were the same.. maybe someone can enlighten me..

Wednesday, March 31, 2021
answered 7 Months ago

No. The Base64 alphabet includes A-Z, a-z, 0-9 and + and /.

You can replace them if you don't care about portability towards other applications.


You can use something like these to use your own symbols instead (replace - and _ by anything you want, as long as it is not in the base64 base alphabet, of course!).

The following example converts the normal base64 to base64url as specified in RFC 4648:

function base64url_encode($s) {
    return str_replace(array('+', '/'), array('-', '_'), base64_encode($s));

function base64url_decode($s) {
    return base64_decode(str_replace(array('-', '_'), array('+', '/'), $s));
Sunday, August 1, 2021
answered 3 Months ago

This appears to be a bug with global TS definitions and "module": "commonjs" in the tsconfig.json.

You can either use global TS definitions and stitch all your output into a single file, or you can use modules and directly import them.

The error here is due to the require returning the module context, and the name of the default being irrelevant - it always becomes default...

declare var thing: ThingStatic;
export thing; // Explicit export for thing
export default thing; // Default export for thing

Now require will return this context, so with commonjs modules:

import module from 'thing';
var thing = module.default; // From the default export
var alsoThing = module.thing; // From the named export

However, I've found this to be inconsistent, so switched to es6 modules:

import thing from './thing'; // Import default
import { thing } from './thing'; // Import named
const thing = (await import('path/to/thing.js')).default; // Import dynamic 
Friday, August 6, 2021
Russ Wheeler
answered 3 Months ago

Debugging suggestion:

Check the output of json_last_error(). It should give you an exact reason why it doesn't work. Available from PHP 5.3.0 only, though.

The reason:

JSONP is not identical with JSON. It contains extra data that breaks json_decode().


Remove the extra brackets using substr($AVDecode, 1, strlen($AVDecode)-2)

Friday, October 22, 2021
answered 3 Days ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :