I have seen people write code like (mix javascript and some templating):
<script>
var prefs = <%= user_prefs.to_spec_conforming_json() %>;
...
Most people that write json encoders are aware of the problem, but why publish a a spec that can potentially create serious security problems?
(Meta: Why have any conversation on an HN back-channel when there are comments open at the source?)
The original json.js file from json.org had this copyright and license:
Copyright (c) 2005 JSON.org
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The Software shall be used for Good, not Evil.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
This was a standard MIT license with one change:
"This license uses the Expat [MIT] license as a base, but adds a clause mandating: “The Software shall be used for Good, not Evil.” This is a restriction on usage and thus conflicts with freedom 0. The restriction might be unenforcible [sic], but we cannot presume that. Thus, the license is nonfree."
http://www.gnu.org/licenses/license-list.html#JSON
However, the current versions of json.js and json2.js on GitHub contain only this public domain dedication and disclaimer:
Public Domain.
NO WARRANTY EXPRESSED OR IMPLIED. USE AT YOUR OWN RISK.
So it's no longer an issue. You can feel free to use json2.js for good or evil.
For context, after Mr. Crockford gave IBM permission to use the license without the clause a few open source projects (mine included), also asked, and Mr. Crockford's response was a bit over the top-
> I released to free use for all with the only condition that it not be used for evil. If that is unacceptable to you, then you may not use it. Your options are to bend to the pro-evil fanatics, or to find a more reasonable hosting solution.
It's nice to see he's become a bit more reasonable.
The NSA breathes a sigh of relief.
That left serialization to a string as the only way to transfer dates. But since there's no specification for the format to use, cross-browser date parsing is a mess (see http://dygraphs.com/date-formats.html ). JSON + dates = sadness.
The non-executing constraint on JSON was a good idea in its early days, when eval was the most common way to parse JSON, but now that there are dedicated parsers for all environments, it's not as much a priority. But we're still stuck with kludgy workarounds for the lack of native date support in JSON.
If there's still concern about using the Date constructor, the spec could require that the date be prefixed to avoid execution: "0 || new Date(...)". Real parsers would extract the date correctly, eval would just return 0.
Wrong! Since ECMAScript 5 there is a single, standard format that all browsers will try to parse first and can predictably output: ISO 8601.
--
[02:49:29.621] (new Date()).toISOString()
[02:49:29.623] "2013-10-12T01:49:29.623Z"
--
[02:49:40.233] JSON.stringify(new Date())
[02:49:40.245] ""2013-10-12T01:49:40.246Z""In any case, my general point still stands: dates are the only "data" type (i.e. not a function, regex, etc.) which is not supported by JSON. So even if there were a usable universal serialization format, you'd still need to post-process the results of the JSON parser to convert the strings into dates.
I swear the moment I glanced at the title I thought it was an error message that someone accidentally posted.
B) Somebody's gotta write those serialization libraries, and they probably do a fair amount of string manipulation to do so.
C) You can't .join data streams without buffering, which defeats the purpose.
D) Adding commas on a preceding line every time you add a new item to a list can pollute diffs.
E) Trailing commas are syntactically correct in ECMAScript 6, and supported by a fair few other languages.
ObjectLiteral :
{ }
{ PropertyNameAndValueList }
ObjectLiteral :
{ }
{ PropertyNameAndValueList }
{ PropertyNameAndValueList , }
For instance, there's a standard for measuring computer equipment in controlled rooms: http://www.ecma-international.org/publications/files/ECMA-ST...
And here's an important one, DVD-RAM discs: http://www.ecma-international.org/publications/files/ECMA-ST... and their cases: http://www.ecma-international.org/publications/files/ECMA-ST...
Plus, NFC: http://www.ecma-international.org/publications/files/ECMA-ST...
It's all new to me!
eww, UTF-16 surrogate pairs. Die, die, die, you scourge. (Yes, I've been working with the win32 api lately, which was designed for UCS2/UTF-16).
when has 16 bit anything been a good idea, really. TCP port ranges, looking at you too.
You don't have to escape unicode. If you want to just use Unicode and encode as UTF-8 then go nuts.
This is valid JSON:
{ "äöü": "大家好", "clef": "𝄞" }
Python has an upper case \UXXXXXXXX literal that seems a lot cleaner.
Is it too late for edn? https://github.com/edn-format/edn
Symbols that aren't "strings" are kinda neat too, and you get downright attached to arbitrary key-value mappings once you have them.
Considering that DPI devices are already sold to parse json-desribed protocols dynamically, I think you are a bit uninformed about my statement. It is not hypothetical.
I accept "The Software shall be used for Good, not Evil." is amusing and "good" but must cause difficulties for people wanting to package with other software under standard licenses.