file - 人間が読める形式のファイル形式を使用する必要があるのはなぜですか？

Question

バイナリ形式ではなく、人間が読める形式のファイル形式を使用する必要があるのはなぜですか？そうでない状況はありますか？

編集：私は最初に質問を投稿したときに説明としてこれを持っていましたが、今はそれほど関連性がありません：

この質問に答えるとき、人間が読める形式のファイル形式を使用することがなぜ良い考えであるかについて、質問者に標準のSO回答を紹介したいと思いました。それから私はそれを探しました、そしてそれを見つけることができませんでした。だからここに質問があります

score 26 · Accepted Answer

それは完全に状況に依存します。

人間が読める形式の利点:

「ネイティブ」形式で読むことができます
単体テスト用など、目的に応じて実際のコンテンツ用に自分で書くこともできます

バイナリ形式の利点:

解析しやすい (コードの観点から)
解析が速い
スペースの面でより効率的
制御が簡単 (そこにテキストが必要なときはいつでも、UTF-8 でエンコードされ、長さがプレフィックスされていることを確認できます)
不透明なバイナリデータを効率的に含めるのが簡単 (画像など - base64 に入るテキスト形式)

いつでもバイナリ形式を実装できることを忘れないでください。また、人間が読める形式との間で変換するツールも作成できます。それが Protocol Buffers フレームワークの機能です。プロトコルバッファのテキストバージョンを解析する必要がある IME は実際にはかなりまれですが、テキストとして書き出せると非常に便利です。

編集:これが最終的に受け入れられた回答になる場合に備えて、スターブルーの指摘にも留意する必要があります:人間が読める形式は、比較にはるかに優れています。差分に適した (そして人間が読める差分を生成できる) バイナリ形式を設計することは実行可能であると思いますが、既存の差分ツールからのすぐに使えるサポートはテキストに適しています。

score 17 · Accepted Answer

テキスト形式を使用すると、変更を簡単に表示してマージできるため、バージョン管理が容易になります。

特に MS-Word は、この点で私たちに悲しみを与えています。

score 7 · Accepted Answer

オープンフォーマット-バイナリビットジャグリングなし
読みやすさ:)
プラットフォーム間の交換
デバッグ支援
簡単に解析できます（そして任意の形式に簡単に変換できます）

重要なポイントの1つは、パーサーを1回作成しますが、出力を何度も読み取ることです。そのようなものは、HRFを支持してバランスを傾けます。

score 6 · Accepted Answer

主な理由は、たとえば 30 年後に誰かがデータを読み取る必要がある場合、人間が読み取れる形式を見つけ出すことができるからです。バイナリははるかに困難です。

本質的にバイナリである大規模なデータセット (画像など) がある場合、それらは明らかにバイナリ形式以外で保存することはできません。しかし、その場合でも、メタデータは人間が判読できる可能性があります (またそうあるべきです!)。

score 6 · Accepted Answer

The Art of Unix Programmingと呼ばれるものがあります。

良し悪しは言いませんが、かなり有名です。それにはTextuality と呼ばれる章全体があり、著者は人間が読めるファイル形式が Unix のプログラミング方法の重要な部分であると主張しています。

score 4 · Accepted Answer

元のツール以外のツールで作成/編集する可能性が開かれます。新しいより優れたツールを他の人が開発でき、サードパーティのアプリケーションへの統合が可能になります。たとえば、バイナリ iCal ファイルについて考えてみてください。このフォーマットは成功したでしょうか?

それとは別に、人間が読めるファイルは、デバッグの能力を向上させます。または、知識のあるユーザーにとっては、少なくともエラーの理由を見つけることができます。

score 4 · Accepted Answer

バイナリの長所:

解析が速い
一般的に小さいデータ
パーサーを書きやすい

人間が読める利点:

読みながら理解しやすい-「フィールドXが4 487に設定されているため、原子炉を今すぐシャットダウンする必要があります」
XML のようなものを使用すると、任意のファイルを解析するツールを簡単に作成できます

私は両方のタイプに対処しなければなりませんでした。データを送信していて、それを保持したい場合は、小さなバイナリが適しています。人々がそれを読むことを期待しているなら、人間が読めるのが良いです。

人間が読める形式で、一般的にある程度の自己文書化も行います。また、バイナリでは間違いを犯しやすく、それらを見つけるのは困難です。

score 3 · Accepted Answer

あなたは人間であり、遅かれ早かれあなた（またはあなたの顧客の1人）がデータを読み取ることができるようになるからです。

速度が問題になる場合にのみ、バイナリ形式を使用します。それでもデバッグは面倒なので、人間が読める形式の同等物を追加しました。

score 3 · Accepted Answer

編集可能
読みやすい（当たり前！）
印刷可能
メモ帳と vi が有効

最も重要なことは、それらの機能はコンテンツから推測できることです（ほとんどの場合）

score 2 · Accepted Answer

相互運用性は標準的な議論です。つまり、人間が読める形式は、異種システムの開発者にとって扱いやすいため、いくつかの利点があります。

個人的にはそれは真実ではないと思います。特にプロトコルを公開する場合、バイナリファイルのパフォーマンス上の利点はその議論を打ち負かすはずです。ただし、マシンの相互作用のためのXML / HTTPベースのフレームワークの普及は、採用が容易であることを意味します。

XMLは使いすぎです。

score 2 · Accepted Answer

人間が読める形式のドキュメントがより適切な選択となる簡単な例を次に示します。

アプリケーションを本番環境にデプロイするために使用されるドキュメント

以前はリリースノートを Word 形式で作成していましたが、そのリリースノートドキュメントは、さまざまな環境 (Linux、Solaris) で本番前および本番のプラットフォームで開く必要がありました。
また、さまざまなデータを抽出するために解析する必要がありました。

最終的に、wiki ベースの構文に切り替えました。これは、wiki を介して HTML で適切に表示されますが、他の状況では単純なテキストファイルとして使用されます。

score 2 · Accepted Answer

これに付随して、人間の読みやすさにはさまざまなレベルがあり、コードの色付け、折りたたみ、またはナビゲーションを備えた優れたエディターまたはビューアーを使用することで、すべてが強化されます。

例えば、

JSON は平文でも非常に読みやすい
XML には山かっこ税がありますが、優れたエディターを使用すれば使用できます
INI はほとんど人間が読める形式です
CSV は読み取り可能ですが、スプレッドシートに読み込むのが最適です。

score 2 · Accepted Answer

誰も言わなかったので、そうします。人間が読みやすいかどうかは、実際にはファイル形式の特性ではなく (結局、すべてのファイルはバイナリです)、むしろファイル形式とビューアーアプリの組み合わせの特性です。

いわゆる人間が読める形式はすべて、既存のテキストエンコーディングの 1 つの追加の抽象化レイヤーの上に基づいています。そして、人間が読める形式でこれらのエンコーディングをレンダリングできるビューアープログラム (多くの場合、エディターとしても機能します) は非常に一般的です。

テキストエンコーディングの標準は広く普及しており、かなり成熟しています。

通常、フォーマットのテキストエンコーディングレイヤーの上には、ターゲットユーザーの知識と文化的背景を考えると、適度に直感的な構文レイヤーがあります。

したがって、「人間が読める」形式の利点は次のとおりです。

適切な視聴者と編集者の遍在。
時代を超越している (文化的慣習があまり変わらないことを考えると)。
学びやすく、読みやすく、修正しやすい。

追加の抽象化レイヤーに依存すると、テキストでエンコードされたファイルが作成されます。

宇宙に飢えている。
処理が遅くなります。

「バイナリ」ファイルは、ベース (または共通分母) としてテキストエンコーディングの抽象化レイヤーに依存しませんが、目的により適した何らかの追加の抽象化を使用する場合と使用しない場合があるため、より適切に最適化することができます。手元にある特定のタスクの意味:

より高速な処理。
フットプリントが小さい。

一方で：

ビューアーとエディターは特定のバイナリ形式に固有であり、相互運用性を難しくしています。
特定の形式のビューアは、より専門的であるため、あまり広く普及していません。
フォーマットは大幅に進化するか、時間の経過とともに使用されなくなる可能性があります。主な利点は、特定のタスクに非常に適していることであり、タスクまたはタスクの要件が進化するにつれて、フォーマットも進化します。

score 2 · Accepted Answer

少し時間を取って、Web 開発以外のアプリケーションについて考えてみてください。

A) テキスト形式で「明白」な意味を持つという仮定は誤りです。製鉄所や製造プラントの制御システムなどは、通常、人間が判読できるというメリットはありません。これらのタイプの環境用のソフトウェアには、通常、データをグラフィカルに意味のある方法で表示するためのルーチンがあります。

B) テキストで出力する方が簡単です。実際にはより多くのコードを必要とする不必要な変換は、システムの堅牢性を低下させます。問題の事実は、すべての変数を文字列として扱う言語を使用していない場合、人間が読めるテキストは余分な変換です。IE エクストラコードは、検証、テストするコードが増え、アプリケーションにエラーが入り込む機会が増えることを意味します。

C) とにかく解析する必要があります。これは、私が取り組んできた DSP システムの多くのケースです (IE NO 人間が読めるインターフェイスではありません)。データは、均一なサイズのパケットでシステムからストリーミングされます。分析とその後の処理のためにデータをログに記録するには、バッファの先頭をポイントし、ブロックサイズの倍数をデータロガーシステムに書き込むだけです。これにより、別の形式に変換するとエラーが発生する可能性がある場合に、顧客のシステムがデータを参照するため、データを「そのまま」分析できます。それだけでなく、「変換されたデータ」のみを保存すると、問題の診断に役立つ情報が翻訳で失われる可能性があります。

D) テキストは、データの Natural 形式です。「TEXT」インターフェースを使用するハードウェアは見たことがありません。(大学卒業後の私の最初の仕事は、カメララインスキャンカメラ用のデバイスドライバーを作成することでした。) その上に構築されたシステムは、すべての "PC" に対して可能性があります。

情報がテキスト形式で「自然な」意味を持つ Web ページの場合は、気を紛らわせてください。もちろん、ソースコードを処理するのは非常に簡単です。しかし、冷蔵庫や歯ブラシでさえプロセッサが組み込まれている普及型コンピューティング環境では、それほど多くはありません。テキストを処理する機能を追加するというオーバーヘッドをこれらのタイプのシステムに単純に負担させるだけで、不必要な複雑さが生じます。マウスを制御する 8 ビットマイクロのソフトウェアに「printf」をリンクするつもりはありません。(ええ、誰かがそのソフトウェアも書かなければなりません。)

世界は、考慮する必要があるコンピューティングの形態が PC と Web サーバーだけである白黒の場所ではありません。

PC でも、単一の OS 読み取り呼び出しを使用してデータをデータ構造に直接ロードし、シリアライズおよびデシリアライズルーチンを記述せずにそれを実行できる場合、それは素晴らしいことです。ブロックの CRC ジョブをチェックし、次の問題に進みます。 .

score 1 · Accepted Answer

ええと…人間が読める形式のファイルは人間が読めるからですか？私にはかなりの理由のようです。

（構成ファイルの場合、人間が読み取る（そして編集する）ことは避けられません。ある種の永続ストレージ用のファイルは、実際には人間が読み取ったり編集したりする必要はありません。）

score 1 · Accepted Answer

おそらくほとんどの状況では良くないと思います。JSON や XML などのこれらの形式の主な理由は、Web 開発と、ユーザー側でデータを処理できる必要があり、必ずしもバイナリを読み取ることができない Web での一般的な使用のためだと思います。人間が読める形式を使用する悪いケースの良い例は、画像、ビデオ、オーディオなどのテキスト以外のものです。Web 開発で非バイナリ形式が使用されていることに気づきましたが、意味がありません。罪悪感を覚えます。

score 1 · Accepted Answer

バイナリ形式ではなく、人間が読めるファイル形式を使用する必要があるのはなぜですか? これが当てはまらない状況はありますか？

はい、圧縮されたボリューム (zip、jpeg、mp3 など) は、人間が判読できる場合は最適ではありません。

score 0 · Accepted Answer

多くの場合、ファイルはヒューマンインターフェースの一部になるため、人間に優しいものにする必要があります (プログラマーのみではありません)。

score 0 · Accepted Answer

REST に関するフィールディングの論文を読んだとき、私は「アーキテクチャプロパティ」の概念がとても気に入りました。こだわったのは「可視性」です。ここで話しているのは、データを「見る」ことができるということです。システムをデバッグするときの大きな利点。

他の回答に欠けている側面の1つは、セマンティクスの強制です。

人間が読み取れるようにした瞬間から、愚かなメモ帳ユーザーがシステムにフィードするデータを作成できるようになります。このデータが意味を成すことを保証する方法はありません。システムが適切な方法で応答することを保証する方法はありません。

したがって、データをメモ帳で検査する必要がなく、最初にデータを検証するのではなく (たとえば API を使用して) 有効なデータを強制したい場合は、人間が判読できるデータを避けることをお勧めします。デバッグ可能性が問題になる場合 (ほとんどの場合)、API を使用してデータの検査を行うこともできます。

score 0 · Accepted Answer

アーカイブではないファイルにバイナリストリームを使用するのは、何気ない観察者から物事を隠したいときだけです。たとえば、自分のアプリケーションだけが編集できる一時ファイルを作成する場合は、バイナリを使用します。

これは難読化の試みではなく、ユーザーが手動でファイルを編集するのを思いとどまらせているだけです (アプリケーションが壊れる可能性があります)。

これが良い例の 1 つは、ゲームに関する実行中のデータを保存/保存することです。つまり、ゲームを保存して後で続行する場合です。他のシナリオでは中間ファイルについて説明しますが、それらは通常バイナリ/バイトコンパイルされています。

score 0 · Accepted Answer

バイナリ形式ではなく、人間が読めるファイル形式を使用する必要があるのはなぜですか?

コンテンツとコンテキストに依存します。つまり、データがどこから来てどこへ行くのか。通常、データが人間によって直接書き込まれる場合は、テキストエディターで操作できる形式で保存することをお勧めします。たとえば、プログラムのソースコードは通常、人間が読める形式で保存されますが、それには正当な理由があります。ただし、アーカイブしたり、バージョン管理システムを使用して共有したりする場合は、ストレージ戦略が変わります。

score 0 · Accepted Answer

人間が読めるということは、機械コードによって簡単に解析できるということと同じではありません。

人間の自然言語を例に挙げてみましょう。:) 人間の言語の機械解析は、まだ完全に解決されていない保留中の問題です。

したがって、この質問についてより深い洞察があるhttps://stackoverflow.com/a/714111/2727173に同意します。

file - 人間が読める形式のファイル形式を使用する必要があるのはなぜですか？

24 に答える 24

Related

Reference