Sometimes I miss the 90s. It was an amazing time, with exciting things happening in the tech world every day. It seemed like there were continual significant advances in computer hardware and software. Great languages came of age in the 90's, like Perl, Python and Ruby. Even Javascript was born in the 90's. And of course, the 90's saw the birth of The Web. The internet went from a tool for email, telnet and gopher to a host for the Web pages and an enabler for astounding changes in the way we find and share information, conduct business, and communicate with friends and strangers around the world.
Nevertheless, it's important to remain humble about humanity's accomplishments. Thus I feel obligated to point out that it was also a time when, if I may presume to paraphrase Douglas Adams, we were so amazingly primitive that we still thought XML was a pretty neat idea.
I have always been a fan of human readable data. It's great when you're developing or debugging things, or if you need try to figure out how to make sense of data for which you have no schema (something old, something borrowed, &etc). Back before we all had lists of contacts on our phones, we used to keep track of things on our desktops. I spent some time creating a nice gui app for this purpose, and one of the design decisions was how to store things. I don't have so many friends that I needed a whole database to deal with it, so I just used a text file. Now, I considered using XML, and actually tried it for a while but found that it was a real pain. Either my hand-created xml tests files or the xml parser I was using seemed to be a bit buggy (I won't speculate on which was at fault :-). In any case, before long I resorted to a simple tab separated list.That suited my needs just fine, but it left me with a bad taste for XML.
XML is a fine idea in theory. It's (theoretically) human readable and it can express a lot of structure, akin to the kind of structure that can be expressed by a tree or a browser's DOM. It's well defined but it's very particular and precise (picky, if you will). And while it's technically human readable, it's not human friendly. Everything needs a tag and a matching close tag (which really brings nothing to the party except a potential for error). Typically a schema is needed to make sense of it. It tends to look very cluttered, with a lot of overhead for tags:
<person>
<name>
<first>Sherlock</first>
<last>Holmes</last>
</name>
<phone>02123456789</phone>
<address>
<street>221B Baker Street</street>
<city>London</city>
<country>England</country>
</address>
<living>false</living>
</person>
One can certainly read this simple example and pick out the information it contains, but it's not very clear. In fact, out of about 200 non-whitespace characters, about two thirds of them are open and closing tags. It's inefficient, and it's ugly. Fortunately technology continued it's inevitable march, and early in the new millenium a new human readable format was born, descended from our own favorite language, Javascript.
One of the good parts of Javascript is it's object notation. It's powerful, flexible and simple. Just after the turn of the millenium, Douglas Crockford realized its potential as a data format. While he wasn't the first to use Javascript's Object Notation as a format for transmitting data on the web, he was the first to codify it, give it a name and describe it on his simple but useful website, JSON.org. (The Logo he created is pretty cool too.) This JSON snippet represents the same data and structure as the XML example above:
{
"person": {
"name": {
"first": "Sherlock",
"last": "Holmes"
},
"phone": 02123456789,
"address": {
"street": "221B Baker Street",
"city": "London",
"country": England"
},
"living": false
}
}
Again ignoring whitespace, the total number of characters is reduced by about 25%. More importantly, though, is that it is far easier to read. On the other hand, like XML, it is also easy to parse automatically (actually easier). There only seven different types of values recognized by JSON; 4 data types, Object, Array, String, Number, and 3 keywords, true, false and null. Keys must be strings and strings must be in double quotes ({foo:'bar'} is not accepted, it must be {"foo":"bar"}). More details can be found at JSON.org, but there are surprisingly few details needed to completely describe it.
While JSON seems a natural choice for Javascript programs, it really doesn't depend on Javascript at all and is well suited as a language independent format. In fact, most languages now have JSON parsers ready to use, making JSON input and output as easy as reading and writing a text file. Also, it is important to remember that while JSON can be 'eval'ed directly, using eval() for that purpose is not recommended, for security reasons if nothing else. Much better is to use JSON.parse(). But of course, you're probably using "use strict"; anyway so you're aware of these issues already, right? I thought so.
图标图像:
