erlang - String.to_atom 将底层 erlang.binary_to_atom 编码选项硬编码为 :utf8, 为什么？

Question

为什么 String.to_atom 将编码选项硬编码为 :utf8 ？

https://github.com/elixir-lang/elixir/blob/d6bb3342b7ea8b921b3d4b69f65064c4158c99d7/lib/elixir/lib/string.ex#L1927
def to_atom(string) 做
:erlang.binary_to_atom(字符串, :utf8)
结尾


erlang binary_to_atom 的可用编码选项是:

latin1 |统一码 | utf8
http://erlang.org/documentation/doc-8.0-rc1/erts-8.0/doc/html/erlang.html#binary_to_atom-2

Answer 1

长话短说

因为 Erlang 宇宙终于在所有地方都采用了 UTF-8。

讨论

latin1 即将消失，主要是 UTF-8 的子集(少数字符除外)，unicode 是 utf8 的旧别名>，这给我们留下了一个普遍适用的选项:utf8。这很重要，因为 UTF-8 原子(和字符串)是 Erlang 和 Elixir 中的前进方向。

如果您处理的是非 UTF-8 编码的旧数据，则在调用 binary_to_atom/2 之前转换它。

这也符合 Erlang 标准库中较新的 string 和 unicode 模块的变化——它们可以最终解决 UTF-经过几十年的不确定性(因为编码很难并且在发明 Erlang 时对此并没有达成太多共识)，8 成为了一个普遍接受的标准。

关于编码实践的一句话

我在日本工作，主要处理业务数据，其中一些很旧，还有一些采用非常疯狂的编码。我倾向于主要使用 Erlang 编写代码(我更喜欢微型语言)。当编写一些较旧的字符串处理函数和 unicode 模块时，字符串分为两类:

• ASCII 中的代码点列表(在相当多的时间里，它被隐式扩展以包含 latin1，因为欧洲语言很常见，而 CJK 当时一团糟)
• 龙火僵尸和冰霜僵尸的一些醒着的噩梦(因为在其他任何事情上都没有达成一致，并且有大量根本不完整、半生不熟、技术上不准确的“标准”)

时代变了。现在我们知道字符串几乎总是采用 UTF-8 并且 Unixverse 中的所有内容最终都解决了这个问题，这产生了令人愉快的效果(几乎)所有其他有意义的系统也解决了这个问题(如果不是在内部) ，然后通过可以在 UTF-16 和 UTF-8 之间进行选择的强大检测库)。

如果您确实拥有非 UTF-8 数据，那么您就知道是这种情况，并且应该在将数据发送到通用函数之前转换您的数据例如 binary_to_atom/2。实际上，我认为我们接下来应该转向包括 binary_to_atom/1 并完全淘汰 binary_to_atom/2 -- which is what has already happened with list_to_atom/1从 Erlang R20 开始(耶!)。

那么这对您的代码有何影响？

当您开始处理古老的编码时，您的代码的复杂性突然爆发，需要立即加以控制，以免它以疯狂的方式感染您的整个代码库。做到这一点的最好方法是让疯狂的业务系统保持正常，并在边缘进行转换。每当我们处理以疯狂编码形式出现的旧数据时，我们已经知道并为此做好了准备——所以我们会在前面明确地转换为 UTF-8，这样以后就不会遇到任何问题在系统的更深处。

您可能会想，“他们为什么不检测每个字符串的编码呢？”唉，没有合适的方法来检测字符串编码。只是高度自信是不可能的。在大多数情况下，它也很快成为一项过时的任务，因为今天生成的绝大多数数据都是 UTF-8(或 UTF-16，但很少通过网络遇到这种情况)。