• 后端
• 文档
• 教程

导读

在系统设计中选择"用哪种方式处理数据"，直接决定了数据传输、存储安全与合规审计的成败。本文以 system-design-101 仓库的 encoding-vs-encryption-vs-tokenization.md 为主体，系统拆解编码（Encoding）、加密（Encryption）与令牌化（Tokenization）三种数据处理方式的本质区别、适用场景与实战选择标准。读完本文，你将掌握何时用 Base64 做传输表示、何时用对称/非对称加密保护机密性、何时用令牌化满足 PCI DSS 等合规要求，并能结合仓库中 symmetric-encryption-vs-asymmetric-encryption.md、how-do-we-manage-sensitive-data-in-a-system.md 与 how-digital-signatures-work.md 等关联文档，建立一套完整的数据处理决策框架。

一、三者概览：先分清目的，再谈技术

编码、加密、令牌化是三种截然不同的数据处理过程，服务于不同目标：

核心判断标准只有一句话：编码解决"能不能传"，加密解决"别人能不能看懂"，令牌化解决"系统里到底要不要出现真数据"。在做系统设计时，我们需要针对敏感信息选择正确的处理方式，而这三者在同一系统中往往会被组合使用。

二、编码（Encoding）：可逆的格式转换，不是安全手段

2.1 编码的本质

编码是使用一套易于逆转的规则将数据转换为另一种格式的过程。最典型的例子是 Base64 编码：它将二进制数据编码为 ASCII 字符，使得数据能够通过只支持文本的介质（如 JSON、HTTP Header、邮件正文）进行传输。

编码的核心特征：

• 同一套规则即可解码：编码和解码使用完全相同的算法，无需任何密钥；
• 目的是互操作性：编码解决的是"数据表示形式"问题，让二进制内容能在文本协议中"旅行"；
• 不提供任何安全性：编码后的数据可以被任何掌握规则的人轻易还原。

仓库中 smooth-data-migration-with-avro.md 从另一个侧面印证了"编码/序列化"的价值与边界：Apache Avro 通过将 schema 与数据块一起存放，动态生成 schema 以支撑数据迁移，说明"格式转换"解决的是互操作与演进问题，而非安全问题——这与 Base64 的定位一致。

2.2 常见编码示例

除了 Base64，系统设计中常见的编码还包括：

• URL 编码（Percent-encoding）：将特殊字符转换为%XX形式，保证 URL 可安全传输；
• 十六进制（Hex）编码：将二进制表示为0-9A-F字符，常用于摘要、密钥的展示与存储；
• UTF-8 / ASCII：字符集编码，解决文本在字节层面的表示问题。

2.3 编码的常见误区

一个高频踩坑点是把编码当加密用。例如把密码做 Base64 后存入数据库——这没有任何防护作用，因为解码不需要密钥。密码在数据库中的安全存储，必须走哈希 + 加盐路线，详见 how-to-store-passwords-in-the-database.md：盐（salt）是每次哈希随机生成并可以明文存储的字符串，密码以hash(password + salt)形式保存，校验时重新计算哈希与库中值比对即可。这一实践与编码、加密、令牌化共同构成了完整的数据安全分层。

三、加密（Encryption）：用密钥守护机密性

3.1 加密的定义与目标

加密通过依赖密钥的复杂算法转换数据：把可读的明文（plaintext）变成不可读的密文（ciphertext）。只有持有正确密钥的一方才能解密并访问原始数据。加密的设计目标是保护数据机密性。

3.2 对称加密与非对称加密

加密分为两大阵营，symmetric-encryption-vs-asymmetric-encryption.md 给出了清晰的对比：

对称加密（Symmetric Encryption）

• 使用同一个密钥完成加密与解密；
• 速度快，适用于海量数据的批量加解密，例如加密大量 PII（个人身份信息）；
• 挑战在于密钥管理：发送方与接收方共享同一个密钥，一旦泄露，全盘皆输。

非对称加密（Asymmetric Encryption）

• 使用密钥对：公钥（public key）自由分发、用于加密；私钥（private key）严格保密、用于解密；
• 更安全，因为私钥永不共享；
• 速度较慢，受限于密钥生成与数学运算的复杂度。

两者的经典组合应用是 HTTPS：TLS 握手阶段使用非对称加密安全地交换会话密钥，随后通信使用对称加密以保证吞吐性能——这正是"各取所长"的工程实践。

3.3 密钥管理：加密体系的安全基石

加密的安全强度不取决于算法本身，而取决于密钥如何管理。仓库中的 how-do-we-manage-sensitive-data-in-a-system.md 给出了一个密钥分片治理思路：为密钥存储设计不同的角色，包括密钥申请者（password applicant）、密钥管理者（password manager）与审计者（auditor），三方各持一段密钥，必须集齐三段才能打开锁。这种"职责分离 + 多方共管"的模式，正是对抗单点密钥泄露的常用设计。

同一文档还提示：类似 GCM 的算法将密文数据与密钥分开存储，使攻击者即使拿到密文也无法解读用户数据。这与"加密 ≠ 密钥与密文同放"的工程常识一致。

3.4 加密与哈希的关系

容易混淆的是加密与哈希：

• 加密可逆：需要密钥解密，用于保护机密性；
• 哈希不可逆：单向函数，用于完整性校验与口令存储，如 how-digital-signatures-work.md 中所示——签名者用哈希函数从文档生成定长摘要，再用私钥加密该摘要形成数字签名，接收方用公钥解密摘要并与重算哈希比对，验证文档是否被篡改。

简单记忆：加密要能"解回来"，哈希永远"回不去"。这也是为什么密码存储使用哈希（而非加密），而信用卡号在传输链路中需要加密。

四、令牌化（Tokenization）：让真数据离开业务系统

4.1 令牌化的定义

令牌化是将**敏感数据替换为不敏感的占位符（令牌，token）的过程。原始数据与令牌之间的映射关系被安全地存储在令牌保险库（token vault）**中。

令牌可以在各类系统与流程中自由流通，而不暴露原始数据，从而显著降低数据泄露风险。其安全核心在于：令牌不包含原始数据的任何部分，无法被逆向工程还原出原始数据——即使数据库、日志、第三方接口被攻破，攻击者拿到的也只是无意义的令牌。

4.2 典型应用场景

令牌化最常用于保护：

• 信用卡信息（满足 PCI DSS 合规）；
• 个人识别号码（PIN）；
• 其他敏感数据（如身份证号、手机号）。

对于 PCI DSS 这类要求"持卡人数据不得明文出现在业务系统中"的合规场景，令牌化几乎是唯一能让业务系统"无卡号运行"的合规方案。

4.3 令牌化与加密的本质区别

一句话概括：加密是"数据变形但还在系统里"，令牌化是"数据移出业务系统，只留一个代号"。

五、如何选择：系统设计中的决策框架

在真实系统中，三者常常叠加出现。以"支付应用保存信用卡"为例，完整链路可能是：

1. 编码：请求报文中的卡号字段经 Base64 编码后在 HTTP 中传输（仅解决格式兼容）；
2. 加密：传输链路用 TLS（HTTPS 的非对称+对称加密组合）保护，防窃听；
3. 令牌化：业务数据库只存令牌，真卡号托管在 token vault，满足 PCI DSS。

选择时可按以下问题逐层决策：

• 数据是否需要在文本介质中传输？→ 编码（Base64 / URL 编码）；
• 是否需要保护数据机密性、防止链路或存储被窃取？→ 加密，按性能与密钥管理成本选择对称/非对称；
• 是否需要让业务系统根本不接触真数据以满足合规？→ 令牌化。

同时不要忽略 how-do-we-manage-sensitive-data-in-a-system.md 提出的配套治理要求：敏感数据（PII、健康信息、知识产权、财务信息等）受 GDPR 等法规约束，系统设计需要同步落实最小权限（RBAC）、数据脱敏（desensitization）与数据生命周期管理（开发期授权、上线后回收权限）——数据处理方式只是安全体系的一环。

六、小结

编码、加密、令牌化不是可以互相替代的同义词，而是三个目的各异的处理层：

• 编码解决格式与传输，天然可逆、无密钥、无安全性；
• 加密解决机密性，可逆但有密钥门槛，对称重在性能、非对称重在安全，实战中常组合使用（如 TLS）；
• 令牌化解决"系统内不存真数据"，最契合 PCI DSS 等合规场景，安全性建立在 token vault 与不可逆令牌之上。

在 system-design-101 仓库中，围绕本主题还可以进一步阅读 symmetric-encryption-vs-asymmetric-encryption.md（对称/非对称加密细节）、how-do-we-manage-sensitive-data-in-a-system.md（密钥管理、脱敏与最小权限）、how-digital-signatures-work.md（哈希与签名验证）以及 how-to-store-passwords-in-the-database.md（加盐哈希）。掌握这三项能力，你在面试与生产系统中面对敏感数据处理时，就能给出有依据、可落地、合规的方案。

• 后端
• 文档
• 教程