编程与软件工程seriot.ch编辑精选
解析 JSON 是个雷区
Parsing JSON is a Minefield
2016 — 2019，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇文章是 Nicolas Seriot 对多种 JSON 解析器做的横向测试：用大量边界用例、非法或恶意载荷以及可选扩展，揭示不同实现在顶层标量、数字、编码和容错等方面行为不一致，甚至崩溃。它说明 JSON 规范中不少细节宽松或未定义，因此不能盲目信任解析器，而要妥善处理错误。
为什么经久不衰：它用可复现的测试把“看似简单”的 JSON 解析变成可验证的兼容性与安全问题，多年后仍是选库、写测试和处理不可信输入时的重要提醒。
HN 评论精选
解析不可信 JSON 必须当作可能崩溃的安全边界来处理，不能静默失败。
不要自己写 JSON 解析器；要假定解析会崩溃，捕获错误并让应用优雅失败。他以 PHP 为例：会话已打开、用户名已设置，随后 json_decode 解析失败导致脚本崩溃，会话仍有效，攻击者可冒充他人登录。结论是不要自己解析 JSON，也不要让解析调用静默失败。
s_q_b查看英文原文
Well, first and most obviously, if you are thinking of rolling your own JSON parser, stop and seek medical attention. Secondly, assume that parsing your input will crash, so catch the error and have your application fail gracefully. This is the number one security issue I encounter in "security audited" PHP. (The second being the "==" vs. "===" debacle that is PHP comparison.) As one example, consider what happens when the code opens a session, sets the session username, then parses some input JSON before the password is evaluated. Crashing the script at the json_decode() fails with the session open, so the attacker can log in as anyone. Third, parsing everything is a minefield, including HTML. We as a community invest a lot of collective effort in improving those parsers, but this article does serve as a useful reminder of a lot of the infrastructure we take for granted. Takeaways: Don't parse JSON yourself, and don't let calls to the parsing functions fail silently.
作者认为问题多来自边缘实现或误用，正常使用主流库时 JSON 相当可靠。
“总之，JSON 不是一种可以盲目依赖的数据格式。”这绝对不是我从文章里得到的结论。更像是：只有当你使用冷门边界情况或 alpha 阶段解析库时，JSON 才不能盲目依赖。我遇到的 JSON 问题，要么是自己手误，要么是试图序列化本更适合 BSON 的数据。
mi100hael查看英文原文
> In conclusion, JSON is not a data format you can rely on blindly. That was definitely not my take-away from the article. More like "JSON is not a data format you can rely on blindly if you are using an esoteric edge-case and/or an alpha-stage parsing library." I haven't ever run into a single JSON issue that wasn't due to my own fat fingers or trying to serialize data that would have been better suited to something like BSON.
实测表明主流实现仍有兼容性缺口，标准化测试套件很有价值。
这种事偏挑我休息日发出来。我把文章测试跑在我负责维护的一个解析器上，发现只有顶层标量（我们不支持）以及我们不该接受却接受了的用例失败。明天我会检查后者，以及可选的 i_ 测试。测试套件对标准是巨大的增值，感谢 Nicolas 研究和制作它。JSON_checker 有些测试失败让我吃惊，我也用它的测试套件。
SloopJon查看英文原文
Figures that something like this would be posted on my day off. I put this through a parser that I cover, and found that the only failures were for top-level scalars, which we don't support, and for things we accept that we shouldn't. I'll look through the latter tomorrow, as well as the optional "i_" tests. Test suites are a huge value add for a standard, so thank you, Nicolas, for researching and creating this one. I was surprised that JSON_checker failed some of the tests. I use its test suite too.
这不是 JSON 独有的问题，而是所有非平凡序列化格式在实现和规范演化中的通病。
虽然这对 JSON 成立，但对任何非平凡的序列化和/或编码格式也成立。主要教训是：1）实现很重要；2）“简单”的规范从来都不简单。像这样探讨边界情况和实现差异的文档很重要，但你可以把开头段落里的 JSON 换成任何序列化格式、编码标准或 IPC 协议，它依然成立：该格式并不像许多人以为的那样简单理想；没有两个库行为完全相同；边界情况和恶意构造的载荷会导致 bug、崩溃和拒绝服务，主要因为该格式的库依赖的规范随时间演化，留下许多细节宽松或完全未规定。
skywhopper查看英文原文
While this is true of JSON, it's also true of any other non-trivial serialization and/or encoding format. The main lessons to learn here are that: 1) implementation matters 2) "simple" specs never really are It's definitely important to have documents like this one that explore the edge cases and the differences between implementations, but you can replace "JSON" in the introductory paragraph with any other serialization format, encoding standard, or IPC protocol and it would remain true: "<format> is not the easy, idealised format as many do believe. [There are not] two libraries that exhibit the very same behaviour. Moreover, [...] edge cases and maliciously crafted payloads can cause bugs, crashes and denial of services, mainly because <format> libraries rely on specifications that have evolved over time and that left many details loosely specified or not specified at all."
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选