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

Question

РЕДАКТИРОВАТЬ: обратите внимание, что из-за того, как жесткие диски фактически записывают данные, ни одна из схем в этом списке не работает надежно.Не используйте их.Просто используйте базу данных.SQLite - хороший простой.

Какой самый технологичный, но надежный способ хранения кортежей строк UTF-8 на диске?Для надежности хранилище должно быть только для добавления.

Как часть системы хранения документов, с которой я экспериментирую, мне нужно хранить данные кортежа UTF-8 на диске.Очевидно, что для полноценной реализации я хочу использовать что-то вроде Amazon S3, Project Voldemort или CouchDB.

Однако на данный момент я экспериментирую и даже не до конца остановился на программировании.языка пока нет.Я использую CSV, но CSV, как правило, становятся хрупкими, когда вы пытаетесь сохранить странный юникод и неожиданные пробелы (например, вертикальные табуляции).

Я мог бы использовать XML или JSON для хранения, но они не играют хорошос файлами только для добавления.Мое лучшее предположение до сих пор - довольно специфический формат, где каждой строке предшествует 4-байтовое целое число со знаком, указывающее количество байтов, которые он содержит, а целочисленное значение -1 указывает, что этот кортеж завершен - эквивалент новой строки CSV,Основным источником головной боли является необходимость выбора порядкового номера целого на диске.

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

Редактировать 2: оказывается, что гарантируется атомарность при добавлении в текстовые файлы,но парсер совсем нетривиален.Написание указанного синтаксического анализатора сейчас.

Редактировать 3: Конечный результат можно посмотреть на http://github.com/MetalBeetle/Fruitbat/tree/master/src/com/metalbeetle/fruitbat/atrio/.

Answer 1

Я бы порекомендовал табуляцию, разделяющую каждое поле, и возврат каретки, разделяющий каждую запись.

Внутри каждой строки замените все символы, которые будут влиять на поле, запишите интерпретацию и рендеринг. Это будет включать управляющие символы (U + 0000 – U + 001F, U + 007F – U + 009F), неграфические разделители строк и абзацев (U + 2028, U = 2029), управляющие символы направления (U + 202A – U +) 202E) и метка порядка байтов (U + FEFF).

Их следует заменить escape-последовательностями постоянной длины. Экранирующие последовательности должны начинаться с редкого (для вашего приложения) символа. Сам символ выхода также должен быть экранирован.

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

Это также было бы легко закодировать, так как файл будет действительным документом UTF-8, поэтому можно использовать стандартные процедуры чтения и записи текста. Это также позволяет легко конвертировать в UTF-16BE или UTF-16LE, если это необходимо, без осложнений.

Пример:

U+0009 CHARACTER TABULATION becomes ~TB
U+000A LINE FEED            becomes ~LF
U+000D CARRIAGE RETURN      becomes ~CR
U+007E TILDE                becomes ~~~
etc.

Есть несколько причин, по которым вкладки будут лучше запятых в качестве разделителей полей. Запятые чаще встречаются в обычных текстовых строках (таких как текст на английском языке), и их придется заменять чаще. А программы для работы с электронными таблицами (такие как Microsoft Excel), как правило, обрабатывают файлы с разделителями табуляции гораздо естественнее.

Answer 2

Здесь мыслят в основном вслух ...

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

Возможно, можно использовать SCSU вместе с этим.

Или, возможно, стоило бы взглянуть на формат gzip , а может, и обезопасить его, если он не используется:

GZIP-файл состоит из серии «членов» (сжатых наборов данных).

[...]

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

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

Или вы можете использовать bencode , используемый в torrent-файлах. Или BSON .

См. Также Сравнение форматов сериализации данных в Википедии .

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