GB2312/GBK 本質解析與中文網頁編碼常見誤區
GB2312 與 GBK 既是字元集也是編碼方案,中文 Windows 系統預設編碼為 GBK。本文揭示網頁 charset=GB2312 實際行為、瀏覽器 GBK 相容機制、程式化抓取的編碼判斷難題。
GB2312 與 GBK 本質釐清
| 標準 | 字元集內容 | 編碼方案 | 備註 |
| GB2312 | ASCII + 6,763 簡體漢字 + 符號 | 直接使用字元集序號作儲存值 (類 UTF-32) | 編碼方案無正式名稱 |
| GBK | GB2312 超集,擴充更多漢字/符號 | 雙位元組編碼,相容 GB2312 | 中文 Windows 系統預設編碼 |
驗證系統預設編碼
String encoding = System.getProperty("file.encoding");
System.out.println(encoding); // 輸出: GBK (中文 Windows)
中文網頁兩大關鍵誤區
誤區一:charset 指定的是字元集而非編碼
<meta charset="GB2312"> // 錯誤認知:以為指定字元集
<meta charset="UTF-8"> // 實際上 charset 屬性指定「字元集編碼」
<meta charset="ISO-8859-1">
// 從未見過 charset="Unicode",因 Unicode 是字元集非編碼
XML 已修正為 encoding 屬性,避免術語混淆。
誤區二:網頁宣稱 GB2312 實際使用 GBK
實驗驗證:
- 找一個 GB2312 無收字:「亸」 (U+4EA8,GBK 有收)
- 放入 HTML 頁面,宣告
charset=GB2312
- 瀏覽器選擇「GB2312」編碼 → 完全正常顯示
結論:瀏覽器「GB2312」選項實際使用 GBK 解碼器。
新浪等大型網站實況
- 頁面到處宣稱
charset=GB2312
- 實際大量使用 GB2312 無收字字元
- 瀏覽器顯示無礙,但**程式化抓取/儲存時無法依賴宣告編碼**
對開發者的影響
| 場景 | 問題 | 對策 |
| 網頁爬蟲抓取 | 無法依賴 charset 宣告 | 實作編碼偵測演算法 (如 Mozilla Universal Charset Detector) |
| 表單提交 | 瀏覽器以頁面編碼送出資料 | 伺服端統一以 UTF-8 接收,必要時轉碼 |
| 資料庫儲存 | GBK 無法儲存繁體/罕見字 | 資料庫欄位使用 UTF-8/utf8mb4 |
結語
理解「charset 實為編碼」、「GB2312 實為 GBK」雙重真相,建立編碼偵測與統一 UTF-8 處理機制,是中文環境開發者必修課。
- 上一篇文章: Java 字元編碼入門(四):網頁檔案編碼與瀏覽器顯示機制
- 下一篇文章: Java 字元編碼入門(二):編碼字元集與字元集編碼的本質區別
Copyright ©
程式碼之家 All Rights Reserved