简介一套收录3500个常用汉字的代码调用字典面向需要快速生成中文人名、企业名称、组织名称或个性化昵称的开发者、内容创作者及文案策划者。资源内置常用汉字数据表与辅助调用脚本可直接嵌入姓名生成、品牌命名、随机文本等应用省去自行收集和整理字库的环节。压缩包共3个文件包含两个txt数据文件与一个py脚本整体仅10KB结构简洁、调用轻量。目前已有601人学习浏览适合正在做随机取名工具、批量品牌命名或中文文本生成实验的读者参考。借助这套字典可快速搭建人名生成器、企业名称生成器等基础应用也可作为词库扩展出更多创意玩法txt便于人工查看与二次编辑py脚本则提供开箱即用的调用入口实用性较强。1. 3500个常用汉字代码调用字典先搞清这个「自己整理」到底解决什么问题做 OCR 后处理、文本白名单过滤、随机起名或者输入法联想时几乎都要用到一张常用汉字表。网上能搜到的字表要么是图片要么是排版混乱的网页表格复制下来还夹着一堆标点和生僻异体真正能被代码直接调用的成品少之又少。于是「自己整理 3500 个常用汉字代码调用字典」就成了一个看似简单、实操全是细节的活字怎么筛、结构怎么定、多语言怎么读、边界情况怎么处理。这篇不绕弯子直接按我整理这类码表的完整路径走一遍覆盖选字规则、JSON 结构设计、Python 与 JavaScript 两侧的最小调用实现以及 5 个真实项目里最容易翻车的点。适合正在做中文文本处理、前端输入组件或需要本地字库的开发者照着抄就能用。2. 码表怎么来3500 字既不是拍脑袋也不是贪多2.1 “3500”这个数字从哪来字频覆盖与体验的平衡中文日常文本的字频分布极度集中前 3000 字左右基本覆盖了绝大多数通用语料到 3500 这个量级覆盖率已经接近甚至超过 99%。这个数字并不是拍脑袋定的而是公开的常用字表标准和多个字频统计结果交叠之后处在同一区间。选字太少白名单过滤时人名、地名用字容易被误杀选字太多字典文件体积变大前端加载和传输的成本上升而且会混入一批「认识但很少用」的字反而稀释了「常用」这个定义。从我实际使用的角度看3500 是覆盖率和轻量性之间最稳的平衡点。我自己试过 3000 和 4000 两版3000 在过滤用户昵称输入时漏掉了「玥、翀、淼」这类不算冷门的人名字4000 则开始出现「龘、爨」这种基本只在网络热词里露面的字对业务几乎没有正向贡献。所以最终主表收敛在 3500多出来的字单独挂到扩展区不进主表。2.2 整理流程清洗、去重、补字、排序的四个步骤拿到一份原始字表后第一步不是急着人工过而是先用脚本把混杂在里面的标点、数字、空白和重复项清掉。常见做法是写一个 Python 脚本直接按 Unicode 汉字范围过滤import re with open(raw_chars.txt, encodingutf-8) as f: raw f.read() # 只保留 CJK 统一汉字基本区字符丢掉标点、数字、空白 chars re.findall(r[\u4e00-\u9fff], raw) # 按首次出现顺序去重保留原始顺序便于核对 chars list(dict.fromkeys(chars)) # 按码点排序保证同一次整理出的结果永远稳定 chars.sort(keylambda c: ord(c)) print(去重后字数:, len(chars))逻辑上这段做了三件事re.findall用\u4e00-\u9fff把字符串里所有落在汉字基本区的字符捞出来这一步天然过滤了标点和英文字母dict.fromkeys利用字典键的唯一性做去重同时保留了首次出现的顺序最后的sort按 Unicode 码点重新排列让后续和公开字表比对时有稳定基线。\u4e00-\u9fff是 CJK 统一汉字基本区覆盖了绝大多数简体常用字如果你的业务会碰到扩展区汉字比如「」这个范围就抓不到需要额外加\u3400-\u4dbf扩展 A 区。清洗完成之后需要和公开的常用字表做一次差集比对补上缺字。这一步绕不开因为不同来源的字频统计口径不一样有的偏重新闻语料有的偏重小说语料人名用字和地名用字会差出一批。我一般会拿两份以上字表做交集和并集主表取交集内的高频字并集里出现频率高但没有进交集的字放进待审清单人工过一遍再决定是否补入。补字的原则是只看它在真实文本里是否高频出现不因为它「看起来常用」就收。3. 字典的结构设计键用汉字还是码点这道题没那么简单3.1 两种键方案的取舍把字表变成代码可用字典第一个绕不开的问题是键到底用汉字本身还是用 Unicode 码点。两种方案我都用过各自适用场景差别挺大直接看对比方案可读性查询方式序列化体积跨语言一致性汉字做键调试时一眼看懂dict 直接 O(1)JSON 会转义成 \uXXXX体积略大所有语言都支持码点做键代码里全是数字可读性差需再转一次 chr() 或按区间查纯 ASCII体积更小无转义问题但可读性差我自己的结论是主结构用汉字做键辅助索引再用码点。原因很简单——在真实项目里你 90% 的查询都是dict[中]这种形态代码可读性直接决定维护成本。JSON 序列化时汉字会被转成\u4e2d这类形式文件看着变大了但 gzip 之后差距可以忽略。码点做键更适合那些要按码点区间批量筛选的场景比如「取所有 GB2312 一级字」这时候用码点数组做二分查找反而更直接。3.2 值里放什么拼音、笔画还是业务标记键确定之后值的设计决定这个字典是「一张表」还是「一个工具」。最简形式是值直接存1只做存在性判断但这有点浪费既然整理都整理了顺手把拼音、笔画和字频序号一起放进去调用侧能省掉大量重复计算{ 中: { py: zhong, st: 4, freq: 1 }, 国: { py: guo, st: 8, freq: 2 }, 人: { py: ren, st: 2, freq: 3 } }py字段存全拼小写用来做首字母索引和排序st是笔画数前端展示按笔画排序时直接当排序键freq是字频序号越小代表越常用随机取名时按它加权能得到更自然的组合。这里有一个取舍要提前想清楚如果你只需要白名单过滤带这三个字段会让 JSON 体积翻三倍那就精简成{中: 1}如果要做输入联想、取名、排序这仨字段全部值得保留。存储格式建议直接输出标准 JSON不要输出 Python 的.py字典文件也不要输出 JS 的.js导出文件——JSON 是所有语言都能读的交集后续接什么项目都不用改数据。4. 代码调用落地Python 与 JavaScript 两侧的最小实现4.1 Python 侧加载 JSON、单字查询、按拼音前缀过滤数据文件准备好之后调用侧的核心诉求就是「加载快、查询稳、能按需过滤」。Python 标准库的json模块足够用不需要额外依赖import json with open(hanzi3500.json, encodingutf-8) as f: hanzi json.load(f) def lookup(ch): 单字查询找不到返回 None 而不是抛异常 return hanzi.get(ch) def filter_by_py_prefix(prefix): 按拼音前缀过滤适合做输入联想接口 if not prefix: return list(hanzi.keys()) return [c for c, meta in hanzi.items() if meta[py].startswith(prefix)] print(lookup(中)) print(filter_by_py_prefix(zh)[:10])这里有两个关键设计lookup用dict.get而不是dict[]因为dict[]在键不存在时直接抛KeyError而白名单过滤场景碰到生僻字是常态返回None让调用方自己在业务层决策filter_by_py_prefix遍历整个字典做startswith匹配3500 条数据遍历一次大概是毫秒级完全够用。但如果这个接口会被高频调用每次全表扫描就浪费了正确做法是在加载时顺手建一个首字母倒排索引from collections import defaultdict py_index defaultdict(list) for c, meta in hanzi.items(): py_index[meta[py][0]].append(c) def filter_by_py_prefix_fast(prefix): 先用首字母定位候选桶再精确过滤 if not prefix: return list(hanzi.keys()) bucket py_index.get(prefix[0], []) return [c for c in bucket if hanzi[c][py].startswith(prefix)]这个版本把全表过滤降成了「取一个候选桶 桶内过滤」桶的平均规模只有 3500 除以 26 分之一性能提升一个数量级。代价是多占一小块内存换来高频接口的稳定性值。4.2 JavaScript 侧ESM 导入、空值合并、按值过滤前端项目里最常见的诉求是把字典作为静态模块导入而不是发请求去服务端拉。用原生 ESM 的 JSON 导入语法可以做到零请求import hanzi from ./hanzi3500.json assert { type: json }; export function lookup(ch) { return hanzi[ch] ?? null; } export function filterByPinyin(pyPrefix) { return Object.entries(hanzi) .filter(([, meta]) meta.py.startsWith(pyPrefix)) .map(([ch]) ch); }??空值合并运算符在这里很有用它只在左侧是null或undefined时返回右侧值不会把空字符串也吞掉。Object.entries把字典转成[键, 值]数组之后filter只按拼音前缀筛map再把值丢回去、只留键的数组最后返回的就是符合条件的汉字列表。这段代码在 Node 16 以上的版本可以直接跑如果部署环境比较老assert { type: json }可能报错备选方案是把 JSON 文件内容包一层改成export default { ... }的.js文件或者用fetch在运行时加载。我的习惯是前端项目直接转.js导出省掉打包器对 JSON 的特殊处理也避免旧浏览器兼容问题。5. 避坑指南这个字典在真实项目里翻车的五个典型场景5.1 乱码Windows 下保存的文件带着 BOM读取直接报错现象Python 用encodingutf-8读取时报UnicodeDecodeError或者读出来第一个字符是\ufeffNode 的JSON.parse直接报Unexpected token。原因Windows 记事本保存 UTF-8 文件时默认带 BOM 头\ufeff是一个不可见字符JSON 解析器不认它。解决整理脚本里直接统一写文件用encodingutf-8而不是utf-8-sig如果拿到手的文件已经带了 BOM读取时临时改用utf-8-sig它能自动吞掉\ufeff。后续分发给其他同事时在文件开头看不到 BOM 才算干净。5.2 去重误伤按出现顺序去重把繁简异体关系搞砸了现象整理脚本跑完后发现「台」和「臺」都出现了字表长度超了手动删掉「臺」之后另一个业务同事反馈说他们那边的繁体内容过滤白名单少了字。原因dict.fromkeys按首次出现顺序去重它只认「字符串是否相同」不认识「繁简对应」和「异体关系」。同一份原始素材里如果繁简混排去重结果取决于谁先出现完全是玄学。解决去重之前先过繁简映射表把同一组异体字合并成主字但合并操作不能直接删字否则繁体内容场景会缺字。我的做法是主表存简体另建一个variant_map扩展字段存「简体 → 繁体列表」的映射过滤时繁体先转简体再查主表两头不耽误。5.3 拼音推算翻车用 GB2312 区位码取首字母遇到表外字直接空指针现象排序功能上线后某天日志里开始出现TypeError: NoneType object is not subscriptable定位到是取拼音首字母的某个函数返回了None。原因老方案是用 GB2312 区位码换算出拼音首字母因为 GB2312 的一级汉字是按拼音排序的这个思路在 3755 个字范围内成立。但这个字典是 3500 常用字里面可能混着 GB2312 一级区之外的字区位码换算遇到这些字直接算不出来。解决拼音字段必须在整理阶段就固化进字典的值里运行时只读不推算。整理时用第三方拼音标注工具批量补全全拼人工抽查边界字多音字、生僻字后再落盘。从此运行时逻辑里不准出现任何「根据编码推拼音」的代码。5.4 查询性能用in判断白名单接口响应时间涨了十倍现象一个批量文本过滤接口单条文本 100 个字上线后 P99 响应时间从 20ms 涨到 200ms查了半天发现是白名单判断用的列表套着全表扫描。原因list的in操作是 O(n) 复杂度100 个字每个都扫一遍 3500 长度的列表等于每篇文本多执行了 35 万次比较。解决白名单判断一律用set(hanzi.keys())把存在性检查从 O(n) 降成 O(1)。加载时初始化一个known_chars set(hanzi.keys())过滤逻辑变成ch in known_chars。如果内存紧张也可以直接ch in hanzi用 dict 的键判断复杂度同样是 O(1)只多占一点哈希表开销。5.5 排序反直觉说的按笔画排序结果字表是按码点排的现象前端展示「按笔画排序」的字库列表总有几个字的位置明显不对仔细一看「一」排在了「乙」前面笔画数完全没生效。原因JavaScript 的Array.sort()默认按 UTF-16 码元排序汉字之间的大小关系和笔画没有任何关系Python 的sorted()也有同样问题。码点排序不等于笔画排序。解决排序时显式指定 key 按第 3 章结构里的st字段排笔画相同再按码点兜底保证顺序稳定const sorted Object.entries(hanzi) .sort((a, b) a[1].st - b[1].st || a[0].localeCompare(b[0])) .map(([ch]) ch);a[1].st - b[1].st先比较笔画数结果为 0 时走localeCompare按字典序稳定排序两个条件组合起来不会出现相同笔画数乱序的情况。6. 进阶玩法把 3500 字字典变成随机取名与生僻字检测工具字典的进阶用法我实际项目里用最多的是两个方向随机生成中文昵称以及检测用户输入里的非常用字。随机取名这段逻辑可以直接复用到游戏角色名、头像昵称、测试数据生成器里import json import random with open(hanzi3500.json, encodingutf-8) as f: hanzi json.load(f) def random_name(length2): 默认生成两字名传入 length3 生成三字名 return .join(random.choice(list(hanzi)) for _ in range(length)) def rare_chars(text): 返回文本中不在常用字字典里的字符 known set(hanzi) return [c for c in text if c not in known] print(random_name()) print(rare_chars(你好欢迎来到我的博客))random.choice在 3500 个键里均匀取字两字组合有 1225 万种基本不会撞名rare_chars把字典键转成set之后逐个字符判断配合上节的 O(1) 查询扫一篇千字文章在毫秒级完成。如果你想生成更自然的昵称可以把freq字段的序号当权重random.choices带weights参数按字频加权取样高频字出现的概率大幅提升生成结果明显更顺眼。验证字典质量的办法也简单拿新闻、小说、聊天记录各抽几万字跑一遍rare_chars统计不在表内的字符占比。如果比例超过千分之一说明主表该补字了如果长期接近零可以考虑把主表精简到更小规模减小传输体积。我自己的习惯是把这个工具脚本放进项目仓库的tools/目录每次接入新业务、遇到新文本类型时跑一遍验证再决定要不要调表。血泪教训是有一回把扩展区汉字直接并进了主表结果老系统的字符集不认扩展区码点整条文本处理链路直接崩了从那以后扩展区汉字一律独立文件主表永远保持基本区纯净。3500 这个规模在当前多数业务场景下是够用的但「够用」的前提是表格结构留好了扩展位随时能补随时能查。希望这篇整理思路对你有帮助。本文还有配套的精品资源点击获取
