この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。出典を追加して記事の信頼性向上にご協力ください。（このテンプレートの使い方）
出典検索?: "テキストファイル" ? ニュース ・ 書籍 ・ スカラー ・ CiNii ・ J-STAGE ・ NDL ・ dlib.jp ・ ジャパンサーチ ・ TWL（2019年12月）

テキストファイル（英: text file）は、何らかの文字コードによって表される文字データだけが含まれるファイルのことで、ファイルフォーマットの一種と見なすこともできる。ファイルを読み書きするシステム双方が同じ文字符号化方式をサポートしているという前提であれば、互換性が高く幅広い環境でデータを交換・利用できるというメリットがある一方、高度な付随情報や階層化・構造化された情報を扱う場合はデータ量（ファイルサイズ）が増加しやすいというデメリットもある。対義語はバイナリファイル。
テキストファイルの内部構造

テキストファイルの内部構造は、ほかのファイルフォーマットに比べてきわめて単純である。テキストファイルに含まれる文字コードで表されるデータには、文字と制御文字が含まれる。制御文字によって表される改行は、テキストファイル中でデータの区切りを表す。バイナリファイルと異なり、基本的にファイルの途中でヌル文字（値0）が出現することはない[1]。
文字の内部表現

一般的にコンピュータで処理されるすべてのデータは、内部的に数値として扱われる。文字をコンピュータで処理する場合は、各文字と整数値を対応させた何らかの文字セットによる文字コードが使われる。かつては基本的な英数字（半角英数字）であってもコンピュータごとに使用される文字セットが異なり、そのため異なるコンピュータ間のデータ交換に難があったが、標準規格としてASCIIが制定され、またオクテット（1バイト＝8ビット）を採用するコンピュータが主流になってからは、異なるコンピュータ間の文字データの交換性が向上した。

ASCIIでは、例えば文字Aは16進数表記で0x41、Bは0x42、……になる。そのため、ASCIIでエンコードされた「ABCD」という文字列を表すファイルを作成すると、内部的には16進数で次のように表される。41424344

しかし、英語以外のヨーロッパ言語で使われるウムラウトやセディーユなどを含むラテン文字や、日本語あるいは中国語のような多数の漢字・かなを使用する言語の文字は、7ビット文字コードのASCIIではサポートされていない。これらの文字をサポートするために、ASCIIから派生したシングルバイト・マルチバイト文字セットの拡張規格が乱立し、国際的な文字データの交換に問題が生じる事態となったが、あらゆる言語の文字を包括する規格であるUnicodeおよびISO/IEC 10646が策定されたことによって統一が進みつつある。Webサイトの記述に使用されるHTMLおよびCSSなど、特に互換性が必要とされるテキストファイルには、UTF-8エンコーディングが採用されることがほとんどになっている[2]。プログラミング言語で使われるソースファイルも、同様にUTF-8の採用が進んでいる。

テキストファイル自体はデータの羅列であり、文字のエンコーディング方式を記述／判定するために決められた方法はない。そのため、ファイル先頭に記述されたタグ情報やマジックナンバー（バイトオーダーマーク）をもとにエンコーディングを判断する、含まれるデータ列の規則性をもとにエンコーディングを推定する、あるいはエンコーディングを決め打ちで仮定するなどの方法を採る必要がある。
制御文字

制御文字は、モニタやプリンタなどの機器を制御するためのデータで、改行を表す改行文字やタブ（水平タブ）などが含まれる。制御文字には、文字と同じようにそれぞれ文字コードが割り当てられる。ASCIIの制御文字では、例えば改行文字 (LF) は0x0A、水平タブ (HT) は0x09である。

テキストファイルの終端に制御文字として、EOF（End Of File、ファイル終端マーク）をつける場合がある。歴史的には、CP/Mオペレーティングシステムに由来する。CP/Mではファイルを、ファイルシステムの（128バイトの）ブロック単位でのみ管理し、1バイト単位のファイルサイズは管理していなかった。ファイルがバイナリ（プログラム）の場合は未使用の領域があるだけで問題ない。しかし、テキストの場合は終端を識別するものが必要となり、ASCIIの置換文字 (SUB) である0x1Aを終端の次の1バイトに付加しファイルの終端を識別することにしていた。MS-DOSでは、CP/Mとの互換性のためテキストファイルにEOFを付加するのが一般的であった。
改行

テキストファイルでは、人間にとってもプログラムにとっても、改行はファイルの中でのデータの区切りを表す重要な部分である。プログラム処理を考える場合、テキストファイル中の1つの行、すなわち改行で区切られた部分は、1つのレコードであると見なすこともできる。後述するように、改行の表現方法はコンピュータ環境によって異なる場合がある。
テキストファイルとバイナリファイル

テキストファイルは、バイナリファイルの対義語である。バイナリファイルは、処理の高速化やデータ圧縮、付加情報を表すデータやマルチメディアなどテキスト以外のデータを格納する、などの目的で使用される。例えばMicrosoft Wordで作成して、.docまたは.docx形式として保存したファイル、すなわちWordドキュメントファイルは、テキスト以外のさまざまなデータを含むバイナリファイルである[注釈 1]。なお、テキストとテキスト以外のデータが混在しているファイルは、バイナリファイルに分類される。
テキストファイルの利点と欠点

テキストファイルには、次の利点がある。こうした利点は、テキストファイルの単純さから生じている部分が大きい。

異なる環境間でも比較的互換性が高い。ASCIIの範囲内の文字データのみであれば、特に互換性が高い。

対応するプログラムを比較的容易に作成できる。

数値を可変長テキストで表現する場合、0や1のように1桁の数値は8ビット単位でエンコーディングすると1バイトで表現できるため、32ビットや64ビットの固定長バイナリ表現よりもデータが小さくなる。

数値を10進数テキストで表現する場合、内部表現に依存しない。例えば、2の補数やIEEE 754を採用しているシステムと採用していないシステムとの間で情報を交換しやすい。

8ビット単位（バイト単位）でエンコーディングする場合、エンディアン（バイトオーダー）に依存しない。

テキストファイルは一般的なテキストエディターで読み書きすることができるが、バイナリファイルはアプリケーションソフトウェアごとにさまざまなファイルフォーマットが存在しており、対応アプリケーションがないと読み書きが困難あるいは不可能であることも多い。ただし、JPEGやPNG、あるいはPDFのように、バイナリ形式であっても標準化が進んでおり、異なるアプリケーション間で読み書きができるファイルフォーマットも存在する。

以上のような理由から、オペレーティングシステム (OS) およびアプリケーションの設定ファイルとしてテキストファイルを採用しているケースも多い。

一方、テキストファイルでは、バイト列の表現はデータサイズが増大しやすく不向きである。例えばラスター画像形式のデータにおける各ピクセルのRGB色情報配列などが挙げられる。PNM画像フォーマットにはASCII形式のP1/P2/P3とバイナリ形式のP4/P5/P6があるが、例えば8ビット階調のグレースケールの場合、バイナリ形式では各ピクセルのデータ幅はその階調値によらず常に8ビット固定となるため、ASCII形式よりもファイルサイズが小さくなる。

テキストでバイト列を表現する場合、16進数表記を使ってもバイナリの場合の2倍の容量が必要となる。情報量を削減するために、Base64エンコーディングを施すこともある[4]。情報量が増えると、エンコードおよびデコードの処理にかかる時間も比例して増え、パフォーマンス低下の要因となる。
テキストファイルでは直接扱えないデータ

単純なテキストファイルでは、文字コードで表される文字以外のデータは格納できない。そのため、例えば次のようなデータを直接含むことができない。