汉字编码查询(Big5/GB/Unicode)

CHINESE DEVELOPER TOOLS 字符编码

简繁 EN

By AI Tools Desk

关于这个工具

查汉字的 Unicode、UTF-8、Big5、GBK、GB18030

免费汉字编码查询工具。输入任意字符,逐字显示 Unicode 码位、UTF-8、UTF-16、Big5、GBK/GB2312、GB18030 十六进制,以及 HTML 实体与十进制码位。浏览器本地计算,不上传数据。

RT-DEV-095 · Developer Tools

Enter Chinese characters / text

Parsed per character — computed locally in your browser; nothing is uploaded.

使用方法

粘贴或输入字符

在输入框中粘贴或键入一个或多个字符——汉字、标点、ASCII、表情符号、扩展区罕用字皆可。工具按 Unicode 码位逐字拆分,代理对(如扩展 B 区罕字)会被完整保留为单个字符。

查看每字的编码

每个字符显示为一张卡片:Unicode 码位(U+)、UTF-8 字节、UTF-16 (BE) 码元、Big5、GBK/GB2312、GB18030,以及 HTML 实体(&#x…;)与十进制码位。

理解 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.

View all news →

方法与来源

计算方式

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.

汉字编码查询(Big5/GB/Unicode)