テキストファイル
 |
テキストファイル（英: 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]。情報量が増えると、エンコードおよびデコードの処理にかかる時間も比例して増え、パフォーマンス低下の要因となる。
テキストファイルでは直接扱えないデータ
[編集]単純なテキストファイルでは、文字コードで表される文字以外のデータは格納できない。そのため、例えば次のようなデータを直接含むことができない。
上記のデータをテキストで表現するには、何らかの書式やルールを定めて構造化したり、文字列としてエンコーディングしたりする必要がある。しかしその場合、バイナリと比べてファイルサイズが肥大化しがちになる。
先進的なテキストファイル
[編集]テキストファイルでありながら付加情報やマルチメディアに対応した先進的なファイルフォーマットとして、例えば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ではRFC標準のJSON仕様に対してコメントを扱えるように拡張を加えたJSONC (JSON with Comments) 形式のテキストファイルによって設定を管理する（settings.jsonなど）[7][8]。
テキストファイルの種類
[編集]テキストファイルは、次の点で分類される。
- 各行（レコード）が固定長か可変長か
- 文字コード
- 改行コード
固定長レコードと可変長レコード
[編集]メインフレーム/汎用機は多くの場合、固定長レコードファイルを扱うのが一般的であった。そのためメインフレーム/汎用機で使われるテキストファイルはすべての行（レコード）を同じ長さにするよう、長さが足りない場合には空白文字などで埋めるようになっている。
一方、UNIXやPCなどでは可変長の行（レコード）を扱うことができ、任意の位置に改行文字を挿入する。
文字コード
[編集]文字のうち、英数字を表す文字コードはほぼASCIIで統一されている。それ以外の、例えば日本語の漢字やかななどを表す文字コードはさまざまな種類があり、互換性を下げる要因となっている。
英数字
[編集]現在[いつ?]のPCや個人用モバイル端末などでは、テキストファイルで使われる文字コードのうち英数字を表すものは、ASCIIまたはASCII互換のものがほとんどである。そのため、英数字が文字化けすることはほとんどない。
ASCIIに含まれる記号類に関しても同様であるが、バックスラッシュを表す文字コード0x5Cのように、たとえASCIIで標準化されていても、フォントや環境によっては異なる字形で表示されてしまうものもある（内部的な文字コードとしては同じ数値だが、歴史的な経緯から、日本語環境では円記号として表示されるケースが多い）。
なお、メインフレーム/汎用機などでは文字コードとしてEBCDICが使われることが多い。
英数以外の文字
[編集]英数以外の文字を表す文字コードはさまざまな種類があり、英数字の場合のように統一されていない。そのため、英数字以外の文字を含むテキストファイルは、英数字だけを含むテキストファイルに比べて互換性が低い。
また、英数以外の言語を表す文字はさまざまな文字コードが使われているため、英語をのぞく複数の言語の文字を混在させることは難しい。例えば、アルファベットと漢字・かな、アルファベットとアラビア文字が混在した文書はそれぞれ比較的容易に作成できるが、漢字・かなとアラビア文字が混在する文書の作成は難しい。
日本語の文字コード
[編集]日本語の漢字・かななどでは、文字コードの文字符号化方式として次の3種類が使われてきた。
| 文字符号化方式 | 使用環境 |
|---|---|
| ISO-2022-JP | インターネット（特に電子メール） |
| Shift_JIS | MS-DOS・WindowsやClassic Mac OS（バージョン9まで） |
| EUC-JP | UNIXやLinux |
厳密に言うと、MS-DOS/Windowsで使われているShift_JISはMicrosoftコードページ932（Windows-31J）と呼ばれる独自拡張であり、Classic Mac OSで使われていたShift_JISはMacJapaneseと呼ばれる独自拡張であり、互換性のない文字が存在する。
そのため、漢字・かななどを含むテキストファイルを異なる環境で使う場合、文字化けなどの問題が発生しやすい。例えば、Linux上で作成した漢字・かなを含むテキストファイルをそのままWindows上で開くと、文字化けすることが多い。こうした問題を解決するには、複数の文字コードに対応するプログラムや、変換ツールが必要になる。
Unicode
[編集]Unicodeは、世界中のすべての文字を統一的に扱えることを目指した、符号化文字集合の国際標準規格である。また、Unicodeの文字符号化方式にはいくつかの種類があるが、実用的にはUTF-8やUTF-16が利用されることが多い。
Unicodeが広く普及することで、英数字以外の文字を扱うときの互換性が高まり、また多言語の文字が混在する文書が容易に作成できるようになることが期待されている。ウェブサイト（ウェブページ）のテキストエンコーディングとしては、2012年にUTF-8の普及率が60%を超え、ASCIIも含めると80%程度となった[9]。2017年には90%を超えた[2]。
しかし、メンテナンスされていない古いウェブサイトに関しては従来の文字コードのままであり、Unicodeによって完全に置き換わっているわけではなく、文字コードに関する混乱が増している一面もある。漢字やかなの場合、UTF-8やUTF-16など文字符号化方式の種類が増えたため、文字化けなどの問題はより難しくなっている一面もある。サロゲートペア、結合文字（異体字セレクタを含む）、書記素クラスタ、絵文字や合成絵文字などを正しく扱えるプログラムおよび対応フォントでなければ、本来意図されたUnicodeのデータシーケンスを正しく解釈して、1つの文字として表示したり編集したりすることができない。さらにUnicode規格にはバージョンがあり、新しい規格に対応していない古いシステムでは正しく表示できない文字も増えている。
なお、Unicodeは文字セットを小さくしようとして、中国語・日本語・朝鮮語の漢字を区別せず、似た字形の文字は言語を問わずCJK統合漢字としてコードポイントを一緒くたにしてしまうという致命的な設計ミスを犯した。そのため、例えば中国語と日本語が混在したテキストデータ自体を作成することはできるものの、単一のフォントでは正しく表示することができない。正しく表示させるには、テキストの本来の言語に応じたグリフセットを持つフォントを指定する必要がある（ウェブページの場合はブラウザのレンダリングエンジンにフォントを自動選択させると誤ることがあるので、文書の言語を明示的に指定する）[10]。
改行コード
[編集]テキストファイル内で用いられる改行を表すコードは、コンピュータの種類ごとに違いがあり、互換性を下げる要因となっている。いずれの場合においても、改行は制御文字LF（0x0A）と制御文字CR（0x0D）で表される。このうち、LF（Line Feed）は行送り、CR（Carriage Return）は復帰を表す。
| コンピュータの種類 | 改行コード |
|---|---|
| MS-DOS・Windows | CR+LF |
| UNIX | LF |
| Classic Mac OS（バージョン9まで） | CR |
MS-DOSは、CP/Mとの互換性を持たせるためにCR+LFを採用し、Windowsもそれを踏襲することになった[11]。Microsoft Visual C++の標準Cライブラリのfopen()にテキストモードを指定してファイルを開くと、入力時（読み取り時）にCR+LFを単独のLFに自動変換し、出力時（書き込み時）に単独のLFをCR+LFに自動変換する動作となる[12]。このような動作が好ましくないアプリケーションの場合、バイナリモードを使用する必要がある。
UnixベースのOSとして再設計されたMac OS X（のちにOS Xを経てmacOSに改名）では、LFを採用するようになった。
例えばWindows上で作成したテキストファイル（改行はCR+LF）をUnix/Linux上で開いた場合、改行コードの違いが原因で、各行の末尾に異常な文字が表示されることがあった。逆に、Unix/Linux上で作成したテキストファイル（改行はLF）をWindows上で開いた場合、改行されずに行がつながってしまうこともあった[11]。もっとも、このような問題の多くはテキストファイルを読み書きするテキストエディター側で吸収・対処できるものであり、モダンなテキストエディターはCR+LFまたはLFのみの改行コード方式の両方に対応している。改行コードが混在していてもそのまま扱い、保存する際に改行コードの違いを維持するものもあれば、どちらかに統一して保存するものもある。ただし、改行コードの混在は問題を引き起こすことも多いので、少なくとも1つのファイル内ではどちらかに統一したほうが望ましい。Microsoft Visual Studioのコードエディターでは、ソースファイルを開いたときに改行コードの混在（不整合）を検出し、統一して開き直すかどうかをユーザーに尋ねるダイアログが表示されるようになっている。
なお、電子メールで送信するときは改行にCR+LFを使うように、RFC 2822内で規定されている[13]。
テキストファイルの編集
[編集]一般的なソフトウェア
[編集]テキストファイルには数多くのソフトウェアが対応しており、例えば、Wordや一太郎、Excelなどでは、ファイル保存時にテキストファイルとして保存することを指定すれば、テキストファイルの作成・編集ツールとして使える。しかし、テキストファイル編集時にはこうしたソフトウェアの豊富な機能の多くが使えないことになる。また、テキスト編集のためには逆に機能が限られていることも多い。
テキストエディター
[編集]テキストエディターはテキストファイルの作成・編集・閲覧に特化したソフトウェアであり、軽快でテキストの読み書きに便利な機能を備えていることが多い。プログラミング言語を含むコンピュータ言語全般のソースファイルの編集に特化したテキストエディターはコードエディターと呼ばれる。統合開発環境に搭載されているコードエディターは、言語のキーワード（予約語）などに応じたテキストの色分けやコード入力補完といった高度な機能も備えており、デバッガーとの連携もできるようになっている。
プログラム処理
[編集]テキストファイルは単純なため、プログラム処理が比較的簡単である。特に、sedやPerlなどはテキスト処理を目的とした言語であるため、比較的簡単な記述で複雑な処理ができる。
脚注
[編集]注釈
[編集]- ^ Microsoft Office 2007以降で採用されたOffice Open XML形式は、複数のXMLやメディアファイルをZIPでアーカイブしたものであり[3]、こちらもバイナリファイルであると言える。
出典
[編集]- ^ 用語集: Null 文字
- ^ Word文書に載っている画像をまとめて取り出す方法！ ExcelやPowerPointでも使える裏技 - 残業を減らす！Officeテクニック - 窓の杜
- ^ バイナリー・データの処理 - IBM Documentation
- ^ XML シリアル化の詳細 | Microsoft Learn
- ^ ConfigurationManager.AppSettings Property (System.Configuration) | Microsoft Learn
- ^ Visual Studio Code User and Workspace Settings
- ^ “JSON editing in Visual Studio Code” (英語). Documentation for Visual Studio Code. 2023年10月7日閲覧。 “In addition to the default JSON mode following the JSON specification, VS Code also has a JSON with Comments (jsonc) mode. This mode is used for the VS Code configuration files such as settings.json, tasks.json, or launch.json.”
- ^ UTF-8の普及率が60%を突破、ASCIIも含めれば80%に近づく | TECH+（テックプラス）
- ^ Your code displays Japanese wrong | Your Code Displays Japanese Wrong
- ^ a b ASCII.jp：Windowsにおける改行文字の扱い (1/2)
- ^ fopen, _wfopen | Microsoft Learn
- ^ 改行について - めぇるの部屋
関連項目
[編集]| 形式 | |
|---|---|
| 属性 | |
| 組織 | |
| 操作 | |
| リンク | |
| 管理 | |
 カテゴリ | |