看到很多文章在問(wèn)和答關(guān)于java網(wǎng)頁(yè)漢字亂碼的情況，有些甚至認(rèn)為這是servlet包容器實(shí)現(xiàn)上的錯(cuò)誤。
可是如果讀過(guò)servlet規(guī)格說(shuō)明書(shū)，關(guān)于java網(wǎng)頁(yè)編碼的問(wèn)題就應(yīng)該迎刃而解了。
編寫(xiě)java網(wǎng)頁(yè)（servlet\jsp），需要關(guān)心response(反饋給客戶(hù)端的頁(yè)面)和request（來(lái)自客戶(hù)端的數(shù)據(jù)）的編碼問(wèn)題。
response的編碼可以直接用代碼實(shí)現(xiàn)。而request的編碼怎么辦呢？
以下是servlet規(guī)范書(shū)上的文字（我粗略翻譯一下吧，不怕見(jiàn)笑）：
-- 整理自 SRV.4.9 --
當(dāng)前,很多瀏覽器并不發(fā)送帶有“Content-Type”頭信息的字符編碼限定符，
而由讀取HTTP請(qǐng)求的代碼來(lái)決定字符的編碼方式。如果客戶(hù)端請(qǐng)求未定義編碼限定符，
則包容器（如tomcat）用于創(chuàng)建request reader和分析POST數(shù)據(jù)的request的缺省編碼
方式必須是“ISO-8859-1”。然而，為了向開(kāi)發(fā)者指明客戶(hù)端沒(méi)有發(fā)送字符編碼信息的
情況，包容器對(duì)getCharacterEncoding方法返回null。
如果客戶(hù)端不設(shè)置字符編碼方式，并且request不是按照以上缺省編碼方式
（iso-8859-1）來(lái)編碼，則會(huì)發(fā)生問(wèn)題。為了解決這個(gè)問(wèn)題，在接口
ServletRequest中加入了一個(gè)新的方法setCharacterEncoding(String enc)。
開(kāi)發(fā)者可以調(diào)用這個(gè)方法來(lái)替換包容器提供的缺省字符編碼方式。但是，
必須在從request中分析任何POST數(shù)據(jù)或者讀取任何輸入之前，調(diào)用這個(gè)方法。
一旦數(shù)據(jù)已被讀取，則調(diào)用這個(gè)方法將不會(huì)影響編碼方式。 

通用字符集ISO/IEC-1062.，也即統(tǒng)一字符編碼標(biāo)準(zhǔn)Unicode 2.0。
其他系列的字符集子集，例如UTF-8、ISO-8859-1或UCS-2等。其中：
UTF-8是指通用字符集UCS(Universal Character Set)的轉(zhuǎn)換格式8(Transformation Format 8)，主要傳輸國(guó)際字符集的轉(zhuǎn)換編碼。UTF-8采用了UCS字符的8位編碼，提供了十分安全的編碼格式，可以有效避免數(shù)據(jù)傳輸過(guò)程中的竊聽(tīng)、截取及非法解密。同時(shí)，UTF-8與7位ACSII碼完全兼容，不會(huì)影響此類(lèi)編碼實(shí)現(xiàn)的程序；它的編碼規(guī)則十分嚴(yán)格，能夠有效避免同步傳輸錯(cuò)誤，而且還會(huì)支持其它字符集提供了足夠的空間。

ISO-8859-1字符集是國(guó)際標(biāo)準(zhǔn)化組織ISO(International Standardization Organization)制定的ACSII字符集的擴(kuò)展集，能夠表示所有西歐語(yǔ)言的字符。與ISO Latin-1一樣，ISO-8859-1與Windows環(huán)境中普遍使用的美國(guó)國(guó)家標(biāo)準(zhǔn)協(xié)會(huì)ANSI(American National Standards Institute)的字符集極為類(lèi)似，絕大多數(shù)情況下無(wú)需區(qū)分。在不特別指明的情況下，HTTP協(xié)議均使用ISOLatin-1字符集。因此，為了WML頁(yè)面中表示非ACSII（non-ACSII）字符，開(kāi)發(fā)人員需要使用相應(yīng)的ISO Latin-1編碼的字符。

UCS-2是ISO 1062.標(biāo)準(zhǔn)中自定義的通用多8位編碼字符集(Universal Multiple-Octer Coded Character Set)的2字節(jié)（即16位）編碼標(biāo)準(zhǔn)，其字符編碼值與Unicode字符的標(biāo)準(zhǔn)編碼值相等。