Хранение двоичных данных в строках - идеологически неправильно?

Некоторые языки программирования имеют поддержку строк, которые хранятся в folows: Хранение двоичных данных в строках - идеологически неправильно?

Например, AnsiString типа в Delphi. Эти строки удобно управляются, и можно подумать, что это хорошая идея использовать их в качестве контейнера для двоичных данных, так как есть некоторые эффективные операции по конкатенации, извлечению подстроки и т. Д.

Как-то у меня сильное чувство, что используя строковый тип, даже если он двоично-безопасный, для хранения двоичных данных идеологически неправильно, но я не могу найти никаких убедительных аргументов для защиты этой позиции.

Конечно, на таких языках, как PHP, где использование массивов фактически добавляет слишком много служебных данных (каждый член массива в PHP занимает около 50 байт памяти из-за хэшированного характера массивов), у вас нет другого выбора, кроме как использовать строки как двоичные контейнеров данных. Но что касается Delphi или C++ (с его std :: string), я думаю, что сохранение двоичных данных в строках (например, ключи шифрования шифрования или любой буфер двоичного протокола) неверно, даже если у вас есть техническая возможность сделать это.

Как вы думаете? Есть ли аргументы против хранения двоичных данных в строках?

источник

2010-07-15 Vladislav Rastrusny

Можно утверждать, что в C все строки являются только двоичными данными, а двоичные данные «строки» довольно распространены. Но опять же, строки C - это всего лишь частный случай байтовых массивов. –

Да, вы правы. Но я не говорю о C здесь. Ах ... В Cактивно, все просто память, вы знаете;)) Никаких типов вообще;) :) –

Извините за то, что написал по старому вопросу, но если у меня есть строка «001», и я хочу сохранить его в двоичный файл или файл .dat, как я могу просто вывести строку как 3 бита вместо двоичного представления строки? –

Строки предназначены для обработки текста, а не двоичных данных. Таким образом, некоторые реализации строк могут принимать определенные свободы и не хранить данные по мере их ввода (например, преобразования в юникоде).

EDIT: Для уточнения, выше комментарий, я не говорю о каком-либо конкретном языке, но тот факт, что некоторые реализации струнные (в языках, где строки являются не просто символьные массивы) внутри хранить данные по-разному, поэтому, даже если вы создаете строку из массива байтов, внутренне она может быть сохранена как двухбайтовый массив. Кроме того, во многих языках строки неизменяемы, что обычно не то, что вы хотите, когда имеете дело с необработанными данными.

В любом случае, я не могу придумать ни одного языка, который имеет приличные реализационные строки, но не векторную реализацию. Почему бы не использовать это вместо вашего контейнера?

EDIT: Правда, большинство языков не позволит вам переопределять операторы для массивов/векторов и по уважительной причине (но это еще одно обсуждение). Но кроме этого, у вас должно быть все, что вам нужно, даже если оно имеет немного менее синтаксический сахар.

источник

2010-07-15 07:19:33

Python 2.x имеет достойную реализацию строки, но у него нет отдельного типа для байтов длины произвольной длины, поэтому тип 'str' часто используется для обоих (хотя текстовые строки, вероятно, должны быть вместо типа' unicode') , Пока вы не пытаетесь преобразовать свои данные в Юникод, вы в безопасности. Я почти уверен, что у Perl есть схожая семантика, но я не вспоминаю об этом. –

например, Delphi имеет массивы (как векторные, так и многомерные). Но не имеет перегрузки оператора, поэтому вы просто не можете писать ArrBig = Arr1 + Arr2, например. Многие программисты, которых я знаю, предпочитают бинарные строки над массивами, но я не знаю полного списка причин BTW –

+1 для «синтаксического сахара» – MrJD

В зависимости от языка. Если он позволяет делать все возможное с помощью строки, например, с целым числом, почему бы не сохранить ее в int? в противном случае, для конкатенации и любой другой утилиты это может показаться и чувствовать себя не так, но строки могут быть единственным вариантом.

источник

2010-07-15 07:12:13 OddCore

Хранение двоичных данных в строках - идеологически неправильно?

ответ

Смежные вопросы