zplCloud Blog

zplCore.com 引擎正式发布：zplCloud 的标签引擎推出 .NET SDK

zplCloud 每一次预览背后的引擎，现在也能用于你自己的应用程序：以打印机级精确参考为基准衡量的 ZPL II 和 EPL2 渲染、144 种码制、合规预检、扫描验证、打印机孪生、CI 中的标签测试，以及面向编程智能体的 MCP 服务器。

October 19, 2026 7 分钟阅读 zplCloud Team

zplCloud 背后的引擎，如今成为 SDK

zplCloud 上的每一次预览、每一份 PDF，都由同一个引擎渲染：zplCore.com。从今天起，它以 .NET 10 SDK 的形式提供给你自己的应用程序使用，zplCloud 用到的所有功能都包含在内：把 ZPL II 和 EPL2 渲染为 PNG、PDF 和 SVG，根据数据生成标签，对照 GS1 和承运商规则进行检查，回读每一个条码，模拟打印机（包括故障），以及打印。它可在 Windows、Linux 和 macOS 上运行，也可运行在 Docker 和 Kubernetes 中，无需打印机驱动。

简而言之： zplCore.com 是一个 .NET 库，外加一个 CLI、一个测试包和一个 MCP 服务器。它像一台虚拟 Zebra 打印机那样渲染，并以打印机级精确的参考渲染为基准进行衡量。除了渲染，它还能检查和模拟：合规预检、扫描验证（scan-proof）、打印机孪生、混沌打印机，以及 CI 中的标签测试。试用版可在 zplcore.com 申请。

zplCloud 为什么要自研引擎

2026 年 10 月之前，zplCloud 使用 Neodynamic 的 ThermalLabel 和 ZPLPrinter SDK 生成预览，并把设计转换为 ZPL。如今 zplCore.com 是 zplCloud 中唯一的引擎：设计器生成 ZPL，PNG、SVG 和 PDF 预览渲染的正是这段 ZPL。预览中看到的，就是发送到打印机的内容，不再有第二条图像生成路径。

我们有三个理由：

以打印机为准绳。 zplCore 与 Labelary 的打印机级精确参考渲染逐像素比较，容差为 2 点：169 个测试用例的平均得分为 0.986，其中 131 个达到 0.99 或更高，85 个像素完全一致。自动化测试确保每个用例至少保持当前得分。
只会渲染还不够。 一张标签看起来没问题，也可能不合格：条码落在空白区内、字段超出打印头范围、SSCC 的 X 尺寸不对。我们想要一个能自己回答这些问题的引擎，离线运行，并且就在构建流程中完成。
云端和你自己的服务器共用一套代码。 免费 zplCloud 工具背后的功能，与你在 SDK 中得到的完全相同。

zplCore.com 是基于公开的 ZPL II 规范和各码制标准的独立实现，不包含其他商业厂商的任何代码；所用的开源组件列在其第三方声明中。

zplCore.com 是什么

领域	内容
平台	.NET 10；已在 Windows 11、macOS、Debian 和 Azure Linux 3.0（包括 distroless）上测试；附带 Dockerfile 和 Helm chart；兼容 NativeAOT
输入	ZPL II 和 EPL2；EPL 表单可转换为 ZPL
输出	PNG、JPEG、WebP、BMP、GIF、PDF 和 SVG（二者均为矢量）、TIFF、PCX、PCL、GRF、EPS、HTML，以及 EPL、Fingerprint 和 ESC/POS
条码	144 种码制，从 Code 128、GS1 DataBar 和 QR 到 MaxiCode、DotCode 和汉信码；GS1 解析器和校验器，支持 534 个应用标识符
基于数据生成标签	以毫米或英寸为单位的标签模型、JSON 模板，数据绑定到 C# 对象、EF Core、LiteDB、MongoDB 和 JSON，流式处理且内存占用恒定
打印	TCP 9100、串口、USB、Windows 打印后台处理程序、CUPS；`~HS`/`~HQES` 状态查询；TCP 9100 上的虚拟打印机
文字	HarfBuzz 字形整形和双向文本，支持阿拉伯文、希伯来文、泰文、印度系文字和中日韩文字

几行 C# 就能得到预览：

using ZplCore;

var renderer = new ZplRenderer(new ZplRenderSettings { Dpi = 203 }.WithLabelSizeMm(100, 150));
List<byte[]> pngs = renderer.ProcessFile("labels.zpl");          // one PNG per label

renderer.Settings.OutputFormat = ZplOutputFormat.Pdf;             // one PDF, one page per label
File.WriteAllBytes("preview.pdf", renderer.ProcessFile("labels.zpl")[0]);

“打印机级精确”具体指什么：

QR 码（^BQ，模型 2）与 Zebra 输出模块级一致：模式选择、版本、纠错等级和掩码均相同，已用 3,600 多个 Labelary 参考符号验证。
PDF417（^B7）和 MicroPDF417（^BF）与 Labelary 码字级一致，采用 Zebra 的压缩方式。
字符集（^CI）和 ^FH 的行为与打印机相同：没有 ^CI 时标签使用代码页 850，^CI0 至 ^CI12 替换各国字符，Windows 代码页遵循 ZPL 指南，在 ^CI28 下二维符号承载的字节与打印机编码的字节一致。
复现 Zebra 的行为：字体 0 的字符步进宽度、QR 码位置随 ^BY 高度产生的偏移、Code 128 模式 N 保持在子集 B、宽条按 floor(ratio × module) 计算。

它的速度也很快。在 Apple M3 Max 上的 Release 构建中，zplCore 以 ZPL 形式（存储格式，单个作业 100,000 张标签）每秒最多生成 199,000 张标签，使用 10 个线程时每秒生成 5,000 多张 PNG 预览。每项测量都可以用一条命令重复执行。

功能一览

本节所有图片和输出都来自引擎本身：取自 zplCore 文档、zplCore CLI 或免费的 zplCloud 工具。

合规预检

ZplCompliance.Check 依据 8 个规则包中的 84 条规则检查标签：GS1 物流标签、含 GS1 Digital Link 的 Sunrise 2027、Amazon FBA、UPS MaxiCode、FedEx 和 DHL Paket 基础规则、UDI 以及 RFID/EPC。它测量的是渲染后的标签，而不是读取文本：以毫米计的 X 尺寸、条高、空白区、HRI 字符大小、AI 格式和校验位。每条检查结果都带有规则 ID、行号、位置和出处，可输出为文本、JSON、SARIF 2.1.0，或像上图那样的标注 PNG。下面是免费工具标签合规检查中的示例：

$ zplcore comply pallet.zpl --pack gs1-logistic --dpi 203
pallet.zpl:13:1: error ZPL3104: label 1 ^BC: X-dimension 0.25 mm (2 dot(s) at 203 dpi) is below the minimum 0.495 mm for logistic units (0.250 mm only if the unit is physically too small). [GS1 General Specifications 26.0 §5.12.3.5 Table 5-51]
    fix: Use ^BY4 or wider at 203 dpi.
pallet.zpl:15:1: error ZPL3106: label 1 ^BC: GS1-128 needs 10X quiet zones: the left quiet zone (30 dots = 3.754 mm) runs 20 dot(s) past the label edge. [GS1 General Specifications 26.0 §5.4.4.2, §5.4.6.3, Table 5-51]
    fix: Move the barcode or the neighbouring field, or reduce ^BY.
1 label(s) at 203 dpi, packs gs1-logistic GenSpecs 26.0 / LLG 1.3: 6 error(s), 0 warning(s), 2 info(s). Pre-check only, not a certification.

输出已缩略，只保留六个错误中的两个。Sunrise 2027 规则包检查零售收银台使用的二维条码，我们的文章 GS1 Sunrise 2027：收银台迎来二维条码对此有详细介绍。需要注意：这是一项预检，不是认证。它不能代替承运商或主管机构的审核，也不能代替对打印标签使用条码检测仪进行的检测。文档

扫描验证（Scan-proof）

ZplScanProof.Verify 用两个相互独立的解码器（zxing-cpp 和 ZXing.Net）从渲染出的位图中回读每一个条码，并将结果与字段数据比对。它测量 X 尺寸、空白区、条高、裁切和重叠，并给出 A 到 F 的等级：这是一项参照 ISO/IEC 15415/15416 的数字预检，按打印机分辨率计算。在免费工具条码扫描验证的示例中，四个条码都能解码，但其中两个会带来麻烦（输出已缩略）：

$ zplcore verify shelf.zpl --dpi 203
[0.0] ^BE EAN-13 line 7 at 8,80 (285×120 dots, 0°)
  status: Match   digital grade: F (0.0)
  SP1101 error: Quiet zone left: 2.7X, 11X required (ISO/IEC 15420 / GS1); limited by the label edge.
  SP1102 error: The symbol is cut off by the label edge (129 pixels of its ink lie outside ^PW/^LL).
[0.1] ^BQ QR Code line 8 at 600,10 (125×245 dots, 0°)
  status: Match   digital grade: D (1.0)
  SP1101 warning: Quiet zone bottom: 3X, 4X required (ISO/IEC 18004); limited by other ink.

Code 39 得到 A 级，但附带一条警告：旁边的文字“ART-4712”看起来像它的人工识读行，却与编码内容“ART-4711”不同。该等级不能代替对打印标签使用经过校准的条码检测仪进行的检测。文档

将 ZPL 转为可编辑的标签模型

Label.FromZpl 把现有 ZPL 转换为可编辑、可绑定数据的模板：文本、条码、图形、图像和 RFID 都成为带类型的元素，^FN 字段成为数据字段，^DF 格式成为模板。每个元素都与原件逐像素核对；测试语料库中的全部 318 个文件都能像素级精确地还原。以横幅中的运单标签为例：

$ zplcore import hero-label.zpl -o label.json --report
1 label(s), 203 dpi (LabelSize), fidelity 1,0000
  label 1: fidelity 1.0000 pixel-exact, 38 typed, 0 raw item(s)
  Info: Resolution detected as 203 dpi from the label width

zplCloud 正是用它把 ZPL 导入设计器（详见下文）。文档

标签内容识别与 GDPR 脱敏

ZplExtract 从 ZPL 中读取收件人、寄件人、带校验位的跟踪号、SSCC、GTIN、日期和重量，每一项都附带位置和置信度。对于上面的标签，它以 0.95 的置信度识别出收件人地址，从 GS1 AI (00) 中识别出校验位有效的 SSCC 340123450000000017，以及重量和日期。ZplRedact 在保持版式不变的前提下替换个人数据，包括 ^FX 注释、^DF/^XF 数据和二维条码内容，填入有效的虚拟条码，然后再次搜索：这张标签共执行 28 项操作，搜索 29 个值，剩余 0 个。它基于规则、无需联网；分享前请复核结果，图像中的文字不会被读取。文档

GS1 Digital Link 与 Sunrise 2027 迁移

ZplGs1Migration.Migrate 从 EAN/UPC、GS1-128、ITF-14 或 GS1 DataBar 中找到 GTIN，并在空白位置添加一个带 GS1 Digital Link URI 的 QR 码或一个 GS1 DataMatrix，同时预留空白区，并对结果进行 Sunrise 预检。这张标签上的批号和保质期取自 GS1-128（输出已缩略）：

$ zplcore gs1 migrate cheese.zpl -o cheese-2d.zpl
label 1: migrated – added a QR Code with GS1 Digital Link URI with GTIN 09506000134352 right of the EAN-13 (^BE, line 9), top-aligned with the bars
  uri: https://id.gs1.org/01/09506000134352/10/L2604?15=270331
sunrise pre-check of the migrated ZPL: 0 error(s), 0 warning(s), 0 info(s)

在 zplCloud 中，免费工具 Sunrise 2027 迁移可以在浏览器中完成同样的操作。它是迁移助手，不是认证。文档

RFID Studio

ZplRfid 按照 GS1 EPC Tag Data Standard 2.3 对 EPC 进行编码和解码（SGTIN、SSCC、SGLN、GRAI、GIAI 以及 TDS 2.0 的“plus”方案），并生成相应的 ^RF 命令。一致性检查会将标签芯片与打印出的标签进行比对。在下面的示例中，标签芯片写入的 SSCC 将与条码显示的不同：

$ zplcore rfid check carton.zpl
carton.zpl:6:1: error ZPL3904: label 1 ^RF: The SSCC-96 EPC encodes SSCC (00) 340123450000000024, but ^BC prints 340123450000000017. [GS1 EPC Tag Data Standard 2.3 §7 (correspondence of EPC and GS1 keys); GS1 General Specifications 26.0 §4.13]
    fix: Encode the printed key, e.g. ZplRfid.EncodeEpc("(00)340123450000000017…") or 'zplcore rfid encode'.

zplcore rfid simulate 会像 RFID 打印机那样，针对模拟的 Gen2 标签芯片执行标签中的 RFID 命令。文档

打印机孪生（Printer twin）

这张标签能在这款机型上打印吗？ZplPrinterTwin.Check 将标签与 24 个配置文件之一进行比对（包括 ZD421、ZD621、ZT411、ZT610、ZQ630 以及三个通用配置文件），报告超出打印头宽度的字段、缺少的选配件（如切刀或 RFID）、固件限制、字体和内存问题，并估算打印时间。配置文件中的每一项参数都有引用来源，或标注为未知。上面这张 4 × 6 英寸标签放到打印头宽 72 mm 的打印机上（共 21 条结果，此处显示一条）：

$ zplcore twin check hero-label.zpl --profile ZQ510-203
  ZPL5102 error (53:1): Label 1: ^BC ">;>800340123450000000017" at x=280 is 16 dots (2 mm) wider than the printhead of ZQ510-203 (576 dots = 72 mm): the right part is cut off; a clipped barcode does not scan.
ZQ510-203: 13 error(s), 8 warning(s), 0 info

文档

混沌打印机与切刀预览

ZplVirtualPrinter 监听 TCP 9100，渲染收到的作业，并像打印机一样响应 ~HS 和 ~HQES。它还能按需制造故障：缺纸或缺碳带、打印头打开、缓冲区已满、切刀卡纸、RFID 作废、连接中断、超时，全部可编写脚本并可复现：

printer.Faults.Schedule(ZplFaultKind.PaperOut, ZplFaultTrigger.AfterLabels(3)); // label 4 waits
printer.Faults.Seed = 42;                                                       // deterministic random triggers

切刀模拟会显示带切刀的打印机在哪里切割（^MM、^PQ、^CN、~JK 等），并把切割位置绘制到 PNG、SVG 和 PDF 预览中，如上图所示：^MMC 配合 ^PQ6,3，在第 3 张和第 6 张标签后切割。混沌打印机 · 切刀

Testing+ 与 GitHub Action

标签就是代码，那就像测试代码一样测试它。ZplCore.Testing 包支持 xUnit、NUnit 和 MSTest：

ZplAssert.Label(zpl)
    .NoOverlaps()
    .Complies(CompliancePacks.Gs1LogisticLabel)
    .Barcode("SSCC").Decodes("(00)376104250021234569").HasGrade(atLeast: 'B')
    .And.MatchesSnapshot("pallet");

测试失败时会指明元素、其位置和对应的 ZPL 行，并链接一张圈出该元素的图片。zplcore check 对大量文件执行同样的检查，并输出 JUnit XML、SARIF 和 Markdown。SDK 中附带的 GitHub Action 会在拉取请求中发表评论，附上修改前、修改后和差异图片，并列出变化内容。上面的图片就来自这样一次运行：一处修改把 SSCC 条码从 ^BY4 收窄为 ^BY3，并更改了其数据（输出已缩略）：

$ zplcore check labels/pallet.zpl --pack gs1-logistic --verify --baseline ../base
FAIL labels/pallet.zpl (1 label(s), 0.25 s) · changed vs baseline (3 element change(s))
  FAIL comply gs1-logistic
    labels/pallet.zpl:12:1: error ZPL3104: Label 1: X-dimension 0.375 mm (3 dot(s) at 203 dpi) is below the minimum 0.495 mm for logistic units (0.250 mm only if the unit is physically too small).
    labels/pallet.zpl:12:1: note ZT3001: Label 1: barcode ^BC Code128 at x=86 y=820: data "(00)376104250021234569" → "(00)376104250021234576"
FAILED (fail-on error)

文档

面向编程智能体的 MCP 服务器

zplcore-mcp 通过 Model Context Protocol 为 Claude Code、Claude Desktop、带 GitHub Copilot 的 VS Code 以及 Cursor 提供 26 个工具，包括渲染、lint 检查、格式化、差异比较、合规、扫描验证、脱敏、打印机孪生、GS1 和 RFID 等。智能体编写 ZPL、查看 PNG、读取诊断信息，并循环修正标签。

claude mcp add zplcore -- zplcore-mcp

该服务器专为不可信输入而设计。它只通过 stdio 通信，不开放任何网络端口。每次调用都在独立的工作进程中运行，有时间和内存限制，环境为空，无法访问文件、网络、打印机或环境变量；在 macOS 上还会额外启用操作系统沙箱。对抗性测试、模糊测试以及对程序集的 IL 审计会检查这些规则。文档

将 PDF 和 SVG 转为原生 ZPL（Vector-Lift）

Vector-Lift 把承运商和 ERP 生成的 PDF 或 SVG 转换为真正的 ZPL，而不是一张 ^GF 光栅图像：文字成为 ^A0 字段，条码经解码后重新生成为原生 ^B 命令并加以验证，线条和方框成为 ^GB、^GC 和 ^GE。每张标签都附带测得的保真度：

$ zplcore lift lift-label.svg -o lift.zpl --report
799x400 dots @ 203 dpi (default), fidelity 0.9785 (exact 0.9114), native ink 97.8 %, 370 bytes vs 4,140 bytes ^GF raster (8.9%)
4 native, 5 approximated, 0 raster, 1 dropped, barcodes match

文字使用字体 0 排版，而不是原始字体；在 PDF 中仅以轮廓形式存在的文字仍保留为图形（不做 OCR）。在 zplCloud 中，免费工具 PDF 转原生 ZPL 使用的就是它。文档

NativeAOT

SDK、测试包、CLI 和 MCP 服务器在构建时没有任何裁剪（trim）或 AOT 警告。CLI 和 MCP 服务器可以发布为原生程序，无需安装 .NET 运行时即可启动；冒烟测试会逐字节、逐像素地将其输出与 JIT 版本进行比较。文档

这对 zplCloud 用户意味着什么

你无需安装任何东西，zplCloud 现在已经运行在 zplCore.com 之上：

四款新的免费工具：标签合规检查、条码扫描验证、Sunrise 2027 迁移和 PDF 转原生 ZPL。这四款工具也都可以通过 zplCloud API 的 /v1/tools/… 调用。
预览即打印：PNG、SVG 和 PDF 预览渲染的，正是发送到打印机的同一段 ZPL。
更好的设计器导入：把 ZPL 导入设计器现在通过 Label.FromZpl 完成。在对 10 种语言、共 96 个模板进行 ZPL → 设计 → ZPL 的往返测试中，平均得分从 0.7707 提高到 0.9998，像素级精确的模板从 960 个中的 26 个增加到 911 个。
你已经熟悉的工具，如 ZPL Linter、ZPL 格式化工具、ZPL Diff 和条码检查，都使用同一个引擎。

即将推出：zplCore Server（Docker）

接下来，我们会把引擎打包成一个带 REST API 的现成容器：输入 ZPL，输出 PNG、PDF 或检查报告。计划提供适用于 linux/amd64 和 linux/arm64 的多架构镜像，基于 distroless，以非 root 用户和只读文件系统运行，提供 /health、/ready 和 /metrics（Prometheus）端点、OpenAPI 描述，以及附带 SBOM 的签名镜像。在我们于 linux/arm64 上进行的 NativeAOT 测试中，服务器约 4 ms 启动，约 11 ms 渲染出第一张标签，镜像大小约 100 MB。功能范围仍在规划中；你可以在 zplcore.com 订阅通知，首个版本就绪时我们会告诉你。

动手试试

在线演示：zplcore.com/en/demo 在浏览器中渲染 ZPL，并运行合规预检、扫描验证、GS1 迁移、信息提取与脱敏以及打印机孪生。
文档：zplcore.com/en/docs，包含 API、CLI、示例、精度说明和已知限制。
试用版：通过 zplcore.com 上的联系表单申请。开发团队会直接回复，也乐意帮你检查自己的 ZPL 和 EPL 文件。许可证面向企业客户（B2B）。
无需编写代码：免费的 zplCloud 工具运行在同一个引擎之上。

常见问题

zplCore.com 和 zplCloud 使用的是同一个引擎吗？

是的。zplCloud 使用 zplCore.com 渲染预览、PDF 和工具结果，新工具调用的也正是你在 SDK 中得到的那些功能。

zplCore.com 需要互联网连接或打印机驱动吗？

不需要。该库在你自己的进程中离线运行，支持 Windows、Linux 和 macOS。打印直接通过 TCP 9100、串口、USB、Windows 打印后台处理程序或 CUPS 进行。

合规预检和扫描等级算是认证吗？

不算。合规预检依据已公开的规则进行测试，扫描等级是一项参照 ISO/IEC 15415/15416 的数字预检。二者都不能代替承运商、主管机构或你所在的 GS1 成员组织的审核，也不能代替对打印标签使用经过校准的条码检测仪进行的检测。

zplCore.com 目前还做不到什么？

Pharmacode 2D、Response Plus PostMatrix 以及符合 ISO/IEC 15434 的 HIBC 尚未实现，因为没有公开的规范。Deutsche Post BZL 和 JAB Code 处于实验阶段。Zebra 的内置字体属于专有字体，由经过校准的替代字体代替；如果你需要完全相同的字形，请注册原始 TTF 字体。完整列表见已知限制。

我需要在 zplCloud 中做任何更改吗？

不需要。设计、模板、打印机和 API 调用都保持不变。

Zebra 和 ZPL 是 Zebra Technologies Corporation 的商标，GS1 和 GS1 Digital Link 是 GS1 AISBL 的商标，Neodynamic、ThermalLabel 和 ZPLPrinter 是其各自所有者的商标。本文仅以描述性方式使用这些名称。