TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Json ⊄ js

216 点作者 rpsubhub超过 12 年前

16 条评论

fdr超过 12 年前
Perhaps more pervasive and despairingly problematic is number representation. JSON only, per specification, supports arbitrary precision numeric representation. However, Javascript is -- also per specification (as I understand it) -- entirely floating point. That makes working with money in Javascript somewhat hazardous. While there are various arbitrary precision libraries out there for Javascript to assuage this, the problem is most JSON-parsing routines will always force one through a floating point conversion anyway, so a loss of precision is more or less inevitable.<p>While swiftly coercing raw off-the-wire number representations to one's arbitrary precision library of choice can avoid most cases of noticeable accumulated error, it is irksome that the only way everyone seems to get by is by cross their fingers that any loss in precision caused by "JSON.parse" is meaningless to their application.<p>Or, the problem can be soundly avoided by using strings in the JSON payload, which is lame but effective and probably one's best practical choice. It is clearly an example of corruption spreading from Javascript to an otherwise reasonable feature of the data representation format JSON.
评论 #4976363 未加载
评论 #4975843 未加载
评论 #4975921 未加载
评论 #4976069 未加载
评论 #4976421 未加载
Rauchg超过 12 年前
Magnus Holm did a great job describing this after he fixed the problem in Rack::JSONP. Good reference as well for those interested in the topic:<p><a href="http://timelessrepo.com/json-isnt-a-javascript-subset" rel="nofollow">http://timelessrepo.com/json-isnt-a-javascript-subset</a>
评论 #4975822 未加载
lucian1900超过 12 年前
Petty much all web technologies appear to be made of twine and duck tape. It's so sad that this is in many cases the best we have.
评论 #4976012 未加载
评论 #4979830 未加载
评论 #4975842 未加载
评论 #4975833 未加载
xmas_project超过 12 年前
The "uniname" command in the uniutils package (apt-get install uniutils) is great for checking "invisible" or weird Unicode characters. `echo '{"str": "own
ed"}' | uniname` will show the LINE SEPARATOR (\u002028) hidden in the string.
rpearl超过 12 年前
I have to comment on this line:<p>&#62; Some libraries implement an unsafe, but fast, JSON parse using “eval” for older browsers<p>eval is not fast! In fact it is the opposite of fast. Most JIT optimizations go away in the face of eval()! Do not use it even if you <i>know</i> it's safe. Use JSON.parse instead.
评论 #4977936 未加载
javajosh超过 12 年前
This is a good catch, but the presentation is awfully passive aggressive. Yes, if JSON wants to strictly be a subset of JS, then those two characters need to be treated specially - either excluded from JSON, or specially escaped in JSON libraries. The simplest solution, clearly, is to exclude them from JSON. (You can still use those characters, but you have to escape them). There's no compelling reason not to do this - and I doubt that this will cause a problem anyway.
评论 #4976797 未加载
JulianMorrison超过 12 年前
The other reason: if you are using a Turing-complete language to eval your nominally context free grammar as if it were code, you are an idiot who is asking to be hacked, whether through quirks like this or otherwise. (This also goes for PHP and ERB.) <a href="http://www.cs.dartmouth.edu/~sergey/langsec/occupy/" rel="nofollow">http://www.cs.dartmouth.edu/~sergey/langsec/occupy/</a>
评论 #4975896 未加载
sil3ntmac超过 12 年前
I often pass inline data from server -&#62; client JS using a meta tag. In rails3 it would look like:<p>&#60;meta name='blah' content="&#60;%= @data.to_json %&#62;" /&#62;<p>However this has always seemed unclean to me. Does anyone else have a better, alternative method of inlining data? I'd rather not use inline scripts for the exact reason they mention.
评论 #4976588 未加载
评论 #4975916 未加载
评论 #4976105 未加载
评论 #4977019 未加载
powrtoch超过 12 年前
I feel really dense, but I don't understand why the example line is throwing an error. The article mentions line terminators, but it doesn't seem to contain any, and I also don't understand why "owned" would be escaped the way the author says... it looks as though the interpreter is just rejecting the use of quotes around the key. But I'm sure I'm just missing something, so I'd be much obliged if someone could enlighten me.
评论 #4976112 未加载
评论 #4976108 未加载
andrewcooke超过 12 年前
anyone else see the strangest mess on view source for that page? (chrome on ubuntu)<p>[edit: i guess it's confused by the line break characters. i reported an issue.]<p>[edit2: whoa, wget seems to show the same thing when i look at the source in emacs...]<p>[edit3: ok, i am an idiot. it's just quotes in a bunch of meta tags. sorry. move along. nothing to see here.]
评论 #4975805 未加载
beatgammit超过 12 年前
One more thing that really bugs me about JSON is that it doesn't support Infinity, -Infinity and NaN. Python's JSON library does, which leads to some interesting breakages.<p>Sure, for NaN you can use null, but for Infinity, you have to use really large/small numbers, which can also lead to other problems.
评论 #4975770 未加载
评论 #4975856 未加载
lacker超过 12 年前
Another problem is unicode characters that are not in the basic multilingual plane. JSON supports those, but many Javascript environments (like basically all browsers) do not.
Xion超过 12 年前
The other thing is that JSON scoffs at trailing comma (both in object and array literals), while JavaScript engines are perfectly happy to accept them.
评论 #4977145 未加载
ot超过 12 年前
Previous discussion: <a href="http://news.ycombinator.com/item?id=2550145" rel="nofollow">http://news.ycombinator.com/item?id=2550145</a>
michaelmcmillan超过 12 年前
Judofyr has covered this in depth on his blog: <a href="http://timelessrepo.com/json-isnt-a-javascript-subset" rel="nofollow">http://timelessrepo.com/json-isnt-a-javascript-subset</a>
Toshio超过 12 年前
YAML is the new JSON dontcha know.
评论 #4981559 未加载