我们的程序经常会出现这样一个问题，在WinXp下测试是正常的，而到了服务器(Linux操作系统)上就出现这个问题。
1、 由于邮件我写的程序的邮件主题是写在配置文件(.
properties)中的，再通过native2ascii把中文邮件主题从本地码(简体中文Wind Xp 是GBK)转换为Unicode
编码。而Java程序读取properties配置文件内容时，是根据操作的编码方式来读取的，这样就造成程序的可移植性差。
2、 没有指定邮件主题的编码方式
当一段 Text 或者 HTML
通过电子邮件传送时，发送的内容首先通过一种指定的字符编码转化成“字节串”，然后再把“字节串”通过一种指定的传输编码(Content-
Transfer-Encoding)进行转化得到另一串“字节串”。比如，打开一封电子邮件源代码，可以看到类似的内容：
Content-Type: text/plain;charset="gb2312"
Content-Transfer-Encoding: base64
sbG+qcrQuqO17cf4yee74bGjz9W7+b3wudzA7dbQ0MQNCg0KvPKzxqO6uqO17cnnsaPW0NDEDQoNCg==
最
常用的 Content-Transfer-Encoding 有 Base64 和 Quoted-Printable
两种。在对二进制文件或者中文文本进行转化时，Base64 得到的“字节串”比 Quoted-Printable
更短。在对英文文本进行转化时，Quoted-Printable 得到的“字节串”比 Base64 更短。
邮件的标题，用了一种更简短的格式来标注“字符编码”和“传输编码”。比如，标题内容为 "中"，则在邮件源代码中表示为：
// 正确的标题格式
Subject: =?GB2312?B?1tA=?=
其中，
第一个“=?”与“?”中间的部分指定了字符编码，在这个例子中指定的是 GB2312。
“?”与“?”中间的“B”代表 Base64。如果是“Q”则代表 Quoted-Printable。
最后“?”与“?=”之间的部分，就是经过 GB2312 转化成字节串，再经过Base64 转化后的标题内容。
如果“传输编码”改为 Quoted-Printable，同样，如果标题内容为 "中"：
// 正确的标题格式
Subject: =?GB2312?Q?=D6=D0?=
如果阅读邮件时出现乱码，一般是因为“字符编码”或“传输编码”指定有误，或者是没有指定。比如，有的发邮件组件在发送邮件时，标题 "中"：
// 错误的标题格式
Subject: =?ISO-8859-1?Q?=D6=D0?=
这样的表示，实际上是明确指明了标题为 [0x00D6, 0x00D0]，即 "ÖÐ"，而不是 "中"。
3、 解决方法
(1)：修改操作系统编码方式为GBK，或在服务器上通过native2ascii把邮件主题重新生成Unicode 编码，并更新配置文件内容；
(2)：给邮件主题指定编码方式：
sun.misc.BASE64Encoder enc = new sun.misc.BASE64Encoder();
msg.setSubject("=?GB2312?B?"+enc.encode(subject.getBytes())+"?=");
建议：带有中文的配置文件，尽量不用*. properties文件，而用XML文件替代。
