C#实现点阵屏取模工具：从HZK16字库到字节数组导出的完整指南

简介：使用C#编写的点阵屏与液晶汉字取模工具，面向嵌入式、物联网开发者及硬件工程师，解决将汉字转换为适配点阵屏和液晶模块的像素数据时重复制表、手工拼接的痛点，适合8x8/16x16点阵以及不同字库定制场景。压缩包共46个文件，约2.95MB，内容兼顾完整源码与成品程序：10个cs文件构成取模主逻辑和界面，resx/resources保存窗体资源，另有可直接运行的exe与pdb调试文件；hzk16、hzk24f等多套字库覆盖宋体、黑体、楷体等常见字体字号，便于对照生成不同点阵格式。已有758人学习下载。工具围绕C#图形处理、汉字编码转换、点阵预览和文件保存展开，既提供可修改的工程与窗体设计，也附带多款字模文件，能直接嵌入硬件项目或继续二次开发，有效提升显示数据准备效率。

1. 点阵屏取模工具：为什么我最后用C#自己写了一个

做点阵屏和液晶显示项目时,最磨人的不是写驱动,而是把汉字变成能塞进单片机Flash里的字节数组。拿16x16的汉字来说,一排排像素点要按特定顺序转成32个字节,横着取、竖着取、高位在前、低位在前,不同屏幕驱动还各有一套规矩。市面上的取模工具我用了不少,要么只能导固定格式,要么换个字号重新点半天,批量导出更是奢望。后来我用C#写了一个本地点阵屏和液晶取模工具,把字库文件读取、系统字体渲染、位图转点阵三条路径统一收进一个WinForm界面里,生成的C数组能直接拷进STM32、51或者Arduino工程。它解决的是从“汉字、图片到数组”的最后一公里,适合做LED点阵屏、OLED、LCD的嵌入式开发者,也适合要在上位机里批量生成字模数据的人。

2. 取模的三种原理路线：HZK16字库、系统字体渲染与位图转点阵

2.1 汉字字模的本质：32字节背后是256个开关

所有取模工具的底层都绕不开一个事实:对单片机来说,汉字不是一个字形,而是一串有顺序的bit。16x16点阵意味着16行乘16列,共256个像素点,每个像素只有“亮、灭”两种状态,刚好用256个bit描述,换算过来就是32字节。这32字节怎么排,完全取决于屏的扫描方式。

最常见的组织方式是“横向逐行”:第0行的16个点拆成两个字节,第一个字节管左8个点,第二个字节管右8个点,然后换下一行。另一种是“纵向逐列”:第0列的16个点拆成两个字节,第一个字节管上8个点,第二个字节管下8个点。像SSD1306这类OLED驱动芯片,GRAM的寻址方式偏纵向,而很多LED点阵屏的移位寄存器扫描偏横向,所以同一个汉字在同一块屏上,取模方式选错了,显示出来的笔画就会乱。

工具的设计思路很简单:先把任何来源的字符转成一个二维布尔矩阵,这一步把字体、字号、粗细全部统一成“哪些位置有点”;再做方向编排,按屏的要求把矩阵打包成字节。只要这两层分离,不管是HZK16字库、TrueType字体还是图片,后面都能共用同一套导出逻辑。

2.2 路线一：HZK16字库文件读取与区位码偏移

HZK16是嵌入式里最常见的16x16汉字点阵字库,每个汉字固定32字节,文件大小约256KB。它的字模按GB2312区位码顺序排列,所以读取的关键是偏移计算。在C#里,我先把字符转成GB2312编码拿到两个字节,第一个字节是区码,第二个字节是位码,然后套公式定位文件的字节偏移。

// 从HZK16字库中读取一个汉字的32字节字模 static byte[] GetGlyphFromHZK16(string hzkPath, char ch) { // HZK16按GB2312区位码排布,每个字模32字节 byte[] gb = Encoding.GetEncoding("GB2312").GetBytes(ch.ToString()); int qu = gb[0] - 0xA1; // 区码 int wei = gb[1] - 0xA1; // 位码 long offset = (qu * 94 + wei) * 32; // 区位码转文件偏移 using (FileStream fs = File.OpenRead(hzkPath)) { byte[] buf = new byte[32]; fs.Seek(offset, SeekOrigin.Begin); fs.Read(buf, 0, 32); return buf; } }

参数含义:qu是区码相对0xA1的偏移,wei是位码相对0xA1的偏移,GB2312每区固定94个字符,所以字模在文件里的位置是((区偏移乘94)加位偏移)再乘每个字模的32字节。这个乘法顺序很容易写错,常见反例是把94和32的位置对调,结果就是所有汉字都错位两三个字符。

注意:HZK16只覆盖GB2312汉字区,生僻字、特殊符号取不到。工具里遇到取不到的字,会降级到系统字体渲染路线。

2.3 路线二：系统字体渲染,TrueType字体也能取模

HZK16的局限很明显:只能用固定字号,只能取宋体风格的黑白点阵。所以我给工具加了第二条路线——用Windows的字体渲染引擎把汉字画到位图上,再转成点阵。这样任意字体、任意字号、加粗、斜体、反白都能直接取。

// 用系统字体把字符渲染到Bitmap上,供后续像素采集 static Bitmap RenderCharToBitmap(char ch, Font font) { // 先用MeasureText量出实际绘制尺寸,避免画布过大或过小 Size sz = TextRenderer.MeasureText(ch.ToString(), font); Bitmap bmp = new Bitmap(sz.Width, sz.Height, PixelFormat.Format24bppRgb); using (Graphics g = Graphics.FromImage(bmp)) { g.Clear(Color.White); TextRenderer.DrawText(g, ch.ToString(), font, new Point(0, 0), Color.Black, Color.White, TextFormatFlags.NoPadding); } return bmp; }

这里最容易被坑的地方是画布尺寸:直接用font.Height当画布高度,实际上等于把行高当成了字高,而TrueType字体的行高里包含内部留白和行间距,画出来的字会被顶部留白压低,上边缘缺笔画。所以我先用TextRenderer.MeasureText量出实际笔画范围,再按这个尺寸建画布,取模之前还可以做一次“裁边”,把四周全白的行和列剪掉,生成的字模更紧凑。

2.4 路线三：位图转点阵,图形和图标也能取

工具里第三条路线是图片转点阵。这个功能在显示小型图标、开机Logo或者量表符号时特别有用。我一般把目标图片加载后先缩放成8的倍数的尺寸,再做灰度化和二值化,然后进入和文字一样的像素采集流程。

缩放这一步有个细节:普通Graphics.DrawImage缩放的抗锯齿会引入大量灰色像素,二值化时容易让笔画边缘长出毛刺。我在工具里用的方式是先缩放到目标尺寸的两倍,二值化后再用最近邻算法缩到最终尺寸,这样做出来的点阵边缘干净得多。换句话说,先缩小再二值化不如先二值化再缩小,这是我从几次图标取模的翻车里总结出来的。

3. C#取模引擎核心实现：从区位码偏移到点阵字节打包

3.1 编码解析不能想当然：GB2312、GBK与Unicode的差值

很多人在C#里取汉字编码,习惯直接Encoding.Default,这在现代Windows上默认是GBK或者UTF-8,很容易出现两个不同的字落进同一个字模位置的情况。工具里锁死用GB2312编码解析,因为HZK16字库的排序就是按GB2312来的。另一个容易踩的坑是偏移量公式里的基数:有些人记成了“(区号-0xA0)*94”,实际上GB2312区位码从1开始,在计算机里存的时候是从0xA1开始的,所以必须先减0xA1。差了这1,单个字模的偏移只错32字节,但批量取几十个字时,偏差会累积成整片乱码。

// 编码解析入口:统一走GB2312,字符转区位码 static (int qu, int wei) GetQuWei(char ch) { byte[] gb = Encoding.GetEncoding("GB2312").GetBytes(ch.ToString()); if (gb.Length != 2) throw new ArgumentException("当前字符不在GB2312范围内"); return (gb[0] - 0xA1, gb[1] - 0xA1); }

这里返回的qu和wei已经减掉了0xA1,后续直接参与偏移计算,不需要再到公式里减一次。把减法和偏移拆开,代码阅读起来清楚,也方便复用。如果你在.NET Core或者.NET 5+环境里跑这段代码,还需要先调用Encoding.RegisterProvider(CodePagesEncodingProvider.Instance),否则GetEncoding("GB2312")会直接抛异常,这个在第5章避坑里再细说。

3.2 像素采集：GetPixel虽然直观,但LockBits才是正解

用系统字体渲染出Bitmap之后,最直接的做法是两层循环调Bitmap.GetPixel(x, y),一行行判断颜色。这个写法逻辑上没错,但性能非常差,一个16x16的字符要调256次,取100个字就是25600次GDI调用,在WinForm里能明显感觉到卡顿。

实际工具里我用的是LockBits把位图内存锁住,一次性拷到托管数组,再直接按偏移量读像素。每个像素在24bpp格式下占3字节,BGR排列,灰度值取三者均值,再和阈值比较。

// LockBits批量读取像素,数据量大时比GetPixel快一个数量级 static bool[,] BitmapToMatrix(Bitmap bmp, int threshold = 128) { bool[,] matrix = new bool[bmp.Height, bmp.Width]; BitmapData data = bmp.LockBits( new Rectangle(0, 0, bmp.Width, bmp.Height), ImageLockMode.ReadOnly, PixelFormat.Format24bppRgb); byte[] buffer = new byte[data.Stride * data.Height]; Marshal.Copy(data.Scan0, buffer, 0, buffer.Length); for (int y = 0; y < bmp.Height; y++) { // 注意这里用Stride而不是Width*3,因为行尾有对齐填充 int rowBase = y * data.Stride; for (int x = 0; x < bmp.Width; x++) { int idx = rowBase + x * 3; int gray = (buffer[idx] + buffer[idx + 1] + buffer[idx + 2]) / 3; matrix[y, x] = gray < threshold; } } bmp.UnlockBits(data); return matrix; }

关键参数是data.Stride:位图每一行占用的字节数不一定是Width * 3,因为Windows位图默认把每行按4字节对齐,所以Stride往往比实际像素数据多几个字节。刚转过来的人最容易在这里栽跟头,直接拿x * Width * 3去寻址,最后取出来的点阵每隔几行就错位一次,表现就是字符中段出现一条斜着的断痕。threshold控制二值化的敏感度,默认128,字库字模建议保持在100到160之间,太低会把浅色噪声也算成点。

3.3 字节打包的四种模式：方向、位序组合成一个参数矩阵

拿到布尔矩阵之后,接下来是工具里最核心的一段逻辑:把二维矩阵按不同的方向和位序打成字节数组。“横向逐行、高位在前”是大多数51单片机点阵屏项目的默认方式,而“纵向逐列、高位在前”更接近OLED驱动IC的GRAM组织。这四个参数组合成一张小表,工具里全部做成下拉框,选完立即刷新预览。

代码实现上,我用一个bool[,]矩阵加方向枚举,循环里按源坐标和目标字节位之间的映射关系写入。

// 横向逐行打包:每8个像素合成一个字节,MSB先发 static byte[] PackHorizontal(bool[,] m, int width, int height) { int bytesPerRow = width / 8; // 宽度要求8的倍数 byte[] result = new byte[bytesPerRow * height]; for (int y = 0; y < height; y++) { for (int x = 0; x < width; x++) { int byteIdx = y * bytesPerRow + x / 8; int bitIdx = x % 8; if (m[y, x]) result[byteIdx] |= (byte)(0x80 >> bitIdx); // 高位在前 } } return result; }

这段代码的映射逻辑是:同一行的x坐标除以8决定落在第几个字节,x对8取余决定字节内的bit位。0x80 >> bitIdx把最高位对应每行最左边的像素,这是MSB先发的标准做法。如果你要LSB先发,只要改成(byte)(1 << bitIdx),一行代码的差别,但显示效果是镜像反转加位序错乱,排查起来相当费劲。

提示:工具的预览区在切换方向后立即重绘点阵,这个即时反馈能省掉大量實机调试时间。我一般先在预览里看笔画是否连贯,再拷到屏上去。

3.4 批量导出：多字一次生成C头文件

单个字取模没什么难度,真正的效率提升在批量。工具里我加了一个文本框,可以直接输入整串汉字,回车后逐个取模,生成一个完整的C头文件。

// 批量生成C语言字模数组,直接输出到.h文件 static string GenerateCHeader(List<byte[]> glyphs, int bytesPerChar) { StringBuilder sb = new StringBuilder(); sb.AppendLine("#ifndef FONT_DATA_H"); sb.AppendLine("#define FONT_DATA_H"); sb.AppendLine("#include <stdint.h>"); sb.AppendLine(); int idx = 0; foreach (byte[] g in glyphs) { // 注释里写上索引对应的字符,便于上屏时按序号取模 sb.AppendLine($"// [{idx++}] {g.Length / bytesPerChar} bytes"); sb.Append("const uint8_t font_").Append(idx).Append("[] = {"); for (int i = 0; i < g.Length; i++) { if (i % 8 == 0) sb.AppendLine(); sb.Append("0x").Append(g[i].ToString("X2")).Append(", "); } sb.AppendLine("};"); sb.AppendLine(); } sb.AppendLine("#endif"); return sb.ToString(); }

这里我故意在每个数组后面留了注释,标明字符序号和字节数,上屏时一旦发现某个字位置不对,可以快速定位是哪个序号出了问题。写嵌入式代码的人都有过这种经历——字模数组一大坨,全靠肉眼数逗号来找第几个字,有了注释定位快得多。

4. WinForm界面与导出参数：点阵方向、位序与批量C数组生成

4.1 界面三区联动：文字输入、参数区、预览区相互驱动

工具的主界面是经典的WinForm三栏布局。左侧是文字输入区,中间是参数区,右侧是实时预览。左侧输入什么,中间切什么字号,右侧立即渲染出对应的点阵预览图。我特意把“取模方向”和“位序”这两个参数放在最显眼的位置,因为绝大多数上屏错误都源于这两个选项没配对。

右侧预览区是一个双缓冲的自定义控件,把bool矩阵按小方块绘制出来。它不是一个装饰性的画布:点击预览区里的一个点,可以手动翻转该点的状态,这个功能在修补HZK16里个别笔画模糊的字时很实用。翻转之后,字节数组会同步更新,不用重新取模。

4.2 参数配置：字号、加粗、反白、裁边与扫描方向

参数区里值得讲的是几个细节配置项。“裁边”选项会自动检测矩阵四周全白的行列并去掉,这能显著压缩字节数。比如一个16x16的汉字实际笔画可能只占12行,裁掉上下空行后,每个字的字节数从32变成24,二十个字的字库能省下160字节,虽然不多,但在Flash紧张的芯片上很有意义。

“反白”选项把亮的像素全翻转为暗的,适用于OLED屏上常见的白字黑底显示方式,免去在单片机里再做一次异或运算。“加粗”在系统字体渲染路线下就是简单地在水平方向把每个点的左右邻居也点亮,虽然比不上专门的粗体算法精细,但应付8x8或者16x16的小字库足够了。扫描方式的选择项和第三章的表格一一对应,切换之后预览区直接变形,做到所见即所得。

4.3 导出格式与批量生成：C数组、BIN裸数据与仿真格式

导出格式在工具里分成三种。第一种是C语言头文件,前面生成的格式,适合直接包含进单片机工程;第二种是BIN裸数据,把所有字模按顺序拼接成一个二进制文件,适合通过烧录器写到外部Flash,或者放到SD卡里由单片机按偏移读取;第三种是文本文件,每字节一行,用逗号分隔,方便喂给Proteus仿真里的数据存储器模块。

// 导出BIN裸数据:字模按输入顺序首尾相接 static void ExportBin(IEnumerable<byte[]> glyphs, string outPath) { using (FileStream fs = new FileStream(outPath, FileMode.Create)) using (BinaryWriter bw = new BinaryWriter(fs)) { foreach (byte[] g in glyphs) bw.Write(g); // 顺序写入,单片机按固定偏移寻址 } }

BIN格式的寻址规则是:第N个字符的数据起始位置是N乘以单字字节数。所以导出BIN时,我在工具里会同步生成一个文本索引文件,列出每个字的偏移量,这样单片机端的字库加载函数不用扫描,直接查表。

5. 取模工具避坑指南：字节序反、扫描方向错、字库偏移算歪的血泪经验

5.1 汉字左右镜像,笔画完全反了

现象:用HZK16读出来的字在点阵屏上整体左右反转,像照镜子一样。

原因:镜像是典型的扫描方向反了。更具体地说,横向取模时,数据是从左读还是从右读,决定了镜像方向。如果代码里用了高字节在前,但屏驱动的高位对应的是最右边的像素,那么字节内的顺序就会反过来。另一个常见做法是把0x80移位写成了向低位移动,比如0x80 >> bitIdx被写成0x80 << bitIdx,这在bitIdx为0时看不出来,一旦bitIdx大于0就全乱。

解决:在工具的预览区把字模渲染出来,和源码字库的样式对比。先判断是水平镜像还是垂直镜像,再决定是调整“方向”还是“位序”。水平镜像改位序,垂直镜像改方向,两个都错就一起调。我从这两个参数里学到的教训是:先改一个,生效后看另一个,不要同时改,否则根本不知道是哪个参数起作用。

5.2 字模上边缘被吃掉,笔画顶到画布边界

现象:用系统字体取16x16字模,生成的点阵上半部分缺一两行笔画,下半部分正常。

原因:画布高度直接用了font.Height,而font.Height是行高,包含内部空白,TextRenderer.DrawText绘制时把字形放在行高的内部顶部,于是上半部分留白被当成有效行,实际笔画挤出了画布上边界。

解决:前面写的MeasureText方案,量出实际文本尺寸后按这个尺寸建画布。注意MeasureText的结果在不同字体下会有细微差别,我还加了TextFormatFlags.NoPadding去掉默认的填充边距。如果个别字符量出来尺寸是0(比如空格),工具里会强制给一个最小尺寸,否则Bitmap构造函数直接抛异常。

5.3 批量导出时第一个字正常,后面全是乱码

现象:输入五个字,第一个字的字模完全正确,从第二个开始字节内容随机错乱。

原因:这是典型的FileStream共享读取问题。我第一次写的代码在循环外面打开HZK16文件,循环里调用ReadBytes(32),但没注意内部缓冲区的Position不会自动重置。连续读取时,位置一路向后偏移,读取结果自然不对。如果在循环里每次新建FileStream,第一个字正常,后面的字也正常,只是频繁开关文件有点浪费性能。

解决:我后来统一改成“先读整个字库文件到内存,再在内存数组上按偏移取32字节”。这样既避免了文件句柄的反复开关,也不会出现流位置错乱。工具里如果碰到大文件,比如24x24字库,也沿用这个方案,内存占用完全可接受。

// 把整个字库读入内存,后续只做数组偏移 static byte[] LoadHZK(string path, int glyphSize) { byte[] data = File.ReadAllBytes(path); if (data.Length % glyphSize != 0) throw new InvalidDataException("字库文件长度与单字字节数不匹配"); return data; }

5.4 .NET Core环境下取GB2312编码直接抛异常

现象:把工具源码迁移到.NET Core或.NET 5+环境,第一次调用Encoding.GetEncoding("GB2312")就报“不支持的编码”。

原因:.NET Core默认不加载GB2312代码页,因为这套编码不在基础代码页集合里。WinForm工具如果用.NET Framework 4.x编译没有这个问题,但换成新版运行时就会踩中。

解决:启动入口处注册CodePagesEncodingProvider。一行代码解决,但要放在任何GetEncoding调用之前,否则无效。

// 必须在解析GB2312之前注册代码页提供程序 Encoding.RegisterProvider(CodePagesEncodingProvider.Instance);

5.5 OLED屏和LED屏同样的字模,一个正常一个歪

现象:同一个16x16汉字数组,在LED点阵屏上显示正常,换到OLED屏上笔画断裂,竖排汉字尤其明显。

原因:OLED驱动芯片的GRAM是列寻址,内部数据排列方式和LED屏的行扫描完全不同。SSD1306的每一页有128个字节,每个字节对应一列里的8个像素,所以要想让OLED正常显示,取模方向必须改成纵向逐列,而不是LED屏常用的横向逐行。

解决:工具里“扫描方式”参数提供了完整的方向选择。我在参数组里还会记住上一次使用的组合,给不同项目分别存预设。换屏时从下拉框直接切换,预览区会立刻显示出OLED那种竖条状的存储结构里字模应该长什么样。从此我拿到一块新屏,第一件事就是查驱动手册的显示RAM寻址图,确认是行扫描还是列扫描,再决定取模方向。

6. 上屏前的最后一道工序：反解预览与批量自动化验证

6.1 反解预览:把字节数组还原成点阵图像

工具里有一个很实用的“反解”功能:粘贴一段C语言形式的字节数组,工具按照你选择的取模方向和位序,把它还原成一张位图。这是验证字模格式对不对的最快手段,不用编译单片机程序、不用接屏,直接在电脑上看结果。

反解时要注意方向必须和取模时完全一致,否则数组里的字节排列顺序和绘图时的扫描顺序对不上。我在工具里会把方向和位序两个参数一起记录在导出文件的头部注释里,这样过几个月再回来改工程,一看注释就知道当时的配置。经验是:就算代码里看不出方向,注释里也一定要写,这个习惯救了我不少次。

6.2 命令行批量验证与构建脚本集成

如果只是偶尔取几个字,图形界面就够了。但我在做项目时需要一次性生成几十个字符的字库,而且希望能自动化验证,于是给工具加了一个命令行入口:

DotMatrixTool -font simhei.ttf -size 16 -mode vertical -msb "电力参数采集系统" -out font_data.h

命令行参数里的-mode vertical指定纵向取模,-msb表示高位在前,后面的汉字串可以自由替换。每次构建固件前,我在批处理脚本里先跑一次这个命令,生成字库头文件,再用反解模式校验一下输出数组包含的字节数是否等于汉字个数的整数倍。数量对不上,说明中间有符号超出了GB2312范围,构建脚本直接报错退出。

从那以后,我每次做点阵屏相关项目都强制走一遍“生成字模、反解预览、实机比对”的流程,不再凭肉眼猜字节序。工具本身也跟着项目迭代了好几个版本,界面和导出格式都是我实际用着顺手的样子。如果你也被取模工具的格式死板、批量困难折腾过,这份用C#写好的完整工程可以直接拿去改,希望帮到你。

本文还有配套的精品资源，点击获取