简介面向嵌入式、单片机及点阵显示项目开发者这套字库合集覆盖 HZK12、HZK14、HZK16、HZK24、HZK32、HZK40、HZK48 等汉字点阵字库以及 ASC12/16/24/32/48 等 ASCII 字模并且为每种字体都配好了读取代码解决了制作点阵文字时字库分散、取模方式不统一的问题省去四处寻找字库的麻烦。压缩包共 55 个文件总大小约 7.53MB按 txt、java、c、class、obj、exe 及各类 hzk、asc 字库文件分门别类既可直接查阅也可用于二次开发。目前已有 1652 人学习下载适合单片机屏幕显示、LED 点阵屏、字符取模与字符渲染等项目的开发人员。示例代码提供 Java 与 C 两种实现可快速理解汉字和 ASCII 字库的存储偏移、字模排列与读取流程再配合工具和说明文件能在实际项目中直接生成所需字模数据有效减少底层摸索时间提升开发效率。 做点阵屏最崩溃的时刻不是代码调不出来而是中文字库读出来的数据全是乱的。我头一回做16×16 LED屏的时候显示“欢迎光临”四个字屏幕上出来四团完全看不出形状的噪声点排查到半夜才意识到问题根本不在驱动电路而在字库文件本身——HZK16到底按什么顺序存字模代码按什么偏移去取这两个一错后面全白搭。这话题看着冷但只要你碰LCD、OLED、LED点阵屏迟早要撞上。这里说的HZK系列、ASC系列就是GB2312编码下最常用的点阵汉字库和ASCII字库文件。本文把这批字库的结构、偏移规则、读取代码和实际排坑经验一次讲清楚适合刚接触单片机显示、正准备做汉字屏的开发者。1. 从HZK16开始认识这批点阵字库1.1 HZK命名与“一个字占多少字节”HZK是汉字库的拼音缩写后面的数字代表点阵规格。HZK16就是16×16点阵的汉字库即每个汉字用16行、每行16个像素点来表示一个像素点用1位数据0不亮、1点亮。16×16总共256位除以8就是32字节所以HZK16里每个汉字固定占32字节。这个“每字32字节”是所有后续计算的地基。显示一个汉字时只要从字库文件里正确读出这32字节再按点阵位置逐位点亮字形就出来了。HZK系列里的HZK24、HZK32、HZK40、HZK48也是同一个逻辑点阵越大字形越精细占的字节也越多HZK2424×24点阵每字 24×24÷8 72字节HZK3232×32点阵每字 32×32÷8 128字节HZK4040×40点阵每字 40×40÷8 200字节HZK4848×48点阵每字 48×48÷8 288字节唯独HZK12要小心。12×12算下来只有18字节但12不是8的整数倍很多字库文件实际按字节对齐存储一行存2字节、共12行于是每字变成24字节也有的按18字节存。所以拿到HZK12文件时第一件事就是确认每字到底占多少字节不能想当然。我见过不止一个项目因为默认按24字节读、实际文件却是18字节结果汉字全部错位。1.2 GB2312区位码与偏移计算公式HZK字库文件内部是按GB2312编码顺序排列字模的。GB2312用两个字节表示一个汉字两个字节减去0xA0后得到区号和位号。区号范围01~94位号范围01~94汉字就按“区”和“位”排成一张二维表。读取任意汉字字模的偏移公式是偏移 ((区号 - 1) * 94 (位号 - 1)) * 每字字节数但在实际代码里一般直接拿编码字节计算区号就是高字节 - 0xA1位号就是低字节 - 0xA1写成offset ((uint32_t)(q - 0xA1) * 94 (uint32_t)(w - 0xA1)) * bytes_per_char;这个公式适用于HZK12、HZK16、HZK24、HZK32、HZK40、HZK48全套区别只在最后乘的每字字节数不同。GB2312的94区×94位理论上能排8836个字模但符号区、空白区实际未必都有内容不同来源的字库文件大小会有差异偏移公式仍按区位顺序走。1.3 先算一笔存储账再挑字库做项目选字库尺寸第一个制约因素是存储空间。按94×94全表估算16点阵全字库约276KB24点阵约622KB32点阵约1.08MB40点阵约1.69MB48点阵约2.43MB。很多单片机的内部Flash连1MB都没有把32点阵以上整库塞进去基本不现实。所以实际项目里通常这样配小尺寸LCD、OLED屏用HZK16或HZK12中等尺寸LED点阵屏用HZK24、HZK32户外大屏、高密度显示屏才考虑HZK40、HZK48而且一般配外部Flash或SD卡。选择顺序应该是先看存储预算再看显示效果而不是越大越好。2. 字模的字节排列横向、纵向和那点“先左后右”的讲究2.1 HZK16标准文件里的横向排列HZK16文件内部存放的是横向取模数据排列方式很规整第0~1字节是第一行的左右两半第2~3字节是第二行的左右两半依此类推共16行、32字节。具体到一个字节内部高位对应左边的像素。也就是说某一行左边8个点对应字节的bit7到bit0bit7是这一行最左边的点。如果你读出来第一行的第一个字节是0x80那左上角那个点必然点亮。这个排列方式对应的是逐行扫描逻辑很方便在LCD上按行刷数据。但市面上很多取模软件默认生成的是纵向取模即先取每一列的上下像素再取下一列。这两种数据互不兼容直接套用必然乱码。2.2 纵向取模LED屏为什么总让你“转个方向”很多LED点阵屏驱动采用逐列扫描一列一列地送数据这种情况下纵向取模更方便第0~1字节是第一列的上下两半第2~3字节是第二列的上下两半共16列、32字节。HZK16文件不是这个格式所以需要做一次转换。从横向转纵向的关键代码长这样void hzk_h2v(const uint8_t *hbuf, uint8_t *vbuf, uint8_t w, uint8_t h) { // hbuf为横向取模数据vbuf输出纵向取模数据 uint8_t bytes_per_row (w 7) / 8; // 每行字节数 memset(vbuf, 0, w * ((h 7) / 8)); for (uint8_t row 0; row h; row) { for (uint8_t col 0; col w; col) { if (hbuf[row * bytes_per_row col / 8] (0x80 (col % 8))) { vbuf[col * ((h 7) / 8) row / 8] | (0x80 (row % 8)); } } } }先想清楚这两件事再写转换你的屏幕是逐行扫描还是逐列扫描你的字库源文件是横向还是纵向。确定了转换就是一重简单的坐标映射不确定就是靠猜猜错就等着花屏。2.3 ASC系列字库ASCII字符的简单偏移规则ASC系列是配套的ASCII半角字库和HZK配合使用用来显示英文字母、数字和符号。这类字库的偏移规则比汉字简单得多通常直接用字符码作为索引。以最常见的ASC16为例每个字符是8×16点阵每行1字节、共16行所以每字符占16字节。读取第ch个字符的偏移就是offset (uint32_t)ch * 16;字符‘A’的ASCII码是0x41偏移就是0x41×161040读16字节就是这个字母的字模。ASC12、ASC24、ASC32、ASC48的区别只在点阵尺寸和每字符字节数ASC12常见为6×12或12×12每字符12字节左右ASC24常见宽度12或16像素、高度24像素每字符48字节上下ASC32常见16×32每字符64字节ASC48常见24×48每字符144字节。这组数不是绝对的很多取模工具生成的具体规格都不太一样拿到文件后先确认“每字符字节数”和“是否保留0x20之前的控制字符位置”确认后再写代码。3. C语言读取代码直接可用的那几段3.1 文件版fopen加fseek读取HZK16与ASC16最直接的用法是把字库文件放在SD卡或文件系统里用标准C库读取。下面这套函数足够覆盖大多数场景。#include stdio.h #include stdint.h #include string.h #define HZK16_BYTES 32 #define ASC16_BYTES 16 static FILE *hzk_fp NULL; static FILE *asc_fp NULL; int font_init(const char *hzk_path, const char *asc_path) { if (hzk_path) { hzk_fp fopen(hzk_path, rb); if (!hzk_fp) return -1; } if (asc_path) { asc_fp fopen(asc_path, rb); if (!asc_fp) return -1; } return 0; } int get_hzk16(uint8_t q, uint8_t w, uint8_t *out) { uint32_t offset ((uint32_t)(q - 0xA1) * 94 (uint32_t)(w - 0xA1)) * HZK16_BYTES; fseek(hzk_fp, offset, SEEK_SET); return fread(out, 1, HZK16_BYTES, hzk_fp) HZK16_BYTES ? 0 : -1; } int get_asc16(uint8_t ch, uint8_t *out) { fseek(asc_fp, (uint32_t)ch * ASC16_BYTES, SEEK_SET); return fread(out, 1, ASC16_BYTES, asc_fp) ASC16_BYTES ? 0 : -1; }注意fopen的模式必须用rb不是r。在Windows上文本模式下遇到0x1A这类特殊字节会被当成文件结束符处理字模数据是二进制数据用文本模式读取大概率会出现字模不完整的问题。3.2 内存数组版把字库烧进Flash的用法如果你的平台片内Flash够大或者字库已经裁剪成数组文件可以直接把整个字库定义成const数组读取时用memcpy效率比fseek高很多还没有文件系统依赖。// 假设已有外部生成的字符数组内容就是整个HZK16字库 extern const uint8_t hzk16_font[]; void get_hzk16_mem(uint8_t q, uint8_t w, uint8_t *out) { uint32_t offset ((uint32_t)(q - 0xA1) * 94 (uint32_t)(w - 0xA1)) * HZK16_BYTES; memcpy(out, hzk16_font offset, HZK16_BYTES); }这个版本最适合STM32这类直接外挂SPI Flash、或者把字模通过工具链转成C数组的项目。数组方式读取没有文件系统开销在循环刷新大量汉字时优势非常明显。3.3 字符串遍历混合中英文时的编码判断实际显示时字符串里往往中英文混排。遍历时每遇到一个字节要先判断它是不是ASCII字符再决定按1字节还是2字节处理。void draw_string(const char *str) { const uint8_t *p (const uint8_t *)str; while (*p) { if (*p 0x80) { // ASCII字符读ASC字库 uint8_t asc_buf[ASC16_BYTES]; get_asc16(*p, asc_buf); draw_asc16(asc_buf); p; } else { // 汉字双字节读HZK字库 uint8_t hz_buf[HZK16_BYTES]; uint8_t q p[0]; uint8_t w p[1]; get_hzk16(q, w, hz_buf); draw_hzk16(hz_buf); p 2; } } }这里有个极其容易踩的C语言坑char类型在不加说明时默认是有符号的。如果直接用char指针判断*p 0x80高字节像0xC4会被当成负数判断结果仍然正确但如果你把字节直接参与区位计算负数的符号扩展会让偏移变成天文数字。一定要用uint8_t指针或者每次强转uint8_t再参与计算。3.4 验证字模先在PC上把点阵打印出来字模读出来对不对不要直接上屏先在PC上打印出来看。写一个极简的打印函数传到PC串口或者本地跑一下能直观看到字形void show_hzk16(const uint8_t *buf) { for (int row 0; row 16; row) { for (int col 0; col 16; col) { // 横向取模第row行第col列 if (buf[row * 2 col / 8] (0x80 (col % 8))) { putchar(#); } else { putchar(.); } } putchar(\n); } }只要这个打印能还原出完整的字形说明偏移和取模方向都没问题接下来上屏就算扫向不匹配也是肉眼可查的镜像或颠倒而不是无从下手的乱码。我调字库时每次必先做这一步能省掉一半调试时间。4. 我踩过的坑乱码、错位和找不到字4.1 源码编码不对UTF-8取出来的“汉字”是三个字节这是新手问得最多的问题之一。单片机工程在Keil、IAR里写你好编译器默认按GB2312/GBK存储字符串里就是两个字节“C4 E3”、“BA C3”上面代码直接可用。但从上位机、手机App、网络接口收到的中文字符串绝大多数是UTF-8编码一个小汉字在UTF-8里占3个字节比如“你”是“E4 BD A0”。直接把这三个字节当成GB2312区位码去读字库会得到完全不相关的字模。解决办法在PC端发送前用工具转好或在下位机做一次UTF-8到GB2312的转换。调试阶段最省事的办法就是串口助手里把发送编码改成GBK别用UTF-8。如果一定要支持UTF-8输入需要引入转换表或者特定的转换代码那是另一个话题这里不展开。4.2 偏移公式踩雷多减0xA1、文件被截断、符号区没算偏移公式看起来简单实战里至少有三类错法。一是把区号位号直接套公式忘了减0xA1。有人说区号16区开始减0xA1高位读出来0xB0就减0xB0这取决于字库文件是否含符号区。最通用、最不容易错的就是按GB2312标准区位顺序高字节、低字节统一减0xA1再乘以94加位号。二是文件被截断。网上能找到的HZK16来源五花八门有的文件缺了一部分有些汉字区偏移越过了文件末尾。fread返回的字节数小于预期时说明这个字库文件不完整别继续往下调了先换一个可靠的字库源。三是符号区没算。全字库里1~9区是标点符号和数字10~15区是空区16区开始才是汉字。如果你只需要中文按16区起算的简化公式可能没问题但如果要显示标点、全角符号偏移就不能按汉字区单独算必须走标准的GB2312全区公式。4.3 扫描方向不匹配字会镜像、上下颠倒、花掉即便字模读对了屏幕上依然可能出现三种典型症状字左右镜像、上下颠倒、整体撕裂成斜的。这些通常不是字库问题而是数据排列方式和扫描方向不匹配。排查顺序建议是这样先看打印出来的ASCII图形是否正常正常就说明字库读取没问题再上屏如果镜像把每行字节的位序反过来试试如果上下颠倒把字模按行逆序送如果一列一列乱大概率是横向数据按纵向屏刷了用前面给的转换函数转成你的屏幕对应的取模方式。这步排查完全靠经验和肉眼对比所以项目里最好写一个专用的字模调试页能随时切换横向、纵向、反向几组参数屏上直接对比效果。这个调试页初期看起来多余实际能帮你把“莫名其妙的乱码”快速定位成“方向不对”强烈建议保留。5. 工程落地建议选型、裁剪与存储5.1 不同尺寸字库适合什么样应用选字库尺寸除了看字号还得看像素密度和观看距离。HZK12、HZK16适合小尺寸LCD、OLED屏比如0.96寸OLED、12864这类字号小、存储压力小字库还能塞进片内Flash。HZK24、HZK32适合LED点阵屏、TFT大屏近距离看字形边缘比较平滑。HZK40、HZK48一般用在户外LED显示屏、灯板这类远距离观看的大字场景再配合高密度灯珠才有效果。一句话字库尺寸不是越大越好要让点阵尺寸和实际物理显示尺寸匹配否则要么字太小看不清要么资源白白浪费。5.2 字库裁剪从276KB到几十KB的常用做法如果只是显示固定菜单、固定提示语完全没必要带整库。我做过一个项目只显示30多个指定汉字用全量HZK16白白占掉276KB后来把需要显示的汉字去重后算下来只有不到3KB字模。做法很简单把项目中所有可能出现的中文文本收集到一个文本文件里去重后按GB2312编码排序在PC上用脚本逐个读取字模输出成一个紧凑的二进制文件同时生成一个索引表。运行时用索引差值或二分查找定位字模。这样字库占用能缩减到原来的十分之一甚至更少代价只是代码里多几十行索引逻辑。如果要支持用户输入任意汉字那就别裁剪了老老实实按场景选整库尺寸。5.3 性能优化别让每个字都去fseek用文件系统读字库每读一个字都做一次fseek加fread在SD卡上频繁寻道是很慢的尤其在整屏刷几十个汉字时帧率会被拉得很难看。工程上常用两种优化思路一是按行缓存先把一屏所有字符的偏移算出来一次性读一批字模到RAM再统一上屏二是把字库从SD卡拷贝到外部SPI Flash或内部Flash用内存映射或直接从Flash地址读取。后者的随机读取性能通常远高于文件系统而且不依赖FATFS这类文件系统组件系统更稳定。另外如果你用文件系统且字库文件较大打开文件后建议保持句柄不关避免反复open/close带来的开销。很多文件系统的open操作本身就很费时。最后再分享一个我个人的习惯不管字库文件是网上下的还是工具生成的拿到手先写几分钟的校验代码读取几个已知字符的ASCII打印图确认格式再往项目里集成。这一步看起来多花时间实际上每次都能提前暴露一批编码、偏移、取模方向的问题。字库这东西坑不深但错了就是整屏乱闪提前校验永远比上了屏再排查划算。本文还有配套的精品资源点击获取
简介面向嵌入式、单片机及点阵显示项目开发者这套字库合集覆盖 HZK12、HZK14、HZK16、HZK24、HZK32、HZK40、HZK48 等汉字点阵字库以及 ASC12/16/24/32/48 等 ASCII 字模并且为每种字体都配好了读取代码解决了制作点阵文字时字库分散、取模方式不统一的问题省去四处寻找字库的麻烦。压缩包共 55 个文件总大小约 7.53MB按 txt、java、c、class、obj、exe 及各类 hzk、asc 字库文件分门别类既可直接查阅也可用于二次开发。目前已有 1652 人学习下载适合单片机屏幕显示、LED 点阵屏、字符取模与字符渲染等项目的开发人员。示例代码提供 Java 与 C 两种实现可快速理解汉字和 ASCII 字库的存储偏移、字模排列与读取流程再配合工具和说明文件能在实际项目中直接生成所需字模数据有效减少底层摸索时间提升开发效率。 做点阵屏最崩溃的时刻不是代码调不出来而是中文字库读出来的数据全是乱的。我头一回做16×16 LED屏的时候显示“欢迎光临”四个字屏幕上出来四团完全看不出形状的噪声点排查到半夜才意识到问题根本不在驱动电路而在字库文件本身——HZK16到底按什么顺序存字模代码按什么偏移去取这两个一错后面全白搭。这话题看着冷但只要你碰LCD、OLED、LED点阵屏迟早要撞上。这里说的HZK系列、ASC系列就是GB2312编码下最常用的点阵汉字库和ASCII字库文件。本文把这批字库的结构、偏移规则、读取代码和实际排坑经验一次讲清楚适合刚接触单片机显示、正准备做汉字屏的开发者。1. 从HZK16开始认识这批点阵字库1.1 HZK命名与“一个字占多少字节”HZK是汉字库的拼音缩写后面的数字代表点阵规格。HZK16就是16×16点阵的汉字库即每个汉字用16行、每行16个像素点来表示一个像素点用1位数据0不亮、1点亮。16×16总共256位除以8就是32字节所以HZK16里每个汉字固定占32字节。这个“每字32字节”是所有后续计算的地基。显示一个汉字时只要从字库文件里正确读出这32字节再按点阵位置逐位点亮字形就出来了。HZK系列里的HZK24、HZK32、HZK40、HZK48也是同一个逻辑点阵越大字形越精细占的字节也越多HZK2424×24点阵每字 24×24÷8 72字节HZK3232×32点阵每字 32×32÷8 128字节HZK4040×40点阵每字 40×40÷8 200字节HZK4848×48点阵每字 48×48÷8 288字节唯独HZK12要小心。12×12算下来只有18字节但12不是8的整数倍很多字库文件实际按字节对齐存储一行存2字节、共12行于是每字变成24字节也有的按18字节存。所以拿到HZK12文件时第一件事就是确认每字到底占多少字节不能想当然。我见过不止一个项目因为默认按24字节读、实际文件却是18字节结果汉字全部错位。1.2 GB2312区位码与偏移计算公式HZK字库文件内部是按GB2312编码顺序排列字模的。GB2312用两个字节表示一个汉字两个字节减去0xA0后得到区号和位号。区号范围01~94位号范围01~94汉字就按“区”和“位”排成一张二维表。读取任意汉字字模的偏移公式是偏移 ((区号 - 1) * 94 (位号 - 1)) * 每字字节数但在实际代码里一般直接拿编码字节计算区号就是高字节 - 0xA1位号就是低字节 - 0xA1写成offset ((uint32_t)(q - 0xA1) * 94 (uint32_t)(w - 0xA1)) * bytes_per_char;这个公式适用于HZK12、HZK16、HZK24、HZK32、HZK40、HZK48全套区别只在最后乘的每字字节数不同。GB2312的94区×94位理论上能排8836个字模但符号区、空白区实际未必都有内容不同来源的字库文件大小会有差异偏移公式仍按区位顺序走。1.3 先算一笔存储账再挑字库做项目选字库尺寸第一个制约因素是存储空间。按94×94全表估算16点阵全字库约276KB24点阵约622KB32点阵约1.08MB40点阵约1.69MB48点阵约2.43MB。很多单片机的内部Flash连1MB都没有把32点阵以上整库塞进去基本不现实。所以实际项目里通常这样配小尺寸LCD、OLED屏用HZK16或HZK12中等尺寸LED点阵屏用HZK24、HZK32户外大屏、高密度显示屏才考虑HZK40、HZK48而且一般配外部Flash或SD卡。选择顺序应该是先看存储预算再看显示效果而不是越大越好。2. 字模的字节排列横向、纵向和那点“先左后右”的讲究2.1 HZK16标准文件里的横向排列HZK16文件内部存放的是横向取模数据排列方式很规整第0~1字节是第一行的左右两半第2~3字节是第二行的左右两半依此类推共16行、32字节。具体到一个字节内部高位对应左边的像素。也就是说某一行左边8个点对应字节的bit7到bit0bit7是这一行最左边的点。如果你读出来第一行的第一个字节是0x80那左上角那个点必然点亮。这个排列方式对应的是逐行扫描逻辑很方便在LCD上按行刷数据。但市面上很多取模软件默认生成的是纵向取模即先取每一列的上下像素再取下一列。这两种数据互不兼容直接套用必然乱码。2.2 纵向取模LED屏为什么总让你“转个方向”很多LED点阵屏驱动采用逐列扫描一列一列地送数据这种情况下纵向取模更方便第0~1字节是第一列的上下两半第2~3字节是第二列的上下两半共16列、32字节。HZK16文件不是这个格式所以需要做一次转换。从横向转纵向的关键代码长这样void hzk_h2v(const uint8_t *hbuf, uint8_t *vbuf, uint8_t w, uint8_t h) { // hbuf为横向取模数据vbuf输出纵向取模数据 uint8_t bytes_per_row (w 7) / 8; // 每行字节数 memset(vbuf, 0, w * ((h 7) / 8)); for (uint8_t row 0; row h; row) { for (uint8_t col 0; col w; col) { if (hbuf[row * bytes_per_row col / 8] (0x80 (col % 8))) { vbuf[col * ((h 7) / 8) row / 8] | (0x80 (row % 8)); } } } }先想清楚这两件事再写转换你的屏幕是逐行扫描还是逐列扫描你的字库源文件是横向还是纵向。确定了转换就是一重简单的坐标映射不确定就是靠猜猜错就等着花屏。2.3 ASC系列字库ASCII字符的简单偏移规则ASC系列是配套的ASCII半角字库和HZK配合使用用来显示英文字母、数字和符号。这类字库的偏移规则比汉字简单得多通常直接用字符码作为索引。以最常见的ASC16为例每个字符是8×16点阵每行1字节、共16行所以每字符占16字节。读取第ch个字符的偏移就是offset (uint32_t)ch * 16;字符‘A’的ASCII码是0x41偏移就是0x41×161040读16字节就是这个字母的字模。ASC12、ASC24、ASC32、ASC48的区别只在点阵尺寸和每字符字节数ASC12常见为6×12或12×12每字符12字节左右ASC24常见宽度12或16像素、高度24像素每字符48字节上下ASC32常见16×32每字符64字节ASC48常见24×48每字符144字节。这组数不是绝对的很多取模工具生成的具体规格都不太一样拿到文件后先确认“每字符字节数”和“是否保留0x20之前的控制字符位置”确认后再写代码。3. C语言读取代码直接可用的那几段3.1 文件版fopen加fseek读取HZK16与ASC16最直接的用法是把字库文件放在SD卡或文件系统里用标准C库读取。下面这套函数足够覆盖大多数场景。#include stdio.h #include stdint.h #include string.h #define HZK16_BYTES 32 #define ASC16_BYTES 16 static FILE *hzk_fp NULL; static FILE *asc_fp NULL; int font_init(const char *hzk_path, const char *asc_path) { if (hzk_path) { hzk_fp fopen(hzk_path, rb); if (!hzk_fp) return -1; } if (asc_path) { asc_fp fopen(asc_path, rb); if (!asc_fp) return -1; } return 0; } int get_hzk16(uint8_t q, uint8_t w, uint8_t *out) { uint32_t offset ((uint32_t)(q - 0xA1) * 94 (uint32_t)(w - 0xA1)) * HZK16_BYTES; fseek(hzk_fp, offset, SEEK_SET); return fread(out, 1, HZK16_BYTES, hzk_fp) HZK16_BYTES ? 0 : -1; } int get_asc16(uint8_t ch, uint8_t *out) { fseek(asc_fp, (uint32_t)ch * ASC16_BYTES, SEEK_SET); return fread(out, 1, ASC16_BYTES, asc_fp) ASC16_BYTES ? 0 : -1; }注意fopen的模式必须用rb不是r。在Windows上文本模式下遇到0x1A这类特殊字节会被当成文件结束符处理字模数据是二进制数据用文本模式读取大概率会出现字模不完整的问题。3.2 内存数组版把字库烧进Flash的用法如果你的平台片内Flash够大或者字库已经裁剪成数组文件可以直接把整个字库定义成const数组读取时用memcpy效率比fseek高很多还没有文件系统依赖。// 假设已有外部生成的字符数组内容就是整个HZK16字库 extern const uint8_t hzk16_font[]; void get_hzk16_mem(uint8_t q, uint8_t w, uint8_t *out) { uint32_t offset ((uint32_t)(q - 0xA1) * 94 (uint32_t)(w - 0xA1)) * HZK16_BYTES; memcpy(out, hzk16_font offset, HZK16_BYTES); }这个版本最适合STM32这类直接外挂SPI Flash、或者把字模通过工具链转成C数组的项目。数组方式读取没有文件系统开销在循环刷新大量汉字时优势非常明显。3.3 字符串遍历混合中英文时的编码判断实际显示时字符串里往往中英文混排。遍历时每遇到一个字节要先判断它是不是ASCII字符再决定按1字节还是2字节处理。void draw_string(const char *str) { const uint8_t *p (const uint8_t *)str; while (*p) { if (*p 0x80) { // ASCII字符读ASC字库 uint8_t asc_buf[ASC16_BYTES]; get_asc16(*p, asc_buf); draw_asc16(asc_buf); p; } else { // 汉字双字节读HZK字库 uint8_t hz_buf[HZK16_BYTES]; uint8_t q p[0]; uint8_t w p[1]; get_hzk16(q, w, hz_buf); draw_hzk16(hz_buf); p 2; } } }这里有个极其容易踩的C语言坑char类型在不加说明时默认是有符号的。如果直接用char指针判断*p 0x80高字节像0xC4会被当成负数判断结果仍然正确但如果你把字节直接参与区位计算负数的符号扩展会让偏移变成天文数字。一定要用uint8_t指针或者每次强转uint8_t再参与计算。3.4 验证字模先在PC上把点阵打印出来字模读出来对不对不要直接上屏先在PC上打印出来看。写一个极简的打印函数传到PC串口或者本地跑一下能直观看到字形void show_hzk16(const uint8_t *buf) { for (int row 0; row 16; row) { for (int col 0; col 16; col) { // 横向取模第row行第col列 if (buf[row * 2 col / 8] (0x80 (col % 8))) { putchar(#); } else { putchar(.); } } putchar(\n); } }只要这个打印能还原出完整的字形说明偏移和取模方向都没问题接下来上屏就算扫向不匹配也是肉眼可查的镜像或颠倒而不是无从下手的乱码。我调字库时每次必先做这一步能省掉一半调试时间。4. 我踩过的坑乱码、错位和找不到字4.1 源码编码不对UTF-8取出来的“汉字”是三个字节这是新手问得最多的问题之一。单片机工程在Keil、IAR里写你好编译器默认按GB2312/GBK存储字符串里就是两个字节“C4 E3”、“BA C3”上面代码直接可用。但从上位机、手机App、网络接口收到的中文字符串绝大多数是UTF-8编码一个小汉字在UTF-8里占3个字节比如“你”是“E4 BD A0”。直接把这三个字节当成GB2312区位码去读字库会得到完全不相关的字模。解决办法在PC端发送前用工具转好或在下位机做一次UTF-8到GB2312的转换。调试阶段最省事的办法就是串口助手里把发送编码改成GBK别用UTF-8。如果一定要支持UTF-8输入需要引入转换表或者特定的转换代码那是另一个话题这里不展开。4.2 偏移公式踩雷多减0xA1、文件被截断、符号区没算偏移公式看起来简单实战里至少有三类错法。一是把区号位号直接套公式忘了减0xA1。有人说区号16区开始减0xA1高位读出来0xB0就减0xB0这取决于字库文件是否含符号区。最通用、最不容易错的就是按GB2312标准区位顺序高字节、低字节统一减0xA1再乘以94加位号。二是文件被截断。网上能找到的HZK16来源五花八门有的文件缺了一部分有些汉字区偏移越过了文件末尾。fread返回的字节数小于预期时说明这个字库文件不完整别继续往下调了先换一个可靠的字库源。三是符号区没算。全字库里1~9区是标点符号和数字10~15区是空区16区开始才是汉字。如果你只需要中文按16区起算的简化公式可能没问题但如果要显示标点、全角符号偏移就不能按汉字区单独算必须走标准的GB2312全区公式。4.3 扫描方向不匹配字会镜像、上下颠倒、花掉即便字模读对了屏幕上依然可能出现三种典型症状字左右镜像、上下颠倒、整体撕裂成斜的。这些通常不是字库问题而是数据排列方式和扫描方向不匹配。排查顺序建议是这样先看打印出来的ASCII图形是否正常正常就说明字库读取没问题再上屏如果镜像把每行字节的位序反过来试试如果上下颠倒把字模按行逆序送如果一列一列乱大概率是横向数据按纵向屏刷了用前面给的转换函数转成你的屏幕对应的取模方式。这步排查完全靠经验和肉眼对比所以项目里最好写一个专用的字模调试页能随时切换横向、纵向、反向几组参数屏上直接对比效果。这个调试页初期看起来多余实际能帮你把“莫名其妙的乱码”快速定位成“方向不对”强烈建议保留。5. 工程落地建议选型、裁剪与存储5.1 不同尺寸字库适合什么样应用选字库尺寸除了看字号还得看像素密度和观看距离。HZK12、HZK16适合小尺寸LCD、OLED屏比如0.96寸OLED、12864这类字号小、存储压力小字库还能塞进片内Flash。HZK24、HZK32适合LED点阵屏、TFT大屏近距离看字形边缘比较平滑。HZK40、HZK48一般用在户外LED显示屏、灯板这类远距离观看的大字场景再配合高密度灯珠才有效果。一句话字库尺寸不是越大越好要让点阵尺寸和实际物理显示尺寸匹配否则要么字太小看不清要么资源白白浪费。5.2 字库裁剪从276KB到几十KB的常用做法如果只是显示固定菜单、固定提示语完全没必要带整库。我做过一个项目只显示30多个指定汉字用全量HZK16白白占掉276KB后来把需要显示的汉字去重后算下来只有不到3KB字模。做法很简单把项目中所有可能出现的中文文本收集到一个文本文件里去重后按GB2312编码排序在PC上用脚本逐个读取字模输出成一个紧凑的二进制文件同时生成一个索引表。运行时用索引差值或二分查找定位字模。这样字库占用能缩减到原来的十分之一甚至更少代价只是代码里多几十行索引逻辑。如果要支持用户输入任意汉字那就别裁剪了老老实实按场景选整库尺寸。5.3 性能优化别让每个字都去fseek用文件系统读字库每读一个字都做一次fseek加fread在SD卡上频繁寻道是很慢的尤其在整屏刷几十个汉字时帧率会被拉得很难看。工程上常用两种优化思路一是按行缓存先把一屏所有字符的偏移算出来一次性读一批字模到RAM再统一上屏二是把字库从SD卡拷贝到外部SPI Flash或内部Flash用内存映射或直接从Flash地址读取。后者的随机读取性能通常远高于文件系统而且不依赖FATFS这类文件系统组件系统更稳定。另外如果你用文件系统且字库文件较大打开文件后建议保持句柄不关避免反复open/close带来的开销。很多文件系统的open操作本身就很费时。最后再分享一个我个人的习惯不管字库文件是网上下的还是工具生成的拿到手先写几分钟的校验代码读取几个已知字符的ASCII打印图确认格式再往项目里集成。这一步看起来多花时间实际上每次都能提前暴露一批编码、偏移、取模方向的问题。字库这东西坑不深但错了就是整屏乱闪提前校验永远比上了屏再排查划算。本文还有配套的精品资源点击获取
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
