简介：这是一款面向嵌入式开发、单片机及点阵显示应用场景的汉字字模生成工具，可解决LED大屏、LCD液晶屏开发中手工取模费时、易错的问题。它支持1024×1024以内任意规格点阵，兼容Windows全部字体，能灵活调整汉字大小与位置，既支持单字生成，也支持按汉语拼音排序的海量汉字批量生成。输出侧提供横扫、纵扫、Z扫描等多种扫描方式，支持4至32bit数据分组、字模取反、字节位倒置，并可自动生成C语言数组或汇编DB表格式，配合图片Logo点阵、GB2312/GBK字符集导入和繁简转换，可直接产出DAT、BIN二进制字库及索引文件，适合制作精减字库以节约ROM空间。同时集成串口通讯与汉字自动提取功能，便于将字模数据发送到存储设备或清洗非汉字字符。资源为绿色破解版，RAR压缩包大小约701KB，已有943人浏览学习，适合需要快速搭建点阵显示字库的软硬件开发者。
1. 汉字字模点阵批量生成工具：一套配置，几百个常用字一次出库
凡是做过LED点阵屏、OLED或ST7789这类小屏驱动的开发者，大概率都有过一段"人肉取模"的日子：把字放大、网格铺开、手动数格子点选，一个16x16的字模点下来，眼睛麻了还得再核对一遍。汉字字模点阵数据批量生成工具_suki_v5.0这套资源，就是把这步彻底流程化——你提供一份TXT字表，它按指定的字体、点阵尺寸、取模方向、字节排列方式，把几百个汉字一次性落成C语言数组或BIN文件，直接对接单片机驱动并口或SPI接口。适合做字库烧录、菜单界面、多语言显示模块，以及任何需要把汉字变成点阵数据的嵌入式场景。
2. 汉字点阵基础与取模方向：不同硬件，字模数据完全不一样
2.1 点阵尺寸与字库关系：16x16、24x24、32x32怎么选
点阵尺寸直接影响显示效果和存储开销。16x16字模一个字符占32字节，显示小号汉字够用，但笔画多的字（比如"霾""懿"）容易糊成一团；24x24字模一个字符占72字节，横竖都有两三根扫描线过渡，是目前菜单界面和仪表显示的主力；32x32以上基本能还原出印刷字体的笔锋细节，适合大屏广告机或高分辨率彩色屏的汉字层。
选尺寸不只是拍脑袋，还得看你的屏幕物理分辨率。比如一块128x64的OLED屏，如果想一行显示8个汉字，屏幕宽度只有128像素，16x16字模一行正好放下8个字，带个2像素间距就溢出。同样的屏，用24x24字模一行最多堆5个字，排版逻辑完全不同。我在项目里的一般做法是：先确认单屏要显示多少个汉字、留不留滚动余量，再倒推字模尺寸。不是所有场景都追求大字号，字模越密集，点阵数据量越大，MCU的Flash写入时间和运行时读取压力都会跟着涨。
字库和点阵尺寸绑定以后，换字号就等于换一套字模，这点和PC上用TrueType字体自由缩放的逻辑就是两码事。工具里每个字号配置是一套独立的参数组，生成文件按字号目录分开落盘，避免混用。我第一次用的时候图省事，把16x16和32x32的字模混在同一个BIN文件里，结果寻址全乱，显示出来的字东一块西一块，后来才老老实实按尺寸分目录管理。
2.2 取模方向的四种常见方式与字节排列规律
取模方向是这工具里最值得花十分钟确认的参数，没有之一。同一个"字"字，按逐行正向和按逐列正向取出来的数据完全不同，直接烧进屏幕里就是镜像或碎片错位。硬件驱动里常见的取模方式有四种：逐行正向、逐行逆向、逐列正向、逐列逆向。逐行正向按从左到右、从上到下的顺序读每一行像素，每8个像素打包成一个字节；逐列正向则先扫最左边一列，从上到下把8个像素打包，再去扫第二列。如果你的屏幕控制器是SSD1306，它的显存写入逻辑是按列地址增量刷新的，用逐列方式取模，DMA发送时数据直接对应显存地址，省去转置。
字节排列的另一个维度是高位在前还是低位在前。逐行方式下，一行16个像素拆成两个字节，MSB在前表示左边第一个像素落在字节的最高位bit7。绝大多数驱动库和取模软件默认MSB在前，但总有些屏厂商的例程是LSB在前，两者错位的结果是每个字节内部的像素左右翻转，字符看起来像照镜子。
建议拿到工具后先做一个最小验证：生成一个"0"或"田"字的16x16字模，打开BIN文件对比首字节，再对照屏幕实际显示效果确认取模方式和实际驱动匹配。这个验证步骤值得写进项目流程里，能省掉后面整屏乱码时的全部排查时间。
2.3 字模数据在文件里的排列与寻址机制
字模批量生成出来的数据有两种常见组合方式：一是顺序排列型，所有字排成一整个大数组，每个字固定占N字节，程序通过"字符编码 - ASCII码或GB2312/UTF-8偏移"计算索引；二是索引表+数据区型，每个字有一个地址表项，指向它在数据区里的偏移。小字库、固定字符集场景用顺序排列就够了，寻址就是一次减法加一次乘法。动态增删字的场景则更适合索引表结构，后续加字不需要重排所有数据。
这工具里可以配置生成索引表，输出一个const uint16_t index_table[]和一个const uint8_t font_data[]。我一般建议即使现在只做一个固定菜单，也把索引表带上，因为代码里按索引访问比算偏移直观，而且后续增量加字的时候，索引表直接复用，不用回头重构代码。
3. 批量生成实战：从字体文件到C语言数组的完整流程
3.1 字表准备与去重：TXT字表直接决定生成质量
工具的字表默认读UTF-8编码的TXT文件，每行放汉字、字母或符号，也可以一行多个字符，工具会按字符粒度切分。最容易翻车的是重复字和非法字符混入。我的习惯是写一个两行Python脚本先洗一次字表，去重、剔除换行符之外的所有空白字符、过滤掉超出字库范围的生僻字。注意这里不是限制你使用生僻字，而是告诉你字表里的字符来源如果是网页复制，经常夹带全角空格、零宽空格，这些不可见字符放进字表，工具的解析结果会莫名跳过一个字或生成一个空字模。
with open('chars_raw.txt', 'r', encoding='utf-8') as f: text = f.read() chars = sorted(set(text.replace('\n', '').replace('\r', '').replace(' ', '').replace('\u3000', ''))) with open('chars_clean.txt', 'w', encoding='utf-8') as f: f.write(''.join(chars))这段脚本的逻辑是逐行读取原始字表，把文本里的回车、换行、半角空格、全角空格全部替换为空，然后用set去重，最后排序输出。排序是为了让生成结果可预期，方便和已有字库做diff。参数说明里有一处值得注意：set去重后顺序会被打乱，用sorted重新排一遍才能保证每次生成的文件顺序一致，尤其是当你要用同一份字表生成多个尺寸字模时，顺序不一致会导致字模和字符的对应关系错位。
3.2 字体参数配置：字号、DPI、抗锯齿对点阵的影响
工具支持指定系统里的TTF字体文件作为字形来源，字号直接填目标像素高度。比如生成24x24字模，字号参数建议填24，但这里有个细节：某些TTF字体在24px时实际渲染出的字形上下会留白，导致点阵字看起来偏小或偏上。一般做法是把字号填到26甚至28，然后通过字模的水平偏移和垂直偏移参数把字形精确压进24x24的网格里。这套工具的字体参数面板里有一组X偏移和Y偏移，正负值分别控制字形整体左右上下移动，微调空间大概在0到4像素之间就够用。
抗锯齿选项默认关闭。对点阵屏来说，抗锯齿本身没有意义——1-bit像素只存在亮和灭，抗锯齿产生的灰度过渡在二值化时只会造成笔画边缘更多的孤立噪点。如果你看到生成的字模笔画边缘有小碎点，先别怀疑工具，检查一下是不是开了灰度或抗锯齿导出。关闭抗锯齿，用二值化输出，出来的字模横平竖直，在LED屏上显示最干净。
DPI参数在嵌入式字模场景通常不参与实际计算，点阵字模只需要像素逻辑尺寸。这个参数只有在从矢量字体渲染到位图、位图再转点阵的链路里影响像素密度换算，工具一般默认96。你不必改动它，除非你发现生成的字比设定尺寸大一圈或小一圈，那时候再回来检查DPI是否被意外修改。
3.3 输出格式与批量生成：C语言数组和BIN文件双通道
输出格式设置是本工具的核心门槛。常见的嵌入式显示项目需要两种产物：直接嵌入固件源码里的C数组，和烧写到外置Flash里的BIN字库文件。工具两个都能出，而且支持同一套字模同时导出两套文件。
// font_24.c - 片段 const uint8_t font_24_data[] = { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x3E, 0x00, 0x20, 0x00, 0x20, 0x00, 0x20, 0x00, 0x3E, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // ... 24x24字模数据，共72字节 }; const uint16_t font_24_index[] = { 0x00, 0x48, 0x90, 0xD8, 0x120, 0x168, 0x1B0, };上面这段是生成后的C文件结构片段，第一个数组是字模数据顺序排列区，第二个数组是字符索引表，每项指向对应字符在数据区的起始偏移。索引表生成后要同时保留一份字符顺序清单，方便程序端做编码到索引的反查。C数组前缀是const，意味着你既可以把整个文件直接放进MCU的Flash，也可以把它转成bin文件烧录到外部存储器，程序通过总线和文件系统读取。工具生成的另一个BIN文件实际就是font_24_data[]的原始字节dump，适合用烧录器直接写入W25Q64这类Flash芯片。
3.4 多尺寸同时生成：批量跑多套配置
工具支持通过配置文件定义多组生成任务。我会在工程根目录建一个fonts目录，里面放共用字表chars_clean.txt，再放三个配置文件分别定义16x16、24x24、32x32的生成参数。启动批量模式后，工具按配置逐套生成，输出目录自动带上尺寸后缀。这一步做成自动化之后，主程序固件里切换菜单字号只需要改一个宏，不需要手动重跑取模。
多尺寸生成的一个容易忽略的点是：不同尺寸的字模在屏幕上的基线不一致。24x24，32x32两种尺寸混排时，如果都以各自网格左上角为基准，写字会呈波浪形上下浮动。工具参数里有一个垂直对齐基准选项，把它设为"基线对齐"或"中心对齐"，混排时视觉效果才统一。这个参数在只生成单尺寸时感觉不出来，一旦同一屏混排大小字号，就变成显眼的问题。
4. 避坑：字模方向颠倒、字节序错乱、命名冲突，五条踩坑记录
4.1 现象：16x16字模显示成乱码，每个字像被撕成两半再错位拼回去
原因：取模方向选了逐列正向，但驱动代码里写入显存时按逐行方式增量填充。屏幕控制器接收数据后按行刷新，而数据是按列打包的，两者对不上，每个字的上半部分和下半部分被拆散错位。
解决：确认你的驱动库的写数据循环是横向扫描还是纵向扫描。SSD1306这类屏如果用了页地址模式，写显存是按页（8像素高的横条）推进的，取模方向必须选逐行正向；除非你改用水平寻址模式或垂直寻址模式，才考虑逐列取模。我在遇到这类问题时会在代码里加一个调试开关，临时输出字模首8字节到串口，和工程里预期的数值比对。比对一致，再查屏幕方向；比对不一致，先改取模方向再重新生成。
4.2 现象：字模本身看起来正常，但屏幕显示的汉字像从镜子看
原因：MSB/LSB字节位序配置和驱动反了。取模工具默认MSB在前（首bit是左边第一个像素），但有些国产屏的驱动库代码里用了LSB-first的数据翻转逻辑，导致每个字节内部像素左右镜像。
解决：在生成工具的字节序选项里切换一次"高位在前/低位在前"，重新生成后对比显示。更稳妥的办法是看驱动库的写数据函数是否对每个字节做bit反转，如果驱动代码里习惯性地写了reverse_bit8函数，那么工具这端就必须选LSB在前。
4.3 现象：生成的文件里字符顺序和预期字表顺序不一致
原因：字表文本被工具按行读取后，部分字符因为编码问题被解析成多字节序列，导致字符计数和排列错位；另有一些编辑器在保存TXT时把换行符改成CRLF，工具按LF切分时会多出空字模项。
解决：统一用UTF-8无BOM格式保存字表，换行符强制LF。生成后先检查输出文件里的字符清单是否正确，工具通常会额外输出一份content_list.txt，把生成的每个字符和对应数据偏移列出来，我每次都先看这个清单再往下走。
4.4 现象：批量生成同一套字表，16x16正常，32x32的某些字数据明显偏少
原因：32x32在渲染时对字体的hinting信息更敏感。部分自由字体在小字号时做了简化字形，大字号时暴露了缺笔画或字形过度问题，工具按固定网格裁剪时，部分笔画被裁掉造成数据稀疏。
解决：换用质量更稳定的系统字体，或者针对32x32单独指定一个不同字体源文件。如果必须沿用同一字体，可以把字号略微增大到34再用偏移校正，给笔画留出更多余量。
4.5 现象：生成后C数组里的注释字符和字符实际内容对应错位
原因：生成的C注释采用UTF-8编码写汉字，而你的单片机构建工具链默认把源文件按GB2312或GBK解读，注释汉字解析出来就变成乱码，导致人工检查时误判对应关系。数组里的字节数据本身没变，但注释和字符名的错位带来了管理混乱。
解决：生成C文件时确认工具设置的输出编码为UTF-8，同时在工程里强制编译器按UTF-8解析源文件。GCC加-finput-charset=UTF-8，Keil在Edit Configuration里把Encoding设为UTF-8。对于已经生成的文件，不要用文本编辑器另存为其他编码，否则中文注释会污染源文件。
5. 验证与进阶：用模拟点阵预览脚本，把字模先画出来再进固件
5.1 用Python把字模数组还原成可视化点阵网格
拿到生成的字模数组，别急着烧片，先用脚本在电脑上渲染成图片，肉眼确认每个字的形态。这个步骤基本消除"写完固件才发现字模废了"的返工。
import struct def parse_font_bin(bin_path, width=16, height=16): with open(bin_path, 'rb') as f: data = f.read() glyph_size = (width * height) // 8 glyphs = [] for i in range(0, len(data), glyph_size): glyphs.append(data[i:i+glyph_size]) return glyphs def render_glyph(glyph, width=16, height=16): rows = [] bytes_per_row = width // 8 for y in range(height): row_bits = [] for b in range(bytes_per_row): byte = glyph[y * bytes_per_row + b] for bit in range(8): row_bits.append((byte >> (7 - bit)) & 0x01) rows.append(row_bits) return rows def show_ascii(glyph, width=16, height=16): rows = render_glyph(glyph, width, height) lines = [] for row in rows: lines.append(''.join('#' if px else '.' for px in row)) return '\n'.join(lines) glyphs = parse_font_bin('font_24.bin', 24, 24) print(show_ascii(glyphs[0], 24, 24))parse_font_bin按glyph_size切分数据块，render_glyph把每个字节按MSB-first拆成8个bit，show_ascii把bit映射成字符画输出。这段脚本假设你的字模文件是按顺序排列的连续数据，且每行字节数正好整除8。24x24字模每行24像素，3个字节，正好能用这段逻辑。如果字号改成非8倍数的宽度，需要额外处理跨字节移位，那种情况下还是用32x32这类对齐宽度更省事。
把脚本输出和字表对照检查，重点看"永""火""国"这类结构复杂的字，轮廓清晰、笔画连贯，基本就能放心进固件。
5.2 增量加字流程：不重新全量生成，只对新字符单独出模
项目跑到后期，产品经理加字是很常见的事。重新全量生成所有字模，虽然工具很快，但会在固件仓库里制造大量diff，而且万一生成参数被顺手改过，整个字库等于悄悄换了版本。我会把原始字表文件、生成参数配置、工具版本号一起放进固件仓库的tools/目录，后续每次加字都走固定流程：修改字表文件，跑一次增量生成参数，工具只输出新增字符的BIN数据段，然后在程序端手动添加索引表项。这个流程配合4.3里提到的content_list.txt，每次都能确认新字符的偏移和字符一一对应。
从那以后我每次接到"加几个字"的活，都强制走一遍：改字表、跑增量生成、比对content_list、用预览脚本画出来，四步确认完才提交代码。批量生成工具的坑大多是参数配置的问题，配置不乱，流程顺手，字模这关就能安稳跨过去。希望帮到你。
本文还有配套的精品资源，点击获取
