gpt4 book ai didi

java - 解析电子邮件

转载 作者:行者123 更新时间:2023-11-30 07:45:00 24 4
gpt4 key购买 nike

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

Message-ID: <53197.1075859003723.JavaMail.evans@thyme>
Date: Tue, 23 Oct 2001 10:31:09 -0700 (PDT)
From: scott.dozier@enron.com
To: tom.donohoe@enron.com, bonnie.chang@enron.com, m..love@enron.com
Subject: RE: CMS Deal #1027152
Cc: lisa.valderrama@enron.com, thomas.mcfatridge@enron.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Bcc: lisa.valderrama@enron.com, thomas.mcfatridge@enron.com
X-From: Dozier, Scott </O=ENRON/OU=NA/CN=RECIPIENTS/CN=SDOZIER>
X-To: Donohoe, Tom </O=ENRON/OU=NA/CN=RECIPIENTS/CN=Tdonoho>, Chang, Bonnie </O=ENRON/OU=NA/CN=RECIPIENTS/CN=Bchang>, Love, Phillip M. </O=ENRON/OU=NA/CN=RECIPIENTS/CN=Plove>
X-cc: Valderrama, Lisa </O=ENRON/OU=NA/CN=RECIPIENTS/CN=Lvalde2>, McFatridge, Thomas </O=ENRON/OU=NA/CN=RECIPIENTS/CN=Tmcfatri>
X-bcc:
X-Folder: \TDONOHO (Non-Privileged)\Inbox
X-Origin: Donohoe-T
X-FileName: TDONOHO (Non-Privileged).pst

I am not sure if they have confirmed either deal. However, deal #1034254 was never pathed by us, whereas 1027152 was. Therefore, nothing billed out under 1034254.

Bonnie - I am including you on this note in case you can add anything about the pathing of the two deals mentioned in this note. Niether CMS orgaination shows anything on Trunkline that matches this. We spoke briefly about this last week.

Phillip - I am including you in case you can add any clarity or determine who we did this deal(s) with.

Thank you,
Scott
5-7213

-----Original Message-----
From: Donohoe, Tom
Sent: Tuesday, October 23, 2001 12:02 PM
To: Dozier, Scott
Subject: RE: CMS Deal #1027152

if they are not confirming this deal are they confirming 1034254?

-----Original Message-----
From: Dozier, Scott
Sent: Tuesday, October 23, 2001 9:24 AM
To: Donohoe, Tom
Cc: Valderrama, Lisa; McFatridge, Thomas
Subject: RE: CMS Deal #1027152
Importance: High

Tom,

In contacting our scheduler and subsequently a CMS scheduler, neither CMS Field Services nor CMS Marketing, Services, and Trading are able to identify the deal. Currently, I am preparing to fax a copy of our confirmation on the deal to CMS Field Services, Again, it is not an executed copy, but I am assuming they may not have sent it back. Furthermore, the CMS Field Services scheduler has told me that they don't even schedule any Trunkline deals.

Considering all of this, I am assuming the worst - that unless we can provide a trader name etc. they will short pay on this deal. So, do you know who represented us with CMS on this deal any one that might know who their trader is or how this deal was booked? We are getting ready to settle for Sep prod so any help asap would be appreciated.

Scott
5-7213

-----Original Message-----
From: Dozier, Scott
Sent: Thursday, October 18, 2001 12:21 PM
To: Donohoe, Tom
Subject: RE: CMS Deal #1027152

They do not recognize that deal at all.

The most recent name and number is a Conoco trader. I have a confirmation on this deal with CMS. However, it is not an executed copy (i.e. sent back or confirmed by CMS). Is there some one who represented us with CMS on this that might know who their trader is or how this deal was booked? I will attempt to contact the scheduler in the mean time but any help would be good.

thanks.

在许多这样的文件中:

Header
Body
Original message 1
Original message 2
...

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

public class test {

public static void main(String[] args) throws IOException, MimeException {
// TODO Auto-generated method stub
MimeTokenStream stream = new MimeTokenStream();
stream.parse(new FileInputStream("test"));
File header = new File ("header");
File body = new File ("body");
BufferedWriter headerWriter = new BufferedWriter(new FileWriter(header));
BufferedWriter bodyWriter = new BufferedWriter(new FileWriter(body));
String str;
for (EntityState state = stream.getState();
state != EntityState.T_END_OF_STREAM;
state = stream.next()) {
switch (state) {
case T_BODY:
str = stream.getInputStream().toString();
bodyWriter.write(str);
break;
case T_FIELD:
str = stream.getField().toString() + "\n";
headerWriter.write(str);
break;
}
}
headerWriter.close();
bodyWriter.close();

}

}

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

但是,我遇到了两个问题:

1) 正文以明显由 Mime 创建的一行开始,看起来像这样:

[LineReaderInputStreamAdaptor: [pos: 937][limit: 4096][

我不知道如何摆脱它。

2)“原始消息”都在正文中。我不知道如何根据那些“原始消息”将 body 分成更多部分。而且,所有的邮件都没有这种格式。有时,原始消息仅通过制表符或每行前的 > 字符“显示”,或者仅通过小标题“from,to”或另一行如 ------forwarded----- --- 等...所以我不能使用格式拆分它。

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

最佳答案

在您的示例中,最后一个 header 之后的所有内容都是正文的一部分。电子邮件客户端对此有控制权(即 outlook 可能会添加原始消息分隔符,其他客户端可能会在其中添加缩进......这将根据客户端和/或语言设置而改变)因此您的解决方案很容易中断。检查内容类型。如果是纯文本,则需要扫描正文以确定其分段方式。 (原始消息 -- 不是 mime 边界。)然后您将应用不同的规则来拆分消息(请参阅下面的 outlook 资源)。您还需要支持多部分(因为嵌入式电子邮件可能会通过这种方式发送。)然后知道您可能根本没有内容 header 。

这里有一些资源给你

关于java - 解析电子邮件,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/52191444/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com