7

我正在阅读Base91 的提案，（我添加了粗体格式）：

所有基于 SMTP 的电子邮件都可以提供与电子邮件的兼容性。所谓与E-mail兼容，就是将E-mail传送的任意8位数据字节串或任意位流数据转换为有限ASCII码的字符串。后者的主要限制是：
(a) 字符必须是可打印的；
(b) 字符不是控制字符或“-”（连字符）。
这样的ASCII字符总共有94个，它们对应的数字编码都是32到126之间的整数，45除外。用这些 ASCII 字符编写的电子邮件与 Internet 标准 SMTP 兼容，几乎可以在所有电子邮件系统中传输。

注意：45 是连字符的 ASCII 值。
注：我刚刚发现这个提案来源于中国（ZL00112884.1）和美国（US6859151B2）的专利。

但我也阅读了关于 SMTP 的RFC 5321 ，但我找不到任何使连字符成为可打印 ASCII 范围的唯一限制的内容。

注意：可打印的 ASCII 范围是：
!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~

为什么 Base91 提案/专利声称“-”（连字符）是电子邮件兼容性的唯一限制？

4

2 回答 2

5

看起来连字符在多行 SMTP 消息中用作控制/标记字符。

RFC5321 4.2.1 回复代码严重性和理论：

多行回复的格式要求除最后一行外，每一行都以回复代码开头，紧跟连字符“-”（也称为减号），然后是文本。最后一行将以回复代码开头，紧随其后的是<SP>，可选的一些文本和<CRLF>。如上所述，<SP> 如果未发送后续文本，服务器应该发送，但客户端必须准备好忽略它。

Base91 提案使用 SMTP 作为其应用和限制的示例。正如您所说，它最初想使用 94 个字符，但由于各种标准（例如 SMTP），它排除了常用的伪控制字符（“-”、“.”、“=”）。它使用 SMTP 是因为它展示了 Base91 编码的实用性（例如，使用 Base64 对每个字符编码 13 位数据而不是 6 位可以大大减少对任何给定消息进行编码所需的位数），此外还承认它使用连字符作为控制字符不会在 Base91 文本中引起歧义。

Base91 可以对任何文本进行编码——论文指出，它将 13 位数据映射为两个可打印的 ASCII 字符。任何数字，任何字符（包括换行符）都可以用 Base91 编码，类似于任何字符可以用 Base64 编码。同样，可以反转此映射，以从 Base91 编码生成原始输出。

这是一个多行 SMTP 回复代码示例：

  250-First line
  250-Second line
  250-234 Text beginning with numbers
  250 The last line

在此示例中，它将包含连字符、换行符和数字的大型多行 SMTP 消息转换为某种 Base91 编码的形式。如果此编码形式包含伪控制字符，例如连字符，则 SMTP 客户端可能会将 Base91 编码的数据解释为格式错误的 SMTP 数据。从 Base91 字符集中删除连字符等字符的目的不是因为 SMTP 的缺陷或 SMTP 本身的规范，而是与使用和解析 SMTP 数据的客户端有关，并确保客户端仍然可以正确接受 Base91 数据而没有任何风险将其误解析为 SMTP 数据。

于 2018-06-19T15:30:48.080 回答
0

我的怀疑是，这只是为了使 base91 对人们有时对文本所做的事情具有鲁棒性，即跨文档复制/粘贴等。期望这种情况经常发生并没有多大意义，但是一些文字处理器等会使用破折号作为连字符点。

于 2018-06-20T04:20:47.757 回答