JSON 格式化 / 压缩 / 校验JSON 转义 / 去转义JSON 对比JSON 键排序JSON 转字符串 / 字符串转 JSONJSON 转 XMLXML 转 JSONJSON 数组转 CSVCSV 转 JSON 数组JSON 与 YAML 互转JSON 生成代码定义查询参数与 JSON 互转Cookie 与 JSON 互转JSON 与 Properties 互转
JSON 转字符串 / 字符串转 JSON
处理双重转义的字符串与 JSON 互转
JSON 转字符串:层数怎么数,以及数据为什么会变成字符串
这个工具解决的是哪一类问题
正常情况下一段 JSON 解析出来是对象,字段可以直接访问。但现实中经常遇到解析出来是字符串的情况——数据的形状不对,字段访问全都失败。这类问题的根源是:这段 JSON 在到达你手上之前,已经被序列化成字符串过一次。
工具的输入是一个字符串字面量,输出是它内部真正承载的数据字面量;反向则是把一段数据字面量包成字符串字面量。判断当前数据属于哪一种,是排查的第一步。
怎么判断手上的是几层
看两端有没有引号,以及引号内部的反斜杠数量:
| 你看到的 | 它是什么 | 处理 |
|---|---|---|
{"a":1} | 数据本身(0 层) | 直接用 |
"{\"a\":1}" | 字符串,内含一段 JSON(1 层) | 解一次 |
"\"{\\\"a\\\":1}\"" | 字符串,内含一个字符串,内含 JSON(2 层) | 解两次 |
规则:最外层如果是双引号起头,就必须先剥一层。剥掉之后如果结果还是以双引号起头,就再剥一层。每多一层,反斜杠的数量大致翻倍——这是最直观的线索。
这类数据通常从哪里来
- 日志。把结构化对象写进日志行时会被整体序列化,于是日志里的 payload 永远是字符串形态。
- 数据库的文本列。字段类型是
TEXT/VARCHAR时,ORM 或驱动可能只做了一次字符串化,读出来是字符串而不是对象。 - 环境变量与配置。环境变量只能存字符串,所以 JSON 配置必须被序列化后放进去(
.env、Kubernetes ConfigMap、CI 的 secrets)。 - 消息队列与 Webhook。消息体本身是字符串;如果生产者把一个对象字段预先序列化过,消费端就会拿到嵌套字符串。
- HTTP 表单或查询参数。它们只能承载字符串,复杂结构必须序列化后传输。
三个容易反复踩的坑
- 反复解析,越解越坏。解一次失败不代表该再解一次。正确做法是先判断层级再动手:解一次看结果是对象还是仍是字符串。如果是对象就已经正确了,继续解会把对象再转成字符串形式,反而更歪。
- 反序列化后类型全变。JSON 只有六种类型(对象、数组、字符串、数字、布尔、null)。原本是
Date、BigInt、Map的值,序列化后都会退化成字符串或数字,反序列化不会把它们变回来。时间字段会变成字符串,大整数会丢精度——这是必须在上层做转换的。 - 用单引号包裹的"JSON"。JSON 字符串只能用双引号做定界符。单引号形式是 JavaScript 对象字面量或 Python 字典的写法,不是 JSON。工具会明确拒绝单引号输入并指出位置。
和"转义"工具的区别
转义工具处理的是字符串内部的特殊字符(引号、反斜杠、换行),关注的是"这一段文本能不能安全地放进 JSON 里"。本工具处理的是整个文档的层数,关注的是"这段数据到底被序列化了几次"。排查时先用本工具确定层数,再在需要时用转义工具处理文本内容。
工具怎么用
把内容粘进输入框,选择方向即可:JSON 转字符串会输出可直接嵌入代码或配置的单行字符串字面量;字符串转 JSON 会剥掉外层定界符并还原内部的反斜杠序列。输入非法时会报出具体原因(单引号、未闭合、非法转义等)和位置,而不会给出一段看似成功的错误输出。
常见问题
双重转义是什么?
把一段 JSON 当成字符串再序列化一次,引号前会多一层反斜杠,例如 "{\"a\":1}"。本工具能一层层剥开直到拿到真正的对象。
JSON → 字符串会做什么?
它先解析输入再重新序列化成紧凑单行,相当于做一次规范化;如果输入本身是字符串,则再转义一层。