很多电商、仓储、物流系统里都有一个不太显眼但很实际的问题：系统生成的是 ZPL 或 EPL 这种热敏标签语言，但开发、测试和客服同事想看的却是图片或 PDF。真正接一台 Zebra 打印机来预览当然可以，但这对 CI、远程调试和批量校验都不友好。

今天推荐的 GOODBOY008/labelize 正是在解决这个问题。它是一个用 Rust 写的开源标签渲染器，可以解析 ZPL 和 EPL，把标签渲染成 PNG 或 PDF，也可以作为命令行工具、HTTP microservice 或 Rust library 使用。目前项目在 GitHub 上约有 27 stars，属于很小众但问题定义清楚的开发者工具。

项目概览

属性详情
仓库GOODBOY008/labelize
Stars约 27
Forks11
主要语言Rust
许可MIT
Crates.io 最新版本0.5.0
创建时间2026 年 3 月 18 日

它解决什么问题

ZPL 是 Zebra 打印机常见的标签语言，EPL 则来自 Eltron 系列设备。很多业务系统会直接生成这类文本，然后把它发给打印机。但在开发阶段，团队经常需要回答一些更朴素的问题：

  • 这张面单上的地址有没有换行错位？
  • 条码是否被渲染出来？
  • 仓库系统生成的 EPL 模板能不能被正常预览？
  • 能否在 CI 里对标签输出做 golden-file 测试？
  • 能否不用外部 SaaS，把标签预览能力放在内网服务里？

Labelize 的价值就在这里：它把这些打印机语言变成普通开发工具链可以处理的 PNG 或 PDF。你可以在本机转换，也可以把它跑成一个 HTTP 服务，让业务系统 POST 一段 ZPL/EPL 后直接拿到渲染结果。

三种使用方式

Labelize 的 README 把使用方式分成三个层次。

第一种是 CLI，适合开发者本地调试：

labelize convert label.zpl
labelize convert label.epl
labelize convert label.zpl -t pdf
labelize convert label.zpl --width 100 --height 62 --dpmm 12

第二种是 HTTP 服务：

labelize serve --port 8080
curl -X POST http://localhost:8080/convert \
  -H "Content-Type: application/zpl" \
  -d '^XA^FO50,50^A0N,40,40^FDHello World^FS^XZ' \
  -o label.png

这对内部工具很有用。比如订单系统、WMS、测试平台都不需要自己引入 Rust crate，只要把标签文本发给一个统一服务即可。

第三种是 Rust library。如果你本来就在写 Rust 服务，可以直接调用解析器和渲染器，把输出写入内存 buffer 或文件。

支持范围

从 README 看，Labelize 目前支持 30 多个 ZPL 命令，覆盖文字、字体、图形、存储格式、标签控制和多种条码。条码方面包括 Code 128、Code 39、EAN-13、Interleaved 2-of-5、PDF417、Aztec、DataMatrix、QR Code 和 MaxiCode。

EPL 支持范围更小一些，但覆盖了新建标签、文字、条码、画线、参考点和打印命令。对很多基础面单和仓储标签来说，这已经足够进入可用范围；复杂模板仍然需要用真实样本验证。

输出格式方面，它可以生成单色 1-bit PNG，也可以生成单页 PDF。项目还内置了 Helvetica Bold Condensed、DejaVu Sans Mono 和 ZPL GS fonts，减少部署时的字体依赖。

为什么离线渲染重要

这类工具最直接的替代方案是在线服务，例如 Labelary。在线服务很方便，但在业务系统里可能会遇到几个限制：

  • 标签里可能包含收件人、地址、电话、订单号等敏感信息。
  • 批量测试和 CI 调用外部服务时，速度、稳定性和限流都不可控。
  • 内网系统有时不能直接访问公网。
  • 团队可能希望把渲染结果纳入自动化测试，而不是依赖人工预览。

Labelize 的定位不是“做一个漂亮的标签设计器”，而是把渲染能力做成可嵌入、可自托管、可自动化的基础组件。

测试和渲染质量

README 里提到，项目用 Labelary 参考渲染器生成的 PNG 做 golden-file e2e 测试，并维护了差异报告。项目列出的当前测试结果是 83 个标签样本，其中 6 个 perfect、27 个 good、39 个 minor、11 个 moderate、0 个 high。

这些数字应该按“项目自己的回归基准”来看，而不是独立第三方评测。但它们至少说明作者不是只做了一个 parser demo，而是在用样本集持续比较渲染结果。

README 还给出了一组性能对比：同一批标签上，Labelize 平均渲染时间约 5 ms，Labelary API 约 388 ms。这个结果同样来自项目文档，实际业务里还要结合标签复杂度、机器配置和服务部署方式重新测。

适合放在哪里

我觉得 Labelize 最适合的场景有几类：

  • 开发预览：前后端或后端同事在本地快速检查 ZPL/EPL 输出。
  • CI 校验：把关键标签模板渲染成图片，与基线文件做比较。
  • 内部微服务：给多个业务系统提供统一的标签转换接口。
  • 客服和运营工具：不用连接打印机，也能预览客户实际收到的面单。
  • 归档流程：把标签文本批量转成 PDF，和订单记录一起保存。

如果你的系统已经高度依赖打印机厂商 SDK，Labelize 未必能立刻替代所有能力。但如果你只是需要“把标签文本可靠地看见”，它的部署成本会低很多。

需要注意的地方

项目还很新，star 数也不高。引入生产系统之前，最好先拿自己的真实标签样本做一轮验证：

  • 常用 ZPL/EPL 命令是否全部支持；
  • 条码、中文字体、旋转、反白、图片字段是否符合预期；
  • PDF 和 PNG 的尺寸、DPI、边距是否匹配打印流程；
  • HTTP 服务在批量转换时的吞吐和内存占用是否稳定；
  • 许可证和依赖是否符合公司规则。

尤其是标签打印这种场景，视觉上差几毫米就可能影响扫码和贴纸位置。它很适合先作为预览、测试、归档工具落地，再逐步评估能否进入更关键的打印链路。

总结

Labelize 有意思的地方，是它把一个很垂直、很工程化的问题做成了普通开发者工具。ZPL/EPL 渲染不属于每天都会被讨论的热门话题，但一旦你维护过物流、仓储、电商或硬件相关系统，就会知道这种工具能省掉很多手工预览和外部服务依赖。

如果你正在处理热敏标签、面单模板、仓储打印或相关的自动化测试，GOODBOY008/labelize 值得放进工具箱里试一试。

项目地址：https://github.com/GOODBOY008/labelize