我们一直坚持这个问题很长一段时间。在我们的项目中,我们正在尝试解析写入文件的电子邮件并将数据导入pojo。它适用于大多数情况,但是当电子邮件ID太长时,邮件ID会转到下一行,因为未提取起始地址而不是提取名称。我们正在使用 commons-email-1.4
包含emailmessage的输入文件有
情形1:
From: "def, abc [CCC-OT]" <abc.def@test.com> //here it fetches the mail id properly
如果邮件ID较长,则文件
情况2:
From: "defxacdhf, abc [CCC-OT]"
<abc.defxacdhf@test.com>// here the mail id jumps to the next line so the from address fetched contains the name
以下是示例代码
ByteArrayInputStream byteArrayStream = new ByteArrayInputStream(FileUtils.getStreamAsByteArray(buffInStream,
lengthOfFile));
// MimeMessage message = new MimeMessage(mailSession, byteArrayStream);
MimeMessageParser mimeParser = new MimeMessageParser(MimeMessageUtils.createMimeMessage(mailSession,
byteArrayStream));
MimeMessageParser parsedMessage = mimeParser.parse();
当我们尝试获取来自地址
时emailData.setFromAddress(parsedMessage.getFrom());
在case1中,它返回abc.def@test.com
,而case2则返回"defxacdhf, abc [CCC-OT]"
。感谢您的任何帮助。
编辑脚本文件读写如下。
while read line
do
echo "$line" >> /directory/$FILE_NAME
done
答案 0 :(得分:1)
如上所述:
这是不所使用的任何库中的错误,而是不符合RFC的输入。
引自RFC-822:
3.1.1。 LONG HEADER FIELDS
Each header field can be viewed as a single, logical line of ASCII characters, comprising a field-name and a field-body. For convenience, the field-body portion of this conceptual entity can be split into a multiple-line representation; this is called "folding". The general rule is that wherever there may be linear-white-space (NOT simply LWSP-chars), a CRLF immediately followed by AT LEAST one LWSP-char may instead be inserted.
答案 1 :(得分:1)
我不明白为什么你在使用shell循环来读取数据而不仅仅是使用cat或类似的东西,但问题在于你使用&#34; read&#34 ;。默认情况下,read将输入行拆分为字段,由shell IFS环境变量指定的字段分隔符分隔。忽略前导字段分隔符,因此当您读取以空格开头的行时,将忽略空格。
将您的循环更改为:
while IFS= read -r line
do
echo "$line" >> /directory/$FILE_NAME
done
在每次读取之前将IFS设置为空字符串,并指定&#34; raw&#34;读取,以使反斜杠字符不特殊。
但除非你在那个阅读循环中做其他事情,否则做起来会简单得多
cat > /directory/$FILE_NAME