Warning: file_get_contents(/data/phpspider/zhask/data//catemap/9/java/340.json): failed to open stream: No such file or directory in /data/phpspider/zhask/libs/function.php on line 167

Warning: Invalid argument supplied for foreach() in /data/phpspider/zhask/libs/tag.function.php on line 1116

Notice: Undefined index: in /data/phpspider/zhask/libs/function.php on line 180

Warning: array_chunk() expects parameter 1 to be array, null given in /data/phpspider/zhask/libs/function.php on line 181
Java 解析电子邮件_Java_Email_Split_Mime4j - Fatal编程技术网

Java 解析电子邮件

Java 解析电子邮件,java,email,split,mime4j,Java,Email,Split,Mime4j,我正在尝试拆分邮件文件,如下所示: 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 #102715

我正在尝试拆分邮件文件,如下所示:

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.
我已经读过一些关于拆分邮件的帖子,似乎使用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创建的,如下所示:

Header
Body
Original message 1
Original message 2 
...
[LineReaderInputStreamAdaptor: [pos: 937][limit: 4096][
我不知道如何摆脱它

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


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

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

这里有一些资源给你


您可以从
流中获得外观奇怪的文本。getInputStream().toString()

toString()
方法主要用于调试。在
InputStream
上调用它不会得到流的内容(可能很多),而只是对该流的描述,这就是您看到的

要获取该流的数据,需要从输入流中读取数据并将其复制到输出流。有关执行此操作的各种方法,请参见

就原始邮件而言:您的示例是一封电子邮件。它只有一个MIME部分,即纯文本部分。人们只是复制了原始信息,然后把答案放在上面,在回复信息的上方

如果他们将消息作为附件转发,MIME结构将看起来不同:您将看到
内容类型:multipart/mixed;boundary=“…”
,然后该边界文本将分隔各个消息。也许apachejames会检测到它们并正确处理它们

MIME multipart用于附件或电子邮件的其他部分(纯文本与html)。它并不是指那些发布回复的人

由于您的示例电子邮件没有那种MIME结构,您最好的办法是手动解析电子邮件正文,查找原始消息--
。请注意,这是脆弱的(您不知道人们的邮件客户端可能会使用什么,人们可能会手动修改它(可能是偶然的)

import org.apache.james.mime4j.stream.*;
import static org.apache.james.mime4j.stream.MimeTokenStream.*;
import java.io.*;

public class Library {
    private static final String SEP = " -----Original Message-----";
    private static final String CRLF = "\r\n";

    static int fileNo = 0;

    public static void main(String[] args) throws Exception {
        MimeTokenStream stream = new MimeTokenStream();
        stream.parse(new FileInputStream(args[0]));
        try (BufferedWriter headerWriter = new BufferedWriter(new FileWriter("header"))) {
            for (EntityState state = stream.getState();
                    state != EntityState.T_END_OF_STREAM;
                    state = stream.next()) {
                switch (state) {
                case T_BODY:
                    writePart(new BufferedReader(new InputStreamReader(stream.getInputStream())));
                    break;
                case T_FIELD:
                    headerWriter.write(stream.getField().toString());
                    headerWriter.write(CRLF);
                    break;
                }
            }
        }
    }

    private static void writePart(BufferedReader in) throws Exception {
        BufferedWriter out = null;
        try {
            out = new BufferedWriter(new FileWriter(fileNo + ".eml"));
            String line = in.readLine();
            while (line != null) {
                if (SEP.equals(line)) {
                    out.close();
                    fileNo++;
                    out = new BufferedWriter(new FileWriter(fileNo + ".eml"));
                }
                out.write(line);
                out.write(CRLF);
                line = in.readLine();
            }
        }
        finally {
            out.close();
        }
    }
}