北京
在电话里报一串64位的十六进制密钥，对方记错一位就得重来。这是每个开发者都经历过的尴尬。一个名为Sing-song的实验性编码方案试图解决这个问题：把任意字节串编码成可以朗读的音节，让长数字和密钥真正"说"出来。
这个项目最初是为了给Nostr的npub密钥生成确定性的"用户名"。作者坦言，英语的发音规则太复杂，效果不算完美——"如果你能在电话里把一串字符串读给对方听，并确保对方完全记对"，这个目标还没完全实现。但如果全世界都说意大利语，Sing-song的价值会大得多。
核心设计：64个音节对应6位数据
Sing-song的核心机制很直接：用64个"辅音+元音"（CV）结构的音节，每个音节精确对应6位二进制数据。辅音和元音严格交替，没有辅音丛或尾辅音，发音规则固定且无例外。
字母表刻意排除了h、y、e三个发音不稳定的字母。每个字母只有一个固定发音，没有静音字母、没有双字母组合、没有依赖上下文的变音。重音固定落在第一个音节上。这种设计让编码结果即使有轻微口音差异，也能保证字母可区分。
前缀稳定与自定长：两个关键特性
Sing-song有两个值得注意的性质。第一是前缀稳定：输入共享前缀，编码结果也共享音节前缀。这意味着你可以像比较十六进制前缀一样比较编码后的音节串。第二是完整编码自带长度信息：保留字节长度和前导零字节，不需要外部元数据就能还原原始数据。
显示时每两个音节为一组（如zila-sibo），用连字符分隔作为自然的朗读停顿点。解析器必须忽略连字符——zilasibotivajuzu和zila-sibo-tiva-juzu是同一个编码。分组纯粹是装饰性的，不携带任何信息。
与Hex和Base58的取舍
相比机器友好的Hex和Base58编码，Sing-song牺牲了一些书写密度，换来了小而规则的发音语法。它保持确定性、可逆性，计算也足够简单。作者将其定位为"草稿"状态（v0.1.2），欢迎社区反馈。
这个方案的价值在于：当编码结果需要被人类口头传递时，一个能读出来的格式比一串难以发音的字符可靠得多。虽然目前的效果受限于英语发音的复杂性，但思路本身值得关注——尤其是对于需要人工核对长标识符的场景。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
