我正在寫一個erlang模塊，它必須處理一些字符串，但不要太多，但是，我會執行一些tcp recv，然後對數據進行一些解析。默認Erlang二進制字符串
在匹配數據和操縱字符串時，我一直在使用二進制模塊，如binary:split(Data,<<":">>)，基本上一直使用<<"StringLiteral">>。直到現在，我還沒有遇到困難或從替代方案（使用列表）中缺少方法，除了可能添加< < >>以外，一切都很自然地出現，但我想知道這種處理字符串的方式是否可能有我不知道的缺點。
任何提示？
你需要非常清楚你的字符串是如何編碼到你的二進制文件中的。當您在代碼中執行< <「StringLiteral」>>時，您必須意識到這只是代碼點列表的二進制序列化。您的Erlang編譯器會將您的代碼讀取爲ISO-8859-1字符，因此只要您只使用Latin-1字符並且始終如此執行此操作，則您應該沒問題，但這對於國際化來說並不是非常友好。
這些天的大多數應用軟件應該更喜歡unicode編碼。對於前128個碼點，UTF-8與您的< <「StringLiteral」兼容，但對於第128個碼點不兼容，所以要小心。如果您在代碼中使用< <「StringLiteral」>>，您可能會對您在UTF-8編碼的Web應用程序中看到的內容感到驚訝。
有一個關於二進制支持的EEP提案，形式爲< <「StringLiteral」/ utf8 >>，但我認爲這不是最終的結果。
另外請注意，如果存在包含要拆分的IS0-8859-1字節的多字節字符，則您的二進制：split/2函數可能會在UTF-8中產生意外的結果。
有些人會認爲UTF-16是一種更好的編碼方式，因爲如果您假設或驗證不存在32位字符，則可以更有效地進行分析，並且可以更容易地按索引拆分。
應使用unicode module，但在使用文字時要小心。
唯一需要注意的是二進制是一個字節片段，而列表是一個unicode碼點列表。換句話說，後者自然是unicode，而前者要求你做某種編碼，通常是UTF-8。
據我所知，你的方法沒有缺點。
只要你和你的團隊記住你的字符串是二進制文件而不是列表，這種方法沒有固有的問題。事實上，Couch DB採用這種方法作爲優化，顯然支付了很好的紅利。
二進制文件是非常有效的結構來存儲字符串。如果它們長於64B，則它們也被存儲在進程堆外部，因此它們不是GC的對象（仍然由最後一次參考失敗時的參考計算得出）。不要忘記使用iolists進行連接，以避免在性能問題時進行復制。