数据编码、存储与传输
这篇解决什么问题
程序处理的字符串、图片、JSON、文件和网络报文,底层都是字节。数据编码、存储与传输要解决的是:信息如何变成字节,字节如何保存,字节如何跨网络传递,并在另一端正确还原。
学完你会掌握
- 二进制和字节为什么是数据表达基础。
- 字符编码为什么会导致乱码。
- 压缩、序列化和传输分别解决什么问题。
- 为什么同一份数据在内存、文件和网络中格式可能不同。
核心概念
| 概念 | 作用 |
|---|---|
| 二进制 | 用 0 和 1 表示信息 |
| 字符编码 | 把字符映射成字节,如 UTF-8 |
| 压缩 | 用更少字节表示同样信息 |
| 序列化 | 把对象转换成可存储或可传输格式 |
| 网络传输 | 按协议把字节从一端发送到另一端 |
开发中最常见的编码是 UTF-8。它能表示中文、英文、符号等多种字符,是 Web 和现代系统的主流选择。
二进制、字节和字符
计算机最终处理的是 bit。8 个 bit 通常组成 1 个 byte。文件、字符串、图片、网络包,本质上都是字节序列。
字符不是天然等于字节。字符需要通过编码规则变成字节:
| 编码 | 特点 |
|---|---|
| ASCII | 主要表示英文字符,范围小 |
| GBK | 常见中文编码,历史系统中仍可能遇到 |
| UTF-8 | 可变长度编码,兼容 ASCII,Web 主流 |
| UTF-16 | 常见于部分运行时内部表示 |
乱码的根源通常是「写入时使用一种编码,读取时按另一种编码解释」。
序列化格式取舍
对象要跨进程、跨网络或写入文件,必须序列化。
| 格式 | 优点 | 局限 |
|---|---|---|
| JSON | 可读性好,Web 生态强 | 不擅长二进制、大整数、日期 |
| XML | 表达能力强,历史系统多 | 冗长 |
| Protobuf | 体积小,性能好,有 schema | 可读性弱,需要生成代码 |
| MessagePack | 二进制紧凑 | 生态和调试便利性不如 JSON |
| CSV | 简单适合表格 | 类型表达弱,转义容易踩坑 |
工程上不要只问「哪个格式更快」,还要看调试成本、跨语言支持、版本兼容和团队习惯。
压缩和传输
压缩适合减少网络传输和存储体积,但会增加 CPU 开销。常见策略是:
- 文本资源用 gzip、br 等压缩。
- 图片和视频使用专门的媒体编码。
- 小数据不一定值得压缩。
- 已经压缩过的格式,再压缩收益通常很低。
网络传输时还要关注分片、流式处理和超时。大文件如果一次性读入内存,容易造成内存峰值过高。
它是怎么工作的
以一个 API 返回 JSON 为例:
后端对象
-> 序列化为 JSON 字符串
-> 用 UTF-8 编码成字节
-> 通过 HTTP 传输
-> 浏览器收到字节
-> 按 UTF-8 解码
-> 解析为 JavaScript 对象
任何一步约定不一致,都可能导致乱码、解析失败或数据丢失。
开发中的真实场景
常见问题包括:
- 中文乱码:写入和读取使用了不同字符编码。
- JSON 解析失败:响应不是合法 JSON,或 Content-Type 不匹配。
- 大文件上传慢:缺少压缩、分片或流式处理。
- 接口字段丢失:序列化规则忽略了空值或私有字段。
- 精度丢失:大整数在 JavaScript 中超过安全整数范围。
AI Coding 时代怎么用
让 AI 处理数据格式时,要明确:
- 输入是什么编码。
- 输出要给谁消费。
- 是否要求兼容旧系统。
- 是否存在大整数、时间、二进制文件、压缩包等特殊数据。
- 是否需要流式处理。
对于数据转换代码,最好要求 AI 给出样例输入、样例输出和边界测试。
常见误区
误区一:以为字符串在所有地方都一样。字符串进入文件或网络时必须变成字节。
误区二:以为 JSON 能表达所有数据。JSON 对日期、大整数、二进制数据并不天然友好。
误区三:以为压缩总是划算。压缩会节省带宽,但也会增加 CPU 开销。
误区四:以为接口返回 JSON 就不会丢信息。大整数、时间、空值、二进制数据都需要明确约定。
小结
数据在系统中流动时,会经历编码、序列化、压缩、存储和传输。理解这些转换,能帮助你定位乱码、解析失败、精度丢失和性能问题。