MIME 编码及其他：Quoted-Printable 与 URL 编码
如果你曾经检查过电子邮件的原始源码，或者观察过表单提交的网络追踪，你一定见过像 =E9 或 %C3%A9 这样奇怪的字符字符串。这些就是二进制转文本编码方案。
在本指南中，我们将探索那些弥合了陈旧的纯文本系统与现代丰富的二进制互联网之间鸿沟的编码方法。从电子邮件标准的 Quoted-Printable 到无处不在的 URL 编码，我们将剖析它们的工作原理以及何时使用它们。
1. 理论：为什么要进行二进制转文本？
计算机将所有数据表示为二进制（零和一）。然而，许多通信协议——特别是像 SMTP（电子邮件）这样较老的协议——最初设计时仅能处理 7 位 ASCII 文本。如果你尝试通过 7 位系统发送二进制文件（如 JPEG 图像），控制字符（如 NULL 或 EOF）将会导致传输中断。
为了解决这个问题，我们使用二进制转文本编码将二进制数据转换为安全的、人类可读的 ASCII 格式。虽然 Base64 是最著名的例子，但它并不总是最高效的。
2. Quoted-Printable (QP) 编码
Quoted-Printable (QP) 在 RFC 2045 中定义。它专为“绝大部分是 ASCII 但包含少量非 ASCII 字符”（如带重音的字母或特殊符号）的数据而设计。
工作原理
- ASCII 字符（从 33 到 126，不包括
=）按原样发送。 - 非 ASCII 字符用一个等号后跟该字符的十六进制值表示（例如，'é' 变为
=E9）。 - 软换行： 为了防止行变得过长，行尾的单个
=表示“软换行”，接收者应忽略它。
何时使用
QP 非常适合 95% 的文本都是标准 ASCII 的欧洲语言。与会使文本变得人类完全无法阅读的 Base64 不同，经 QP 编码的文本大部分仍然清晰可辨。
3. MIME 编码字 (MIME Encoded-Word)
电子邮件由两部分组成：正文 (Body) 和 头部 (Headers)（主题、发件人、收件人）。虽然正文可以使用 QP，但头部有更严格的规则。MIME 编码字 (RFC 2047) 的创建是为了允许在邮件头部使用非 ASCII 字符。
语法
一个编码字的格式如下：=?charset?encoding?encoded-text?=。
- charset: 例如
UTF-8 - encoding:
Q（代表 Quoted-Printable 的变体）或B（代表 Base64）。 - 示例：
=?UTF-8?Q?Hello_=C3=A9?=。
4. Web 的语言：application/x-www-form-urlencoded
当你提交 HTML 表单时，浏览器会将数据编码为 application/x-www-form-urlencoded。这与 URL 查询字符串 使用的是同一种编码。
深入探讨
虽然与 Quoted-Printable 类似，但 URL 编码有其独特的规则（通常称为百分号编码）：
- 字母数字字符 (A-Z, a-z, 0-9) 永远不被编码。
- 空格 被转换为加号
+（在表单数据中）或%20（在 URL 中）。 - 特殊字符（如
/,&,=）被转换为%后跟它们的十六进制值（例如，/变为%2F）。
常见陷阱
许多开发者忘记了 & 和 = 在 URL 中具有特殊含义。如果你尝试传递像 name=John&Doe 这样的值，你必须将其编码为 name=John%26Doe，否则服务器会认为 Doe 是一个独立的参数。
5. 比较：QP vs. Base64 vs. URL 编码
| 编码方式 | 效率（二进制数据） | 人类可读？ | 主要应用场景 |
|---|---|---|---|
| Quoted-Printable | 可变 (对于二进制约 3:1) | 是 | 邮件正文（欧洲语言） |
| Base64 | 固定 (4:3) | 否 | 邮件附件、Data URI |
| URL 编码 | 可变 (对于二进制约 3:1) | 部分 | 表单提交、API 查询参数 |
结论
编码是互联网中看不见的翻译层。无论是确保你的“主题”行在收件箱中正确显示，还是确保复杂的 API 请求完整到达，理解 Quoted-Printable 和 URL 编码的细微差别对任何现代 Web 开发者来说都是一项至关重要的技能。
下次当你看到 %20 或 =E9 时，你就会确切地知道是哪种协议在发挥作用，确保互联网的齿轮平稳运行。