Java

          BlogJava 首頁 新隨筆 聯(lián)系 聚合 管理
            8 Posts :: 0 Stories :: 1 Comments :: 0 Trackbacks

          2006年6月29日 #

          Q 什么是MIME?什么是MIME郵件?

          A MIME, 全稱為“Multipurpose Internet Mail Extensions”, 比較確切的中文名稱為“多用途互聯(lián)網(wǎng)郵件擴(kuò)展”。它是當(dāng)前廣泛應(yīng)用的一種電子郵件技術(shù)規(guī)范,基本內(nèi)容定義于RFC 2045-2049。

          自然,MIME郵件就是符合MIME規(guī)范的電子郵件,或者說根據(jù)MIME規(guī)范編碼而成的電子郵件。

          在MIME出臺(tái)之前,使用RFC 822只能發(fā)送基本的ASCII碼文本信息,郵件內(nèi)容如果要包括二進(jìn)制文件、聲音和動(dòng)畫等,實(shí)現(xiàn)起來非常困難。MIME提供了一種可以在郵件中附加多種不 同編碼文件的方法,彌補(bǔ)了原來的信息格式的不足。實(shí)際上不僅僅是郵件編碼,現(xiàn)在MIME經(jīng)成為HTTP協(xié)議標(biāo)準(zhǔn)的一個(gè)部分。

          下面舉幾個(gè)MIME郵件的例子,讓我們先對(duì)MIME編碼的格式有個(gè)直觀的印象。例1是最簡單的,只帶純文本 正文,基本上就是RFC 822格式;例2復(fù)雜一些,包含純文本和超文本正文;例3是最復(fù)雜的,包含純文本正文、超文本正文、內(nèi)嵌資源和文件附件。其中,行號(hào)和行號(hào)后的空格是為了 分析方便而另外加的,“... ... ... ...”表示此處省略了大段編碼。

          例1

             1 Date: Thu, 18 Apr 2002 09:32:45 +0800
          2 From: <bhw98@sina.com>
          3 To: <bhwang@jlonline.com>
          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" <bhw98@sina.com>
          2 Reply-To: bhw98@sina.com
          3 To: <bluesky7810@163.com>
          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 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
          37 <HTML><HEAD>
          38 <META content=3D"text/html; charset=3Dgb2312"=
          39 http-equiv=3DContent-Type>
          40 <META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR>
          ... ... ... ...
          79 </HTML>
          80
          81 --=====002_Dragon307572345230_=====--
          82

          例3

             1 Return-Path: <bluesky7810@163.com>
          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==?=" <bluesky7810@163.com>
          8 To: "bhw98" <bhw98@sina.com>
          9 Cc: <bhwang@jlonline.com>
          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 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
          45 <HTML><HEAD><TITLE>=C7=E7=C0=CA</TITLE>
          46 <META content=3D"text/html; charset=3Dgb2312" http-equiv=3DContent-Type>
          47 <STYLE>BODY {
          48 COLOR: #0033cc; FONT-FAMILY: =CB=CE=CC=E5, Arial, Helvetica; FONT-SIZE: =
          49 9pt; MARGIN-LEFT: 10px; MARGIN-TOP: 25px
          50 }
          51 </STYLE>
          52 <META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR></HEAD>
          53 <BODY background=3Dcid:007901c3111c$72b978a0$0100007f@bluesky =
          54 bgColor=3D#ffffff>
          55 <DIV>
          56 <DIV>bhw98, =C4=E3=BA=C3!</DIV>
          57 <P>=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!</P></DIV>
          59 <P> </P></BODY></HTML>
          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郵件的時(shí)候,如何得到這樣的源碼?

          A 一些功能比較完善的郵件客戶端軟件,如微軟的Outlook Express,國產(chǎn)的Foxmail等,都提供了查看和保存郵件源碼(原始信息)的功能。在Foxmail中,選擇郵件列表右鍵菜單的“原始信息”進(jìn)行 查看,主菜單的“文件-導(dǎo)出”進(jìn)行保存。在Outlook Express中,對(duì)應(yīng)的操作分別是“屬性”和“另存為”。所保存的.eml文件,可以調(diào)用這些程序打開。

          Q 請(qǐng)介紹一下MIME郵件的組成?

          A 總體來說,MIME消息由消息頭和消息體兩大部分組成。現(xiàn)在我們關(guān)注的是MIME郵件,因此在以下的討論中姑且稱“消息”為“郵件”。在上面的例子中,例 1的1-6行,例2的1—8行,例3的1-18行,是郵件頭;例1的8—9行,例2的10—82行,例3的20—3128行,是郵件體。郵件頭與郵件體之 間以空行進(jìn)行分隔,如例1的第7行,例2的第9行,例3的第19行。郵件頭中不允許出現(xiàn)空行。有一些郵件不能被郵件客戶端軟件識(shí)別,顯示的是原始碼,就是 因?yàn)槭仔惺强招小?

          郵件頭包含了發(fā)件人、收件人、主題、時(shí)間、MIME版本、郵件內(nèi)容的類型等重要信息。每條信息稱為一個(gè)域, 由域名后加“: ”和信息內(nèi)容構(gòu)成,可以是一行,較長的也可以占用多行。域的首行必須“頂頭”寫,即左邊不能有空白字符(空格和制表符);續(xù)行則必須以空白字符打頭,且第 一個(gè)空白字符不是信息本身固有的,解碼時(shí)要過濾掉。如例2的7-8行,例3的4-5行,13-14行,分別屬于一個(gè)域。

          郵件體包含郵件的內(nèi)容,它的類型由郵件頭的“Content-Type”域指出。常見的簡單類型有text/plain(純文本)和text/html(超文本)。

          例2和例3中出現(xiàn)的multipart類型,是MIME郵件的精髓。郵件體被分為多個(gè)段,每個(gè)段又包含段頭和 段體兩部分,這兩部分之間也以空行分隔。常見的multipart類型有三種:multipart/mixed, multipart/related和multipart/alternative。從它們的名稱,不難推知這些類型各自的含義和用處。它們之間的層次關(guān) 系可歸納為下圖所示:

          +------------------------- multipart/mixed ----------------------------+
          | |
          | +----------------- multipart/related ------------------+ |
          | | | |
          | | +----- multipart/alternative ------+ +----------+ | +------+ |
          | | | | | 內(nèi)嵌資源 | | | 附件 | |
          | | | +------------+ +------------+ | +----------+ | +------+ |
          | | | | 純文本正文 | | 超文本正文 | | | |
          | | | +------------+ +------------+ | +----------+ | +------+ |
          | | | | | 內(nèi)嵌資源 | | | 附件 | |
          | | +----------------------------------+ +----------+ | +------+ |
          | | | |
          | +------------------------------------------------------+ |
          | |
          +----------------------------------------------------------------------+

          可以看出,如果在郵件中要添加附件,必須定義multipart/mixed段;如果存在內(nèi)嵌資源,至少要定義 multipart/related段;如果純文本與超文本共存,至少要定義multipart/alternative段。什么是“至少”?舉個(gè)例子 說,如果只有純文本與超文本正文,那么在郵件頭中將類型擴(kuò)大化,定義為multipart/related,甚至multipart/mixed,都是允 許的。

          multipart諸類型的共同特征是,在段頭指定“boundary”參數(shù)字符串,段體內(nèi)的每個(gè)子段以此 串定界。所有的子段都以“--”+boundary行開始,父段則以“--”+boundary+“--”行結(jié)束。段與段之間也以空行分隔。在郵件體是 multipart類型的情況下,郵件體的開始部分(第一個(gè)“--”+boundary行之前)可以有一些附加的文本行,相當(dāng)于注釋,解碼時(shí)應(yīng)忽略。段間 也可以有一些附加的文本行,不會(huì)顯示出來,如果有興趣,不妨驗(yàn)證一下。

          結(jié)合boundary定界和multipart層次關(guān)系圖,我們分析一下例2和例3的郵件體層次與段嵌套關(guān)系。

          在例2中,10-12行是附加文本行,13-82行是multipart/alternative型的段,包含兩個(gè)子段:13-30行是純文本正文,32-79行是超文本正文。

          在例3中,20-21行是附加文本行,22-3127行是multipart/mixed型的段,包含3個(gè)子 段:22-171行是multipart/related段,173-1688行與1690-3125行是兩個(gè)附件。multipart/related 段又包含兩個(gè)子段:27-61行是multipart/alternative段,63-169行是一個(gè)內(nèi)嵌資源(圖片)。 multipart/alternative段又包含兩個(gè)子段:31-48行是純文本正文,40-59行是超文本正文。

          例1只有純文本正文,實(shí)際上屬于multipart層次關(guān)系圖中的一個(gè)特殊情況。如果非要避簡就繁,寫成下面的形式,也是完全符合MIME精神的。

          Date: Thu, 18 Apr 2002 09:32:45 +0800
          From: <bhw98@sina.com>
          To: <bhwang@jlonline.com>
          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也增加了一些。常見的標(biāo)準(zhǔn)域名和含義如下
          域名 含義 添加者
          Received 傳輸路徑 各級(jí)郵件服務(wù)器
          Return-Path 回復(fù)地址 目標(biāo)郵件服務(wù)器
          Delivered-To 發(fā)送地址 目標(biāo)郵件服務(wù)器
          Reply-To 回復(fù)地址 郵件的創(chuàng)建者
          From 發(fā)件人地址 郵件的創(chuàng)建者
          To 收件人地址 郵件的創(chuàng)建者
          Cc 抄送地址 郵件的創(chuàng)建者
          Bcc 暗送地址 郵件的創(chuàng)建者
          Date 日期和時(shí)間 郵件的創(chuàng)建者
          Subject 主題 郵件的創(chuàng)建者
          Message-ID 消息ID 郵件的創(chuàng)建者
          MIME-Version MIME版本 郵件的創(chuàng)建者
          Content-Type 內(nèi)容的類型 郵件的創(chuàng)建者
          Content-Transfer-Encoding 內(nèi)容的傳輸編碼方式 郵件的創(chuàng)建者

          非標(biāo)準(zhǔn)的、自定義域名都以X-開頭,例如X-Mailer, X-MSMail-Priority等,通常在接收和發(fā)送郵件的是同一程序時(shí)才能理解它們的意義。

          在段頭中,大致有如下一些域
          域名 含義
          Content-Type 段體的類型
          Content-Transfer-Encoding 段體的傳輸編碼方式
          Content-Disposition 段體的安排方式
          Content-ID 段體的ID
          Content-Location 段體的位置(路徑)
          Content-Base 段體的基位置

          有的域除了值之外,還帶有參數(shù)。值與參數(shù)、參數(shù)與參數(shù)之間以“;”分隔。參數(shù)名與參數(shù)值之間以“=”分隔。如 例3的28-29行,Content-Type域的值為“multipart/alternative”,此外有一個(gè)參數(shù)boundary,值為"--- -=_NextPart_002_007C_01C3115F.80DFC5E0"。又如例3的第176行,Content-Disposition域的 值為“attachment”,此外有一個(gè)參數(shù)filename,值為“readme.doc”。

          Q Content-Type以及它們的參數(shù)有哪些形式?

          A Content-Type都是“主類型/子類型”的形式。主類型有text, image, audio, video, application, multipart, message等,分別表示文本、圖片、音頻、視頻、應(yīng)用、分段、消息等。每個(gè)主類型都可能有多個(gè)子類型,如text類型就包含plain, html, xml, css等子類型。以X-開頭的主類型和子類型,同樣表示自定義的類型,未向IANA正式注冊(cè),但大多已經(jīng)約定成俗了。如application/x- zip-compressed是ZIP文件類型。在Windows中,注冊(cè)表的“HKEY_CLASSES_ROOT\MIME\Database\ Content Type”內(nèi)列舉了除multipart之外大部分已知的Content-Type。

          關(guān)于參數(shù)的形式,RFC里有很多補(bǔ)充規(guī)定,有的允許帶幾個(gè)參數(shù),較為常見的有
          主類型 參數(shù)名 含義
          text charset 字符集
          image name 名稱
          application name 名稱
          multipart boundary 邊界

          其中字符集也能在Windows注冊(cè)表的“HKEY_CLASSES_ROOT\MIME\Database\Charset”內(nèi)見到。

          Q Content-Transfer-Encoding有哪些?有什么特點(diǎn)?

          A Content-Transfer-Encoding共有Base64, Quoted-printable, 7bit, 8bit, Binary等幾種。其中7bit是缺省的編碼方式。電子郵件源碼最初設(shè)計(jì)為全部是可打印的ASCII碼的形式。非ASCII碼的文本或數(shù)據(jù)要編碼成要求 的格式,如上面的三個(gè)例子。Base64, Quoted-Printable是在非英語國家使用最廣使的編碼方式。Binary方式只具有象征意義,而沒有任何實(shí)用價(jià)值。

          Base64將輸入的字符串或一段數(shù)據(jù)編碼成只含有{'A'-'Z', 'a'-'z', '0'-'9', '+', '/'}這64個(gè)字符的串,'='用于填充。其編碼的方法是,將輸入數(shù)據(jù)流每次取6 bit,用此6 bit的值(0-63)作為索引去查表,輸出相應(yīng)字符。這樣,每3個(gè)字節(jié)將編碼為4個(gè)字符(3×8 → 4×6);不滿4個(gè)字符的以'='填充。有的場(chǎng)合,以“=?charset?B?xxxxxxxx?=”表示xxxxxxxx是Base64編碼,且原文 的字符集是charset。如例3第7行"=?gb2312?B?wLbAtrXEzOwNCg==?="是由簡體中文“藍(lán)藍(lán)的天”編碼而成的。在段體內(nèi) 則直接編碼,適當(dāng)時(shí)機(jī)換行,MIME建議每行最多76個(gè)字符。如例3的1697-3125行,是一個(gè)ZIP文件的Base64編碼。

          Quoted-printable根據(jù)輸入的字符串或字節(jié)范圍進(jìn)行編碼,若是不需編碼的字符,直接輸出;若 需要編碼,則先輸出'=',后面跟著以2個(gè)字符表示的十六進(jìn)制字節(jié)值。有的場(chǎng)合,以“=?charset?Q?xxxxxxxx?=”表示 xxxxxxxx是Quoted-printable編碼,且原文的字符集是charset。在段體內(nèi)則直接編碼,適當(dāng)時(shí)機(jī)換行,換行前額外輸出一個(gè)'= '。如例3的44-59行,是HTML文本的Quoted-printable編碼。其中第45行“=C7=E7=C0=CA”原文是“晴朗”,因?yàn)? “晴”的GB2312碼是C7E7,“朗”的GB2312碼是C0CA。第48、53、57行末尾只有孤零零的'=',表示這是由編碼造成的軟回車,而非 原文固有的。

          近年來,國內(nèi)多數(shù)郵件服務(wù)器已經(jīng)支持8bit方式,因此只在國內(nèi)傳輸?shù)泥]件,特別是在郵件頭中,可直接使用8bit編碼,對(duì)漢字不做處理。如果郵件要出國,還是老老實(shí)實(shí)地按Base64或Quoted-printable編碼才行。

          Q 什么是內(nèi)嵌資源?它有哪些形式?

          A 內(nèi)嵌資源也是MIME的一個(gè)發(fā)光點(diǎn),它能使郵件內(nèi)容變得生動(dòng)活潑、豐富多彩。可在郵件的multipart/related框架內(nèi)定義一些與正文關(guān)聯(lián)的圖 片、動(dòng)畫、聲音甚至CSS樣式和腳本的段。通常在HTML正文內(nèi),使用超級(jí)鏈接與內(nèi)嵌資源相聯(lián)系。如在例3中,HTML正文53-54行,解碼后為

          <BODY background=cid:007901c3111c$72b978a0$0100007f@bluesky bgColor=#ffffff>

          它指出用一個(gè)Content-ID為007901c3111c$72b978a0$0100007f@bluesky的圖片作為背景(cid:xxxxxxxx也是一種超級(jí)鏈接)。而64-169行恰好就是這樣一個(gè)內(nèi)嵌資源。

          除了用Content-ID進(jìn)行聯(lián)系外,還有另外一種常用形式:用普通超級(jí)連接和Content-Location。例如:

          在HTML正文中,

          ... ...  ... ...
          <IMG SRC="http://www.dangdang.com/images/all/anti_joyo_dm_book.gif">
          ... ... ... ...
          <IMG SRC="http://www.dangdang.com/dd2001/getimage_small.asp?id=486341">
          ... ... ... ...

          對(duì)應(yīng)的內(nèi)嵌資源為

          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 郵件病毒如何利用附件和內(nèi)嵌資源傳播?

          A 有的郵件附件可能帶有病毒,容易理解。附件畢竟是文件,也好預(yù)防,不輕易打開就是了。但內(nèi)嵌資源是在瀏覽郵件內(nèi)容時(shí)就要訪問的,若其中藏有病毒或惡意代碼,你在不知不覺中就中招了。如前兩年曾經(jīng)在全球范圍內(nèi)流行的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

          <HTML><HEAD></HEAD><BODY bgColor=#ffffff>
          <iframe src=cid:EA4DMGBP9p height=0 width=0>
          </iframe></BODY></HTML>
          --====_ABC0987654321DEF_====--

          --====_ABC1234567890DEF_====
          Content-Type: audio/x-wav; name="readme.exe"
          Content-Transfer-Encoding: base64
          Content-ID: <EA4DMGBP9p>

          TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
          AAAA2AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v
          ZGUuDQ0KJAAAAAAAAAA11CFvcbVPPHG1TzxxtU88E6pcPHW1TzyZqkU8dbVPPJmqSzxytU88cbVO
          ... ... ... ... ... ... ... ...
          AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=

          --====_ABC1234567890DEF_====

          它將一個(gè)可執(zhí)行文件作為資源嵌入了框架型頁面,卻聲明這段可執(zhí)行代碼是波形聲音類型。由于當(dāng)時(shí)微軟的IE(版本5.0 及以下)存在重大安全漏洞,沒有檢查Content-Type與name的擴(kuò)展名是否匹配,于是就被輕易騙過了,致使點(diǎn)選或打開郵件時(shí)自動(dòng)運(yùn)行了這個(gè) “readme.exe”,機(jī)器就感染上病毒。帶毒的機(jī)器利用地址簿向別人發(fā)送帶毒的郵件,一傳十,十傳百,Nimda蠕蟲大行其道。

          縱觀歷史,病毒剛出來時(shí)是厲害,但沒有任何一種能夠持續(xù)肆虐下去。Nimda如此,SARS亦當(dāng)如此。曰:“多難興邦,眾志成城”,又曰:“非典終將倒下,城市精神永存”,相信我們定能很快戰(zhàn)勝“非典”!

          病毒庫升級(jí)是跟在新病毒屁股后進(jìn)行的,不要過分依賴殺毒軟件。一個(gè)良好的習(xí)慣是關(guān)閉郵件預(yù)覽功能,或者設(shè)定預(yù)覽純文本部分,先查看郵件源碼,確信排除病毒嫌疑后再打開。對(duì)陌生人發(fā)來的帶超文本正文的郵件,尤其要當(dāng)心。永遠(yuǎn)不要在郵件客戶端軟件內(nèi)直接打開附件。

          Q 一些垃圾郵件采取隱藏發(fā)件人的方式,如何追查它們來自哪里?

          A 從上面的郵件頭域名表中可以看出,郵件的創(chuàng)建者可以掌握大部分的域的內(nèi)容,但Received等域由各級(jí)服務(wù)器自動(dòng)添加,發(fā)件人是鞭長莫及。垃圾郵件一般 采用了群發(fā)軟件發(fā)送,郵件頭的From域(發(fā)件人地址)可以任意偽造,甚至寫成收件人地址(收到了自己并沒有發(fā)過的垃圾郵件,氣憤吧?)。查看 Received域(傳輸路徑)鏈可以找到真正的出處。每個(gè)服務(wù)器添加的Received語句都在郵件首,故最下面一個(gè)Received就包含了發(fā)件人所 用的SMTP或HTTP服務(wù)器,及最初的網(wǎng)關(guān)外部IP地址。

          Receive語句的基本格式是:from A by B。A為發(fā)送方,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 <bhw98@sina.com>; 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 <bhw98@sina.com>; 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。恰好出現(xiàn)了發(fā)件人郵箱fanyingxxxx@tom.com,但多數(shù)情況不一定能列出來。

          此例的localhost [127.0.0.1],意味著bjapp9.163.net上安裝了郵件服務(wù)代理性質(zhì)的軟件。

          posted @ 2007-12-01 16:36 java執(zhí)著者 閱讀(1305) | 評(píng)論 (0)編輯 收藏

          Java中文問題一直困擾著很多初學(xué)者,如果了解了Java系統(tǒng)的中文問題原理,我們就可以對(duì)中文問題能夠采取根本的解決之道。

            最古老的解決方案是使用String的字節(jié)碼轉(zhuǎn)換,這種方案問題是不方便,我們需要破壞對(duì)象封裝性,進(jìn)行字節(jié)碼轉(zhuǎn)換。

            還有一種方式是對(duì)J2EE容器進(jìn)行編碼設(shè)置,如果J2EE應(yīng)用系統(tǒng)脫離該容器,則會(huì)發(fā)生亂碼,而且指定容器配置不符合J2EE應(yīng)用和容器分離的原則。

          在Java內(nèi)部運(yùn)算中,涉及到的所有字符串都會(huì)被轉(zhuǎn)化為UTF-8編碼來進(jìn)行運(yùn)算。那么,在被Java轉(zhuǎn)化之前,字符串是什么樣的字符集? Java總是根據(jù)操作系統(tǒng)的默認(rèn)編碼字符集來決定字符串的初始編碼,而且Java系統(tǒng)的輸入和輸出的都是采取操作系統(tǒng)的默認(rèn)編碼。

            因 此,如果能統(tǒng)一Java系統(tǒng)的輸入、輸出和操作系統(tǒng)3者的編碼字符集合,將能夠使Java系統(tǒng)正確處理和顯示漢字。這是處理Java系統(tǒng)漢字的一個(gè)原則, 但是在實(shí)際項(xiàng)目中,能夠正確抓住和控制住Java系統(tǒng)的輸入和輸出部分是比較難的。J2EE中,由于涉及到外部瀏覽器和數(shù)據(jù)庫等,所以中文問題亂碼顯得非 常突出。

            J2EE應(yīng)用程序是運(yùn)行在J2EE容器中。在這個(gè)系統(tǒng)中,輸入途徑有很多種:一種是通過頁面表單打包成請(qǐng)求(request) 發(fā)往服務(wù)器的;第二種是通過數(shù)據(jù)庫讀入;還有第3種輸入比較復(fù)雜,JSP在第一次運(yùn)行時(shí)總是被編譯成Servlet,JSP中常常包含中文字符,那么編譯 使用javac時(shí),Java將根據(jù)默認(rèn)的操作系統(tǒng)編碼作為初始編碼。除非特別指定,如在Jbuilder/eclipse中可以指定默認(rèn)的字符集。

            輸出途徑也有幾種:第一種是JSP頁面的輸出。由于JSP頁面已經(jīng)被編譯成Servlet,那么在輸出時(shí),也將根據(jù)操作系統(tǒng)的默認(rèn)編碼來選擇輸出編碼,除非指定輸出編碼方式;還有輸出途徑是數(shù)據(jù)庫,將字符串輸出到數(shù)據(jù)庫。

            由此看來,一個(gè)J2EE系統(tǒng)的輸入輸出是非常復(fù)雜,而且是動(dòng)態(tài)變化的,而Java是跨平臺(tái)運(yùn)行的,在實(shí)際編譯和運(yùn)行中,都可能涉及到不同的操作系統(tǒng),如果任由Java自由根據(jù)操作系統(tǒng)來決定輸入輸出的編碼字符集,這將不可控制地出現(xiàn)亂碼。

            正是由于Java的跨平臺(tái)特性,使得字符集問題必須由具體系統(tǒng)來統(tǒng)一解決,所以在一個(gè)Java應(yīng)用系統(tǒng)中,解決中文亂碼的根本辦法是明確指定整個(gè)應(yīng)用系統(tǒng)統(tǒng)一字符集。

            指定統(tǒng)一字符集時(shí),到底是指定ISO8859_1 、GBK還是UTF-8呢?

            (1)如統(tǒng)一指定為ISO8859_1,因?yàn)槟壳按蠖鄶?shù)軟件都是西方人編制的,他們默認(rèn)的字符集就是ISO8859_1,包括操作系統(tǒng)Linux和數(shù)據(jù)庫MySQL等。這樣,如果指定Jive統(tǒng)一編碼為ISO8859_1,那么就有下面3個(gè)環(huán)節(jié)必須把握:

            開發(fā)和編譯代碼時(shí)指定字符集為ISO8859_1。

            運(yùn)行操作系統(tǒng)的默認(rèn)編碼必須是ISO8859_1,如Linux。

            在JSP頭部聲明:<%@ page contentType="text/html;charset=ISO8859_1" %>。

            (2)如果統(tǒng)一指定為GBK中文字符集,上述3個(gè)環(huán)節(jié)同樣需要做到,不同的是只能運(yùn)行在默認(rèn)編碼為GBK的操作系統(tǒng),如中文Windows。

            統(tǒng)一編碼為ISO8859_1和GBK雖然帶來編制代碼的方便,但是各自只能在相應(yīng)的操作系統(tǒng)上運(yùn)行。但是也破壞了Java跨平臺(tái)運(yùn)行的優(yōu)越性,只在一定范圍內(nèi)行得通。例如,為了使得GBK編碼在linux上運(yùn)行,設(shè)置Linux編碼為GBK。

            那么有沒有一種除了應(yīng)用系統(tǒng)以外不需要進(jìn)行任何附加設(shè)置的中文編碼根本解決方案呢?

            將Java/J2EE系統(tǒng)的統(tǒng)一編碼定義為UTF-8。UTF-8編碼是一種兼容所有語言的編碼方式,惟一比較麻煩的就是要找到應(yīng)用系統(tǒng)的所有出入口,然后使用UTF-8去“結(jié)扎”它。

            一個(gè)J2EE應(yīng)用系統(tǒng)需要做下列幾步工作:

          1. 開發(fā)和編譯代碼時(shí)指定字符集為UTF-8。JBuilder和Eclipse都可以在項(xiàng)目屬性中設(shè)置。
          2. 使用過濾器,如果所有請(qǐng)求都經(jīng)過一個(gè)Servlet控制分配器,那么使用Servlet的filter執(zhí)行語句,將所有來自瀏覽器的請(qǐng)求(request)轉(zhuǎn)換為UTF-8,因?yàn)闉g覽器發(fā)過來的請(qǐng)求包根據(jù)瀏覽器所在的操作系統(tǒng)編碼,可能是各種形式編碼。關(guān)鍵一句:
            request.setCharacterEncoding("UTF-8")。
            網(wǎng)上有此filter的源碼,Jdon框架源碼中com.jdon.util.SetCharacterEncodingFilter
            需要配置web.xml 激活該Filter。
          3. 在JSP頭部聲明:<%@ page contentType="text/html;charset= UTF-8" %>。
          4. 在Jsp的html代碼中,聲明UTF-8:
            <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
          5. 設(shè)定數(shù)據(jù)庫連接方式是UTF-8。例如連接MYSQL時(shí)配置URL如下:
            jdbc:mysql://localhost:3306/test?useUnicode=true&amp;characterEncoding=UTF-8
            注意,上述寫法是JBoss的mysql-ds.xml寫法,多虧網(wǎng)友提示,在tomcat中&amp;要寫成&即可。一般其他數(shù)據(jù)庫都可以通過管理設(shè)置設(shè)定UTF-8
          6. 其他和外界交互時(shí)能夠設(shè)定編碼時(shí)就設(shè)定UTF-8,例如讀取文件,操作XML等。
          筆者以前在Jsp/Servlet時(shí)就采取這個(gè)原則,后來使用Struts、Tapestry、EJB、Hibernate、Jdon等框架時(shí),從未被亂 碼困擾過,可以說適合各種架構(gòu)。希望本方案供更多初學(xué)者分享,減少Java/J2EE的第一個(gè)攔路虎,也避免因?yàn)椴扇∫恍┡R時(shí)解決方案,導(dǎo)致中文問題一直 出現(xiàn)在新的技術(shù)架構(gòu)中 
          posted @ 2007-09-20 11:07 java執(zhí)著者 閱讀(1057) | 評(píng)論 (0)編輯 收藏

          標(biāo)題:Session詳解
          [評(píng)論]

          作者:郎云鵬(dev2dev ID: hippiewolf)

          摘要:雖然session機(jī)制在web應(yīng)用程序中被采用已經(jīng)很長時(shí)間了,但是仍然有很多人不清楚session機(jī)制的本質(zhì),以至不能正確的應(yīng)用這一技術(shù)。本文將詳細(xì)討論session的工作機(jī)制并且對(duì)在Java web application中應(yīng)用session機(jī)制時(shí)常見的問題作出解答。

          目錄:
          一、術(shù)語session
          二、HTTP協(xié)議與狀態(tài)保持
          三、理解cookie機(jī)制
          四、理解session機(jī)制
          五、理解javax.servlet.http.HttpSession
          六、HttpSession常見問題
          七、跨應(yīng)用程序的session共享
          八、總結(jié)
          參考文檔

          一、術(shù)語session
          在我的經(jīng)驗(yàn)里,session這個(gè)詞被濫用的程度大概僅次于transaction,更加有趣的是transaction與session在某些語境下的含義是相同的。

          session,中文經(jīng)常翻譯為會(huì)話,其本來的含義是指有始有終的一系列動(dòng)作/消息,比如打電話時(shí)從拿起電話撥號(hào)到掛斷電話這中間的一系列過程可以稱之為一個(gè)session。有時(shí)候我們可以看到這樣的話“在一個(gè)瀏覽器會(huì)話期間,...”,這里的會(huì)話一詞用的就是其本義,是指從一個(gè)瀏覽器窗口打開到關(guān)閉這個(gè)期間①。最混亂的是“用戶(客戶端)在一次會(huì)話期間”這樣一句話,它可能指用戶的一系列動(dòng)作(一般情況下是同某個(gè)具體目的相關(guān)的一系列動(dòng)作,比如從登錄到選購商品到結(jié)賬登出這樣一個(gè)網(wǎng)上購物的過程,有時(shí)候也被稱為一個(gè)transaction),然而有時(shí)候也可能僅僅是指一次連接,也有可能是指含義①,其中的差別只能靠上下文來推斷②。

          然而當(dāng)session一詞與網(wǎng)絡(luò)協(xié)議相關(guān)聯(lián)時(shí),它又往往隱含了“面向連接”和/或“保持狀態(tài)”這樣兩個(gè)含義,“面向連接”指的是在通信雙方在通信之前要先建立一個(gè)通信的渠道,比如打電話,直到對(duì)方接了電話通信才能開始,與此相對(duì)的是寫信,在你把信發(fā)出去的時(shí)候你并不能確認(rèn)對(duì)方的地址是否正確,通信渠道不一定能建立,但對(duì)發(fā)信人來說,通信已經(jīng)開始了。“保持狀態(tài)”則是指通信的一方能夠把一系列的消息關(guān)聯(lián)起來,使得消息之間可以互相依賴,比如一個(gè)服務(wù)員能夠認(rèn)出再次光臨的老顧客并且記得上次這個(gè)顧客還欠店里一塊錢。這一類的例子有“一個(gè)TCP session”或者“一個(gè)POP3 session”③。

          而到了web服務(wù)器蓬勃發(fā)展的時(shí)代,session在web開發(fā)語境下的語義又有了新的擴(kuò)展,它的含義是指一類用來在客戶端與服務(wù)器之間保持狀態(tài)的解決方案④。有時(shí)候session也用來指這種解決方案的存儲(chǔ)結(jié)構(gòu),如“把xxx保存在session里”⑤。由于各種用于web開發(fā)的語言在一定程度上都提供了對(duì)這種解決方案的支持,所以在某種特定語言的語境下,session也被用來指代該語言的解決方案,比如經(jīng)常把Java里提供的javax.servlet.http.HttpSession簡稱為session⑥。

          鑒于這種混亂已不可改變,本文中session一詞的運(yùn)用也會(huì)根據(jù)上下文有不同的含義,請(qǐng)大家注意分辨。
          在本文中,使用中文“瀏覽器會(huì)話期間”來表達(dá)含義①,使用“session機(jī)制”來表達(dá)含義④,使用“session”表達(dá)含義⑤,使用具體的“HttpSession”來表達(dá)含義⑥

          二、HTTP協(xié)議與狀態(tài)保持
          HTTP協(xié)議本身是無狀態(tài)的,這與HTTP協(xié)議本來的目的是相符的,客戶端只需要簡單的向服務(wù)器請(qǐng)求下載某些文件,無論是客戶端還是服務(wù)器都沒有必要紀(jì)錄彼此過去的行為,每一次請(qǐng)求之間都是獨(dú)立的,好比一個(gè)顧客和一個(gè)自動(dòng)售貨機(jī)或者一個(gè)普通的(非會(huì)員制)大賣場(chǎng)之間的關(guān)系一樣。

          然而聰明(或者貪心?)的人們很快發(fā)現(xiàn)如果能夠提供一些按需生成的動(dòng)態(tài)信息會(huì)使web變得更加有用,就像給有線電視加上點(diǎn)播功能一樣。這種需求一方面迫使HTML逐步添加了表單、腳本、DOM等客戶端行為,另一方面在服務(wù)器端則出現(xiàn)了CGI規(guī)范以響應(yīng)客戶端的動(dòng)態(tài)請(qǐng)求,作為傳輸載體的HTTP協(xié)議也添加了文件上載、cookie這些特性。其中cookie的作用就是為了解決HTTP協(xié)議無狀態(tài)的缺陷所作出的努力。至于后來出現(xiàn)的session機(jī)制則是又一種在客戶端與服務(wù)器之間保持狀態(tài)的解決方案。

          讓我們用幾個(gè)例子來描述一下cookie和session機(jī)制之間的區(qū)別與聯(lián)系。筆者曾經(jīng)常去的一家咖啡店有喝5杯咖啡免費(fèi)贈(zèng)一杯咖啡的優(yōu)惠,然而一次性消費(fèi)5杯咖啡的機(jī)會(huì)微乎其微,這時(shí)就需要某種方式來紀(jì)錄某位顧客的消費(fèi)數(shù)量。想象一下其實(shí)也無外乎下面的幾種方案:
          1、該店的店員很厲害,能記住每位顧客的消費(fèi)數(shù)量,只要顧客一走進(jìn)咖啡店,店員就知道該怎么對(duì)待了。這種做法就是協(xié)議本身支持狀態(tài)。
          2、發(fā)給顧客一張卡片,上面記錄著消費(fèi)的數(shù)量,一般還有個(gè)有效期限。每次消費(fèi)時(shí),如果顧客出示這張卡片,則此次消費(fèi)就會(huì)與以前或以后的消費(fèi)相聯(lián)系起來。這種做法就是在客戶端保持狀態(tài)。
          3、發(fā)給顧客一張會(huì)員卡,除了卡號(hào)之外什么信息也不紀(jì)錄,每次消費(fèi)時(shí),如果顧客出示該卡片,則店員在店里的紀(jì)錄本上找到這個(gè)卡號(hào)對(duì)應(yīng)的紀(jì)錄添加一些消費(fèi)信息。這種做法就是在服務(wù)器端保持狀態(tài)。

          由于HTTP協(xié)議是無狀態(tài)的,而出于種種考慮也不希望使之成為有狀態(tài)的,因此,后面兩種方案就成為現(xiàn)實(shí)的選擇。具體來說cookie機(jī)制采用的是在客戶端保持狀態(tài)的方案,而session機(jī)制采用的是在服務(wù)器端保持狀態(tài)的方案。同時(shí)我們也看到,由于采用服務(wù)器端保持狀態(tài)的方案在客戶端也需要保存一個(gè)標(biāo)識(shí),所以session機(jī)制可能需要借助于cookie機(jī)制來達(dá)到保存標(biāo)識(shí)的目的,但實(shí)際上它還有其他選擇。

          三、理解cookie機(jī)制
          cookie機(jī)制的基本原理就如上面的例子一樣簡單,但是還有幾個(gè)問題需要解決:“會(huì)員卡”如何分發(fā);“會(huì)員卡”的內(nèi)容;以及客戶如何使用“會(huì)員卡”。

          正統(tǒng)的cookie分發(fā)是通過擴(kuò)展HTTP協(xié)議來實(shí)現(xiàn)的,服務(wù)器通過在HTTP的響應(yīng)頭中加上一行特殊的指示以提示瀏覽器按照指示生成相應(yīng)的cookie。然而純粹的客戶端腳本如JavaScript或者VBScript也可以生成cookie。

          而cookie的使用是由瀏覽器按照一定的原則在后臺(tái)自動(dòng)發(fā)送給服務(wù)器的。瀏覽器檢查所有存儲(chǔ)的cookie,如果某個(gè)cookie所聲明的作用范圍大于等于將要請(qǐng)求的資源所在的位置,則把該cookie附在請(qǐng)求資源的HTTP請(qǐng)求頭上發(fā)送給服務(wù)器。意思是麥當(dāng)勞的會(huì)員卡只能在麥當(dāng)勞的店里出示,如果某家分店還發(fā)行了自己的會(huì)員卡,那么進(jìn)這家店的時(shí)候除了要出示麥當(dāng)勞的會(huì)員卡,還要出示這家店的會(huì)員卡。

          cookie的內(nèi)容主要包括:名字,值,過期時(shí)間,路徑和域。
          其中域可以指定某一個(gè)域比如.google.com,相當(dāng)于總店招牌,比如寶潔公司,也可以指定一個(gè)域下的具體某臺(tái)機(jī)器比如www.google.com或者froogle.google.com,可以用飄柔來做比。
          路徑就是跟在域名后面的URL路徑,比如/或者/foo等等,可以用某飄柔專柜做比。
          路徑與域合在一起就構(gòu)成了cookie的作用范圍。
          如果不設(shè)置過期時(shí)間,則表示這個(gè)cookie的生命期為瀏覽器會(huì)話期間,只要關(guān)閉瀏覽器窗口,cookie就消失了。這種生命期為瀏覽器會(huì)話期的cookie被稱為會(huì)話cookie。會(huì)話cookie一般不存儲(chǔ)在硬盤上而是保存在內(nèi)存里,當(dāng)然這種行為并不是規(guī)范規(guī)定的。如果設(shè)置了過期時(shí)間,瀏覽器就會(huì)把cookie保存到硬盤上,關(guān)閉后再次打開瀏覽器,這些cookie仍然有效直到超過設(shè)定的過期時(shí)間。

          存儲(chǔ)在硬盤上的cookie可以在不同的瀏覽器進(jìn)程間共享,比如兩個(gè)IE窗口。而對(duì)于保存在內(nèi)存里的cookie,不同的瀏覽器有不同的處理方式。對(duì)于IE,在一個(gè)打開的窗口上按Ctrl-N(或者從文件菜單)打開的窗口可以與原窗口共享,而使用其他方式新開的IE進(jìn)程則不能共享已經(jīng)打開的窗口的內(nèi)存cookie;對(duì)于Mozilla Firefox0.8,所有的進(jìn)程和標(biāo)簽頁都可以共享同樣的cookie。一般來說是用javascript的window.open打開的窗口會(huì)與原窗口共享內(nèi)存cookie。瀏覽器對(duì)于會(huì)話cookie的這種只認(rèn)cookie不認(rèn)人的處理方式經(jīng)常給采用session機(jī)制的web應(yīng)用程序開發(fā)者造成很大的困擾。

          下面就是一個(gè)goolge設(shè)置cookie的響應(yīng)頭的例子
          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這個(gè)HTTP Sniffer軟件來俘獲的HTTP通訊紀(jì)錄的一部分


          瀏覽器在再次訪問goolge的資源時(shí)自動(dòng)向外發(fā)送cookie


          使用Firefox可以很容易的觀察現(xiàn)有的cookie的值
          使用HTTPLook配合Firefox可以很容易的理解cookie的工作原理。


          IE也可以設(shè)置在接受cookie前詢問


          這是一個(gè)詢問接受cookie的對(duì)話框。

          四、理解session機(jī)制
          session機(jī)制是一種服務(wù)器端的機(jī)制,服務(wù)器使用一種類似于散列表的結(jié)構(gòu)(也可能就是使用散列表)來保存信息。

          當(dāng)程序需要為某個(gè)客戶端的請(qǐng)求創(chuàng)建一個(gè)session的時(shí)候,服務(wù)器首先檢查這個(gè)客戶端的請(qǐng)求里是否已包含了一個(gè)session標(biāo)識(shí) - 稱為session id,如果已包含一個(gè)session id則說明以前已經(jīng)為此客戶端創(chuàng)建過session,服務(wù)器就按照session id把這個(gè)session檢索出來使用(如果檢索不到,可能會(huì)新建一個(gè)),如果客戶端請(qǐng)求不包含session id,則為此客戶端創(chuàng)建一個(gè)session并且生成一個(gè)與此session相關(guān)聯(lián)的session id,session id的值應(yīng)該是一個(gè)既不會(huì)重復(fù),又不容易被找到規(guī)律以仿造的字符串,這個(gè)session id將被在本次響應(yīng)中返回給客戶端保存。

          保存這個(gè)session id的方式可以采用cookie,這樣在交互過程中瀏覽器可以自動(dòng)的按照規(guī)則把這個(gè)標(biāo)識(shí)發(fā)揮給服務(wù)器。一般這個(gè)cookie的名字都是類似于SEEESIONID,而。比如weblogic對(duì)于web應(yīng)用程序生成的cookie,JSESSIONID=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764,它的名字就是JSESSIONID。

          由于cookie可以被人為的禁止,必須有其他機(jī)制以便在cookie被禁止時(shí)仍然能夠把session id傳遞回服務(wù)器。經(jīng)常被使用的一種技術(shù)叫做URL重寫,就是把session id直接附加在URL路徑的后面,附加方式也有兩種,一種是作為URL路徑的附加信息,表現(xiàn)形式為http://...../xxx;jsessionid=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764
          另一種是作為查詢字符串附加在URL后面,表現(xiàn)形式為http://...../xxx?jsessionid=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764
          這兩種方式對(duì)于用戶來說是沒有區(qū)別的,只是服務(wù)器在解析的時(shí)候處理的方式不同,采用第一種方式也有利于把session id的信息和正常程序參數(shù)區(qū)分開來。
          為了在整個(gè)交互過程中始終保持狀態(tài),就必須在每個(gè)客戶端可能請(qǐng)求的路徑后面都包含這個(gè)session id。

          另一種技術(shù)叫做表單隱藏字段。就是服務(wù)器會(huì)自動(dòng)修改表單,添加一個(gè)隱藏字段,以便在表單提交時(shí)能夠把session id傳遞回服務(wù)器。比如下面的表單
          <form name="testform" action="/xxx">
          <input type="text">
          </form>
          在被傳遞給客戶端之前將被改寫成
          <form name="testform" action="/xxx">
          <input type="hidden" name="jsessionid" value="ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764">
          <input type="text">
          </form>
          這種技術(shù)現(xiàn)在已較少應(yīng)用,筆者接觸過的很古老的iPlanet6(SunONE應(yīng)用服務(wù)器的前身)就使用了這種技術(shù)。
          實(shí)際上這種技術(shù)可以簡單的用對(duì)action應(yīng)用URL重寫來代替。

          在談?wù)搒ession機(jī)制的時(shí)候,常常聽到這樣一種誤解“只要關(guān)閉瀏覽器,session就消失了”。其實(shí)可以想象一下會(huì)員卡的例子,除非顧客主動(dòng)對(duì)店家提出銷卡,否則店家絕對(duì)不會(huì)輕易刪除顧客的資料。對(duì)session來說也是一樣的,除非程序通知服務(wù)器刪除一個(gè)session,否則服務(wù)器會(huì)一直保留,程序一般都是在用戶做log off的時(shí)候發(fā)個(gè)指令去刪除session。然而瀏覽器從來不會(huì)主動(dòng)在關(guān)閉之前通知服務(wù)器它將要關(guān)閉,因此服務(wù)器根本不會(huì)有機(jī)會(huì)知道瀏覽器已經(jīng)關(guān)閉,之所以會(huì)有這種錯(cuò)覺,是大部分session機(jī)制都使用會(huì)話cookie來保存session id,而關(guān)閉瀏覽器后這個(gè)session id就消失了,再次連接服務(wù)器時(shí)也就無法找到原來的session。如果服務(wù)器設(shè)置的cookie被保存到硬盤上,或者使用某種手段改寫瀏覽器發(fā)出的HTTP請(qǐng)求頭,把原來的session id發(fā)送給服務(wù)器,則再次打開瀏覽器仍然能夠找到原來的session。

          恰恰是由于關(guān)閉瀏覽器不會(huì)導(dǎo)致session被刪除,迫使服務(wù)器為seesion設(shè)置了一個(gè)失效時(shí)間,當(dāng)距離客戶端上一次使用session的時(shí)間超過這個(gè)失效時(shí)間時(shí),服務(wù)器就可以認(rèn)為客戶端已經(jīng)停止了活動(dòng),才會(huì)把session刪除以節(jié)省存儲(chǔ)空間。

          五、理解javax.servlet.http.HttpSession
          HttpSession是Java平臺(tái)對(duì)session機(jī)制的實(shí)現(xiàn)規(guī)范,因?yàn)樗鼉H僅是個(gè)接口,具體到每個(gè)web應(yīng)用服務(wù)器的提供商,除了對(duì)規(guī)范支持之外,仍然會(huì)有一些規(guī)范里沒有規(guī)定的細(xì)微差異。這里我們以BEA的Weblogic Server8.1作為例子來演示。

          首先,Weblogic Server提供了一系列的參數(shù)來控制它的HttpSession的實(shí)現(xiàn),包括使用cookie的開關(guān)選項(xiàng),使用URL重寫的開關(guān)選項(xiàng),session持久化的設(shè)置,session失效時(shí)間的設(shè)置,以及針對(duì)cookie的各種設(shè)置,比如設(shè)置cookie的名字、路徑、域,cookie的生存時(shí)間等。

          一般情況下,session都是存儲(chǔ)在內(nèi)存里,當(dāng)服務(wù)器進(jìn)程被停止或者重啟的時(shí)候,內(nèi)存里的session也會(huì)被清空,如果設(shè)置了session的持久化特性,服務(wù)器就會(huì)把session保存到硬盤上,當(dāng)服務(wù)器進(jìn)程重新啟動(dòng)或這些信息將能夠被再次使用,Weblogic Server支持的持久性方式包括文件、數(shù)據(jù)庫、客戶端cookie保存和復(fù)制。

          復(fù)制嚴(yán)格說來不算持久化保存,因?yàn)閟ession實(shí)際上還是保存在內(nèi)存里,不過同樣的信息被復(fù)制到各個(gè)cluster內(nèi)的服務(wù)器進(jìn)程中,這樣即使某個(gè)服務(wù)器進(jìn)程停止工作也仍然可以從其他進(jìn)程中取得session。

          cookie生存時(shí)間的設(shè)置則會(huì)影響瀏覽器生成的cookie是否是一個(gè)會(huì)話cookie。默認(rèn)是使用會(huì)話cookie。有興趣的可以用它來試驗(yàn)我們?cè)诘谒墓?jié)里提到的那個(gè)誤解。

          cookie的路徑對(duì)于web應(yīng)用程序來說是一個(gè)非常重要的選項(xiàng),Weblogic Server對(duì)這個(gè)選項(xiàng)的默認(rèn)處理方式使得它與其他服務(wù)器有明顯的區(qū)別。后面我們會(huì)專題討論。

          關(guān)于session的設(shè)置參考[5] http://e-docs.bea.com/wls/docs70/webapp/weblogic_xml.html#1036869

          六、HttpSession常見問題
          (在本小節(jié)中session的含義為⑤和⑥的混合)


          1、session在何時(shí)被創(chuàng)建
          一個(gè)常見的誤解是以為session在有客戶端訪問時(shí)就被創(chuàng)建,然而事實(shí)是直到某server端程序調(diào)用HttpServletRequest.getSession(true)這樣的語句時(shí)才被創(chuàng)建,注意如果JSP沒有顯示的使用 <%@page session="false"%> 關(guān)閉session,則JSP文件在編譯成Servlet時(shí)將會(huì)自動(dòng)加上這樣一條語句HttpSession session = HttpServletRequest.getSession(true);這也是JSP中隱含的session對(duì)象的來歷。

          由于session會(huì)消耗內(nèi)存資源,因此,如果不打算使用session,應(yīng)該在所有的JSP中關(guān)閉它。

          2、session何時(shí)被刪除
          綜合前面的討論,session在下列情況下被刪除a.程序調(diào)用HttpSession.invalidate();或b.距離上一次收到客戶端發(fā)送的session id時(shí)間間隔超過了session的超時(shí)設(shè)置;或c.服務(wù)器進(jìn)程被停止(非持久session)

          3、如何做到在瀏覽器關(guān)閉時(shí)刪除session
          嚴(yán)格的講,做不到這一點(diǎn)。可以做一點(diǎn)努力的辦法是在所有的客戶端頁面里使用javascript代碼window.oncolose來監(jiān)視瀏覽器的關(guān)閉動(dòng)作,然后向服務(wù)器發(fā)送一個(gè)請(qǐng)求來刪除session。但是對(duì)于瀏覽器崩潰或者強(qiáng)行殺死進(jìn)程這些非常規(guī)手段仍然無能為力。

          4、有個(gè)HttpSessionListener是怎么回事
          你可以創(chuàng)建這樣的listener去監(jiān)控session的創(chuàng)建和銷毀事件,使得在發(fā)生這樣的事件時(shí)你可以做一些相應(yīng)的工作。注意是session的創(chuàng)建和銷毀動(dòng)作觸發(fā)listener,而不是相反。類似的與HttpSession有關(guān)的listener還有HttpSessionBindingListener,HttpSessionActivationListener和HttpSessionAttributeListener。

          5、存放在session中的對(duì)象必須是可序列化的嗎
          不是必需的。要求對(duì)象可序列化只是為了session能夠在集群中被復(fù)制或者能夠持久保存或者在必要時(shí)server能夠暫時(shí)把session交換出內(nèi)存。在Weblogic Server的session中放置一個(gè)不可序列化的對(duì)象在控制臺(tái)上會(huì)收到一個(gè)警告。我所用過的某個(gè)iPlanet版本如果session中有不可序列化的對(duì)象,在session銷毀時(shí)會(huì)有一個(gè)Exception,很奇怪。

          6、如何才能正確的應(yīng)付客戶端禁止cookie的可能性
          對(duì)所有的URL使用URL重寫,包括超鏈接,form的action,和重定向的URL,具體做法參見[6]
          http://e-docs.bea.com/wls/docs70/webapp/sessions.html#100770

          7、開兩個(gè)瀏覽器窗口訪問應(yīng)用程序會(huì)使用同一個(gè)session還是不同的session
          參見第三小節(jié)對(duì)cookie的討論,對(duì)session來說是只認(rèn)id不認(rèn)人,因此不同的瀏覽器,不同的窗口打開方式以及不同的cookie存儲(chǔ)方式都會(huì)對(duì)這個(gè)問題的答案有影響。

          8、如何防止用戶打開兩個(gè)瀏覽器窗口操作導(dǎo)致的session混亂
          這個(gè)問題與防止表單多次提交是類似的,可以通過設(shè)置客戶端的令牌來解決。就是在服務(wù)器每次生成一個(gè)不同的id返回給客戶端,同時(shí)保存在session里,客戶端提交表單時(shí)必須把這個(gè)id也返回服務(wù)器,程序首先比較返回的id與保存在session里的值是否一致,如果不一致則說明本次操作已經(jīng)被提交過了。可以參看《J2EE核心模式》關(guān)于表示層模式的部分。需要注意的是對(duì)于使用javascript window.open打開的窗口,一般不設(shè)置這個(gè)id,或者使用單獨(dú)的id,以防主窗口無法操作,建議不要再window.open打開的窗口里做修改操作,這樣就可以不用設(shè)置。

          9、為什么在Weblogic Server中改變session的值后要重新調(diào)用一次session.setValue
          做這個(gè)動(dòng)作主要是為了在集群環(huán)境中提示W(wǎng)eblogic Server session中的值發(fā)生了改變,需要向其他服務(wù)器進(jìn)程復(fù)制新的session值。

          10、為什么session不見了
          排除session正常失效的因素之外,服務(wù)器本身的可能性應(yīng)該是微乎其微的,雖然筆者在iPlanet6SP1加若干補(bǔ)丁的Solaris版本上倒也遇到過;瀏覽器插件的可能性次之,筆者也遇到過3721插件造成的問題;理論上防火墻或者代理服務(wù)器在cookie處理上也有可能會(huì)出現(xiàn)問題。
          出現(xiàn)這一問題的大部分原因都是程序的錯(cuò)誤,最常見的就是在一個(gè)應(yīng)用程序中去訪問另外一個(gè)應(yīng)用程序。我們?cè)谙乱还?jié)討論這個(gè)問題。

          七、跨應(yīng)用程序的session共享

          常常有這樣的情況,一個(gè)大項(xiàng)目被分割成若干小項(xiàng)目開發(fā),為了能夠互不干擾,要求每個(gè)小項(xiàng)目作為一個(gè)單獨(dú)的web應(yīng)用程序開發(fā),可是到了最后突然發(fā)現(xiàn)某幾個(gè)小項(xiàng)目之間需要共享一些信息,或者想使用session來實(shí)現(xiàn)SSO(single sign on),在session中保存login的用戶信息,最自然的要求是應(yīng)用程序間能夠訪問彼此的session。

          然而按照Servlet規(guī)范,session的作用范圍應(yīng)該僅僅限于當(dāng)前應(yīng)用程序下,不同的應(yīng)用程序之間是不能夠互相訪問對(duì)方的session的。各個(gè)應(yīng)用服務(wù)器從實(shí)際效果上都遵守了這一規(guī)范,但是實(shí)現(xiàn)的細(xì)節(jié)卻可能各有不同,因此解決跨應(yīng)用程序session共享的方法也各不相同。

          首先來看一下Tomcat是如何實(shí)現(xiàn)web應(yīng)用程序之間session的隔離的,從Tomcat設(shè)置的cookie路徑來看,它對(duì)不同的應(yīng)用程序設(shè)置的cookie路徑是不同的,這樣不同的應(yīng)用程序所用的session id是不同的,因此即使在同一個(gè)瀏覽器窗口里訪問不同的應(yīng)用程序,發(fā)送給服務(wù)器的session id也可以是不同的。

          根據(jù)這個(gè)特性,我們可以推測(cè)Tomcat中session的內(nèi)存結(jié)構(gòu)大致如下。

          筆者以前用過的iPlanet也采用的是同樣的方式,估計(jì)SunONE與iPlanet之間不會(huì)有太大的差別。對(duì)于這種方式的服務(wù)器,解決的思路很簡單,實(shí)際實(shí)行起來也不難。要么讓所有的應(yīng)用程序共享一個(gè)session id,要么讓應(yīng)用程序能夠獲得其他應(yīng)用程序的session id。

          iPlanet中有一種很簡單的方法來實(shí)現(xiàn)共享一個(gè)session id,那就是把各個(gè)應(yīng)用程序的cookie路徑都設(shè)為/(實(shí)際上應(yīng)該是/NASApp,對(duì)于應(yīng)用程序來講它的作用相當(dāng)于根)。
          <session-info>
          <path>/NASApp</path>
          </session-info>

          需要注意的是,操作共享的session應(yīng)該遵循一些編程約定,比如在session attribute名字的前面加上應(yīng)用程序的前綴,使得setAttribute("name", "neo")變成setAttribute("app1.name", "neo"),以防止命名空間沖突,導(dǎo)致互相覆蓋。


          在Tomcat中則沒有這么方便的選擇。在Tomcat版本3上,我們還可以有一些手段來共享session。對(duì)于版本4以上的Tomcat,目前筆者尚未發(fā)現(xiàn)簡單的辦法。只能借助于第三方的力量,比如使用文件、數(shù)據(jù)庫、JMS或者客戶端cookie,URL參數(shù)或者隱藏字段等手段。

          我們?cè)倏匆幌耊eblogic Server是如何處理session的。

          從截屏畫面上可以看到Weblogic Server對(duì)所有的應(yīng)用程序設(shè)置的cookie的路徑都是/,這是不是意味著在Weblogic Server中默認(rèn)的就可以共享session了呢?然而一個(gè)小實(shí)驗(yàn)即可證明即使不同的應(yīng)用程序使用的是同一個(gè)session,各個(gè)應(yīng)用程序仍然只能訪問自己所設(shè)置的那些屬性。這說明Weblogic Server中的session的內(nèi)存結(jié)構(gòu)可能如下

          對(duì)于這樣一種結(jié)構(gòu),在session機(jī)制本身上來解決session共享的問題應(yīng)該是不可能的了。除了借助于第三方的力量,比如使用文件、數(shù)據(jù)庫、JMS或者客戶端cookie,URL參數(shù)或者隱藏字段等手段,還有一種較為方便的做法,就是把一個(gè)應(yīng)用程序的session放到ServletContext中,這樣另外一個(gè)應(yīng)用程序就可以從ServletContext中取得前一個(gè)應(yīng)用程序的引用。示例代碼如下,

          應(yīng)用程序A
          context.setAttribute("appA", session);

          應(yīng)用程序B
          contextA = context.getContext("/appA");
          HttpSession sessionA = (HttpSession)contextA.getAttribute("appA");

          值得注意的是這種用法不可移植,因?yàn)楦鶕?jù)ServletContext的JavaDoc,應(yīng)用服務(wù)器可以處于安全的原因?qū)τ赾ontext.getContext("/appA");返回空值,以上做法在Weblogic Server 8.1中通過。

          那么Weblogic Server為什么要把所有的應(yīng)用程序的cookie路徑都設(shè)為/呢?原來是為了SSO,凡是共享這個(gè)session的應(yīng)用程序都可以共享認(rèn)證的信息。一個(gè)簡單的實(shí)驗(yàn)就可以證明這一點(diǎn),修改首先登錄的那個(gè)應(yīng)用程序的描述符weblogic.xml,把cookie路徑修改為/appA訪問另外一個(gè)應(yīng)用程序會(huì)重新要求登錄,即使是反過來,先訪問cookie路徑為/的應(yīng)用程序,再訪問修改過路徑的這個(gè),雖然不再提示登錄,但是登錄的用戶信息也會(huì)丟失。注意做這個(gè)實(shí)驗(yàn)時(shí)認(rèn)證方式應(yīng)該使用FORM,因?yàn)闉g覽器和web服務(wù)器對(duì)basic認(rèn)證方式有其他的處理方式,第二次請(qǐng)求的認(rèn)證不是通過session來實(shí)現(xiàn)的。具體請(qǐng)參看[7] secion 14.8 Authorization,你可以修改所附的示例程序來做這些試驗(yàn)。

          八、總結(jié)
          session機(jī)制本身并不復(fù)雜,然而其實(shí)現(xiàn)和配置上的靈活性卻使得具體情況復(fù)雜多變。這也要求我們不能把僅僅某一次的經(jīng)驗(yàn)或者某一個(gè)瀏覽器,服務(wù)器的經(jīng)驗(yàn)當(dāng)作普遍適用的經(jīng)驗(yàn),而是始終需要具體情況具體分析。

          關(guān)于作者:
          郎云鵬(dev2dev ID: hippiewolf),軟件工程師,從事J2EE開發(fā)
          電子郵件:langyunpeng@yahoo.com.cn
          地址:大連軟件園路31號(hào)科技大廈A座大連博涵咨詢服務(wù)有限公司

          參考文檔:
          [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

          posted @ 2006-09-19 14:35 java執(zhí)著者 閱讀(1186) | 評(píng)論 (1)編輯 收藏

          這是一篇程序員寫給程序員的趣味讀物。所謂趣味是指可以比較輕松地了解一些原來不清楚的概念,增進(jìn)知識(shí),類似于打RPG游戲的升級(jí)。整理這篇文章的動(dòng)機(jī)是兩個(gè)問題:

          問題一:?

          使用Windows記事本的“另存為”,可以在GBK、Unicode、Unicode?big?endian和UTF-8這幾種編碼方式間相互轉(zhuǎn)換。同樣是txt文件,Windows是怎樣識(shí)別編碼方式的呢?

          我 很早前就發(fā)現(xiàn)Unicode、Unicode?big?endian和UTF-8編碼的txt文件的開頭會(huì)多出幾個(gè)字節(jié),分別是FF、FE (Unicode),FE、FF(Unicode?big?endian),EF、BB、BF(UTF-8)。但這些標(biāo)記是基于什么標(biāo)準(zhǔn)呢?

          問題二:?
          最 近在網(wǎng)上看到一個(gè)ConvertUTF.c,實(shí)現(xiàn)了UTF-32、UTF-16和UTF-8這三種編碼方式的相互轉(zhuǎn)換。對(duì)于Unicode(UCS2)、 GBK、UTF-8這些編碼方式,我原來就了解。但這個(gè)程序讓我有些糊涂,想不起來UTF-16和UCS2有什么關(guān)系。?

          查了查相關(guān)資料,總算將這些問題弄清楚了,順帶也了解了一些Unicode的細(xì)節(jié)。寫成一篇文章,送給有過類似疑問的朋友。本文在寫作時(shí)盡量做到通俗易懂,但要求讀者知道什么是字節(jié),什么是十六進(jìn)制。

          0、big?endian和little?endian

          big?endian 和little?endian是CPU處理多字節(jié)數(shù)的不同方式。例如“漢”字的Unicode編碼是6C49。那么寫到文件里時(shí),究竟是將6C寫在前面, 還是將49寫在前面?如果將6C寫在前面,就是big?endian。如果將49寫在前面,就是little?endian。

          “endian”這個(gè)詞出自《格列佛游記》。小人國的內(nèi)戰(zhàn)就源于吃雞蛋時(shí)是究竟從大頭(Big-Endian)敲開還是從小頭(Little-Endian)敲開,由此曾發(fā)生過六次叛亂,一個(gè)皇帝送了命,另一個(gè)丟了王位。

          我們一般將endian翻譯成“字節(jié)序”,將big?endian和little?endian稱作“大尾”和“小尾”。

          1、字符編碼、內(nèi)碼,順帶介紹漢字編碼

          字符必須編碼后才能被計(jì)算機(jī)處理。計(jì)算機(jī)使用的缺省編碼方式就是計(jì)算機(jī)的內(nèi)碼。早期的計(jì)算機(jī)使用7位的ASCII編碼,為了處理漢字,程序員設(shè)計(jì)了用于簡體中文的GB2312和用于繁體中文的big5。

          GB2312(1980年)一共收錄了7445個(gè)字符,包括6763個(gè)漢字和682個(gè)其它符號(hào)。漢字區(qū)的內(nèi)碼范圍高字節(jié)從B0-F7,低字節(jié)從A1-FE,占用的碼位是72*94=6768。其中有5個(gè)空位是D7FA-D7FE。

          GB2312支持的漢字太少。1995年的漢字?jǐn)U展規(guī)范GBK1.0收錄了21886個(gè)符號(hào),它分為漢字區(qū)和圖形符號(hào)區(qū)。漢字區(qū)包括21003個(gè)字符。

          從ASCII、 GB2312到GBK,這些編碼方法是向下兼容的,即同一個(gè)字符在這些方案中總是有相同的編碼,后面的標(biāo)準(zhǔn)支持更多的字符。在這些編碼中,英文和中文可以 統(tǒng)一地處理。區(qū)分中文編碼的方法是高字節(jié)的最高位不為0。按照程序員的稱呼,GB2312、GBK都屬于雙字節(jié)字符集?(DBCS)。

          2000 年的GB18030是取代GBK1.0的正式國家標(biāo)準(zhǔn)。該標(biāo)準(zhǔn)收錄了27484個(gè)漢字,同時(shí)還收錄了藏文、蒙文、維吾爾文等主要的少數(shù)民族文字。從漢字字 匯上說,GB18030在GB13000.1的20902個(gè)漢字的基礎(chǔ)上增加了CJK擴(kuò)展A的6582個(gè)漢字(Unicode碼0x3400- 0x4db5),一共收錄了27484個(gè)漢字。

          CJK就是中日韓的意思。Unicode為了節(jié)省碼位,將中日韓三國語言中的文字統(tǒng)一編碼。GB13000.1就是ISO/IEC?10646-1的中文版,相當(dāng)于Unicode?1.1。

          GB18030 的編碼采用單字節(jié)、雙字節(jié)和4字節(jié)方案。其中單字節(jié)、雙字節(jié)和GBK是完全兼容的。4字節(jié)編碼的碼位就是收錄了CJK擴(kuò)展A的6582個(gè)漢字。?例如: UCS的0x3400在GB18030中的編碼應(yīng)該是8139EF30,UCS的0x3401在GB18030中的編碼應(yīng)該是8139EF31。

          微軟提供了GB18030的升級(jí)包,但這個(gè)升級(jí)包只是提供了一套支持CJK擴(kuò)展A的6582個(gè)漢字的新字體:新宋體-18030,并不改變內(nèi)碼。Windows?的內(nèi)碼仍然是GBK。

          這里還有一些細(xì)節(jié):

          • GB2312的原文還是區(qū)位碼,從區(qū)位碼到內(nèi)碼,需要在高字節(jié)和低字節(jié)上分別加上A0。

          • 對(duì) 于任何字符編碼,編碼單元的順序是由編碼方案指定的,與endian無關(guān)。例如GBK的編碼單元是字節(jié),用兩個(gè)字節(jié)表示一個(gè)漢字。?這兩個(gè)字節(jié)的順序是固 定的,不受CPU字節(jié)序的影響。UTF-16的編碼單元是word(雙字節(jié)),word之間的順序是編碼方案指定的,word內(nèi)部的字節(jié)排列才會(huì)受到 endian的影響。后面還會(huì)介紹UTF-16。

          • GB2312的兩個(gè)字節(jié)的最高位都是1。但符合這個(gè)條件的碼位只有 128*128=16384個(gè)。所以GBK和GB18030的低字節(jié)最高位都可能不是1。不過這不影響DBCS字符流的解析:在讀取DBCS字符流時(shí),只 要遇到高位為1的字節(jié),就可以將下兩個(gè)字節(jié)作為一個(gè)雙字節(jié)編碼,而不用管低字節(jié)的高位是什么。

          2、Unicode、UCS和UTF

          前面提到從ASCII、GB2312、GBK到GB18030的編碼方法是向下兼容的。而Unicode只與ASCII兼容(更準(zhǔn)確地說,是與ISO-8859-1兼容),與GB碼不兼容。例如“漢”字的Unicode編碼是6C49,而GB碼是BABA。

          Unicode 也是一種字符編碼方法,不過它是由國際組織設(shè)計(jì),可以容納全世界所有語言文字的編碼方案。Unicode的學(xué)名是"Universal?Multiple -Octet?Coded?Character?Set",簡稱為UCS。UCS可以看作是"Unicode?Character?Set"的縮寫。

          根據(jù)維基百科全書(http://zh.wikipedia.org/wiki/)的記載:歷史上存在兩個(gè)試圖獨(dú)立設(shè)計(jì)Unicode的組織,即國際標(biāo)準(zhǔn)化組織(ISO)和一個(gè)軟件制造商的協(xié)會(huì)(unicode.org)。ISO開發(fā)了ISO?10646項(xiàng)目,Unicode協(xié)會(huì)開發(fā)了Unicode項(xiàng)目。

          在1991年前后,雙方都認(rèn)識(shí)到世界不需要兩個(gè)不兼容的字符集。于是它們開始合并雙方的工作成果,并為創(chuàng)立一個(gè)單一編碼表而協(xié)同工作。從Unicode2.0開始,Unicode項(xiàng)目采用了與ISO?10646-1相同的字庫和字碼。

          目前兩個(gè)項(xiàng)目仍都存在,并獨(dú)立地公布各自的標(biāo)準(zhǔn)。Unicode協(xié)會(huì)現(xiàn)在的最新版本是2005年的Unicode?4.1.0。ISO的最新標(biāo)準(zhǔn)是ISO?10646-3:2003。

          UCS 只是規(guī)定如何編碼,并沒有規(guī)定如何傳輸、保存這個(gè)編碼。例如“漢”字的UCS編碼是6C49,我可以用4個(gè)ascii數(shù)字來傳輸、保存這個(gè)編碼;也可以用 utf-8編碼:3個(gè)連續(xù)的字節(jié)E6?B1?89來表示它。關(guān)鍵在于通信雙方都要認(rèn)可。UTF-8、UTF-7、UTF-16都是被廣泛接受的方案。 UTF-8的一個(gè)特別的好處是它與ISO-8859-1完全兼容。UTF是“UCS?Transformation?Format”的縮寫。

          IETF 的RFC2781和RFC3629以RFC的一貫風(fēng)格,清晰、明快又不失嚴(yán)謹(jǐn)?shù)孛枋隽薝TF-16和UTF-8的編碼方法。我總是記不得IETF是 Internet?Engineering?Task?Force的縮寫。但I(xiàn)ETF負(fù)責(zé)維護(hù)的RFC是Internet上一切規(guī)范的基礎(chǔ)。

          2.1、內(nèi)碼和code?page

          目前Windows的內(nèi)核已經(jīng)支持Unicode字符集,這樣在內(nèi)核上可以支持全世界所有的語言文字。但是由于現(xiàn)有的大量程序和文檔都采用了某種特定語言的編碼,例如GBK,Windows不可能不支持現(xiàn)有的編碼,而全部改用Unicode。

          Windows使用代碼頁(code?page)來適應(yīng)各個(gè)國家和地區(qū)。code?page可以被理解為前面提到的內(nèi)碼。GBK對(duì)應(yīng)的code?page是CP936。

          微軟也為GB18030定義了code?page:CP54936。但是由于GB18030有一部分4字節(jié)編碼,而Windows的代碼頁只支持單字節(jié)和雙字節(jié)編碼,所以這個(gè)code?page是無法真正使用的。

          3、UCS-2、UCS-4、BMP

          UCS有兩種格式:UCS-2和UCS-4。顧名思義,UCS-2就是用兩個(gè)字節(jié)編碼,UCS-4就是用4個(gè)字節(jié)(實(shí)際上只用了31位,最高位必須為0)編碼。下面讓我們做一些簡單的數(shù)學(xué)游戲:

          UCS-2有2^16=65536個(gè)碼位,UCS-4有2^31=2147483648個(gè)碼位。

          UCS -4根據(jù)最高位為0的最高字節(jié)分成2^7=128個(gè)group。每個(gè)group再根據(jù)次高字節(jié)分為256個(gè)plane。每個(gè)plane根據(jù)第3個(gè)字節(jié)分為 256行?(rows),每行包含256個(gè)cells。當(dāng)然同一行的cells只是最后一個(gè)字節(jié)不同,其余都相同。

          group?0的plane?0被稱作Basic?Multilingual?Plane,?即BMP。或者說UCS-4中,高兩個(gè)字節(jié)為0的碼位被稱作BMP。

          將UCS-4的BMP去掉前面的兩個(gè)零字節(jié)就得到了UCS-2。在UCS-2的兩個(gè)字節(jié)前加上兩個(gè)零字節(jié),就得到了UCS-4的BMP。而目前的UCS-4規(guī)范中還沒有任何字符被分配在BMP之外。

          4、UTF編碼

          UTF-8就是以8位為單元對(duì)UCS進(jìn)行編碼。從UCS-2到UTF-8的編碼方式如下:

          UCS-2編碼(16進(jìn)制) UTF-8?字節(jié)流(二進(jìn)制)
          0000?-?007F 0xxxxxxx
          0080?-?07FF 110xxxxx?10xxxxxx
          0800?-?FFFF 1110xxxx?10xxxxxx?10xxxxxx

          例如“漢”字的Unicode編碼是6C49。6C49在0800-FFFF之間,所以肯定要用3字節(jié)模板了: 1110 xxxx? 10 xxxxxx? 10 xxxxxx。將6C49寫成二進(jìn)制是:0110?110001?001001,?用這個(gè)比特流依次代替模板中的x,得到: 1110 0110? 10 110001? 10 001001,即E6?B1?89。

          讀者可以用記事本測(cè)試一下我們的編碼是否正確。需要注意,UltraEdit在打開utf-8編碼的文本文件時(shí)會(huì)自動(dòng)轉(zhuǎn)換為UTF-16,可能產(chǎn)生混淆。你可以在設(shè)置中關(guān)掉這個(gè)選項(xiàng)。更好的工具是Hex?Workshop。

          UTF -16以16位為單元對(duì)UCS進(jìn)行編碼。對(duì)于小于0x10000的UCS碼,UTF-16編碼就等于UCS碼對(duì)應(yīng)的16位無符號(hào)整數(shù)。對(duì)于不小于 0x10000的UCS碼,定義了一個(gè)算法。不過由于實(shí)際使用的UCS2,或者UCS4的BMP必然小于0x10000,所以就目前而言,可以認(rèn)為UTF -16和UCS-2基本相同。但UCS-2只是一個(gè)編碼方案,UTF-16卻要用于實(shí)際的傳輸,所以就不得不考慮字節(jié)序的問題。

          5、UTF的字節(jié)序和BOM

          UTF -8以字節(jié)為編碼單元,沒有字節(jié)序的問題。UTF-16以兩個(gè)字節(jié)為編碼單元,在解釋一個(gè)UTF-16文本前,首先要弄清楚每個(gè)編碼單元的字節(jié)序。例如 “奎”的Unicode編碼是594E,“乙”的Unicode編碼是4E59。如果我們收到UTF-16字節(jié)流“594E”,那么這是“奎”還是 “乙”?

          Unicode規(guī)范中推薦的標(biāo)記字節(jié)順序的方法是BOM。BOM不是“Bill?Of?Material”的BOM表,而是Byte?Order?Mark。BOM是一個(gè)有點(diǎn)小聰明的想法:

          在UCS 編碼中有一個(gè)叫做"ZERO?WIDTH?NO-BREAK?SPACE"的字符,它的編碼是FEFF。而FFFE在UCS中是不存在的字符,所以不應(yīng)該 出現(xiàn)在實(shí)際傳輸中。UCS規(guī)范建議我們?cè)趥鬏斪止?jié)流前,先傳輸字符"ZERO?WIDTH?NO-BREAK?SPACE"。

          這樣如果接收者收到FEFF,就表明這個(gè)字節(jié)流是Big-Endian的;如果收到FFFE,就表明這個(gè)字節(jié)流是Little-Endian的。因此字符"ZERO?WIDTH?NO-BREAK?SPACE"又被稱作BOM。

          UTF -8不需要BOM來表明字節(jié)順序,但可以用BOM來表明編碼方式。字符"ZERO?WIDTH?NO-BREAK?SPACE"的UTF-8編碼是 EF?BB?BF(讀者可以用我們前面介紹的編碼方法驗(yàn)證一下)。所以如果接收者收到以EF?BB?BF開頭的字節(jié)流,就知道這是UTF-8編碼了。

          Windows就是使用BOM來標(biāo)記文本文件的編碼方式的。

          6、進(jìn)一步的參考資料

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

          我還找了兩篇看上去不錯(cuò)的資料,不過因?yàn)槲议_始的疑問都找到了答案,所以就沒有看:

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

          我寫過UTF-8、UCS-2、GBK相互轉(zhuǎn)換的軟件包,包括使用Windows?API和不使用Windows?API的版本。以后有時(shí)間的話,我會(huì)整理一下放到我的個(gè)人主頁上(http://fmddlmyy.home4u.china.com)

          我是想清楚所有問題后才開始寫這篇文章的,原以為一會(huì)兒就能寫好。沒想到考慮措辭和查證細(xì)節(jié)花費(fèi)了很長時(shí)間,竟然從下午1:30寫到9:00。希望有讀者能從中受益。

          附錄1?再說說區(qū)位碼、GB2312、內(nèi)碼和代碼頁

          有的朋友對(duì)文章中這句話還有疑問:
          “GB2312的原文還是區(qū)位碼,從區(qū)位碼到內(nèi)碼,需要在高字節(jié)和低字節(jié)上分別加上A0。”

          我再詳細(xì)解釋一下:

          “GB2312 的原文”是指國家1980年的一個(gè)標(biāo)準(zhǔn)《中華人民共和國國家標(biāo)準(zhǔn)?信息交換用漢字編碼字符集?基本集?GB?2312-80》。這個(gè)標(biāo)準(zhǔn)用兩個(gè)數(shù)來編碼漢 字和中文符號(hào)。第一個(gè)數(shù)稱為“區(qū)”,第二個(gè)數(shù)稱為“位”。所以也稱為區(qū)位碼。1-9區(qū)是中文符號(hào),16-55區(qū)是一級(jí)漢字,56-87區(qū)是二級(jí)漢字。現(xiàn)在 Windows也還有區(qū)位輸入法,例如輸入1601得到“啊”。(這個(gè)區(qū)位輸入法可以自動(dòng)識(shí)別16進(jìn)制的GB2312和10進(jìn)制的區(qū)位碼,也就是說輸入 B0A1同樣會(huì)得到“啊”。)

          內(nèi)碼是指操作系統(tǒng)內(nèi)部的字符編碼。早期操作系統(tǒng)的內(nèi)碼是與語言相關(guān)的。現(xiàn)在的Windows在系統(tǒng)內(nèi)部支持Unicode,然后用代碼頁適應(yīng)各種語言,“內(nèi)碼”的概念就比較模糊了。微軟一般將缺省代碼頁指定的編碼說成是內(nèi)碼。

          內(nèi)碼這個(gè)詞匯,并沒有什么官方的定義,代碼頁也只是微軟這個(gè)公司的叫法。作為程序員,我們只要知道它們是什么東西,沒有必要過多地考證這些名詞。

          所謂代碼頁(code?page)就是針對(duì)一種語言文字的字符編碼。例如GBK的code?page是CP936,BIG5的code?page是CP950,GB2312的code?page是CP20936。

          Windows中有缺省代碼頁的概念,即缺省用什么編碼來解釋字符。例如Windows的記事本打開了一個(gè)文本文件,里面的內(nèi)容是字節(jié)流:BA、BA、D7、D6。Windows應(yīng)該去怎么解釋它呢?

          是 按照Unicode編碼解釋、還是按照GBK解釋、還是按照BIG5解釋,還是按照ISO8859-1去解釋?如果按GBK去解釋,就會(huì)得到“漢字”兩個(gè) 字。按照其它編碼解釋,可能找不到對(duì)應(yīng)的字符,也可能找到錯(cuò)誤的字符。所謂“錯(cuò)誤”是指與文本作者的本意不符,這時(shí)就產(chǎn)生了亂碼。

          答案是Windows按照當(dāng)前的缺省代碼頁去解釋文本文件里的字節(jié)流。缺省代碼頁可以通過控制面板的區(qū)域選項(xiàng)設(shè)置。記事本的另存為中有一項(xiàng)ANSI,其實(shí)就是按照缺省代碼頁的編碼方法保存。

          Windows的內(nèi)碼是Unicode,它在技術(shù)上可以同時(shí)支持多個(gè)代碼頁。只要文件能說明自己使用什么編碼,用戶又安裝了對(duì)應(yīng)的代碼頁,Windows就能正確顯示,例如在HTML文件中就可以指定charset。

          有 的HTML文件作者,特別是英文作者,認(rèn)為世界上所有人都使用英文,在文件中不指定charset。如果他使用了0x80-0xff之間的字符,中文 Windows又按照缺省的GBK去解釋,就會(huì)出現(xiàn)亂碼。這時(shí)只要在這個(gè)html文件中加上指定charset的語句,例如:
          <meta?http-equiv="Content-Type"?content="text/html;?charset=ISO8859-1">
          如果原作者使用的代碼頁和ISO8859-1兼容,就不會(huì)出現(xiàn)亂碼了。

          再 說區(qū)位碼,啊的區(qū)位碼是1601,寫成16進(jìn)制是0x10,0x01。這和計(jì)算機(jī)廣泛使用的ASCII編碼沖突。為了兼容00-7f的ASCII編碼,我 們?cè)趨^(qū)位碼的高、低字節(jié)上分別加上A0。這樣“啊”的編碼就成為B0A1。我們將加過兩個(gè)A0的編碼也稱為GB2312編碼,雖然GB2312的原文根本 沒提到這一點(diǎn)。

          posted @ 2006-06-29 16:56 java執(zhí)著者 閱讀(1514) | 評(píng)論 (0)編輯 收藏

          UTF-16是Unicode的其中一個(gè)使用方式。 UTF是 Unicode Translation Format,即把Unicode轉(zhuǎn)做某種格式的意思。

          它定義于ISO/IEC 10646-1的附錄Q,而RFC2781也定義了相似的做法。

          在Unicode基本多文種平面定義的字符(無論是拉丁字母、漢字或其他文字或符號(hào)),一律使用2字節(jié)儲(chǔ)存。而在輔助平面定義的字符,會(huì)以代理對(duì)(surrogate pair)的形式,以兩個(gè)2字節(jié)的值來儲(chǔ)存。

          UTF-16比起UTF-8,好處在于大部分字符都以固定長度的字節(jié) (2字節(jié)) 儲(chǔ)存,但UTF-16卻無法兼容于ASCII編碼。

          UTF-16的編碼模式

          UTF-16的大尾序和小尾序儲(chǔ)存形式都在用。一般來說,以Macintosh制作或儲(chǔ)存的文字使用大尾序格式,以Microsoft或Linux制作或儲(chǔ)存的文字使用小尾序格式。

          為了弄清楚UTF-16文件的大小尾序,在UTF-16文件的開首,都會(huì)放置一個(gè)U+FEFF字符作為Byte Order Mark (UTF-16LE 以 FF FE 代表,UTF-16BE 以 FE FF 代表),以顯示這個(gè)文字檔案是以UTF-16編碼。

          以下的例子有四個(gè)字符:“朱”、半角逗號(hào)、“聿”、“??”。

          使用 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 的關(guān)系

          UTF-16可看成是UCS-2的父集。在沒有輔助平面字符前,UTF-16與UCS-2所指的是同一的意思。但當(dāng)引入輔助平面字符后,就只稱為UTF-16了。現(xiàn)在若有軟件聲稱自己支援UCS-2編碼,那其實(shí)是暗指它不能支援輔助平面字符的委婉語。

          posted @ 2006-06-29 16:51 java執(zhí)著者 閱讀(2019) | 評(píng)論 (0)編輯 收藏

          字符集簡史

          在所有字符集中,最知名可能 要數(shù)被稱為ASCII的7位字符集了。它是美國信息交換標(biāo)準(zhǔn)委員會(huì) (American?Standards?Committee?for?Information?Interchange)的縮寫,?為美國英語通信所設(shè) 計(jì)。它由128個(gè)字符組成,包括大小寫字母、數(shù)字0-9、標(biāo)點(diǎn)符號(hào)、非打印字符(換行符、制表符等4個(gè))以及控制字符(退格、響鈴等)組成。

          但 是,由于他是針對(duì)英語設(shè)計(jì)的,當(dāng)處理帶有音調(diào)標(biāo)號(hào)(形如漢語的拼音)的歐洲文字時(shí)就會(huì)出現(xiàn)問題。因此,創(chuàng)建出了一些包括255個(gè)字符的由ASCII擴(kuò)展的 字符集。其中有一種通常被成為IBM字符集,它把值為128-255之間的字符用于畫圖和畫線,以及一些特殊的歐洲字符。另一種8位字符集是 ISO?8859-1?Latin?1,也簡稱為ISO?Latin-1。它把位于128-255之間的字符用于拉丁字母表中特殊語言字符的編碼,也因此 而得名。

          歐洲語言不是地球上的唯一語言,因此亞洲和非洲語言并不能被8位字符 集所支持。僅漢語(或pictograms)字母表就有80000以上個(gè)字符。但是把漢語、日語和越南語的一些相似的字符結(jié)合起來,在不同的語言里,使不 同的字符代表不同的字,這樣只用2個(gè)字節(jié)就可以編碼地球上幾乎所有地區(qū)的文字。因此,創(chuàng)建了UNICODE編碼。它通過增加一個(gè)高字節(jié)對(duì) ISO?Latin-1字符集進(jìn)行擴(kuò)展,當(dāng)這些高字節(jié)位為0時(shí),低字節(jié)就是ISO?Latin-1字符。UNICODE支持歐洲、非洲、中東、亞洲(包括 統(tǒng)一標(biāo)準(zhǔn)的東亞像形漢字和韓國像形文字)。但是,UNICODE并沒有提供對(duì)諸如Braille,?Cherokee,?Ethiopic, ?Khmer,?Mongolian,?Hmong,?Tai?Lu,?Tai?Mau文字的支持。同時(shí)它也不支持如Ahom,?Akkadian, ?Aramaic,?Babylonian?Cuneiform,?Balti,?Brahmi,?Etruscan,?Hittite,?Javanese, ?Numidian,?Old?Persian?Cuneiform,?Syrian之類的古老的文字。

          事 實(shí)證明,對(duì)可以用ASCII表示的字符使用UNICODE并不高效,因?yàn)閁NICODE比ASCII占用大一倍的空間,而對(duì)ASCII來說高字節(jié)的0對(duì)他 毫無用處。為了解決這個(gè)問題,就出現(xiàn)了一些中間格式的字符集,他們被稱為通用轉(zhuǎn)換格式,既UTF (Universal?Transformation?Format)。目前存在的UTF格式有:UTF-7,?UTF-7.5,?UTF-8,?UTF -16,?以及?UTF-32。本文討論UTF-8字符集的基礎(chǔ)。

          UTF_8字符集

          UTF -8是UNICODE的一種變長字符編碼,由Ken?Thompson于1992年創(chuàng)建。現(xiàn)在已經(jīng)標(biāo)準(zhǔn)化為RFC?3629。UTF-8用1到6個(gè)字節(jié)編 碼UNICODE字符。如果UNICODE字符由2個(gè)字節(jié)表示,則編碼成UTF-8很可能需要3個(gè)字節(jié),而如果UNICODE字符由4個(gè)字節(jié)表示,則編碼 成UTF-8可能需要6個(gè)字節(jié)。用4個(gè)或6個(gè)字節(jié)去編碼一個(gè)UNICODE字符可能太多了,但很少會(huì)遇到那樣的UNICODE字符。

          UFT-8轉(zhuǎn)換表表示如下:

          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?

          實(shí) 際表示ASCII字符的UNICODE字符,將會(huì)編碼成1個(gè)字節(jié),并且UTF-8表示與ASCII字符表示是一樣的。所有其他的UNCODE字符轉(zhuǎn)化成 UTF-8將需要至少2個(gè)字節(jié)。每個(gè)字節(jié)由一個(gè)換碼序列開始。第一個(gè)字節(jié)由唯一的換碼序列,由n位1加一位0組成。n位1表示字符編碼所需的字節(jié)數(shù)。

          示例

          UNICODE?uCA(11001010)?編碼成UTF-8將需要2個(gè)字節(jié):

          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個(gè)字節(jié):

          u?F03F?->?EF?80?BF

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

          譯者注:由上分析可以看到,UNCODE到UTF-8的轉(zhuǎn)換就是先確定編碼所需要的字節(jié)數(shù),然后用UNICODE編碼位從低位到高位依次填入上面表示為x的位上,不足的高位以0補(bǔ)充。以上是個(gè)人經(jīng)驗(yàn),如有錯(cuò)誤,請(qǐng)不惜指教,謝過先:)

          UTF-8編碼的優(yōu)點(diǎn):

          UTF-8編碼可以通過屏蔽位和移位操作快速讀寫。
          字符串比較時(shí)strcmp()和wcscmp()的返回結(jié)果相同,因此使排序變得更加容易。
          字節(jié)FF和FE在UTF-8編碼中永遠(yuǎn)不會(huì)出現(xiàn),因此他們可以用來表明UTF-16或UTF-32文本(見BOM)
          UTF-8?是字節(jié)順序無關(guān)的。它的字節(jié)順序在所有系統(tǒng)中都是一樣的,因此它實(shí)際上并不需要BOM。

          UTF-8編碼的缺點(diǎn):

          你無法從UNICODE字符數(shù)判斷出UTF-8文本的字節(jié)數(shù),因?yàn)閁TF-8是一種變長編碼
          它需要用2個(gè)字節(jié)編碼那些用擴(kuò)展ASCII字符集只需1個(gè)字節(jié)的字符
          ISO?Latin-1?是UNICODE的子集,但不是UTF-8的子集
          8位字符的UTF-8編碼會(huì)被email網(wǎng)關(guān)過濾,因?yàn)閕nternet信息最初設(shè)計(jì)為7為ASCII碼。因此產(chǎn)生了UTF-7編碼。
          UTF-8?在它的表示中使用值100xxxxx的幾率超過50%,?而現(xiàn)存的實(shí)現(xiàn)如ISO?2022,?4873,?6429,?和8859系統(tǒng),會(huì)把它錯(cuò)認(rèn)為是C1?控制碼。因此產(chǎn)生了UTF-7.5編碼。

          修正的UTF-8:


          java使用UTF-16表示內(nèi)部文本,并支持用于字符串串行化的非標(biāo)準(zhǔn)的修正UTF-8編碼。標(biāo)準(zhǔn)UTF-8和修正的UTF-8有兩點(diǎn)不同:
          修 正的UTF-8中,null字符編碼成2個(gè)字節(jié)(11000000?00000000)?而不是標(biāo)準(zhǔn)的1個(gè)字節(jié)(00000000),這樣作可以保證編碼 后的字符串中不會(huì)嵌入null字符。因此如果在類C語言中處理字符串,文本不會(huì)在第一個(gè)null字符時(shí)截?cái)啵–字符串以null結(jié)尾)。
          在標(biāo)準(zhǔn) UTF-8編碼中,超出基本多語言范圍(BMP?-?Basic?Multilingual?Plain)的字符被編碼為4字節(jié)格式,但是在修正的UTF -8編碼中,他們由代理編碼對(duì)(surrogate?pairs)表示,然后這些代理編碼對(duì)在序列中分別重新編碼。結(jié)果標(biāo)準(zhǔn)UTF-8編碼中需要4個(gè)字節(jié) 的字符,在修正后的UTF-8編碼中將需要6個(gè)字節(jié)。

          位序標(biāo)志BOM


          BOM(Byte?Order?Mark)是一個(gè)字符,它表明UNICODE文本的UTF-16,UTF-32的編碼字節(jié)順序(高字節(jié)低字節(jié)順序)和編碼方式(UTF-8,UTF-16,UTF-32,?其中UTF-8編碼是字節(jié)順序無關(guān)的)。

          如下所示:

          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++?程序編碼示例:

          下面是四個(gè)C++函數(shù),他們分別實(shí)現(xiàn)2字節(jié)和4字節(jié)UNICODE和UTF-8之間的轉(zhuǎn)換。

          #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);
          }
          }


          限譯者水平有限,有不解之處請(qǐng)參考原文。版權(quán)屬原文作者所有,轉(zhuǎn)載請(qǐng)注明出處及作者。

          原文參見:http://www.codeguru.com/Cpp/misc ... article.php/c10451/

          posted @ 2006-06-29 16:00 java執(zhí)著者 閱讀(2240) | 評(píng)論 (0)編輯 收藏

          主站蜘蛛池模板: 玛曲县| 三江| 虞城县| 盈江县| 凯里市| 南城县| 邳州市| 西平县| 津南区| 沅江市| 嵩明县| 策勒县| 竹北市| 通榆县| 胶州市| 峨眉山市| 台南市| 榆中县| 奉节县| 中方县| 东平县| 五大连池市| 南安市| 依安县| 中卫市| 夏邑县| 阿克陶县| 青神县| 钟祥市| 阜城县| 西充县| 邵武市| 镇康县| 嵊泗县| 遂宁市| 工布江达县| 通江县| 奉节县| 子长县| 蒙自县| 沙雅县|