Question

I need it because I recently made an app that saves an object containing all the user-generated data to localStorage, and encodes/decodes it with JSON.

The bizarre thing is that for some reason, Internet Explorer has poor, if not zero, support for JSON (“JSON is not defined”), and I’m not up to trying to re-create the entire function.

stringify:function(x){
    y='{'
    for(i in x){
        reg=RegExp('\'','g')
        y+=',\''+i.replace(reg,'\\\'')+'\':\''+x[i].replace(reg,'\\\'')+'\''
    }
    y=y.replace(',','')
    y+='}'
    return y
}

This was my first attempt, but I had forgotten that the object has other objects inside it, which themselves contain objects, and kept getting an error which basically stemmed from trying to call the method String.prototype.replace() of an Object.

Since I was kinda OCD with my code at the time, I actually do have the structure of the object saved in the source code:

/*
Link Engine.data: Object: { 
    X: Object: {    [Each is a Paradigm, contains links]
        link.0:{
            link:[link],
            title:[title],
            removed:[true/false],
            starred:[true/false]
        },
        ...
    },
    LSPAR: [Reserved] Object: { [Paradigm list and pointer contained here]
        key:[key], (this controls X)
        list:{
            [listitem]:[listitem],
            ...
        }
    },
    #CONFIG: [Reserved] Object: { [contains miscellaneous Config data]
        property:boolean/number/string,
        ...
    }
*/

That’s the basic data structure, ... represents a repeating pattern.

---

Edit 2019

This whole question is an abomination, but I want to at least attempt to fix the bothersome documentation I wrote for my poorly-designed data structure so that it’s more coherent:

Link {
    string  link
    string  title
    boolean removed
    boolean starred
}

Config {
    ...

    /* Just has a bunch of arbitrary fields; not important */
}

WArray {
    string... [paradigm-name]

    /* Wasteful Array; an object of the form
     * { "a":"a", "b":"b", ... }
     */
}

Paradigm { /* analogous to above "X: Object: {..." nonsense */
    Link... [paradigm-name].[id]

    /* each key is of the form [paradigm-name].[id] and stores a Link
     * e.g. the first link in the "Example" paradigm would
     * be identified by the key "Example.0"
     */
}

ParadigmList {
    string key  /* name of selected paradigm */
    WArray list /* list of paradigm names */
}

LinkEngineData {
    Paradigm...   [paradigm-name]
    ParadigmList  LSPAR
    Config        #CONFIG /* actual field name */
}

Hopefully now you can sort of parse what’s going on. This syntax:

type... format

is meant to convey that objects of type type appear many times, like an array, except it isn’t an array. As such, the fields don’t have a name that is set-in-stone, hence

format: [descriptor1]text[descriptor2]text...

a format is used in place of an actual field name. This is what happens when you try to create a data structure without knowing what a data structure is. I did use the words “data” and “structure” adjacently in the original question, but it was pure coincidence. I didn’t mean it like “this is the data structure I used”; I meant it like “this is the structure of my data”.

Anyways, here’s how I would design it today:

Link {
    string  url
    string  title
    boolean starred
}

LinkGroup {
    string name
    Link[] links
}

Config {
    ... /* has whatever it needs to have */
}

Data {
    int         selGroup
    LinkGroup[] groups
    Config      config
}

That is all.

---

If someone has the sourcecode of the actual JSON.stringify function, or knows a way to replicate it, then please put your answer.

---

EDIT (2013, probably)

I ended up dropping IE support and completely redesigning the app from the ground up; the new version is hosted here. And it works with IE9 out of the box!

Answer 1

I think this is the best replacement: http://bestiejs.github.com/json3/

It claims to be better than Crockford’s JSON 2 for the following reasons (from their site):

JSON 3…

• Correctly serializes primitive wrapper objects (Issue #28).
• Throws a TypeError when serializing cyclic structures (JSON 2 recurses until the call stack overflows).
• Utilizes feature tests to detect broken or incomplete native JSON implementations (JSON 2 only checks for the presence of the native functions). The tests are only executed once at runtime, so there is no additional performance cost when parsing or serializing values.

In contrast to JSON 2, JSON 3 does not…

• Add toJSON() methods to the Boolean, Number, and String prototypes. These are not part of any standard, and are made redundant by the design of the stringify() implementation.
• Add toJSON() or toISOString() methods to Date.prototype. See the note about date serialization below.