2. 本文档使用的约定
本文档中的关键词 "MUST"（必须）、"MUST NOT"（禁止）、"REQUIRED"（要求）、"SHALL"（应）、"SHALL NOT"（不应）、"SHOULD"（应该）、"SHOULD NOT"（不应该）、"RECOMMENDED"（推荐）、"MAY"（可以）和 "OPTIONAL"（可选）应按照 [RFC 2119] 中的描述进行解释。
RFC 2119 关键词解释
根据 RFC 2119，这些关键词在本规范中具有以下特定含义：
强制性要求
| 关键词 | 含义 | 示例 |
|---|---|---|
| MUST | 绝对要求 | 实现必须包含填充字符 |
| MUST NOT | 绝对禁止 | 实现不得添加换行符 |
| REQUIRED | 等同于 MUST | 要求支持标准字母表 |
| SHALL | 等同于 MUST | 解码器应拒绝非法字符 |
| SHALL NOT | 等同于 MUST NOT | 编码器不应使用非标准字符 |
推荐性要求
| 关键词 | 含义 | 示例 |
|---|---|---|
| SHOULD | 强烈推荐，但允许例外 | 实现应校验填充 |
| SHOULD NOT | 强烈不推荐，但允许例外 | 实现不应忽略错误 |
| RECOMMENDED | 等同于 SHOULD | 推荐使用 URL 安全字母表 |
可选性
| 关键词 | 含义 | 示例 |
|---|---|---|
| MAY | 真正可选 | 实现可以支持无填充模式 |
| OPTIONAL | 等同于 MAY | 换行符支持是可选的 |
在基数编码规范中的应用
MUST 的使用
示例 1：填充要求
"实现必须在编码数据的末尾包含适当的填充字符。"
违反后果：❌ 解码失败、数据损坏
示例 2：非法字符处理
"如果编码数据包含不属于基数字母表的字符，
实现必须拒绝该数据。"
违反后果：❌ 安全漏洞、数据损坏
SHOULD 的使用
示例：错误报告
"当解码失败时，实现应提供清晰的错误信息。"
可接受的未遵从情形：
- 资源受限的嵌入式系统
- 性能关键的场景
MAY 的使用
示例：可选特性
"实现可以支持对不含填充字符的数据进行解码。"
含义：这是真正可选的功能；实现可自行决定是否支持。
实际应用指南
对实现者
合规优先级：
1. MUST/MUST NOT/REQUIRED/SHALL/SHALL NOT
→ 必须严格遵守，否则不合规
2. SHOULD/SHOULD NOT/RECOMMENDED
→ 强烈推荐遵循，除非有充分理由
3. MAY/OPTIONAL
→ 根据需求决定
对测试者
测试重点：
✅ 验证所有 MUST 要求
✅ 检查 SHOULD 推荐的实现情况
⚠️ 记录对 MAY 特性的支持状态
对用户
选择实现时：
1. 确保实现满足所有 MUST 要求
2. 优先选择遵循 SHOULD 推荐的实现
3. 根据需求选择 MAY 特性
常见误解
❌ 错误理解
误解 1："SHOULD 可以忽略"
✗ 错误：SHOULD 只是建议，可随意忽略
✓ 正确：SHOULD 是强烈推荐，仅在确有充分理由时偏离
误解 2："MAY 只是可选特性"
✗ 错误：MAY 特性不重要
✓ 正确：MAY 特性是可选的，但若实现则必须正确
误解 3："MUST 只是建议"
✗ 错误：MUST 在某些情况下可忽略
✓ 正确：MUST 是绝对要求，必须严格遵守
本规范关键要求预览
在后续章节中，你将看到以下关键要求：
第 3.1 节：
"实现不得向基数编码数据添加换行符，除非……"
第 3.2 节：
"实现必须在编码数据末尾包含适当的填充字符……"
第 3.3 节：
"如果编码数据包含不属于基数字母表的字符，
实现必须拒绝该数据……"
这些要求使用了 MUST，表明它们是绝对强制的，所有合规实现都必须遵守。
参考文献
- RFC 2119 - 用于 RFC 中表示需求等级的关键词
- RFC 8174 - RFC 2119 关键词中大小写歧义（更新版本）