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

Dataview позволяет вам проверять содержимое ArrayBuffer. Нечто подобное может сработать:

let arr = [];
let view = new DataView(arrayBuffer);
for (let i = 0; i

53
задан Community 23 May 2017 в 01:52
поделиться

23 ответа

Это зависит

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

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

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

, Почему человекочитаемое использование?

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

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

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

Спорный

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

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

Что-либо еще

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

Кредиты

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

76
ответ дан 12 revs, 2 users 98% 7 November 2019 в 08:18
поделиться

При чтении диссертации Fielding о REST мне действительно понравилось понятие" Архитектурные Свойства "; тот, что sticked была "Видимость". Это - то, о чем мы говорим здесь: способность 'видеть' данные. Огромные преимущества при отладке системы.

Один аспект, что я нахожу пропавших без вести в других ответах: семантика осуществления .

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

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

0
ответ дан xtofl 7 November 2019 в 08:18
поделиться

Человеческий формат является simplier к парсингу и отладке, если у Вас есть проблема с полем (пример: поле содержит число, где спецификация говорит, что это поле должно быть строкой), также человеческий формат является closier к домену проблемы.

я предпочитаю двоичный формат с большим количеством данных, И я уверен, что у меня есть программное обеспечение для парсинга его :)

0
ответ дан alepuzio 7 November 2019 в 08:18
поделиться

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

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

0
ответ дан SmacL 7 November 2019 в 08:18
поделиться

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

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

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

0
ответ дан Tim Post 7 November 2019 в 08:18
поделиться

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

0
ответ дан robi-y 7 November 2019 в 08:18
поделиться

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

1
ответ дан teh_noob 7 November 2019 в 08:18
поделиться

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

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

1
ответ дан Zach Scrivena 7 November 2019 в 08:18
поделиться

Uhm†¦, потому что человекочитаемые форматы файлов могут быть считаны людьми? Походит на довольно серьезное основание мне.

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

1
ответ дан Bombe 7 November 2019 в 08:18
поделиться

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

, Например,

  • JSON довольно читаем даже в простом тексте
  • , который XML имеет налог угловой скобки , но применим при использовании хорошего редактора
  • , INI главным образом человекочитаем
  • , CSV может быть читаемым, но является лучшим при загрузке в электронную таблицу.
2
ответ дан garrow 7 November 2019 в 08:18
поделиться

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

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

XML является злоупотребившим путем.

2
ответ дан Simon 7 November 2019 в 08:18
поделиться

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

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

3
ответ дан mmcdole 7 November 2019 в 08:18
поделиться
  • Доступный для редактирования
  • Читаемый (понятное дело!)
  • Печатаемый
  • Блокнот и vi включили

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

3
ответ дан Learning 7 November 2019 в 08:18
поделиться

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

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

Профессионалы для человекочитаемого:

  • легче понять при чтении - никакое "поле X не установлено на 4 487, что означает, что реактор должен быть закрыт ТЕПЕРЬ"
  • при использовании чего-то как XML, легкий записать инструмент, который проанализирует любой файл

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

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

4
ответ дан TofuBeer 7 November 2019 в 08:18
поделиться

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

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

4
ответ дан Tomalak 7 November 2019 в 08:18
поделиться

Существует что-то позвонившее Искусство Программирования .

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

6
ответ дан ChrisW 7 November 2019 в 08:18
поделиться

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

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

6
ответ дан Joonas Pulakka 7 November 2019 в 08:18
поделиться
  • Открытый формат - никакой бит, манипулирующий
  • Удобочитаемость :)
  • Обмен через платформы
  • Отладка помощи
  • Легко проанализированный (и легко преобразованный в любой формат)

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

7
ответ дан dirkgently 7 November 2019 в 08:18
поделиться

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

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

17
ответ дан starblue 7 November 2019 в 08:18
поделиться

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

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

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

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

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

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

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

26
ответ дан Community 7 November 2019 в 08:18
поделиться

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

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

, Мы раньше имели наш информация о версии в формате слова, но тот документ информации о версии должен был быть открыт на различной среде (Linux, Солярис) в plateform подготовки производства и производства.
Это также должно было быть проанализировано для извлечения различных данных.

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

2
ответ дан VonC 7 November 2019 в 08:18
поделиться

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

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

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

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

Следовательно преимущества "человекочитаемых" форматов:

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

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

  • Easiness-learn, считайте и измените.

Уверенность в дополнительном уровне абстракции делает закодированные файлы текста:

  • Голодное пространство.

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

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

  • Быстрее обработка.

  • Меньшее место.

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

  • Средства просмотра и редакторы специфичны для конкретного двоичного формата и делают совместимость тяжелее.

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

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

2
ответ дан Vlad Gudim 7 November 2019 в 08:18
поделиться

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

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

B) Выводить их в текстовом виде проще. Ненужные преобразования, которые на самом деле требуют большего количества кода, делают систему МЕНЬШЕ надежной. Дело в том, что если вы НЕ используете язык, который обрабатывает все переменные как строки, тогда читаемый человеком текст является дополнительным преобразованием. IE Extra code означает больше кода для проверки, тестирования и больше возможностей для внесения ошибок в приложение.

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

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

Для веб-страниц, где информация имеет "

2
ответ дан 7 November 2019 в 08:18
поделиться
Другие вопросы по тегам:

Похожие вопросы: