punycode 发布 v0.15.0
Source: Dev.to
背景
我想整理一下自己的多个 GitHub 仓库，但一个旧的 issue 和一个旧分支引起了我的注意。
该 issue（#34）涉及 punycode 与某些 Unicode 字符的问题，特别是包含零宽连接符（Zero Width Joiner，ZWJ）的表情符号。
Issue 描述
问题：
包含零宽连接符的 Punycodes/表情符号未被正确处理。
xn--8k8hlfr9n应该是 🧑🏾🎨，而不是 🧑🏾🎨。
🧑🏾🎨 的 punycode 显示为xn--1ug6825plhas9r，而不是xn--8k8hlfr9n。
ZWJ 用于通过将多个字符连接在一起创建复合字符。在本例中，它将基字符 (🧑🏾) 与附加字符 (🎨) 组合成单一的复合字符 🧑🏾🎨。
实现的修复
我发现现有的 punycode 实现没有在编码和解码时考虑 ZWJ。于是对编码和解码函数进行了修改，使其能够正确处理 ZWJ。
测试
修改后，我使用了包含 ZWJ 的各种输入对更新后的实现进行了测试。测试结果表明问题已解决，生成了正确的 punycode 表示。
更新后的 CLI 输出
在最新的更新中，CLI 现在能够产生预期的结果。
./punycode xn--8k8hlfr9n
🧑🏾🎨./punycode xn--1ug6825plhas9r
🧑🏾🎨我将解码结果与多个在线实现进行比对，结果一致。
讨论
原始 issue 中写道：
xn--8k8hlfr9n应该是 🧑🏾🎨，而不是 🧑🏾🎨- punycode 🧑🏾🎨 显示为
xn--1ug6825plhas9r，而不是xn--8k8hlfr9n
我的客户端将 xn--8k8hlfr9n 解码为 🧑🏾🎨，而报告者期望的是 🧑🏾🎨。由于在线工具的输出与我的客户端一致，我将该 issue 标记为 won’t fix，并说明报告者可能把期望写反了。如有需要，我欢迎进一步的说明。
项目背景
这个工具是在学习 Go 的过程中创建的。凭借十多年在 DNS 与域名管理方面的经验，我觉得在自己熟悉的领域做一个工具很自然。
本仓库涉及的关键主题包括：
- 使用 Go 构建 CLI 工具
- 创建可分发的可执行文件
- 从命令行和 STDIN 读取数据
- 测试 CLI 工具以及
main函数
该仓库可能永远不会完美，但它已经达到了预期目的。另一种做法是仅限处理 DNS 相关的 Unicode 子集，而这本身就是一个深不见底的兔子洞。
贡献
欢迎提出建议、想法或改进。请在仓库中打开 issue 或提交 pull request。
发布
我发布了 v0.16.0，以确保与最新的 Go 版本和模块兼容。