简介：这份 Microsoft Barcode Control 9.0 示例资料面向基于 .NET Framework 的 Windows Forms 开发者，围绕条形码生成与打印需求提供可运行的集成参考。压缩包共 30 个文件，约 57KB，包含 cs 源代码、dll 组件、exe 程序、resx 资源及 csproj/sln 工程文件等，既有窗体设计代码，也保留编译输出与项目配置，便于直接打开解决方案对照控件用法。已有 6438 人学习，说明其在条码控件入门与项目实践中具有一定参考价值。通过 Form1 等示例代码，读者可了解 Code 39、Code 128、EAN-13 等条码类型的属性设置、数据绑定、绘制事件与打印接口调用，并观察校验位处理和动态数据更新方式，从而把条码生成逻辑迁移到自己的 Windows 应用中，减少从零摸索控件集成的成本。

1. 一套十几年前的控件，为什么今天还在被翻出来

上周帮人看一条标签线，现场机器还是 Win7，软件是十多年前写完就没再动过的 WinForms。客户要求加个条码，负责的工程师试了三个开源库：有的 Code128 打出来扫码枪读三次错两次，有的中文批号一贴就比例失真。最后翻出来的还是Barcode Control 9.0。这个 ActiveX 条码控件确实不新鲜，但它把“出码”和“打纸”两件事绑在同一套对象模型里：属性赋值完，直接往打印机 DC 上画，省掉了位图导出、缩放、DPI 对齐这一串麻烦。

它适合的场景很具体：老系统加条码、固定格式标签批量打印、下游不是报表引擎而是打印机 DC。如果正好卡在“代码能生成、纸上扫不出”这一步，这个包值得拆开看一遍。

2. 控件对象模型与码制选型：先算清模块宽度再谈打印

条码打印失败的原因，八九成不在控件本身，而在动手写代码之前就没把两件事定下来：模块宽度多大，用哪种码制。这两个参数一错，后面打印链路调得再顺，纸上的条码照样是废的。所以先把模型和选型掰开说清楚，再谈怎么调用。

2.1 三个属性能决定条码能不能被扫出来

这套控件的属性加起来几十个，真正决定“扫得出扫不出”的其实只有三个：模块宽度（通常叫BarWidth或NarrowBarWidth）、条码高度、静区留白。

模块宽度的单位是缇（twip），1 缇 = 1/1440 英寸，不是像素，也不是毫米。很多人第一次用的时候看到BarWidth = 2觉得挺宽，其实才 0.035 毫米，打出来整条码糊成一片黑。拿 300 DPI 的打印机算一下：一个点约等于 0.0847 毫米，Code128 的模块宽度至少要覆盖 2 个打印点才算稳，也就是 0.17 毫米左右，换算成缇是 9.6，取 10 比较合适。

我一般会写个换算函数，把毫米当唯一输入，别在代码里到处填缇：

// 缇转毫米，毫米转缇，统一从这里走，避免不同页面重复算错 private const double TwipsPerInch = 1440.0; private static int MmToTwips(double mm) => (int)Math.Round(mm / 25.4 * TwipsPerInch); private static double TwipsToMm(int twips) => twips / TwipsPerInch * 25.4;

高度和宽度要分开看。高度不够（低于 8 毫米）扫码枪在斜角方向读不到；高度够但模块宽度不够，问题更深，肉眼看条码还在，设备却读不出来。静区是最容易漏的：Code128 左右各留 10 倍模块宽度，控件一般有LeftMargin/RightMargin这类属性，但不少版本默认是 0，生成出来贴在标签边缘，扫码枪直接读不到起始符。所以静区要么在控件里设，要么在排版时留出足够空白，别指望编码器兜底。

还有一个经常被忽略的点：模块宽度是相对打印机 DPI 的，不是相对屏幕的。屏幕预览看着完美，打到纸上变窄一半，因为预览按 96 DPI 渲染，打印机是 203 或 300 DPI。正确做法是先确定目标打印机 DPI，反推出毫米值，再换算成缇，屏幕预览只用来核对内容，不用来核对尺寸。

2.2 码制选型：Code128、Code39、EAN-13 怎么挑

控件的Style或Symbology属性是一个枚举，各版本编号不一样，我在代码里通常自己包一层常量，不直接写数字。选型上常见就四种，对照一下需求就够：

默认推荐 Code128，除非下游明确只认 Code39。从 Code39 换到 Code128 最常见的代价不在条码宽度，而在扫描器配置：有些老设备的键盘仿真层会把 Code128 的某些控制字符吞掉，扫出来的字符串跑到输入框里就少几位。这种情况我一般现场拿扫码枪回读一次，跟原字符串逐字符比对（包括校验位和不可见字符），比猜快得多。

EAN-13 和 ITF-14 有个坑要注意：校验位通常不是控件替你算，而是要求你传入完整 13 位或 14 位数字，其中最后一位是校验位。控件里有CheckDigit开关，设成自动计算，会截掉你传的末位自己重算；设成手动，传入的字符串不对就直接拒码。两种模式没有对错，取决于数据源头——批号从数据库来、校验位上游已经算好，就别开自动，否则出现“我传的对，出来却不对”的情况。

还有一类：如果编码内容里含%、*、空格这类字符，Code39 在某些实现里会被当成起止符解释，或者在*两侧拼接时出错。这种情况不是编码逻辑问题，是字符集不支持，换成 Code128 基本能绕开。

2.3 控件在 .NET 里的三层包装关系

很多人第一次把这套控件引到 WinForms 里就晕：设计器拖出来的类型叫AxBarcodeCtl，代码里又能声明BarcodeCtl，到底该用哪个。

它是一个 COM/ActiveX 控件（.ocx），在 .NET 里要经过两步转换才可用：先由tlbimp（或 IDE 自动）生成互操作程序集，得到接口类型；再由aximp生成 Ax 宿主包装，负责窗口句柄和事件转发。结果就是一个控件对应两个程序集、两个类型：

• AxBarcodeCtl：继承自AxHost，带窗口句柄，能拖到窗体上、能响应事件、能直接DrawToDC。
• BarcodeCtl：接口类型，不能直接可视化，但可以用来读取属性、或者在非可视化场景下做编码计算。

要往界面上放，用 Ax 类型；要纯计算条码内容不显示，用接口类型。搞混的典型症状是：new BarcodeCtl()之后调用绘制方法，报“对象未初始化”或者句柄无效——因为它没有真正的窗口，DrawToDC没地方画。这一条记牢，后面运行时创建的代码就不会踩。

3. WinForm 落地：注册、引用到运行时出码

从拿到包到跑出第一张标签，实际要过三步：注册控件、让项目认识它、再在代码里创建并赋值。三步里最容易翻车的是第一步，因为注册失败时 IDE 给你的报错非常含糊，只说“未能加载”，不告诉你为什么。所以这一段我按操作顺序写，每步都标出失败时该看什么。

3.1 注册与引用：OCX 到 Ax 包装的三步

先在管理员权限的命令提示符里注册，注意路径里别带中文和空格，注册失败多半是路径问题：

:: 以管理员身份运行；换成你解压后的实际文件名 cd /d "D:\tools\barcode9" regsvr32 /s "BarcodeCtl9.ocx" :: 先卸旧版再注册新版，两台机器上都装着不同版本时尤其要执行 regsvr32 /u /s "BarcodeCtl9.ocx"

/s是静默模式，不弹成功框。装完想确认注册表里有没有落到正确位置，查一下 CLSID 有没有被写进去：

:: 能查到 ProgID 说明注册成功；查不到就是注册失败，别急着开 IDE reg query "HKCR\BarcodeCtl9.BarcodeCtl" /s

注册成功之后，在 WinForms 项目里走“添加引用 → COM 选项卡”，勾选对应的控件条目，IDE 会自动生成AxBarcodeCtl和BarcodeCtl两个包装。生成的 Interop 程序集会被拷到输出目录，这一点很重要——后面部署到客户机时，如果只在目标机regsvr32注册了 ocx 而没把 Interop 程序集带过去，照样报类未注册。

如果你的环境是 32 位和 64 位混着的，注册时用哪个regsvr32决定注册到哪个注册表视图。32 位系统只有一种，64 位系统要分清楚：

:: 64 位系统里，32 位控件用 SysWOW64 下的注册器，别用 System32 那个 C:\Windows\SysWOW64\regsvr32.exe /s "BarcodeCtl9.ocx"

3.2 运行时创建控件并赋值出图

不是所有场景都适合设计器拖拽：动态生成多个条码、按数据行批量出码、或者把控件放在没有界面的服务里跑，都得运行时创建。下面这段是能直接抄的骨架：

using System; using System.Drawing; using System.Drawing.Imaging; using System.Windows.Forms; using AxBarcodeLib; // IDE 生成的 Ax 包装命名空间，实际名称以你项目为准 public class BarcodeRenderer : IDisposable { private AxBarcodeCtl _ctl; public void Init(Form host) { _ctl = new AxBarcodeCtl(); // 关键：BeginInit/EndInit 之间不能访问句柄相关属性 ((ISupportInitialize)_ctl).BeginInit(); host.Controls.Add(_ctl); // 不挂到某个容器上，CreateControl 会失败 ((ISupportInitialize)_ctl).EndInit(); _ctl.CreateControl(); // 显式创建句柄，服务端无窗体场景下尤其必要 // 下面这些属性名以对象浏览器里实际显示的为准，各家版本拼写略有差异 _ctl.Style = 7; // 码制，Code128；枚举值查控件文档 _ctl.BarWidth = MmToTwips(0.25); // 模块宽度 0.25mm，约合 300DPI 下 3 个点 _ctl.Height = MmToTwips(12); // 条码高度 12mm _ctl.ShowText = true; // 是否在下方显示明文 _ctl.TextPosition = 2; // 0 不显示 1 上方 2 下方 _ctl.Rotation = 0; // 0 度，正向 _ctl.MarginLeft = MmToTwips(2.5); // 左静区，10 倍模块宽度 _ctl.MarginRight= MmToTwips(2.5); } public void RenderTo(string data, string filePath) { _ctl.Value = data; // 待编码内容，赋值即完成编码 using (var bmp = new Bitmap(600, 240)) using (var g = Graphics.FromImage(bmp)) { g.Clear(Color.White); IntPtr hdc = g.GetHdc(); try { // 把控件画到内存 DC；x/y 单位同样按控件约定，一般是缇或像素 _ctl.DrawToDC(hdc.ToInt32(), MmToTwips(5), MmToTwips(5)); } finally { g.ReleaseHdc(hdc); // 必须成对释放，否则下次 GetHdc 会失败 } bmp.Save(filePath, ImageFormat.Png); } } public void Dispose() => _ctl?.Dispose(); }

这段代码里真正容易出错的只有三处：

第一，CreateControl()不能省。控件是窗口化的 ActiveX，没有句柄时内部很多绘制状态是空的，直接调DrawToDC要么抛异常，要么画出来是一张白图。

第二，GetHdc/ReleaseHdc必须成对。少写一次释放，下一次调用会拿到一个失效句柄，表现是“第一张图正常，第二张开始全白”，非常有迷惑性。

第三，BarWidth填的是缇，Height也是缇。我见过有人把像素直接塞进去，屏幕预览正常（因为控件会把缇当像素处理一部分），一上打印机高度只剩三分之一。

3.3 批量生成：从数据表循环出码

单张出码只是验证，真正上线都是几万条批号一次跑。这时候要把“编码失败”和“渲染失败”分开处理，别让一条脏数据把整批打断。

using System.Collections.Generic; using System.Data; using System.Text.RegularExpressions; public List<string> BatchRender(DataTable table, string outDir) { var failed = new List<string>(); foreach (DataRow row in table.Rows) { string code = (row["SkuCode"] ?? "").ToString().Trim(); // 编码前先做字符集与长度预检，比让控件抛异常再 catch 干净得多 if (code.Length == 0 || code.Length > 48 || !Regex.IsMatch(code, @"^[\x20-\x7E]+$")) { failed.Add(code); continue; } try { RenderTo(code, $@"{outDir}\{code}.png"); } catch (Exception ex) { // 记下具体行，方便回头只重跑失败的那几条，而不是整批重来 failed.Add($"{code}\t{ex.Message}"); } } return failed; }

参数上要注意长度：Code128 在常见控件实现里有个内部缓冲区上限，超长字符串会被截断而且不报错，打出来的条码少一段，扫码枪读到的内容和预期对不上，排查起来很费时间。我一般按业务规则硬性卡在 48 字符以内，超长的走分段或者换码制。

字符集预检用的是可打印 ASCII 范围，这一条挡掉了中文和全角符号。Code128 本身能编码扩展字符，但不少控件实现只保证 ASCII 的正确性，中文进得去出不来，出来的是一条内容错乱的条码。如果业务上确实要打中文批号，正确做法是把中文放在明文区域，条码只编码数字或英文短码，两者用同一个主键关联。

4. 打印链路：从屏幕预览到标签纸的三条出口

生成图片只是半程，纸上的条码能不能扫，取决于你怎么把它送到打印机。三条常见路径各有适用范围，选错了再调参数也是白费力气。

4.1 走 PrintDocument：把控件当绘制器

这是最贴合控件设计意图的用法。PrintDocument的PrintPage事件里拿到的是打印机 DC，直接让控件往上画，中间不经过位图缩放，尺寸最准。

private void OnPrintPage(object sender, PrintPageEventArgs e) { // 一页三个标签，横向 45mm 步进；位置全部用毫米算，别写死像素 for (int i = 0; i < 3; i++) { int x = MmToPx(e.Graphics, 8 + i * 45); int y = MmToPx(e.Graphics, 10); IntPtr hdc = e.Graphics.GetHdc(); try { _ctl.DrawToDC(hdc.ToInt32(), x, y); } finally { e.Graphics.ReleaseHdc(hdc); } } e.HasMorePages = false; } // 毫米转像素，按当前 Graphics 的水平分辨率算，屏幕和打印机自动适配 private static int MmToPx(Graphics g, double mm) => (int)Math.Round(mm / 25.4 * g.DpiX);

这里的MmToPx用的是g.DpiX，所以同一段代码在屏幕上预览是 96 DPI，打到 203 DPI 的标签机上会自动放大到正确尺寸，不需要写两套坐标。

需要注意PrintPage事件的坐标系原点在可打印区域的左上角，不是纸张物理边缘。不同打印机不可打印边距差几毫米很正常，标签纸上位置整体偏一点点，八成就是这个原因。稳妥做法是先打一张定位图（画十字线到四个角的已知距离），量出来再统一加偏移。

4.2 导出图片再交给报表模板

如果标签版式复杂、有 logo、有多列数据，用控件直接画太累，常见做法是先用控件出图，再交给报表工具或者 FastReport 这类模板引擎排。

这条路的代价是图片分辨率必须和打印机 DPI 对齐。用 96 DPI 出的图，塞进 300 DPI 的模板里会被插值放大，模块边缘发虚，扫码枪读起来就吃力了。正确做法是生成时按目标 DPI 反推像素尺寸：

// 按目标打印机 DPI 生成位图，避免模板里二次插值 double targetDpi = 300; double widthMm = 60, heightMm = 25; int pxW = (int)Math.Round(widthMm / 25.4 * targetDpi); int pxH = (int)Math.Round(heightMm / 25.4 * targetDpi); using (var bmp = new Bitmap(pxW, pxH)) { bmp.SetResolution((float)targetDpi, (float)targetDpi); // 关键：写进图片元数据 // 后续绘制同 3.2 节 }

SetResolution这一行不写，图片默认是 96 DPI 元数据，某些报表引擎会按 96 去算物理尺寸，贴到纸上的条码凭空缩小三倍。这类问题在预览里看不出来，只有打出来才发现，返工成本很高。

4.3 标签打印机：指令打印和图形打印的分界

这是选型上最容易走偏的一环。标签打印机通常有两条路：一是把整页当图片发给打印机（图形模式），二是发字体/条码指令让打印机自己渲染（指令模式，比如 ZPL 这类）。

用 ActiveX 控件出图，本质上是图形模式。它能保证屏幕所见即所得，但有两个限制：一是分辨率受图片本身限制，图片做多细纸上就多细；二是每张标签都要传一张图，行数多的时候传输量不小。

指令模式生成的是矢量条码，打印机用自己的固件渲染，边缘更锐利、速度快，但版式控制权从你手里交出去了，对齐、旋转、多行文本都得用打印机自己的语言写。

我的判断标准很简单：条码是整张标签的主体、版式简单、数量大，走指令；标签里有复杂图文混排、需要复用现有模板、或者打印机品牌杂，走图形。两套混着上的情况也有——主体条码走指令，图片和说明文字走图形叠加，前提是打印机支持混合渲染。

5. 避坑与排查：五个高频翻车点

这一章只写现场撞见过的，每条按“现象、原因、解决”的顺序，能对号入座的直接照做。

5.1 扫不出来：八成是模块宽度被打印链路改过

现象：控件里量着模块宽度 0.25 毫米，扫十次错八次，读出来的字符串还经常少一位。

原因：中间经过了缩放。要么是图片被报表模板按比例拉伸，要么是打印机的“适合页面”选项开着，把整张图缩小了 80%。模块宽度一旦低于一个打印点，相邻条空在物理上就糊在一起，边缘对比度不够，扫描器判不出边界。

解决：先别改控件的值，直接拿卡尺量纸上实际的黑条宽度，和理论值对一下。差了就往上找缩放源头，把“适合页面”“自动缩放”全部关掉，图片按 1:1 输出。确认没有缩放之后，再把模块宽度往上调到 0.3 毫米试，一般能解决。

5.2 位置漂移：控件坐标和可打印区域不是一回事

现象：屏幕上位置对着，打出来整条码往右偏了五六毫米，换一台同型号打印机又对上了。

原因：DrawToDC的坐标是相对当前 DC 的原点，而打印机 DC 的原点在可打印区域左上角，不同机型、不同纸边距这个点不一样。控件本身不知道纸的物理边缘在哪。

解决：别在代码里硬编码偏移，先打一张带十字标记的校准页，量出实际偏移量，做成打印机型号对应的配置项读进来。同型号批量部署时这套配置可以直接复用，跨型号再校准一次。

5.3 换台机器就报“类未注册”

现象：开发机跑得好好的，拷到客户机上启动就抛COMException，提示类未注册或 ProgID 找不到，重装软件也没用。

原因：regsvr32注册的是 ocx 本身，但 .NET 项目运行时还需要 IDE 生成的 Interop 程序集。发布时如果只拷了 exe 和 dll，Interop 那个程序集没跟着走，运行时找不到包装类型。另一种情况是注册到了错误的注册表视图：32 位控件用 64 位注册器注册，64 位进程读得到、32 位进程读不到。

解决：先把 Interop 程序集设为“复制到本地”，确认输出目录里有；再用对应位数的注册器重新注册一次，注册完用reg query确认 CLSID 落到了哪。这两步都做完还报错，看一眼应用程序日志里的事件 ID，一般会指明具体是哪个 CLSID 失败。

5.4 64 位进程里加载失败

现象：项目平台目标设成 AnyCPU，在 64 位系统上跑，创建控件时抛BadImageFormatException或者直接崩掉。

原因：这类 ActiveX 控件绝大多数只有 32 位版本，64 位进程加载不了 32 位组件。AnyCPU 在 64 位系统上默认按 64 位跑，正好踩中。

解决：把平台目标钉死成 x86。改项目文件比改 IDE 里的下拉框更可靠，因为有些构建配置会把它覆盖掉：

<PropertyGroup> <PlatformTarget>x86</PlatformTarget> <!-- 如果项目里有 Prefer32Bit 且是 exe，这里要明确关掉，避免行为和预期不一致 --> <Prefer32Bit>false</Prefer32Bit> </PropertyGroup>

改完记得清理重建，只做增量编译有时旧的目标框架信息还留在中间文件里。

5.5 特殊字符把整批打挂

现象：单独测试某一条批号时抛异常，日志里只有一句“参数无效”，看不出是哪个字符的问题；批量跑的时候整批中断。

原因：编码内容里混进了全角字符、制表符、或者超过控件缓冲区长度的串。控件在赋值阶段就拒绝，异常信息没带上具体数据，定位很困难。

解决：编码前统一做一次清洗和校验，长度和字符集都卡死，脏数据不进控件。批量处理时逐条 try/catch，失败的行写进单独的结果文件，跑完只重跑失败的那几条，不整批重来。这条看着笨，但省下来的时间比任何调试技巧都多。

6. 上线前的三重验证：回读、静区与模块宽度

条码这东西有个特点：肉眼看着好好的，设备读不出来；或者反过来，扫码枪能读，但换一台型号稍老的设备就废了。所以只靠“看一眼觉得没问题”是不够的，我习惯在批量投产前跑三道验证。

第一道是回读。拿现场实际使用的那把扫码枪，不是办公室里随便找的一把，对同一张标签连扫十次，逐字符比对读回值和原字符串，包括校验位和不可见字符。这一道最容易抓到字符集问题——键盘仿真层会把某些控制字符吞掉，屏幕上完全看不出异常，读回来少两位才知道。

第二道是静区。量一下条码左右到标签边缘的实际距离，和模块宽度乘 10 对一下。这一项在密集排版里最容易被挤掉，尤其是标签宽度本来就紧张的时候，设计师为了字大一点，把条码往边上挪了两毫米，扫码枪立刻变挑剔。

第三道是模块宽度实测。不用每次都上卡尺，但新打印机、新纸、新模板第一次上线时必须量一次。量出来的值和理论值差 5% 以内可以接受，超了就回头查缩放链路，别指望调控件参数能补回来。

三道都过了再批量跑。听起来麻烦，实际做下来一轮不到十分钟，比起打了几千张发现扫不出、整批返工重印，这点时间花得值。从那以后我每批标签上线前，都会先打三张、扫十次、拿卡尺量一遍模块宽度，全部过了才敢放开批量跑。这个习惯帮我拦下过好几次看似正常的模板改动。希望帮到你。

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