现在位置: 首页 > Javamail
+0°
2009年10月23日 5.产品相关 ⁄ 共 457字 ⁄ 被围观 +
一直以来iOffice当中使用JavaMail来处理各种WebMail都是,在最早的代码基础上进行打补丁的方式进行修改。日前安排了人对这块进行代码重写。 最早的代码是建立在JavaMail1.2版本左右的,而目前JavaMail版本已经升级到1.4了,所以重构之后,代码还是发生了很大变化。 重构的效果是不错的,大部分邮件都可以正常,很好的读取。 但是有些垃圾邮件无法正常读取。 例如:某些垃圾邮件中 Header当中没有任何ContentType的信息,自然更加...
阅读全文
+0°
2009年09月19日 5.产品相关 ⁄ 共 536字 ⁄ 被围观 +
日本的一位技术者开发了一个处理Pop3邮件的JavaMail Provider。 相对于sun javamail 自带的pop3邮件功能,它能够支持本地存储,多邮件Folder等重要功能。 只是这位老兄自几年前以后就不再更新这个开源代码了。最近iOffice在升级支持 imap SSL, pop3 SSL协议的过程中,发现这个开源代码不支持pop3 SSL协议。 鉴于sun的简易pop3 javamail Provider太简单,简直无法用,于是搬动JerryHan来修改升级这部分代码以使得它支持pop3 SSL....
阅读全文
+0°
2009年05月27日 5.产品相关 ⁄ 共 622字 ⁄ 被围观 +
iOfficeV3在Win32 服务器上运行,WebMail模块的处理都是正确无误的,但是当iOffceV3运行在类似于iOffice网站这样的Linux环境(缺省编码是UTF-8)当中,浏览器去访问WebMail页面的时候,即便是Gb2312编码 的PlainText邮件也自动在iframe页面上显示为编码为UTF-8,不会根据 iframe当中 html的 content 编码设定为GBK/GB2312而变化. 这样在PC环境的IE浏览器上,只要在iFrame上点击右键强制转换编码到中文就可以了,但是在PDA浏览器...
阅读全文
+0°
2009年05月20日 5.产品相关 ⁄ 共 314字 ⁄ 被围观 +
iOffice的WebMail在处理一些日文邮件的特殊字符的时候,无法正常从Mail中取得并表示。 主要是这样的一些字符:①、②、③、㈱ 分析了很多可能的情况,作了很多容错恢复的尝试,仍旧无法解决。 最终看到网上有一份资料说 javamail.jar 当中关于 getContent()的处理,在内部做decode的时候,对这种依赖于机器的字符处理有缺陷,所以既然你得到的是一个已经发生错误的字串,那么再怎么处理也都是徒劳。 最后该文章指出唯一的出路就是 ...
阅读全文
+0°
2009年05月19日 5.产品相关 ⁄ 共 783字 ⁄ 被围观 +
总有一些邮件是比较独特的,只能够出现一种情况解决一个情况。 昨天发现一个日文邮件也出现附件的日文名称被分割为两段来编码, 而对于这种多段编码的解码,目前JavaMail1.4的库还不支持。 于是碰上一个就要写一段代码来自己分割成多段,分别解码对付解决, 如果能够有一段现成的库来对 字符串,按照“=?GB2312?B?|=?gb2312?b?|=?GB_2312-80?B?|....." 进行分割就好了。 今天又出现一个日文邮件,原始数据如下 Content-Type: mul...
阅读全文
+0°
2009年04月28日 5.产品相关 ⁄ 共 2158字 ⁄ 被围观 +
邮件附件进行保存的时候,不仅仅面临首先从邮件中正确解码问题,还有再次交给浏览器的时候,针对各种浏览器做各种正确编码的问题。 所以这里面有几个步骤 1)从邮件当中正确解码,表示出正确的文件名。 无论是中文文件名也好,日文文件名也好,总之也是要如同之前所说读取Subject一样,对GB2312进行GBK的转换处理。避免一些人把中文邮件添置了日文文件名的附件。 2)针对各个浏览器再次进行URLEncoding。要注意的是, Chrome,Saf...
阅读全文
+0°
2009年04月27日 5.产品相关 ⁄ 共 1042字 ⁄ 被围观 +
iOffice使用了JavaMail来提供基于Web页面的邮件收发功能。从理论上很简单,但是因为mail的发展历史足够长,所以各种Mail客户端之间还存在编码方式兼容的问题。不做一些特殊处理,看起来就会有一些乱码, 众多邮件客户程序当中,兼容性纠错性最好的当属OutLookExpress、OutLook了, 如果不能够做到很好的兼容性,容错性的话,客户使用起来,虽然90%的邮件表示正常,但是即便有10%的邮件无法正常表示,也会有不那么放心或者不那么...
阅读全文