尧图网站建设 
简介这份MySQL数据库将简繁汉字的笔画数、笔顺、Unicode编码与GB编码整合为结构化数据面向汉字输入法开发、汉字教学、书法研究以及姓名或诗词笔画计算等场景。资源包仅304KB共1个SQL脚本文件导入MySQL后即可生成汉字笔画信息表支持按笔画数、笔顺等字段进行查询、排序与统计分析例如快速筛选笔画最多的字或按书写顺序排列。已有980人学习下载。使用者无需自行爬取或整理汉字属性可直接获得标准编码与书写顺序数据便于快速搭建原型、开展字形对照研究也可用于课程示例与演示帮助学生理解笔画规则。无论是构建教学课件、输入法词库还是开展字形统计这些字段都能直接复用省去重复整理工作。整体来看该数据库体积小巧但字段完整能有效缩短汉字类应用的前期数据准备周期适合作为汉字信息化项目的基础数据集。1. 汉字笔画及Unicode数据库简繁MySQL这套数据到底解决什么问题做识字类App、校对系统或者排版引擎的人大概率都遇到过这三件事一个字明明认识但就是不确定它几画一个简体字对应的繁体字在数据库里查不到Unicode码点拿到了却不知道怎么和笔画数一起存进MySQL。汉字笔画及Unicode数据库简繁MySQL简单说就是把每一个汉字的码点、笔画数、简繁属性、Unicode类别整理成可查询的表让排序、筛选和程序对接都有标准答案。它解决的是「汉字数据进MySQL之后怎么查、怎么排、怎么不丢字」的问题适合正在做字库工具、输入法词库、中文教学软件以及被字符集折腾过的人。这个方案不是要你从零造字库而是把已经存在的公开数据整理成自己能维护的MySQL库。2. 先拆分数据模型笔画、码点、简繁为什么要分开建表2.1 不要迷信「一个汉字一行」三个现实反例很多人第一反应是建一张表字段叫「汉字、笔画数、Unicode码、简繁标识」然后往里灌数据。这种设计自己写几个查询没问题一旦碰上真实中文文本立刻会发现三个反例。第一个反例是同一个汉字有多个码点。「里」和「裡」是简繁关系但「里」本身在Unicode里还有一个兼容汉字符号「户」和「戶」更典型简体和繁体在Unicode中是不同的码点可字形几乎一样。如果你用汉字本身做主键这一行插进去另一行就撞了。第二个反例是笔画数和码点没有因果关系。Unicode是按部首和笔画排序编码的但「一」的码点小于「丁」「丁」的码点小于「七」码点顺序和笔画数排序并不完全一致只存一个字段根本没法做稳定的笔画排序。第三个反例是简繁不是一对一。「干」的繁体可能是「幹」也可能是「乾」一个简体字对应多个繁体字是常态如果表结构里只放一个「繁体」字段数据必然丢。所以我的结论是不要试图用一张宽表解决所有问题。应该把「字符本身」「笔画明细」「简繁映射」「Unicode类别」拆开用码点作为稳定关联键。这样后续加数据源、加笔顺、加异体字都不用改主表。2.2 码点当主键汉字只当业务属性为什么不直接拿汉字做主键因为汉字是给人和业务看的码点是给计算机看的。一个程序从外部拿到一段文本要查笔画最可靠的做法是拿到字符后调用ord()得到整数码点然后用这个整数去查MySQL而不是把字符拼进SQL字符串里等数据库去解析。字符在传输过程中受客户端字符集影响可能被转成错误字节码点是整数不会因为连接字符集变化而改变。我一般会把码点字段设计成INT UNSIGNED同时保留一个CHAR(6)的十六进制形式类似U4E2D方便人读和调试。汉字本身用VARCHAR(4)就够因为Unicode里汉字在基本平面最多占4个字节utf8mb4但码点可能落到扩展区那个字符用VARCHAR(4)存没问题只是排序和比较仍然依赖码点字段。主键用码点业务键用「汉字变体类型」的组合唯一索引这样同一个字形出现在不同分区时也不会互相覆盖。简繁映射单独建一张表不塞进字符主表。原因很简单一个简体字可能映射到多个繁体字一对多关系在关系型数据库里就该用子表表达。映射表里再加一个map_type字段标记是「一一对应」还是「一简多繁」以后做全文检索或者词向量对齐时就知道该按哪种规则展开。2.3 建表SQLutf8mb4、InnoDB、外键与索引怎么选建库建表这一步是后面所有操作的地基。先上完整SQL我标注了每一处的选择理由。-- 建库必须用utf8mb4而不是utf8 CREATE DATABASE hanzi_unicode DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; USE hanzi_unicode; -- 字符主表一个码点一行 CREATE TABLE char_base ( cp INT UNSIGNED NOT NULL COMMENT Unicode码点十进制, hex_cp CHAR(6) NOT NULL COMMENT UXXXX十六进制表示, char_text VARCHAR(4) NOT NULL COMMENT 汉字字符, unicode_category CHAR(2) NOT NULL DEFAULT Lo COMMENT Unicode类别如Lo汉字Po标点, stroke_count TINYINT UNSIGNED NOT NULL COMMENT 总笔画数, variant_type ENUM(简,繁,异体,通用) NOT NULL DEFAULT 通用 COMMENT 简繁属性, source VARCHAR(32) DEFAULT NULL COMMENT 数据来源标识, PRIMARY KEY (cp), UNIQUE KEY uk_char_variant (char_text, variant_type) ) ENGINEInnoDB COMMENT汉字码点与笔画基础表; -- 笔画明细表一个字多笔一对多 CREATE TABLE char_strokes ( cp INT UNSIGNED NOT NULL COMMENT 关联char_base.cp, stroke_seq TINYINT UNSIGNED NOT NULL COMMENT 第几笔从1开始, stroke_name VARCHAR(8) DEFAULT NULL COMMENT 笔形名称如横、竖、撇, PRIMARY KEY (cp, stroke_seq), CONSTRAINT fk_strokes_cp FOREIGN KEY (cp) REFERENCES char_base (cp) ) ENGINEInnoDB COMMENT汉字笔顺明细表; -- 简繁映射表一对多关系显式表达 CREATE TABLE char_simp_trad_map ( simp_cp INT UNSIGNED NOT NULL COMMENT 简体码点, trad_cp INT UNSIGNED NOT NULL COMMENT 繁体码点, map_type ENUM(一一对应,一简多繁,繁简共用) NOT NULL DEFAULT 一一对应, PRIMARY KEY (simp_cp, trad_cp), CONSTRAINT fk_map_simp FOREIGN KEY (simp_cp) REFERENCES char_base (cp), CONSTRAINT fk_map_trad FOREIGN KEY (trad_cp) REFERENCES char_base (cp) ) ENGINEInnoDB COMMENT简繁一对一/一对多映射表;这段SQL里有几个参数值得单独说明。数据库字符集用utf8mb4而不是utf8是因为MySQL里的utf8最多只支持3字节扩展B区以外的汉字会变成问号utf8mb4才覆盖完整Unicode。排序规则我选utf8mb4_unicode_ci它基于Unicode Collation Algorithm比general_ci更接近字符语义虽然性能略慢但汉字库的写入是一次性的查询性能远没到瓶颈。cp字段用INT UNSIGNED最大能存42亿Unicode目前码点总量约110万完全够用。hex_cp用CHAR(6)因为U10FFFF刚好6位如果后面想存小于0xFFFF的码点也不会有空字符串问题。外键这里不是摆设char_strokes和char_simp_trad_map都依赖char_base加上外键后删除主表数据时如果关联数据没清干净会直接报错这反而是好事免得你误删了字库还在那儿查半天。有人会问为什么不给unicode_category建索引。我的建议是建一个普通的B树索引因为后续判断标点符号时会按这个字段过滤。ALTER TABLE char_base ADD INDEX idx_unicode_category (unicode_category); 这一句可以放在导入数据之后再执行避免导入时索引频繁更新拖慢速度。3. 数据灌入MySQL从源文件到可查询表的完整操作3.1 先归一化源数据CSV、JSON、UnicodeData.txt都转成同一种行格式建完表就要面对现实手上拿到的数据往往不是为MySQL准备的。常见源有三种。第一种是公开的汉字笔画表通常是CSV列名类似「汉字,总笔画数,备注」但简繁体混在一起。第二种是Unicode联盟发布的UnicodeData.txt里面有码点、字符名、Unicode类别但它只涵盖字符属性不管笔画数。第三种是语言处理工具生成的JSON比如某个字库项目导出的记录包含简体、繁体、笔顺、笔画数等。我自己的习惯是先写一个小脚本把不同来源全部转成统一的CSV行格式固定为cp,hex_cp,char_text,unicode_category,stroke_count,variant_type,source。这一步看着简单实际上是最容易翻车的地方。比如CSV里汉字列可能带着BOM头第一行第一个字会变成类似「国」前面加零宽空格再比如逗号分隔时字符本身可能包含英文逗号必须用引号包裹。下面这段Python脚本可以完成原始CSV到目标格式的转换import csv import sys # 输入文件比如 raw_hanzi.csv列汉字,总笔画数,简繁标签 # 输出文件 target.csv列顺序符合char_base表 input_path raw_hanzi.csv output_path target.csv with open(input_path, encodingutf-8-sig) as rf, \ open(output_path, w, encodingutf-8, newline) as wf: reader csv.reader(rf) writer csv.writer(wf) writer.writerow([cp, hex_cp, char_text, unicode_category, stroke_count, variant_type, source]) for row in reader: if not row or len(row) 3: continue char_text row[0].strip() if not char_text: continue try: stroke_count int(row[1]) except ValueError: stroke_count 0 variant_type row[2].strip() if len(row) 2 and row[2].strip() else 通用 cp ord(char_text) hex_cp fU{cp:04X} unicode_category Lo # 先用默认值后续用UnicodeData.txt补全 writer.writerow([cp, hex_cp, char_text, unicode_category, stroke_count, variant_type, raw_csv])这里用utf-8-sig读源文件能自动去掉BOM用ord(char_text)拿到十进制码点再用格式化成U加四位十六进制。unicode_category先统一填Lo这个不严谨等导入后再用UnicodeData.txt批量更新。source字段记录数据来源方便以后追溯哪些字是从哪份文件来的真出问题不至于对着黑匣子猜。3.2 LOAD DATA INFILE导入参数、权限、失败重试归一化后的CSV可以直接用LOAD DATA导入比一条一条INSERT快几个数量级。我实测过五万字左右的数据逐条INSERT要几分钟LOAD DATA基本秒级。下面是导入脚本mysql --local-infile1 -u root -p hanzi_unicode -- 在MySQL客户端里执行 LOAD DATA LOCAL INFILE /path/to/target.csv INTO TABLE char_base CHARACTER SET utf8mb4 FIELDS TERMINATED BY , OPTIONALLY ENCLOSED BY LINES TERMINATED BY \n IGNORE 1 LINES (cp, hex_cp, char_text, unicode_category, stroke_count, variant_type, source);关键参数是LOCAL INFILE它让客户端把文件内容传给服务器。如果报错提示LOCAL INFILE被禁止需要先检查两个地方启动MySQL时有没有加--local-infile1以及全局变量local_infile是不是ON。执行SET GLOBAL local_infile ON;可以打开但只对之后的新连接生效。CHARACTER SET utf8mb4必须写否则客户端会把文件内容按系统默认字符集解析极可能把汉字读成乱码。OPTIONALLY ENCLOSED BY 是告诉解析器字段可以被双引号包着但不强制这样即使字符里有逗号只要在引号内就不会被错误拆列。这条语句执行完建议立即做一次校验SELECT COUNT(*), COUNT(DISTINCT cp) FROM char_base;如果两个数不一致说明有重复码点被忽略或者部分行导入失败。LOAD DATA遇到主键冲突默认是报错中断所以导入前最好先把目标表TRUNCATE保证是干净导入。如果要允许重复行覆盖可以在LOAD DATA后面加REPLACE关键字但我更倾向于先导入临时表再通过INSERT SELECT去重这样原始数据不会因为一次误操作就被破坏。3.3 简繁映射与Unicode类别的补全不要手动拼简繁映射和Unicode类别这两块数据最重要的原则是别手动维护。手动维护几百个字没问题一上规模就必然出错。正统做法是借助公开的简繁对照表和Unicode官方文件通过代码自动补齐。Unicode类别可以用官方UnicodeData.txt补全。这个文件的每一行以分号分隔第一个字段是十六进制码点第三个字段是类别。解析脚本如下# 解析UnicodeData.txt更新char_base.unicode_category import mysql.connector category_map {} with open(UnicodeData.txt, encodingutf-8) as f: for line in f: parts line.strip().split(;) if len(parts) 3: cp int(parts[0], 16) category parts[2] category_map[cp] category cnx mysql.connector.connect( host127.0.0.1, userroot, passwordyour_password, databasehanzi_unicode, charsetutf8mb4 ) cursor cnx.cursor() for cp, category in category_map.items(): cursor.execute( UPDATE char_base SET unicode_category %s WHERE cp %s, (category, cp) ) cnx.commit() cursor.close() cnx.close()这个脚本的逻辑很直白把官方文件解析成字典再一条条更新。五万个字的UPDATE可能在本地跑几十秒可以接受。将来如果不想逐条更新也可以用临时表先INSERT脱机文件内容再JOIN更新但那是性能优化现阶段不用着急。简繁映射我用类似的思路。写法上不外乎读一个简化字到繁体字的映射JSON然后往char_simp_trad_map插入。重点是map_type字段要区分一对一和一对多。判断方法很简单同一个simp_cp如果对应两个trad_cp那它就是「一简多繁」。但你不要只看一次数据因为简繁映射有普遍规则和异体字差异某些字在GBK和Big5体系里对照关系并不一致。我的建议是保留source字段把「来自标准简化字总表」和「来自民间字库」分开记录查询时优先取官方映射。这个库如果将来要用于搜索索引一对多的映射会直接影响召回率所以绝不能拍脑袋合并。4. 查询与应用层接法笔画排序、标点判断、程序集成4.1 按笔画数排序为什么ORDER BY stroke_count和ORDER BY char_text不一样很多人以为查到汉字表后ORDER BY char_text就能按笔画排这是中文搜索里最常见的错误认知之一。MySQL的字符集排序规则基于Unicode码点而码点排序是「先按部首再按笔画」的康熙字典序不是纯笔画数顺序。如果业务要的是「一画字在前、二画字在后」这种纯笔画排序唯一可靠的做法就是ORDER BY stroke_count。-- 按笔画数从少到多同笔画内按码点排序保持稳定 SELECT char_text, stroke_count, hex_cp FROM char_base WHERE variant_type IN (简, 繁) ORDER BY stroke_count ASC, cp ASC;这个查询的稳定点在最后那个cp ASC。同笔画数的字很多如果不加二级排序每次查询返回顺序可能因为执行计划变化而不同导致前端页面翻页时看到字的位置跳来跳去。加上cp后就固定了。但要注意同笔画数内按码点排不是按部首排序所以如果你要做「字典检索式」的笔画排序光有笔画数不够还需要携带部首或笔顺特征字段。真正要满足出版级的笔画序表里必须加一个sort_key字段例如把每个字的笔画序列转成「横1、竖2、撇3、点4、折5」的编码字符串。排序时按这个编码逐位比较。这个字段在导入阶段就要生成写完字库再回头补会十分痛苦。如果你还没这笔数据最稳妥的做法是先按stroke_count排至少能满足大多数识字场景。4.2 基于Unicode类别判断中英文标点一个可复用的SQL标题里的Unicode数据库不只是存汉字还要能用于判断标点。判断中英文标点这个需求热搜词里也经常出现。关键在于Unicode类别字段只能告诉你它是不是标点不能告诉你它是中文标点还是英文标点。比如中文逗号UFF0C的类别是Po英文逗号U002C的类别也是Po单看category字段两者完全一样。要通过MySQL判断得把码点范围也考虑进去。中英文标点区分主要在两个Unicode区块CJK符号和标点区块0x3000-0x303F以及全角形式区块0xFF00-0xFFEF。中文常用标点基本都落在这两个区块内。可用下面这条SQL-- 判断一个字符是否是中文标点 SELECT char_text, hex_cp, unicode_category, CASE WHEN cp BETWEEN 0x3000 AND 0x303F THEN 中文标点 WHEN cp BETWEEN 0xFF00 AND 0xFFEF THEN 中文标点全角形式 WHEN unicode_category LIKE P% THEN 英文标点 ELSE 非标点 END AS punct_type FROM char_base WHERE char_text OR char_text , OR char_text 。;这个CASE表达式的优先级很关键。先判断码点范围再判断Unicode类别这样全角逗号会被归为中文标点半角逗号落入LIKE P%分支被归为英文标点。实际项目里你可以把这段查询包成一个视图或者存储函数应用层只需要传一个字进去就能拿到标点类型。注意0xFF00到0xFFEF区间里并不全是标点它包含全角字母、全角数字但如果你已经限定unicode_category LIKE P%那么全角字母不会误入标点阵营。4.3 程序集成GBK转Unicode后再查MySQL的最小链路很多Windows上位机和老系统还在用GBK编码文本。LabVIEW里把GBK转成Unicode是常见操作热搜词里也频繁出现。核心思路是GBK字节流先进内存按GBK解码得到字符再用ord()拿到Unicode码点最后用码点查MySQL。这样可以避开数据库连接字符集和源文件编码的互相干扰。下面是一个最小可用的Python集成示例逻辑同样适用于其他语言import mysql.connector # 模拟从LabVIEW或文件中拿到的GBK字节流 gbk_bytes bV4C0 # 这是国的GBK编码 char_text gbk_bytes.decode(gbk) cp ord(char_text) cnx mysql.connector.connect( host127.0.0.1, databasehanzi_unicode, userroot, passwordyour_password, charsetutf8mb4 ) cursor cnx.cursor(dictionaryTrue) cursor.execute( SELECT char_text, stroke_count, hex_cp, unicode_category FROM char_base WHERE cp %s, (cp,) ) row cursor.fetchone() cursor.close() cnx.close() if row: print(row[char_text], row[stroke_count], row[hex_cp]) else: print(未找到, char_text)这里有两个容易被忽略的参数。第一个是mysql.connector.connect里的charsetutf8mb4它保证查询参数里的字符串以完整Unicode形式发送给服务器如果漏了GBK解码出来的字符在传输中可能被截断。第二个是SQL里用%s参数化占位而不是把cp直接拼进字符串这既避免SQL注入也避免码点被当作字符串比较时触发隐式转换。顺序很重要先把GBK字节decode成字符再取码点最后查库不要直接把GBK字节丢进数据库因为MySQL根本不知道那串字节是GBK还是别的编码。5. 避坑Unicode数据进MySQL后最常翻车的5个现场5.1 查询结果全是问号utf8与utf8mb4的坑现象导入时明明看到汉字正常重新打开客户端查询返回的却是「??」或者乱码。原因几乎都是连接字符集没对齐。MySQL的utf8实际是utf8mb3最多存3字节而很多扩展汉字需要4字节一旦客户端和表字符集没有统一成utf8mb4传输过程中字节就被替换成问号。解决建库建表时显式指定utf8mb4连接时也指定charsetutf8mb4。老项目里如果已经用了utf8赶紧执行ALTER TABLE char_base CONVERT TO CHARACTER SET utf8mb4然后重启连接。还有一个隐蔽问题是某些客户端工具默认用latin1连接即使表是utf8mb4也会乱码需要在连接参数里写死SET NAMES utf8mb4。5.2 排序结果永远不符合笔画COLLATE帮不了你现象执行ORDER BY char_text LIMIT 20出来的字完全不是从少画到多画。原因MySQL排序规则是按码点或拼音不是按笔画数。别指望COLLATE utf8mb4_unicode_ci能按笔画排这不属于Unicode默认排序算法的范围。解决不要用char_text排序用stroke_count排序需要出版级笔画序的必须建笔顺编码字段。这里有个替换思路如果你只是想让字按「常用字优先」排那应该维护一个frequency字段而不是在排序规则上折腾。5.3 简繁映射手动维护一简对多繁是常态现象查到「干」只映射到「幹」结果用户搜「干」时没召回「乾」。原因简繁并非一一对应任何手工维护的简繁表都会漏。解决在char_simp_trad_map里为同一个simp_cp允许插入多个trad_cpmap_type标记为「一简多繁」。查询时INNER JOIN映射表会得到多行这就是预期行为。真正的坑在于很多现成映射数据默认只保留第一个映射导入时要去重策略改成「保留全部」否则后映射的行会因为主键冲突被跳过。5.4 LOAD DATA导入到一半报错idb文件膨胀现象LOAD DATA执行到中间遇到主键冲突或编码错误事务回滚但表空间文件已经变大磁盘占用明显上涨。原因InnoDB在导入时为保证一致性会写undo日志中断后不立即回收空间。解决导入前TRUNCATE表导入时先建一个和最终表结构相同的临时表导入成功后再INSERT SELECT到正式表。日常可以用OPTIMIZE TABLE回收空间但不要在业务高峰期执行。如果你要用数据库同步工具把这份数据迁移到另一台机器务必确认工具对VARCHAR(4)字段的字符集转换是UTF-8到UTF-8很多同步软件默认假设源库是latin1同步完汉字就变成问号。5.5 判断中英文标点只查category翻车现象用unicode_category LIKE P%判断标点结果把中文句号、英文句号、中文逗号、英文逗号全混在一起。原因Unicode类别只区分标点、字母、数字这种大类不区分中英文。解决按4.2的SQL把码点范围判断放在前面。这里容易再踩一个小坑全角逗号UFF0C和中文顿号U3001虽然都是中文标点但不在同一个Unicode块所以判断中文标点时要同时覆盖0x3000-0x303F和0xFF00-0xFFEF两个区间而不是只写一个BETWEEN。6. 把方案落地验证数据完整性、扩展笔顺与封装视图6.1 用官方码点表做交叉验证数据灌完后先做一次全量校验把char_base里的码点和Unicode官方码点表比对看有没有不存在的码点有没有漏掉的常用汉字。常见做法是导出一份码点清单然后用Python的set做差集。校验SQL很简单SELECT COUNT(*) AS total_chars, COUNT(DISTINCT hex_cp) AS unique_cps FROM char_base;如果total_chars和unique_cps不一致说明有码点重复通常是同一字形出现在多个Unicode区块里。对于字库型项目这种重复可以接受但你应该在source字段里标注清楚避免以后误以为数据脏。6.2 扩展笔顺字段与按笔顺检索如果现有数据只有笔画数下一步最值得做的是补笔顺。在char_strokes表里已经有stroke_seq和stroke_name你可以按笔画名称的首字母生成一个编码字段比如「横H、竖S、撇P、点D、折Z」。按笔顺检索时把输入字转成编码序列再用前缀匹配去查候选字。这个功能对书法教学和输入法开发很有用。6.3 封装视图与存储过程后的日常使用把4.2里的标点判断SQL封装成视图把4.1里的笔画排序封装成存储过程业务层就不用反复写复杂的CASE表达式。视图只读适合给报表用存储过程适合高频查询。我个人习惯是把基础表保持干净所有业务逻辑都放视图和存储过程这样换数据源时只需要改底层表不碰应用。6.4 落地的最后一句建议这套数据库值不值得自己搭要看你的核心需求是不是「持续维护汉字数据」。如果只是想要一张能查笔画数的表买现成的数据文件更划算但如果你要打通简繁、笔顺、Unicode类别这三者的关联并让MySQL成为唯一数据源那就按上面的表结构一步步做。自己动手的唯一后悔药是没在一开始就用码点做主键。我见过太多人用汉字当主键最后被同一个字不同码点折磨到重来。先把地基打对后面加字段、加数据都是顺手的事希望帮到你。本文还有配套的精品资源点击获取 汉字笔画与Unicode数据库MySQL实现：简繁映射、笔画排序和避坑指南
简介这份MySQL数据库将简繁汉字的笔画数、笔顺、Unicode编码与GB编码整合为结构化数据面向汉字输入法开发、汉字教学、书法研究以及姓名或诗词笔画计算等场景。资源包仅304KB共1个SQL脚本文件导入MySQL后即可生成汉字笔画信息表支持按笔画数、笔顺等字段进行查询、排序与统计分析例如快速筛选笔画最多的字或按书写顺序排列。已有980人学习下载。使用者无需自行爬取或整理汉字属性可直接获得标准编码与书写顺序数据便于快速搭建原型、开展字形对照研究也可用于课程示例与演示帮助学生理解笔画规则。无论是构建教学课件、输入法词库还是开展字形统计这些字段都能直接复用省去重复整理工作。整体来看该数据库体积小巧但字段完整能有效缩短汉字类应用的前期数据准备周期适合作为汉字信息化项目的基础数据集。1. 汉字笔画及Unicode数据库简繁MySQL这套数据到底解决什么问题做识字类App、校对系统或者排版引擎的人大概率都遇到过这三件事一个字明明认识但就是不确定它几画一个简体字对应的繁体字在数据库里查不到Unicode码点拿到了却不知道怎么和笔画数一起存进MySQL。汉字笔画及Unicode数据库简繁MySQL简单说就是把每一个汉字的码点、笔画数、简繁属性、Unicode类别整理成可查询的表让排序、筛选和程序对接都有标准答案。它解决的是「汉字数据进MySQL之后怎么查、怎么排、怎么不丢字」的问题适合正在做字库工具、输入法词库、中文教学软件以及被字符集折腾过的人。这个方案不是要你从零造字库而是把已经存在的公开数据整理成自己能维护的MySQL库。2. 先拆分数据模型笔画、码点、简繁为什么要分开建表2.1 不要迷信「一个汉字一行」三个现实反例很多人第一反应是建一张表字段叫「汉字、笔画数、Unicode码、简繁标识」然后往里灌数据。这种设计自己写几个查询没问题一旦碰上真实中文文本立刻会发现三个反例。第一个反例是同一个汉字有多个码点。「里」和「裡」是简繁关系但「里」本身在Unicode里还有一个兼容汉字符号「户」和「戶」更典型简体和繁体在Unicode中是不同的码点可字形几乎一样。如果你用汉字本身做主键这一行插进去另一行就撞了。第二个反例是笔画数和码点没有因果关系。Unicode是按部首和笔画排序编码的但「一」的码点小于「丁」「丁」的码点小于「七」码点顺序和笔画数排序并不完全一致只存一个字段根本没法做稳定的笔画排序。第三个反例是简繁不是一对一。「干」的繁体可能是「幹」也可能是「乾」一个简体字对应多个繁体字是常态如果表结构里只放一个「繁体」字段数据必然丢。所以我的结论是不要试图用一张宽表解决所有问题。应该把「字符本身」「笔画明细」「简繁映射」「Unicode类别」拆开用码点作为稳定关联键。这样后续加数据源、加笔顺、加异体字都不用改主表。2.2 码点当主键汉字只当业务属性为什么不直接拿汉字做主键因为汉字是给人和业务看的码点是给计算机看的。一个程序从外部拿到一段文本要查笔画最可靠的做法是拿到字符后调用ord()得到整数码点然后用这个整数去查MySQL而不是把字符拼进SQL字符串里等数据库去解析。字符在传输过程中受客户端字符集影响可能被转成错误字节码点是整数不会因为连接字符集变化而改变。我一般会把码点字段设计成INT UNSIGNED同时保留一个CHAR(6)的十六进制形式类似U4E2D方便人读和调试。汉字本身用VARCHAR(4)就够因为Unicode里汉字在基本平面最多占4个字节utf8mb4但码点可能落到扩展区那个字符用VARCHAR(4)存没问题只是排序和比较仍然依赖码点字段。主键用码点业务键用「汉字变体类型」的组合唯一索引这样同一个字形出现在不同分区时也不会互相覆盖。简繁映射单独建一张表不塞进字符主表。原因很简单一个简体字可能映射到多个繁体字一对多关系在关系型数据库里就该用子表表达。映射表里再加一个map_type字段标记是「一一对应」还是「一简多繁」以后做全文检索或者词向量对齐时就知道该按哪种规则展开。2.3 建表SQLutf8mb4、InnoDB、外键与索引怎么选建库建表这一步是后面所有操作的地基。先上完整SQL我标注了每一处的选择理由。-- 建库必须用utf8mb4而不是utf8 CREATE DATABASE hanzi_unicode DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; USE hanzi_unicode; -- 字符主表一个码点一行 CREATE TABLE char_base ( cp INT UNSIGNED NOT NULL COMMENT Unicode码点十进制, hex_cp CHAR(6) NOT NULL COMMENT UXXXX十六进制表示, char_text VARCHAR(4) NOT NULL COMMENT 汉字字符, unicode_category CHAR(2) NOT NULL DEFAULT Lo COMMENT Unicode类别如Lo汉字Po标点, stroke_count TINYINT UNSIGNED NOT NULL COMMENT 总笔画数, variant_type ENUM(简,繁,异体,通用) NOT NULL DEFAULT 通用 COMMENT 简繁属性, source VARCHAR(32) DEFAULT NULL COMMENT 数据来源标识, PRIMARY KEY (cp), UNIQUE KEY uk_char_variant (char_text, variant_type) ) ENGINEInnoDB COMMENT汉字码点与笔画基础表; -- 笔画明细表一个字多笔一对多 CREATE TABLE char_strokes ( cp INT UNSIGNED NOT NULL COMMENT 关联char_base.cp, stroke_seq TINYINT UNSIGNED NOT NULL COMMENT 第几笔从1开始, stroke_name VARCHAR(8) DEFAULT NULL COMMENT 笔形名称如横、竖、撇, PRIMARY KEY (cp, stroke_seq), CONSTRAINT fk_strokes_cp FOREIGN KEY (cp) REFERENCES char_base (cp) ) ENGINEInnoDB COMMENT汉字笔顺明细表; -- 简繁映射表一对多关系显式表达 CREATE TABLE char_simp_trad_map ( simp_cp INT UNSIGNED NOT NULL COMMENT 简体码点, trad_cp INT UNSIGNED NOT NULL COMMENT 繁体码点, map_type ENUM(一一对应,一简多繁,繁简共用) NOT NULL DEFAULT 一一对应, PRIMARY KEY (simp_cp, trad_cp), CONSTRAINT fk_map_simp FOREIGN KEY (simp_cp) REFERENCES char_base (cp), CONSTRAINT fk_map_trad FOREIGN KEY (trad_cp) REFERENCES char_base (cp) ) ENGINEInnoDB COMMENT简繁一对一/一对多映射表;这段SQL里有几个参数值得单独说明。数据库字符集用utf8mb4而不是utf8是因为MySQL里的utf8最多只支持3字节扩展B区以外的汉字会变成问号utf8mb4才覆盖完整Unicode。排序规则我选utf8mb4_unicode_ci它基于Unicode Collation Algorithm比general_ci更接近字符语义虽然性能略慢但汉字库的写入是一次性的查询性能远没到瓶颈。cp字段用INT UNSIGNED最大能存42亿Unicode目前码点总量约110万完全够用。hex_cp用CHAR(6)因为U10FFFF刚好6位如果后面想存小于0xFFFF的码点也不会有空字符串问题。外键这里不是摆设char_strokes和char_simp_trad_map都依赖char_base加上外键后删除主表数据时如果关联数据没清干净会直接报错这反而是好事免得你误删了字库还在那儿查半天。有人会问为什么不给unicode_category建索引。我的建议是建一个普通的B树索引因为后续判断标点符号时会按这个字段过滤。ALTER TABLE char_base ADD INDEX idx_unicode_category (unicode_category); 这一句可以放在导入数据之后再执行避免导入时索引频繁更新拖慢速度。3. 数据灌入MySQL从源文件到可查询表的完整操作3.1 先归一化源数据CSV、JSON、UnicodeData.txt都转成同一种行格式建完表就要面对现实手上拿到的数据往往不是为MySQL准备的。常见源有三种。第一种是公开的汉字笔画表通常是CSV列名类似「汉字,总笔画数,备注」但简繁体混在一起。第二种是Unicode联盟发布的UnicodeData.txt里面有码点、字符名、Unicode类别但它只涵盖字符属性不管笔画数。第三种是语言处理工具生成的JSON比如某个字库项目导出的记录包含简体、繁体、笔顺、笔画数等。我自己的习惯是先写一个小脚本把不同来源全部转成统一的CSV行格式固定为cp,hex_cp,char_text,unicode_category,stroke_count,variant_type,source。这一步看着简单实际上是最容易翻车的地方。比如CSV里汉字列可能带着BOM头第一行第一个字会变成类似「国」前面加零宽空格再比如逗号分隔时字符本身可能包含英文逗号必须用引号包裹。下面这段Python脚本可以完成原始CSV到目标格式的转换import csv import sys # 输入文件比如 raw_hanzi.csv列汉字,总笔画数,简繁标签 # 输出文件 target.csv列顺序符合char_base表 input_path raw_hanzi.csv output_path target.csv with open(input_path, encodingutf-8-sig) as rf, \ open(output_path, w, encodingutf-8, newline) as wf: reader csv.reader(rf) writer csv.writer(wf) writer.writerow([cp, hex_cp, char_text, unicode_category, stroke_count, variant_type, source]) for row in reader: if not row or len(row) 3: continue char_text row[0].strip() if not char_text: continue try: stroke_count int(row[1]) except ValueError: stroke_count 0 variant_type row[2].strip() if len(row) 2 and row[2].strip() else 通用 cp ord(char_text) hex_cp fU{cp:04X} unicode_category Lo # 先用默认值后续用UnicodeData.txt补全 writer.writerow([cp, hex_cp, char_text, unicode_category, stroke_count, variant_type, raw_csv])这里用utf-8-sig读源文件能自动去掉BOM用ord(char_text)拿到十进制码点再用格式化成U加四位十六进制。unicode_category先统一填Lo这个不严谨等导入后再用UnicodeData.txt批量更新。source字段记录数据来源方便以后追溯哪些字是从哪份文件来的真出问题不至于对着黑匣子猜。3.2 LOAD DATA INFILE导入参数、权限、失败重试归一化后的CSV可以直接用LOAD DATA导入比一条一条INSERT快几个数量级。我实测过五万字左右的数据逐条INSERT要几分钟LOAD DATA基本秒级。下面是导入脚本mysql --local-infile1 -u root -p hanzi_unicode -- 在MySQL客户端里执行 LOAD DATA LOCAL INFILE /path/to/target.csv INTO TABLE char_base CHARACTER SET utf8mb4 FIELDS TERMINATED BY , OPTIONALLY ENCLOSED BY LINES TERMINATED BY \n IGNORE 1 LINES (cp, hex_cp, char_text, unicode_category, stroke_count, variant_type, source);关键参数是LOCAL INFILE它让客户端把文件内容传给服务器。如果报错提示LOCAL INFILE被禁止需要先检查两个地方启动MySQL时有没有加--local-infile1以及全局变量local_infile是不是ON。执行SET GLOBAL local_infile ON;可以打开但只对之后的新连接生效。CHARACTER SET utf8mb4必须写否则客户端会把文件内容按系统默认字符集解析极可能把汉字读成乱码。OPTIONALLY ENCLOSED BY 是告诉解析器字段可以被双引号包着但不强制这样即使字符里有逗号只要在引号内就不会被错误拆列。这条语句执行完建议立即做一次校验SELECT COUNT(*), COUNT(DISTINCT cp) FROM char_base;如果两个数不一致说明有重复码点被忽略或者部分行导入失败。LOAD DATA遇到主键冲突默认是报错中断所以导入前最好先把目标表TRUNCATE保证是干净导入。如果要允许重复行覆盖可以在LOAD DATA后面加REPLACE关键字但我更倾向于先导入临时表再通过INSERT SELECT去重这样原始数据不会因为一次误操作就被破坏。3.3 简繁映射与Unicode类别的补全不要手动拼简繁映射和Unicode类别这两块数据最重要的原则是别手动维护。手动维护几百个字没问题一上规模就必然出错。正统做法是借助公开的简繁对照表和Unicode官方文件通过代码自动补齐。Unicode类别可以用官方UnicodeData.txt补全。这个文件的每一行以分号分隔第一个字段是十六进制码点第三个字段是类别。解析脚本如下# 解析UnicodeData.txt更新char_base.unicode_category import mysql.connector category_map {} with open(UnicodeData.txt, encodingutf-8) as f: for line in f: parts line.strip().split(;) if len(parts) 3: cp int(parts[0], 16) category parts[2] category_map[cp] category cnx mysql.connector.connect( host127.0.0.1, userroot, passwordyour_password, databasehanzi_unicode, charsetutf8mb4 ) cursor cnx.cursor() for cp, category in category_map.items(): cursor.execute( UPDATE char_base SET unicode_category %s WHERE cp %s, (category, cp) ) cnx.commit() cursor.close() cnx.close()这个脚本的逻辑很直白把官方文件解析成字典再一条条更新。五万个字的UPDATE可能在本地跑几十秒可以接受。将来如果不想逐条更新也可以用临时表先INSERT脱机文件内容再JOIN更新但那是性能优化现阶段不用着急。简繁映射我用类似的思路。写法上不外乎读一个简化字到繁体字的映射JSON然后往char_simp_trad_map插入。重点是map_type字段要区分一对一和一对多。判断方法很简单同一个simp_cp如果对应两个trad_cp那它就是「一简多繁」。但你不要只看一次数据因为简繁映射有普遍规则和异体字差异某些字在GBK和Big5体系里对照关系并不一致。我的建议是保留source字段把「来自标准简化字总表」和「来自民间字库」分开记录查询时优先取官方映射。这个库如果将来要用于搜索索引一对多的映射会直接影响召回率所以绝不能拍脑袋合并。4. 查询与应用层接法笔画排序、标点判断、程序集成4.1 按笔画数排序为什么ORDER BY stroke_count和ORDER BY char_text不一样很多人以为查到汉字表后ORDER BY char_text就能按笔画排这是中文搜索里最常见的错误认知之一。MySQL的字符集排序规则基于Unicode码点而码点排序是「先按部首再按笔画」的康熙字典序不是纯笔画数顺序。如果业务要的是「一画字在前、二画字在后」这种纯笔画排序唯一可靠的做法就是ORDER BY stroke_count。-- 按笔画数从少到多同笔画内按码点排序保持稳定 SELECT char_text, stroke_count, hex_cp FROM char_base WHERE variant_type IN (简, 繁) ORDER BY stroke_count ASC, cp ASC;这个查询的稳定点在最后那个cp ASC。同笔画数的字很多如果不加二级排序每次查询返回顺序可能因为执行计划变化而不同导致前端页面翻页时看到字的位置跳来跳去。加上cp后就固定了。但要注意同笔画数内按码点排不是按部首排序所以如果你要做「字典检索式」的笔画排序光有笔画数不够还需要携带部首或笔顺特征字段。真正要满足出版级的笔画序表里必须加一个sort_key字段例如把每个字的笔画序列转成「横1、竖2、撇3、点4、折5」的编码字符串。排序时按这个编码逐位比较。这个字段在导入阶段就要生成写完字库再回头补会十分痛苦。如果你还没这笔数据最稳妥的做法是先按stroke_count排至少能满足大多数识字场景。4.2 基于Unicode类别判断中英文标点一个可复用的SQL标题里的Unicode数据库不只是存汉字还要能用于判断标点。判断中英文标点这个需求热搜词里也经常出现。关键在于Unicode类别字段只能告诉你它是不是标点不能告诉你它是中文标点还是英文标点。比如中文逗号UFF0C的类别是Po英文逗号U002C的类别也是Po单看category字段两者完全一样。要通过MySQL判断得把码点范围也考虑进去。中英文标点区分主要在两个Unicode区块CJK符号和标点区块0x3000-0x303F以及全角形式区块0xFF00-0xFFEF。中文常用标点基本都落在这两个区块内。可用下面这条SQL-- 判断一个字符是否是中文标点 SELECT char_text, hex_cp, unicode_category, CASE WHEN cp BETWEEN 0x3000 AND 0x303F THEN 中文标点 WHEN cp BETWEEN 0xFF00 AND 0xFFEF THEN 中文标点全角形式 WHEN unicode_category LIKE P% THEN 英文标点 ELSE 非标点 END AS punct_type FROM char_base WHERE char_text OR char_text , OR char_text 。;这个CASE表达式的优先级很关键。先判断码点范围再判断Unicode类别这样全角逗号会被归为中文标点半角逗号落入LIKE P%分支被归为英文标点。实际项目里你可以把这段查询包成一个视图或者存储函数应用层只需要传一个字进去就能拿到标点类型。注意0xFF00到0xFFEF区间里并不全是标点它包含全角字母、全角数字但如果你已经限定unicode_category LIKE P%那么全角字母不会误入标点阵营。4.3 程序集成GBK转Unicode后再查MySQL的最小链路很多Windows上位机和老系统还在用GBK编码文本。LabVIEW里把GBK转成Unicode是常见操作热搜词里也频繁出现。核心思路是GBK字节流先进内存按GBK解码得到字符再用ord()拿到Unicode码点最后用码点查MySQL。这样可以避开数据库连接字符集和源文件编码的互相干扰。下面是一个最小可用的Python集成示例逻辑同样适用于其他语言import mysql.connector # 模拟从LabVIEW或文件中拿到的GBK字节流 gbk_bytes bV4C0 # 这是国的GBK编码 char_text gbk_bytes.decode(gbk) cp ord(char_text) cnx mysql.connector.connect( host127.0.0.1, databasehanzi_unicode, userroot, passwordyour_password, charsetutf8mb4 ) cursor cnx.cursor(dictionaryTrue) cursor.execute( SELECT char_text, stroke_count, hex_cp, unicode_category FROM char_base WHERE cp %s, (cp,) ) row cursor.fetchone() cursor.close() cnx.close() if row: print(row[char_text], row[stroke_count], row[hex_cp]) else: print(未找到, char_text)这里有两个容易被忽略的参数。第一个是mysql.connector.connect里的charsetutf8mb4它保证查询参数里的字符串以完整Unicode形式发送给服务器如果漏了GBK解码出来的字符在传输中可能被截断。第二个是SQL里用%s参数化占位而不是把cp直接拼进字符串这既避免SQL注入也避免码点被当作字符串比较时触发隐式转换。顺序很重要先把GBK字节decode成字符再取码点最后查库不要直接把GBK字节丢进数据库因为MySQL根本不知道那串字节是GBK还是别的编码。5. 避坑Unicode数据进MySQL后最常翻车的5个现场5.1 查询结果全是问号utf8与utf8mb4的坑现象导入时明明看到汉字正常重新打开客户端查询返回的却是「??」或者乱码。原因几乎都是连接字符集没对齐。MySQL的utf8实际是utf8mb3最多存3字节而很多扩展汉字需要4字节一旦客户端和表字符集没有统一成utf8mb4传输过程中字节就被替换成问号。解决建库建表时显式指定utf8mb4连接时也指定charsetutf8mb4。老项目里如果已经用了utf8赶紧执行ALTER TABLE char_base CONVERT TO CHARACTER SET utf8mb4然后重启连接。还有一个隐蔽问题是某些客户端工具默认用latin1连接即使表是utf8mb4也会乱码需要在连接参数里写死SET NAMES utf8mb4。5.2 排序结果永远不符合笔画COLLATE帮不了你现象执行ORDER BY char_text LIMIT 20出来的字完全不是从少画到多画。原因MySQL排序规则是按码点或拼音不是按笔画数。别指望COLLATE utf8mb4_unicode_ci能按笔画排这不属于Unicode默认排序算法的范围。解决不要用char_text排序用stroke_count排序需要出版级笔画序的必须建笔顺编码字段。这里有个替换思路如果你只是想让字按「常用字优先」排那应该维护一个frequency字段而不是在排序规则上折腾。5.3 简繁映射手动维护一简对多繁是常态现象查到「干」只映射到「幹」结果用户搜「干」时没召回「乾」。原因简繁并非一一对应任何手工维护的简繁表都会漏。解决在char_simp_trad_map里为同一个simp_cp允许插入多个trad_cpmap_type标记为「一简多繁」。查询时INNER JOIN映射表会得到多行这就是预期行为。真正的坑在于很多现成映射数据默认只保留第一个映射导入时要去重策略改成「保留全部」否则后映射的行会因为主键冲突被跳过。5.4 LOAD DATA导入到一半报错idb文件膨胀现象LOAD DATA执行到中间遇到主键冲突或编码错误事务回滚但表空间文件已经变大磁盘占用明显上涨。原因InnoDB在导入时为保证一致性会写undo日志中断后不立即回收空间。解决导入前TRUNCATE表导入时先建一个和最终表结构相同的临时表导入成功后再INSERT SELECT到正式表。日常可以用OPTIMIZE TABLE回收空间但不要在业务高峰期执行。如果你要用数据库同步工具把这份数据迁移到另一台机器务必确认工具对VARCHAR(4)字段的字符集转换是UTF-8到UTF-8很多同步软件默认假设源库是latin1同步完汉字就变成问号。5.5 判断中英文标点只查category翻车现象用unicode_category LIKE P%判断标点结果把中文句号、英文句号、中文逗号、英文逗号全混在一起。原因Unicode类别只区分标点、字母、数字这种大类不区分中英文。解决按4.2的SQL把码点范围判断放在前面。这里容易再踩一个小坑全角逗号UFF0C和中文顿号U3001虽然都是中文标点但不在同一个Unicode块所以判断中文标点时要同时覆盖0x3000-0x303F和0xFF00-0xFFEF两个区间而不是只写一个BETWEEN。6. 把方案落地验证数据完整性、扩展笔顺与封装视图6.1 用官方码点表做交叉验证数据灌完后先做一次全量校验把char_base里的码点和Unicode官方码点表比对看有没有不存在的码点有没有漏掉的常用汉字。常见做法是导出一份码点清单然后用Python的set做差集。校验SQL很简单SELECT COUNT(*) AS total_chars, COUNT(DISTINCT hex_cp) AS unique_cps FROM char_base;如果total_chars和unique_cps不一致说明有码点重复通常是同一字形出现在多个Unicode区块里。对于字库型项目这种重复可以接受但你应该在source字段里标注清楚避免以后误以为数据脏。6.2 扩展笔顺字段与按笔顺检索如果现有数据只有笔画数下一步最值得做的是补笔顺。在char_strokes表里已经有stroke_seq和stroke_name你可以按笔画名称的首字母生成一个编码字段比如「横H、竖S、撇P、点D、折Z」。按笔顺检索时把输入字转成编码序列再用前缀匹配去查候选字。这个功能对书法教学和输入法开发很有用。6.3 封装视图与存储过程后的日常使用把4.2里的标点判断SQL封装成视图把4.1里的笔画排序封装成存储过程业务层就不用反复写复杂的CASE表达式。视图只读适合给报表用存储过程适合高频查询。我个人习惯是把基础表保持干净所有业务逻辑都放视图和存储过程这样换数据源时只需要改底层表不碰应用。6.4 落地的最后一句建议这套数据库值不值得自己搭要看你的核心需求是不是「持续维护汉字数据」。如果只是想要一张能查笔画数的表买现成的数据文件更划算但如果你要打通简繁、笔顺、Unicode类别这三者的关联并让MySQL成为唯一数据源那就按上面的表结构一步步做。自己动手的唯一后悔药是没在一开始就用码点做主键。我见过太多人用汉字当主键最后被同一个字不同码点折磨到重来。先把地基打对后面加字段、加数据都是顺手的事希望帮到你。本文还有配套的精品资源点击获取