问题标签 [mime4j]

我正在编写一个常规代码来从 MIME 消息中获取图像/附件，并且我想在 MessageWriter 类中使用 writeTo 和 writeBody 方法。

如何关闭或覆盖 MessageWriter 类中 writeTo 和 writeBody 方法输出中的解码？

我有下面的 groovy 代码，它检查字节 [] 的 mime 类型，下面的 apache 引用是apache-mime4j-0.6.jar

这段代码曾经可以工作，但我不确定为什么现在它会抛出异常

下面是我的示例 mime 消息，正在读取ByteArrayInputStream并尝试解析其 mime 类型

有人可以帮我解决吗？

我正在尝试拆分像这样的邮件文件：

在许多这样的文件中：

我已经阅读了一些关于拆分邮件的帖子，似乎使用 Mime4j 应该是一个好主意。所以我这样做了：

此代码正确地将邮件拆分为两个文件：标题和正文。可能有更好的方法来做到这一点，但我发现 Mime4j Javadoc 不是很有帮助......好吧，我仍在尝试完全理解它是如何工作的。

但是，我遇到了两个问题：

1) 正文以显然由 Mime 创建的一条线开始，如下所示：

我不知道如何摆脱它。

2）“原始消息”都在正文中。我不知道如何根据那些“原始消息”将身体分成更多部分。而且，并不是所有的邮件都采用这种格式。有时原始消息仅由制表符或每行前的 > 字符或仅由小标题“from，to”或另一行（如 --------forwarded-----）“显示” ---，等等......所以我不能使用格式分割它。

我认为 Mime4j 应该将这些部分识别为“Multipart”消息，但似乎不是（有一个案例 T_START_MULTIPART 但它没有找到任何东西。）

问题

如果没有标准，用作“最大标题行长度”的好值是多少？

是否有某种非正式标准来确定 SMTP 标头行的最大长度应该是多少？

语境

我使用Mime4J来解析 SMTP 消息。

最近，我遇到了与很长的标题行相关的解析失败，这是由Microsoft Forefront显然添加的标题引起的。有问题的标题行如下所示：

这导致 Mime4j 出现以下解析错误：

通过将 Mime4J 配置为接受更长的行，我能够解决这个问题：

我将它翻倍到 2000，因为我在堆空间方面有足够的空间，所以这不是问题。

但是我实际上可以通过将最大行长度增加到 1001 来解决这个问题。这个标题行正好是 999 个字符长，默认Mime4J值为 1000，这似乎不仅仅是巧合。

这整个问题可能是由于收到的邮件以 Windows 行结尾（即两个字节而不是一个字节）终止这一事实而导致的一个错误。

似乎MS Forefront并Mime4j同意彼此的最大长度为 1000，只是有人在行尾的问题上交叉了线。

谷歌搜索给了我这个 SO 答案，这意味着没有标准的最大长度： https ://stackoverflow.com/a/2721849/924597

有“正确”的价值吗？

我需要将电子邮件发送到需要阅读附件的旧系统。

对于多部分电子邮件中的每个部分，我需要提供附件在电子邮件中开始位置的字节偏移量，因此旧系统不需要知道如何解析电子邮件。

性能和内存使用是一个问题，因此该解决方案无法将整个电子邮件加载到内存中。在我看来，javax.mail 被忽略了。

你会如何在 Java 中处理它？

我的第一个想法是使用 mime4j，但该库不保留字节偏移量甚至行号。我调查了对 mime4j 进行 PR 以添加对行号和字节偏移的跟踪。但这并不容易，因为它是一个非常成熟的项目，并且在内部使用了大量的缓冲。

现在我在想，也许我正在以错误的方式解决这个问题。所以我非常感谢任何关于如何通过简单的问题解决这个问题的想法。

有没有办法将 mime4j 严格解析设置为 true 以实现 resteasy 而无需侵入和扩展 MultipartFormDataInputImpl？根据mime4j 0.8 javadoc，默认值为 false。我们想让它抛出一个异常而不是像默认给出的那样发出警告

公共无效 setStrictParsing（布尔严格解析）

定义是否应容忍轻微违反 MIME 规范或应导致 MimeException。如果此参数设置为 true，则将强制执行 MIME 规范的严格解释，如果此参数设置为 false，轻微违规将导致日志中出现警告。