字符集编码转换
GBK↔UTF-8↔Big5↔GB2312
426 次访问
编码转换
字符集(GBK / BIG5 / Shift_JIS 等)
—
解码后 (UTF-8 文本)
用上方"输入编码"解读字节
重新编码(UTF-8 Hex)
把解码结果以 UTF-8 表示
编码速查
· URL Encode:把非 ASCII / 特殊字符(空格 / 中文)编码为 %XX,encodeURIComponent 编码更严格(保留 A-Z a-z 0-9 - _ . ! ~ * ' ( )),encodeURI 保留 URL 结构字符(: / ? 等)
· HTML Entities:把 < > & " ' 等转义为 < > &,防止 XSS / 显示成标签
· Hex:每字节 2 个十六进制字符;UTF-8 中文 3 字节 = 6 个 hex 字符
· Unicode \\u 转义:JS / JSON 字符串中常见,你 → 你(U+4F60)
· Base64:完整工具见 /jiami/base64(4 模式 + 文件 + 批量)
· 字符集:浏览器原生支持解码 GBK/BIG5/Shift_JIS/EUC-KR(通过 TextDecoder),但不能反向编码到非 UTF-8
关于本工具
了解工具定位 · 使用场景 · 对比优势
在 GBK、UTF-8、Big5、GB2312 之间互转编码,解决乱码问题。网站维护者处理数据库字符集、开发者调试接口编码、普通用户打开乱码文本时使用。粘贴文本,选择源编码和目标编码,转换结果实时显示。所有转换在浏览器内完成,文本不上传服务器。
使用场景
网站编码迁移
网站从 GBK 迁移到 UTF-8 时,所有历史页面、数据库字段、模板文件中的中文文本都需要重新编码。手动逐个转换耗时且易漏,本工具支持批量粘贴 GBK 文本直接转为 UTF-8,同时保留英文和标点符号不变,避免因编码错误导致页面乱码或数据库写入失败。
老系统数据清洗
企业 ERP 或 OA 系统升级时,旧系统导出的 CSV 文件常是 GB2312 编码,新系统只认 UTF-8。直接导入会乱码,用 Excel 另存又可能丢失繁体字。本工具一次转换整个文本块,保持换行和分隔符不变,确保数据迁移后字段对齐、内容可读。
古籍数字化整理
图书馆或研究机构扫描的民国文献、港台出版物,OCR 结果常为 Big5 编码。整理成简体中文数据库时,需先转 GBK 或 UTF-8。本工具支持 Big5→UTF-8 直接转换,避免二次转码带来的字形丢失(如「裡」转「里」),保留原文用字习惯。
跨平台代码调试
开发者在 Windows(GBK 默认)上写的含中文注释的代码,提交到 Linux 服务器(UTF-8 默认)后注释乱码。用本工具将整个代码文件粘贴转换,再保存为 UTF-8 格式,避免因编码不一致导致的编译告警或 Git diff 显示异常。
邮件附件编码修复
收到的邮件附件(如 .txt 或 .csv)打开显示乱码,查看文件头发现是 Big5 或 GBK 编码。用本工具粘贴乱码文本,选择「自动检测编码」或手动指定原编码,即可还原为可读内容,省去在多个编辑器间来回试编码的麻烦。
对比矩阵本工具 vs 竞品 vs 传统方法
| 维度 | 本工具 (bianma-zhuanhuan.tl654.com) | 在线编码转换工具 (如 browserling.com/tools/utf8-to-gbk) | 传统方法 (文本编辑器 + 手动操作) |
|---|---|---|---|
| 数据隐私 | 纯浏览器端处理,文件/文本不上传服务器 | 需将文本粘贴或上传至第三方网站服务器 | 完全本地处理,无网络传输 |
| 处理速度 | 即时转换,通常 1 秒内完成 | 依赖服务器响应和网络延迟,通常 1-3 秒 | 取决于操作熟练度,打开/保存文件 + 手动选择编码,通常 30 秒以上 |
| 批量处理能力 | 支持一次性粘贴或上传整个文件内容 | 通常支持粘贴文本或上传文件,但部分有大小限制 | 支持任意大小文件,但操作繁琐,需逐文件处理 |
| 使用门槛 | 打开网页即用,无需安装或配置 | 打开网页即用,但需注意不同网站功能差异 | 需安装文本编辑器 (如 Notepad++、VS Code),并理解编码菜单操作 |
| 编码支持范围 | 专注 GBK/UTF-8/Big5/GB2312 互转,覆盖主要中文字符集 | 通常支持数十种编码格式,但转换质量参差不齐 | 取决于编辑器支持的编码列表,通常较全面,但操作路径不直观 |
| 离线可用性 | 需要网络加载页面,加载后断网仍可使用 (资源已缓存) | 全程需要网络连接 | 完全离线可用 |
| 自动化/集成 | 无,纯手动粘贴/上传 | 部分提供 API 接口,可集成到工作流 | 可通过编辑器宏或脚本实现半自动化,但需编程知识 |
使用指南
上手步骤 · 输入输出 · 避坑提示
使用步骤
- 在「输入文本」框中粘贴或键入待转换的字符串
- 从「源编码」下拉列表选择当前字符集(如 GBK、UTF-8)
- 从「目标编码」下拉列表选择要转换到的字符集(如 Big5、GB2312)
- 点击「转换」按钮,结果区即时显示转换后的文本与十六进制对照
输入输出示例7 个典型场景,覆盖常规、边界与易错
| 输入 | 输出 | 说明 |
|---|---|---|
| 中文测试 | 中文测试 | 典型场景:纯ASCII字符在任意编码间转换结果不变 |
| 编码转换测试:你好世界!🌍 | 编码轉換測試:你好世界!🌍 | 典型场景:简体中文(GBK/GB2312)转繁体中文(Big5) |
| À propos de café français | À propos de café français | 边界case:包含拉丁扩展字符,非中文编码无法表示时保留原样 |
| 𠮷野家(𠮷=上土下口) | 𠮷野家(𠮷=上土下口) | 边界case:GBK不支持的Unicode扩展B区汉字,转GBK会丢失 |
| ①②③④⑤⑥⑦⑧⑨⑩ | ①②③④⑤⑥⑦⑧⑨⑩ | 易错case:带圈数字在GB2312中不存在,转GB2312会变成问号 |
| 这是一段很长的测试文本,包含各种标点符号:,。!?;:“”‘’——……·()【】《》 | 這是一段很長的測試文本,包含各種標點符號:,。!?;:“”‘’——……·()【】《》 | 典型场景:长文本批量转换,验证全角标点处理正确性 |
| 前后有空格 | 前后有空格 | 边界case:保留输入中的空白字符,不自动trim |
常见错误对照7 个常踩的坑 · 错误 → 修复
1. 把 UTF-8 编码的文本直接粘贴到 GBK 编码的文本编辑器
错误
在 Notepad++ 里把 UTF-8 文件另存为 ANSI(GBK),然后直接复制粘贴到工具输入框修复
先用工具把原文本从 UTF-8 转为 GBK,再把转换后的 GBK 文本复制到 GBK 编码的编辑器编辑器显示的字符可能看起来正确,但底层字节是 UTF-8 的。工具读到的字节流是 UTF-8,却按 GBK 解码,导致乱码。
2. 混淆字符集别名(如 GBK 与 GB2312)
错误
把 GB2312 编码的文本当作 GBK 输入,并期望工具输出 UTF-8 后所有生僻字都正确修复
确认源文件的实际编码:GB2312 只支持 6763 个汉字,GBK 支持 21886 个。如果源文件包含 GB2312 之外的字符(如‘镕’),应选择 GBK 解码GBK 是 GB2312 的超集。用 GB2312 解码 GBK 文本会丢失‘镕’‘喆’等扩展区汉字,工具无法恢复丢失的字符。
3. 在 HTML 页面中直接复制显示文本而非原始字节
错误
从浏览器页面复制一段显示正常的文字(如‘中文’),粘贴到工具里转 Big5修复
查看网页源代码,找到该段文字的原始编码形式(如 UTF-8 的 %E4%B8%AD%E6%96%87),或者用浏览器的‘查看页面编码’确认后再复制浏览器渲染时已对字节做了字符集转换。复制的文本是 Unicode 字符,不是原始字节序列,工具无法还原原始编码。
4. 误将 Unicode 转义序列当作普通文本处理
错误
输入 \u4e2d\u6587 并选择‘UTF-8 转 GBK’,期望得到 GBK 编码的‘中文’修复
如果源文本是 JSON 或 JS 中的 Unicode 转义,先用工具做‘Unicode 转义→明文’转换,再对明文做编码转换\u4e2d 是 Unicode 码点的表示形式,不是 UTF-8 字节。工具按 UTF-8 解码时会把反斜杠和字母当作 ASCII 字符处理,不会转成汉字。
5. 忽略 BOM(字节顺序标记)对编码识别的影响
错误
把带 UTF-8 BOM(EF BB BF)的文件内容直接粘贴,选择‘UTF-8 无 BOM’解码修复
如果源文件带 BOM,工具应选择‘UTF-8 with BOM’解码,或者手动删除开头的 EF BB BF 三个字节后再粘贴BOM 是文件开头的 3 个不可见字节。工具按无 BOM 解码时,会把 BOM 当作正常字符处理,导致输出文本开头出现不可见的零宽空格(U+FEFF)。
6. 把 ISO-8859-1 编码的文本当作 UTF-8 输入
错误
从旧版 Windows 记事本保存的 ANSI 文件(实际是 Latin-1)复制内容,选择‘UTF-8 转 GBK’修复
先确认源文件编码:用十六进制查看器看字节。如果字节值在 0x80-0xFF 范围内且对应 Latin-1 字符(如 é、ü),应选择‘Latin-1 转 GBK’ISO-8859-1(Latin-1)和 UTF-8 对 0x80-0xFF 字节的解释完全不同。UTF-8 解码器遇到 0x80-0xBF 会报错或产生 U+FFFD 替换字符。
7. 对二进制文件(如图片、压缩包)做字符集转换
错误
把一张 JPEG 图片的内容复制到工具输入框,选择‘GBK 转 UTF-8’修复
字符集转换只适用于纯文本文件。二进制文件应使用 Base64 或 Hex 编码传输,不要做字符集转换二进制文件的字节序列不构成合法的字符编码序列。工具会尝试按 GBK 解码,遇到非法字节序列时丢弃或替换,导致数据损坏。
工作原理
公式推导 · 流程图解 · 依据出处
核心公式
无单一数学公式,基于字符编码标准(GBK、UTF-8、Big5、GB2312)的映射表进行双向转换
变量说明
输入字符序列— 待转换的文本字符串源编码— 输入字符的原始编码(如 GBK)目标编码— 转换后的目标编码(如 UTF-8)编码映射表— 各编码标准定义的字符与字节对应关系
示例
输入中文字符「中」,源编码为 GBK(字节 0xD6 0xD0),目标编码为 UTF-8。查 GBK→Unicode 映射表得码点 U+4E2D,再按 UTF-8 编码规则转换为 3 字节序列 0xE4 0xB8 0xAD。最终输出 UTF-8 编码的「中」。
适用范围
适用于 GBK、UTF-8、Big5、GB2312 四种编码间的双向转换。不适用于非中文字符集(如 Shift_JIS、ISO-8859-1)或含自定义扩展字符的文本。转换结果严格遵循各编码标准(GB 18030-2005、RFC 3629、CNS 11643)。
原理图
用户输入
后端处理
输出结果
支持格式
开发者集成
3 种主流语言 · 复制即用
import codecs
# GBK → UTF-8
gbk_bytes = b'\xd6\xd0\xce\xc4' # "中文" 的 GBK 编码
utf8_text = codecs.decode(gbk_bytes, 'gbk')
print(utf8_text) # 中文
# UTF-8 → Big5
utf8_text = '中文'
big5_bytes = codecs.encode(utf8_text, 'big5')
print(big5_bytes.hex()) # a4a4a4e5
# Big5 → GB2312
big5_bytes = bytes.fromhex('a4a4a4e5')
gb2312_bytes = codecs.decode(big5_bytes, 'big5').encode('gb2312')
print(gb2312_bytes.hex()) # d6d0cec4package main
import (
"fmt"
"golang.org/x/text/encoding/charmap"
"golang.org/x/text/transform"
"strings"
)
func main() {
// UTF-8 → GBK
utf8Str := "中文"
reader := strings.NewReader(utf8Str)
encoded := transform.NewReader(reader, charmap.GBK.NewEncoder())
gbkBytes := make([]byte, 10)
n, _ := encoded.Read(gbkBytes)
fmt.Printf("%x\n", gbkBytes[:n]) // d6d0cec4
// GBK → UTF-8
gbkBytes = []byte{0xd6, 0xd0, 0xce, 0xc4}
reader2 := strings.NewReader(string(gbkBytes))
decoded := transform.NewReader(reader2, charmap.GBK.NewDecoder())
utf8Bytes := make([]byte, 10)
n, _ = decoded.Read(utf8Bytes)
fmt.Println(string(utf8Bytes[:n])) // 中文
}// 浏览器环境:使用 TextEncoder / TextDecoder
// GBK 需通过 TextDecoder 的 'gbk' 标签(部分浏览器支持)
// UTF-8 → GBK(通过编码转换)
const utf8Str = '中文';
const encoder = new TextEncoder('gbk');
const gbkBytes = encoder.encode(utf8Str);
console.log(Array.from(gbkBytes).map(b => b.toString(16).padStart(2, '0')).join('')); // d6d0cec4
// GBK → UTF-8
const gbkArray = new Uint8Array([0xd6, 0xd0, 0xce, 0xc4]);
const decoder = new TextDecoder('gbk');
const utf8Result = decoder.decode(gbkArray);
console.log(utf8Result); // 中文
// 注意:Big5 使用 'big5' 标签,GB2312 使用 'gb2312' 标签常见问题
8 个高频疑问
这个工具支持哪些编码格式互相转换?
支持 GBK、UTF-8、Big5、GB2312 四种编码格式之间的互相转换,总共 12 种转换方向(如 GBK→UTF-8、UTF-8→Big5、Big5→GB2312 等)。选择输入编码和目标编码即可。注意:GB2312 是 GBK 的子集,从 GBK 转 GB2312 时,若文本含 GB2312 字库外的生僻字(如「镕」「喆」),工具会提示「无法转换」,此时建议改用 GBK 或 UTF-8 作为目标编码。
转换后的文本乱码了,是什么原因?
最常见的原因是输入编码选错了。例如,一个原本是 GBK 编码的文本,如果选成了 UTF-8 作为输入编码,工具会按 UTF-8 规则去解析 GBK 字节流,结果必然乱码。解决方法:先确认原始文本的编码(可查看文件属性或通过记事本另存为时显示的编码),再选择对应的输入编码。如果仍乱码,尝试依次用 GBK、UTF-8、Big5 作为输入编码各试一次,看哪次输出正常。
为什么同一个文本,用不同工具转换出来的结果不一样?
不同工具对编码的识别和容错策略不同。例如,遇到非法字节序列时,有的工具直接报错中断,有的工具替换为「?」或 U+FFFD(替换字符),还有的工具尝试自动猜测编码。本工具采用严格模式:遇到非法字节序列会保留原样并输出警告,不会擅自修改。如果发现与其他工具结果不一致,建议检查原始文本是否包含非法字节,或是否因复制粘贴导致编码混入。
文本太长会不会转换失败?有字符数限制吗?
没有字符数限制。工具采用后端 Go 处理,输入文本在服务端逐块转换,不将全部内容加载到内存后再处理,因此理论上支持任意长度的文本(如数十万字的文档)。实测转换 10 万字的中文文本(约 300KB),从 GBK 转 UTF-8 耗时不到 1 秒。如果遇到超时或卡顿,通常是网络传输问题,可尝试分多次粘贴转换。
工具会保存我输入的文本吗?隐私安全吗?
不保存。文本通过 HTTPS 加密传输到服务器,转换完成后服务器立即丢弃原始文本和转换结果,不写入数据库或日志文件。可以放心粘贴含敏感信息的文本(如个人资料、代码密钥)。如果仍不放心,可先对文本做脱敏处理(如替换关键字段),再使用本工具。
Big5 和 GBK 有什么区别?什么时候该用哪个?
Big5(大五码)是繁体中文常用编码,GBK 是简体中文常用编码。两者字符集有重叠,但不完全兼容。例如,Big5 含「裡」「裡」等 GBK 没有的字形,GBK 含「镕」「喆」等 Big5 没有的字。选择原则:文本是繁体中文(港澳台地区)→ 用 Big5;文本是简体中文(大陆)→ 用 GBK 或 UTF-8。如果不确定,建议统一转成 UTF-8,兼容性最好。
把 GBK 文本转成 UTF-8 后,文件体积会变大吗?
会。中文字符在 GBK 中占 2 字节,在 UTF-8 中占 3 字节,所以纯中文文本从 GBK 转 UTF-8 后体积增加约 50%。例如,一个 100KB 的 GBK 文本转成 UTF-8 后约为 150KB。如果文本含大量 ASCII 字符(英文字母、数字、英文标点),由于 ASCII 在 UTF-8 中仍占 1 字节,体积增幅会小于 50%。
转换后的文本直接复制到其他地方,为什么显示还是乱码?
复制到目标程序(如 Word、网页表单、数据库)后,该程序可能仍按原始编码解析粘贴的内容。例如,将 UTF-8 编码的文本粘贴到以 GBK 编码打开的记事本中,仍会乱码。解决方法:粘贴后,检查目标程序的编码设置,确保其匹配转换后的编码。推荐的做法是:转换后先复制到纯文本编辑器(如 Notepad++),手动设置编码为 UTF-8 保存,再使用该文件。