Skip to main content

RFC-9000 文件命名说明

背景​

RFC-9000文档存在两种文件命名风格：

英文原版（带下划线）​

  • 7.Cryptographic_Handshake.md
  • 10.Connection_Termination.md
  • Appendix_A.md

翻译版（无下划线/CamelCase）​

  • 7.CryptographicHandshake.md
  • 10.ConnectionTermination.md
  • Appendix-A.md

影响分析​

✅ 无影响项​

  1. 内容完整性：两种命名方式不影响文档内容
  2. 文件访问：Docusaurus正确处理两种路径格式
  3. ID一致性：frontmatter中的ID保持一致
  4. 功能正常：所有链接和导航功能正常

⚠️ 差异项​

  1. 文件系统：在文件列表中显示不同
  2. 自动化脚本：需要处理两种命名模式
  3. 开发者体验：首次接触时可能困惑

决策建议​

方案1：保持现状 ⭐ 推荐​

优点：

  • 无需修改任何文件
  • 零风险，不影响现有引用
  • 翻译版的CamelCase更符合现代URL规范
  • 所有5种语言已统一使用无下划线格式

缺点：

  • 文件命名不统一
  • 需要在自动化脚本中处理两种模式

适用场景：

  • 项目已在生产环境运行
  • 有外部链接引用
  • 不希望引入变更风险

方案2：统一为CamelCase（无下划线）​

操作：重命名英文版19个文件

  • Connection_Termination.md → ConnectionTermination.md

优点：

  • 全局命名统一
  • 符合现代URL命名规范
  • 与翻译版一致

缺点：

  • 需要修改19个文件
  • 需要更新内部链接引用
  • 可能破坏外部引用

工作量：中等（19个文件）

方案3：统一为下划线风格​

操作：重命名所有翻译版文件（19文件 × 5语言 = 95文件）

  • ConnectionTermination.md → Connection_Termination.md

优点：

  • 与英文原版一致
  • 下划线在某些场景更易读

缺点：

  • 工作量巨大（95个文件）
  • 需要更新大量内部链接
  • 高风险，容易出错
  • 与现代URL规范不符

工作量：大（95个文件）

最终建议​

建议采用方案1：保持现状

理由：

  1. ✅ 两种命名都有效且可访问
  2. ✅ 不影响内容质量和用户体验
  3. ✅ 翻译版的命名实际上更优（符合URL规范）
  4. ✅ 零风险，无破坏性变更
  5. ✅ 节省大量修改和测试时间

如何处理差异​

对于开发者​

在脚本中使用映射表：

# 文件名转换函数
convert_filename() {
    echo "$1" | sed 's/_//g'
}

# 或使用映射表
declare -A FILE_MAP=(
    ["Connection_Termination.md"]="ConnectionTermination.md"
    ["Error_Handling.md"]="ErrorHandling.md"
    # ...
)

对于文档​

在README中说明两种命名风格的存在和原因。

文档版本：1.0
创建日期：2026-01-08
审核状态：✅ 已通过

Last updated on