Java

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

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

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

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

UTF-16的編碼模式

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

為了弄清楚UTF-16文件的大小尾序，在UTF-16文件的開(kāi)首，都會(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的父集。在沒(méi)有輔助平面字符前，UTF-16與UCS-2所指的是同一的意思。但當(dāng)引入輔助平面字符后，就只稱為UTF-16了?，F(xiàn)在若有軟件聲稱自己支援UCS-2編碼，那其實(shí)是暗指它不能支援輔助平面字符的委婉語(yǔ)。

字符集簡(jiǎn)史

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

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

歐洲語(yǔ)言不是地球上的唯一語(yǔ)言，因此亞洲和非洲語(yǔ)言并不能被8位字符 集所支持。僅漢語(yǔ)（或pictograms）字母表就有80000以上個(gè)字符。但是把漢語(yǔ)、日語(yǔ)和越南語(yǔ)的一些相似的字符結(jié)合起來(lái)，在不同的語(yǔ)言里，使不 同的字符代表不同的字，這樣只用2個(gè)字節(jié)就可以編碼地球上幾乎所有地區(qū)的文字。因此，創(chuàng)建了UNICODE編碼。它通過(guò)增加一個(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)的東亞像形漢字和韓國(guó)像形文字）。但是，UNICODE并沒(méi)有提供對(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來(lái)說(shuō)高字節(jié)的0對(duì)他 毫無(wú)用處。為了解決這個(gè)問(wèn)題，就出現(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的一種變長(zhǎng)字符編碼，由Ken?Thompson于1992年創(chuàng)建?，F(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è)換碼序列開(kāi)始。第一個(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)不惜指教，謝過(guò)先:)

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

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

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

你無(wú)法從UNICODE字符數(shù)判斷出UTF-8文本的字節(jié)數(shù)，因?yàn)閁TF-8是一種變長(zhǎng)編碼
它需要用2個(gè)字節(jié)編碼那些用擴(kuò)展ASCII字符集只需1個(gè)字節(jié)的字符
ISO?Latin-1?是UNICODE的子集，但不是UTF-8的子集
8位字符的UTF-8編碼會(huì)被email網(wǎng)關(guān)過(guò)濾，因?yàn)閕nternet信息最初設(shè)計(jì)為7為ASCII碼。因此產(chǎn)生了UTF-7編碼。
UTF-8?在它的表示中使用值100xxxxx的幾率超過(guò)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語(yǔ)言中處理字符串，文本不會(huì)在第一個(gè)null字符時(shí)截?cái)啵–字符串以null結(jié)尾）。
在標(biāo)準(zhǔn) UTF-8編碼中，超出基本多語(yǔ)言范圍（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é)順序無(wú)關(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)注明出處及作者。

原文參見(jiàn)：http://www.codeguru.com/Cpp/misc ... article.php/c10451/

現(xiàn)在的開(kāi)發(fā)技術(shù)的發(fā)展的速度比起開(kāi)發(fā)者的學(xué)習(xí)速度不知道要快多少，每隔一兩天就會(huì)有一個(gè)開(kāi)源的工程誕生，學(xué)習(xí)如何去使用這些開(kāi)源的工程不如學(xué)習(xí)一下其中的思想。比如Hibernate，ibatis等ORM等f(wàn)ramework它只不過(guò)是幫你擺脫那些DAO模式為每個(gè)數(shù)據(jù)對(duì)象作一個(gè)DAO對(duì)象專門來(lái)負(fù)責(zé)數(shù)據(jù)庫(kù)操作，你可以用一個(gè)統(tǒng)一的接口來(lái)進(jìn)行數(shù)據(jù)庫(kù)的操作。與其去專研如何去配置，如何去使用還不如去好好的研究一些他所體現(xiàn)的一些思想，比如數(shù)據(jù)庫(kù)查詢的優(yōu)化，利用緩存機(jī)制，數(shù)據(jù)庫(kù)連接池等等。
還有就是spring，它到底體現(xiàn)了什么是用來(lái)替換現(xiàn)在的J2EE的技術(shù)，不，就連spring的作者都說(shuō)是在合時(shí)的情況下使用合適的技術(shù)，一句看似空洞的話卻包含了深意。spring的核心思想在我看來(lái)就是DI，他在其他的open source的項(xiàng)目的基礎(chǔ)上加以抽象，比如他提供了spring mvc--可以去使用底層的web mvc可以有很多，但是現(xiàn)在可以用一個(gè)統(tǒng)一的接口來(lái)調(diào)用，底層的實(shí)現(xiàn)機(jī)制與上層無(wú)關(guān)，這不證實(shí)了分層開(kāi)發(fā)的思想嗎，DI的思想正是用接口編程。
技術(shù)的快速的發(fā)展，給開(kāi)發(fā)者帶了很多的學(xué)習(xí)的難度，但是開(kāi)發(fā)者如何來(lái)面對(duì)這種挑戰(zhàn)，與其掌握如何去使用還不如去掌握它的思想。只有掌握了思想是用時(shí)才會(huì)有更深的理解。

今天來(lái)了BlogJava開(kāi)了自己的Bolg，工作了一年，在公司中用java的機(jī)會(huì)并不是很多，但是在有限的幾個(gè)項(xiàng)目中我都選擇了java作為我的開(kāi)發(fā)語(yǔ)言，并且用了許多開(kāi)源的java的工具，Hibernate，Ant，Log4J，Dom4j等等，我是一個(gè)追求新事物的人，對(duì)于眼前那許許多多的java的開(kāi)源的項(xiàng)目，我也有些茫然。然而上個(gè)禮拜去Sybase公司面試的經(jīng)歷，卻讓我重新認(rèn)識(shí)了原來(lái)我懂得盡然是那么少。Java的本質(zhì)是什么，JVM是怎么工作的，gc是怎么工作的，ClassLoad是什么樣的，現(xiàn)在的程序員有幾個(gè)人能真正回答的完整的，也許很少?？粗切┨咸喜唤^說(shuō)出現(xiàn)了什么新技術(shù)的人，我只有暗地里感到，我真的想奉勸那些朋友有空好好去看看JVM的書，不要滿口說(shuō)什么新的技術(shù)。