ZWS：用零宽空格把短链接藏进文本里

零宽空格短链要解决什么问题

普通短链服务把长 URL 变成一串短字符，比如 bit.ly 或 t.cn。这些字符仍然可见，会打断文本的连贯性。ZWS 的思路不同：它把 URL 编码成零宽空格，这类字符在大多数渲染环境中不占宽度，肉眼根本看不见。结果是链接被“藏”进文本里，阅读时毫无痕迹，复制整段文字后粘贴到浏览器即可访问。这个项目面向两类人：一是想在签名档或文档里嵌入链接又不愿破坏版面的个人用户，二是需要把链接嵌入生成图片或 PDF 的工具开发者。ShareX 已经集成了 ZWS，说明它确实有实际用途，而不是概念玩具。

编码机制：把 URL 塞进零宽字符

根据 README 和项目结构，ZWS 使用零宽空格（U+200B）作为编码基础。具体做法是把原始 URL 的每个字符转换为二进制，再用零宽空格表示 0，用零宽非连接符（U+200C）表示 1，可能还包含零宽连接符（U+200D）作为分隔。编码后的字符串长度与 URL 的字节数成正比，所以短链接并不比原链接短，只是不可见。访问时，服务端解码这些字符，还原出原始 URL，再返回 302 重定向。这个机制决定了链接无法被肉眼识别，也无法手动输入，只能通过复制粘贴使用。与 Base62 或哈希短链不同，ZWS 不生成短码，而是把整个 URL 编码进字符序列，所以它没有数据库存储映射的需求，只需要解码和重定向。

部署与运行：自托管需要哪些组件

ZWS 是一个 TypeScript 项目，采用 monorepo 结构，包含 API 服务、schemas 包和 CLI 工具。要自托管，你需要克隆仓库，安装依赖，然后配置环境变量。根据仓库文件，它依赖 PostgreSQL 存储 URL 映射，Redis 用于缓存和统计。启动命令通常是 `yarn start` 或 `npm run start`，具体端口和数据库连接串通过 `.env` 文件配置。官方提供了 Docker 镜像，可以用 `docker-compose up` 一键启动，但需要预先准备 PostgreSQL 和 Redis 实例。API 文档位于 `/api-docs`，基于 OpenAPI 规范，方便客户端生成。部署难点在于零宽字符的处理：服务端必须正确解析 UTF-8 编码的请求路径，否则解码会失败。对于不熟悉 Node.js 和 Docker 的团队，部署成本不算低。

使用方式：API 与 CLI 的实际操作

ZWS 提供 REST API，核心端点有两个：`POST /api/v1/urls` 用于创建短链，请求体包含 `url` 字段，返回编码后的链接；`GET /api/v1/urls/:id` 用于访问，服务端解码并重定向。官方 CLI 工具 `@zws.im/cli` 可以简化操作，安装后运行 `zws shorten https://example.com` 即可生成短链，`zws open <short>` 会打开浏览器访问。统计端点 `/stats/shields/urls` 和 `/stats/shields/visits` 返回 JSON，符合 Shields.io 的 endpoint schema，可以直接生成徽章显示短链数量和访问次数。这些 API 设计得比较干净，但文档只覆盖了基本用法，没有提及错误处理和限流策略。实际使用时，你需要查看 OpenAPI schema 来确定具体的请求格式，因为 README 没有给出完整的 curl 示例。

局限：不可见链接的代价

ZWS 的核心特性也是它的最大缺陷。零宽字符在许多场景下会被过滤或替换，比如某些社交平台会剥离控制字符，邮件客户端可能显示为乱码，代码编辑器可能会高亮为不可见字符导致复制错误。如果接收方无法保留这些字符，链接就彻底失效。其次，链接无法记忆，也不能口头传播，用户必须复制完整文本，这在移动设备上尤其不便。另外，编码后的链接长度与原始 URL 成正比，对于超长 URL，编码结果可能超过 2000 字符，超出某些浏览器的 URL 长度限制，导致访问失败。最后，项目最后推送停留在 2021 年 11 月，之后没有活跃维护，依赖的安全更新可能缺失，对生产环境而言是个风险。

与常规短链服务的本质差异

对比 Bitly 或自建的 YOURLS，ZWS 走的是完全不同的路线。常规服务把 URL 映射到一个短码，例如 `https://bit.ly/3xYz`，短码可见、可记忆、可追踪点击量。ZWS 不生成短码，而是把整个 URL 编码成不可见字符，因此它没有数据库映射表，也不需要处理冲突，但代价是失去了可读性。常规服务提供管理后台、自定义别名、分析报表，ZWS 只有基础的统计计数，且通过 Shields 端点暴露，没有用户界面。如果你需要可分享、可追踪的链接，ZWS 是错误工具。如果你需要把链接嵌入到纯文本且不破坏格式，常规服务做不到，ZWS 是唯一选择。两者的适用场景几乎不重叠，选择取决于你对“短链”的定义。

维护与许可：Apache-2.0 下的风险

ZWS 采用 Apache-2.0 许可证，允许商用、修改和分发，只需保留版权声明并注明修改。这对集成到商业产品（如 ShareX）是友好的。但项目自 2021 年 11 月后没有新提交，最近发布的是 `@zws.im/schemas@1.0.5`，属于补丁级别更新。这意味着核心代码可能没有跟上依赖库的版本变化，潜在的安全漏洞或兼容性问题未修复。如果你打算自托管，需要自行审查依赖树，并可能 fork 后维护。升级成本方面，由于是 monorepo，更新需要同时处理 API 和 schemas 包，但因为没有活跃上游，实际升级频率很低，更多是初始部署时的配置成本。

编辑结论

ZWS 适合需要把链接藏进纯文本、且接收方能正常渲染零宽字符的场景，比如社交平台签名或文档内部引用。它不适合面向普通用户的公开分享，因为许多应用会过滤或显示为乱码，而且链接无法记忆或口头传播。在部署前，先确认目标平台的文本渲染是否保留零宽字符，并评估自托管时 Redis 与 PostgreSQL 的运维成本。若需要可读、可追踪的短链，应选择常规服务；若追求不可见，ZWS 是目前少见的开源实现，但请以 2021 年后的维护状态为准。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes