简介：这是一份面向打印机固件开发、LCD汉字显示及嵌入式字库应用场景的GBK点阵字模资源，收录GBK1.0规范内22046个汉字，不含用户自定义区，可解决开发中难以找到专业字库的痛点。包内提供16×16与24×24两套点阵字库文件，并附完整GBK编码表两份，分别按分区与编码顺序排列，便于快速定位与校验。资源共21个文件，以bin字库、txt编码表、exe字模工具、bpl与ptl组件、c与h转码源码等为主，压缩包约3.41MB，另含GBK转BIG5、GBK转Unicode函数及字模提取、牧码字模、PCtoLCD2002等工具，覆盖从取模到编码转换的完整链路。目前已有1670人学习下载，适合需要直接集成字库、研究索引算法或搭建显示打印原型的开发者参考使用。
1. 点阵字模的刚需场景：为什么嵌入式打印和显示绕不开 GBK 16×16 与 24×24
做嵌入式显示或热敏打印的兄弟多半遇到过这种局面：屏幕驱动调通了，字库却成了拦路虎。用矢量字体吧，Flash 和 RAM 都吃紧，渲染还依赖复杂的字形引擎；用现成的字库芯片吧，成本上去了，字型又改不动。这时候 GBK 点阵字模就成了最务实的选择——16×16 用于小尺寸 LCD 状态栏和票据行，24×24 用于打印抬头和需要清晰度的场合，数据直接按位取模，MCU 拿到就能刷屏或送打印头。
这份资源给的就是一套完整的 GBK 汉字点阵字模数据，覆盖 16×16 和 24×24 两种规格，同时附带索引算法和取模工具。它解决的核心问题很具体：你不需要再自己跑取模软件一个个导出，也不用去猜 GBK 编码和字模数组之间的映射关系。拿到手就能集成到显示驱动或打印任务里，适合做嵌入式 HMI、POS 机打印、工控仪表显示的开发者。
2. 字模数据组织与 GBK 索引算法：从编码到点阵数组的映射链路
2.1 GBK 编码区间与字模存储布局
GBK 是双字节编码，高字节范围 0x81–0xFE，低字节范围 0x40–0xFE（剔除 0x7F）。汉字点阵数据通常按区位顺序排列，每个汉字对应固定字节数的点阵信息。16×16 点阵每字占 32 字节，24×24 点阵每字占 72 字节。存储时一般把整个 GBK 汉字区连续排列，通过编码计算出偏移量直接定位。
常见做法是只存 GBK 一级和二级汉字区，不存符号区，因为符号区往往用 ASCII 点阵单独处理。一级汉字从 0xB0A1 开始，二级汉字到 0xF7FE 结束。索引算法的本质就是把 GBK 双字节编码转换成一个线性序号，再乘以单字字节数得到数组下标。
// gbk_font_index.c // 根据 GBK 编码计算 16x16 点阵字模在数组中的偏移 // gbk_code: 双字节 GBK 编码，高字节在前 // 返回：字模数据在 font_16x16 数组中的起始下标（字节单位） // 若编码不在汉字区，返回 -1 #include <stdint.h> #define FONT_16X16_BYTES 32 // 16*16/8 = 32 字节 #define FONT_24X24_BYTES 72 // 24*24/8 = 72 字节 int32_t gbk_get_font_offset(uint16_t gbk_code, uint8_t font_size) { uint8_t high = (gbk_code >> 8) & 0xFF; uint8_t low = gbk_code & 0xFF; uint16_t quwei; // 区位码 uint16_t index; // 汉字序号 // 仅处理 GBK 汉字区：高字节 0xB0-0xF7，低字节 0xA1-0xFE if (high < 0xB0 || high > 0xF7) { return -1; } if (low < 0xA1 || low > 0xFE) { return -1; } // 转换为区位码：区号 = 高字节 - 0xA0，位号 = 低字节 - 0xA0 quwei = (uint16_t)(high - 0xA0) * 100 + (low - 0xA0); // 计算在一级/二级汉字表中的线性序号 // 一级汉字：区 16-55，二级汉字：区 56-87 if (high >= 0xB0 && high <= 0xD7) { // 一级汉字区 index = (uint16_t)(high - 0xB0) * 94 + (low - 0xA1); } else if (high >= 0xD8 && high <= 0xF7) { // 二级汉字区，接在一级之后 index = 94 * 55 + (uint16_t)(high - 0xD8) * 94 + (low - 0xA1); } else { return -1; } if (font_size == 16) { return (int32_t)(index * FONT_16X16_BYTES); } else if (font_size == 24) { return (int32_t)(index * FONT_24X24_BYTES); } return -1; }这段代码的关键在于区位码到线性序号的转换。一级汉字共 55 个区，每区 94 个位，所以二级汉字的起始序号是 94×55。参数gbk_code需要调用方保证是合法的双字节 GBK 编码，font_size只支持 16 和 24 两种规格。返回 -1 表示该编码不在汉字区，调用方应该回退到 ASCII 字模或显示占位符。
注意：不同取模工具生成的数组可能按列优先或行优先排列，也可能高低字节顺序不同。集成前务必用“中”字验证偏移是否正确，这个字在一级汉字区第一个位置，最容易核对。
2.2 点阵数据的字节序与扫描方向
点阵字模的字节排列方式直接决定显示效果。16×16 汉字通常每行 2 字节，共 16 行，高位在前表示左侧像素。24×24 每行 3 字节，共 24 行。如果扫描方向搞反，字会变成镜像或者上下颠倒。
常见做法是在取模工具里选择“横向取模、字节正序”，这样生成的数组可以直接按行写入 LCD 的 GRAM。打印场景则要注意热敏打印头是纵向排列还是横向排列，必要时在送数据前做一次转置。
// font_render.c // 将 16x16 点阵字模渲染到单色 LCD 缓冲区 // font_data: 指向字模数组的指针 // lcd_buf: LCD 显存缓冲区，每行 2 字节，共 16 行 // 说明：按行优先、高位在左的方式写入 void render_16x16(const uint8_t *font_data, uint8_t *lcd_buf) { for (int row = 0; row < 16; row++) { // 每行 2 字节，直接拷贝 lcd_buf[row * 2] = font_data[row * 2]; lcd_buf[row * 2 + 1] = font_data[row * 2 + 1]; } } // 若 LCD 控制器要求列优先，则需要转置 void render_16x16_transposed(const uint8_t *font_data, uint8_t *lcd_buf) { for (int row = 0; row < 16; row++) { for (int col = 0; col < 16; col++) { // 读取源点阵中的像素 uint8_t byte = font_data[row * 2 + (col / 8)]; uint8_t bit = (byte >> (7 - (col % 8))) & 0x01; // 写入转置后的位置 if (bit) { lcd_buf[col * 2 + (row / 8)] |= (0x80 >> (row % 8)); } } } }render_16x16适用于大多数 SPI LCD，直接按行拷贝即可。render_16x16_transposed用于那些显存按列组织的屏，比如某些 OLED 或热敏打印头。参数lcd_buf需要调用方提前清零，否则会出现残影。转置版本里row / 8和row % 8的计算是定位目标字节和位偏移，这是点阵操作里最常见的位运算套路。
2.3 索引算法的边界处理与性能取舍
实际项目里，GBK 编码可能来自串口、文件系统或者网络，难免遇到非法编码或非汉字字符。索引函数必须能区分“编码合法但非汉字”和“编码本身非法”两种情况。前者返回 -1 让上层显示问号，后者应该直接丢弃或记录错误。
性能方面，如果每帧都要刷新大量汉字，每次都做乘法和除法会拖慢速度。常见优化是预计算一张偏移表，把常用汉字的偏移量缓存起来。对于 RAM 紧张的 MCU，也可以只缓存最近使用的 32 个汉字，用简单的 LRU 淘汰。
// font_cache.c // 简单的汉字偏移缓存，减少重复计算 #define CACHE_SIZE 32 typedef struct { uint16_t gbk_code; int32_t offset; uint8_t valid; } font_cache_entry_t; static font_cache_entry_t cache[CACHE_SIZE]; static uint8_t cache_idx = 0; int32_t gbk_get_offset_cached(uint16_t gbk_code, uint8_t font_size) { // 先查缓存 for (int i = 0; i < CACHE_SIZE; i++) { if (cache[i].valid && cache[i].gbk_code == gbk_code) { return cache[i].offset; } } // 未命中则计算并写入 int32_t off = gbk_get_font_offset(gbk_code, font_size); if (off >= 0) { cache[cache_idx].gbk_code = gbk_code; cache[cache_idx].offset = off; cache[cache_idx].valid = 1; cache_idx = (cache_idx + 1) % CACHE_SIZE; } return off; }这个缓存实现很轻量，32 个条目在大多数 MCU 上只占几百字节。cache_idx循环递增，相当于一个简单的 FIFO 淘汰策略。对于打印场景，一页内容往往有重复汉字，缓存命中率能到 60% 以上，效果立竿见影。
3. 从取模工具到工程集成：16×16 与 24×24 字模的生成与调用
3.1 取模工具的参数配置与输出格式
资源里附带的取模工具通常支持批量导出。配置时要注意几个关键选项：取模方式选“横向取模”，字节序选“高位在前”，输出格式选“C 数组”或“二进制文件”。如果工具支持按 GBK 编码命名文件，那后期维护会省很多事。
常见做法是先用工具生成一个完整的二进制字库文件，再用脚本转成 C 数组嵌入固件。这样比直接生成巨大的 C 文件更灵活，也方便在外部 Flash 里存放字库。
# 将取模工具输出的二进制字库转换为 C 数组 # font_16x16.bin 为 16x16 点阵数据，按 GBK 顺序排列 xxd -i font_16x16.bin > font_16x16.h # 生成的数组名类似 font_16x16_bin，长度变量为 font_16x16_bin_lenxxd -i是 Linux 下常用的转换命令，Windows 下可以用bin2c工具替代。生成的数组可以直接放在 Flash 的常量区，用const修饰避免占用 RAM。如果字库太大，建议放到外部 SPI Flash，通过地址映射读取。
3.2 显示驱动中的字模调用流程
在显示驱动里集成字模，核心就三步：取编码、算偏移、刷数据。以 ST7789 驱动的 SPI LCD 为例，显示一个汉字的流程如下。
// display.c // 在 LCD 指定位置显示一个 GBK 汉字 // x, y: 左上角坐标 // gbk_code: 汉字 GBK 编码 // color: 前景色，背景色假设已填充 void lcd_draw_gbk_char(uint16_t x, uint16_t y, uint16_t gbk_code, uint16_t color) { int32_t offset = gbk_get_offset_cached(gbk_code, 16); if (offset < 0) { // 非汉字，显示占位符或跳过 return; } const uint8_t *font = &font_16x16[offset]; for (int row = 0; row < 16; row++) { uint8_t byte0 = font[row * 2]; uint8_t byte1 = font[row * 2 + 1]; for (int col = 0; col < 16; col++) { uint8_t bit; if (col < 8) { bit = (byte0 >> (7 - col)) & 0x01; } else { bit = (byte1 >> (7 - (col - 8))) & 0x01; } if (bit) { lcd_draw_pixel(x + col, y + row, color); } } } }lcd_draw_gbk_char逐像素判断并绘制，适合没有硬件加速的场合。如果 LCD 支持区域填充，可以先把点阵展开成一行像素再批量写入，速度会快很多。参数color是前景色，背景色需要在调用前填充好，否则会出现花屏。
3.3 打印场景下的 24×24 字模处理
热敏打印和针式打印对点阵的要求不同。热敏打印头通常是 384 点或 576 点宽，每行数据按字节从高位到低位对应加热点。24×24 字模在打印时，需要把每行 3 字节拆成 24 个位，再按打印头的位序重新组装。
// printer.c // 将 24x24 字模转换为打印头行数据 // font_data: 24x24 点阵数据，每行 3 字节 // print_buf: 打印行缓冲区，长度至少 24 字节（每字节对应一个加热点） // 说明：假设打印头位序为高位在前，与字模一致 void font24_to_printer(const uint8_t *font_data, uint8_t *print_buf) { for (int row = 0; row < 24; row++) { uint8_t b0 = font_data[row * 3]; uint8_t b1 = font_data[row * 3 + 1]; uint8_t b2 = font_data[row * 3 + 2]; for (int col = 0; col < 24; col++) { uint8_t bit; if (col < 8) { bit = (b0 >> (7 - col)) & 0x01; } else if (col < 16) { bit = (b1 >> (7 - (col - 8))) & 0x01; } else { bit = (b2 >> (7 - (col - 16))) & 0x01; } print_buf[col] = bit ? 1 : 0; } // 此处调用打印头送行函数，发送 print_buf 的前 24 字节 // printer_send_line(print_buf, 24); } }这段代码把字模的位展开成打印头的点数据。实际打印时，一行可能包含多个汉字，需要把它们的点数据拼接起来。print_buf的长度要按打印头宽度分配，24 只是单个汉字的宽度。如果打印头是 384 点，缓冲区至少 384 字节。
注意：热敏打印头的加热时间与点数据有关，连续黑点过多会导致打印头过热。打印 24×24 粗体字时，建议在固件里加入加热时间动态调整，或者降低打印速度。
4. 避坑与排查：字模集成中最容易翻车的五个地方
4.1 显示出来是乱码或镜像
现象：汉字显示成乱码，或者左右镜像、上下颠倒。
原因：取模工具的扫描方向与 LCD 驱动不匹配。横向取模配列优先显存，或者高位在前配低位在前。
解决：用“中”字做基准，分别测试四种组合：横向/纵向、高位/低位。找到正确组合后，在取模工具里固定下来，不要中途更换。
4.2 偏移计算错误导致取到相邻字
现象：显示的字总是差一个或几个位置，比如“中”显示成“串”。
原因：GBK 区位码转换公式用错，或者一级/二级汉字区的起始序号算错。
解决：打印出gbk_get_font_offset的返回值，与字库文件里“中”字的实际偏移对比。一级汉字区第一个字是“啊”，偏移 0；第二个字是“阿”，偏移 32（16×16）。用这两个字验证公式。
4.3 字库太大导致 Flash 溢出
现象：编译报错region FLASH overflowed，或者链接时提示空间不足。
原因：完整 GBK 汉字库 16×16 约 260KB，24×24 约 580KB，加上代码很容易超过 MCU 内部 Flash。
解决：只保留项目用到的汉字，用工具生成子集字库。或者把字库放到外部 SPI Flash，通过内存映射或文件系统读取。
4.4 打印时汉字缺笔画或拖尾
现象：打印出来的汉字缺横少竖，或者相邻行之间有拖尾。
原因：打印头送行速度与加热时间不匹配，或者点数据在移位时丢失。
解决：检查打印头的锁存信号和时钟信号时序，确保每个字节在送行前已经稳定。适当增加加热时间，但不要超过打印头规格书的上限。
4.5 缓存命中率低导致刷新慢
现象：刷屏时明显卡顿，尤其是滚动显示时。
原因：缓存太小或者淘汰策略不合理，频繁未命中导致重复计算。
解决：把缓存扩大到 64 或 128 条，或者改用直接映射缓存，用编码的低位做索引。对于滚动显示，可以预取下一屏的汉字偏移。
5. 二次开发与改造：字库裁剪、动态加载与自定义字型
5.1 按项目需求裁剪字库
完整 GBK 字库虽好，但很多项目只用得到几百个汉字。裁剪字库最直接的办法是用工具生成子集，但子集字库的索引算法需要调整——不能再按 GBK 区位码直接算偏移，而要建立一张编码到偏移的映射表。
我一般会这样做：先用脚本统计项目里所有用到的汉字，生成一个编码列表；然后用取模工具只导出这些字，按列表顺序排列；最后在固件里放一张uint16_t的编码表，查找时先二分查找编码，拿到序号再算偏移。这样字库能缩小到原来的十分之一，RAM 占用也可控。
# gen_subset.py # 根据汉字列表生成子集字库和编码映射表 # 输入：chars.txt 每行一个汉字 # 输出：subset_font.bin 和 subset_map.h chars = [] with open('chars.txt', 'r', encoding='gbk') as f: for line in f: line = line.strip() if line: chars.append(line) # 去重并排序 chars = sorted(set(chars)) # 生成编码映射表 with open('subset_map.h', 'w', encoding='utf-8') as f: f.write('const uint16_t gbk_subset_map[] = {\n') for ch in chars: gbk = ch.encode('gbk') code = (gbk[0] << 8) | gbk[1] f.write(f' 0x{code:04X}, // {ch}\n') f.write('};\n') f.write(f'#define GBK_SUBSET_COUNT {len(chars)}\n') print(f'共 {len(chars)} 个汉字，映射表已生成')这个脚本用 Python 的 GBK 编码功能，把汉字转成双字节编码。生成的映射表按编码排序，固件里用二分查找就能快速定位。GBK_SUBSET_COUNT宏定义方便数组遍历。注意脚本要以 GBK 读取输入文件，否则中文会乱码。
5.2 动态加载外部字库
如果字库放在外部 SPI Flash 或 SD 卡，就需要动态加载。常见做法是把字库文件按扇区对齐，每个扇区存固定数量的汉字。读取时先算扇区号，再读整个扇区到缓冲区，最后从缓冲区里取字模。
// font_ext.c // 从外部 SPI Flash 读取 16x16 字模 // gbk_code: 汉字编码 // buf: 输出缓冲区，至少 32 字节 // 返回：0 成功，-1 失败 #include "spi_flash.h" #define FONT_BASE_ADDR 0x00010000 // 字库在 Flash 中的起始地址 #define SECTOR_SIZE 4096 #define CHARS_PER_SECTOR (SECTOR_SIZE / 32) int ext_font_read_16x16(uint16_t gbk_code, uint8_t *buf) { int32_t offset = gbk_get_font_offset(gbk_code, 16); if (offset < 0) { return -1; } uint32_t addr = FONT_BASE_ADDR + offset; uint32_t sector_addr = addr & ~(SECTOR_SIZE - 1); uint32_t sector_offset = addr - sector_addr; // 如果字模跨扇区，需要读两个扇区 if (sector_offset + 32 > SECTOR_SIZE) { uint8_t sector_buf[SECTOR_SIZE]; spi_flash_read(sector_addr, sector_buf, SECTOR_SIZE); uint32_t first_part = SECTOR_SIZE - sector_offset; for (uint32_t i = 0; i < first_part; i++) { buf[i] = sector_buf[sector_offset + i]; } spi_flash_read(sector_addr + SECTOR_SIZE, buf + first_part, 32 - first_part); } else { spi_flash_read(addr, buf, 32); } return 0; }ext_font_read_16x16处理了跨扇区的情况，这是外部 Flash 读取最容易忽略的细节。FONT_BASE_ADDR需要根据实际分区表调整，SECTOR_SIZE要与 Flash 芯片的扇区大小一致。如果 SPI Flash 支持内存映射模式，可以直接用指针访问，省去拷贝开销。
5.3 自定义字型与混合排版
有些项目需要特殊字型，比如加粗、倾斜或者手写体。点阵字模的改造空间有限，但可以通过位运算实现简单效果。加粗就是把点阵向右和下各偏移一位再或运算；倾斜就是每行按行号偏移若干位。
// font_style.c // 对 16x16 字模进行加粗处理 // src: 原始字模，dst: 输出字模，均 32 字节 void font_bold_16x16(const uint8_t *src, uint8_t *dst) { for (int row = 0; row < 16; row++) { uint16_t line = (src[row * 2] << 8) | src[row * 2 + 1]; uint16_t bold = line | (line >> 1); // 向右加粗 dst[row * 2] = (bold >> 8) & 0xFF; dst[row * 2 + 1] = bold & 0xFF; } // 向下加粗：把当前行与上一行或运算 for (int row = 15; row > 0; row--) { dst[row * 2] |= dst[(row - 1) * 2]; dst[row * 2 + 1] |= dst[(row - 1) * 2 + 1]; } }font_bold_16x16先做水平加粗，再做垂直加粗。line >> 1把像素向右移一位，或运算后原来的点保留，右边多出一个点。垂直加粗从下往上遍历，避免覆盖未处理的行。这个函数会改变字模的原始数据，所以dst要和src分开。
混合排版时，16×16 和 24×24 字模可以混用。比如标题用 24×24，正文用 16×16。关键是坐标计算要统一，行高按最大字模高度对齐。我一般会封装一个draw_text函数，根据字号参数自动选择字模和偏移算法。
从那以后我每次集成新字库，都强制走一遍“中”字验证流程：先确认偏移正确，再确认扫描方向，最后确认字节序。这三步过了，后面基本不会出玄学问题。希望帮到你。
本文还有配套的精品资源，点击获取
