通过的说，电子邮件导出后的文件格式就是.eml文件，比如使用outlook、163邮箱等等电子邮件程序将电子邮件导出后，就可以得到.eml文件，EML文件应该符合RFC 5322规范，这样EML文件就可以在不同的邮件客户端之间流通。
也就是说，使用163邮箱客户端导出的eml文件，完全可以在Ooutlook中『基本一致』的打开
之所以说基本一致，因为还是有很多兼容性问题要处理，而且很多邮箱客户端还有独有的私有协议内容，对应的样式在其他邮箱客户端只能以基本的样式进行展示
以163邮箱为例，如下图，将邮件导出，就得到了预约直播，听专家分享《面向大规模数据的云端管理，百度沧海·存储产品解析》.eml文件
使用邮箱大师，就可以将这个文件导入，并进行展示：
展示与原邮件基本是一致的
在我们的灵犀办公客户端上，也要实现这个导入EML文件的功能，这个功能有现成的库来支持，可选择的有三个库：
三个工具使用的解析的结果大同小异，我们选用的是MailParser（额外说一句，NodeMailer功能非常强大，可以用它构建一个自己的邮件收发系统）
按照文档很容易就能实现一个简单的EML解析器：
const fse = require('fs-extra');
const simpleParser = require('mailparser').simpleParser;
function parseEml(filePath) {
return fse.stat(filePath).then(() => {
return fse.readFile(filePath).then((file) => {
return simpleParser(file);
});
});
}
解析的结果包含了下面的字段：
在我们的系统中，根据这些属性，可以构造出一个完整的MailEntitiy结构，用于完成常规的服务端返回的邮件数据解析流程。到此解析就流程就完了。
当然不是，为了提高解析性能，我们还在客户端本地的数据库，使用文件地址和文件名称组合为key，在本地数据库记录了结果。当然这都是小优化，直到功能上线后，QA报了一个线上问题，有一封邮件，我们的客户端打开后，样式乱了，结果如下：
导入导服务端之后却是正常的
用邮箱大师也是正常的，那我们出了什么问题呢？
用MailParser解析之后，发现解析的结果里面，attachments是有值的，而html是false，text里面就是我们的客户端解析后的数据，并没有相应的内联样式：
一开始以为是参数的问题，一通调试后发现然并卵，后来以为是编码的问题，因为这封邮件的charset是gb2312，结果发现也没有用（虽然后面编码还是要处理的）
咨询了服务端的同学，他给出的答案一针见血，邮件的附件里面是不是有一个dat附件，需要对dat附件进行二次解析才可以
winmai.dat是Microsoft Outlook是特殊格式附件，如果Outlook寄出富文本格式的信件，其他邮件客户端收到的时候，就会产生这个文件。真正的内容和样式实际上都是在这个附件中。
所以需要对这个文件进行二次解析，在NPM上找到了node-tnef这个工具，使用它就可以解析winmai.dat附件。由于我们在解析eml文件时，附件已经是Buffer格式的数据了，所以直接使用tnef.parseBuffer这个方法就可以，得到的content里面包含了BodyHTML数据，把这个带有样式的富文本数据格式赋值给eml解析后的html字段（原本是false）就可以解析出正确的数据了
function handleDatAttachments(parsedMail, encoding) {
const datAttach = parsedMail.attachments.find(
(v) => v.contentType === 'application/ms-tnef' && v.filename && v.filename.endsWith('dat')
);
if (datAttach) {
return new