テキストファイル(textfileと綴られることもあり、以前はflat fileとも呼ばれていた)は、電子テキストの行のシーケンスとして構造化されたコンピュータファイルの一種です。テキストファイルは、コンピュータのファイルシステム内にデータとして保存されます。
CP/Mなどのオペレーティングシステムでは、オペレーティングシステムがファイルサイズをバイト単位で追跡しないため、テキストファイルの終わりは、テキストファイルの最後の行の後に、ファイル終端(EOF) マーカーと呼ばれる 1 つ以上の特殊文字をパディングとして配置することで示されます。[ 1 ] DOS、Microsoft Windows、Unix ライクなシステムなどの最新のオペレーティングシステムでは、これらのオペレーティングシステムのファイルシステムがファイルサイズをバイト単位で追跡するため、テキストファイルには特別な EOF 文字は含まれません。[ 2 ]
Multics、Unix ライクなシステム、CP/M、DOS、クラシック Mac OS、Windowsなどの一部のオペレーティングシステムは、テキスト ファイルをバイト列として格納し、各行の末尾に行末区切り文字を付けます。 [ 3 ] OpenVMSやOS/360 とその後継システムなどの他のオペレーティングシステムは、レコード指向ファイルシステムを採用しており、テキスト ファイルは、固定長レコードのシーケンス、またはレコード ヘッダーにレコード長の値を持つ可変長レコードのシーケンスとして格納されます。
「テキストファイル」とはコンテナの一種を指し、一方「プレーンテキスト」とはコンテンツの一種を指します。

テキストファイルは、そのシンプルさから、情報の保存によく用いられます。エンディアン、パディングバイト、マシンワードのバイト数の違いなど、他のファイル形式で発生するいくつかの問題を回避できます。さらに、テキストファイルでデータ破損が発生した場合でも、残りの内容の復旧と処理の継続が容易な場合が多いです。テキストファイルの欠点は、通常エントロピーが低いことです。つまり、情報が厳密に必要な容量よりも多くのストレージを占有してしまうということです。
単純なテキストファイルであれば、読者が内容を解釈するのに役立つ追加のメタデータ(文字セットに関する知識以外)は必要ない場合があります。テキストファイルにはデータが全く含まれていない場合もあり、これはゼロバイトファイルと呼ばれます。
ASCII文字セットは、英語のテキストファイルで最も一般的な互換性のある文字セットのサブセットであり、多くの場合、デフォルトのファイル形式として想定されています。アメリカ英語はカバーされていますが、英国のポンド記号、ユーロ記号、または英語以外の言語で使用される文字については、より豊富な文字セットを使用する必要があります。多くのシステムでは、これは読み込まれるコンピュータのデフォルトのロケール設定に基づいて選択されます。UTF-8以前は、ヨーロッパ言語にはシングルバイトエンコーディング( ISO-8859-1からISO-8859-16など)、アジア言語にはワイド文字エンコーディングが伝統的に使用されていました。
エンコーディングは必然的に限られた文字レパートリーしか持たず、多くの場合非常に小さいため、多くは限られた数の人間の言語のテキストを表現するためにしか使用できません。Unicodeは、既知のすべての言語を表現するための共通標準を作成しようとする試みであり、既知の文字セットのほとんどは、非常に大きなUnicode文字セットのサブセットです。Unicodeには複数の文字エンコーディングがありますが、最も一般的なのはUTF-8で、ASCIIとの下位互換性があるという利点があります。つまり、すべてのASCIIテキストファイルは、同じ意味を持つUTF-8テキストファイルでもあります。UTF-8には、簡単に自動検出できるという利点もあります。したがって、UTF-8対応ソフトウェアの一般的な動作モードは、未知のエンコーディングのファイルを開くときに、まずUTF-8を試行し、それが明らかにUTF-8でない場合は、ロケールに依存する従来のエンコーディングにフォールバックすることです。[ 5 ]
ほとんどのオペレーティングシステムでは、テキストファイルという名前は、書式設定がほとんどない(太字や斜体などがない)プレーンテキストコンテンツのみを許可するファイル形式を指します。このようなファイルは、テキスト端末やシンプルなテキストエディタで表示および編集できます。テキストファイルには通常、 MIMEタイプがあり、通常はエンコードを示す追加情報が含まれています。text/plain

DOSとMicrosoft Windowsは共通のテキストファイル形式を使用しており、各行はキャリッジリターン(CR)とラインフィード(LF)の2文字の組み合わせで区切られています。最終行がCR-LFマーカーで終了しないこともよくあり、多くのテキストエディタ(メモ帳を含む)は最終行に自動的にCR-LFを挿入しません。
Microsoft Windowsオペレーティングシステムでは、ファイル名の接尾辞(ファイル名拡張子)が.txtの場合、そのファイルはテキストファイルとみなされます。しかし、テキストファイルには、特定の目的のために他の多くの接尾辞が使用されます。たとえば、コンピュータプログラムのソースコードは通常、ソースコードが記述されたプログラミング言語.txtを示すファイル名の接尾辞を持つテキストファイルに保存されます。
ほとんどのMicrosoft Windowsのテキストファイルは、ANSI、OEM、またはUnicode(UTF-16またはUTF-8)エンコーディングを使用しています。
Microsoft Windowsの用語で「ANSIエンコーディング」と呼ばれるものは、通常はシングルバイトのISO/IEC 8859エンコーディングです(つまり、Microsoftメモ帳のメニューにあるANSIは、実際にはUnicodeではないレガシーエンコーディングである「システムコードページ」です)。ただし、中国語、日本語、韓国語など、ダブルバイト文字セットを必要とするロケールは例外です。ANSIエンコーディングは、Unicodeへの移行以前は、Microsoft Windowsのデフォルトのシステムロケールとして伝統的に使用されていました。
一方、OEMエンコーディング(DOSコードページとも呼ばれる)は、 IBMがオリジナルのIBM PCテキストモード表示システムで使用するために定義したものです。これらには通常、DOSアプリケーションでよく使われるグラフィック文字や線画文字が含まれています。
「Unicode」エンコードされた Microsoft Windows テキスト ファイルには、UTF-16 Unicode Transformation Format のテキストが含まれています。このようなファイルは通常、バイト オーダー マーク(BOM) で始まり、ファイル コンテンツのエンディアンを示します。UTF-8 はエンディアンの問題が発生しませんが、多くの Microsoft Windows プログラム (メモ帳など) は、UTF-8 エンコードされたファイルのコンテンツの先頭に BOM を追加して、UTF-8 エンコードを他の 8 ビット エンコードと区別します。[ 6 ] [ 7 ]
Unix ライクなオペレーティングシステムでは、テキストファイルの形式は正確に記述されています。POSIXでは、テキストファイルは、0 行以上の行に整理された文字を含むファイルとして定義されています[ 8 ]。ここで、行は、0 個以上の非改行文字のシーケンスと、終了改行文字[ 9 ](通常は LF)です。
さらに、POSIXは印刷可能なファイルとは、地域規則に従って、文字が印刷可能、またはスペースまたはバックスペースであるテキストファイルを指します。これには、印刷できないほとんどの制御文字は含まれません。 [ 10 ]
macOSが登場する以前は、従来の Mac OSシステムでは、リソース フォークがファイルのタイプが「TEXT」であることを示している場合、ファイルの内容 (データ フォーク) はテキスト ファイルであるとみなされていました。[ 11 ]従来の Mac OS のテキスト ファイルの行は CR 文字で終了します。[ 12 ]
Unix ライクなシステムである macOS は、テキスト ファイルに Unix 形式を使用します。[ 12 ] macOS のテキスト ファイルに使用されるUniform Type Identifier (UTI) は「public.plain-text」です。その他のより具体的な UTI は、utf-8 エンコード テキスト用の「public.utf8-plain-text」、utf-16 エンコード テキスト用の「public.utf16-external-plain-text」および「public.utf16-plain-text」、および従来の Mac OS テキスト ファイル用の「com.apple.traditional-mac-plain-text」です。[ 11 ]
テキストエディタでファイルを開くと、人間が読める内容がユーザーに表示されます。これは通常、ユーザーに表示されるファイルのプレーンテキストで構成されます。アプリケーションによっては、制御コードはエディタによって実行されるリテラル命令としてレンダリングされる場合と、プレーンテキストとして編集可能な可視エスケープ文字としてレンダリングされる場合があります。テキストファイルにはプレーンテキストが含まれている場合でも、ファイル内の制御文字(特にファイル終端文字)によって、特定の方法ではプレーンテキストが表示されないことがあります。
TeX、Markdown、Wikitextといった軽量マークアップ言語の使用は、プレーンテキストファイルの拡張とみなすことができる。なぜなら、マークアップされたテキストは、機械が解釈可能な注釈を含んでいるにもかかわらず、依然として完全に、あるいは部分的に人間が読み取ることができるからである。初期のHTMLの使用も同様に考えることができるが、現代のウェブサイトのHTMLは、人間にとってほとんど読み取れない。リッチテキストやCSVなどの他のファイル形式も、ある程度は人間が解釈可能であるとみなすことができる。
MS-DOS (CP/M とは異なり) はディレクトリにバイト数を保持しているため、ファイルの正確な終了位置を認識しており、この点に関して特に混乱が生じることはないはずです。ただし、一部の MS-DOS プログラムは、テキスト ファイルを Control-Z 文字で終了するという CP/M の慣例を引き続き使用しており、この終了バイトが存在しないと正しく動作しません。したがって、後述する受信ファイルと送信ファイルの両方に特別な SET EOF オプションがあることに注意してください。
{{cite web}}: CS1 maint: url-status (リンク)はい、UTF-8 には BOM を含めることができます。ただし、バイト ストリームのエンディアンには影響しません
。UTF
-8 は常に同じバイト オーダーです。先頭の BOM は署名としてのみ使用されます。つまり、マークされていないテキスト ファイルが UTF-8 であることを示すものです。UTF-8 エンコードされたデータの受信者の中には、BOM を期待しない人もいることに注意してください。UTF-8 が8 ビット環境で
透過的に
使用されている場合、BOM の使用は、Unix シェル スクリプトの先頭での "#!" の使用など、先頭に特定の ASCII 文字を期待するプロトコルやファイル フォーマットに干渉します。