テキストファイル

テキストファイルの内部構造は、ほかのファイルフォーマットに比べてきわめて単純である。テキストファイルに含まれる文字コードで表されるデータには、文字と制御文字が含まれる。制御文字によって表される改行は、テキストファイル中でデータの区切りを表す。バイナリファイルと異なり、基本的にファイルの途中でヌル文字（値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]。情報量が増えると、エンコードおよびデコードの処理にかかる時間も比例して増え、パフォーマンス低下の要因となる。

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

• 付加情報を表すデータ
  • 文書情報を表すデータ
  • 文書の構造を表すデータ
  • 文書や、その一部のスタイルやレイアウトを表すデータ
• マルチメディア
  • 画像
  • 音声
  • 動画

上記のデータをテキストで表現するには、何らかの書式やルールを定めて構造化したり、文字列としてエンコーディングしたりする必要がある。しかしその場合、バイナリと比べてファイルサイズが肥大化しがちになる。

テキストファイルでありながら付加情報やマルチメディアに対応した先進的なファイルフォーマットとして、例えばLaTeXやHTML、XMLがある。

HTMLやXMLでは、付加情報を表すデータやマルチメディアデータへの参照をタグで表す。HTMLやXMLのファイルは、テキストファイルとして開くとタグも含めた文書の内容がそのまま表示され、対応するウェブブラウザなどで開くとタグの記述内容に従った文書の表示や処理の実行が行われる。

このようなフォーマットはマークアップ言語と呼ばれる。

.NETでは、XMLテキストによるオブジェクトのシリアライズと逆シリアライズをサポートする^[5]。これにより、XMLテキストファイルへの.NETオブジェクトの保存と読み込みを実装できる。.NET Framework 2.0以降では、アプリケーションの設定をXMLファイル経由で簡単に読み書きするユーティリティクラスも用意されている^[6]。

アプリケーションの設定を管理するテキストファイル形式として、古くはINIファイルが用いられてきたが、MSXML（英語版）のようなOS標準コンポーネントやJavaなどのプログラミング言語における標準ライブラリによってXMLが広くサポートされるようになったこともあり、INIファイルよりも柔軟かつ機能性の高いXMLを設定ファイルとして採用するアプリケーションも多い。

一方、XMLよりも軽量なデータ記述言語として、JSONやその派生形式が使用されるケースも増えている。たとえば、Visual Studio Codeではsettings.jsonというファイル名でJSONC (JSON with Comments)形式のテキストファイルによって設定を管理する^[7][8]。

テキストファイルは、次の点で分類される。

• 各行（レコード）が固定長か可変長か
• 文字コード
• 改行コード

メインフレーム/汎用機は多くの場合、固定長レコードファイルを扱うのが一般的であった。そのためメインフレーム/汎用機で使われるテキストファイルはすべての行（レコード）を同じ長さにするよう、長さが足りない場合には空白文字などで埋めるようになっている。

一方、UNIXやPCなどでは可変長の行（レコード）を扱うことができ、任意の位置に改行文字を挿入する。

文字のうち、英数字を表す文字コードはほぼASCIIで統一されている。それ以外の、例えば日本語の漢字やかななどを表す文字コードはさまざまな種類があり、互換性を下げる要因となっている。

現在のPCや個人用モバイル端末などでは、テキストファイルで使われる文字コードのうち英数字を表すものは、ASCIIまたはASCII互換のものがほとんどである。そのため、英数字が文字化けすることはほとんどない。

なお、メインフレーム/汎用機などでは文字コードとしてEBCDICが使われることが多い。

英数以外の文字を表す文字コードはさまざまな種類があり、英数字の場合のように統一されていない。そのため、英数字以外の文字を含むテキストファイルは、英数字だけを含むテキストファイルに比べて互換性が低い。

また、英数以外の言語を表す文字はさまざまな文字コードが使われているため、英語をのぞく複数の言語の文字を混在させることは難しい。例えば、アルファベットと漢字・かな、アルファベットとアラビア文字が混在した文書はそれぞれ比較的容易に作成できるが、漢字・かなとアラビア文字が混在する文書の作成は難しい。

日本語の漢字・かななどでは、文字コードの文字符号化方式として次の3種類が使われてきた。

そのため、漢字・かななどを含むテキストファイルを異なる環境で使う場合、文字化けなどの問題が発生しやすい。例えば、Linux上で作成した漢字・かなを含むテキストファイルをそのままWindows上で開くと、文字化けすることが多い。こうした問題を解決するには、複数の文字コードに対応するプログラムや、変換ツールが必要になる。

Unicodeは、世界中のすべての文字を共通で扱えることを目指した、符号化文字集合の規格である。また、Unicodeの文字符号化方式としてUTF-8やUTF-16が利用されることが多い。

Unicodeが広く普及することで、英数字以外の文字を扱うときの互換性が高まり、また多言語の文字が混在する文書が容易に作成できるようになることが期待されている。

しかし現在では、Unicodeが普及途上ということもあり、文字コードに関する混乱が増している一面もある。漢字やかなの場合、UTF-8やUTF-16など文字符号化方式の種類が増えたため、文字化けなどの問題はより難しくなっている一面もある。

テキストファイル内で用いられる改行を表すコードは、コンピュータの種類ごとに違いがあり、互換性を下げる要因となっている。いずれの場合においても、改行は制御文字LF（0x0A）と制御文字CR（0x0D）で表される。このうち、LF（Line Feed）は行送り、CR（Carriage Return）は復帰を表す。

例えばWindows上で作成したファイルをLinux上で開いた場合、改行コードの違いが原因で、各行の末尾に異常な文字が表示されることがある。

テキストファイルには数多くのソフトウェアが対応しており、例えば、Wordや一太郎、Excelなどでは、ファイル保存時にテキストファイルとして保存することを指定すれば、テキストファイルの作成・編集ツールとして使える。しかし、テキストファイル編集時にはこうしたソフトウェアの豊富な機能の多くが使えないことになる。また、テキスト編集のためには逆に機能が限られていることも多い。

テキストエディタはテキストファイルの作成・編集・閲覧に特化したソフトウェアであり、軽快でテキストの読み書きに便利な機能を備えていることが多い。

テキストファイルは単純なため、プログラム処理が比較的簡単である。特に、sedやPerlなどはテキスト処理を目的とした言語であるため、比較的簡単な記述で複雑な処理ができる。

• テキスト
• プレーンテキスト
• ファイルフォーマット