简介这是一套提供约4792条汉字简体与繁体映射关系的参照数据库覆盖常见高频用字面向需要实现简繁转换、多语言支持或汉字文本处理的开发人员、数据挖掘与语言研究者可直接用于软件界面切换、语料预处理及汉字演变研究。压缩包共含4个文件涵盖SQL、JSON、CSV、XLSX四种主流格式SQL便于搭建关系型数据库进行复杂查询JSON适合网络接口与前后端数据交换CSV可被Excel、pandas等工具直接读取XLSX则便于直观查看和编辑整体大小仅162KB轻量实用。目前已有673人学习资源虽小但覆盖了从数据库管理到数据交换的常见应用场景。下载后可直接获得完整的简繁对照数据无需额外清洗可快速集成到网站、软件或分析项目中用于界面文字自动转换、简繁语料对齐、搜索引擎优化或汉语言学研究能有效节省自行收集整理映射数据的时间。1. 汉字简体繁体参照表数据库先摸清映射结构再谈查询与转换做内容检索、做站点多语言、做OCR后的文字规整几乎都会撞上同一个问题汉字简体繁体参照表数据库到底该怎么组织才能在MySQL、PostgreSQL这类关系型数据库里做关联查询又不会在字符串替换时翻车。常见的全量替换脚本第一轮就会把“皇后”换成“皇後”把“头发”和“发财”的“发”字搅到一起。这份资源把简体、繁体、一简对多繁的候选关系预先拆好同时给出SQL、JSON、CSV三种格式分别对应数据库查询、应用内存字典与离线批处理三类场景。适合正在搭内容系统、需要处理繁简混排数据又不想从零维护映射表的开发者和数据分析师。我拆过好几个版本也从里面吃过亏下面直接写字段设计、导入命令和五个高频坑新手照着做能跑通熟手可以直接跳到避坑章节。2. 三种格式的门道数据模型、字段设计与选型依据2.1 一简对多繁这份表的数据模型是怎么设计的简体转繁体最麻烦的不是字量大而是一个简体字对应多个繁体字。“干”对应“乾”干燥、“幹”干部、“干”天干地支三个候选“发”对应“發”发射、“髮”头发两个候选“后”对应“後”后面、“后”皇后两个候选。如果映射表只维护一列简体一列繁体程序取到最后一条记录就是错的取到第一条也大概率是错的因为常见义项到底该选哪个跟业务场景强相关。我拆过的这份数据库在结构上把映射拆成两层第一层是基础对照行记录每一个简体字与繁体候选的单条对应第二层是分组聚合用group_id把同一个简体字的所有候选绑在一起再用priority标记主次。主候选用作默认转换结果次候选按词频或上下文场景选用。核心思想是对照表只负责给可能对应关系真正的取舍交给上层逻辑而不是让表结构背锅。下面用几个典型分组说明简体group_idpriority繁体典型词发121發发射发122髮头发后331後后面后332后皇后干471乾干燥干472幹干部干473干天干这个表看起来简单但它是整个资源的核心价值所在。没有分组和优先级的设计后续所有转换逻辑都得在代码里自己猜猜一次错一次。拿到数据后我建议先按这个维度检查一遍看看几个高频多义字的分组是否完整再决定要不要继续往下接。2.2 字段清单核心列与扩展列怎么读拿到文件先看头部注释或表结构说明再决定列名怎么引用。常见做法是包含以下列字段名类型含义使用建议simplifiedvarchar(10)简体单字建索引关联查询的左边traditionalvarchar(10)繁体单字建索引反向翻译的右边group_idint分组号同一个简体字的候选共享一个号prioritytinyint优先级1为主字2/3为候选sourcevarchar(50)数据来源可空用于追查映射是否可靠字段名在不同版本里会有差异比如traditional可能写成traditional_chargroup_id可能写成s_idpriority也可能反过来取大值优先。拿到文件后第一件事是统计行数和去重后的简体字数量对照一下README描述是否一致。数字对不上说明文件可能被二次加工过不能直接当准。另外有的版本会在尾部追加“备注”列、词性列或者常用度评分这些扩展列不影响核心功能但可以用来做更细的过滤比如在转换时只保留常用度高于阈值的候选。2.3 三种格式的定位SQL、JSON、CSV各自适合什么场景SQL版本适合直接接进业务库做关联查询。几十KB到几百KB的映射表建好唯一索引之后查询耗时在毫秒级更新映射走SQL事务也比较可靠。JSON版本适合放在应用内存里做字典启动时一次性载入不依赖数据库环境适合写转码工具、做搜索词预处理。CSV版本适合数据分析师批量处理pandas、Excel都能直接读不需要建表也不需要写连接串拿到就能跑。选型没有标准答案我一般按项目形态定团队基础设施是MySQL或PostgreSQL就用SQL版如果是定时脚本或转码工具用JSON版如果数据管道里做清洗CSV最省事。三种格式覆盖同一套映射不存在哪个更准的说法只有哪个更容易接入当前代码的差别。需要注意的是JSON和CSV的内容来自同一份数据不用同时引入两份否则后续更新时容易两边不一致。2.4 覆盖范围与字量不是越大越好这类对照表最容易被拿来比较的就是收录字数。一万多常用字的版本和几万字的扩展版本差异主要在异体字、生僻字和扩展B区及以上字。单纯比拼字量没有意义更大的表会把生僻字也带进来替换时把不该动的字动掉反而在业务里产生噪音。我见过有人拿一个大而全的表做新闻搜索归一化结果一些异体字被替换后用户搜到的结果反而变少了。建议先确认业务覆盖范围做新闻、阅读类的覆盖常用字、次常用字就够做古文、偏旁查询的再考虑扩展版本。拿到CSV文件先跑一段去重脚本统计简体字分组数、繁体字总数如果数字跟业务预期明显不符就不要直接上游使用。注意不要盲目追求字量大先看业务需要覆盖到哪一级汉字。2.5 拿到文件后的五分钟检查流程不管用哪种格式先花五分钟做三件事查行数、查去重后的简体字数、查分组数。命令行一把梭wc -l char_map.csv cut -d, -f1 char_map.csv | tail -n 2 | sort -u | wc -l cut -d, -f3 char_map.csv | tail -n 2 | sort -u | wc -l说明第一条命令看总行数减去表头就是映射记录条数第二条命令按第一列去重得到独立的简体字个数第三条命令按第三列去重得到分组ID个数。如果简体字数远小于记录条数说明大量简体字都有多个繁体候选这是正常现象如果某个简体字对应十几个候选就要人工复核这些候选是否真的属于常见义项很可能是把异体字也收进来了。这三条命令是免费的后悔药能避免把一份结构有问题的数据直接接进生产环境。3. 落库与调用从建表到Python替换的完整路径3.1 SQL导入MySQL建表、LOAD DATA、加索引拿到SQL文件如果是建表加INSERT的形式直接source进客户端就能用。如果拿到的是CSV或者需要自己建表常见做法是手工建表再导入。建表语句里字符集必须用utf8mb4繁体字落在BMP之外时不会出乱码CREATE TABLE IF NOT EXISTS char_map ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, simplified VARCHAR(10) NOT NULL, traditional VARCHAR(10) NOT NULL, group_id INT UNSIGNED NOT NULL DEFAULT 0, priority TINYINT UNSIGNED NOT NULL DEFAULT 1, source VARCHAR(50) DEFAULT , UNIQUE KEY uk_simp_trad (simplified, traditional) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_unicode_ci;说明UNIQUE键约束同一个简体字和繁体字的组合不重复如果原文件里本身有一简对多繁但同一组合重复多条导入就会报错此时需要先去重。collate用utf8mb4_unicode_ci对中文单字查询影响不大但比utf8mb4_general_ci更接近Unicode的默认排序行为。CSV导入用LOAD DATA第一条命令跳过表头第二条命令处理带双引号的字段LOAD DATA LOCAL INFILE /data/char_map.csv INTO TABLE char_map FIELDS TERMINATED BY , OPTIONALLY ENCLOSED BY LINES TERMINATED BY \n IGNORE 1 LINES (simplified, traditional, group_id, priority, source);说明IGNORE 1 LINES是跳过CSV的表头行OPTIONALLY ENCLOSED BY双引号是防止某些列的字段里带逗号。如果你的CSV第一列是id目标列列表里要把id补上并赋值为NULL。导入之后执行一遍ANALYZE TABLE再按priority字段做一次分组统计确认主字候选的比例符合预期。LOAD DATA LOCAL需要数据库账号有FILE权限没有的话改用mysql命令逐行INSERT但几千行数据建议直接用LOAD DATA。3.2 PostgreSQL适配COPY命令与编码处理业务库是PostgreSQL的话MySQL风格的SQL文件不能直接执行反引号、ENGINE、AUTO_INCREMENT这些语法都会被拒。我一般把建表语句改写一遍再用COPY导入CSV。表名和列名要对齐CSV表头CREATE TABLE char_map ( id SERIAL PRIMARY KEY, simplified VARCHAR(10) NOT NULL, traditional VARCHAR(10) NOT NULL, group_id INTEGER NOT NULL DEFAULT 0, priority SMALLINT NOT NULL DEFAULT 1, source VARCHAR(50) DEFAULT );COPY char_map(simplified, traditional, group_id, priority, source) FROM /data/char_map.csv WITH (FORMAT csv, HEADER true, DELIMITER ,, ENCODING UTF8);说明HEADER true告诉COPY第一行是列名DELIMITER默认就是逗号显式写出来是防手误。如果文件是GBK编码需要先转成UTF-8再执行COPYiconv -f GBK -t UTF-8 char_map_gbk.csv char_map_utf8.csv转换后的文件要复查一次简体字长度繁体在转码过程中偶尔会出现半个字符的情况用wc -L检查最长行即可。3.3 SQLite场景快速排查一简多繁的分布SQLite适合做临时工具不用部署服务文件即库。把CSV导进去之后可以直接用SQL查某个简体字的所有候选排查一简多繁的分布非常方便sqlite3 char_map.db EOF .mode csv .import char_map.csv char_map CREATE INDEX idx_simp ON char_map(simplified); SELECT * FROM char_map WHERE simplified发; EOF说明.import的默认行为是不认表头如果CSV第一行是列名导入后需要删掉那条脏数据CREATE INDEX是为了在按简体字查询时走索引。Windows下没有sqlite3命令就用DB Browser for SQLite导入时勾选第一行为列名即可。这个场景适合做数据体检不适合做生产环境的高频查询生产还是交给MySQL或PostgreSQL。3.4 JSON版在Python里做正向与反向映射JSON适合做应用内字典。读取之后我习惯同时构建两张图一张简体到候选列表另一张繁体到简体因为业务里两个方向都会用到import json with open(char_map.json, encodingutf-8) as f: data json.load(f) # data 是 list[dict] simp_to_trad_group {} trad_to_simp {} for item in data: s item[simplified].strip() t item[traditional].strip() g item.get(group_id, 0) p item.get(priority, 1) key (s, g) if key not in simp_to_trad_group: simp_to_trad_group[key] [] simp_to_trad_group[key].append((t, p)) if t not in trad_to_simp: trad_to_simp[t] s说明用(s, g)做键是为了在同一个简体字下按候选组取主字单纯用s做键的话一简多繁的组会被后面的项覆盖。trad_to_simp的覆盖策略是先到先得因为繁体到简体一个方向里同一个繁体字通常只对应一个简体字取第一个即可。如果不放心可以用set收集后按Unicode码位排序再取最小但一般没必要。主字默认转换时从组里挑priority最小的那条def to_traditional(text): out [] for ch in text: candidates simp_to_trad_group.get((ch, 0)) if not candidates: out.append(ch) continue out.append(min(candidates, keylambda x: x[1])[0]) return .join(out)注意这里的group_id取0只是示意逻辑真实数据的group_id从1开始读取时要先统计group_id的取值分布把实际值传进来别写死。3.5 CSV版做批量清洗只动该动的字CSV最直接的使用方式是pandas做批量清洗。一个我常用的写法是先把CSV读成DataFrame再按priority过滤出主字映射最后做逐字替换。先过滤主字是为了避免一简多繁的候选同时进入dict出现“后”被替换成最后一条记录的情况import pandas as pd df pd.read_csv(char_map.csv, encodingutf-8-sig) df df.drop_duplicates(subset[simplified, traditional]) # 主字映射优先级取1若priority列不存在则每个简体字取第一条 main_map {} for s, group in df.groupby(simplified): if priority in df.columns: row group.sort_values(priority).iloc[0] else: row group.iloc[0] main_map[s] row[traditional] text 今天天气很干头发也干了 converted .join(main_map.get(ch, ch) for ch in text) print(converted)说明drop_duplicates去掉重复行避免同一对映射重复写入sort_values(priority)把主候选排到最前iloc[0]取的就是默认转换结果。逐字替换成立的前提是映射粒度是单字如果表里有多字词映射这段逻辑就不适用需要改成最长匹配见后面进阶章节的做法。4. 避坑繁简映射的五个翻车现场4.1 皇后变成皇後一简对多繁误杀现象上线了一套全文替换结果所有“皇后”全部变成“皇後”搜索引擎里搜“皇后”一个结果都出不来。原因替换逻辑只拿了简体“后”到繁体“後”这一条映射。实际上“后”有两个分组表示方位和时间的“后”对应“後”表示君主配偶的“后”本身就写作“后”。把优先级为2的候选取成主字或者根本没使用分组字段都会命中这个坑。解决把主字映射按priority1重新生成转换场景中“后”的主候选改成“後”剩下的“后”在“皇后、后土、后妃”这些词里不参与替换。这其实是把默认行为从全替换改成按分组主字替换同时要建一条词级白名单白名单内的词不转换。现在我做这类表都会强制保留分组字段不再为了图省事只留两列。4.2 台湾用词差异搜“軟體”匹配不到“软件”现象繁简转换做完后繁体站点的搜索词“軟體”在简体内容里依然查不到相关的“软件”内容。原因简体“软”映射到繁体是“軟”“件”映射到“件”但“軟體”是台湾用语大陆对应的是“软件”。把“软件”按字转成繁体得到“軟件”在台湾地区并不常用。这个属于用词差异不是字映射能解决的问题。解决词级术语表要单独维护和字级映射表分开。搜索归一化时需要把“軟體-软件、網路-网络、硬碟-硬盘、滑鼠-鼠标”这类高频异名放进同义词表先做整词映射再做单字映射。数据里如果有按词分组的扩展区直接用词级部分没有的话就在业务侧维护一个几十条的高频词表收益远大于成本。4.3 CSV带着BOM进Excel第一列多出一个“锘”现象CSV文件双击用Excel打开第一列表头前面多了一个奇怪的字符导入MySQL时第一行表头名字和预期不一致。原因文件头带UTF-8 BOM字节序标记Excel和部分数据库导入工具把BOM当作可见字符处理。UTF-8 with BOM本身不是错误只是工具兼容性问题。解决用记事本另存为UTF-8记事本保存的UTF-8不带BOM。或者在Python里用utf-8-sig读取再写一份无BOM文件with open(char_map.csv, encodingutf-8-sig) as f: content f.read() with open(char_map_nobom.csv, w, encodingutf-8) as f: f.write(content)说明utf-8-sig读取会自动剥离BOM重新写的时候用utf-8就没有BOM。命令行环境也可以用sed删掉开头的BOM字节但Python这个写法在Windows下最稳不容易误伤。4.4 MySQL表字符集不对繁体字全变成问号现象数据导入MySQL后查出来的繁体字全部是问号简体却正常。原因建表时用了latin1字符集繁体字里不少字符落在BMP外latin1根本存不住写入时被转成问号。连接串和表字符集不匹配同样会造成写入时乱码这类乱码问题最折腾人排查时先查表字符集再查连接参数。解决建表用utf8mb4连接参数显式声明字符集。以Python为例import pymysql conn pymysql.connect( host127.0.0.1, userroot, passwordxxx, databasetest, charsetutf8mb4, )说明charsetutf8mb4是连接层设置建表时也要保证表字段是utf8mb4两层都对了才不会再出问号。还有一个容易被忽略的地方如果走的是旧项目里的连接池连接池配置里可能把charset写成了utf8需要一并改掉。4.5 生僻字漏转对照表来源有边界现象一段含扩展区字的古文文本转换后没有任何字被替换看起来像是程序没生效。原因很多公开的简繁对照表只收日常用字扩展区字不在收录范围。这不是数据损坏而是资源定位问题——这份数据是给现代文本使用的不是给古籍整理使用的。解决导入后做一次覆盖审计把文本中出现的字跟映射表做差集统计漏转字数。如果漏转率超过业务阈值就考虑放弃这些字的默认转换改为人工校对。审计脚本很短text_chars set(text) dict_chars set(main_map.keys()) | set(trad_to_simp.keys()) missed text_chars - dict_chars print(f未覆盖字数: {len(missed)}, sorted(missed)[:20])说明这里main_map是简体到繁体的主字映射trad_to_simp是繁体到简体的映射两个集合的并集才是当前可用覆盖范围。差集结果随机抽样打印前20个即可全量打印没有意义。5. 进阶把静态映射表变成一个可维护的转换服务5.1 包一层HTTP接口把CSV或JSON载入内存后包一个轻量接口前后端只做“文本进、文本出”。我用的Flask版本思路是启动时加载映射请求时只查表from flask import Flask, request, jsonify import json app Flask(__name__) with open(char_map.json, encodingutf-8) as f: DATA json.load(f) MAIN {} for item in DATA: s, t, p item[simplified], item[traditional], item.get(priority, 1) if s not in MAIN or p MAIN[s][1]: MAIN[s] (t, p) def conv(text): return .join(MAIN.get(ch, (ch, 0))[0] for ch in text) app.post(/convert) def convert(): data request.get_json() return jsonify({text: conv(data.get(text, ))})说明MAIN只存每个简体字优先级最高的候选几千字文本的响应在毫秒级。加载逻辑必须在启动时完成放进请求内会被高并发打穿。5.2 词级消歧与不转换词表单字映射解决不了的“后、发、干、面”多义字要靠词级词典兜底先做最长词匹配匹配上的输出词表结果剩下的字走单字表。实测下来“皇后、后土、干部”这几个词必须放不转换列表里否则转换完就是错的。PHRASES {头发: 頭髮, 发射: 發射} NOCONV {皇后, 后土, 干部} def smart(text): out, i [], 0 while i len(text): word3 text[i:i3] word2 text[i:i2] if word3 in PHRASES or word3 in NOCONV: out.append(PHRASES.get(word3, word3)); i 3 elif word2 in PHRASES or word2 in NOCONV: out.append(PHRASES.get(word2, word2)); i 2 else: out.append(conv(text[i])); i 1 return .join(out)说明这里的词典规模小直接遍历即可量级上了万条再考虑用前缀树或AC自动机不要一上来就上重型数据结构。5.3 回归语料每次改动都要跑一遍的后悔药替换逻辑改多了改一个词表带崩另一段文本的翻车我经历过不止一次。现在我每次改动映射都拿一份固定语料做diff典型用例就几十行用例期望输出今天天气很干头发干了今天天氣很乾頭髮乾了皇后驾到皇后駕到他把硬盘拆了他把硬碟拆了跑完diff再上线比上线后查翻车现场踏实得多。从那以后我每次动映射表都会强制走一遍这个回归脚本确认变化点都在预期范围内才敢提交。希望帮到你。本文还有配套的精品资源点击获取