プレーンテキスト – 日本語百科事典辞書

Plain_text

暗号化の意味については、「平文」を参照してその他の用法については、「テキスト」をご覧
「プレーンテキスト」 –
コンピューティングにおいて、プレーンテキストは、グラフィック表現や他のオブジェクト (浮動小数点数、画像など)ではなく、読み取り可能な内容の文字のみを表すデータ (ファイルコンテンツなど) を表す大まかな用語です。また、スペース、改行、表文字など、テキストの単純な配置に影響を与える限られた数の「空白」文字も含まれる場合がプレーンテキストは、スタイル情報が含まれる書式付きテキストとは異なります。段落やセクションなどの文書の構造部分が識別される構造化テキストから。一部の部分をバイナリオブジェクト (エンコードされた整数、実数、画像など) として解釈する必要があるバイナリファイルから。
Royal Dixonの『The Human Side of Animals』の一部を含むテキストファイル(コマンドによってxtermウィンドウ
に表示される)cat
この用語は、「読み取り可能な」コンテンツのみを含むファイル(または、話者が好まない内容が含まれていないファイル) を意味する、非常に大雑把に使用されることもたとえば、フォントやレイアウト (マークアップ、マークダウン、さらにはタブなど) の表示を除外する可能性が中引用符、非改行スペース、ソフトハイフン、全角ダッシュ、合字などの文字。または他のこと。
原則として、プレーンテキストは任意のエンコーディングで表現できますが、場合によっては、この用語がASCIIを意味するものと解釈されることがUTF-8やUTF-16などのUnicodeベースのエンコーディングが一般的になるにつれて、その使用は縮小する可能性が
プレーンテキストは、「バイナリ」ファイル、つまりファイルの少なくとも一部が実際の文字エンコーディングでは正しく解釈できないファイルを除外するためだけに使用されることもたとえば、「hello」（エンコーディングは何でも）と、その後に単なる文字ではないバイナリ整数を表す 4 バイトで構成されるファイルまたは文字列は、バイナリファイルであり、最も緩やかな一般的なテキストであってもプレーンテキストではありません。用途。別の言い方をすると、プレーンテキストファイルを、文字を表すためにまったく異なる数値を使用する文字エンコーディングに変換しても (使用されているエンコーディングがわかっている限り) 意味は変わりませんが、バイナリファイルの場合、そのような変換は意味を変えます。ファイルの少なくとも一部の部分。
コンテンツ
1 プレーンテキストとリッチテキスト
2 使用法
3 エンコーディング
3.1 文字エンコーディング 3.2 制御コード
4 こちらも参照
5 参考文献

プレーンテキストとリッチテキスト
Unicode 標準によると:
「プレーンテキストは文字コードの純粋なシーケンスです。したがって、エンコードされていないプレーンテキストは 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やラインモードブラウザなどのいくつかのブラウザは、表示用にプレーンテキストのみを生成します) やその他の電子テキストリーダーも同様です。
プレーンテキストファイルはプログラミングにおいてほぼ普遍的です。プログラミング言語の命令を含むソースコードファイルは、ほとんどの場合、プレーンテキストファイルです。プレーンテキストは、プログラムの起動時に保存された設定のために読み取られる構成ファイルにも一般的に使用されます。
多くの電子メールではプレーンテキストが使用されます。
コメント、「.txt」ファイル、またはTXT レコードには通常、人間が読むことを目的としたプレーンテキスト (書式設定されていない) のみが含まれています。
ナレッジを永続的に保存するための最適な形式は、バイナリ形式ではなく、プレーンテキストです。

エンコーディング

文字エンコーディング
詳細は「文字エンコード」を参照
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 番目のビットをチェックサムとして使用することと競合しますが、チェックサムの使用は徐々に廃れていきました。。
これらの追加文字は国によってエンコード方法が異なるため、作成者のルールを理解することなくテキストを解読することが不可能になりました。たとえば、ブラウザは、ある文字セットを別の文字セットとして解釈しようとすると、 `ではなくзAを表示する可能性が国際標準化機構 ( ISO ) は、さまざまな言語に対応するために、最終的にISO 8859に基づいていくつかのコードページを開発しました。これらの 1 つ目 ( 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 文字エンコーディングを使用して表されるプレーンテキストです。
文字エンコーディングが明示的に示されていないドキュメントを受信した場合、一部のアプリケーションは文字セット検出を使用して、使用されたエンコーディングを推測しようとします。

制御コード
詳細は「C0 および C1 制御コード」を参照
ASCII は、「C0 セット」として知られる制御文字用に最初の 32 コード (10 進数 0 ～ 31) を予約しています。このコードは、もともと印刷可能な情報を表すのではなく、 ASCII を使用するデバイス (プリンタなど) を制御することを目的としていました。磁気テープに保存されているデータストリームなどのデータストリームに関するメタ情報を提供します。これらには、改行やタブ文字などの一般的な文字が含まれます。
Latin-1やその他のISO 8859セットなどの 8 ビット文字セットでは、「上半分」（128 ～ 159）の最初の 32 文字も「C1 セット」として知られる制御コードです。これらが直接使用されることはほとんどありません。表向き ISO 8859 エンコーディングである文書内に文字が出現する場合、そのコード位置は通常、そのコードを使用する独自のシステム固有のエンコーディング (Windows-1252 や Mac OS Roman など) のその位置にある文字を指します。代わりに追加のグラフィック文字を提供します。
詳細は「Unicode 制御文字」を参照
Unicode は、双方向のテキスト方向オーバーライド文字 (左から右への書き込み内で右から左への書き込みを明示的にマークするために使用される) やその逆のCJK 表意文字、絵文字の代替形式を選択するバリエーションセレクターなど、追加の制御文字を定義します。そして他のキャラクター。

こちらも参照
バイナリーファイル
ソースコード
テキストファイル
ワードラップ

参考文献
^ 「Unicode 標準バージョン 14.0」 (PDF)。18～19ページ。
^ アンドリュー・ハント、デヴィッド・トーマス。「実践的なプログラマー」。1999。第 14 章:「プレーンテキストの力」。p. 73. ·