English
This page is available in English
The whole page — instructions, buttons and results.
Switch to English免費漢字編碼查詢工具。輸入任意字元,逐字顯示 Unicode 碼位、UTF-8、UTF-16、Big5、GBK/GB2312、GB18030 十六進位,以及 HTML 實體與十進位碼位。瀏覽器本地計算,不上傳資料。
漢字編碼查詢(Big5/GB/Unicode)
使用方法
貼上或輸入字元
在輸入框中貼上或鍵入一個或多個字元——漢字、標點、ASCII、表情符號、擴展區罕用字皆可。工具按 Unicode 碼位逐字拆分,代理對(如擴展 B 區罕字)會被完整保留為單個字元。
查看每字的編碼
每個字元顯示為一張卡片:Unicode 碼位(U+)、UTF-8 位元組、UTF-16 (BE) 碼元、Big5、GBK/GB2312、GB18030,以及 HTML 實體(…;)與十進位碼位。
理解 Big5 與 GB 欄
Big5 以繁體字為主,大多數簡體專用字會顯示「不在 Big5」——但並非全部:万、与、厂、气 都有 Big5 碼位,本表可查。GBK/GB2312 涵蓋簡體與大量繁體。GB18030 涵蓋整個 Unicode,因此永遠有值:ASCII 為 1 位元組,GBK 收錄的字與 GBK 完全相同(2 位元組),GBK 之外的字則為 4 位元組——每個值旁都標註了它屬於哪一種。
一鍵複製
每個數值旁的「複製」按鈕可將該十六進位 / 碼位複製到剪貼簿,方便直接貼進程式碼、資料庫或終端機。全部計算在瀏覽器本地完成。
漢字編碼:從 Big5、GB 到 Unicode 的來龍去脈
對處理中文的開發者而言,「同一個字,在不同編碼裡是不同的位元組」是最容易踩坑的地方。一個漢字在 UTF-8 裡通常佔 3 個位元組,在 Big5 或 GBK 裡佔 2 個位元組,而它的 Unicode 碼位又是另一套數字。本工具把任意字元在這些主流編碼下的十六進位表示一次性列出,方便你在資料遷移、亂碼排查、協定對接時快速核對。所有換算都在瀏覽器本地完成,不會把你的文字上傳到任何伺服器。
Big5 與 GB 系列:兩套並行的本地編碼
Big5 是台灣、香港地區繁體中文的傳統編碼,以繁體字與符號為主,大多數簡體專用字並未收錄,本工具會標註「不在 Big5」——但「簡體字在 Big5 中不存在」的說法過頭了,本表就是反證:万(C945)、与(C94F)、厂(C944)、气(C961)都有 Big5 碼位;几、儿 則是 Big5 本就收錄的繁體字,只是恰好與簡體同形。大陸一側則是 GB 系列:最早的 GB2312 只含約 6,763 個常用簡體字;GBK 向後相容 GB2312 並擴充到約兩萬字,同時收錄大量繁體字;GB18030 則是國家強制標準,用 1、2、4 位元組變長方案涵蓋整個 Unicode——當一個字已在 GBK 中(2 位元組)時,它的 GB18030 編碼與 GBK 完全相同,只有 GBK 之外的字元才會用到 4 位元組形式。理解這層相容關係,能解釋為什麼很多「GBK 檔案」其實可以安全地當作 GB18030 讀取。
Unicode、UTF-8 與 UTF-16:碼位與位元組的區別
初學者常把「Unicode 碼位」和「UTF-8 位元組」混為一談,其實它們是兩個層次:碼位(code point)是字元在 Unicode 字元集中的抽象編號(如「中」是 U+4E2D),而 UTF-8 / UTF-16 是把這個碼位序列化成位元組的具體方案。UTF-8 對 ASCII 用 1 位元組、對常見漢字用 3 位元組;UTF-16 對基本平面字元用 1 個 16 位元碼元,對補充平面(如擴展 B 區的罕用字)用一對「代理對」碼元。本工具按 Array.from 的碼位粒度拆分,因此即使是需要代理對的四位元組字元,也會被當作單個字元正確顯示,不會被截成兩半。
「亂碼不是字元壞了,而是用錯了解碼器。」——每個處理多編碼的開發者遲早會懂的道理。
什麼時候你會用到這個工具
典型場景包括:把舊的 Big5 / GBK 資料庫遷移到 UTF-8 時核對位元組;偵錯 URL 編碼、HTTP 標頭或檔名亂碼;為前端手寫 HTML 數字實體(中);確認某個生僻字是否落在 GBK 收錄範圍內,從而決定是否需要 GB18030 或直接走 Unicode。本工具是一個純前端的開發輔助:不呼叫任何模型、不發起除編碼詞表以外的網路請求、不含隨機性,相同輸入永遠得到相同結果——這正是一個可靠的編碼參考所應有的確定性。
關於漢字編碼的 10 個事實
一個常見漢字在 UTF-8 中佔 3 個位元組,在 Big5 / GBK 中佔 2 個位元組。這就是為什麼同一段中文文字在不同編碼下檔案大小不一樣。
「Unicode 碼位」是字元的抽象編號,「UTF-8」是把碼位變成位元組的方案。U+4E2D 是「中」的碼位,E4 B8 AD 才是它的 UTF-8 位元組。
Big5 以繁體字為主,大多數簡體專用字並未收錄,把簡體文字儲存為 Big5 會丟字或產生亂碼。但「簡體字在 Big5 中根本不存在」的說法過頭了:万、与、厂、气 都有 Big5 碼位,而 几、儿 本身就是 Big5 收錄的繁體字,只是恰好與簡體同形。
GB2312(1980)只含約 6,763 個簡體常用字;GBK 擴充到約兩萬字並向後相容 GB2312;GB18030 則涵蓋整個 Unicode。三者是逐層包含的關係。
GB18030 是變長的:ASCII 用 1 位元組,GBK 已收錄的字與 GBK 完全相同(2 位元組),只有 GBK 之外的字元才用 4 位元組形式——例如 𠀀(U+20000)是 95 32 82 36。
GB18030 自 2001 年起是中國的強制性國家標準,要求在中國銷售的軟體支援它——這是它能完整涵蓋 Unicode 的原因。
UTF-16 對基本平面字元用一個 16 位元碼元,對補充平面字元(如擴展 B 區罕字)用一對「代理對」碼元——這就是為什麼有些字「佔兩個 char」。
在 JavaScript 中用 string.length 數中文字元可能出錯:補充平面字元的 .length 是 2。要按真正的字元迭代應使用 Array.from() 或 for...of。
HTML 數字實體 中 與 中 表示同一個「中」字——前者十六進位、後者十進位。它們引用的是 Unicode 碼位,與頁面用什麼編碼無關。
同一個漢字在 Big5 與 GBK 裡的位元組幾乎總是不同(如「繁」:Big5 是 C163,GBK 是 B7B1)。這正是跨編碼遷移必須逐字映射、不能直接拷貝位元組的原因。
常見問題
-
碼位是字元在 Unicode 字元集中的抽象編號(如「中」= U+4E2D),它不規定如何儲存為位元組。UTF-8 是一種把碼位編碼成位元組的具體方案:ASCII 用 1 位元組,常見漢字用 3 位元組。同一個碼位在 UTF-8、UTF-16、UTF-32 下的位元組各不相同,但指向的是同一個字元。
-
Big5 是繁體中文的傳統編碼,以繁體字與符號為主,大多數簡體專用字並未收錄——但並非「完全不含簡體字」:万、与、厂、气 都有 Big5 碼位,而 几、儿 本身就是 Big5 收錄的繁體字,只是恰好與簡體同形。當某個字確實不在 Big5 時,Big5 欄會顯示「不在 Big5」。這類字元若要儲存,應使用 GBK、GB18030 或 UTF-8——GB18030 一定有對應編碼,因為它涵蓋整個 Unicode。
-
GBK 是 2 位元組定長編碼,收錄約兩萬字。GB18030 是變長編碼(1、2、4 位元組),涵蓋整個 Unicode,且是中國的強制國家標準。關鍵點:對已在 GBK 中的字元,二者編碼完全相同;只有 GBK 範圍之外的字元,GB18030 才用 4 位元組表示。本工具會算出這三種形式中正確的那一種並標註出來:輸入 𠀀(U+20000,擴展 B 區,不在 GBK 內),GB18030 欄顯示 95 32 82 36,而 Big5 與 GBK 兩欄顯示「不在」。
-
BE 指 Big-Endian(大端序),即高位位元組在前。本工具顯示的是 UTF-16 的碼元(每個 16 位元碼元一組,如「中」是 4E2D),按大端序書寫。若你的系統使用小端序(LE),位元組順序會顛倒(2D4E)。基本平面字元是 1 個碼元,補充平面字元是一對代理對碼元。
-
可以。Unicode 碼位、UTF-8、UTF-16、HTML 實體與十進位碼位對任意字元都有效,包括 ASCII 字母、標點和表情符號。ASCII 字母在三種編碼裡都是同一個單位元組(A 就是 41),因為 Big5、GBK、GB18030 都相容 ASCII。其餘字元:Big5 與 GBK 兩欄只對其收錄的給出值,否則顯示「不在…」;GB18030 欄則永遠有值,因為它涵蓋整個 Unicode——表情符號這類補充平面字元是 4 位元組。表情符號同時會以 4 位元組 UTF-8 和代理對 UTF-16 正確顯示。
-
工具會按 Unicode 碼位逐字拆分,為每個字元生成一張獨立的編碼卡片。拆分使用 Array.from,因此需要代理對的四位元組字元(如擴展 B 區罕字)會被當作單個字元,不會被截斷。普通空白字元會被跳過,以免產生空卡片。
-
不會。所有編碼(Unicode、UTF-8、UTF-16、實體、十進位)都在瀏覽器本地用 JavaScript 計算。唯一的網路請求是一次性、可快取地下載 Big5 / GB 編碼詞表(encmap.json),用於查表;你的文字本身從不離開你的裝置。
-
工具會優雅降級:Unicode 碼位、UTF-8、UTF-16、HTML 實體與十進位碼位仍然正常顯示(它們由 JS 本地計算,不依賴詞表)。Big5 與 GBK 兩欄會暫時不可用,並在結果上方提示詞表未能載入。GB18030 欄只有 2 位元組情形依賴詞表:ASCII 的 1 位元組與 GBK 之外的 4 位元組形式都是按公式算出的,不受影響。重新整理頁面通常即可恢復。
-
因為同一個字在不同編碼中的位元組幾乎總是不同的(如「繁」在 Big5 是 C163,在 GBK 是 B7B1)。把 Big5 位元組直接當作 GBK 或 UTF-8 讀取就會產生亂碼。正確做法是:先用源編碼把位元組解碼成 Unicode 字元,再用目標編碼重新編碼——本工具正好幫你核對每一步的對應關係。
-
沒有關係。HTML 數字實體(十六進位 中 或十進位 中)引用的是 Unicode 碼位,與頁面宣告的字元集無關。這意味著即使頁面用 ASCII 儲存,你也能用實體表示任意 Unicode 字元——這在郵件範本、設定檔或無法直接輸入中文的環境裡很有用。
Related News
You may be interested in these recent stories from our newsroom.
-
One Generated Prompt Beat Up to 63 Per Cent of a Top Conference's LLM Techniques
A University of Virginia team reproduced 35 ICSE 2026 techniques and outperformed 37 to 63 per cent of them with a single prompt to a newer...
-
The Sixth Exploited Langflow Flaw This Year Is Not a Vulnerability Story
VulnCheck has recorded 360 attacks on a Langflow flaw fixed in January. It is the sixth separately identified Langflow vulnerability exploit...
-
Broadcom Already Maintains Spring and RabbitMQ. Now It Will Sell You Clean Builds.
A reproducible build proves the binary matches the source. It says nothing about whether the source is safe, which is where the damaging inc...
方法與來源
計算方式
For each character the tool reports its Unicode code point, its UTF-8 bytes, its UTF-16 big-endian code units with surrogate pairs kept intact, its Big5 bytes where the character exists in Big5, its GBK/GB2312 bytes, its GB18030 form — two bytes where that equals GBK, four where it does not — plus the HTML numeric entity and the decimal code point. The Unicode and UTF forms are computed in the browser; the legacy encodings come from a compiled table of 20,902 characters.
本工具採用的標準
- UTF-16 is reported as code units with surrogate pairs left intact rather than collapsed, because a character outside the Basic Multilingual Plane is two units and pretending otherwise is how CJK string bugs start.
- Big5 covers Traditional characters only. A Simplified-only character has no Big5 representation and the tool reports its absence rather than inventing a mapping.
- GB18030 is shown separately from GBK because they coincide in the two-byte range and diverge in the four-byte one; showing only "GBK" hides that a character needs four bytes.
- 20,902 characters are covered — the CJK Unified Ideographs base block. A character outside it returns its Unicode forms without a legacy mapping rather than a guess.
資料來源
- The Unicode Standard: https://www.unicode.org/versions/latest/ — code points, planes, and the surrogate mechanism that makes the UTF-16 column non-obvious.
- WHATWG Encoding Standard: https://encoding.spec.whatwg.org/ — the specification of Big5, GBK and GB18030 as implemented on the web, including the index tables these byte values correspond to.
- GB 18030 is the Chinese national standard for character encoding and is mandatory for software sold in mainland China; GBK and GB 2312 are its predecessors, and Big5 is the de-facto Traditional encoding from Taiwan and Hong Kong. The tool reports all of them because a CJK developer still meets all of them.
可能使本頁過時的因素
- The legacy encoding table is a compiled snapshot of 20,902 characters and nothing refetches it. Unicode adds characters with each release; the legacy encodings do not grow, so the gap is in newer characters having Unicode forms and no legacy mapping — which is correct, not missing data.
Pick up where you left off
Stored only in this browser — never sent to our servers.