プレーンテキスト

コンピューティングにおいて、プレーン テキストとは、読み取り可能な素材の文字のみを表し、グラフィカルな表現や他のオブジェクト (浮動小数点数、画像など)は表さないデータ (ファイル コンテンツなど) を指すあいまいな用語です。また、スペース、改行、タブ文字など、テキストの単純な配置に影響する限られた数の「空白」文字が含まれる場合もあります。プレーン テキストは、スタイル情報が含まれる書式設定されたテキスト、段落、セクションなどの文書の構造部分が識別される構造化テキスト、および一部をバイナリ オブジェクト (エンコードされた整数、実数、画像など) として解釈する必要がある バイナリ ファイルとは異なります。

この用語は、非常に緩く使用され、 「読み取り可能な」コンテンツのみを含むファイル(または、話し手が好まないものを含まないファイル) を意味することがあります。たとえば、フォントやレイアウト (マークアップ、マークダウン、タブなど) の表示、カーリー引用符、ノーブレーク スペース、ソフト ハイフン、エム ダッシュ、合字などの文字、その他のものが除外される場合があります。

原則として、プレーンテキストは任意のエンコードで使用できますが、この用語がASCII を意味すると解釈されることもあります。UTF -8やUTF-16などのUnicodeベースのエンコードが一般的になるにつれて、その使用は減少する可能性があります。

プレーン テキストは、"バイナリ" ファイル (ファイルの少なくとも一部が、有効な文字エンコードでは正しく解釈できないファイル) を除外するためだけに使われることもあります。たとえば、 "hello" (任意のエンコード) と、それに続く 4 バイトの文字ではない2 進整数を表すファイルは、バイナリ ファイルです。プレーン テキスト ファイルを別の文字エンコードに変換しても、正しい文字エンコードが使用されている限り、テキストの意味は変わりません。ただし、バイナリ ファイルを別の形式に変換すると、非テキスト データの解釈が変わる場合があります。

ユニコード標準によれば: ^[1]

• 「プレーン テキストは純粋な文字コードのシーケンスです。したがって、エンコードされていないプレーン テキストは Unicode 文字コードのシーケンスです。
• 対照的に、スタイル付きテキスト (リッチ テキストとも呼ばれます) は、プレーン テキストに加えて、言語識別子、フォント サイズ、色、ハイパーテキスト リンクなどの追加情報を含むテキスト表現です。
• SGML、RTF、HTML、XML、TeX は、プレーンテキスト ストリームとして完全に表現されるリッチ テキストの例であり、プレーンテキスト データと、追加のデータ構造を表す文字列が混在しています。

ただし、他の定義によれば、マークアップやその他のメタデータを含むファイルは、マークアップが直接人間が読める形式 (HTML、XML など) である限り、通常はプレーン テキストと見なされます。したがって、SGML、RTF、HTML、XML、wiki マークアップ、TeX などの表現、およびほぼすべてのプログラミング言語のソース コード ファイルは、プレーン テキストと見なされます。特定のコンテンツは、ファイルがプレーン テキストであるかどうかとは関係ありません。たとえば、SVGファイルは描画やビットマップ グラフィックスを表現できますが、それでもプレーン テキストです。

バイナリ ファイルではなくプレーン テキストを使用すると、ファイルがコンピュータ アーキテクチャの非互換性の影響をほとんど受けなくなるため、ファイルが「野外」でより適切に存続できるようになります。たとえば、エンディアンの問題はすべて回避できます (UTF-8 ではなくUCS-2などのエンコードを使用すると、エンディアンは重要になりますが、潜在的に未知のサブセットではなく、すべての文字に対して一律に重要です)。

今日、プレーン テキストを使用する主な目的は、独自の特別なエンコードやフォーマット、またはファイル形式を必要とするプログラムから独立することです。プレーン テキスト ファイルは、一般的なテキスト エディターやユーティリティを使用して開いたり、読み取ったり、編集したりできます。

コマンドライン インターフェイスを使用すると、プレーン テキストでコマンドを入力し、応答 (通常はプレーン テキスト) を受け取ることができます。

DOS、Windows、クラシック Mac OS、Unixおよびその類似の無数のプログラム、Web ブラウザー ( LynxやLine Mode Browserなどのいくつかのブラウザーは表示用にプレーンテキストのみを生成します)、およびその他の電子テキストリーダーなど、他の多くのコンピューター プログラムもプレーンテキストを処理または作成できます。

プレーン テキスト ファイルはプログラミングではほぼ普遍的です。プログラミング言語の命令を含むソース コード ファイルは、ほとんどの場合プレーン テキスト ファイルです。プレーン テキストは、プログラムの起動時に保存された設定を読み取る 構成ファイルにも一般的に使用されます。

多くの電子メールではプレーンテキストが使用されています。

コメント、 " .txt " ファイル、またはTXT レコードには通常、人間が読むことを目的としたプレーンテキスト (書式なし) のみが含まれます。

知識を永続的に保存するための最良の形式は、バイナリ形式ではなくプレーンテキストです。^[2]

1960 年代初頭まで、コンピュータは主にテキストではなく数値計算に使用されており、メモリは非常に高価でした。コンピュータは各文字に 6 ビットしか割り当てられず、64 文字しか使用できないことが多く、AZ、az、0-9 にコードを割り当てると 2 つのコードしか残らず、まったく足りませんでした。ほとんどのコンピュータは小文字をサポートしないことを選択しました。そのため、Roberto BusaのIndex ThomisticusやBrown Corpusなどの初期のテキスト プロジェクトでは、実際には大文字であるはずの文字の前にアスタリスクを入力するなどの規則に頼らざるを得ませんでした。

IBMのFred Brooks は、将来人々がテキストを処理したくなるかもしれないという理由で 8 ビット バイトへの移行を強く主張し、それが認められました。IBM はEBCDIC を使用していましたが、それ以降のほとんどのテキストはASCIIでエンコードされるようになり、(印刷されない)制御文字には 0 から 31 までの値、文字、数字、句読点などのグラフィック文字には 32 から 127 までの値を使用しました。ほとんどのマシンは文字を 7 ビットではなく 8 ビットで保存し、残りのビットを無視するか、チェックサムとして使用しました。

ASCII がほぼどこにでもあることは大きな助けになりましたが、国際的および言語的な問題には対処できませんでした。ドル記号 ("$") はイギリスではそれほど役に立ちませんでしたし、スペイン語、フランス語、ドイツ語、ポルトガル語、イタリア語、その他多くの言語で使用されるアクセント付き文字は ASCII ではまったく使用できませんでした (ギリシャ語、ロシア語、およびほとんどの東洋言語で使用される文字は言うまでもありません)。多くの個人、企業、および国が必要に応じて追加の文字を定義しました。多くの場合、制御文字を再割り当てするか、128 から 255 の範囲の値を使用します。128 を超える値を使用すると、8 番目のビットをチェックサムとして使用することと競合しますが、チェックサムの使用は徐々に廃れていきました。

これらの追加文字は国によってエンコード方法が異なっていたため、作成者のルールを理解しなければテキストをデコードすることは不可能でした。たとえば、ブラウザが1 つの文字セットを別の文字セットとして解釈しようとすると、 `ではなく¬A が表示されることがあります。国際標準化機構 ( ISO ) は最終的に、さまざまな言語に対応するためにISO 8859に基づいていくつかのコード ページを開発しました。最初のコード ページ ( ISO 8859-1 ) は「Latin-1」とも呼ばれ、ラテン文字を使用するほとんどの (すべてではない) ヨーロッパ言語のニーズをカバーしています (すべてをカバーするにはスペースが足りませんでした)。その後、 ISO 2022では、ファイルの途中で異なる文字セットを「切り替える」ための規則が提供されました。他の多くの組織がこれらのバリエーションを開発し、Windows および Macintosh コンピュータは長年互換性のないバリエーションを使用していました。

テキストエンコーディングの状況はますます複雑になり、ISO とUnicode コンソーシアムは、既知の (または少なくとも現在知られているすべての) 言語をカバーできる単一の統合文字エンコーディングを開発する取り組みを進めました。いくつかの対立の後、^{[引用が必要]}これらの取り組みは統合されました。現在、 Unicode は1,114,112 のコード値を許可しており、ほぼすべての現代のテキスト記述システムと多くの歴史的なシステムをカバーするコードと、プリンターのディンバット、数学記号など の多くの非言語文字を割り当てています。

テキストは、エンコードに関係なくプレーン テキストと見なされます。テキストを正しく理解または処理するには、受信者は使用されたエンコードを知っている (または理解できる) 必要があります。ただし、使用されたコンピューター アーキテクチャや、データを作成したプログラム (存在する場合) によって定義されたバイナリ構造について知る必要はありません。

プレーン テキストの特定のエンコードを明示的に指定する最も一般的な方法は、おそらくMIMEタイプを使用することです。電子メールとHTTPの場合、デフォルトの MIME タイプは「text/plain 」で、マークアップのないプレーン テキストです。電子メールと HTTP の両方でよく使用される別の MIME タイプは「 text/html ; charset=UTF-8 」で、HTML マークアップを使用した UTF-8 文字エンコードを使用して表されるプレーン テキストです。別の一般的な MIME タイプは「 application/json 」で、JSONマークアップを使用した UTF-8 文字エンコードを使用して表されるプレーン テキストです。

文字エンコードが明示的に示されていないドキュメントを受信した場合、一部のアプリケーションでは文字セット検出を使用して、使用されたエンコードを推測しようとします。

ASCII では、最初の 32 個のコード (10 進数の 0 ～ 31 の数字) を「C0 セット」と呼ばれる制御文字用に予約しています。このコードは、本来は印刷可能な情報を表すのではなく、ASCII を使用するデバイス (プリンターなど) を制御したり、磁気テープなどに格納されているデータ ストリームに関するメタ情報を提供したりするためのものです。これには、改行文字やタブ文字などの一般的な文字が含まれます。

Latin-1やその他のISO 8859セットなどの 8 ビット文字セットでは、「上位半分」の最初の 32 文字 (128 から 159) も制御コードであり、「C1 セット」と呼ばれます。これらは直接使用されることはほとんどありません。表面上は ISO 8859 エンコードの文書にこれらの文字が出現する場合、そのコード位置は、通常、Windows-1252やMac OS Romanなどの独自のシステム固有のエンコードのその位置にある文字を参照します。これらのエンコードでは、これらのコードを使用して追加のグラフィック文字が提供されます。

Unicode では、双方向テキスト方向オーバーライド文字 (左から右への記述内で右から左への記述を明示的にマークしたり、その逆のマークに使用) や、CJK 表意文字、絵文字、その他の文字の代替形式を選択するための異体字セレクターなどの追加の制御文字が定義されています。

• バイナリデータ
• バイナリファイル
• バイナリプロトコル
• ソースコード
• テキストファイル
• テキストベースのプロトコル
• 行折り返しと単語折り返し