なぜプレーンテキストは依然として我々が持つ最高の技術の一つなのか

50年後もまだ読めるであろうコンピューターファイル形式は多くありませんが、プレーンテキストはその一つです。 それは、かすかな賞賛のように聞こえるかもしれません。 テキストファイルは、スプレッドシートを埋め込んだり、凝ったページレイアウトを保持したり、プレゼンテーションを実行したり、現代のアプリケーションに期待する多くの利便性を提供したりすることはできません。 その代わりに、コンピューティングにおいて最もシンプルで広く理解されている形式の一つでテキストを保存します。そして、その単純さが長持ちした大きな理由なのです。 ほとんど問題が起こらない Unicode標準は、プレーンテキストを本質的に、リッチテキストに関連付けられた追加のフォーマット情報なしの、文字コードのシーケンスとして定義しています。 フォント、色、レイアウト、および同様のプレゼンテーションの詳細は、別の場所に属します。 ユーザーの視点からは、重要な部分はよりシンプルです。ファイルは、それを理解するために特定のアプリケーションを必要とせずに、テキスト自体を含んでいます。 Linuxでテキストファイルを作成し、Windowsマシンにコピーし、ウェブサーバーに配置し、ターミナルで開き、コマンドラインツールで検索し、多数のプログラムで編集し、あるいは全く異なるシステムを使用して誰かに送信することができます。 ファイルに関して、それがどのように作成されたかに依存することは非常に少ないです。 それは、情報がその形式を理解するアプリケーションまたはアプリケーションファミリーに密接に関連付けられている多くのドキュメント形式とは異なります。 時にはそれは無害です。 時にはフォーマットは十分に文書化されており、広くサポートされています。 他の場合では、古いファイルを開くことは、適切なソフトウェアがまだ存在することを願うことを意味します。 プレーンテキストには、そのような負担はほとんどありません。 理由があって、我々はそれを永遠に使ってきた プレーンテキストは、救済を必要とする忘れられた技術ではありません。 それはコンピューティングの基本的な配管の一部であり続けています。 ソースコードは一般的にテキストです。 設定ファイルはしばしばテキストです。 ログファイルは一般的にテキストです。 UnixおよびLinuxシステムはテキストファイルでいっぱいです。 ウェブの背後にある多くの仕組みも、何らかの形でテキストを扱います。 HTML、XML、JSON、CSS、シェルスクリプト、プログラミング言語、設定フォーマット、その他多くのものは、人間が検査できる文字を中心に構築されています。 これらは、通常の散文ではなく、構造化されたフォーマットです。 もちろん、HTMLドキュメントは.txtファイル内のメモと同じではありません。 類似点は、内容がまだ見えるということです。 基本的なテキストエディタでファイルを開くと、たとえその一部を理解していなくても、何があるかを見ることができます。 それは実用的な価値があります。 テキスト設定ファイルで問題が発生した場合、それを作成したプログラムを必要とせずに、直接検査したり、コピーしたり、バージョンを比較したり、特定のセッティングを検索したり、バックアップを作成したりできます。 通常のアプリケーションの外でも理解可能なデータは、トラブルシューティングや保存がはるかに容易です。 プレーンテキストは他者と良好に連携する プレーンテキストの最大の強みの一つは、膨大な数のツールがすでにそれと連携する方法を知っていることです。 Unixライクなシステムでは、テキストファイルはgrep、sed、awk、sort、diff、そして数十年間存在する他の多くのユーティリティに渡すことができます。 スクリプトは、メニューを人間のようにクリックすることなく、何千ものファイルを処理できます。 利点はコマンドラインに限定されません。 グラフィカルエディタ、プログラミング環境、メモ取りアプリケーション、ファイルマネージャー、検索ツール、ブラウザ、そして数え切れないほどの他のプログラムもテキストを扱うことができます。 真の利点は、情報が一つのインターフェースに厳密に結合されていないことです。 現代のソフトウェアはしばしば反対のアプローチを取ります。 アプリケーションは、あなたの情報がどこに存在するか、どのように整理されているか、どのように同期されるか、どのように検索されるか、そして他のどのソフトウェアがそれに触れることが許可されているかを決定するかもしれません。 これらのシステムは有用な機能を提供できますが、アプリケーションをデータに対してますます中心的なものにもします。 プレーンテキストは、これらの選択肢の多くをユーザーに委ねます。 Markdownは有用な中間領域を見つけた プレーンテキストの明白な弱点はフォーマットです。 見出し、強調、リンク、リスト、引用、その他の構造は、ドキュメントを読みやすくしますが、基本的な.txtファイルは、それらのほとんどを表現するための標準的な方法を提供しません。 Markdownは実用的な妥協案です。 それは構造化されたドキュメントのためのプレーンテキストフォーマットであり、電子メールやUsenetからすでに馴染みのある慣習を引き継いでいます。 それは2004年に導入され、そのバリエーションは現在、ソフトウェアドキュメント、ウェブサイト、メモ、書籍、そして他の多くの種類の文章に使用されています。 その真の強みは、Markdownプロセッサが消滅してもソースが有用であり続けることです。 見出しは依然として見出しのように見えます。 箇条書きリストは依然としてリストのように見えます。 リンクは、その説明と宛先の両方を含んでいます。 フォーマット構文は、バイナリ構造の中に埋め込まれるのではなく、可視的です。 それは、プレーンテキストの主要な利点を失うことなく、有用な機能を追加する良い例です。 レンダリングされた出力は便利かもしれませんが、ソースファイルは通常のテキストのままです。 テキストは驚くほど長持ちする 長寿命は、プレーンテキストの最も強い主張かもしれません。 コンピューターの歴史は、放棄されたファイル形式とアプリケーションでいっぱいです。 古いドキュメントを復旧するには、時代遅れのソフトウェアを見つけ、インポートフィルターを見つけ、エミュレーターを実行し、あるいはいくつかの移行フォーマットを経て変換する必要がある場合があります。 テキストファイルは互換性の問題から完全に免れているわけではありません。 古いファイルには文字エンコーディングの問題があり、行末の違いは何年もの間、いらだちの原因となってきました。 それでも、これらは通常、不明瞭なプロプライエタリフォーマットから情報を復旧しようとするよりも管理しやすい問題です。 古いテキストファイルを見つけた場合、現在のコンピューター上の何らかのプログラムが開くことができる可能性は非常に高いです。 たとえフォーマットが粗雑であったり、エンコーディングに注意が必要であったりしても、言葉自体は一般的に回復可能です。 現代のUnicodeはまた、英語の文字、数字、句読点以外はほとんど含まない古いASCIIテキストの考え方よりも、プレーンテキストをはるかに強力にしました。 今日のプレーンテキストは、世界中の筆記システムや文字を表現できますが、同じ基本的な考え方を維持しています。ファイルは、プロプライエタリなプレゼンテーションフォーマットではなく、エンコードされた文字を含んでいます。 シンプルであることが原始的である必要はありません。 所有も容易である プレーンテキストの利点は、ソフトウェアがアカウント、クラウドストレージ、同期サービス、サブスクリプションへと移行するにつれて、さらに顕著になります。 テキストファイルは、単に私のコンピューター上のディレクトリに存在することができます。 私はそれを他のファイルと一緒にバックアップしたり、好きなように同期したり、バージョン管理下に置いたり、別のマシンにコピーしたり、私が管理するサーバーに保存したりできます。 これらのどれも、私のエディタを作成した会社が事業を継続したり、サービスをサポートし続けたりすることを必要としません。 それは、すべてのメモ取りサービスやクラウドアプリケーションを悪い考えにするものではありません。 専門的なアプリケーションは、プレーンテキストだけでは容易に提供できない機能を提供します。 コラボレーション、データベース、埋め込みメディア、複雑なフォーマット、そして異なる種類の情報間の関係は、すべて正当な用途があります。 すべての種類のデータを.txtファイルに強制することに利点はありません。 有用な区別は、追加の複雑さが実際の問題を解決するか、単に別の依存関係になるかです。 プレーンテキストが十分な場合、それは後で邪魔になる可能性のある驚くほど多くのものを排除します。 限界は現実である プレーンテキストは万能ではありません。 私は写真のピクセルをテキストで説明したものに置き換えたくありませんし、すべての数式を手動で再構築する必要がある数字の山に金融ワークブックを変換したくもありません。 リッチドキュメントは、プレゼンテーションと構造が時に重要であるために存在します。 アプリケーションも有用な抽象化を提供します。 データベースは、テキストファイルのディレクトリでは実現できない関係を強制できます。 ワードプロセッサは、手動で再現するのが面倒なページレイアウトを処理できます。 専門的なソフトウェアが存在するのには良い理由があります。 問題は、よりリッチなツールを使用することではありません。 それは、仕事の時に自動的に良いとは限らないリッチなツールを、常に良いと仮定することです。