简介：《汉字拼音数据库》是一份面向开发人员的数据资源，提供汉字到标准拼音的逐字映射，适用于中文输入法、语音识别、搜索引擎提示及汉字教学等场景。资源压缩包仅有1.31MB，共包含33个文件，既便于人工查阅和编辑的Excel表格，也提供支持结构化查询的数据库文件，同时还附带完整的VS2010项目源码。源码中覆盖了数据库连接辅助类、拼音服务类、主窗体及界面资源，开发者可直接在VS2010中导入项目，附加数据库后即可运行，并可在此基础上扩展出汉字转拼音接口、拼音检字工具或批量注音模块。数据库按照统一编码存储所有汉字及其标准拼音，保证了跨平台环境下的数据兼容性与准确性。目前已有378人浏览学习，适合需要快速实现中文拼音功能的初中级开发者参考使用。
1. 汉字拼音数据库：一张“字→音”表为什么远远不够
做输入法、语音合成文本前端、拼音搜索这类功能时，第一反应是去网上找一个现成的“汉字拼音数据库”，下载下来一个 CSV 或者 SQLite 文件直接用。但真正动手的人很快会发现一个反直觉的事实：字符和拼音的对照关系只是这个数据库最表层的东西，多音字、轻声、变调、繁简体码位才是决定它能不能用的关键。一个只存“字→音”的静态表，在“重庆”这种词上百分之百会标错。汉字拼音数据库的真正价值，在于它把“单字读音候选集合”和“上下文选择逻辑”分开处理：数据层只负责提供某个字有哪些合法读音，规则层负责在具体词语中确定用哪个。这篇文章会从数据源选型、多音字消歧、建库流程、常见坑位到验证方法，完整走一遍一个可落地的汉字拼音数据库是怎么从零做出来的，适合正在做拼音输入、TTS 前端正则化或者搜索索引的开发者。
2. 汉字拼音数据库的数据源选型：两份基础数据怎么配合
2.1 Unihan_Readings.txt 的字段格式：解析前先看懂三列
最常见的起点是一份名为 Unihan_Readings.txt 的标准属性文件，它由 Unicode 标准附带发布，描述每个汉字的读音属性。文件是纯文本，每一行三列，用制表符分隔。第一列是 U+ 开头的十六进制码位，第二列是属性名，第三列是这个属性的取值。以 kMandarin 属性为例，它的取值就是这个字的现代汉语拼音，带数字声调音符，比如 zhong1 zhong4。需要特别注意的是，这个文件并不是每个字都有 kMandarin 字段，少数字只有 kHanyuPinyin 或干脆没有任何读音属性；而且 kMandarin 给出的多个读音是平铺列表，没有频率信息，也没有语境标签。
解析这类文件最稳的方式是逐行读、按 Tab 切分、只看第二个字段等于 kMandarin 的行。实际解析中有一个高频翻车点：第三列取值里可能包含空格，多个拼音用空格分隔，不能把整行按空格直接切，否则会把码位和属性名切碎。正确做法是先按 Tab 切出三个字段，再对第三个字段按空格拆分。还有一个隐藏细节：文件里偶尔有以 # 开头的注释行，以及个别行只有两个字段，这些都要在循环里直接跳过，否则会抛 IndexError。
2.2 词表从哪来：整词注音要比单字注音更可靠
只有一个单字读音列表还不够，因为数据库要服务的是句子和词语，不是孤立汉字。比如“行”在 kMandarin 里会有 xing2 和 hang2 两个音，单独看到“行”字根本无法判断，只有看到“银行”或者“行走”才知道该选哪个。因此一份靠谱的汉字拼音数据库必须叠加一个词级映射表：词语作为整体，配上整词拼音。这里的词表不需要做到分词器的规模，覆盖高频多音字词就够了，大约几千条能让绝大多数场景达到可用水平。
词表的来源一般有两个方向：一是从公开的大规模语料里统计抽取含多音字的二字词，按词频排序后人工校验前几百条；二是直接用输入法词库里的拼音标注数据做映射。第二种虽然省事，但要注意词库的颗粒度和注音规范可能与你的场景不一致。我一般会先抽取词频 Top 500 的多音字词，逐条人工核对拼音，把它作为种子词表，后续再靠实际查询日志持续回补。
2.3 两种数据怎么合并：不要互相覆盖
单字读音表和词表合并时最忌讳的逻辑是让词表直接覆盖单字表。正确设计是两张表各司其职：字表回答“这个字有哪些合法读音”，词表回答“这个词语整体怎么读”。查询时先查词表，词表命中就直接返回整词拼音；词表没命中，再退回到单字表，逐字取默认读音。这个回退顺序非常重要，如果反过来先逐字拼，再查词表修正，逻辑上会很难维护——因为修正规则永远追不上词表的增长速度。
3. 多音字消歧：汉字拼音数据库真正难啃的骨头
3.1 多音字分成两类：语音变体和语境变体
多音字问题不能一概而论，从工程角度我习惯把它们分成两类。第一类叫语音变体，同一个词在不同语域中允许有不同的合法读音，比如“血”可以读 xue4 也可以读 xie3，两种读法都有人用，不存在一个绝对正确的答案。这类字做数据库时，策略是标记语域而非硬性二选一。第二类叫语境变体，读音完全由前后字构成的词语决定，比如“重”在“重庆”里读 chong2，在“重量”里读 zhong4，脱离了词语就无法判断。
分类的意义在于分配权重。语境变体是词表要解决的核心问题，词表命中率决定了这类多音字的正确率；语音变体则不需要在数据库层消灭多样性，反而应该保留所有读音并给出适用场景标记。很多建库项目在语音变体上强行统一，结果做输入法时用户打哪个音都觉得自己对，做 TTS 时又因为选了一个不常用的音导致合成结果特别别扭。
3.2 词表优先规则：整词命中就不逐字猜
在具体实现上，最可靠的规则只有一条：整词匹配优先。给定一个待注音的字符串，先尝试用词表从左到右做最长匹配，匹配到词就直接输出该词拼音，然后继续处理剩余部分。这个规则简单且准确率高，因为它回避了最难的部分——逐字读音无法决定的困境。以“长大”为例，两个字分开看，“长”有 zhang3 和 chang2 两个读音，“大”有 da4 和 dai4 两个读音，如果逐字猜大概率会在“长”上选错；但词表把“长大”整体映射成 zhang3 da4，就直接跳过了单字判断。
词表匹配的引擎实现不复杂，哈希表查词即可，关键在匹配方向。我建议用双向匹配：先做最长词匹配，剩余未匹配的单字再按字频取默认音，最后把结果拼接起来。实测中这个策略能覆盖大约百分之八十的多音字问题，剩下的边界情况需要靠动态规划兜底。
3.3 动态规划兜底：切词和注音同时决策
词表没覆盖的情况必然存在，而且集中在低频词和人名地名上。这时候最实用的兜底方案是动态规划：把整句分词和注音当成一个联合决策问题来解。对每个可能的切词方案，累加各词的注音置信度，最后选总置信度最高的方案。置信度来源有两种：词频，以及词表中该词条出现过的次数。
这个方案听起来复杂，但实现起来相当轻。待处理文本长度一般不超过几十个字，候选切分方式有限，用一张一维 DP 表就能完成。状态定义是“前 i 个字的最优总得分”，转移时枚举最后一词的起点 j，分数等于 dp[j] 加上词表中“j 到 i 这段词”的词频对数分。没有词表的连续单字则按单字默认音给一个基础分数。这样处理“今天我去了重庆”时，“重庆”作为一个整体被词表命中，得分远高于“重”和“庆”分别单字累加，于是整个方案会正确切出“重庆”并读成 chong2 qing4。
4. 构建最小汉字拼音数据库：从 Unihan 解析到 SQLite 落地
4.1 解析 Unihan：把三列文本变成 Python 字典
这一节把前面设计的数据流完整落成代码。先写读取 Unihan 文件并抽取 kMandarin 字段的解析器，纯标准库实现，没有任何第三方依赖。
from pathlib import Path UNIHAN_PATH = Path("Unihan_Readings.txt") def load_mandarin(path: Path) -> dict[str, list[str]]: char_pinyins: dict[str, list[str]] = {} with path.open("r", encoding="utf-8") as f: for line in f: line = line.strip() if not line or line.startswith("#"): continue fields = line.split("\t") if len(fields) < 3 or fields[1] != "kMandarin": continue codepoint = int(fields[0][2:], 16) # 去掉 U+ 前缀 char = chr(codepoint) pinyins = fields[2].split() char_pinyins[char] = pinyins return char_pinyins这段代码的逻辑核心有两个防御点：一是跳过以 # 开头的注释行和长度不足三列的异常行，二是先按 Tab 切分再对第三列按空格拆读音列表，顺序不能反过来。参数方面，path 是下载到的 Unihan_Readings.txt 路径，文件编码固定为 utf-8，遇到编码报错优先检查是不是下载过程中被转成了 GBK。返回的字典 key 是单个汉字，value 是该字的所有 kMandarin 读音列表，顺序与文件中的出现顺序一致，不在这里做频率排序。
4.2 建词表映射并用代码合并
接下来定义种子词表。实际项目里这份词表可以单独放在一个 Python 文件或 JSON 文件中维护，这里展示最小形式。词表的原则是宁缺毋滥：只收录能确定读音的高频多音字词，不要为了凑量加入有争议的词条。
POLYPHONE_WORDS = { "银行": "yin2 hang2", "行走": "xing2 zou3", "长大": "zhang3 da4", "重庆": "chong2 qing4", "音乐": "yin1 yue4", "快乐": "kuai4 le4", "的确": "di2 que4", "重新": "chong2 xin1", } def merge_into_db(char_pinyins: dict[str, list[str]], word_map: dict[str, str]) -> tuple[dict, dict]: # 字表保持不变，词表独立存放，不覆盖字表 return char_pinyins, word_map合并不是字面意义上的合并字典，而是把字表和词表放进同一个封装里交给后续查询层使用。查询时先检查整词是否在 word_map 中，命中就直接返回；没命中则逐个查 char_pinyins 取第一个读音作为默认。这样设计的好处是字表可以持续随 Unicode 标准更新，词表可以按业务场景单独维护，互不干扰。
4.3 建 SQLite 表并写入：字段与索引设计
存储层我推荐用 SQLite，单文件、零配置、查询性能足够。需要两张表：hanzi 表存单字读音，words 表存整词读音。
CREATE TABLE IF NOT EXISTS hanzi ( id INTEGER PRIMARY KEY AUTOINCREMENT, char TEXT NOT NULL UNIQUE, codepoint INTEGER NOT NULL, pinyins TEXT NOT NULL ); CREATE TABLE IF NOT EXISTS words ( id INTEGER PRIMARY KEY AUTOINCREMENT, word TEXT NOT NULL UNIQUE, pinyin TEXT NOT NULL ); CREATE INDEX IF NOT EXISTS idx_hanzi_char ON hanzi(char); CREATE INDEX IF NOT EXISTS idx_words_word ON words(word);pinyins 字段用空格分隔的字符串存多个读音，查询拆开即可。不要把多音字拆成多行，否则查“一个字的全部读音”时要多一次聚合。words 表的 word 列加 UNIQUE 约束能有效防重复，配合 INSERT OR IGNORE 可以把词表更新变成幂等操作。
4.4 查询验证：正向查字音、反向查拼音
建完表后必须写一个查询验证脚本，确认正反两个方向的查询都可用。正向查询指输入汉字得到拼音，反向查询指输入拼音得到候选汉字列表，后者是拼音搜索的核心能力。
import sqlite3 def lookup_char(conn: sqlite3.Connection, ch: str) -> str | None: cur = conn.execute( "SELECT pinyins FROM hanzi WHERE char = ?", (ch,)) row = cur.fetchone() return row[0] if row else None def lookup_word(conn: sqlite3.Connection, word: str) -> str | None: cur = conn.execute( "SELECT pinyin FROM words WHERE word = ?", (word,)) row = cur.fetchone() return row[0] if row else None def reverse_lookup(conn: sqlite3.Connection, pinyin: str) -> list[str]: pattern = f"%{pinyin}%" cur = conn.execute( "SELECT char FROM hanzi WHERE pinyins LIKE ?", (pattern,)) return [row[0] for row in cur.fetchall()]验证时拿“重庆”“银行”“的确”三个词分别调用 lookup_word，必须全部返回正确读音；再用 reverse_lookup 查 zhong4，结果中应该包含“重”这个字。如果逆向查询漏字，多半是入库时声调符号格式混用，这个陷阱下一章单独展开。
5. 建库必看的 5 个典型坑：现象、原因与解决办法
5.1 “谁”字两种读音并存：别默认取第一个
现象：字表里“谁”存在 shui2 和 shei2 两个读音，默认取第一个后，在“谁人”这类词里读出来非常书面化，口语场景听着不对。
原因：kMandarin 的读音列表是平铺关系，不含口语书面语标记，也不含使用频率。把它当频率排序是大多数人的第一反应，但读音顺序本身并不能代表哪个更常用。
解决：在词表里针对这类读音并存且语域分化的字加场景标记，比如“谁”默认音频仍取 shui2，另建一个口语读音映射表，由上层应用按文本风格决定启用哪个。不要在数据库层强行删掉另一个音。
5.2 轻声不该塞进字库
现象：把“东西”整体注音时，想标出“西”的轻声，但字库里“西”只有 xi1，注释写不进词表。
原因：轻声音节本质上属于语流音变和词汇音变，不属于单字读音属性。单字层面没有轻声这个概念，硬塞会让字表失去一致性。
解决：词表字段明确允许轻声写法，用不带声调数字的拼音或数字 5 标记轻声，比如 dong1 xi5。同时约定：字表只存原调，词表存实际发音，两层之间不互相校验。
5.3 声调符号表示法混用
现象：一批数据里的拼音是 zhong1，另一批是 zhōng，前端判断 pinyin == "zhong1" 时全部失配，但人眼看不出问题。
原因：数据源混用了数字调号和带变音符号的字母两种声调表示法，入库前没有做归一化。
解决：写一个转换函数，把带符号的韵母映射回数字调，例如 “ā á ǎ à” 全部转成 a1 到 a4。入库时统一存数字调格式，需要展示时再转回符号，不要在数据库里存两种格式。
5.4 繁简体码位不一致
现象：用户输入“发”的拼音 fa1，想匹配“發”和“髮”，结果反向查询只返回简体结果，繁体全丢。
原因：繁体与简体在 Unicode 中是不同码位，拼音相同但作为独立字符存储，而业务数据里没有做关联。
解决：入库时增加一个合并键，把读音相同、繁体简体关联的字归组。最简单的做法是在 hanzi 表加一列 group_id，同一拼音组的字共享同一个 id，反向查询时按 group_id 聚合返回。
5.5 “一”“不”的变调该交给谁
现象：把这句话“一个两个不一样”逐字注音后直接喂给语音合成，读出来“一”全是 yī，破音严重。
原因：字典里记录的是单字原调，而实际语流中“一”在去声前要变调为二声，在非去声前变调为四声，这是连读变调规则，不属于数据库内容。
解决：字库只存原调，变调由上层 TTS 前端规则处理。宁可让数据库“懒”，也不要试图把变调后的音写进字表，否则同一个字在不同上下文会出现互相矛盾的数据，非常难维护。
6. 用带注音的语料验证字库：三个指标一个脚本
6.1 验证脚本：逐字比对并输出三个指标
数据库建得再快，没有验证数据就是心里没底。我习惯的做法是准备一份带完整拼音标注的文本语料，语料不用多，两三千字即可，但必须包含“重庆”“银行”“长大”这类多音字词。验证脚本逐字比对语料里的注音和数据库输出，计算三个指标：整体字音正确率、多音字正确率、未收录率。
def evaluate(gold: list[tuple[str, str]], predict: list[tuple[str, str]]) -> dict: total = len(gold) hit = sum(1 for g, p in zip(gold, predict) if g[1] == p[1]) polyphonic = [(g, p) for g, p in zip(gold, predict) if len(g[0]) > 0] # 实际用多音字表过滤 poly_hit = sum(1 for g, p in polyphonic if g[1] == p[1]) missing = sum(1 for g, p in predict if p[1] == "") return { "accuracy": hit / total, "poly_accuracy": poly_hit / len(polyphonic), "missing_rate": missing / total, }gold 来自语料标注，predict 来自数据库逐字查询。多音字过滤方式不必追求完美，直接拿字库里读音数量大于一的字做列表即可。
6.2 用验证结果反哺：先补词表，再调规则
验证结果不能只看数字，还要按错误样本分类决定下一步动作。我的经验是：未收录率高于 2%，先补字表；多音字正确率低于 90%，几乎都是词表覆盖不足，优先从错误样本提取未命中词组，逐条加入词表，而不是急着调 DP 置信度分数；只有整体正确率上不去且错误集中在无词表可依的低频组合时，才去调默认音排序。
整个建库过程做完，我最深的体会是：汉字拼音数据库不是一张静态表，而是一套“字表 + 词表 + 规则”的分层系统。字表追求完整，词表追求场景覆盖，规则追求最小化。现在每当我拿到一批新数据，第一反应永远是先跑一遍验证脚本看三个指标，而不是直接改规则。先看缺什么，再决定动哪一层，能省掉大量反复试错的时间，希望帮到你。
本文还有配套的精品资源，点击获取
