JSP 中 pageEncoding 與 contentType charset 差異詳解

核心定義

三階段編碼流程

1. 翻譯階段：容器以 pageEncoding 讀取 JSP，產生 UTF-8 編碼的 .java。若設定錯誤，中文會變亂碼並永久寫入 Servlet 原始碼。
2. 編譯階段：javac 以 UTF-8 讀取 .java，產生 UTF-8 位元碼 .class。此階段不受 JSP 編碼影響。
3. 執行階段：Tomcat 載入 .class 執行，將字串以 contentType 指定的 charset 輸出。此時 pageEncoding 已無作用。

預設值與相依關係

• 兩者預設皆為 ISO-8859-1。
• Tomcat 4.1.x 行為：若只設定其中一個，另一個會自動跟隨相同值；但此非規格強制，各容器實作可能不同。
• 最佳實務：明確同時設定兩者，且可不同值 (如 pageEncoding="GBK"、contentType="UTF-8") 以支援中文開發與現代瀏覽器相容。

實務範例

<%@ page contentType="text/html;charset=utf-8" pageEncoding="GBK" %>

上例：JSP 檔以 GBK 儲存 (pageEncoding)，輸出網頁採 UTF-8 (contentType)。若省略 pageEncoding，容器會以 ISO-8859-1 讀取 GBK 檔案，導致中文亂碼。

常見誤區

• 誤以為 contentType 能修正 JSP 檔案讀取編碼 —— 只能靠 pageEncoding。
• 誤以為 <meta charset="..."> 可替代 contentType —— HTTP 標頭優先級高於 HTML meta 標籤。
• Java 原始碼 (.java) 編譯時預編碼為作業系統 locale (中文 Windows 為 GBK)，但 JSP 無此機制，必須靠 pageEncoding 明確指定。