Какой символ (ы) разделитель / разделитель лучше всего подходит для простого файла БД?

Question

Какой символ (ы) разделитель / разделитель лучше всего подходит для простого файла БД?

Я подумал об использовании |, ,, <TAB>, ; и т. Д. Но все они могут быть повреждены, когда у соседних записей есть достаточно специальные символы.

Итак, опытные пользователи базы данных, какой символ (ы) разделителя вы предлагаете использовать?

Answer 1

Я думаю, что лучший способ соединить строку с тремя вишнями '@@@'.

Answer 2

Независимо от того, какой символ вы выберете в качестве разделителя, вы захотите экранировать любой экземпляр этого символа в ваших данных.

Возможно, тильда (~) или переход к символу с высоким ASCII.

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

Answer 3

Ну, в US-ASCII есть несколько разделителей символов , шестнадцатеричные 1c, 1d, 1e и 1f.Простой текст не должен содержать их.

1c  FS  ␜  ^\  File Separator
1d  GS  ␝  ^]  Group Separator
1e  RS  ␞  ^^  Record Separator
1f  US  ␟  ^_  Unit Separator

Answer 4

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

При создании исходного файла с разделителями мы удалили все █ (alt + 219) в данных и использовали этот символ для разделителя. Бонус, этот персонаж действительно легко обнаружить.

Answer 5

Лично мне нравится использовать «в качестве символа-разделителя для разделения данных в файлах CSV, я не думаю, что когда-либо встречал естественный экземпляр« и »лично, поэтому вот мои два цента об этом».

Answer 6

Вы можете использовать специальные символы-разделители (шестнадцатеричные 1c -> 1f), но они не пригодны для печати, и некоторые технологии имеют проблемы с обработкой содержащих их данных.

Итак, планируйте B, если ваши данныев UTF-8 вы можете выбрать случайный символ UTF-8, который чрезвычайно вряд ли появится в любых исходных данных, которые вы получите.

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

Я склонен ненавидеть инкапсуляцию со страстью и избегать ее всякий раз, когда это возможно, как объяснено в моем посте в главе «Инкапсуляция» здесь: https://theonemanitdepartment.wordpress.com/2014/12/15/the-absolute-minimum-everyone-working-with-data-absolutely-positively-must-know-about-file-types-encoding-delimiters-and-data-types-no-excuses/

Answer 7

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

Answer 8

Я обычно предпочитаю непечатаемые символы, такие как «\ u0001», например, я использую это как разделитель столбцов в большинстве моих сценариев U-SQL Azure Data Analytics.Это предполагает, что вы можете использовать многосимвольный пользовательский разделитель

Answer 9

Ранее я использовал конвертер ePUB, и символ разделителя был символом кавычки, где бы он ни использовался, он будет переписан в файл как @, простой, но эффективный, даже если он уничтожит производимый образец материала. 1001 *

Answer 10

Если вы не можете контролировать вводимые в него данные, не используйте простой текстовый db.Здесь не может быть вообще правильного ответа.Без контекста или ограничений это неверный вопрос.

То есть: если бы я сказал, что собираюсь принимать только строчные буквы в качестве данных, я мог бы использовать любой другой символ в качестве разделителя.Даже, скажем, номер 9, и я буду в порядке.Ни один символ, кроме символа нижнего регистра, не будет лучше, чем любой другой.

И наоборот, если сказано, что я могу принять любой символ, у меня не останется символов для разделителя, и у меня останется очень печальная база данных, которая может хранить только одно значение.

Если вам нужно слишком сильно постараться, чтобы превратить ваш БД в простой текст, вам, вероятно, нужен двоичный БД.Вы смотрели на sqlite?Он чертовски прост в использовании, доступен во многих контекстах и ​​имеет массу преимуществ по сравнению с обычным текстом.