Erlang двоичные строки по умолчанию

Question

Я пишу модуль erlang, который должен немного разбираться со строками, но не слишком много, однако я делаю tcp recv, а затем разбираю данные.

При сопоставлении данных и манипулировании строками я все время использую двоичный модуль, например binary:split(Data,<<":">>), и в основном использую <<"StringLiteral">> все время.

До сих пор я не сталкивался с трудностями или отсутствующими методами из альтернативы (используя списки), и все выходит вполне естественно, за исключением, возможно, добавления << >>, но мне было интересно, может ли этот способ иметь дело со строками Недостатки, о которых я не знаю.

Есть подсказка?

Answer 1

Пока вы и ваша команда помните, что ваши строки - это двоичные файлы, а не списки, при таком подходе нет никаких проблем. Фактически, Couch DB восприняла этот подход как оптимизацию, которая, очевидно, принесла хорошие дивиденды.

Answer 2

Вы должны очень хорошо знать, как ваша строка кодируется в ваших двоичных файлах.Когда вы делаете << "StringLiteral" >> в своем коде, вы должны знать, что это просто двоичная сериализация списка кодов.Ваш компилятор Erlang читает ваш код как символы ISO-8859-1, так что, если вы используете только символы Latin-1 и делаете это последовательно, у вас все будет хорошо, но это не очень благоприятно для интернационализации.

Большинство прикладных программ сегодня предпочитают кодировку Юникод.UTF-8 совместим с вашим << "StringLiteral" >> для первых 128 кодовых точек, но не для вторых 128, поэтому будьте осторожны.Вы можете быть удивлены тем, что видите в своих веб-приложениях в кодировке UTF-8, если в своем коде вы используете << "StrïngLïteral" >>.

Было предложение EEP о бинарной поддержке в виде << "StrïngLïteral "/ utf8 >>, но я не думаю, что это завершено.

Также имейте в виду, что ваша функция binary: split / 2 может иметь неожиданные результаты в UTF-8, если есть многобайтовый символкоторый содержит байт IS0-8859-1, на который делится.

Некоторые утверждают, что UTF-16 - лучшая кодировка для использования, поскольку она может быть проанализирована более эффективно и ее легче разделить по индексу,если вы предполагаете или проверяете, что 32-разрядных символов нет.

Следует использовать модуль Unicode , но при использовании литералов следует соблюдать осторожность.

Answer 3

Единственное, о чем следует знать, это то, что двоичный файл представляет собой фрагмент байтов, а список - это список кодовых точек Unicode. Другими словами, последний, естественно, является юникодом, тогда как первый требует, чтобы вы выполняли какое-то кодирование, обычно UTF-8.

Насколько мне известно, у вашего метода нет недостатков.

Answer 4

Двоичные файлы - очень эффективные структуры для хранения строк.Если они длиннее 64B, они также хранятся вне кучи процесса, поэтому они не являются объектом GC (все еще GC ', считая счет, когда последний ref потерян).Не забудьте использовать iolists для объединения их во избежание копирования, когда производительность имеет значение.