字符串长度的“多重宇宙”：从UTF-8到用户感知，语言设计与现实的博弈

在编程语言的字符串处理中，对“长度”的定义存在多种理解，从底层的UTF-8编码单元数（如Rust的`len()`返回17）到用户感知的字符单元（如Swift的`count`返回1），再到Unicode标量值（如Python 3的`len()`返回5）和UTF-16编码单元（如JavaScript的`.length`返回7）。这种差异源于对字符串内部表示和Unicode标准的解读不同。Rust通过`len()`方法提供UTF-8编码单元数，并可通过库实现对扩展字形簇（Extended Grapheme Clusters, EGC）的计数。Swift则将EGC计数作为默认的`count`方法，同时提供对Unicode标量值、UTF-16和UTF-8单元的访问。

深入分析显示，语言设计者在选择字符串长度的定义时，往往权衡了性能、兼容性与用户体验。例如，Rust将UTF-8编码单元长度存储在字符串对象中，以加速字符串连接等操作，而其他长度则按需计算。Swift的EGC优先策略，虽然提高了API的易用性，但可能引入与操作系统Unicode版本相关的潜在不一致性，尤其是在跨平台或服务器端应用中。C语言的长度计算方式则更为基础，依赖于空字符作为终止符，不存储长度信息，这为内存管理提供了灵活性，但也增加了计算长度的开销。

对长度定义的考量，最终指向了实际应用场景。如在用户界面显示估算、文本长度限制或国际化公平性考量时，不同长度定义会产生显著差异。研究表明，没有一种单一的长度度量能完全公平地反映信息量，尤其是在跨语言和脚本的比较中。UTF-8编码单元长度虽然在某些语言（如中文、日文）中比UTF-16/32更紧凑，但其“公平性”仍受限于语言本身的字符信息密度。因此，在设计系统时，明确所需长度的含义至关重要，避免因对“长度”的模糊理解而引入错误。

It’s not wrong that ”🤦🏼‍♂️”.length == 7

Henri Sivonen