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