コンピュータの世界で「テキストファイル」と呼ばれるファイルは存在するが、実際にテキストファイルをテキストファイルならしめているのは、ファイル自体ではなく、それを読み込むプログラムのほうである。
より簡単に言えば、中身がテキストであるという前提に立ってファイルを読み込んで解釈するプログラムは存在するが、読み込むファイル自体には、テキストファイルという特別な区別は存在せず、ファイルは等しく同じものしかない。
このテキストファイルには「行末文字」がある。改行文字、改行コードともいう。本記事では「ラインフィード」が「改行」となり、混乱を防ぐ意味からも、テキストの行末にある区切り文字を「行末文字」と呼ぶことにする。
行末文字は、短いテキストファイルには存在しないこともあるが、行末文字があるために、テキストファイルには「行」が存在できる。行末文字は主にプラットフォームで決まっており、「LFのみ」「CRのみ」「CRLF」の3パターンがある。
現在では、テキストファイルをインターネットから入手することもあり、必ずしもプラットフォームと同じ行末文字が使われているとは限らない。
Windowsでは、MS-DOS時代からテキストの行末文字は「CRLF」だった。MS-DOSは、先行する8ビットCPU用OS「CP/M」と互換性を持たせたからだ。このあたりについては、過去記事(「Windows 10 RS5では「メモ帳」がCR+LF以外の行末記号に対応」)も参照してほしい。
行末文字とテキストファイル
テキストファイルは、テキストと行末文字やタブ文字などの制御コードなどからなるファイルだが、一般にファイルとして、テキストファイルではないものと比較して何か特別なしるしがあるわけではない。
拡張子に「txt」を用いることも多いが、これもあくまでも「約束事」の範囲を出ない。たとえば、拡張子をほかのものにすることもできれば、拡張子が「txt」なのにバイナリ形式になっていることだってある。Windowsの拡張子は、デフォルトで扱うプログラムとの対応に使われているだけで、ファイル形式に関しては、何も保証されていないことは理解しておいたほうがいいだろう。
そもそも、ファイルのすべてのコードを判定して、テキストファイルかどうかを判定することも難しい。どんなに巨大でも、ファイルを全部見なければ、テキストかどうかわからないため、判定に時間がかかってしまう。また、文字コードにより、使われるコード範囲が異なるため、文字コードを特定しないと、ファイル内容がテキストかどうかの判定ができない。しかし、一般的にファイルは文字コードに関する情報を持たず、「Windows XPでは、シフトJISコードを使う」といった約束事で対応していることがほとんどだからだ。
文字コードにより、絶対に登場しないバイト列は存在するが、その文字がファイル中に存在しないのでなければ、判定できない。また、文字コード同士、たとえば「ASCII」と「UTF-8」のようにバイト列が共通している場合があり、共通部分の文字しか入っていない場合には、コードを決定できない。
文字コードが確定していなければ、ファイルがテキスト形式かどうかを判断できず、また、ファイルから文字コードを自動判定することは、常にできるわけではない。
前述のようにテキストファイルの行末文字には、3つのパターンがある。実際には、これも約束事でしかなく、複数の行末文字が存在するようなファイルを作ることも可能だ。かつて、Windowsに付属のメモ帳は、Windows標準の「CRLF」しか許容していなかったが、Windows 10/11に付属するメモ帳では、複数の文字コード、複数の行末文字を許容している(冒頭画面)。判定は、最初の行の行末文字で判定されるようだが、行末文字が混在していても読み込むことが可能なのである
テキストモードとバイナリモード
プログラムは、ファイルを処理する場合に外部記憶装置からメモリに読み込みをする。このとき、ファイル内容が「テキスト」であるとして、前処理をすることがあり、これを一般的に「テキストモード」という。
逆に、テキストではない前提でファイルを読み込むことを「バイナリモード」という。ファイルを読み込むプログラムは、必ず、このモードのどちらか1つを持つ(両方持つプログラムも存在する)。ファイルシステムには、「テキストファイル」という区別を持つファイルは存在しないが、プログラムにはテキストモードとバイナリモードという区別がある。
プログラムによっては、バイナリモードでの読み込みを強制する機能を持つ場合がある。たとえば、メモ帳のようなエディタプログラムは、テキストモードしか持たないが、Windowsの標準コマンドfc.exeには、「テキストモード」と「バイナリモード」の区別がある。
テキストモードでは、行末文字が意味を持つ。読み込み中に行末文字を見つけたら、そこを行末として、テキストの行を構成していく。このときに行末文字は、内部コードに変換されることが多い。というのも前述のように3種類の行末文字があるからだ。
今のところ、行末文字はこの3種に限定されるので、この処理は、人手を介さずに完全に自動で可能。行末文字が混在していても基本的には問題ない。かつては、プラットフォームの約束事にしか従わないプログラムもあったが、現在ではどの行末文字でも正しく文末として認識するような作りが一般的だ。
かつては、プラットフォームでテキストファイルの行末文字に対して約束事があり、これに従ってプログラムが作られていた。たとえば、Windows 10より前、メモ帳はCRLFだけを行末文字として認識していたため、Unixなどから転送されてきたテキストファイルでは行が全部つながってしまったことがあった。
こうしたこともあり、かつては、テキストファイルの行末文字を変換して処理する必要があったが、最近では行末文字の変換はほぼ不要となった。

この連載の記事
-
第399回
PC
Windowsではプロセスからプログラムに関するさまざまな情報が得られる -
第398回
PC
Windows Subsystem for Androidの進化を確認 エクスプローラーからのファイルのドラッグ&ドロップが可に -
第397回
PC
Windowsにおけるディスク、ドライブ、パーティションの扱いの違い -
第396回
PC
Windows 11における新規作成コンテキストメニュー -
第395回
PC
Windowsの「近距離共有」は微妙だが、Windows版も登場した「ニアバイシェア」は使える -
第394回
PC
コマンドの出力が長いとき、PowerShellではとりあえずselect-objectでなんとかする -
第393回
PC
Windows 11のWinUI3対応で、MicrosoftはWin32アプリ、さらにWindows自体を改良しようとしている -
第392回
PC
あらためてWindowsにおける2進数、10進数、16進数について -
第391回
PC
WindowsのNTFS/ReFSに搭載されている「再解析ポイント」とは何か? -
第390回
PC
この秋登場予定のWindows 11 Ver.23H2はどうなるか? -
第389回
PC
Windowsにおけるファイルリンクについてあらためて説明する - この連載の一覧へ