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

Question

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

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

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

Answer 1

Это зависит

Правильный ответ - это зависит. Например, если вы пишете аудио / видео данные, если вы ломаете их в удобочитаемый формат, они не будут очень удобочитаемыми! И текстовые документы являются классическим примером, когда люди хотели, чтобы они были удобочитаемыми для человека, чтобы они были более гибкими, и, переходя на XML, MS идут по этому пути.

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

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

Зачем использовать читабельный человек?

1. Следующий парень . Представьте себе, что ведущий разработчик просматривает ваш код через 30 или шесть месяцев. Да, он должен иметь исходный код. Да, он должен иметь документы и комментарии. Но он, скорее всего, не будет. И, будучи этим парнем и должен был спасать или конвертировать старые, чрезвычайно ценные данные, я буду благодарен вам за то, что вы сделали то, что я могу просто посмотреть и понять.
2. Позвольте мне прочитать И НАПИСАТЬ его своими инструментами . Если я пользователь emacs, я могу это использовать. Или Vim, или блокнот, или ... Даже если вы создали отличные инструменты или библиотеки, они могут не работать на моей платформе или даже вообще не работать. Кроме того, я могу создавать новые данные с помощью своих инструментов.
3. Налог невелик - хранилище бесплатно . Почти всегда дисковое пространство свободно. И если это не так, вы будете знать. Не беспокойтесь о нескольких угловых скобках или запятых, обычно это не имеет большого значения. Преждевременная оптимизация - корень всего зла. И если вы действительно беспокоитесь, просто используйте стандартный инструмент сжатия, и тогда у вас есть небольшой читаемый человеком формат - любой может запустить unzip.
4. Налог не такой большой - компьютеры быстры . Это может быть быстрее для анализа двоичного файла. Пока вам не понадобится добавить дополнительный столбец или тип данных или поддерживать как устаревшие, так и новые файлы. (хотя это смягчается с помощью буферов протокола )
5. Есть много хороших форматов . Даже если вам не нравится XML. Попробуйте CSV. Или JSON. Или. Свойства. Или даже XML. Существует множество инструментов для их анализа уже на многих языках. И это займет всего 5 минут, чтобы написать их снова, если загадочным образом весь исходный код потерян.
6. Различия становятся легкими . Когда вы регистрируетесь в системе контроля версий, гораздо легче увидеть, что изменилось. И просматривать его в Интернете. Или твой айфон. Двоичный код, вы знаете, что что-то изменилось, но вы полагаетесь на комментарии, чтобы сказать вам, что.
7. Слияния становятся проще . В Интернете по-прежнему возникают вопросы о том, как добавить один PDF-файл в другой. Это не происходит с текстом.
8. Легче ремонтировать, если повреждено . Попробуйте восстановить поврежденный текстовый документ или поврежденный ZIP-архив. Достаточно сказано.
9. Каждый язык (и платформа) может читать или писать . Конечно, двоичный код является родным языком для компьютеров, поэтому каждый язык также будет поддерживать двоичный код. Но многие классические языки сценариев инструментов намного лучше работают с текстовыми данными. Я не могу думать о языке, который хорошо работает с бинарным, а не с текстом (может быть, ассемблер), но не наоборот. А это значит, что ваши программы могут взаимодействовать с другими программами, о которых вы даже не думали или которые были написаны за 30 лет до вашей. Есть причины, по которым Unix был успешным.

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

1. Возможно, у вас много данных - терабайт, возможно. И тогда фактор 2 может действительно иметь значение. Но преждевременная оптимизация все еще является корнем зла. Как насчет использования человека сейчас, а преобразования позже? Это не займет много времени.
2. Хранилище может быть бесплатным, но пропускная способность не равна (Джон Скит в комментариях). Если вы разбрасываете файлы по сети, тогда размер действительно может иметь значение. Даже пропускная способность диска и с диска может быть ограничивающим фактором.
3. Код с действительно высокой производительностью . Двоичный код может быть серьезно оптимизирован. Существует причина, по которой базы данных обычно не имеют своего собственного текстового формата.
4. Бинарный формат может быть стандартным . Так что используйте PNG, MP3 или MPEG. Это облегчает работу следующих ребят (по крайней мере, в течение следующих 10 лет).
5. Существует множество хороших двоичных форматов . Некоторые из них являются глобальными стандартами для данных такого типа. Или может быть стандартом для аппаратных устройств. Некоторые из них являются стандартными средами сериализации. Отличным примером является Буферы протокола Google . Другой пример: Bencode
6. Проще встраивать двоичные файлы . Некоторые данные уже являются двоичными, и вам нужно их встроить. Это естественно работает в двоичных форматах файлов, но выглядит уродливо и очень неэффективно в читаемых человеком, и обычно мешает им быть читаемыми человеком.
7. Умышленное безвестность . Иногда вы не хотите, чтобы было очевидно, что делают ваши данные. Шифрование лучше, чем случайная защита из-за неясности, но если вы шифруете, вы можете также сделать его двоичным и покончить с этим.

Дискуссионный

1. Проще разбирать . Люди утверждают, что и текст, и двоичный файл легче разбирать. Очевидно, что анализ легче всего делать, когда ваш язык или библиотека поддерживает синтаксический анализ, и это верно для некоторых двоичных и некоторых читаемых человеком форматов, поэтому на самом деле также не поддерживает. Бинарные форматы могут быть четко выбраны, чтобы их было легко анализировать, но так же легко для восприятия человеком (например, CSV или фиксированная ширина), поэтому я считаю, что этот вопрос спорный. Некоторые двоичные форматы могут быть просто выгружены в память и использованы как есть, так что это можно назвать самым простым для анализа, особенно если используются числа (не только строки. Однако я думаю, что большинство людей будет утверждать, что разбор понятный для человека анализ легче отлаживать , поскольку легче увидеть, что происходит в отладчике (слегка).
2. Легче контролировать . Да, более вероятно, что кто-то будет искажать текстовые данные в своем редакторе или будет стонать, когда один формат Unicode работает, а другой - нет. С двоичными данными это менее вероятно. Тем не менее, люди и оборудование все еще могут искажать двоичные данные. И вы можете (и должны) указать кодировку текста для удобочитаемых или фиксированных данных.

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

Что-нибудь еще

Вы действительно хотите файл? Вы рассматривали базу данных? : -)

Кредиты

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

Answer 2

Это полностью зависит от ситуации.

Преимущества удобочитаемого формата:

• Вы можете прочитать его в «родном» формате.
• Вы можете написать это самостоятельно, например, для юнит-тестов - или даже для реального контента, в зависимости от того, что для

Возможные преимущества двоичного формата:

• Проще разбирать (в терминах кода)
• Быстрее разобрать
• Более эффективный с точки зрения пространства
• Легче контролировать (в любое время, когда вам нужен текст, вы можете убедиться, что он в кодировке UTF-8, с префиксом длины и т. Д.)
• Легче эффективно включать непрозрачные двоичные данные (изображения и т. Д. - в текстовом формате, который вы получите в base64)

Не забывайте, что вы всегда можете реализовать двоичный формат, но также можете создавать инструменты для преобразования в / из читаемого человеком формата. Это то, что делает инфраструктура Protocol Buffers - на самом деле IME довольно редко нужно анализировать текстовую версию буфера протокола, но очень удобно иметь возможность записывать его как текст.

РЕДАКТИРОВАТЬ: На всякий случай, если это в конечном итоге является принятым ответом, вы также должны иметь в виду замечание, сделанное Starblue : Человекочитаемые формы намного лучше для сравнения. Я подозреваю, что было бы целесообразно спроектировать двоичный формат, который подходит для сравнения (и где может быть сгенерирован читаемый человеком разностный формат), но встроенная поддержка существующих инструментов сравнения будет лучше для текста.

Answer 3

Контроль версий проще с текстовыми форматами, потому что изменения могут быть легко просмотрены и объединены.

Особенно MS-Word дает нам горе в этом отношении.

Answer 4

• Открытый формат - без использования двоичных битов
• Читабельность:)
• Обмен между платформами
• Помощь при отладке
• Легко анализируется (и легко конвертируется в любой формат)

Один важный момент: вы пишете парсер один раз, но читаете вывод много раз. Этот вид склоняет баланс в пользу HRF.

Answer 5

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

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

Answer 6

Есть нечто, называемое Искусство программирования Unix .

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

Answer 7

Плюсы для двоичного файла:

• быстро разобрать
• обычно меньшие данные
• легко написать парсер для

Плюсы для человека удобочитаемы:

• легче понять при чтении - «поле X не установлено на 4 487, что означает, что реактор должен быть закрыт СЕЙЧАС»
• если использовать что-то вроде XML, легко написать инструмент, который будет анализировать любой файл

Мне приходилось иметь дело с обоими типами. Если вы отправляете данные и хотите, чтобы они были небольшими, это хорошо. Если вы ожидаете, что люди прочтут его, тогда читаемость - это хорошо.

Читаемый человеком, как правило, также самодокументированный. А с двоичным кодом очень легко совершать ошибки, и их трудно обнаружить.

Answer 8

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

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

Answer 9

• Editable
• Чтение (дух!)
• Версия для печати
• Блокнот и vi включены

Самое главное, их функция может быть выведена из содержимого (в основном, в основном)

Answer 10

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

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