语源科技BlogJava-Java

MIME邮件面面观

java执著者 — Sat, 01 Dec 2007 08:36:00 GMT

Q 什么是MIME？什么是MIME邮件？

A MIME, 全称为“Multipurpose Internet Mail Extensions”, 比较确切的中文名称为“多用途互联网邮件扩展”。它是当前广泛应用的一种电子邮件技术规范，基本内容定义于RFC 2045-2049。

自然，MIME邮件就是符合MIME规范的电子邮件，或者说根据MIME规范编码而成的电子邮件。

在MIME出台之前，使用RFC 822只能发送基本的ASCII码文本信息，邮件内容如果要包括二进制文件、声音和动画等，实现起来非常困难。MIME提供了一种可以在邮件中附加多种不同编码文件的方法，弥补了原来的信息格式的不足。实际上不仅仅是邮件编码，现在MIME经成为HTTP协议标准的一个部分。

下面举几个MIME邮件的例子，让我们先对MIME编码的格式有个直观的印象。例1是最简单的，只带纯文本正文，基本上就是RFC 822格式；例2复杂一些，包含纯文本和超文本正文；例3是最复杂的，包含纯文本正文、超文本正文、内嵌资源和文件附件。其中，行号和行号后的空格是为了分析方便而另外加的，“... ... ... ...”表示此处省略了大段编码。

例1

   1 Date: Thu, 18 Apr 2002 09:32:45 +0800

2 From: 

3 To: 

4 Subject: Test

5 Mime-Version: 1.0

6 Content-Type: text/plain; charset="iso-8859-1"

7

8 This is a simple mail.

9

例2

   1 From: "bhw98" 

2 Reply-To: bhw98@sina.com

3 To: 

4 Subject: Re: help

5 X-Mailer: Foxmail 4.2 [cn]

6 Mime-Version: 1.0

7 Content-Type: multipart/alternative;

8  boundary="=====002_Dragon307572345230_====="

9

10

11 This is a multi-part message in MIME format.

12

13 --=====002_Dragon307572345230_=====

14 Content-Type: text/plain; charset="GB2312"

15 Content-Transfer-Encoding: quoted-printable

16

17 bluesky7810=A3=AC=C4=FA=BA=C3=A3=A1

18

19 =A1=A1=A1=A1=D4=DA=CF=C2=C6=AA=D7=EE=BA=F3=BF=C9=D2=D4=CF=C2=D4=D8=B0=A1=A3=AC=C4=E3

... ...  ... ...

30 =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A12003-04-07

31

32 --=====002_Dragon307572345230_=====

33 Content-Type: text/html; charset="GB2312"

34 Content-Transfer-Encoding: quoted-printable

35

36 

37 

38 
39  http-equiv=3DContent-Type>

40 

... ...  ... ...

79 

80

81 --=====002_Dragon307572345230_=====--

82

例3

   1 Return-Path: 

2 Delivered-To: bhw98@sina.com

3 Received: (qmail 75513 invoked by alias); 20 May 2002 02:19:53 -0000

4 Received: from unknown (HELO bluesky) (61.155.118.135)

5   by 202.106.187.143 with SMTP; 20 May 2002 02:19:53 -0000

6 Message-ID: <007f01c3111c$742fec00$0100007f@bluesky>

7 From: "=?gb2312?B?wLbAtrXEzOwNCg==?=" 

8 To: "bhw98" 

9 Cc: 

10 Subject: =?gb2312?B?ztK1xLbgtK6/2rPM0PI=?=

11 Date: Sat, 20 May 2002 10:03:36 +0800

12 MIME-Version: 1.0

13 Content-Type: multipart/mixed;

14    boundary="----=_NextPart_000_007A_01C3115F.80DFC5E0"

15 X-Priority: 3

16 X-MSMail-Priority: Normal

17 X-Mailer: Microsoft Outlook Express 5.00.2919.6700

18 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700

19

20 This is a multi-part message in MIME format.

21

22 ------=_NextPart_000_007A_01C3115F.80DFC5E0

23 Content-Type: multipart/related; type="multipart/alternative";

24     boundary="----=_NextPart_001_007B_01C3115F.80DFC5E0"

25

26

27 ------=_NextPart_001_007B_01C3115F.80DFC5E0

28 Content-Type: multipart/alternative;

29     boundary="----=_NextPart_002_007C_01C3115F.80DFC5E0"

30

31 ------=_NextPart_002_007C_01C3115F.80DFC5E0

32 Content-Type: text/plain; charset="gb2312"

33 Content-Transfer-Encoding: quoted-printable

34

35 bhw98, =C4=E3=BA=C3!

36 =D5=E2=CA=C7=CE=D2=D0=B4=B5=C4=B6=E0=B4=AE=BF=DA=CD=A8=D0=C5=B5=C4=B3=CC=D0=

37 =F2, =C7=EB=D6=B8=BD=CC!

38

39

40 ------=_NextPart_002_007C_01C3115F.80DFC5E0

41 Content-Type: text/html; charset="gb2312"

42 Content-Transfer-Encoding: quoted-printable

43

44 

45 =C7=E7=C0=CA

46 

47 

52 

53 
54 bgColor=3D#ffffff>

55 

56 bhw98, =C4=E3=BA=C3!


57 =D5=E2=CA=C7=CE=D2=D0=B4=B5=C4=B6=E0=B4=AE=BF=DA=CD=A8=D0=C5=B5=C4=B3=CC=

58 =D0=F2, =C7=EB=D6=B8=BD=CC!


59  


60

61 ------=_NextPart_002_007C_01C3115F.80DFC5E0--

62

63 ------=_NextPart_001_007B_01C3115F.80DFC5E0

64 Content-Type: image/jpeg; name="=?gb2312?B?x+fAyrGzvrAuSlBH?="

65 Content-Transfer-Encoding: base64

66 Content-ID: <007901c3111c$72b978a0$0100007f@bluesky>

67

68 /9j/4AAQSkZJRgABAgEASABIAAD/7QVoUGhvdG9zaG9wIDMuMAA4QklNA+0AAAAAABAASAAAAAEA

69 AQBIAAAAAQABOEJJTQPzAAAAAAAIAAAAAAAAAAA4QklNBAoAAAAAAAEAADhCSU0nEAAAAAAACgAB

70 AAAAAAAAAAI4QklNA/UAAAAAAEgAL2ZmAAEAbGZmAAYAAAAAAAEAL2ZmAAEAoZmaAAYAAAAAAAEA

... ...  ... ...

169 RxVw98Vawq12xQ44q0cKtHFDWKGsKt4EtiuKt4q//9k=

170

171 ------=_NextPart_001_007B_01C3115F.80DFC5E0--

172

173 ------=_NextPart_000_007A_01C3115F.80DFC5E0

174 Content-Type: application/msword; name="readme.doc"

175 Content-Transfer-Encoding: base64

176 Content-Disposition: attachment; filename="readme.doc"

177

178 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAJgAAAAAAAAAA

179 EAAAKAAAAAEAAAD+////AAAAACUAAAD/////////////////////////////////////////////

180 ////////////////////////////////////////////////////////////////////////////

... ...  ... ...

1688 AAAAAAAAAAAAAAAAAAA=

1689

1690 ------=_NextPart_000_007A_01C3115F.80DFC5E0

1691 Content-Type: application/x-zip-compressed;

1692     name="=?gb2312?B?tuC0rr/azajQxbXE1LTC6y56aXA=?="

1693 Content-Transfer-Encoding: base64

1694 Content-Disposition: attachment;

1695     filename="=?gb2312?B?tuC0rr/azajQxbXE1LTC6y56aXA=?="

1696

1697 UEsDBBQAAAAIAFKAoi7qOMOvLw0AAABWAAAUAAAAtuC0rr/azajQxbXE1LTC6y5kb2PtXHtwVNUZ

1698 /+4+kk3IQoAkBkRYQkSgbrKb7IYNEMwmm6ckG0jCI0boZneTbJJ9sNlAEsdOtFqd8Z846tQ6PhB1

1699 hrZTJoK0Vhgf1aGt4rMy6D8tdugfTjuOpcBIR9j+vvsIy4YkRNTRen87v/ud53cee+6557vn7L73

... ...  ... ...

3125 zajQxbXE1LTC6y5kb2NQSwUGAAAAAAEAAQBCAAAAYQ0AAA==

3126

3127 ------=_NextPart_000_007A_01C3115F.80DFC5E0--

3128

Q 在开始研究MIME邮件的时候，如何得到这样的源码？

A 一些功能比较完善的邮件客户端软件，如微软的Outlook Express，国产的Foxmail等，都提供了查看和保存邮件源码(原始信息)的功能。在Foxmail中，选择邮件列表右键菜单的“原始信息”进行查看，主菜单的“文件-导出”进行保存。在Outlook Express中，对应的操作分别是“属性”和“另存为”。所保存的.eml文件，可以调用这些程序打开。

Q 请介绍一下MIME邮件的组成？

A 总体来说，MIME消息由消息头和消息体两大部分组成。现在我们关注的是MIME邮件，因此在以下的讨论中姑且称“消息”为“邮件”。在上面的例子中，例 1的1-6行，例2的1—8行，例3的1-18行，是邮件头；例1的8—9行，例2的10—82行，例3的20—3128行，是邮件体。邮件头与邮件体之间以空行进行分隔，如例1的第7行，例2的第9行，例3的第19行。邮件头中不允许出现空行。有一些邮件不能被邮件客户端软件识别，显示的是原始码，就是因为首行是空行。

邮件头包含了发件人、收件人、主题、时间、MIME版本、邮件内容的类型等重要信息。每条信息称为一个域，由域名后加“: ”和信息内容构成，可以是一行，较长的也可以占用多行。域的首行必须“顶头”写，即左边不能有空白字符（空格和制表符）；续行则必须以空白字符打头，且第一个空白字符不是信息本身固有的，解码时要过滤掉。如例2的7-8行，例3的4-5行，13-14行，分别属于一个域。

邮件体包含邮件的内容，它的类型由邮件头的“Content-Type”域指出。常见的简单类型有text/plain(纯文本)和text/html(超文本)。

例2和例3中出现的multipart类型，是MIME邮件的精髓。邮件体被分为多个段，每个段又包含段头和段体两部分，这两部分之间也以空行分隔。常见的multipart类型有三种：multipart/mixed, multipart/related和multipart/alternative。从它们的名称，不难推知这些类型各自的含义和用处。它们之间的层次关系可归纳为下图所示：

+------------------------- multipart/mixed ----------------------------+

|                                                                      |

|  +----------------- multipart/related ------------------+            |

|  |                                                      |            |

|  |  +----- multipart/alternative ------+  +----------+  |  +------+  |

|  |  |                                  |  | 内嵌资源 |  |  | 附件 |  |

|  |  |  +------------+  +------------+  |  +----------+  |  +------+  |

|  |  |  | 纯文本正文 |  | 超文本正文 |  |                |            |

|  |  |  +------------+  +------------+  |  +----------+  |  +------+  |

|  |  |                                  |  | 内嵌资源 |  |  | 附件 |  |

|  |  +----------------------------------+  +----------+  |  +------+  |

|  |                                                      |            |

|  +------------------------------------------------------+            |

|                                                                      |

+----------------------------------------------------------------------+

可以看出，如果在邮件中要添加附件，必须定义multipart/mixed段；如果存在内嵌资源，至少要定义 multipart/related段；如果纯文本与超文本共存，至少要定义multipart/alternative段。什么是“至少”？举个例子说，如果只有纯文本与超文本正文，那么在邮件头中将类型扩大化，定义为multipart/related，甚至multipart/mixed，都是允许的。

multipart诸类型的共同特征是，在段头指定“boundary”参数字符串，段体内的每个子段以此串定界。所有的子段都以“--”+boundary行开始，父段则以“--”+boundary+“--”行结束。段与段之间也以空行分隔。在邮件体是 multipart类型的情况下，邮件体的开始部分(第一个“--”+boundary行之前)可以有一些附加的文本行，相当于注释，解码时应忽略。段间也可以有一些附加的文本行，不会显示出来，如果有兴趣，不妨验证一下。

结合boundary定界和multipart层次关系图，我们分析一下例2和例3的邮件体层次与段嵌套关系。

在例2中，10-12行是附加文本行，13-82行是multipart/alternative型的段，包含两个子段：13-30行是纯文本正文，32-79行是超文本正文。

在例3中，20-21行是附加文本行，22-3127行是multipart/mixed型的段，包含3个子段：22-171行是multipart/related段，173-1688行与1690-3125行是两个附件。multipart/related 段又包含两个子段：27-61行是multipart/alternative段，63-169行是一个内嵌资源(图片)。 multipart/alternative段又包含两个子段：31-48行是纯文本正文，40-59行是超文本正文。

例1只有纯文本正文，实际上属于multipart层次关系图中的一个特殊情况。如果非要避简就繁，写成下面的形式，也是完全符合MIME精神的。

Date: Thu, 18 Apr 2002 09:32:45 +0800

From: 

To: 

Subject: Test

Mime-Version: 1.0

Content-Type: multipart/alternative; boundary="{[(^_^)]}"



--{[(^_^)]}

Content-Type: text/plain; charset="iso-8859-1"

Content-Transfer-Encoding: 7bit



This is a simple mail.



--{[(^_^)]}--

Q 在邮件头和段头中，有哪一些常见的域？

A 在邮件头中，有很多从RFC 822沿用的域名，MIME也增加了一些。常见的标准域名和含义如下

域名	含义	添加者
Received	传输路径	各级邮件服务器
Return-Path	回复地址	目标邮件服务器
Delivered-To	发送地址	目标邮件服务器
Reply-To	回复地址	邮件的创建者
From	发件人地址	邮件的创建者
To	收件人地址	邮件的创建者
Cc	抄送地址	邮件的创建者
Bcc	暗送地址	邮件的创建者
Date	日期和时间	邮件的创建者
Subject	主题	邮件的创建者
Message-ID	消息ID	邮件的创建者
MIME-Version	MIME版本	邮件的创建者
Content-Type	内容的类型	邮件的创建者
Content-Transfer-Encoding	内容的传输编码方式	邮件的创建者

非标准的、自定义域名都以X-开头，例如X-Mailer, X-MSMail-Priority等，通常在接收和发送邮件的是同一程序时才能理解它们的意义。

在段头中，大致有如下一些域

域名	含义
Content-Type	段体的类型
Content-Transfer-Encoding	段体的传输编码方式
Content-Disposition	段体的安排方式
Content-ID	段体的ID
Content-Location	段体的位置(路径)
Content-Base	段体的基位置

有的域除了值之外，还带有参数。值与参数、参数与参数之间以“;”分隔。参数名与参数值之间以“=”分隔。如例3的28-29行，Content-Type域的值为“multipart/alternative”，此外有一个参数boundary，值为"--- -=_NextPart_002_007C_01C3115F.80DFC5E0"。又如例3的第176行，Content-Disposition域的值为“attachment”，此外有一个参数filename，值为“readme.doc”。

Q Content-Type以及它们的参数有哪些形式？

A Content-Type都是“主类型/子类型”的形式。主类型有text, image, audio, video, application, multipart, message等，分别表示文本、图片、音频、视频、应用、分段、消息等。每个主类型都可能有多个子类型，如text类型就包含plain, html, xml, css等子类型。以X-开头的主类型和子类型，同样表示自定义的类型，未向IANA正式注册，但大多已经约定成俗了。如application/x- zip-compressed是ZIP文件类型。在Windows中，注册表的“HKEY_CLASSES_ROOT\MIME\Database\ Content Type”内列举了除multipart之外大部分已知的Content-Type。

关于参数的形式，RFC里有很多补充规定，有的允许带几个参数，较为常见的有

主类型	参数名	含义
text	charset	字符集
image	name	名称
application	name	名称
multipart	boundary	边界

其中字符集也能在Windows注册表的“HKEY_CLASSES_ROOT\MIME\Database\Charset”内见到。

Q Content-Transfer-Encoding有哪些？有什么特点？

A Content-Transfer-Encoding共有Base64, Quoted-printable, 7bit, 8bit, Binary等几种。其中7bit是缺省的编码方式。电子邮件源码最初设计为全部是可打印的ASCII码的形式。非ASCII码的文本或数据要编码成要求的格式，如上面的三个例子。Base64, Quoted-Printable是在非英语国家使用最广使的编码方式。Binary方式只具有象征意义，而没有任何实用价值。

Base64将输入的字符串或一段数据编码成只含有{'A'-'Z', 'a'-'z', '0'-'9', '+', '/'}这64个字符的串，'='用于填充。其编码的方法是，将输入数据流每次取6 bit，用此6 bit的值(0-63)作为索引去查表，输出相应字符。这样，每3个字节将编码为4个字符(3×8 → 4×6)；不满4个字符的以'='填充。有的场合，以“=?charset?B?xxxxxxxx?=”表示xxxxxxxx是Base64编码，且原文的字符集是charset。如例3第7行"=?gb2312?B?wLbAtrXEzOwNCg==?="是由简体中文“蓝蓝的天”编码而成的。在段体内则直接编码，适当时机换行，MIME建议每行最多76个字符。如例3的1697-3125行，是一个ZIP文件的Base64编码。

Quoted-printable根据输入的字符串或字节范围进行编码，若是不需编码的字符，直接输出；若需要编码，则先输出'='，后面跟着以2个字符表示的十六进制字节值。有的场合，以“=?charset?Q?xxxxxxxx?=”表示 xxxxxxxx是Quoted-printable编码，且原文的字符集是charset。在段体内则直接编码，适当时机换行，换行前额外输出一个'= '。如例3的44-59行，是HTML文本的Quoted-printable编码。其中第45行“=C7=E7=C0=CA”原文是“晴朗”，因为 “晴”的GB2312码是C7E7，“朗”的GB2312码是C0CA。第48、53、57行末尾只有孤零零的'='，表示这是由编码造成的软回车，而非原文固有的。

近年来，国内多数邮件服务器已经支持8bit方式，因此只在国内传输的邮件，特别是在邮件头中，可直接使用8bit编码，对汉字不做处理。如果邮件要出国，还是老老实实地按Base64或Quoted-printable编码才行。

Q 什么是内嵌资源？它有哪些形式？

A 内嵌资源也是MIME的一个发光点，它能使邮件内容变得生动活泼、丰富多彩。可在邮件的multipart/related框架内定义一些与正文关联的图片、动画、声音甚至CSS样式和脚本的段。通常在HTML正文内，使用超级链接与内嵌资源相联系。如在例3中，HTML正文53-54行，解码后为

它指出用一个Content-ID为007901c3111c$72b978a0$0100007f@bluesky的图片作为背景(cid:xxxxxxxx也是一种超级链接)。而64-169行恰好就是这样一个内嵌资源。

除了用Content-ID进行联系外，还有另外一种常用形式：用普通超级连接和Content-Location。例如：

在HTML正文中，

... ...  ... ...



... ...  ... ...



... ...  ... ...

对应的内嵌资源为

Content-Type: image/gif; name="anti_joyo_dm_book.gif"

Content-Transfer-Encoding: base64

Content-Location: http://www.dangdang.com/images/all/anti_joyo_dm_book.gif

... ... ... ...

Content-Type: application/octet-stream; name="getimage_small.asp?id=486341"

Content-Transfer-Encoding: base64

Content-Location: http://www.dangdang.com/dd2001/getimage_small.asp?id=486341

... ... ... ...

另外，

Content-Location: http://www.dangdang.com/images/all/anti_joyo_dm_book.gif

与

Content-Location: anti_joyo_dm_book.gif

Content-Base: http://www.dangdang.com/images/all/

是等效的。

Q 邮件病毒如何利用附件和内嵌资源传播？

A 有的邮件附件可能带有病毒，容易理解。附件毕竟是文件，也好预防，不轻易打开就是了。但内嵌资源是在浏览邮件内容时就要访问的，若其中藏有病毒或恶意代码，你在不知不觉中就中招了。如前两年曾经在全球范围内流行的Nimda病毒，功能性源码如下：

MIME-Version: 1.0

Content-Type: multipart/related;

type="multipart/alternative";

boundary="====_ABC1234567890DEF_===="



--====_ABC1234567890DEF_====

Content-Type: multipart/alternative;

boundary="====_ABC0987654321DEF_===="



--====_ABC0987654321DEF_====

Content-Type: text/html;

charset="iso-8859-1"

Content-Transfer-Encoding: 7bit









--====_ABC0987654321DEF_====--



--====_ABC1234567890DEF_====

Content-Type: audio/x-wav; name="readme.exe"

Content-Transfer-Encoding: base64

Content-ID: 



TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAA2AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v

ZGUuDQ0KJAAAAAAAAAA11CFvcbVPPHG1TzxxtU88E6pcPHW1TzyZqkU8dbVPPJmqSzxytU88cbVO

... ...  ... ...  ... ...  ... ...

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=



--====_ABC1234567890DEF_====

它将一个可执行文件作为资源嵌入了框架型页面，却声明这段可执行代码是波形声音类型。由于当时微软的IE(版本5.0 及以下)存在重大安全漏洞，没有检查Content-Type与name的扩展名是否匹配，于是就被轻易骗过了，致使点选或打开邮件时自动运行了这个 “readme.exe”，机器就感染上病毒。带毒的机器利用地址簿向别人发送带毒的邮件，一传十，十传百，Nimda蠕虫大行其道。

纵观历史，病毒刚出来时是厉害，但没有任何一种能够持续肆虐下去。Nimda如此，SARS亦当如此。曰：“多难兴邦，众志成城”，又曰：“非典终将倒下，城市精神永存”，相信我们定能很快战胜“非典”!

病毒库升级是跟在新病毒屁股后进行的，不要过分依赖杀毒软件。一个良好的习惯是关闭邮件预览功能，或者设定预览纯文本部分，先查看邮件源码，确信排除病毒嫌疑后再打开。对陌生人发来的带超文本正文的邮件，尤其要当心。永远不要在邮件客户端软件内直接打开附件。

Q 一些垃圾邮件采取隐藏发件人的方式，如何追查它们来自哪里？

A 从上面的邮件头域名表中可以看出，邮件的创建者可以掌握大部分的域的内容，但Received等域由各级服务器自动添加，发件人是鞭长莫及。垃圾邮件一般采用了群发软件发送，邮件头的From域(发件人地址)可以任意伪造，甚至写成收件人地址(收到了自己并没有发过的垃圾邮件，气愤吧？)。查看 Received域(传输路径)链可以找到真正的出处。每个服务器添加的Received语句都在邮件首，故最下面一个Received就包含了发件人所用的SMTP或HTTP服务器，及最初的网关外部IP地址。

Receive语句的基本格式是：from A by B。A为发送方，B为接收方。例如：

Received: (qmail 45304 invoked from network); 4 May 2003 17:05:47 -0000

Received: from unknown (HELO bjapp9.163.net) (202.108.255.197)

by 202.106.182.244 with SMTP; 4 May 2003 17:05:47 -0000

Received: from localhost (localhost [127.0.0.1])

by bjapp9.163.net (Postfix) with SMTP id E1C761D84C631

for ; Mon,  5 May 2003 01:07:26 +0800 (CST)

Received: from fanyingxxxx@tom.com (unknown [211.99.162.194])

by bjapp9.163.net (Coremail) with SMTP id OgEAAM1ItT7MNaLC.1

for ; Mon, 05 May 2003 01:07:26 +0800 (CST)

从上面的例子中不难看出，该邮件的传输路径是：211.99.162.194 → bjapp9.163.net (Coremail 202.108.255.197?) → bjapp9.163.net (Postfix, 202.108.255.197?) → 202.106.182.244。恰好出现了发件人邮箱fanyingxxxx@tom.com，但多数情况不一定能列出来。

此例的localhost [127.0.0.1]，意味着bjapp9.163.net上安装了邮件服务代理性质的软件。

java执著者 2007-12-01 16:36 发表评论

[转]Java/J2EE中文问题终极解决之道

java执著者 — Thu, 20 Sep 2007 03:07:00 GMT

Java中文问题一直困扰着很多初学者，如果了解了Java系统的中文问题原理，我们就可以对中文问题能够采取根本的解决之道。

　　最古老的解决方案是使用String的字节码转换，这种方案问题是不方便，我们需要破坏对象封装性，进行字节码转换。

　　还有一种方式是对J2EE容器进行编码设置，如果J2EE应用系统脱离该容器，则会发生乱码，而且指定容器配置不符合J2EE应用和容器分离的原则。

在Java内部运算中，涉及到的所有字符串都会被转化为UTF-8编码来进行运算。那么，在被Java转化之前，字符串是什么样的字符集？ Java总是根据操作系统的默认编码字符集来决定字符串的初始编码，而且Java系统的输入和输出的都是采取操作系统的默认编码。

　　因此，如果能统一Java系统的输入、输出和操作系统3者的编码字符集合，将能够使Java系统正确处理和显示汉字。这是处理Java系统汉字的一个原则，但是在实际项目中，能够正确抓住和控制住Java系统的输入和输出部分是比较难的。J2EE中，由于涉及到外部浏览器和数据库等，所以中文问题乱码显得非常突出。

　　J2EE应用程序是运行在J2EE容器中。在这个系统中，输入途径有很多种：一种是通过页面表单打包成请求（request）发往服务器的；第二种是通过数据库读入；还有第3种输入比较复杂，JSP在第一次运行时总是被编译成Servlet，JSP中常常包含中文字符，那么编译使用javac时，Java将根据默认的操作系统编码作为初始编码。除非特别指定，如在Jbuilder/eclipse中可以指定默认的字符集。

　　输出途径也有几种：第一种是JSP页面的输出。由于JSP页面已经被编译成Servlet，那么在输出时，也将根据操作系统的默认编码来选择输出编码，除非指定输出编码方式；还有输出途径是数据库，将字符串输出到数据库。

　　由此看来，一个J2EE系统的输入输出是非常复杂，而且是动态变化的，而Java是跨平台运行的，在实际编译和运行中，都可能涉及到不同的操作系统，如果任由Java自由根据操作系统来决定输入输出的编码字符集，这将不可控制地出现乱码。

　　正是由于Java的跨平台特性，使得字符集问题必须由具体系统来统一解决，所以在一个Java应用系统中，解决中文乱码的根本办法是明确指定整个应用系统统一字符集。

　　指定统一字符集时，到底是指定ISO8859_1 、GBK还是UTF-8呢？

　　（1）如统一指定为ISO8859_1，因为目前大多数软件都是西方人编制的，他们默认的字符集就是ISO8859_1，包括操作系统Linux和数据库MySQL等。这样，如果指定Jive统一编码为ISO8859_1，那么就有下面3个环节必须把握：

　　开发和编译代码时指定字符集为ISO8859_1。

　　运行操作系统的默认编码必须是ISO8859_1，如Linux。

　　在JSP头部声明：<%@ page contentType="text/html;charset=ISO8859_1" %>。

　　（2）如果统一指定为GBK中文字符集，上述3个环节同样需要做到，不同的是只能运行在默认编码为GBK的操作系统，如中文Windows。

　　统一编码为ISO8859_1和GBK虽然带来编制代码的方便，但是各自只能在相应的操作系统上运行。但是也破坏了Java跨平台运行的优越性，只在一定范围内行得通。例如，为了使得GBK编码在linux上运行，设置Linux编码为GBK。

　　那么有没有一种除了应用系统以外不需要进行任何附加设置的中文编码根本解决方案呢？

　　将Java/J2EE系统的统一编码定义为UTF-8。UTF-8编码是一种兼容所有语言的编码方式，惟一比较麻烦的就是要找到应用系统的所有出入口，然后使用UTF-8去“结扎”它。

　　一个J2EE应用系统需要做下列几步工作：

开发和编译代码时指定字符集为UTF-8。JBuilder和Eclipse都可以在项目属性中设置。
使用过滤器，如果所有请求都经过一个Servlet控制分配器，那么使用Servlet的filter执行语句，将所有来自浏览器的请求（request）转换为UTF-8，因为浏览器发过来的请求包根据浏览器所在的操作系统编码，可能是各种形式编码。关键一句：
request.setCharacterEncoding("UTF-8")。
网上有此filter的源码，Jdon框架源码中com.jdon.util.SetCharacterEncodingFilter
需要配置web.xml 激活该Filter。
在JSP头部声明：<%@ page contentType="text/html;charset= UTF-8" %>。
在Jsp的html代码中，声明UTF-8:
设定数据库连接方式是UTF-8。例如连接MYSQL时配置URL如下：
jdbc:mysql://localhost:3306/test?useUnicode=true&characterEncoding=UTF-8
注意，上述写法是JBoss的mysql-ds.xml写法，多亏网友提示，在tomcat中&要写成&即可。一般其他数据库都可以通过管理设置设定UTF-8
其他和外界交互时能够设定编码时就设定UTF-8，例如读取文件，操作XML等。

笔者以前在Jsp/Servlet时就采取这个原则，后来使用Struts、Tapestry、EJB、Hibernate、Jdon等框架时，从未被乱码困扰过，可以说适合各种架构。希望本方案供更多初学者分享，减少Java/J2EE的第一个拦路虎，也避免因为采取一些临时解决方案，导致中文问题一直出现在新的技术架构中

java执著者 2007-09-20 11:07 发表评论

[转载]Session详解

java执著者 — Tue, 19 Sep 2006 06:35:00 GMT

标题：Session详解

[评论]

作者：郎云鹏（dev2dev ID: hippiewolf）

摘要：虽然session机制在web应用程序中被采用已经很长时间了，但是仍然有很多人不清楚session机制的本质，以至不能正确的应用这一技术。本文将详细讨论session的工作机制并且对在Java web application中应用session机制时常见的问题作出解答。

目录：
一、术语session
二、HTTP协议与状态保持
 三、理解cookie机制
 四、理解session机制
 五、理解javax.servlet.http.HttpSession
六、HttpSession常见问题
 七、跨应用程序的session共享
 八、总结
 参考文档

一、术语session
在我的经验里，session这个词被滥用的程度大概仅次于transaction，更加有趣的是transaction与session在某些语境下的含义是相同的。

session，中文经常翻译为会话，其本来的含义是指有始有终的一系列动作/消息，比如打电话时从拿起电话拨号到挂断电话这中间的一系列过程可以称之为一个session。有时候我们可以看到这样的话“在一个浏览器会话期间，...”，这里的会话一词用的就是其本义，是指从一个浏览器窗口打开到关闭这个期间①。最混乱的是“用户（客户端）在一次会话期间”这样一句话，它可能指用户的一系列动作（一般情况下是同某个具体目的相关的一系列动作，比如从登录到选购商品到结账登出这样一个网上购物的过程，有时候也被称为一个transaction），然而有时候也可能仅仅是指一次连接，也有可能是指含义①，其中的差别只能靠上下文来推断②。

然而当session一词与网络协议相关联时，它又往往隐含了“面向连接”和/或“保持状态”这样两个含义，“面向连接”指的是在通信双方在通信之前要先建立一个通信的渠道，比如打电话，直到对方接了电话通信才能开始，与此相对的是写信，在你把信发出去的时候你并不能确认对方的地址是否正确，通信渠道不一定能建立，但对发信人来说，通信已经开始了。“保持状态”则是指通信的一方能够把一系列的消息关联起来，使得消息之间可以互相依赖，比如一个服务员能够认出再次光临的老顾客并且记得上次这个顾客还欠店里一块钱。这一类的例子有“一个TCP session”或者“一个POP3 session”③。

而到了web服务器蓬勃发展的时代，session在web开发语境下的语义又有了新的扩展，它的含义是指一类用来在客户端与服务器之间保持状态的解决方案④。有时候session也用来指这种解决方案的存储结构，如“把xxx保存在session里”⑤。由于各种用于web开发的语言在一定程度上都提供了对这种解决方案的支持，所以在某种特定语言的语境下，session也被用来指代该语言的解决方案，比如经常把Java里提供的javax.servlet.http.HttpSession简称为session⑥。

鉴于这种混乱已不可改变，本文中session一词的运用也会根据上下文有不同的含义，请大家注意分辨。
在本文中，使用中文“浏览器会话期间”来表达含义①，使用“session机制”来表达含义④，使用“session”表达含义⑤，使用具体的“HttpSession”来表达含义⑥

二、HTTP协议与状态保持
HTTP协议本身是无状态的，这与HTTP协议本来的目的是相符的，客户端只需要简单的向服务器请求下载某些文件，无论是客户端还是服务器都没有必要纪录彼此过去的行为，每一次请求之间都是独立的，好比一个顾客和一个自动售货机或者一个普通的（非会员制）大卖场之间的关系一样。

然而聪明（或者贪心？）的人们很快发现如果能够提供一些按需生成的动态信息会使web变得更加有用，就像给有线电视加上点播功能一样。这种需求一方面迫使HTML逐步添加了表单、脚本、DOM等客户端行为，另一方面在服务器端则出现了CGI规范以响应客户端的动态请求，作为传输载体的HTTP协议也添加了文件上载、cookie这些特性。其中cookie的作用就是为了解决HTTP协议无状态的缺陷所作出的努力。至于后来出现的session机制则是又一种在客户端与服务器之间保持状态的解决方案。

让我们用几个例子来描述一下cookie和session机制之间的区别与联系。笔者曾经常去的一家咖啡店有喝5杯咖啡免费赠一杯咖啡的优惠，然而一次性消费5杯咖啡的机会微乎其微，这时就需要某种方式来纪录某位顾客的消费数量。想象一下其实也无外乎下面的几种方案：
1、该店的店员很厉害，能记住每位顾客的消费数量，只要顾客一走进咖啡店，店员就知道该怎么对待了。这种做法就是协议本身支持状态。
2、发给顾客一张卡片，上面记录着消费的数量，一般还有个有效期限。每次消费时，如果顾客出示这张卡片，则此次消费就会与以前或以后的消费相联系起来。这种做法就是在客户端保持状态。
3、发给顾客一张会员卡，除了卡号之外什么信息也不纪录，每次消费时，如果顾客出示该卡片，则店员在店里的纪录本上找到这个卡号对应的纪录添加一些消费信息。这种做法就是在服务器端保持状态。

由于HTTP协议是无状态的，而出于种种考虑也不希望使之成为有状态的，因此，后面两种方案就成为现实的选择。具体来说cookie机制采用的是在客户端保持状态的方案，而session机制采用的是在服务器端保持状态的方案。同时我们也看到，由于采用服务器端保持状态的方案在客户端也需要保存一个标识，所以session机制可能需要借助于cookie机制来达到保存标识的目的，但实际上它还有其他选择。

三、理解cookie机制
cookie机制的基本原理就如上面的例子一样简单，但是还有几个问题需要解决：“会员卡”如何分发；“会员卡”的内容；以及客户如何使用“会员卡”。

正统的cookie分发是通过扩展HTTP协议来实现的，服务器通过在HTTP的响应头中加上一行特殊的指示以提示浏览器按照指示生成相应的cookie。然而纯粹的客户端脚本如JavaScript或者VBScript也可以生成cookie。

而cookie的使用是由浏览器按照一定的原则在后台自动发送给服务器的。浏览器检查所有存储的cookie，如果某个cookie所声明的作用范围大于等于将要请求的资源所在的位置，则把该cookie附在请求资源的HTTP请求头上发送给服务器。意思是麦当劳的会员卡只能在麦当劳的店里出示，如果某家分店还发行了自己的会员卡，那么进这家店的时候除了要出示麦当劳的会员卡，还要出示这家店的会员卡。

cookie的内容主要包括：名字，值，过期时间，路径和域。
其中域可以指定某一个域比如.google.com，相当于总店招牌，比如宝洁公司，也可以指定一个域下的具体某台机器比如www.google.com或者froogle.google.com，可以用飘柔来做比。
路径就是跟在域名后面的URL路径，比如/或者/foo等等，可以用某飘柔专柜做比。
路径与域合在一起就构成了cookie的作用范围。
如果不设置过期时间，则表示这个cookie的生命期为浏览器会话期间，只要关闭浏览器窗口，cookie就消失了。这种生命期为浏览器会话期的cookie被称为会话cookie。会话cookie一般不存储在硬盘上而是保存在内存里，当然这种行为并不是规范规定的。如果设置了过期时间，浏览器就会把cookie保存到硬盘上，关闭后再次打开浏览器，这些cookie仍然有效直到超过设定的过期时间。

存储在硬盘上的cookie可以在不同的浏览器进程间共享，比如两个IE窗口。而对于保存在内存里的cookie，不同的浏览器有不同的处理方式。对于IE，在一个打开的窗口上按Ctrl-N（或者从文件菜单）打开的窗口可以与原窗口共享，而使用其他方式新开的IE进程则不能共享已经打开的窗口的内存cookie；对于Mozilla Firefox0.8，所有的进程和标签页都可以共享同样的cookie。一般来说是用javascript的window.open打开的窗口会与原窗口共享内存cookie。浏览器对于会话cookie的这种只认cookie不认人的处理方式经常给采用session机制的web应用程序开发者造成很大的困扰。

下面就是一个goolge设置cookie的响应头的例子
HTTP/1.1 302 Found
Location: http://www.google.com/intl/zh-CN/
Set-Cookie: PREF=ID=0565f77e132de138:NW=1:TM=1098082649:LM=1098082649:S=KaeaCFPo49RiA_d8; expires=Sun, 17-Jan-2038 19:14:07 GMT; path=/; domain=.google.com
Content-Type: text/html

这是使用HTTPLook这个HTTP Sniffer软件来俘获的HTTP通讯纪录的一部分

浏览器在再次访问goolge的资源时自动向外发送cookie

使用Firefox可以很容易的观察现有的cookie的值
使用HTTPLook配合Firefox可以很容易的理解cookie的工作原理。

IE也可以设置在接受cookie前询问

这是一个询问接受cookie的对话框。

四、理解session机制
session机制是一种服务器端的机制，服务器使用一种类似于散列表的结构（也可能就是使用散列表）来保存信息。

当程序需要为某个客户端的请求创建一个session的时候，服务器首先检查这个客户端的请求里是否已包含了一个session标识 - 称为session id，如果已包含一个session id则说明以前已经为此客户端创建过session，服务器就按照session id把这个session检索出来使用（如果检索不到，可能会新建一个），如果客户端请求不包含session id，则为此客户端创建一个session并且生成一个与此session相关联的session id，session id的值应该是一个既不会重复，又不容易被找到规律以仿造的字符串，这个session id将被在本次响应中返回给客户端保存。

保存这个session id的方式可以采用cookie，这样在交互过程中浏览器可以自动的按照规则把这个标识发挥给服务器。一般这个cookie的名字都是类似于SEEESIONID，而。比如weblogic对于web应用程序生成的cookie，JSESSIONID=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764，它的名字就是JSESSIONID。

由于cookie可以被人为的禁止，必须有其他机制以便在cookie被禁止时仍然能够把session id传递回服务器。经常被使用的一种技术叫做URL重写，就是把session id直接附加在URL路径的后面，附加方式也有两种，一种是作为URL路径的附加信息，表现形式为http://...../xxx;jsessionid=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764
另一种是作为查询字符串附加在URL后面，表现形式为http://...../xxx?jsessionid=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764
这两种方式对于用户来说是没有区别的，只是服务器在解析的时候处理的方式不同，采用第一种方式也有利于把session id的信息和正常程序参数区分开来。
为了在整个交互过程中始终保持状态，就必须在每个客户端可能请求的路径后面都包含这个session id。

另一种技术叫做表单隐藏字段。就是服务器会自动修改表单，添加一个隐藏字段，以便在表单提交时能够把session id传递回服务器。比如下面的表单

在被传递给客户端之前将被改写成

这种技术现在已较少应用，笔者接触过的很古老的iPlanet6(SunONE应用服务器的前身)就使用了这种技术。
实际上这种技术可以简单的用对action应用URL重写来代替。

在谈论session机制的时候，常常听到这样一种误解“只要关闭浏览器，session就消失了”。其实可以想象一下会员卡的例子，除非顾客主动对店家提出销卡，否则店家绝对不会轻易删除顾客的资料。对session来说也是一样的，除非程序通知服务器删除一个session，否则服务器会一直保留，程序一般都是在用户做log off的时候发个指令去删除session。然而浏览器从来不会主动在关闭之前通知服务器它将要关闭，因此服务器根本不会有机会知道浏览器已经关闭，之所以会有这种错觉，是大部分session机制都使用会话cookie来保存session id，而关闭浏览器后这个session id就消失了，再次连接服务器时也就无法找到原来的session。如果服务器设置的cookie被保存到硬盘上，或者使用某种手段改写浏览器发出的HTTP请求头，把原来的session id发送给服务器，则再次打开浏览器仍然能够找到原来的session。

恰恰是由于关闭浏览器不会导致session被删除，迫使服务器为seesion设置了一个失效时间，当距离客户端上一次使用session的时间超过这个失效时间时，服务器就可以认为客户端已经停止了活动，才会把session删除以节省存储空间。

五、理解javax.servlet.http.HttpSession
HttpSession是Java平台对session机制的实现规范，因为它仅仅是个接口，具体到每个web应用服务器的提供商，除了对规范支持之外，仍然会有一些规范里没有规定的细微差异。这里我们以BEA的Weblogic Server8.1作为例子来演示。

首先，Weblogic Server提供了一系列的参数来控制它的HttpSession的实现，包括使用cookie的开关选项，使用URL重写的开关选项，session持久化的设置，session失效时间的设置，以及针对cookie的各种设置，比如设置cookie的名字、路径、域，cookie的生存时间等。

一般情况下，session都是存储在内存里，当服务器进程被停止或者重启的时候，内存里的session也会被清空，如果设置了session的持久化特性，服务器就会把session保存到硬盘上，当服务器进程重新启动或这些信息将能够被再次使用，Weblogic Server支持的持久性方式包括文件、数据库、客户端cookie保存和复制。

复制严格说来不算持久化保存，因为session实际上还是保存在内存里，不过同样的信息被复制到各个cluster内的服务器进程中，这样即使某个服务器进程停止工作也仍然可以从其他进程中取得session。

cookie生存时间的设置则会影响浏览器生成的cookie是否是一个会话cookie。默认是使用会话cookie。有兴趣的可以用它来试验我们在第四节里提到的那个误解。

cookie的路径对于web应用程序来说是一个非常重要的选项，Weblogic Server对这个选项的默认处理方式使得它与其他服务器有明显的区别。后面我们会专题讨论。

关于session的设置参考[5] http://e-docs.bea.com/wls/docs70/webapp/weblogic_xml.html#1036869

六、HttpSession常见问题
（在本小节中session的含义为⑤和⑥的混合）

1、session在何时被创建
一个常见的误解是以为session在有客户端访问时就被创建，然而事实是直到某server端程序调用HttpServletRequest.getSession(true)这样的语句时才被创建，注意如果JSP没有显示的使用 <%@page session="false"%> 关闭session，则JSP文件在编译成Servlet时将会自动加上这样一条语句HttpSession session = HttpServletRequest.getSession(true);这也是JSP中隐含的session对象的来历。

由于session会消耗内存资源，因此，如果不打算使用session，应该在所有的JSP中关闭它。

2、session何时被删除
综合前面的讨论，session在下列情况下被删除a.程序调用HttpSession.invalidate();或b.距离上一次收到客户端发送的session id时间间隔超过了session的超时设置;或c.服务器进程被停止（非持久session）

3、如何做到在浏览器关闭时删除session
严格的讲，做不到这一点。可以做一点努力的办法是在所有的客户端页面里使用javascript代码window.oncolose来监视浏览器的关闭动作，然后向服务器发送一个请求来删除session。但是对于浏览器崩溃或者强行杀死进程这些非常规手段仍然无能为力。

4、有个HttpSessionListener是怎么回事
你可以创建这样的listener去监控session的创建和销毁事件，使得在发生这样的事件时你可以做一些相应的工作。注意是session的创建和销毁动作触发listener，而不是相反。类似的与HttpSession有关的listener还有HttpSessionBindingListener，HttpSessionActivationListener和HttpSessionAttributeListener。

5、存放在session中的对象必须是可序列化的吗
不是必需的。要求对象可序列化只是为了session能够在集群中被复制或者能够持久保存或者在必要时server能够暂时把session交换出内存。在Weblogic Server的session中放置一个不可序列化的对象在控制台上会收到一个警告。我所用过的某个iPlanet版本如果session中有不可序列化的对象，在session销毁时会有一个Exception，很奇怪。

6、如何才能正确的应付客户端禁止cookie的可能性
对所有的URL使用URL重写，包括超链接，form的action，和重定向的URL，具体做法参见[6]
http://e-docs.bea.com/wls/docs70/webapp/sessions.html#100770

7、开两个浏览器窗口访问应用程序会使用同一个session还是不同的session
参见第三小节对cookie的讨论，对session来说是只认id不认人，因此不同的浏览器，不同的窗口打开方式以及不同的cookie存储方式都会对这个问题的答案有影响。

8、如何防止用户打开两个浏览器窗口操作导致的session混乱
这个问题与防止表单多次提交是类似的，可以通过设置客户端的令牌来解决。就是在服务器每次生成一个不同的id返回给客户端，同时保存在session里，客户端提交表单时必须把这个id也返回服务器，程序首先比较返回的id与保存在session里的值是否一致，如果不一致则说明本次操作已经被提交过了。可以参看《J2EE核心模式》关于表示层模式的部分。需要注意的是对于使用javascript window.open打开的窗口，一般不设置这个id，或者使用单独的id，以防主窗口无法操作，建议不要再window.open打开的窗口里做修改操作，这样就可以不用设置。

9、为什么在Weblogic Server中改变session的值后要重新调用一次session.setValue
做这个动作主要是为了在集群环境中提示Weblogic Server session中的值发生了改变，需要向其他服务器进程复制新的session值。

10、为什么session不见了
排除session正常失效的因素之外，服务器本身的可能性应该是微乎其微的，虽然笔者在iPlanet6SP1加若干补丁的Solaris版本上倒也遇到过；浏览器插件的可能性次之，笔者也遇到过3721插件造成的问题；理论上防火墙或者代理服务器在cookie处理上也有可能会出现问题。
出现这一问题的大部分原因都是程序的错误，最常见的就是在一个应用程序中去访问另外一个应用程序。我们在下一节讨论这个问题。

七、跨应用程序的session共享

常常有这样的情况，一个大项目被分割成若干小项目开发，为了能够互不干扰，要求每个小项目作为一个单独的web应用程序开发，可是到了最后突然发现某几个小项目之间需要共享一些信息，或者想使用session来实现SSO(single sign on)，在session中保存login的用户信息，最自然的要求是应用程序间能够访问彼此的session。

然而按照Servlet规范，session的作用范围应该仅仅限于当前应用程序下，不同的应用程序之间是不能够互相访问对方的session的。各个应用服务器从实际效果上都遵守了这一规范，但是实现的细节却可能各有不同，因此解决跨应用程序session共享的方法也各不相同。

首先来看一下Tomcat是如何实现web应用程序之间session的隔离的，从Tomcat设置的cookie路径来看，它对不同的应用程序设置的cookie路径是不同的，这样不同的应用程序所用的session id是不同的，因此即使在同一个浏览器窗口里访问不同的应用程序，发送给服务器的session id也可以是不同的。

根据这个特性，我们可以推测Tomcat中session的内存结构大致如下。

笔者以前用过的iPlanet也采用的是同样的方式，估计SunONE与iPlanet之间不会有太大的差别。对于这种方式的服务器，解决的思路很简单，实际实行起来也不难。要么让所有的应用程序共享一个session id，要么让应用程序能够获得其他应用程序的session id。

iPlanet中有一种很简单的方法来实现共享一个session id，那就是把各个应用程序的cookie路径都设为/（实际上应该是/NASApp，对于应用程序来讲它的作用相当于根）。

/NASApp

需要注意的是，操作共享的session应该遵循一些编程约定，比如在session attribute名字的前面加上应用程序的前缀，使得setAttribute("name", "neo")变成setAttribute("app1.name", "neo")，以防止命名空间冲突，导致互相覆盖。

在Tomcat中则没有这么方便的选择。在Tomcat版本3上，我们还可以有一些手段来共享session。对于版本4以上的Tomcat，目前笔者尚未发现简单的办法。只能借助于第三方的力量，比如使用文件、数据库、JMS或者客户端cookie，URL参数或者隐藏字段等手段。

我们再看一下Weblogic Server是如何处理session的。

从截屏画面上可以看到Weblogic Server对所有的应用程序设置的cookie的路径都是/，这是不是意味着在Weblogic Server中默认的就可以共享session了呢？然而一个小实验即可证明即使不同的应用程序使用的是同一个session，各个应用程序仍然只能访问自己所设置的那些属性。这说明Weblogic Server中的session的内存结构可能如下

对于这样一种结构，在session机制本身上来解决session共享的问题应该是不可能的了。除了借助于第三方的力量，比如使用文件、数据库、JMS或者客户端cookie，URL参数或者隐藏字段等手段，还有一种较为方便的做法，就是把一个应用程序的session放到ServletContext中，这样另外一个应用程序就可以从ServletContext中取得前一个应用程序的引用。示例代码如下，

应用程序A
context.setAttribute("appA", session);

应用程序B
contextA = context.getContext("/appA");
HttpSession sessionA = (HttpSession)contextA.getAttribute("appA");

值得注意的是这种用法不可移植，因为根据ServletContext的JavaDoc，应用服务器可以处于安全的原因对于context.getContext("/appA");返回空值，以上做法在Weblogic Server 8.1中通过。

那么Weblogic Server为什么要把所有的应用程序的cookie路径都设为/呢？原来是为了SSO，凡是共享这个session的应用程序都可以共享认证的信息。一个简单的实验就可以证明这一点，修改首先登录的那个应用程序的描述符weblogic.xml，把cookie路径修改为/appA访问另外一个应用程序会重新要求登录，即使是反过来，先访问cookie路径为/的应用程序，再访问修改过路径的这个，虽然不再提示登录，但是登录的用户信息也会丢失。注意做这个实验时认证方式应该使用FORM，因为浏览器和web服务器对basic认证方式有其他的处理方式，第二次请求的认证不是通过session来实现的。具体请参看[7] secion 14.8 Authorization，你可以修改所附的示例程序来做这些试验。

八、总结
session机制本身并不复杂，然而其实现和配置上的灵活性却使得具体情况复杂多变。这也要求我们不能把仅仅某一次的经验或者某一个浏览器，服务器的经验当作普遍适用的经验，而是始终需要具体情况具体分析。

关于作者：
郎云鹏（dev2dev ID: hippiewolf），软件工程师，从事J2EE开发
电子邮件：langyunpeng@yahoo.com.cn
地址：大连软件园路31号科技大厦A座大连博涵咨询服务有限公司

参考文档：
[1] Preliminary Specification http://wp.netscape.com/newsref/std/cookie_spec.html
[2] RFC2109 http://www.rfc-editor.org/rfc/rfc2109.txt
[3] RFC2965 http://www.rfc-editor.org/rfc/rfc2965.txt
[4] The Unofficial Cookie FAQ http://www.cookiecentral.com/faq/
[5] http://e-docs.bea.com/wls/docs70/webapp/weblogic_xml.html#1036869
[6] http://e-docs.bea.com/wls/docs70/webapp/sessions.html#100770
[7] RFC2616 http://www.rfc-editor.org/rfc/rfc2616.txt

代码下载：sampleApp.zip

java执著者 2006-09-19 14:35 发表评论

谈谈Unicode编码，简要解释UCS、UTF、BMP、BOM等名词

java执著者 — Thu, 29 Jun 2006 08:56:00 GMT

这是一篇程序员写给程序员的趣味读物。所谓趣味是指可以比较轻松地了解一些原来不清楚的概念，增进知识，类似于打RPG游戏的升级。整理这篇文章的动机是两个问题：

问题一：

使用Windows记事本的“另存为”，可以在GBK、Unicode、Unicode big endian和UTF-8这几种编码方式间相互转换。同样是txt文件，Windows是怎样识别编码方式的呢？

我很早前就发现Unicode、Unicode big endian和UTF-8编码的txt文件的开头会多出几个字节，分别是FF、FE （Unicode）,FE、FF（Unicode big endian）,EF、BB、BF（UTF-8）。但这些标记是基于什么标准呢？

问题二：

最近在网上看到一个ConvertUTF.c，实现了UTF-32、UTF-16和UTF-8这三种编码方式的相互转换。对于Unicode(UCS2)、 GBK、UTF-8这些编码方式，我原来就了解。但这个程序让我有些糊涂，想不起来UTF-16和UCS2有什么关系。

查了查相关资料，总算将这些问题弄清楚了，顺带也了解了一些Unicode的细节。写成一篇文章，送给有过类似疑问的朋友。本文在写作时尽量做到通俗易懂，但要求读者知道什么是字节，什么是十六进制。

0、big endian和little endian

big endian 和little endian是CPU处理多字节数的不同方式。例如“汉”字的Unicode编码是6C49。那么写到文件里时，究竟是将6C写在前面，还是将49写在前面？如果将6C写在前面，就是big endian。如果将49写在前面，就是little endian。

“endian”这个词出自《格列佛游记》。小人国的内战就源于吃鸡蛋时是究竟从大头(Big-Endian)敲开还是从小头(Little-Endian)敲开，由此曾发生过六次叛乱，一个皇帝送了命，另一个丢了王位。

我们一般将endian翻译成“字节序”，将big endian和little endian称作“大尾”和“小尾”。

1、字符编码、内码，顺带介绍汉字编码

字符必须编码后才能被计算机处理。计算机使用的缺省编码方式就是计算机的内码。早期的计算机使用7位的ASCII编码，为了处理汉字，程序员设计了用于简体中文的GB2312和用于繁体中文的big5。

GB2312(1980年)一共收录了7445个字符，包括6763个汉字和682个其它符号。汉字区的内码范围高字节从B0-F7，低字节从A1-FE，占用的码位是72*94=6768。其中有5个空位是D7FA-D7FE。

GB2312支持的汉字太少。1995年的汉字扩展规范GBK1.0收录了21886个符号，它分为汉字区和图形符号区。汉字区包括21003个字符。

从ASCII、 GB2312到GBK，这些编码方法是向下兼容的，即同一个字符在这些方案中总是有相同的编码，后面的标准支持更多的字符。在这些编码中，英文和中文可以统一地处理。区分中文编码的方法是高字节的最高位不为0。按照程序员的称呼，GB2312、GBK都属于双字节字符集 (DBCS)。

2000 年的GB18030是取代GBK1.0的正式国家标准。该标准收录了27484个汉字，同时还收录了藏文、蒙文、维吾尔文等主要的少数民族文字。从汉字字汇上说，GB18030在GB13000.1的20902个汉字的基础上增加了CJK扩展A的6582个汉字（Unicode码0x3400- 0x4db5），一共收录了27484个汉字。

CJK就是中日韩的意思。Unicode为了节省码位，将中日韩三国语言中的文字统一编码。GB13000.1就是ISO/IEC 10646-1的中文版，相当于Unicode 1.1。

GB18030 的编码采用单字节、双字节和4字节方案。其中单字节、双字节和GBK是完全兼容的。4字节编码的码位就是收录了CJK扩展A的6582个汉字。例如： UCS的0x3400在GB18030中的编码应该是8139EF30，UCS的0x3401在GB18030中的编码应该是8139EF31。

微软提供了GB18030的升级包，但这个升级包只是提供了一套支持CJK扩展A的6582个汉字的新字体：新宋体-18030，并不改变内码。Windows 的内码仍然是GBK。

这里还有一些细节：

GB2312的原文还是区位码，从区位码到内码，需要在高字节和低字节上分别加上A0。
对于任何字符编码，编码单元的顺序是由编码方案指定的，与endian无关。例如GBK的编码单元是字节，用两个字节表示一个汉字。这两个字节的顺序是固定的，不受CPU字节序的影响。UTF-16的编码单元是word（双字节），word之间的顺序是编码方案指定的，word内部的字节排列才会受到 endian的影响。后面还会介绍UTF-16。
GB2312的两个字节的最高位都是1。但符合这个条件的码位只有 128*128=16384个。所以GBK和GB18030的低字节最高位都可能不是1。不过这不影响DBCS字符流的解析：在读取DBCS字符流时，只要遇到高位为1的字节，就可以将下两个字节作为一个双字节编码，而不用管低字节的高位是什么。

2、Unicode、UCS和UTF

前面提到从ASCII、GB2312、GBK到GB18030的编码方法是向下兼容的。而Unicode只与ASCII兼容（更准确地说，是与ISO-8859-1兼容），与GB码不兼容。例如“汉”字的Unicode编码是6C49，而GB码是BABA。

Unicode 也是一种字符编码方法，不过它是由国际组织设计，可以容纳全世界所有语言文字的编码方案。Unicode的学名是"Universal Multiple -Octet Coded Character Set"，简称为UCS。UCS可以看作是"Unicode Character Set"的缩写。

根据维基百科全书(http://zh.wikipedia.org/wiki/)的记载：历史上存在两个试图独立设计Unicode的组织，即国际标准化组织（ISO）和一个软件制造商的协会（unicode.org）。ISO开发了ISO 10646项目，Unicode协会开发了Unicode项目。

在1991年前后，双方都认识到世界不需要两个不兼容的字符集。于是它们开始合并双方的工作成果，并为创立一个单一编码表而协同工作。从Unicode2.0开始，Unicode项目采用了与ISO 10646-1相同的字库和字码。

目前两个项目仍都存在，并独立地公布各自的标准。Unicode协会现在的最新版本是2005年的Unicode 4.1.0。ISO的最新标准是ISO 10646-3:2003。

UCS 只是规定如何编码，并没有规定如何传输、保存这个编码。例如“汉”字的UCS编码是6C49，我可以用4个ascii数字来传输、保存这个编码；也可以用 utf-8编码:3个连续的字节E6 B1 89来表示它。关键在于通信双方都要认可。UTF-8、UTF-7、UTF-16都是被广泛接受的方案。 UTF-8的一个特别的好处是它与ISO-8859-1完全兼容。UTF是“UCS Transformation Format”的缩写。

IETF 的RFC2781和RFC3629以RFC的一贯风格，清晰、明快又不失严谨地描述了UTF-16和UTF-8的编码方法。我总是记不得IETF是 Internet Engineering Task Force的缩写。但IETF负责维护的RFC是Internet上一切规范的基础。

2.1、内码和code page

目前Windows的内核已经支持Unicode字符集，这样在内核上可以支持全世界所有的语言文字。但是由于现有的大量程序和文档都采用了某种特定语言的编码，例如GBK，Windows不可能不支持现有的编码，而全部改用Unicode。

Windows使用代码页(code page)来适应各个国家和地区。code page可以被理解为前面提到的内码。GBK对应的code page是CP936。

微软也为GB18030定义了code page：CP54936。但是由于GB18030有一部分4字节编码，而Windows的代码页只支持单字节和双字节编码，所以这个code page是无法真正使用的。

3、UCS-2、UCS-4、BMP

UCS有两种格式：UCS-2和UCS-4。顾名思义，UCS-2就是用两个字节编码，UCS-4就是用4个字节（实际上只用了31位，最高位必须为0）编码。下面让我们做一些简单的数学游戏：

UCS-2有2^16=65536个码位，UCS-4有2^31=2147483648个码位。

UCS -4根据最高位为0的最高字节分成2^7=128个group。每个group再根据次高字节分为256个plane。每个plane根据第3个字节分为 256行 (rows)，每行包含256个cells。当然同一行的cells只是最后一个字节不同，其余都相同。

group 0的plane 0被称作Basic Multilingual Plane, 即BMP。或者说UCS-4中，高两个字节为0的码位被称作BMP。

将UCS-4的BMP去掉前面的两个零字节就得到了UCS-2。在UCS-2的两个字节前加上两个零字节，就得到了UCS-4的BMP。而目前的UCS-4规范中还没有任何字符被分配在BMP之外。

4、UTF编码

UTF-8就是以8位为单元对UCS进行编码。从UCS-2到UTF-8的编码方式如下：

UCS-2编码(16进制)	UTF-8 字节流(二进制)
0000 - 007F	0xxxxxxx
0080 - 07FF	110xxxxx 10xxxxxx
0800 - FFFF	1110xxxx 10xxxxxx 10xxxxxx

例如“汉”字的Unicode编码是6C49。6C49在0800-FFFF之间，所以肯定要用3字节模板了： 1110 xxxx 10 xxxxxx 10 xxxxxx。将6C49写成二进制是：0110 110001 001001，用这个比特流依次代替模板中的x，得到： 1110 0110 10 110001 10 001001，即E6 B1 89。

读者可以用记事本测试一下我们的编码是否正确。需要注意，UltraEdit在打开utf-8编码的文本文件时会自动转换为UTF-16，可能产生混淆。你可以在设置中关掉这个选项。更好的工具是Hex Workshop。

UTF -16以16位为单元对UCS进行编码。对于小于0x10000的UCS码，UTF-16编码就等于UCS码对应的16位无符号整数。对于不小于 0x10000的UCS码，定义了一个算法。不过由于实际使用的UCS2，或者UCS4的BMP必然小于0x10000，所以就目前而言，可以认为UTF -16和UCS-2基本相同。但UCS-2只是一个编码方案，UTF-16却要用于实际的传输，所以就不得不考虑字节序的问题。

5、UTF的字节序和BOM

UTF -8以字节为编码单元，没有字节序的问题。UTF-16以两个字节为编码单元，在解释一个UTF-16文本前，首先要弄清楚每个编码单元的字节序。例如 “奎”的Unicode编码是594E，“乙”的Unicode编码是4E59。如果我们收到UTF-16字节流“594E”，那么这是“奎”还是 “乙”？

Unicode规范中推荐的标记字节顺序的方法是BOM。BOM不是“Bill Of Material”的BOM表，而是Byte Order Mark。BOM是一个有点小聪明的想法：

在UCS 编码中有一个叫做"ZERO WIDTH NO-BREAK SPACE"的字符，它的编码是FEFF。而FFFE在UCS中是不存在的字符，所以不应该出现在实际传输中。UCS规范建议我们在传输字节流前，先传输字符"ZERO WIDTH NO-BREAK SPACE"。

这样如果接收者收到FEFF，就表明这个字节流是Big-Endian的；如果收到FFFE，就表明这个字节流是Little-Endian的。因此字符"ZERO WIDTH NO-BREAK SPACE"又被称作BOM。

UTF -8不需要BOM来表明字节顺序，但可以用BOM来表明编码方式。字符"ZERO WIDTH NO-BREAK SPACE"的UTF-8编码是 EF BB BF（读者可以用我们前面介绍的编码方法验证一下）。所以如果接收者收到以EF BB BF开头的字节流，就知道这是UTF-8编码了。

Windows就是使用BOM来标记文本文件的编码方式的。

6、进一步的参考资料

本文主要参考的资料是 "Short overview of ISO-IEC 10646 and Unicode" (http://www.nada.kth.se/i18n/ucs/unicode-iso10646-oview.html)。

我还找了两篇看上去不错的资料，不过因为我开始的疑问都找到了答案，所以就没有看：

"Understanding Unicode A general introduction to the Unicode Standard" (http://scripts.sil.org/cms/scrip ... S-Chapter04a)
"Character set encoding basics Understanding character set encodings and legacy encodings" (http://scripts.sil.org/cms/scrip ... WS-Chapter03)

我写过UTF-8、UCS-2、GBK相互转换的软件包，包括使用Windows API和不使用Windows API的版本。以后有时间的话，我会整理一下放到我的个人主页上(http://fmddlmyy.home4u.china.com)。

我是想清楚所有问题后才开始写这篇文章的，原以为一会儿就能写好。没想到考虑措辞和查证细节花费了很长时间，竟然从下午1:30写到9:00。希望有读者能从中受益。

附录1 再说说区位码、GB2312、内码和代码页

有的朋友对文章中这句话还有疑问：
“GB2312的原文还是区位码，从区位码到内码，需要在高字节和低字节上分别加上A0。”

我再详细解释一下：

“GB2312 的原文”是指国家1980年的一个标准《中华人民共和国国家标准信息交换用汉字编码字符集基本集 GB 2312-80》。这个标准用两个数来编码汉字和中文符号。第一个数称为“区”，第二个数称为“位”。所以也称为区位码。1-9区是中文符号，16-55区是一级汉字，56-87区是二级汉字。现在 Windows也还有区位输入法，例如输入1601得到“啊”。（这个区位输入法可以自动识别16进制的GB2312和10进制的区位码，也就是说输入 B0A1同样会得到“啊”。）

内码是指操作系统内部的字符编码。早期操作系统的内码是与语言相关的。现在的Windows在系统内部支持Unicode，然后用代码页适应各种语言，“内码”的概念就比较模糊了。微软一般将缺省代码页指定的编码说成是内码。

内码这个词汇，并没有什么官方的定义，代码页也只是微软这个公司的叫法。作为程序员，我们只要知道它们是什么东西，没有必要过多地考证这些名词。

所谓代码页(code page)就是针对一种语言文字的字符编码。例如GBK的code page是CP936，BIG5的code page是CP950，GB2312的code page是CP20936。

Windows中有缺省代码页的概念，即缺省用什么编码来解释字符。例如Windows的记事本打开了一个文本文件，里面的内容是字节流：BA、BA、D7、D6。Windows应该去怎么解释它呢？

是按照Unicode编码解释、还是按照GBK解释、还是按照BIG5解释，还是按照ISO8859-1去解释？如果按GBK去解释，就会得到“汉字”两个字。按照其它编码解释，可能找不到对应的字符，也可能找到错误的字符。所谓“错误”是指与文本作者的本意不符，这时就产生了乱码。

答案是Windows按照当前的缺省代码页去解释文本文件里的字节流。缺省代码页可以通过控制面板的区域选项设置。记事本的另存为中有一项ANSI，其实就是按照缺省代码页的编码方法保存。

Windows的内码是Unicode，它在技术上可以同时支持多个代码页。只要文件能说明自己使用什么编码，用户又安装了对应的代码页，Windows就能正确显示，例如在HTML文件中就可以指定charset。

有的HTML文件作者，特别是英文作者，认为世界上所有人都使用英文，在文件中不指定charset。如果他使用了0x80-0xff之间的字符，中文 Windows又按照缺省的GBK去解释，就会出现乱码。这时只要在这个html文件中加上指定charset的语句，例如：

如果原作者使用的代码页和ISO8859-1兼容，就不会出现乱码了。

再说区位码，啊的区位码是1601，写成16进制是0x10,0x01。这和计算机广泛使用的ASCII编码冲突。为了兼容00-7f的ASCII编码，我们在区位码的高、低字节上分别加上A0。这样“啊”的编码就成为B0A1。我们将加过两个A0的编码也称为GB2312编码，虽然GB2312的原文根本没提到这一点。

java执著者 2006-06-29 16:56 发表评论

[转载]UTF-16

java执著者 — Thu, 29 Jun 2006 08:51:00 GMT

UTF-16是Unicode的其中一个使用方式。 UTF是 Unicode Translation Format，即把Unicode转做某种格式的意思。

它定义于ISO/IEC 10646-1的附录Q，而RFC2781也定义了相似的做法。

在Unicode基本多文种平面定义的字符（无论是拉丁字母、汉字或其他文字或符号），一律使用2字节储存。而在辅助平面定义的字符，会以代理对（surrogate pair）的形式，以两个2字节的值来储存。

UTF-16比起UTF-8，好处在于大部分字符都以固定长度的字节 (2字节) 储存，但UTF-16却无法兼容于ASCII编码。

UTF-16的编码模式

UTF-16的大尾序和小尾序储存形式都在用。一般来说，以Macintosh制作或储存的文字使用大尾序格式，以Microsoft或Linux制作或储存的文字使用小尾序格式。

为了弄清楚UTF-16文件的大小尾序，在UTF-16文件的开首，都会放置一个U+FEFF字符作为Byte Order Mark (UTF-16LE 以 FF FE 代表，UTF-16BE 以 FE FF 代表)，以显示这个文字档案是以UTF-16编码。

以下的例子有四个字符：“朱”、半角逗号、“聿”、“𨮁”。

使用 UTF-16 编码的例子
编码名称	编码次序	编码
UTF-16LE	小尾序	31 67, 2C 00, 7F 80, 62 D8 81 DF
UTF-16BE	大尾序	67 31, 00 2C, 80 7F, D8 62 DF 81
UTF-16	小尾序，包含BOM	FF FE, 31 67, 2C 00, 7F 80, 62 D8 81 DF
UTF-16	大尾序，包含BOM	FE FF, 67 31, 00 2C, 80 7F, D8 62 DF 81

UTF-16 与 UCS-2 的关系

UTF-16可看成是UCS-2的父集。在没有辅助平面字符前，UTF-16与UCS-2所指的是同一的意思。但当引入辅助平面字符后，就只称为UTF-16了。现在若有软件声称自己支援UCS-2编码，那其实是暗指它不能支援辅助平面字符的委婉语。

java执著者 2006-06-29 16:51 发表评论

[转载]UTF-8 字符集基础

java执著者 — Thu, 29 Jun 2006 08:00:00 GMT

字符集简史

在所有字符集中，最知名可能要数被称为ASCII的7位字符集了。它是美国信息交换标准委员会（American Standards Committee for Information Interchange）的缩写, 为美国英语通信所设计。它由128个字符组成，包括大小写字母、数字0-9、标点符号、非打印字符（换行符、制表符等4个）以及控制字符（退格、响铃等）组成。

但是，由于他是针对英语设计的，当处理带有音调标号（形如汉语的拼音）的欧洲文字时就会出现问题。因此，创建出了一些包括255个字符的由ASCII扩展的字符集。其中有一种通常被成为IBM字符集，它把值为128-255之间的字符用于画图和画线，以及一些特殊的欧洲字符。另一种8位字符集是 ISO 8859-1 Latin 1，也简称为ISO Latin-1。它把位于128-255之间的字符用于拉丁字母表中特殊语言字符的编码，也因此而得名。

欧洲语言不是地球上的唯一语言，因此亚洲和非洲语言并不能被8位字符集所支持。仅汉语（或pictograms）字母表就有80000以上个字符。但是把汉语、日语和越南语的一些相似的字符结合起来，在不同的语言里，使不同的字符代表不同的字，这样只用2个字节就可以编码地球上几乎所有地区的文字。因此，创建了UNICODE编码。它通过增加一个高字节对 ISO Latin-1字符集进行扩展，当这些高字节位为0时，低字节就是ISO Latin-1字符。UNICODE支持欧洲、非洲、中东、亚洲（包括统一标准的东亚像形汉字和韩国像形文字）。但是，UNICODE并没有提供对诸如Braille, Cherokee, Ethiopic, Khmer, Mongolian, Hmong, Tai Lu, Tai Mau文字的支持。同时它也不支持如Ahom, Akkadian, Aramaic, Babylonian Cuneiform, Balti, Brahmi, Etruscan, Hittite, Javanese, Numidian, Old Persian Cuneiform, Syrian之类的古老的文字。

事实证明，对可以用ASCII表示的字符使用UNICODE并不高效，因为UNICODE比ASCII占用大一倍的空间，而对ASCII来说高字节的0对他毫无用处。为了解决这个问题，就出现了一些中间格式的字符集，他们被称为通用转换格式，既UTF （Universal Transformation Format）。目前存在的UTF格式有：UTF-7, UTF-7.5, UTF-8, UTF -16, 以及 UTF-32。本文讨论UTF-8字符集的基础。

UTF_8字符集

UTF -8是UNICODE的一种变长字符编码，由Ken Thompson于1992年创建。现在已经标准化为RFC 3629。UTF-8用1到6个字节编码UNICODE字符。如果UNICODE字符由2个字节表示，则编码成UTF-8很可能需要3个字节，而如果UNICODE字符由4个字节表示，则编码成UTF-8可能需要6个字节。用4个或6个字节去编码一个UNICODE字符可能太多了，但很少会遇到那样的UNICODE字符。

UFT-8转换表表示如下：

UNICODE UTF-8
00000000 - 0000007F 0xxxxxxx
00000080 - 000007FF 110xxxxx 10xxxxxx
00000800 - 0000FFFF 1110xxxx 10xxxxxx 10xxxxxx
00010000 - 001FFFFF 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
00200000 - 03FFFFFF 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
04000000 - 7FFFFFFF 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx

实际表示ASCII字符的UNICODE字符，将会编码成1个字节，并且UTF-8表示与ASCII字符表示是一样的。所有其他的UNCODE字符转化成 UTF-8将需要至少2个字节。每个字节由一个换码序列开始。第一个字节由唯一的换码序列，由n位1加一位0组成。n位1表示字符编码所需的字节数。

示例

UNICODE uCA(11001010) 编码成UTF-8将需要2个字节：

uCA -> C3 8A

1100 1010
110xxxxx 10xxxxxx

1100 1010 -> 110xxxxx 10xxxxxx
-> 110xxxxx 10xxxxx0
-> 110xxxxx 10xxxx10
-> 110xxxxx 10xxx010
-> 110xxxxx 10xx1010
-> 110xxxxx 10x01010
-> 110xxxxx 10001010
-> 110xxxx1 10001010
-> 110xxx11 10001010
-> 11000011 10001010
-> C3 8A

UNICODE uF03F (11110000 00111111) 编码成UTF-8将需要3个字节:

u F03F -> EF 80 BF

1111 0000 0011 1111 -> 1110xxxx 10xxxxxx 10xxxxxx
-> 11101111 10000000 10111111
-> EF 80 BF

译者注：由上分析可以看到，UNCODE到UTF-8的转换就是先确定编码所需要的字节数，然后用UNICODE编码位从低位到高位依次填入上面表示为x的位上，不足的高位以0补充。以上是个人经验，如有错误，请不惜指教，谢过先:)

UTF-8编码的优点：

UTF-8编码可以通过屏蔽位和移位操作快速读写。
字符串比较时strcmp()和wcscmp()的返回结果相同，因此使排序变得更加容易。
字节FF和FE在UTF-8编码中永远不会出现，因此他们可以用来表明UTF-16或UTF-32文本（见BOM）
UTF-8 是字节顺序无关的。它的字节顺序在所有系统中都是一样的，因此它实际上并不需要BOM。

UTF-8编码的缺点：

你无法从UNICODE字符数判断出UTF-8文本的字节数，因为UTF-8是一种变长编码
它需要用2个字节编码那些用扩展ASCII字符集只需1个字节的字符
ISO Latin-1 是UNICODE的子集，但不是UTF-8的子集
8位字符的UTF-8编码会被email网关过滤，因为internet信息最初设计为7为ASCII码。因此产生了UTF-7编码。
UTF-8 在它的表示中使用值100xxxxx的几率超过50%，而现存的实现如ISO 2022， 4873， 6429，和8859系统，会把它错认为是C1 控制码。因此产生了UTF-7.5编码。

修正的UTF-8：

java使用UTF-16表示内部文本，并支持用于字符串串行化的非标准的修正UTF-8编码。标准UTF-8和修正的UTF-8有两点不同：
修正的UTF-8中，null字符编码成2个字节（11000000 00000000）而不是标准的1个字节（00000000），这样作可以保证编码后的字符串中不会嵌入null字符。因此如果在类C语言中处理字符串，文本不会在第一个null字符时截断（C字符串以null结尾）。
在标准 UTF-8编码中，超出基本多语言范围（BMP - Basic Multilingual Plain）的字符被编码为4字节格式，但是在修正的UTF -8编码中，他们由代理编码对（surrogate pairs）表示，然后这些代理编码对在序列中分别重新编码。结果标准UTF-8编码中需要4个字节的字符，在修正后的UTF-8编码中将需要6个字节。

位序标志BOM

BOM（Byte Order Mark）是一个字符，它表明UNICODE文本的UTF-16,UTF-32的编码字节顺序（高字节低字节顺序）和编码方式（UTF-8,UTF-16,UTF-32，其中UTF-8编码是字节顺序无关的）。

如下所示：

Encoding Representation
UTF-8 EF BB BF
UTF-16 Big Endian FE FF
UTF-16 Little Endian FF FE
UTF-32 Big Endian 00 00 FE FF
UTF-32 Little Endian FF FE 00 00

UTF-8 C++ 程序编码示例：

下面是四个C++函数，他们分别实现2字节和4字节UNICODE和UTF-8之间的转换。

#define MASKBITS 0x3F
#define MASKBYTE 0x80
#define MASK2BYTES 0xC0
#define MASK3BYTES 0xE0
#define MASK4BYTES 0xF0
#define MASK5BYTES 0xF8
#define MASK6BYTES 0xFC

typedef unsigned short Unicode2Bytes;
typedef unsigned int Unicode4Bytes;

void UTF8Encode2BytesUnicode(std::vector< Unicode2Bytes > input,
std::vector< byte >& output)
{
for(int i=0; i < input.size(); i++)
{
// 0xxxxxxx
if(input < 0x80)
{
output.push_back((byte)input);
}
// 110xxxxx 10xxxxxx
else if(input < 0x800)
{
output.push_back((byte)(MASK2BYTES | input >> 6));
output.push_back((byte)(MASKBYTE | input & MASKBITS));
}
// 1110xxxx 10xxxxxx 10xxxxxx
else if(input < 0x10000)
{
output.push_back((byte)(MASK3BYTES | input >> 12));
output.push_back((byte)(MASKBYTE | input >> 6 & MASKBITS));
output.push_back((byte)(MASKBYTE | input & MASKBITS));
}
}
}

void UTF8Decode2BytesUnicode(std::vector< byte > input,
std::vector< Unicode2Bytes >& output)
{
for(int i=0; i < input.size();)
{
Unicode2Bytes ch;

// 1110xxxx 10xxxxxx 10xxxxxx
if((input & MASK3BYTES) == MASK3BYTES)
{
ch = ((input & 0x0F) << 12) | (
(input[i+1] & MASKBITS) << 6)
| (input[i+2] & MASKBITS);
i += 3;
}
// 110xxxxx 10xxxxxx
else if((input & MASK2BYTES) == MASK2BYTES)
{
ch = ((input & 0x1F) << 6) | (input[i+1] & MASKBITS);
i += 2;
}
// 0xxxxxxx
else if(input < MASKBYTE)
{
ch = input;
i += 1;
}

output.push_back(ch);
}
}

void UTF8Encode4BytesUnicode(std::vector< Unicode4Bytes > input,
std::vector< byte >& output)
{
for(int i=0; i < input.size(); i++)
{
// 0xxxxxxx
if(input < 0x80)
{
output.push_back((byte)input);
}
// 110xxxxx 10xxxxxx
else if(input < 0x800)
{
output.push_back((byte)(MASK2BYTES | input > 6));
output.push_back((byte)(MASKBYTE | input & MASKBITS));
}
// 1110xxxx 10xxxxxx 10xxxxxx
else if(input < 0x10000)
{
output.push_back((byte)(MASK3BYTES | input >> 12));
output.push_back((byte)(MASKBYTE | input >> 6 & MASKBITS));
output.push_back((byte)(MASKBYTE | input & MASKBITS));
}
// 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
else if(input < 0x200000)
{
output.push_back((byte)(MASK4BYTES | input >> 18));
output.push_back((byte)(MASKBYTE | input >> 12 & MASKBITS));
output.push_back((byte)(MASKBYTE | input >> 6 & MASKBITS));
output.push_back((byte)(MASKBYTE | input & MASKBITS));
}
// 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
else if(input < 0x4000000)
{
output.push_back((byte)(MASK5BYTES | input >> 24));
output.push_back((byte)(MASKBYTE | input >> 18 & MASKBITS));
output.push_back((byte)(MASKBYTE | input >> 12 & MASKBITS));
output.push_back((byte)(MASKBYTE | input >> 6 & MASKBITS));
output.push_back((byte)(MASKBYTE | input & MASKBITS));
}
// 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
else if(input < 0x8000000)
{
output.push_back((byte)(MASK6BYTES | input >> 30));
output.push_back((byte)(MASKBYTE | input >> 18 & MASKBITS));
output.push_back((byte)(MASKBYTE | input >> 12 & MASKBITS));
output.push_back((byte)(MASKBYTE | input >> 6 & MASKBITS));
output.push_back((byte)(MASKBYTE | input & MASKBITS));
}
}
}

void UTF8Decode4BytesUnicode(std::vector< byte > input,
std::vector< Unicode4Bytes >& output)
{
for(int i=0; i < input.size();)
{
Unicode4Bytes ch;

// 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
if((input & MASK6BYTES) == MASK6BYTES)
{
ch = ((input & 0x01) << 30) | ((input[i+1] & MASKBITS) << 24)
| ((input[i+2] & MASKBITS) << 18) | ((input[i+3]
& MASKBITS) << 12)
| ((input[i+4] & MASKBITS) << 6) | (input[i+5] & MASKBITS);
i += 6;
}
// 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
else if((input & MASK5BYTES) == MASK5BYTES)
{
ch = ((input & 0x03) << 24) | ((input[i+1]
& MASKBITS) << 18)
| ((input[i+2] & MASKBITS) << 12) | ((input[i+3]
& MASKBITS) << 6)
| (input[i+4] & MASKBITS);
i += 5;
}
// 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
else if((input & MASK4BYTES) == MASK4BYTES)
{
ch = ((input & 0x07) << 18) | ((input[i+1]
& MASKBITS) << 12)
| ((input[i+2] & MASKBITS) << 6) | (input[i+3] & MASKBITS);
i += 4;
}
// 1110xxxx 10xxxxxx 10xxxxxx
else if((input & MASK3BYTES) == MASK3BYTES)
{
ch = ((input & 0x0F) << 12) | ((input[i+1] & MASKBITS) << 6)
| (input[i+2] & MASKBITS);
i += 3;
}
// 110xxxxx 10xxxxxx
else if((input & MASK2BYTES) == MASK2BYTES)
{
ch = ((input & 0x1F) << 6) | (input[i+1] & MASKBITS);
i += 2;
}
// 0xxxxxxx
else if(input < MASKBYTE)
{
ch = input;
i += 1;
}
output.push_back(ch);
}
}

限译者水平有限，有不解之处请参考原文。版权属原文作者所有，转载请注明出处及作者。

原文参见：http://www.codeguru.com/Cpp/misc ... article.php/c10451/

java执著者 2006-06-29 16:00 发表评论

新的技术--开发者挑战

java执著者 — Mon, 27 Mar 2006 09:00:00 GMT

现在的开发技术的发展的速度比起开发者的学习速度不知道要快多少，每隔一两天就会有一个开源的工程诞生，学习如何去使用这些开源的工程不如学习一下其中的思想。比如Hibernate，ibatis等ORM等framework它只不过是帮你摆脱那些DAO模式为每个数据对象作一个DAO对象专门来负责数据库操作，你可以用一个统一的接口来进行数据库的操作。与其去专研如何去配置，如何去使用还不如去好好的研究一些他所体现的一些思想，比如数据库查询的优化，利用缓存机制，数据库连接池等等。
还有就是spring，它到底体现了什么是用来替换现在的J2EE的技术，不，就连spring的作者都说是在合时的情况下使用合适的技术，一句看似空洞的话却包含了深意。spring的核心思想在我看来就是DI，他在其他的open source的项目的基础上加以抽象，比如他提供了spring mvc--可以去使用底层的web mvc可以有很多，但是现在可以用一个统一的接口来调用，底层的实现机制与上层无关，这不证实了分层开发的思想吗，DI的思想正是用接口编程。
技术的快速的发展，给开发者带了很多的学习的难度，但是开发者如何来面对这种挑战，与其掌握如何去使用还不如去掌握它的思想。只有掌握了思想是用时才会有更深的理解。

java执著者 2006-03-27 17:00 发表评论

BlogJava

java执著者 — Wed, 08 Mar 2006 12:52:00 GMT

今天来了BlogJava开了自己的Bolg，工作了一年，在公司中用java的机会并不是很多，但是在有限的几个项目中我都选择了java作为我的开发语言，并且用了许多开源的java的工具，Hibernate，Ant，Log4J，Dom4j等等，我是一个追求新事物的人，对于眼前那许许多多的java的开源的项目，我也有些茫然。然而上个礼拜去Sybase公司面试的经历，却让我重新认识了原来我懂得尽然是那么少。Java的本质是什么，JVM是怎么工作的，gc是怎么工作的，ClassLoad是什么样的，现在的程序员有几个人能真正回答的完整的，也许很少。看着那些滔滔不绝说出现了什么新技术的人，我只有暗地里感到，我真的想奉劝那些朋友有空好好去看看JVM的书，不要满口说什么新的技术。

java执著者 2006-03-08 20:52 发表评论