我正在编写一个 erlang 模块，它必须处理一些字符串，但不多，但是，我做了一些 tcp recv 然后对数据进行一些解析。
在匹配数据和处理字符串时，我一直在使用二进制模块，比如binary:split(Data,<<":">>)，基本上一直在使用<<"StringLiteral">>。
到目前为止，我还没有遇到替代方法（使用列表）的困难或缺少方法，除了添加 > 之外，一切都很自然，但我想知道这种处理字符串的方式是否可能我不知道的缺点。
有什么提示吗？
【问题讨论】：
唯一需要注意的是，二进制是字节切片，而列表是 unicode 代码点列表。换句话说，后者自然是 unicode，而前者需要你进行某种编码，通常是 UTF-8。
据我所知，您的方法没有缺点。
【讨论】：
只要您和您的团队记住您的字符串是二进制而不是列表，这种方法就没有固有的问题。事实上，Couch DB 将这种方法作为一种优化，显然带来了不错的收益。
【讨论】：
二进制文件是存储字符串的非常有效的结构。如果它们长于 64B，它们也存储在进程堆之外，因此它们不是 GC 的对象（当最后一个 ref 丢失时，仍然通过 ref 计数进行 GC）。不要忘记使用 iolist 将它们连接起来，以避免在性能很重要时复制。
【讨论】：
您确实需要非常了解您的字符串在二进制文件中的编码方式。当您在代码中执行 > 时，您必须意识到这只是代码点列表的二进制序列化。您的 Erlang 编译器将您的代码读取为 ISO-8859-1 字符，因此只要您只使用 Latin-1 字符并始终如一地执行此操作，就可以了，但这对国际化不是很友好。
如今，大多数应用软件应该更喜欢 unicode 编码。 UTF-8 与前 128 个代码点的 > 兼容，但与后 128 个代码点不兼容，所以要小心。如果您在代码中使用 >，您可能会对在 UTF-8 编码的 Web 应用程序中看到的内容感到惊讶。
有一个以 > 的形式支持二进制的 EEP 提案，但我认为这还没有最终确定。
另外请注意，如果存在包含要拆分的 IS0-8859-1 字节的多字节字符，则您的 binary:split/2 函数在 UTF-8 中可能会产生意外结果。
有些人会争辩说 UTF-16 是一种更好的编码，因为如果您假设或验证没有 32 位字符，它可以更有效地解析并且更容易按索引拆分。
应该使用unicode module，但在使用文字时要小心。
【讨论】：