JSON是什么,语法为什么这么严格
JSON(JavaScript Object Notation)是用文本交换数据的格式,由ECMA-404和IETF的RFC 8259规定。名字里虽有JavaScript,但它不依赖某种语言,Python、Java、Go、PHP等几乎所有语言都能用同样方式读写, 因此成了Web接口和配置文件的通用格式。语法小而严格,是为了让不同系统把同一段文本解读成同一份数据。代价是手写时多一个逗号或引号,整份文档就会被拒绝。 本工具把这类拒绝转换成可以定位的位置和常见原因提示。输入内容由浏览器内置的JSON.parse在你的设备上处理,本页脚本不含任何网络请求,粘贴的内容不会被上传或保存。
只有六种值
| 类型 | 示例 | 注意事项 |
|---|---|---|
| 字符串 | "你好", "a\nb" | 只能用双引号。换行、制表符等控制字符必须写成 \n、\t 这样的转义。 |
| 数字 | 30, -1.5, 2e3 | 不允许前导0的08、十六进制0xFF、NaN、Infinity,也不能写成以小数点结尾的1.。 |
| 布尔值 | true, false | 必须小写,True、FALSE都会报错。 |
| null | null | JSON中没有undefined。 |
| 数组 | [1, "a", null] | 最后一个元素后面不能有逗号。 |
| 对象 | 一组键: 值对 | 键必须是双引号字符串,最后一对后面不能有逗号。 |
JSON没有日期类型,通常用ISO 8601字符串(如2025-01-01T00:00:00Z)或数字时间戳表示。它也不能直接放二进制数据,一般先用Base64转成文本。系统之间交换时,RFC 8259要求使用UTF-8。
最常见的八种语法错误
实际遇到的错误大多在下表之内。解析失败时,工具会忽略字符串内容扫描输入,把符合的情形列为“可能的原因”。这只是启发式提示,可能同时列出多条,也可能一条都没有。
| 原因 | 样子 | 解决办法 |
|---|---|---|
| 多余的逗号 | [1,2,]或最后一对后面的逗号 | 删除最后的逗号 |
| 单引号 | 'name' | 改成双引号 |
| 键没有引号 | name: 1 | 给键加上双引号 |
| 注释 | // 说明、/* 说明 */ | 删除(JSON不支持注释) |
| Python或JS的值 | None、True、undefined、NaN | 改成null、true、false,或删掉该键 |
| 漏了逗号 | "a":1 "b":2 | 在两对之间补上逗号 |
| 括号不匹配 | 左右括号的种类或数量不一致 | 沿着缩进找到配对出错的位置 |
| 字符串中的换行 | 在双引号里真的按了回车 | 改成转义的<code>\n</code> |
错误位置是怎么算出来的
浏览器会报告“位置57”这样从0开始的字符序号,较新的引擎直接给出行和列。只有序号时,工具数出它之前的换行数得到行号,再用距最后一个换行的字符数得到列号,并显示该行和指向问题处的插入符(^)。 要注意:解析器报告的是“第一次发现问题的位置”,不一定是你写错的位置。两对之间漏了逗号时,报错会指向下一对的第一个字符,而不是空隙。请同时检查标记位置之前的内容。 不同浏览器的提示文字和位置格式不一样;拿不到位置时,只显示原始信息和可能原因。
美化与压缩怎么选
两者含义完全相同,只差空白。需要人读、人改的配置和日志适合美化;放进请求体、URL、环境变量或Cookie时适合压缩。下表是本页构建时把同一个小对象转成各种形式后测得的UTF-8字节数。
{
"name": "张伟",
"age": 30,
"tags": [
"a",
"b"
],
"address": {
"city": "北京"
}
}| 形式 | 大小(字节) |
|---|---|
| 压缩(一行) | 71 |
| 2个空格缩进 | 110 |
| 4个空格缩进 | 134 |
| 制表符缩进 | 98 |
该例压缩后比2个空格的美化版约小35%。嵌套越深差距越大,但如果服务器使用gzip或Brotli压缩传输,实际传输量的差别会小得多。制表符更小,是因为每层缩进只占1个字节。
三个转换会改变值的例子(已实际运行验证)
JSON经历“文本→值→文本”的过程,所以只是重新排版也可能改变内容。以下结果均在本页构建时实际运行得出。
例1:大整数丢失精度
解析并输出{"id":12345678901234567890}后,id变成12345678901234567000。JavaScript的数字是64位浮点数,能精确表示的整数最大到9007199254740991(2的53次方减1)。 超过15到16位的编号,如社交平台的帖子ID、订单号,应当用字符串传递。输入中出现超出安全范围的整数时,工具会给出警告。
例2:键的顺序、重复键和数字写法
{"b":1,"2":2,"1":3}输出后变成{"1":3,"2":2,"b":1}。JavaScript会先按升序输出"1"、"2"这类整数形式的键,所以此时原有顺序不会保留。 遇到{"a":1,"a":2}这样的重复键,RFC 8259只建议名称应当唯一,并未规定如何处理,浏览器保留最后一个值,得到{"a":2}。 数字也会被规范化:[0.1,1e3,1.0,-0]变成[0.1,1000,1,0],1e3变为1000,1.0变为1,-0变为0。含义不变,但对需要逐字符一致的签名或哈希校验数据,请不要使用重新排版后的结果。
例3:先按键排序,再比较两份JSON
两个系统导出同样的数据却键的顺序不同,肉眼对比很费劲。把两份分别用“按键名排序”加美化转换,再贴进文本对比工具,剩下的就是真正的差异。 数组的顺序有意义,所以保持不变,只会递归排序对象的键。
局限与不适用的情况
- 只支持标准JSON。允许注释和末尾逗号的JSON5、JSONC(很多编辑器的设置文件)会被判为错误,请先删掉注释。
- 每行一个JSON的JSON Lines(NDJSON)日志整体粘贴会报错,请逐行校验。
- 几十MB以上的文件可能让浏览器卡住,大数据请改用命令行工具或编辑器。
- 校验的只是语法。必填键是否存在、值的类型是否正确,需要JSON Schema这类模式校验。
- 虽然不会上传,但在公用电脑或共享屏幕时,仍不建议粘贴密码、令牌和个人信息。
用在哪里
- 接口返回400错误时:先校验请求体排除语法问题,再检查服务器要求的字段。
- 改完配置文件后:保存前点“仅校验”,避免程序因此无法启动。
- 日志里的压缩JSON看不懂时:先美化,再用正则表达式测试器提取需要的部分。
- 查询字符串里带着JSON时:先用URL编码器解码,再粘贴到这里。
常见问题
粘贴的JSON会上传到服务器吗?
不会。解析和转换全部由浏览器中的JavaScript完成,本页脚本不含网络请求,你输入的内容不会被发送或保存。
支持键不带引号或使用单引号的JavaScript对象吗?
不支持。只接受标准JSON,键和字符串都必须用双引号。从控制台复制的对象需要先给键和值加上双引号,工具会在可能的原因中提示引号问题。
格式化后键的顺序变了,为什么?
如果勾选了“按键名排序”,这是预期行为。没勾选却变了,是因为存在"1"、"2"这样的整数形式的键,JavaScript总会把它们按升序放在前面(见例2)。JSON对象的键本来就没有顺序含义,数据意义不变。
数字末尾变成了0怎么办?
JavaScript无法精确表示超过15到16位的整数。这类值不要使用本工具的输出,根本的办法是让数据源改用字符串传递。
单独一个数字或字符串算合法的JSON吗?
按RFC 8259算合法:42和"hello"都是有效的JSON文本。不过一些老系统默认最外层必须是对象或数组,请确认对接方的要求。