JSON 对于数据交换仍然变得越来越重要，但是 JSON specification在某些方面比较宽松:
The names within an object SHOULD be unique.
An implementation may set limits on the size of texts that it accepts. An implementation may set limits on the maximum depth of nesting. An implementation may set limits on the range of numbers. An implementation may set limits on the length and character contents of strings.
我认为大多数 JSON 解析器都会忽略重复的对象键，并且不会区分负零 (-0) 和零。大多数也可能将数字限制为 32 位 float 或有符号整数。此外，JSON 允许包含不是有效 Unicode 代码点的字符(参见 this question )。我敢打赌，在基本多语言平面(U+0000 到 U+FFFF)之上，Unicode 字符的实现可能会出现问题。但也不是 JSON 规范，像 CouchDB、MongoDB、Persevere/Dojo 等 JSON 数据库也添加了限制:我怀疑你可以使用像 id、_id 这样的对象键，和 $ref 在所有 JSON 存储中，因为它们在每个系统中可能具有特殊含义。
这在某种程度上令人沮丧:JSON 应该很容易，但你看得越仔细，你发现的障碍就越多。是否存在可以在所有 解析器和数据库中安全使用的通用(不太受限制)JSON 子集，或者 NoSQL 运动是否会添加 more and more extensions以及不应在 JSON 文档中使用的特殊结构？
最佳答案
一般不会。
诚然，有很多错误(例如，MongoDB 在大于 64 位未签名 INT 的数字上给出 String Parse Error)。其中一些是错误，而另一些是固有的平台限制 - 与任何其他重要的计算机系统一样。
但我通常不相信定义 JSON 的“安全子集”。虽然你可以获得 JSON schemas ，让全世界的每个人都同意该做什么和不该做什么是不太可能发生的。
从广义上讲，JSON 之所以流行，是因为它没有固有的局限性。 (相对于 ex. ASN.1 或 XML。)
关于database - 是否存在可用于所有 JSON 解析器和数据库的安全 JSON 子集，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3337601/