Почему я должен использовать читаемый человеком формат файла?

Question

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

EDIT: Я имел это в качестве объяснения при первоначальной публикации вопроса, но сейчас это не так актуально:

При ответе на этот вопрос Я хотел отослать спрашивающего к стандартному SO-ответу о том, почему использование читаемого человеком формата файла является хорошей идеей. Тогда я искал один и не мог найти. Так вот вопрос

Answer 1

Функциональная совместимость является стандартным аргументом, т. Е. Удобочитаемая форма проще для разработчиков разрозненных систем, поэтому она дает некоторое преимущество.

Лично я думаю, что это не так, и преимущества бинарных файлов должны превосходить этот аргумент, особенно если вы публикуете свой протокол. Однако повсеместное распространение основанных на XML / HTTP фреймворков для машинных взаимодействий означает, что их легче принять.

XML слишком часто используется.

Answer 2

Просто быстрая иллюстрация, где читабельный формат документа может быть лучшим выбором:

документы, используемые для развертывания приложения в производстве

Раньше у нас были заметки о выпуске в текстовом формате, но этот документ с заметками о выпуске приходилось открывать в различных средах (Linux, Solaris) в форме подготовки и производства. Его также нужно было проанализировать, чтобы извлечь различные данные.

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

Answer 3

Никто не сказал, так что я скажу: удобочитаемость на самом деле не является свойством формата файла (все файлы являются двоичными в конце концов), а скорее комбинацией формата файла и приложения просмотра.

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

Стандарты кодирования текста широко распространены и достаточно зрелы, что означает, что они вряд ли будут развиваться в обозримом будущем.

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

Отсюда и преимущества «читабельных» форматов:

• Повсеместное распространение подходящих зрителей и редакторов.

• Вневременность (учитывая, что культурные традиции не сильно изменятся).

• Легкость в освоении, чтении и изменении.

Использование дополнительного слоя абстракции позволяет создавать текстовые файлы:

• Пространство голодно.

• Медленнее обрабатывать.

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

• Ускоренная обработка.

• Меньшая площадь.

С другой стороны:

• Средства просмотра и редакторы предназначены для конкретного двоичного формата и затрудняют взаимодействие.

• Средства просмотра для любого данного формата менее распространены, потому что они более специализированы.

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

Answer 4

Найдите минутку и подумайте о приложении ДРУГОЕ, чем веб-разработка.

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

B) Вывести его в текст легче. Ненужные преобразования, которые на самом деле требуют больше кода, делают систему менее надежной. В том-то и дело, что если вы НЕ используете язык, который рассматривает все переменные как строки, то читаемый человеком текст является дополнительным преобразованием. И.Е. Дополнительный код означает больше кода, подлежащего проверке, тестированию и больше возможностей для внесения ошибок в приложение.

C) Вы все равно должны это проанализировать. Во многих случаях для DSP-систем, над которыми я работал (т. Е. НЕТ удобочитаемого интерфейса для начала). Данные передаются из системы в пакетах одинакового размера. Регистрация данных для анализа и последующей обработки - это просто указание на начало буфера и запись кратного размера блока в систему регистратора данных. Это позволяет мне анализировать данные «нетронутыми» так, как их увидит система клиента, и, опять же, преобразование их в другой формат может привести к возможным ошибкам. Более того, если вы сохраните только «преобразованные данные», вы можете потерять информацию в переводе, которая может помочь вам диагностировать проблему.

D) Текст - это естественный формат данных. Никакое оборудование, которое я когда-либо видел, не использует интерфейс «TEXT». (Моей первой работой после окончания колледжа было написание драйвера устройства для камеры с линейным сканированием камеры.) Система, созданная на ее основе, МОЖЕТ, но для каждого «ПК».

Для веб-страниц, где информация имеет «естественное» значение в текстовом формате, поэтому постарайтесь себя вырубить. Для обработки исходного кода это, конечно, не сложно. Но во всепроникающих вычислительных средах, где даже у вас холодильник и TOOTHBRUSH будет встроенный процессор, не так уж и много. Простое обременение этих типов систем дополнительными возможностями по обработке текста вносит ненужную сложность. Вы не собираетесь связывать «printf» с программным обеспечением для 8-битного микро, который управляет мышью. (И да, кто-то тоже должен писать это программное обеспечение.)

Мир - это не черно-белое место, где единственными формами вычислений, которые необходимо учитывать, являются ПК и веб-серверы.

Даже на ПК, если я могу напрямую загрузить данные непосредственно в структуру данных, используя один вызов чтения из ОС, и выполнить это без написания процедур сериализации и десериализации, это фантастика, проверить работу CRC-блоков - выполнено следующая проблема.

Answer 5

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

Например,

• JSON вполне читабелен даже в текстовом формате
• XML имеет налог на угловую скобку , но его можно использовать при использовании хорошего редактора
• INI в основном читается человеком
• CSV может быть читаемым, но лучше всего при загрузке в электронную таблицу.

Answer 6

Хм ... потому что читаемые человеком форматы файлов могут быть прочитаны человеком? Мне кажется, это очень веская причина.

(Ну, для файлов конфигурации неизбежно, что они читаются (и редактируются!) Людьми. Файлы для постоянного хранения того или иного типа не нуждаются в чтении или редактировании людьми.)

Answer 7

Почему я должен использовать читаемый человеком файл формат предпочтительнее двоичного? Есть ли когда-нибудь ситуация, когда это не в этом дело?

Да, сжатые тома (zip, jpeg, mp3 и т. Д.) Были бы неоптимальными, если бы они были читаемыми человеком.

Answer 8

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

Answer 9

Удобочитаемость для человека не равна тому, что ее легче разобрать по машинному коду.

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

Так что я согласен с https://stackoverflow.com/a/714111/2727173, который гораздо глубже понимает этот вопрос.

Answer 10

При чтении диссертации Филдинга о REST мне очень понравилась концепция « Архитектурные свойства »; тот, который придерживался, был "Видимостью". Об этом мы и говорим: возможность «увидеть» данные. Огромные преимущества при отладке системы.

Один аспект, который я нахожу отсутствующим в других ответах: применение семантики .

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

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