1. 为什么我会写一个条形码生成器而不是直接装个控件去年做一套进销存系统的时候仓库那边提了个需求所有物料需要打上条形码贴纸方便扫码枪扫描入库。当时我的第一反应是——这还不简单NuGet 上搜 Barcode装个第三方库一分钟搞定。结果装满三个库之后才发现要么是商业授权收费要么是依赖太重、文档稀烂还有个货在 .NET Framework 4.7.2 环境下直接编译不过。就在这时我看到用户提供的热搜词里出现了“抖音核销票 c#”、“c# 上位机开发”这类词一下子就有了代入感——很多人做 C# WinForms 不是在做花哨的互联网应用而是在做工具型软件仓库管理、会员核销、生产扫码、票据打印。这类软件有一个共性需求需要在本地生成条形码并且要把条形码打成物理贴纸。而大多数人的做法要么是在网上找在线生成器然后截图要么装一堆杀鸡用牛刀的重型依赖。于是我自己花了一个周末用纯 WinForms 加上 GDI 写了一个轻量级条形码生成器没有引用任何第三方条形码 SDK核心绘制代码全部自己控制。带保存 PNG/JPG 功能带 PrintPreviewDialog 打印预览发布出来只有一个 exe体积 200KB 出头。这篇文章就把完整的实现思路、踩坑过程、以及打印精确布局的细节全部分享出来。如果你是做 C# WinForms 的尤其是处理上位机、仓库、核销这类工具型软件这篇文章应该能帮你省下不少折腾时间。2. 条形码类型选型为什么单选 Code 128在动手写代码之前必须先确定一个事情生成哪种条形码这不是拍脑袋选的条形码的编码规则决定了扫描识别的成功率、条码长度、字符集支持选错了后面全白搭。2.1 几种常见条码的区别条码类型字符集长度典型场景优缺点Code 39大写字母数字部分符号可变工业、资产管理实现简单但密度低、条很长EAN-1313位纯数字固定零售商品必须用国际前缀不适合内部编码Code 128ASCII 全字符集可变长物流、仓储、内部管理信息密度高条码短适合标签打印QR Code任意文本可变移动端核销扫码角度要求低但需要图像库支持我的场景是仓库物料标签物料编码里既有数字又有字母偶尔还有连字符那么第一排除 EAN-13因为它只支持纯数字且固定 13 位。Code 39 也能做但用同样的编码内容打出来Code 39 的物理长度约为 Code 128 的 1.5 倍左右——在 40mm 宽的小标签上这差距很致命。Code 128 在同等信息量下条码最短而且支持完整的 ASCII 字符集对物料编码来说最理想。所以最终确定Code 128 编码字符集选 Code 128 B支持大写、小写、数字和绝大多数可见字符。2.2 关于 QR Code 的热搜词联想热搜词里有“抖音核销票 c#”这让我想起不少朋友做核销系统时纠结要不要上二维码。说实话如果清单码一维条码够用就坚决用一维条码。二维码看起来很“先进”但它有两个问题第一需要引第三方库生成码图比如 QRCoder违背了我这个项目零依赖的目标第二仓库场景的扫码枪如果配置得当一维激光枪对 Code 128 的识别速度和成功率远高于摄像头扫码器对二维码的识别。核销场景如果只是票号Code 128 完全能扛住。3. Code 128 编码原理与纯 C# 绘制实现这节是整个项目的核心也是我踩坑最多的地方。先说清楚 Code 128 的编码规则再给完整代码最后讲 GDI 绘制的关键细节。3.1 Code 128 的编码机制不是简单画粗细线很多人以为条形码就是把二进制 0 和 1 映射成黑白条实际上 Code 128 的编码要复杂得多。Code 128 的每个字符由11 个模块module组成这 11 个模块被划分成3 个条bar和 3 个空space交替排列。每个条或空的宽度可以是 1 到 4 个模块。这带来两个关键问题第一必须正确计算每个字符对应的模块宽度序列第二必须生成校验位。Code 128 的编码表有 107 个符号分 A、B、C 三种字符集。B 字符集覆盖 ASCII 32 到 127这正是我们需要的。每个字符的编码数据由查表得到但最容易被忽略的是——开始符、校验符和结束符。开始符表示从哪个字符集开始编码Code 128 B 的开始符值是 104校验符所有字符包括开始符的加权和模 103结束符固定值 106它有特殊的 13 模块结构校验位的计算公式是校验值 (开始符值 Σ(字符值 × 位置索引)) % 103其中位置索引从 1 开始计数第一个数据字符的索引是 1。注意校验计算是针对“值”的运算不是字符本身。举个例子要编码字符串ABC开始符值 104A 的值 65位置索引 1B 的值 66位置索引 2C 的值 67位置索引 3校验和 104 65×1 66×2 67×3 104 65 132 201 502校验值 502 % 103 90然后编码序列就是开始符(104)、A(65)、B(66)、C(67)、校验符(90)、结束符(106)。3.2 查表数据的组织方式Code 128 官方标准里给出了每个值对应的模块宽度模式但我没有在代码里硬编码那 107 条数据——那样代码太长且容易抄错。我用了另一种方式通过一个字符串字典来维护编码表键是字符的值值是 6 个数字组成的模式串分别表示 bar、space、bar、space、bar、space 的模块数。private static readonly Dictionaryint, string Code128Patterns new Dictionaryint, string { {0, 212222}, {1, 222122}, {2, 222221}, {3, 121223}, {4, 121322}, {5, 131222}, {6, 122213}, {7, 122312}, {8, 132212}, {9, 221213}, {10, 221312}, {11, 231212}, {12, 112232}, {13, 122132}, {14, 122231}, {15, 113222}, {16, 123122}, {17, 123221}, {18, 223211}, {19, 221132}, {20, 221231}, {21, 213212}, {22, 223112}, {23, 312131}, {24, 311222}, {25, 321122}, {26, 321221}, {27, 312212}, {28, 322112}, {29, 322211}, {30, 212123}, {31, 212321}, {32, 232121}, {33, 111323}, {34, 131123}, {35, 131321}, {36, 112313}, {37, 132113}, {38, 132311}, {39, 211313}, {40, 231113}, {41, 231311}, {42, 112133}, {43, 112331}, {44, 132131}, {45, 113123}, {46, 113321}, {47, 133121}, {48, 313121}, {49, 211331}, {50, 231131}, {51, 213113}, {52, 213311}, {53, 213131}, {54, 311123}, {55, 311321}, {56, 331121}, {57, 312113}, {58, 312311}, {59, 332111}, {60, 314111}, {61, 221411}, {62, 431111}, {63, 111224}, {64, 111422}, {65, 121124}, {66, 121421}, {67, 141122}, {68, 141221}, {69, 112214}, {70, 112412}, {71, 122114}, {72, 122411}, {73, 142112}, {74, 142211}, {75, 241211}, {76, 221114}, {77, 413111}, {78, 241112}, {79, 134111}, {80, 111242}, {81, 121142}, {82, 121241}, {83, 114212}, {84, 124112}, {85, 124211}, {86, 411212}, {87, 421112}, {88, 421211}, {89, 212141}, {90, 214121}, {91, 412121}, {92, 111143}, {93, 111341}, {94, 131141}, {95, 114113}, {96, 114311}, {97, 411113}, {98, 411311}, {99, 113141}, {100, 114131}, {101, 311141}, {102, 411131}, {103, 211412}, // Start A {104, 211214}, // Start B {105, 211232}, // Start C {106, 2331112} // Stop };这里211214就是 Code 128 B 开始符的模式意思是第 1 条黑条 2 个模块宽第 1 个白空 1 个模块宽第 2 条黑条 1 个模块宽第 2 个白空 2 个模块宽第 3 条黑条 1 个模块宽第 3 个白空 4 个模块宽。结束符是 7 个数字因为它的结构特殊比普通字符多了一个条。3.3 生成模块序列的核心函数有了编码表生成模块序列就是顺理成章的事public static Listint GetCode128BModuleSequence(string input) { var result new Listint(); // 1. 加入开始符Code 128 B AddPattern(result, 104); // 2. 加入数据字符 foreach (char c in input) { if (c 32 || c 126) throw new ArgumentException($字符 {c} 不在 Code 128 B 可编码范围内); AddPattern(result, c); } // 3. 计算校验位 int checksum 104; // 开始符值 for (int i 0; i input.Length; i) { checksum input[i] * (i 1); } checksum % 103; AddPattern(result, checksum); // 4. 加入结束符 AddPattern(result, 106); return result; } private static void AddPattern(Listint target, int codeValue) { string pattern Code128Patterns[codeValue]; foreach (char digit in pattern) { target.Add(digit - 0); } }这段代码的核心思想是把每个字符展开成模块宽度的数字序列最后整个条码就是一堆数字的连续序列。比如序列开头是2 1 1 2 1 4就表示从最左边开始画 2 模块宽的黑条留 1 模块宽的白空画 1 模块宽的黑条留 2 模块宽的白空画 1 模块宽的黑条留 4 模块宽的白空。注意AddPattern函数里target.Add(digit - 0)是把字符数字转换成整数。这种查表方式比逐个判断if/else要干净得多后续如果要支持 Code 128 A 或 C只需要把开始符改成 103 或 105加一个字符集切换逻辑即可。3.4 GDI 绘制条形码位图模块序列有了绘制就变得非常简单了。这里的核心决策是X 轴的像素计算public Bitmap RenderBarcode(string input, int moduleWidth 2, int height 60) { var modules GetCode128BModuleSequence(input); int totalModules modules.Sum(); int pixelWidth totalModules * moduleWidth; var bmp new Bitmap(pixelWidth, height); using (var g Graphics.FromImage(bmp)) { g.Clear(Color.White); int x 0; bool isBar true; // Code 128 总是从条开始 foreach (int moduleCount in modules) { int width moduleCount * moduleWidth; if (isBar) { g.FillRectangle(Brushes.Black, x, 0, width, height); } x width; isBar !isBar; } } return bmp; }这里有个容易忽略的细节isBar的初始值必须为true因为 Code 128 每个字符的编码模式都从条开始而且字符结束的位置一定是空所以下一个字符又从条开始这个交替关系能一直维持到结束符。如果你从false开始画出来的条码会黑白翻转扫码枪直接扫不出来。3.5 绘制时的问题为什么条码底部要加空白区很多第一次做条码的人只画了条和空没有在条码下方留出足够的空白区域Quiet Zone结果扫码枪频繁识别失败。条码标准要求条码左右两侧各留至少 10 倍模块宽度的空白区底部也要留出足够空间给文字或空白。我的做法是在RenderBarcode生成的位图基础上再包一层留白的逻辑public Bitmap RenderBarcodeWithQuietZone(string input, int moduleWidth 2, int height 60, int quietZoneWidth 10) { var bmp RenderBarcode(input, moduleWidth, height); int quietPixels quietZoneWidth * moduleWidth; var fullBmp new Bitmap(bmp.Width quietPixels * 2, height); using (var g Graphics.FromImage(fullBmp)) { g.Clear(Color.White); g.DrawImage(bmp, quietPixels, 0); } bmp.Dispose(); return fullBmp; }左右各加 10 个模块宽的静区扫码识别的成功率会明显提升。这个细节在我实际测试中非常关键。4. WinForms 界面搭建与保存功能实现画条码的核心逻辑完成后界面部分反而简单。但有几个交互细节值得单独说一说。4.1 界面设计简单直接避免过度设计我用的是最传统的 WinForms 布局顶部一个 TextBox 输入条形码内容一个“生成”按钮中部一个 PictureBox 显示生成的条形码底部一个“保存图片”按钮和一个“打印预览”按钮界面不需要花哨因为使用者是仓库员工不是设计师。但 TextBox 有一个小细节值得注意——限制输入长度。Code 128 B 虽然没有严格长度限制但在标签宽度固定的情况下内容越长条码越密扫码越难。所以我在 TextBox 的KeyPress事件里限制了最多 20 个字符private void txtBarcode_KeyPress(object sender, KeyPressEventArgs e) { if (txtBarcode.Text.Length 20 e.KeyChar ! (char)8) // 8 是 Backspace { e.Handled true; } }4.2 保存功能PNG 格式和分辨率的选择保存功能使用SaveFileDialog这个没什么特别的。真正值得注意的是保存时的像素尺寸。如果直接把 PictureBox 上显示的位图保存分辨率可能不够打印出来发虚。我的做法是private void btnSave_Click(object sender, EventArgs e) { if (_currentBarcode null) { MessageBox.Show(请先生成条形码); return; } using (var saveDialog new SaveFileDialog()) { saveDialog.Filter PNG 图片|*.png|JPEG 图片|*.jpg; saveDialog.FileName $barcode_{txtBarcode.Text}_{DateTime.Now:yyyyMMddHHmmss}.png; if (saveDialog.ShowDialog() DialogResult.OK) { // 生成高分辨率版本方便打印 int highResModuleWidth 4; // 渲染时用更大的模块宽度 int highResHeight _currentBarcodeHeight * 2; using (var highResBmp RenderBarcodeWithQuietZone( txtBarcode.Text, highResModuleWidth, highResHeight)) { if (saveDialog.FilterIndex 1) highResBmp.Save(saveDialog.FileName, ImageFormat.Png); else highResBmp.Save(saveDialog.FileName, ImageFormat.Jpeg); } MessageBox.Show(保存成功); } } }这里有个很实用的经验界面上显示用的位图和保存/打印用的位图应该用不同的渲染参数。界面显示只需要看清楚即可模块宽度 2、高度 60 足够但保存时要考虑后续打印需求所以模块宽度翻倍到 4、高度乘 2这样即使标签打印机驱动做了缩放条码也不会发虚。这也呼应了热搜词里那张“保存视频/保存图片”的痛点——很多工具软件里“保存”出来的资源比屏幕上看到的模糊本质就是没有区分屏幕分辨率和输出分辨率。4.3 生成按钮和界面交互private void btnGenerate_Click(object sender, EventArgs e) { string content txtBarcode.Text.Trim(); if (string.IsNullOrEmpty(content)) { MessageBox.Show(请输入条形码内容); return; } try { _currentBarcode RenderBarcodeWithQuietZone(content, 2, 60); _currentBarcodeHeight 60; picBarcode.Image?.Dispose(); picBarcode.Image _currentBarcode; picBarcode.SizeMode PictureBoxSizeMode.Zoom; } catch (ArgumentException ex) { MessageBox.Show(ex.Message, 输入内容不合法); } }picBarcode.Image?.Dispose()这行代码很重要。WinForms 里如果反复生成新的 Bitmap 赋给 PictureBox.Image而不释放旧对象GDI 句柄会持续增长运行一两天后就会出现“内存不足无法创建位图”的错误这是 WinForms 工具型软件最常见的隐性 bug。5. 打印预览与精确打印布局的关键细节打印预览是用户给的标题里有明确要求的功能也是整个项目里最阴险的部分。很多人以为打印预览就是调用PrintPreviewDialog然后把图片贴到PrintDocument上就完了实际上打印位置对不齐、比例不对的问题都出在这。5.1 PrintDocument 的核心设置private PrintDocument _printDoc new PrintDocument(); private void SetupPrintDocument() { _printDoc.PrinterSettings.PrinterName GetDefaultPrinter(); // 获取默认打印机 _printDoc.DefaultPageSettings.Landscape false; // 竖版标签 // 关键设置可打印区域边距为 0具体边界由我们自己控制 _printDoc.DefaultPageSettings.Margins new Margins(0, 0, 0, 0); _printDoc.PrintPage PrintDoc_PrintPage; }这里面最大的坑是Margins。WinForms 的PrintDocument默认会根据打印机驱动计算可打印区域很多打印机实际可打印区域是四边不等距的比如底部总是留出 5mm 无法打印。如果完全依赖默认值你无法精确控制条码在标签纸上的位置。我的做法是把Margins清零然后在PrintPage事件里用e.PageBounds作为画布原点。5.2 PrintPage 事件里的精确绘制private void PrintDoc_PrintPage(object sender, PrintPageEventArgs e) { if (_currentBarcode null) return; Graphics g e.Graphics; // 先设置高质量插值模式保证打印不模糊 g.InterpolationMode System.Drawing.Drawing2D.InterpolationMode.HighQualityBicubic; // 获取页面边界 Rectangle pageBounds e.PageBounds; // 在页面正中间打印条形码 int barcodeWidth _currentBarcode.Width; int barcodeHeight _currentBarcode.Height; int x (pageBounds.Width - barcodeWidth) / 2; int y (pageBounds.Height - barcodeHeight) / 2 - 10; g.DrawImage(_currentBarcode, x, y, barcodeWidth, barcodeHeight); // 在条码下方打印人眼可读的字符 string humanReadable txtBarcode.Text; using (Font font new Font(Consolas, 22, FontStyle.Regular, GraphicsUnit.Point)) { SizeF textSize g.MeasureString(humanReadable, font); float textX (pageBounds.Width - textSize.Width) / 2; float textY y barcodeHeight 5; g.DrawString(humanReadable, font, Brushes.Black, textX, textY); } }这里我用e.PageBounds而不是e.MarginBounds就是要把坐标系原点直接设在纸张边缘。很多人不知道PageBounds和MarginBounds的区别——前者是整个纸张的边界后者是减去了Margins属性后的可用区域。我在DefaultPageSettings里把边距设为 0 后两者才一致。5.3 打印预览一行代码但前提条件不少WinForms 的打印预览使用起来非常简单private void btnPrintPreview_Click(object sender, EventArgs e) { if (_currentBarcode null) { MessageBox.Show(请先生成条形码); return; } SetupPrintDocument(); using (var preview new PrintPreviewDialog()) { preview.Document _printDoc; preview.StartPosition FormStartPosition.CenterParent; preview.ClientSize new Size(800, 600); preview.ShowDialog(this); } }但这里有个前置条件PrintPage事件里用的_currentBarcode必须存在。所以btnPrintPreview_Click里先做了判空。另外要注意PrintPreviewDialog 不会自动更新 PrintDocument如果你在生成条码之后修改了_printDoc.PrintPage事件的处理逻辑需要重新SetupPrintDocument()。5.4 打印尺寸换算DPI 是罪魁祸首这是整个打印功能里最容易出错的地方。屏幕上的 100px 和打印机上的 100px 不是一回事因为屏幕通常是 96 DPI而打印机的分辨率通常是 300 DPI 甚至 600 DPI。PrintDocument 绘制时使用的坐标系已经由 WinForms 帮我们做了转换但如果你直接从 Bitmap 的像素宽高去打印会出现“打印出来比屏幕上的大/小 3 倍”的问题。解决方法是显式指定打印尺寸// 打印物理尺寸 像素数 / 分辨率 * 25.4单位从像素转毫米 int barcodeWidthMm (int)(_currentBarcode.Width / 96.0 * 25.4); int barcodeHeightMm (int)(_currentBarcode.Height / 96.0 * 25.4); // 换算成打印机的 1/100 英寸单位 int printWidth (int)(barcodeWidthMm / 25.4 * 100); int printHeight (int)(barcodeHeightMm / 25.4 * 100);更简单的做法是直接用Graphics.DrawImageUnscaled或者指定矩形大小// 以 96 DPI 为基准1 英寸 96 像素 int printWidthPixels _currentBarcode.Width; // 相当于 1:1 打印 e.Graphics.DrawImage(_currentBarcode, x, y, printWidthPixels, printHeightPixels);在实际项目中我推荐在界面上加一个“打印缩放比例”的 NumericUpDown默认 100%让用户微调。因为不同标签打印机的物理分辨率、边缘留白都不一样没有一个固定的公式能适配所有硬件。给用户一个可以调的旋钮比你在代码里死磕参数要省事得多。6. 实战中的三个坑字体、缩放和性能6.1 人眼可读文字的字体选择条码下方通常会印一行和条码内容一致的文字方便人眼核对。这里我强烈建议使用等宽字体比如 Consolas、Courier New。原因很简单不等宽字体下“1”和“O”很难区分而在仓库管理里物料编码 1 和 O、0 和 O 的混淆是致命的。如果目标是中文字体物料编码包含中文则需要换个思路。Code 128 B 不支持中文你需要提前在业务层把中文映射成拼音或数字编码或者改用二维码方案。这也是我在标题里特意写“条形码生成器”而不是“二维码生成器”的原因。6.2 高分屏下的 WinForms 缩放问题WinForms 在 Windows 10/11 的 150% 缩放下如果不做任何处理界面会模糊。这里有两个方案第一在app.manifest里声明 PerMonitorV2 DPI 感知第二用TableLayoutPanel做布局让控件随窗体缩放。我选了第二套方案配合手动设置// 在 Program.cs 的 Main() 里初始化前设置 if (Environment.OSVersion.Version.Major 6) { SetProcessDPIAware(); } [DllImport(user32.dll)] private static extern bool SetProcessDPIAware();这个设置让我的程序在高分屏上依然显示锐利。但有一个副作用DPI 感知开启后SaveFileDialog和PrintPreviewDialog等系统对话框在某些旧版 Windows 上可能显示偏小。这个问题在 Win10 21H2 之后基本消失不必过度担心。6.3 性能问题高分辨率条码的生成耗时实测在生成模块宽度为 4、高度为 120 的条码时RenderBarcode方法耗时在 20 毫秒以内完全不需要上异步。但如果你的场景需要批量生成几百张条码图片比如批量打印物料标签逐张生成会让循环耗时明显。优化手段是复用Graphics和Bitmap避免反复创建更进一步可以把条码的灰色底色合并成一次FillRectangle而不是逐条绘制// 优化前每条黑白交替逐个填充 // 优化后先全部填白再只填黑条 bmp new Bitmap(pixelWidth, height); using (var g Graphics.FromImage(bmp)) { g.Clear(Color.White); int x 0; for (int i 0; i modules.Count; i 2) { int width modules[i] * moduleWidth; g.FillRectangle(Brushes.Black, x, 0, width, height); x (modules[i] modules[i 1]) * moduleWidth; } }这样的循环次数直接少了一半只画黑条白条留给 Clear 填充。批量生成一千张时这个优化能明显降低耗时。6.4 实测扫码验证的教训最后一个经验也可能是最重要的一条代码无论如何严谨最终都要用真实扫码枪过一遍。我第一次实现完成后在电脑上看看码形正常就直接打包给了仓库。结果扫码枪死活不识别。排查了两小时最后发现是我忘了加左右静区条码画到了边缘扫码枪的光束扫不到起始符。加上静区之后所有扫码场景一次性通过。另外一个教训是贴纸材质对打印效果的影响。热敏标签纸在高温环境下会发黑导致条码对比度下降。这里不是代码能解决的但你要在帮助文档里提醒用户——用热转印标签纸避免阳光直射和高温环境。这种细节虽然不属于程序实现但作为工具软件的开发者你有义务替终端用户考虑到。7. 扩展思路这个生成器还能接什么场景如果你不只是想做一个独立的生成器而是想把条形码能力集成到更大的系统里那下面这几个方向可以直接参考。热搜词里出现了“抖音核销票 c#”和“c# 上位机开发”说明不少人正在做类似的业务系统集成。7.1 批量生成与 CSV 导入导出仓库管理员手里往往有一整张 Excel 物料编码表逐个人工复制到生成器里太蠢了。我的实现里加了一个“批量生成”入口读取 CSV 文件每一行生成一张条码图片按行号命名保存到输出目录。核心代码public void BatchGenerate(string csvPath, string outputDir) { var lines File.ReadAllLines(csvPath); foreach (var line in lines) { string content line.Trim(); if (string.IsNullOrEmpty(content)) continue; using (var bmp RenderBarcodeWithQuietZone(content, 4, 120)) { string fileName SanitizeFileName(content) .png; bmp.Save(Path.Combine(outputDir, fileName), ImageFormat.Png); } } }这里SanitizeFileName要过滤掉 Windows 文件名里不允许的字符\/:*?|因为物料编码里可能包含斜杠或冒号直接作为文件名会抛异常。7.2 对接 CRichTextBox 或 DataGridView 的逐行打印热搜词里有一条“project进度时间打印预览”这让我想到批处理打印的场景。如果你不是保存成图片而是希望直接在一张 A4 纸上排版多个条码那就需要计算每个条码的位置在PrintPage事件里用 for 循环逐个绘制并通过e.HasMorePages控制翻页private int _printIndex 0; private ListBitmap _printBarcodes; private void PrintDoc_PrintPage(object sender, PrintPageEventArgs e) { int columns 2; int rowsPerPage 5; int cellWidth e.PageBounds.Width / columns; int cellHeight e.PageBounds.Height / rowsPerPage; for (int i 0; i columns * rowsPerPage _printIndex _printBarcodes.Count; i) { var bmp _printBarcodes[_printIndex]; int col i % columns; int row i / columns; int x col * cellWidth; int y row * cellHeight; e.Graphics.DrawImage(bmp, x 10, y 10, bmp.Width / 2, bmp.Height / 2); _printIndex; } e.HasMorePages _printIndex _printBarcodes.Count; }7.3 与数据库字段联动最常见的场景是条形码内容来自数据库字段比如订单号、设备序列号。这时不需要用户手动输入而是在系统里直接拿字段值生成string barcodeContent ${order.BillNo}-{order.LineNo};这里有两个建议第一要注意字段值合法字符过滤掉 Code 128 B 之外的 ASCII 控制码第二预留数据库查询接口让生成器可以作为一个组件嵌入到现有的仓储、ERP 系统里而不是每次都手动输入。我个人在实际操作中的体会是条形码工具类软件最大的价值不在追逐新技术而是把编码标准、打印精度、扫码可靠性这些细节打磨到位。这个项目我从零到可用花了两天但从“能用”到“稳定”是在仓库里连续使用了两周后才逐步收敛的。希望这份分享能帮你少走点弯路尤其是静区、DPI 和字体这三个暗坑提前避开后面就顺了。
1. 为什么我会写一个条形码生成器而不是直接装个控件去年做一套进销存系统的时候仓库那边提了个需求所有物料需要打上条形码贴纸方便扫码枪扫描入库。当时我的第一反应是——这还不简单NuGet 上搜 Barcode装个第三方库一分钟搞定。结果装满三个库之后才发现要么是商业授权收费要么是依赖太重、文档稀烂还有个货在 .NET Framework 4.7.2 环境下直接编译不过。就在这时我看到用户提供的热搜词里出现了“抖音核销票 c#”、“c# 上位机开发”这类词一下子就有了代入感——很多人做 C# WinForms 不是在做花哨的互联网应用而是在做工具型软件仓库管理、会员核销、生产扫码、票据打印。这类软件有一个共性需求需要在本地生成条形码并且要把条形码打成物理贴纸。而大多数人的做法要么是在网上找在线生成器然后截图要么装一堆杀鸡用牛刀的重型依赖。于是我自己花了一个周末用纯 WinForms 加上 GDI 写了一个轻量级条形码生成器没有引用任何第三方条形码 SDK核心绘制代码全部自己控制。带保存 PNG/JPG 功能带 PrintPreviewDialog 打印预览发布出来只有一个 exe体积 200KB 出头。这篇文章就把完整的实现思路、踩坑过程、以及打印精确布局的细节全部分享出来。如果你是做 C# WinForms 的尤其是处理上位机、仓库、核销这类工具型软件这篇文章应该能帮你省下不少折腾时间。2. 条形码类型选型为什么单选 Code 128在动手写代码之前必须先确定一个事情生成哪种条形码这不是拍脑袋选的条形码的编码规则决定了扫描识别的成功率、条码长度、字符集支持选错了后面全白搭。2.1 几种常见条码的区别条码类型字符集长度典型场景优缺点Code 39大写字母数字部分符号可变工业、资产管理实现简单但密度低、条很长EAN-1313位纯数字固定零售商品必须用国际前缀不适合内部编码Code 128ASCII 全字符集可变长物流、仓储、内部管理信息密度高条码短适合标签打印QR Code任意文本可变移动端核销扫码角度要求低但需要图像库支持我的场景是仓库物料标签物料编码里既有数字又有字母偶尔还有连字符那么第一排除 EAN-13因为它只支持纯数字且固定 13 位。Code 39 也能做但用同样的编码内容打出来Code 39 的物理长度约为 Code 128 的 1.5 倍左右——在 40mm 宽的小标签上这差距很致命。Code 128 在同等信息量下条码最短而且支持完整的 ASCII 字符集对物料编码来说最理想。所以最终确定Code 128 编码字符集选 Code 128 B支持大写、小写、数字和绝大多数可见字符。2.2 关于 QR Code 的热搜词联想热搜词里有“抖音核销票 c#”这让我想起不少朋友做核销系统时纠结要不要上二维码。说实话如果清单码一维条码够用就坚决用一维条码。二维码看起来很“先进”但它有两个问题第一需要引第三方库生成码图比如 QRCoder违背了我这个项目零依赖的目标第二仓库场景的扫码枪如果配置得当一维激光枪对 Code 128 的识别速度和成功率远高于摄像头扫码器对二维码的识别。核销场景如果只是票号Code 128 完全能扛住。3. Code 128 编码原理与纯 C# 绘制实现这节是整个项目的核心也是我踩坑最多的地方。先说清楚 Code 128 的编码规则再给完整代码最后讲 GDI 绘制的关键细节。3.1 Code 128 的编码机制不是简单画粗细线很多人以为条形码就是把二进制 0 和 1 映射成黑白条实际上 Code 128 的编码要复杂得多。Code 128 的每个字符由11 个模块module组成这 11 个模块被划分成3 个条bar和 3 个空space交替排列。每个条或空的宽度可以是 1 到 4 个模块。这带来两个关键问题第一必须正确计算每个字符对应的模块宽度序列第二必须生成校验位。Code 128 的编码表有 107 个符号分 A、B、C 三种字符集。B 字符集覆盖 ASCII 32 到 127这正是我们需要的。每个字符的编码数据由查表得到但最容易被忽略的是——开始符、校验符和结束符。开始符表示从哪个字符集开始编码Code 128 B 的开始符值是 104校验符所有字符包括开始符的加权和模 103结束符固定值 106它有特殊的 13 模块结构校验位的计算公式是校验值 (开始符值 Σ(字符值 × 位置索引)) % 103其中位置索引从 1 开始计数第一个数据字符的索引是 1。注意校验计算是针对“值”的运算不是字符本身。举个例子要编码字符串ABC开始符值 104A 的值 65位置索引 1B 的值 66位置索引 2C 的值 67位置索引 3校验和 104 65×1 66×2 67×3 104 65 132 201 502校验值 502 % 103 90然后编码序列就是开始符(104)、A(65)、B(66)、C(67)、校验符(90)、结束符(106)。3.2 查表数据的组织方式Code 128 官方标准里给出了每个值对应的模块宽度模式但我没有在代码里硬编码那 107 条数据——那样代码太长且容易抄错。我用了另一种方式通过一个字符串字典来维护编码表键是字符的值值是 6 个数字组成的模式串分别表示 bar、space、bar、space、bar、space 的模块数。private static readonly Dictionaryint, string Code128Patterns new Dictionaryint, string { {0, 212222}, {1, 222122}, {2, 222221}, {3, 121223}, {4, 121322}, {5, 131222}, {6, 122213}, {7, 122312}, {8, 132212}, {9, 221213}, {10, 221312}, {11, 231212}, {12, 112232}, {13, 122132}, {14, 122231}, {15, 113222}, {16, 123122}, {17, 123221}, {18, 223211}, {19, 221132}, {20, 221231}, {21, 213212}, {22, 223112}, {23, 312131}, {24, 311222}, {25, 321122}, {26, 321221}, {27, 312212}, {28, 322112}, {29, 322211}, {30, 212123}, {31, 212321}, {32, 232121}, {33, 111323}, {34, 131123}, {35, 131321}, {36, 112313}, {37, 132113}, {38, 132311}, {39, 211313}, {40, 231113}, {41, 231311}, {42, 112133}, {43, 112331}, {44, 132131}, {45, 113123}, {46, 113321}, {47, 133121}, {48, 313121}, {49, 211331}, {50, 231131}, {51, 213113}, {52, 213311}, {53, 213131}, {54, 311123}, {55, 311321}, {56, 331121}, {57, 312113}, {58, 312311}, {59, 332111}, {60, 314111}, {61, 221411}, {62, 431111}, {63, 111224}, {64, 111422}, {65, 121124}, {66, 121421}, {67, 141122}, {68, 141221}, {69, 112214}, {70, 112412}, {71, 122114}, {72, 122411}, {73, 142112}, {74, 142211}, {75, 241211}, {76, 221114}, {77, 413111}, {78, 241112}, {79, 134111}, {80, 111242}, {81, 121142}, {82, 121241}, {83, 114212}, {84, 124112}, {85, 124211}, {86, 411212}, {87, 421112}, {88, 421211}, {89, 212141}, {90, 214121}, {91, 412121}, {92, 111143}, {93, 111341}, {94, 131141}, {95, 114113}, {96, 114311}, {97, 411113}, {98, 411311}, {99, 113141}, {100, 114131}, {101, 311141}, {102, 411131}, {103, 211412}, // Start A {104, 211214}, // Start B {105, 211232}, // Start C {106, 2331112} // Stop };这里211214就是 Code 128 B 开始符的模式意思是第 1 条黑条 2 个模块宽第 1 个白空 1 个模块宽第 2 条黑条 1 个模块宽第 2 个白空 2 个模块宽第 3 条黑条 1 个模块宽第 3 个白空 4 个模块宽。结束符是 7 个数字因为它的结构特殊比普通字符多了一个条。3.3 生成模块序列的核心函数有了编码表生成模块序列就是顺理成章的事public static Listint GetCode128BModuleSequence(string input) { var result new Listint(); // 1. 加入开始符Code 128 B AddPattern(result, 104); // 2. 加入数据字符 foreach (char c in input) { if (c 32 || c 126) throw new ArgumentException($字符 {c} 不在 Code 128 B 可编码范围内); AddPattern(result, c); } // 3. 计算校验位 int checksum 104; // 开始符值 for (int i 0; i input.Length; i) { checksum input[i] * (i 1); } checksum % 103; AddPattern(result, checksum); // 4. 加入结束符 AddPattern(result, 106); return result; } private static void AddPattern(Listint target, int codeValue) { string pattern Code128Patterns[codeValue]; foreach (char digit in pattern) { target.Add(digit - 0); } }这段代码的核心思想是把每个字符展开成模块宽度的数字序列最后整个条码就是一堆数字的连续序列。比如序列开头是2 1 1 2 1 4就表示从最左边开始画 2 模块宽的黑条留 1 模块宽的白空画 1 模块宽的黑条留 2 模块宽的白空画 1 模块宽的黑条留 4 模块宽的白空。注意AddPattern函数里target.Add(digit - 0)是把字符数字转换成整数。这种查表方式比逐个判断if/else要干净得多后续如果要支持 Code 128 A 或 C只需要把开始符改成 103 或 105加一个字符集切换逻辑即可。3.4 GDI 绘制条形码位图模块序列有了绘制就变得非常简单了。这里的核心决策是X 轴的像素计算public Bitmap RenderBarcode(string input, int moduleWidth 2, int height 60) { var modules GetCode128BModuleSequence(input); int totalModules modules.Sum(); int pixelWidth totalModules * moduleWidth; var bmp new Bitmap(pixelWidth, height); using (var g Graphics.FromImage(bmp)) { g.Clear(Color.White); int x 0; bool isBar true; // Code 128 总是从条开始 foreach (int moduleCount in modules) { int width moduleCount * moduleWidth; if (isBar) { g.FillRectangle(Brushes.Black, x, 0, width, height); } x width; isBar !isBar; } } return bmp; }这里有个容易忽略的细节isBar的初始值必须为true因为 Code 128 每个字符的编码模式都从条开始而且字符结束的位置一定是空所以下一个字符又从条开始这个交替关系能一直维持到结束符。如果你从false开始画出来的条码会黑白翻转扫码枪直接扫不出来。3.5 绘制时的问题为什么条码底部要加空白区很多第一次做条码的人只画了条和空没有在条码下方留出足够的空白区域Quiet Zone结果扫码枪频繁识别失败。条码标准要求条码左右两侧各留至少 10 倍模块宽度的空白区底部也要留出足够空间给文字或空白。我的做法是在RenderBarcode生成的位图基础上再包一层留白的逻辑public Bitmap RenderBarcodeWithQuietZone(string input, int moduleWidth 2, int height 60, int quietZoneWidth 10) { var bmp RenderBarcode(input, moduleWidth, height); int quietPixels quietZoneWidth * moduleWidth; var fullBmp new Bitmap(bmp.Width quietPixels * 2, height); using (var g Graphics.FromImage(fullBmp)) { g.Clear(Color.White); g.DrawImage(bmp, quietPixels, 0); } bmp.Dispose(); return fullBmp; }左右各加 10 个模块宽的静区扫码识别的成功率会明显提升。这个细节在我实际测试中非常关键。4. WinForms 界面搭建与保存功能实现画条码的核心逻辑完成后界面部分反而简单。但有几个交互细节值得单独说一说。4.1 界面设计简单直接避免过度设计我用的是最传统的 WinForms 布局顶部一个 TextBox 输入条形码内容一个“生成”按钮中部一个 PictureBox 显示生成的条形码底部一个“保存图片”按钮和一个“打印预览”按钮界面不需要花哨因为使用者是仓库员工不是设计师。但 TextBox 有一个小细节值得注意——限制输入长度。Code 128 B 虽然没有严格长度限制但在标签宽度固定的情况下内容越长条码越密扫码越难。所以我在 TextBox 的KeyPress事件里限制了最多 20 个字符private void txtBarcode_KeyPress(object sender, KeyPressEventArgs e) { if (txtBarcode.Text.Length 20 e.KeyChar ! (char)8) // 8 是 Backspace { e.Handled true; } }4.2 保存功能PNG 格式和分辨率的选择保存功能使用SaveFileDialog这个没什么特别的。真正值得注意的是保存时的像素尺寸。如果直接把 PictureBox 上显示的位图保存分辨率可能不够打印出来发虚。我的做法是private void btnSave_Click(object sender, EventArgs e) { if (_currentBarcode null) { MessageBox.Show(请先生成条形码); return; } using (var saveDialog new SaveFileDialog()) { saveDialog.Filter PNG 图片|*.png|JPEG 图片|*.jpg; saveDialog.FileName $barcode_{txtBarcode.Text}_{DateTime.Now:yyyyMMddHHmmss}.png; if (saveDialog.ShowDialog() DialogResult.OK) { // 生成高分辨率版本方便打印 int highResModuleWidth 4; // 渲染时用更大的模块宽度 int highResHeight _currentBarcodeHeight * 2; using (var highResBmp RenderBarcodeWithQuietZone( txtBarcode.Text, highResModuleWidth, highResHeight)) { if (saveDialog.FilterIndex 1) highResBmp.Save(saveDialog.FileName, ImageFormat.Png); else highResBmp.Save(saveDialog.FileName, ImageFormat.Jpeg); } MessageBox.Show(保存成功); } } }这里有个很实用的经验界面上显示用的位图和保存/打印用的位图应该用不同的渲染参数。界面显示只需要看清楚即可模块宽度 2、高度 60 足够但保存时要考虑后续打印需求所以模块宽度翻倍到 4、高度乘 2这样即使标签打印机驱动做了缩放条码也不会发虚。这也呼应了热搜词里那张“保存视频/保存图片”的痛点——很多工具软件里“保存”出来的资源比屏幕上看到的模糊本质就是没有区分屏幕分辨率和输出分辨率。4.3 生成按钮和界面交互private void btnGenerate_Click(object sender, EventArgs e) { string content txtBarcode.Text.Trim(); if (string.IsNullOrEmpty(content)) { MessageBox.Show(请输入条形码内容); return; } try { _currentBarcode RenderBarcodeWithQuietZone(content, 2, 60); _currentBarcodeHeight 60; picBarcode.Image?.Dispose(); picBarcode.Image _currentBarcode; picBarcode.SizeMode PictureBoxSizeMode.Zoom; } catch (ArgumentException ex) { MessageBox.Show(ex.Message, 输入内容不合法); } }picBarcode.Image?.Dispose()这行代码很重要。WinForms 里如果反复生成新的 Bitmap 赋给 PictureBox.Image而不释放旧对象GDI 句柄会持续增长运行一两天后就会出现“内存不足无法创建位图”的错误这是 WinForms 工具型软件最常见的隐性 bug。5. 打印预览与精确打印布局的关键细节打印预览是用户给的标题里有明确要求的功能也是整个项目里最阴险的部分。很多人以为打印预览就是调用PrintPreviewDialog然后把图片贴到PrintDocument上就完了实际上打印位置对不齐、比例不对的问题都出在这。5.1 PrintDocument 的核心设置private PrintDocument _printDoc new PrintDocument(); private void SetupPrintDocument() { _printDoc.PrinterSettings.PrinterName GetDefaultPrinter(); // 获取默认打印机 _printDoc.DefaultPageSettings.Landscape false; // 竖版标签 // 关键设置可打印区域边距为 0具体边界由我们自己控制 _printDoc.DefaultPageSettings.Margins new Margins(0, 0, 0, 0); _printDoc.PrintPage PrintDoc_PrintPage; }这里面最大的坑是Margins。WinForms 的PrintDocument默认会根据打印机驱动计算可打印区域很多打印机实际可打印区域是四边不等距的比如底部总是留出 5mm 无法打印。如果完全依赖默认值你无法精确控制条码在标签纸上的位置。我的做法是把Margins清零然后在PrintPage事件里用e.PageBounds作为画布原点。5.2 PrintPage 事件里的精确绘制private void PrintDoc_PrintPage(object sender, PrintPageEventArgs e) { if (_currentBarcode null) return; Graphics g e.Graphics; // 先设置高质量插值模式保证打印不模糊 g.InterpolationMode System.Drawing.Drawing2D.InterpolationMode.HighQualityBicubic; // 获取页面边界 Rectangle pageBounds e.PageBounds; // 在页面正中间打印条形码 int barcodeWidth _currentBarcode.Width; int barcodeHeight _currentBarcode.Height; int x (pageBounds.Width - barcodeWidth) / 2; int y (pageBounds.Height - barcodeHeight) / 2 - 10; g.DrawImage(_currentBarcode, x, y, barcodeWidth, barcodeHeight); // 在条码下方打印人眼可读的字符 string humanReadable txtBarcode.Text; using (Font font new Font(Consolas, 22, FontStyle.Regular, GraphicsUnit.Point)) { SizeF textSize g.MeasureString(humanReadable, font); float textX (pageBounds.Width - textSize.Width) / 2; float textY y barcodeHeight 5; g.DrawString(humanReadable, font, Brushes.Black, textX, textY); } }这里我用e.PageBounds而不是e.MarginBounds就是要把坐标系原点直接设在纸张边缘。很多人不知道PageBounds和MarginBounds的区别——前者是整个纸张的边界后者是减去了Margins属性后的可用区域。我在DefaultPageSettings里把边距设为 0 后两者才一致。5.3 打印预览一行代码但前提条件不少WinForms 的打印预览使用起来非常简单private void btnPrintPreview_Click(object sender, EventArgs e) { if (_currentBarcode null) { MessageBox.Show(请先生成条形码); return; } SetupPrintDocument(); using (var preview new PrintPreviewDialog()) { preview.Document _printDoc; preview.StartPosition FormStartPosition.CenterParent; preview.ClientSize new Size(800, 600); preview.ShowDialog(this); } }但这里有个前置条件PrintPage事件里用的_currentBarcode必须存在。所以btnPrintPreview_Click里先做了判空。另外要注意PrintPreviewDialog 不会自动更新 PrintDocument如果你在生成条码之后修改了_printDoc.PrintPage事件的处理逻辑需要重新SetupPrintDocument()。5.4 打印尺寸换算DPI 是罪魁祸首这是整个打印功能里最容易出错的地方。屏幕上的 100px 和打印机上的 100px 不是一回事因为屏幕通常是 96 DPI而打印机的分辨率通常是 300 DPI 甚至 600 DPI。PrintDocument 绘制时使用的坐标系已经由 WinForms 帮我们做了转换但如果你直接从 Bitmap 的像素宽高去打印会出现“打印出来比屏幕上的大/小 3 倍”的问题。解决方法是显式指定打印尺寸// 打印物理尺寸 像素数 / 分辨率 * 25.4单位从像素转毫米 int barcodeWidthMm (int)(_currentBarcode.Width / 96.0 * 25.4); int barcodeHeightMm (int)(_currentBarcode.Height / 96.0 * 25.4); // 换算成打印机的 1/100 英寸单位 int printWidth (int)(barcodeWidthMm / 25.4 * 100); int printHeight (int)(barcodeHeightMm / 25.4 * 100);更简单的做法是直接用Graphics.DrawImageUnscaled或者指定矩形大小// 以 96 DPI 为基准1 英寸 96 像素 int printWidthPixels _currentBarcode.Width; // 相当于 1:1 打印 e.Graphics.DrawImage(_currentBarcode, x, y, printWidthPixels, printHeightPixels);在实际项目中我推荐在界面上加一个“打印缩放比例”的 NumericUpDown默认 100%让用户微调。因为不同标签打印机的物理分辨率、边缘留白都不一样没有一个固定的公式能适配所有硬件。给用户一个可以调的旋钮比你在代码里死磕参数要省事得多。6. 实战中的三个坑字体、缩放和性能6.1 人眼可读文字的字体选择条码下方通常会印一行和条码内容一致的文字方便人眼核对。这里我强烈建议使用等宽字体比如 Consolas、Courier New。原因很简单不等宽字体下“1”和“O”很难区分而在仓库管理里物料编码 1 和 O、0 和 O 的混淆是致命的。如果目标是中文字体物料编码包含中文则需要换个思路。Code 128 B 不支持中文你需要提前在业务层把中文映射成拼音或数字编码或者改用二维码方案。这也是我在标题里特意写“条形码生成器”而不是“二维码生成器”的原因。6.2 高分屏下的 WinForms 缩放问题WinForms 在 Windows 10/11 的 150% 缩放下如果不做任何处理界面会模糊。这里有两个方案第一在app.manifest里声明 PerMonitorV2 DPI 感知第二用TableLayoutPanel做布局让控件随窗体缩放。我选了第二套方案配合手动设置// 在 Program.cs 的 Main() 里初始化前设置 if (Environment.OSVersion.Version.Major 6) { SetProcessDPIAware(); } [DllImport(user32.dll)] private static extern bool SetProcessDPIAware();这个设置让我的程序在高分屏上依然显示锐利。但有一个副作用DPI 感知开启后SaveFileDialog和PrintPreviewDialog等系统对话框在某些旧版 Windows 上可能显示偏小。这个问题在 Win10 21H2 之后基本消失不必过度担心。6.3 性能问题高分辨率条码的生成耗时实测在生成模块宽度为 4、高度为 120 的条码时RenderBarcode方法耗时在 20 毫秒以内完全不需要上异步。但如果你的场景需要批量生成几百张条码图片比如批量打印物料标签逐张生成会让循环耗时明显。优化手段是复用Graphics和Bitmap避免反复创建更进一步可以把条码的灰色底色合并成一次FillRectangle而不是逐条绘制// 优化前每条黑白交替逐个填充 // 优化后先全部填白再只填黑条 bmp new Bitmap(pixelWidth, height); using (var g Graphics.FromImage(bmp)) { g.Clear(Color.White); int x 0; for (int i 0; i modules.Count; i 2) { int width modules[i] * moduleWidth; g.FillRectangle(Brushes.Black, x, 0, width, height); x (modules[i] modules[i 1]) * moduleWidth; } }这样的循环次数直接少了一半只画黑条白条留给 Clear 填充。批量生成一千张时这个优化能明显降低耗时。6.4 实测扫码验证的教训最后一个经验也可能是最重要的一条代码无论如何严谨最终都要用真实扫码枪过一遍。我第一次实现完成后在电脑上看看码形正常就直接打包给了仓库。结果扫码枪死活不识别。排查了两小时最后发现是我忘了加左右静区条码画到了边缘扫码枪的光束扫不到起始符。加上静区之后所有扫码场景一次性通过。另外一个教训是贴纸材质对打印效果的影响。热敏标签纸在高温环境下会发黑导致条码对比度下降。这里不是代码能解决的但你要在帮助文档里提醒用户——用热转印标签纸避免阳光直射和高温环境。这种细节虽然不属于程序实现但作为工具软件的开发者你有义务替终端用户考虑到。7. 扩展思路这个生成器还能接什么场景如果你不只是想做一个独立的生成器而是想把条形码能力集成到更大的系统里那下面这几个方向可以直接参考。热搜词里出现了“抖音核销票 c#”和“c# 上位机开发”说明不少人正在做类似的业务系统集成。7.1 批量生成与 CSV 导入导出仓库管理员手里往往有一整张 Excel 物料编码表逐个人工复制到生成器里太蠢了。我的实现里加了一个“批量生成”入口读取 CSV 文件每一行生成一张条码图片按行号命名保存到输出目录。核心代码public void BatchGenerate(string csvPath, string outputDir) { var lines File.ReadAllLines(csvPath); foreach (var line in lines) { string content line.Trim(); if (string.IsNullOrEmpty(content)) continue; using (var bmp RenderBarcodeWithQuietZone(content, 4, 120)) { string fileName SanitizeFileName(content) .png; bmp.Save(Path.Combine(outputDir, fileName), ImageFormat.Png); } } }这里SanitizeFileName要过滤掉 Windows 文件名里不允许的字符\/:*?|因为物料编码里可能包含斜杠或冒号直接作为文件名会抛异常。7.2 对接 CRichTextBox 或 DataGridView 的逐行打印热搜词里有一条“project进度时间打印预览”这让我想到批处理打印的场景。如果你不是保存成图片而是希望直接在一张 A4 纸上排版多个条码那就需要计算每个条码的位置在PrintPage事件里用 for 循环逐个绘制并通过e.HasMorePages控制翻页private int _printIndex 0; private ListBitmap _printBarcodes; private void PrintDoc_PrintPage(object sender, PrintPageEventArgs e) { int columns 2; int rowsPerPage 5; int cellWidth e.PageBounds.Width / columns; int cellHeight e.PageBounds.Height / rowsPerPage; for (int i 0; i columns * rowsPerPage _printIndex _printBarcodes.Count; i) { var bmp _printBarcodes[_printIndex]; int col i % columns; int row i / columns; int x col * cellWidth; int y row * cellHeight; e.Graphics.DrawImage(bmp, x 10, y 10, bmp.Width / 2, bmp.Height / 2); _printIndex; } e.HasMorePages _printIndex _printBarcodes.Count; }7.3 与数据库字段联动最常见的场景是条形码内容来自数据库字段比如订单号、设备序列号。这时不需要用户手动输入而是在系统里直接拿字段值生成string barcodeContent ${order.BillNo}-{order.LineNo};这里有两个建议第一要注意字段值合法字符过滤掉 Code 128 B 之外的 ASCII 控制码第二预留数据库查询接口让生成器可以作为一个组件嵌入到现有的仓储、ERP 系统里而不是每次都手动输入。我个人在实际操作中的体会是条形码工具类软件最大的价值不在追逐新技术而是把编码标准、打印精度、扫码可靠性这些细节打磨到位。这个项目我从零到可用花了两天但从“能用”到“稳定”是在仓库里连续使用了两周后才逐步收敛的。希望这份分享能帮你少走点弯路尤其是静区、DPI 和字体这三个暗坑提前避开后面就顺了。
