如何使用正则匹配EML中符合RFC1341/RFC2045规范的完整Base64块

核心结论 #

可以通过正则实现跨整段的完整Base64块匹配，当前写出的正则存在逻辑缺陷，导致无法跨行捕获、还会出现误匹配。

现有正则的问题定位 #

当前使用的匹配规则为 ^(?:[a-zA-Z0-9+\/=-]{1,76}[\r|\n|\r\n]?)+，存在三处核心问题：

• 换行匹配逻辑错误：字符组[\r|\n|\r\n]的实际匹配范围是\r、\n、管道符|三个独立字符，而非兼容\r、\n、\r\n三种换行格式，不符合换行匹配的预期。
• 缺乏边界锚定：没有区分EML中Base64块和普通正文的前后分界，只要是字符符合规则、长度在1-76区间的文本行都会被纳入匹配范围，自然会误选不属于Base64块的内容。
• 匹配范围限制：在Notepad++默认的行处理模式下，未开启跨行全文档捕获能力，正则会逐行独立校验，无法把连续的Base64行串成完整块，因此只能定位到单条Base64行。

适配RFC1341、RFC2045规范的匹配逻辑调整 #

符合规范的EML Base64块具备固定结构特征，匹配时不能仅逐行校验Base64字符规则，需要锚定块的首尾边界：

• 前置边界锚定：Base64块一定出现在带有Content-Transfer-Encoding: base64声明的头字段之后，经过一个空行分隔才开始正式的Base64内容
• 内容规则校验：
  • 单行Base64内容长度上限为76字符，字符集严格限定为大小写英文字母、数字、+、/、末尾填充用的=
  • 行尾换行兼容\r\n、\r、\n三种格式
• 后置边界锚定：Base64块会在下一个MIME分界符、非Base64字符的正文行、文档结束位置终止，不会无限向下匹配非合规内容

内容的提问来源于stack exchange，提问作者mythofechelon