11

我正在做一个电子邮件项目。由于我不会在此处详细介绍的原因，在客户环境中对长电子邮件消息进行引用可打印编码是有问题的。

对我们发送的 SMTP 电子邮件的 HTML 和文本部分进行 base64 编码似乎是一个可行的选择。在测试它时，它似乎在几个测试客户端（如 Gmail）中工作得很好。

但是我想知道这是否会在不同的电子邮件客户端中出现任何问题。从阅读 RFC 规范来看，base64 似乎是文本部分的兼容编码，但对于文本和 html 部分来说，这已经足够不寻常了，我想知道是否会有任何潜在的问题需要考虑。

看起来有问题的可能性：

  • 也许一些较旧或不太健壮的客户端不希望在文本或 HTML 电子邮件部分中使用 base64，并且无法对其进行编码
  • 也许某些电子邮件客户端会根据原始内容进行预览或搜索，因此收件人会看到 base64 而不是实际内容
  • 也许 base64 会对可传递性/垃圾邮件评分产生负面影响？

有人有经验可以分享吗？这似乎是一个很好的解决方案，但我想确保我没有遗漏任何东西。

4

1 回答 1

14

这很难回答——是的，quoted-printable更频繁地使用它只是因为它浪费的字节更少（在主要是 ASCII 文本上），并且因为邮件正文部分的原始文本类似于解码后的输出（在主要是 ASCII 文本上）。但是，没有任何内容禁止base64用于文本消息部分。

这几乎是一个悬而未决的问题——你永远无法确定某个地方的 MUA 没有被彻底破坏到没有显示任何东西的程度。里面有很多“也许”，你是对的——但问题是你永远不会知道。如果它能让你睡得更好，以下公司都在我收到的营销垃圾邮件中使用 base64 编码的 HTML：

  • 梅拉诺克斯
  • 阿尔扎.cz
  • 奥克罗.cz
  • 现代物理学杂志

任何可以显示嵌入图像的 MUA 都必须包含 base64 解码器。绝对有可能 MUA 可能会明确拒绝使用该代码进行解码text/plain，text/html但在这种情况下，无论如何你都被搞砸了。

有趣的是，其中一家公司很乐意在多字节字符内的字节边界打破 UTF-8 编码主题，并将文本的两半编码为单独的编码字（此处为 RFC2047 术语）。

于 2013-05-01T14:37:20.603 回答