如何压缩 JSON —— 以及什么时候应该这么做

JSON 在设计上对空白字符宽容。JSON 美化器 把紧凑的、机器生成的字符串展开成带缩进、便于人读的输出。JSON 压缩器 做完全相反的事 —— 把那些空白全部剥除以减小文件体积。两种操作都不会改变数据本身,只改变空白。本指南讲什么时候美化、什么时候压缩,以及如何做这两件事 —— 在 JavaScript、Python、命令行,以及直接在你的浏览器中。

压缩 JSON 到底做了什么

看这个格式化过的 JSON 对象:

{
  "user": {
    "id": 42,
    "name": "Alice",
    "roles": [
      "admin",
      "editor"
    ],
    "active": true
  }
}

压缩之后:

{"user":{"id":42,"name":"Alice","roles":["admin","editor"],"active":true}}

这两个字符串在语义上完全相同。任何 JSON 解析器都把它们当成同样的数据。压缩后的版本 73 个字符;格式化版本 110 个。这是 34% 的缩减 —— 而 JSON 越大、嵌套越深,差距越大。

被移除的: 所有换行、所有缩进空格与制表符,键与值之间 : 前后的空格,以及条目之间 , 之后的空格。

永远不会移除的: 字符串值内部的空白("hello world" 仍是 "hello world"),以及真正的数据:键、值与结构字符。

反向操作:什么是 JSON 美化器?

JSON 美化器 —— 也叫 JSON 格式化器或 JSON pretty-printer —— 与压缩器相反。它把紧凑、不易阅读的 JSON 展开,加上一致的缩进与换行,让结构对人一目了然。

在这个语境中,“beautify”“format”“pretty-print”和“indent”表达的意思完全一样。输出与输入在语义上一致,只有空白不同。

// 压缩(你从 API 或日志里收到的样子)
{"order":{"id":1001,"items":[{"sku":"A1","qty":2},{"sku":"B3","qty":1}],"total":49.99}}

// 美化(2 空格缩进)
{
  "order": {
    "id": 1001,
    "items": [
      { "sku": "A1", "qty": 2 },
      { "sku": "B3", "qty": 1 }
    ],
    "total": 49.99
  }
}

什么时候美化 JSON

最常见的情形与压缩相反:你收到了紧凑的 JSON —— 来自 API 响应、日志文件、数据库导出或同事的消息 —— 而你需要读或编辑它。

• 调试 API 响应 —— 压缩过的响应几乎无法扫读;美化只要一秒,就能让每个键都显眼
• 编辑配置文件 —— 把改动提交到 JSON 配置之前先美化,diff 才看得懂,评审者才能跟上变化
• 记录数据结构 —— README、wiki 或 PR 描述里的格式化 JSON,远比一行文字更能传达结构
• 查看陌生数据 —— 面对新 API 或从没见过的数据集时,先美化能让你立刻看清整体形状
• 修复坏掉的 JSON —— 美化还会顺便校验 JSON;若输出不对或出现错误,说明输入有语法问题

如何用 fixjson 美化 JSON

fixjson 的 JSON 美化器 同时处理合法和损坏的 JSON —— 这是大多数格式化器做不到的。用法如下:

1. 粘贴你的 JSON 到左侧输入面板。它可以是压缩的、部分格式化的,甚至损坏的(尾随逗号、单引号、未加引号的键 —— 都接受)。
2. 输出立刻出现 在右侧,以 2 空格缩进美化好。不需要点按钮 —— 工具会随你输入实时更新。
3. 按需调整缩进。缩进选择器可以在 2 空格、4 空格与制表符之间切换,以符合你项目的风格指南。
4. 复制结果,用输出面板顶栏的复制按钮,或者全选直接粘贴。

如果你的 JSON 有错误,fixjson 会在美化前自动修复 —— 尾随逗号被移除、单引号被换成双引号、缺失的括号被补齐。这意味着你可以直接粘贴 LLM、Python REPL 或日志文件的原始输出,得到干净、格式化的 JSON,无需手动逐个修错。

一切都在你的浏览器中运行。任何数据都不会发送到服务器 —— 当 JSON 含有 API 密钥、用户记录或其他敏感信息时,这点尤其重要。

在代码中美化 JSON

如果你不在浏览器里,而是想以编程方式生成美化输出,JSON.stringify 的第三个参数控制缩进:

// 2 空格缩进
JSON.stringify(data, null, 2);

// 4 空格缩进
JSON.stringify(data, null, 4);

// 制表符缩进
JSON.stringify(data, null, '\t');

在 Python 中:

import json

# 2 空格缩进,键排序
print(json.dumps(data, indent=2, sort_keys=True))

在命令行用 jq(默认输出本身就是美化的):

jq . data.min.json

如何在 JavaScript 中压缩 JSON

JavaScript 内置的 JSON.stringify 在不传第三个参数(spacer)时,就会输出压缩 JSON。

从 JavaScript 对象出发

const data = {
  user: {
    id: 42,
    name: "Alice",
    roles: ["admin", "editor"],
    active: true
  }
};

const minified = JSON.stringify(data);
// {"user":{"id":42,"name":"Alice","roles":["admin","editor"],"active":true}}

不需要任何库。JSON.stringify(value) 总是产出紧凑输出。

从 JSON 字符串出发(先 parse 再 stringify)

如果你手上是一段格式化的 JSON 字符串,想把它压缩:

const formatted = `{
  "user": {
    "id": 42,
    "name": "Alice"
  }
}`;

const minified = JSON.stringify(JSON.parse(formatted));
// {"user":{"id":42,"name":"Alice"}}

这种来回 —— parse 然后不带 spacer 再 stringify —— 是标准做法。它还有一个有用的副作用:JSON.parse 在输入非法时会抛错,所以损坏的 JSON 在你想传输之前就会被发现。

在 Node.js 中,从文件读取

import { readFileSync, writeFileSync } from 'fs';

const input = readFileSync('data.json', 'utf8');
const minified = JSON.stringify(JSON.parse(input));
writeFileSync('data.min.json', minified);

如何在 Python 中压缩 JSON

Python 的 json 模块用 json.dumps 的两个参数就能干净地处理这件事。

从 Python dict 出发

import json

data = {
    "user": {
        "id": 42,
        "name": "Alice",
        "roles": ["admin", "editor"],
        "active": True
    }
}

minified = json.dumps(data, separators=(',', ':'))
# {"user":{"id":42,"name":"Alice","roles":["admin","editor"],"active":true}}

关键是 separators=(',', ':') 参数。默认情况下,json.dumps 使用 ', ' 和 ': '(带尾随空格)。传入 (',', ':') 就能完全去掉那些空格。

从 JSON 文件出发

import json

with open('data.json', 'r') as f:
    data = json.load(f)

with open('data.min.json', 'w') as f:
    json.dump(data, f, separators=(',', ':'))

如何在命令行压缩 JSON

使用 jq

jq 是 Unix 类系统中事实上的 JSON 处理器。-c 选项产出紧凑(压缩)的输出:

jq -c . data.json > data.min.json

# 行内
echo '{ "name": "Alice", "age": 30 }' | jq -c .
# {"name":"Alice","age":30}

用 Python(无需额外安装)

如果没装 jq,Python 几乎总是有的:

python3 -m json.tool --compact data.json > data.min.json

--compact 选项是在 Python 3.9 才加进来的。更老的版本:

python3 -c "import json,sys; print(json.dumps(json.load(sys.stdin), separators=(',',':')))" < data.json

如何在线压缩 JSON

对于一次性任务 —— 提交前的配置文件、要复制到别处的 API 响应 —— 基于浏览器的工具比任何命令行配置都更快。一个好的在线 JSON 压缩器应该接受粘贴或文件上传、在客户端即时压缩,且永不把你的数据发到服务器。

fixjson 的 JSON 压缩器 把一切处理都放在本地。粘贴 JSON,点击 Minify,然后复制结果 —— 没有任何东西离开你的浏览器。

压缩 JSON 到底能省多少?

节省多少取决于原本是怎么格式化的。

• 轻度格式化(2 空格缩进、浅嵌套):典型可省 15–25%
• 重度格式化(4 空格缩进、深嵌套、键多):典型可省 30–50%
• 本已紧凑(已压缩或机器生成):节省接近 0%

现实示例 —— 一个返回 100 个用户对象列表的 REST API 响应:

注意 gzip 那一行。这是本指南中最重要的观察 —— 它直接引出下一个问题。

压缩(minify) vs 压缩(compress):区别是什么?

Minify 去掉空白字符 —— 在数据层面无损,产出更小的文本字符串。Compression(gzip、Brotli、zstd)用算法在整个文件中找出重复的字节模式并更高效地表示它们。它在二进制层面工作,产出的是必须先解压才能读的内容。

实际影响: 当你的服务器启用了 HTTP 压缩 —— 任何 JSON API 都该启用 —— gzip 或 Brotli 对空白的压缩力度与对其他内容一样狠。先 minify 再压缩通常只能在已经有的压缩之上再省下边际的一点(3–8%)。

这就把决策重新框定为:

• 如果你的服务器使用 HTTP 压缩:minify 只是一个次要优化
• 如果你在磁盘或数据库里存 JSON 且没有压缩:minify 能显著降低存储成本
• 如果客户端不支持 HTTP 压缩:minify 更重要

实践中的压缩:HTTP/2、HTTP/3 与该检查什么

现代 HTTP 版本并不改变算账方式 —— 压缩仍发生在响应体层面 —— 但在决定是否 minify 时,有些头值得检查:

• Content-Encoding: gzip(或 br 表示 Brotli,或 zstd 在某些部署中)—— 确认响应体在传输中被压缩了。
• Vary: Accept-Encoding —— 必备,以便 CDN 能分别缓存压缩与未压缩的响应。
• HTTP/2 / HTTP/3 的头部压缩(HPACK / QPACK) —— 压缩的是 请求头,不是响应体。它不能取代针对 JSON 负载的 gzip/brotli。

如果你的 CDN 已经用 br 提供服务,minify 只能再省几个百分点。如果你掌控的某个服务不做压缩(自定义二进制、webhook 目标、IoT 端点),minify 仍然有用。

对大 JSON 用流式处理,而不是 minify

对真正大的负载 —— 几 MB 的 API 响应、日志转储、数据集导出 —— 正确做法往往不是去压缩一整块,而是把它流式传递。两种模式:

• NDJSON / JSON Lines —— 每行一个 JSON 值。客户端可以在每一行到达时就解析与处理,而不必等整个文档。
• 分块流式解析器 —— 像 clarinet / jsonparse 这样的库在数据从线缆上到达时就处理 token,这正是内存受限环境想要的。

什么时候应该 minify JSON

生产 API 响应(未开启 HTTP 压缩)

如果你的 API 服务器没启用 Content-Encoding: gzip 或 Content-Encoding: br,每一个空白字节都要被传输。Minify 能减小负载体积、加快响应,在慢速移动连接上尤为明显。

嵌入 HTML 中的 JSON

嵌在 <script type="application/json"> 标签或直接写在 HTML 中的 JSON 是页面总重量的一部分。Minify 它对降低首屏体积有贡献。

大规模存储的 JSON 文件

如果你在数据仓库、对象存储或数据库里存上百万、上千万条 JSON 记录,且存储层没有压缩 —— 那些空白会累计起来。在 1000 万条记录上节省 30%,效果非常可观。

有大小限制的边角场景

有些系统有硬性大小限制:webhook payload、某些消息队列、cookie 值、URL 参数。如果你的 JSON 已接近限制,minify 可能是最直接的留在限内之路。

构建产物与打包的配置

前端构建产物里捆绑的 JSON 配置文件会增加 bundle 体积。把它们作为构建步骤的一部分 minify —— 就像 JS、CSS 那样 —— 是标准做法。

什么时候大概不必折腾

你的服务器已经在做 HTTP 压缩

检查你的响应头。如果看到 Content-Encoding: gzip 或 Content-Encoding: br,说明你的服务器已经在传输中压缩 JSON 了。在此之上再 minify,顶多再省几个百分点 —— 通常不值得换来额外复杂度。

JSON 是给人看的

开发者编辑的配置文件、调试日志、需要人工审阅的导出数据 —— 这些更需要可读性而不是紧凑。永远不要 minify 人需要经常阅读的 JSON。

数据本身就很小

对于不到 1 KB 的 JSON,minified 与格式化的绝对差距常常不到 300 字节。在这个量级上,HTTP 请求本身的开销才是大头;在体上抠 200 字节,对性能没有可测量的影响。

会让调试变难

日志、错误信息与监控系统里的 minified JSON 难以扫读。如果你要在生产中读 JSON 输出,就保持格式化。

构建流水线中的压缩

一个在 Node.js 构建流水线中压缩 JSON 配置文件的实用方案:

// scripts/minify-configs.js
import { readdirSync, readFileSync, writeFileSync } from 'fs';
import { join } from 'path';

const configDir = './config';
const outputDir = './dist/config';

for (const file of readdirSync(configDir)) {
  if (!file.endsWith('.json')) continue;
  const raw = readFileSync(join(configDir, file), 'utf8');
  const minified = JSON.stringify(JSON.parse(raw));
  writeFileSync(join(outputDir, file), minified);
  const saved = raw.length - minified.length;
  console.log(`${file}: ${raw.length} → ${minified.length} bytes (saved ${saved})`);
}

把它放在部署前的步骤跑。如果有配置文件含非法 JSON,JSON.parse 会抛错,构建会失败 —— 这正是你想要的。

压缩 JSON 时常见的错误

把压缩当混淆

压缩后的 JSON 在任何有意义的层面上都不算被隐藏。任何人都可以几秒钟内把它丢进 格式化器 然后读到全部。不要 minify 敏感数据然后就当万事大吉 —— 用真正的加密,或者干脆不传输敏感数据。

忘了 Python 中的编码选项

json.dumps 默认输出是 ASCII 安全的,会把非 ASCII 字符转义成 \uXXXX。要保留原样的 UTF-8 字符,传 ensure_ascii=False:

minified = json.dumps(data, separators=(',', ':'), ensure_ascii=False)

大整数失精

对带有非常大整数的 JSON 进行解析再字符串化,有些语言会丢失精度。JavaScript 的 JSON.parse 把所有数字转成 IEEE 754 双精度浮点,无法精确表示 2⁵³ 以上的整数。如果你的 JSON 包含大整数(如数据库 ID 或外部服务 ID),请确认 parse-stringify 来回不会破坏它们。

常见问题

我怎么在 JavaScript 里 minify JSON?

调用 JSON.stringify(value) 而不传第三个参数 —— 输出永远是紧凑的。要 minify 已有的字符串,就来回走一遭:JSON.stringify(JSON.parse(formatted))。

minify JSON 真的能省很多体积吗?

压缩前通常是 15–50%,取决于缩进与嵌套。但如果你的服务器已经发送 Content-Encoding: gzip 或 br,gzip 反正会把空白都压掉,先 minify 再压缩只能再多省一点点。

minify JSON 和 compress JSON 有什么区别?

Minify 去掉空白、保留人可读的文本;Compression(gzip、Brotli)重新编码字节,必须解压才能读。两者可以叠加,但在传输中,compression 干了大部分活。

minify 和 format 有什么不同?

两者相反:minify 去掉空白以缩体积,format 加上空白以求可读性。反向操作请见 如何格式化 JSON。

结语

Minify JSON 是最简单的优化之一 —— 在任何语言里就是一次函数调用,在任何浏览器工具里就是一次点击。合适的时机是:在没有 HTTP 压缩的情况下传输 JSON、在没有存储层压缩的情况下大规模存储 JSON,或者把它打进构建产物里。

错误的时机是:JSON 是给人看的、payload 本来就小,或你的基础设施已经在传输中压缩响应了。

当你确实需要 minify 时 —— 不论是在构建脚本、CI 步骤,还是一次性清理里 —— 各语言里的做法都一样:先解析 JSON,再不带 spacer 序列化它。如果你的 JSON 因有错误而无法解析,请先 修复它,然后再压缩。