プレーンテキスト

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ
テキストファイルの動物の人間的側面により、ロイヤル・ディクソンは、コマンドで表示catのxtermウィンドウ

計算プレーンテキストのみを表すデータ(例えば、ファイルの内容)のためのルーズな用語である文字読み取り可能材料がなく、そのグラフィカル表現も他のオブジェクト(浮動小数点数、画像、等)。また、スペース、改行、タブ文字など、テキストの単純な配置に影響を与える限られた数の「空白」文字が含まれる場合もあります(ただし、タブ文字はさまざまなことを「意味」する可能性があるため、「わかりやすい」ことはほとんどありません)。プレーンテキストは、スタイル情報が含まれているフォーマットされたテキストとは異なります。段落、セクションなどのドキュメントの構造部分が識別される構造化テキストから。およびバイナリファイルから 一部の部分はバイナリオブジェクト(エンコードされた整数、実数、画像など)として解釈する必要があります。

この用語は、「読み取り可能な」コンテンツのみを含むファイル(または話者が好まないものを含まないファイル)を意味するために、非常に大まかに使用されることがあります。たとえば、フォントやレイアウト(マークアップ、マークダウン、さらにはタブなど)の表示を除外できます。中引用符、改行なしスペース、ソフトハイフン、全角ダッシュ、および/または合字などの文字。または他のもの。

原則として、プレーンテキストは任意のエンコーディングにすることができますが、ASCIIを意味する用語と見なされることもあります。ユニコードなどのエンコーディングベースのUTF-8およびUTF-16は、より一般的になり、その使用量は縮小されてもよいです。

プレーンテキストは、「バイナリ」ファイル(ファイルの少なくとも一部が実際の文字エンコードでは正しく解釈できないファイル)を除外するためにのみ使用されることもあります。たとえば、「hello」(どのエンコーディングでも)で構成され、その後に4バイトが続き、文字だけではない2進整数を表すファイルまたは文字列は、2進ファイルであり、最も緩い一般的なテキストでもプレーンテキストではありません。使用法。言い換えると、プレーンテキストファイルをまったく異なる数字を使用して文字を表す文字エンコードに変換ても意味変わりませんが(使用されているエンコードがわかっている限り)、バイナリファイルの場合はそのような変換によって意味変わります。ファイルの少なくともいくつかの部分の。

プレーンテキストとリッチテキスト

Unicode標準によると:

  • プレーンテキストは文字コードの純粋なシーケンスです。したがって、プレーンなエンコードされていないテキストはUnicode文字コードのシーケンスです。
  • 対照的に、スタイル付きテキストはリッチテキストとも呼ばれ、プレーンテキストに加えて、言語識別子、フォントサイズ、色、ハイパーテキストリンクなどの追加情報を含むテキスト表現です。

SGML、RTF、HTML、XML、およびTEXは、プレーンテキストストリームとして完全に表現されたリッチテキストの例であり、追加のデータ構造を表す文字のシーケンスがプレーンテキストデータに散在しています。」 [1]

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

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

使用法

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

コマンド・ライン・インターフェースは、典型的にはプレーンテキストで、人々はプレーンテキストでコマンドを与え、応答を取得することができます。

DOSWindowsクラシックMac OSUnixとその同類の無数のプログラムなど、他の多くのコンピュータプログラムもプレーンテキストを処理または作成できますWebブラウザ(LynxLine Mode Browserなどのいくつかのブラウザは表示用のプレーンテキストのみを生成します)やその他の電子テキストリーダーも同様です。

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

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

コメント、「.TXT」ファイル、またはTXTレコードが、一般的に(書式設定なし)のみ、プレーンテキストは人間が読むことをするためのものが含まれています。

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

エンコーディング

文字エンコード

1960年代初頭以前は、コンピュータはテキストではなく主に数値計算に使用され、メモリは非常に高価でした。多くの場合、コンピューターは各文字に6ビットしか割り当てず、64文字しか許可しません。AZ、az、および0-9にコードを割り当てると、2つのコードしか残されません。ほとんどのコンピューターは小文字をサポートしないことを選択しました。したがって、このような早けれテキストプロジェクトロベルト・バサインデックスThomisticusブラウンコーパス、そして他の人は、このような実際に大文字であることを意図した文字の前にアスタリスクキーイングなどの規則に頼らなければなりませんでした。

フレッド・ブルックスIBMは、いつかの人々がテキストを処理する場合がありますので、8ビットバイトに行くために強く主張しました。そして勝ちました。 IBMはEBCDICを使用していましたが、それ以降、ほとんどのテキストはASCIIエンコードされるようになり、(非印刷)制御文字は0から31の値を使用し、文字、数字、句読点などのグラフィック文字には32から127の値を使用しました。ほとんどのマシンは、文字を7ビットではなく8ビットで格納し、残りのビットを無視するか、チェックサムとして使用します

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

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

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

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

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

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

制御コード

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

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

Unicodeは、双方向テキスト方向オーバーライド文字(左から右への書き込み内で右から左への書き込みを明示的にマークするために使用される)やCJKイデオグラフ絵文字の代替形式を選択するためのバリエーションセレクターなどの追加の制御文字を定義します。および他の文字。

も参照してください

参考文献

  1. ^ Unicode標準、バージョン14.0、18〜19ページ
  2. ^ アンドリュー・ハント、デビッド・トーマス。実用的なプログラマー」。1999. 第14章:「プレーンテキストの力」NS。73。