摘要

  • RFC 2422 把字节布局纳入 audio/32KADPCM 的契约：较早的码字放入低半字节，随后一个放入高半字节。
  • 码字数量为奇数时，RFC 优先建议补入静音；若仍为奇数，则丢弃最后一个码字。这条规则消除了字节解释的歧义，却不能证明邮件已送达或有人听过。

编解码器的数学工作此前已经完成。ITU-T 建议 G.726 描述了自适应差分脉冲编码调制，以及如何在每秒 8,000 次采样的 64 kbit/s A 律或 μ 律 PCM 与较低速率信道之间转换，其中包括 32 kbit/s。达到 32 kbit/s 时，每个采样由四个位表示。这说明码字如何生成，却没有单独说明八位字节的哪一半装着较早的码字。

这个区别很容易在编解码器说明中被忽略，却足以阻断互换。两个实现可以得到相同的四位数值序列，却把每一对分别放进字节相反的两半。按各自本地约定看，两边的八位组都有效；使用另一种约定的读取端却会还原出不同序列。这并不要求文件损坏，也不意味着邮件事务失败。歧义发生在更低一层：只看 MIME 子类型，接收端无法知道发送端采用了哪一种本地约定。

RFC 1911 早已把 Audio/32KADPCM 列为其实验性 Voice Profile for Internet Mail 的必选通用音频格式之一。它规定了这种编码在受限邮件配置中的作用，却没有解决四个位的先后顺序。RFC 2422 于 1998 年 9 月作为标准轨文件发布，并明确细化了早先的注册；它补上了这道缺口，为 G.726 数据注册 audio/32KADPCM，并把一种序列化约定纳入子类型本身的含义。

具体映射没有含糊空间。每个八位组中，第一个码字 A 占第 0 至第 3 位，其最低有效位 A0 放在整个八位组的最低位。下一个码字 B 占第 4 至第 7 位，B3 位于最高位一端。后续码字两两依此排列。这不是把整个音频流反转，也没有改变 G.726 的自适应预测器；它只规定一个字节中两个半字节的顺序。

明确规则也意味着责任被分配。RFC 2422 指出，既有 G.726 编解码器可能采用不同的码字顺序。该 MIME 类型只接受小端排列，因此采用相反约定的编解码器必须在写入这种类型之前或读取之后重新排列码字。一个共同名称本身并不能让这些编解码器互操作。标准把转换发生的位置变得可见、可验证，而不是让每一对系统私下协调。

最后一对不完整的码字还揭示了另一道边界。RFC 建议优先在语音采样末尾补入静音，使编码结果含有偶数个码字。如果最终仍为奇数，就丢弃最后一个。它并非对安静收尾的审美偏好，而是在告诉解析器剩余半个字节应如何解释。没有这条规则，容器会停在字节边界，编解码序列却终止在两个半字节之间；读取方只能自行发明一条规则，决定那最后半个单元是否有效。

这个子类型没有必需或可选参数。正文承载 G.726 二进制音频，不包括音频头部信息；MIME 传输编码可以使用二进制，通常也可以使用 Base64。这是两件不同的事。Base64 改变八位组如何通过邮件系统传输，却不会改变正文解码后 A、B 分别位于哪个半字节。把传输编码当成码字顺序的答案，就是把字节的外壳和字节的含义混为一谈。

因此，RFC 2422 讲述的是一段简短却重要的标准制定史：定义变换算法，有时仍不足以定义一个可互操作的对象。一旦输出跨越系统边界，顺序、补齐和责任也会成为契约的一部分。文件并未说明该规则的实际部署范围、哪一种编解码器曾经出错，或收件人是否听到了消息。它确实说明，实现必须在哪里明确作出选择，以及 MIME 子类型不再允许把这个选择留在本地。