摘要

  • RFC 1924 把完整的 128 位 IPv6 地址视作一个整数，用 85 个可打印 ASCII 字符编码成固定二十位。转换可逆、算术严密，但这不等于人员与工具能够直接识别、搜索和关联。
  • 字母表刻意让出九个符号，供引号、列表、句号、CIDR、URL、方括号与转义使用。这说明地址表示从来不是孤立的数学对象，它必须嵌入别的语法。
  • 后来的标准路线保留冒号十六进制，以方括号解决 URI 边界，再用规范化输出减少同值异形。字符串一致只是表示证据，不能升级为分配、授权、路由、身份或交付证明。

从一次“零结果”开始

事故工单里写着一个熟悉的 IPv6 地址。分析员把它粘贴进日志系统，返回零条结果。若换成按数值检索，记录其实就在那里：128 位没有变化，只是被 RFC 1924 的 Base85 形式写了出来。失败发生在地址与调查之间，而不是地址与解码器之间。

RFC 1924 于 1996 年 4 月 1 日以 Informational 文档发布，并未规定互联网标准。它把地址当作无符号大整数，在包含 85 个可打印 ASCII 字符的字母表中展开。示例把 1080:0:0:0:8:800:200C:417A 变成 4)+k&C#VzJ4br>0wv%Yp。每个结果固定二十位，前导零也保留下来。

这足以证明可逆性：合格的解码器能找回原值。但运维中的问题远不止“能否找回”。URL 解析器是否知道边界？资产表是否按数值归一？旧日志索引是否包含新写法？值班人员是否能一眼认出它属于 IPv6？如果答案不一致，同一个地址会在不同系统里形成互不相见的证据岛。

二十位是一条精确的算术边界

IPv6 有 (2^{128}) 个可能值。二十位 84 进制覆盖不了全部空间，二十位 85 进制则足够：(84^{20} < 2^{128} \leq 85^{20})。即便使用 94 或 95 个可打印字符，也仍然需要二十位。因此，Base85 在维持最短固定宽度的同时，可以空出九个字符。

固定宽度并非虚假的优点。字段长度可预测，没有十六进制压缩造成的多种合法写法，机器解码后也能直接比较数值。若记录边界已由外层协议明确，而且所有参与者都部署了解码器，这种形式紧凑而完整。

问题恰恰在“外层”。被排除的九个字符包括单双引号、逗号、句点、斜杠、冒号、左右方括号和反斜杠。它们承担引用、列表、句末、CIDR 后缀、URL、字面量边界和转义。RFC 1924 的字母表实际上承认：要缩短内部值，仍须为周围语法留下呼吸空间。

熟悉的十六进制也有自己的债务

早期 IPv6 地址架构允许八个 16 位十六进制组，以冒号分隔；每组前导零可省略；一段连续零组可以用一次 :: 压缩；尾部还可写成 IPv4 十进制。这些自由使同一个值拥有多种合法拼法。冒号与分组提供了可识别轮廓，却没有提供唯一字符串。

在人工阅读里，轮廓很重要。在机器比对里，不唯一也会带来代价：电子表格把同值当成两项，文本检索漏掉另一种写法，Whois、图表与日志看似互相矛盾。RFC 1924 用全新字母表消除了原有变体，却要求整条工具链理解另一种表面。

后来的做法更像分层修补。IPv6 字面量进入 URL 时，内部冒号会与外部语法碰撞。RFC 2732 选择用方括号包住地址，并把“尽量少编辑即可复制粘贴”列为目标；RFC 3986 随后保留了 URI 中的方括号 IP-literal。它们解决的是边界冲突，没有重造地址内部的表示。

规范化把相等写到表面

RFC 4291 仍接受灵活的十六进制文本形式。到 2010 年，RFC 5952 已明确记录多种合法写法给搜索、电子表格、文本文件、Whois、网络图、日志、审计和核验带来的问题。它采用不对称策略：解析器必须继续接收 RFC 4291 允许的所有合法输入，输出端则遵守一套规范形式。

规则包括：去掉每组前导零；使用小写十六进制；用 :: 最大化压缩最长的连续零组；长度相同则选择最先出现的一段；单独一个零组不得用 ::。这并不追求每个字符串都短到极限，而是让独立系统更可能为同一数值留下同一条可见记录。

这一选择把兼容与证据分开处理。入口宽容，避免旧数据失效；出口收敛，降低后续比对成本。方括号再为 URI 提供外部边界。无需让每个参与者同时学习一套全新字母表，也能改善共同接口。

六级证据不能越级

第一层是 128 位原值；第二层是解析后的数值；第三层是规范化显示；第四层是日志真正保存的字符串；第五层是检索是否命中；第六层才是观测到的网络结果。每一层都有独立失败方式。

两个字符串解码相同，只证明表示等价。两个规范字符串相同，只证明格式器遵守同一约定。日志出现一个地址，只证明某组件记录了它。这些都不能证明地址分配给谁、路由起源是否获授权、路由是否在线、接口是否可达、服务是否通过认证，更不能证明数据包已交付。

这条历史线索来自 RFC 1884、RFC 1924、RFC 2732、RFC 3986、RFC 4291 与 RFC 5952。这些规范没有提供 Base85 “从未实现”的部署普查，也没有证明后续作者正式否决了它。

Running-Code Primacy 提供的是后来的分析纪律：检查真实解析器、日志和运维流程究竟接受并保留了什么。Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption 则帮助解释，为何较小的共同规则可以容纳本地选择而不破坏协调。两篇文章都不能倒推成 RFC 作者当年的意图。

RFC 1924 的二十个字符没有丢失任何地址位。它提醒后人：证据会在位之外丢失——丢在格式器、日志、搜索框和人的识别之间。