??? 今天看了子華的博客中關于昨晚我們討論編碼方面的問題，發現其中有一個關鍵點沒有談到。
??? 情況是這樣的：我們現在使用的一個名為Notepad++的編輯器，它大體上和UltraEdit類似，是我從sourceforge上下載下載使用的。它有個格式的功能，簡單而言就是設置使用ascii編碼編輯文檔還是使用utf-8編碼，其實這里主要是對應非英文方面的字符才發生差異。
??? 如前那篇隨筆所述utf-8只是用于在數據傳輸時將字符串分割成字節傳輸出去，它對于unicode編碼有著嚴格的一一對應關系，而對于gb2312、gbk、gb18030之類的中文編碼是沒有對應關系的。gb2312、gbk、gb18030是在ascii編碼之上進行的中文編碼開發，所以它們是與ascii相兼容的，可以這么理解在我們的文本編輯器中ascii方式編輯的文本是以ascii碼保存，而以utf-8方式編輯的文本是以unicode編碼保存。
??? 現在，編碼的差異就在這里發生了，unicode中的英文部分編碼是與ascii相兼容的，具體而言是iso8859-1兼容，所以我們無論用什么編碼保存方式保存jsp文件，在網頁上顯示的都是正確的英文字符。但是對于中文這個保存的格式卻非常重要。在了解了jsp頁面的顯示過程我們就會明白其中的原因。
??? 現在回頭來看看jsp文件是經過了哪些步驟才在網頁上顯示出來的。
??? 1、首先我們用編輯器編輯jsp頁面代碼保存；
??? 2、web服務器對其進行編譯，將jsp頁面編譯成為一個java的class文件；
??? 3、web服務器將其class文件用傳輸格式在網絡上傳輸；
??? 4、客戶端瀏覽器解析代碼生成頁面。
??? 過程大致如上，能夠影響編碼方面的基本上在1、2、4方面，所以對其進行詳細講解。
??? 我們的編輯器是有一種默認的編碼保存方式的。這會到后面java編譯器是否將其中的中文進行轉換的問題。大家都知道java是以十六位的unicode編碼編譯、存儲java文件的。因為同一個漢字在unicode編碼和gb2312編碼中的位置是不一樣的，（具體而言就是這兩種編碼沒有兼容性，也不能通過公式換算出來，只能通過字符對應表進行轉換）
??? 上面指出的保存格式的重要性就在這里體現出來了，這也是很多人容易遺漏之處，當我們用默認格式位gbk的編輯器編輯jsp頁面，而在其頭部聲明charset＝utf－8，那么返回的頁面會出現亂碼，而charset＝gb2312則正常顯示。本人分析原因在于，在charset＝utf－8的聲明有誤時，java編譯器會錯誤的認為現在保存的文件就是以unicode編碼格式保存的文件，所以在編譯中就不對其中的中文字符進行gb2312－－unicode的轉化，而直接將其gb2312指向的編碼地址保存為unicode的編碼地址。反之，當編輯器的默認編輯保存格式為utf－8時，在jsp中聲明為gb2312，就會讓編譯器畫蛇添足的多進行一次中文編碼轉換，從而亂碼出現。
??? 綜上所述，編輯器的默認編碼方式是在解決中文亂碼方面是很重要的一個因素，當然我們可以用pageEncoding參數來說明文本編碼形式。弄清中文顯示后面的具體調用過程是徹底解決該類問題的終極之道！
本文依據《創作共用約定》之“署名-禁止派生-非商業用途”方式發布，即你可以免費拷貝、分發、呈現和表演當前作品，但是必須基于以下條款：
對于任何二次使用或分發，你必須讓其他人明確當前作品的授權條款。
在得到作者的明確允許下，這里的某些條款可以放棄。