在 Postgresql 中存储原始 IMAP 获取的电子邮件消息的数据类型是什么？

Question

我需要在从 IMAP 获取电子邮件消息后立即将其存储在数据库中以供以后处理。我使用FETCH 请求提取消息，并使用BODY.PEEK[] 返回数据。

据我了解，所有 IMAP 邮件都以US-ASCII 的形式返回（邮件服务器只接受那个），但我可能是错的。

我的选择（按照我认为正确的顺序）是：

• US-ASCII 文本列
• 字节亚
• BLOB

我正在考虑使用 US-ASCII，但我担心编码有问题，我不知道是否有“故障”IMAP 服务器没有返回 us-ascii 邮件。 另一种选择是 Bytea，但我读到您必须处理编码，所以我不确定与 US-ASCII 相比有什么优势/劣势。 BLOB 是原始的，我不确定它在这种情况下会带来什么问题。我假设我必须处理字节到字符串的转换。

推荐的数据类型是什么？

Answer 1

对于电子邮件等小对象，我认为使用 Bytea 会更好。存储和处理是不同的，因为你的对象会很小，看起来它会像字节茶一样处理得更好。请参阅here 以了解 Microolap 对两者的比较。这不是您问题的完整答案，但可能会从列表中删除一个选项。

Answer 2

您做出了一个非常没有根据的假设，即您可以避免处理编码。

你不能。

无论您使用 lob、bytea 还是您假设仅包含 7 位邮件的 text 列...邮件只是任意二进制数据。你不知道它的文本编码。实际上，邮件客户端一直使用 8 位编码；通过 MIME 引用打印符合标准，或者通常只是原始的 8 位文本。

甚至已知某些客户端包含包含空（零）字节的完整 8 位 MIME 段。 PostgreSQL 不会在 text 列中容忍这种情况。

但即使对于使用兼容 MIME、可引用打印的转义文本主体等的客户，邮件也可能包含非 ASCII 字符，它们只是被转义了。索引这些并忽略转义将产生奇怪和错误的结果。此外，附件通常是任意 base64 数据。将其作为文本进行索引是完全没有意义的。然后是所有的 HTML 正文、多部分/替代段、CSS 等......

在处理电子邮件时，假设客户端或服务器可能做错的任何事情，它都会做错。对于存储，将电子邮件视为未知编码的原始字节。这正是bytea 的用途。

如果您想对邮件进行任何操作，您需要一个防御性的 MIME 解析器，它可以提取 MIME 部分、处理损坏的部分等。它需要检查声明的编码（如果有的话）针对实际的 mime 部分主体，如果没有声明或声明的编码明显错误，则猜测编码。它必须处理各种伪造的 MIME 结构和内容；不是真正可引用打印的引用打印体，等等。

因此，如果您打算索引这封电子邮件，那绝对不是“创建全文索引并愉快地继续”那么简单。问题不是 if 它会失败，而是 when。

就个人而言，如果我必须这样做（如果我可以选择不这样做），我会将原始电子邮件存储为 bytea。然后对于搜索，我将其分解为 MIME 部分，检测类似文本的部分，进行编码检测和取消引用等，并将解码和清理的文本主体注入单独的表中以进行文本索引。

有一些有用的 Perl 模块可以通过plperlu 使用，但我可能会在外部脚本/工具中使用。然后，您可以选择 MIME 处理器、语言等。