歴史レッスン：.txtファイルとは？古いテキストファイルが文字化けする理由

「.txtファイル」とは？

どんなエディターで.txtファイルを開いても、見えるのは文字だけです。文字、数字、句読点、スペース、改行。これがフォーマットのすべてです。ヘッダーも、フォントも、太字や斜体も、ページサイズも、テキストの言語の記録もありません。ファイルが実際に持っているのは0〜255の数字であるバイトの並びで、開くプログラムが各数字をどの文字として扱うかを決めなければなりません。拡張子「.txt」はWindowsにどのプログラムを提案するかを伝えるだけで、バイトの読み方については何も語りません。だからプレーンテキストは、これまでに作られた中でもっとも持ち運びやすい形式の一つであり、同時にもっとも読み間違えやすい形式の一つでもあります。

.txtファイルが文字化けするのはなぜ？

ファイルを読むプログラムが、書いたプログラムとは別の文字コードを使っているからです。同じ文字でも保存されるバイトは変わります。éは、Microsoftが英語などの西ヨーロッパ言語で通常使われるコードページと説明するWindows-1252では1バイトのE9ですが、UTF-8では2バイトのC3 A9です。UTF-8のファイルをWindows-1252として開くと、すべてのéがéになります。曲線のアポストロフィ’（UTF-8ではE2 80 99）は’になります。バイト順マーク（BOM、後述）で始まるUTF-8のファイルは、先頭にが現れます。逆にWindows-1252のファイルをUTF-8として開くと、単独のバイトE9は正しいUTF-8ではないため、プログラムは置換文字�を表示します。

DOS時代のファイルは、別の形で失敗します。最初のIBM PCでは、同じバイトがさらに別の文字になりました。DOSの文字セットであるコードページ437では、バイト82はéで、5バイトのC9 CD CD CD BBは枠の上辺（╔═══╗）を描きます。Windowsはこれをコードページ1252として読み、‚とÉÍÍÍ»と表示するので、caféという語はcaf‚になり、READMEの枠付きバナーは文字の羅列に変わります。

プログラムだけで常に正しく判断することはできません。2007年、MicrosoftのRaymond Chenは、D0 AEという2バイトのファイルでメモ帳のジレンマを示しました。Windows-1252として読めばЮ、UTF-8として読めばキリル文字のЮ、UTF-16（1文字2バイト）として読めばバイト順ごとに異なる韓国語のハングル1音節になります。4通りの読み方がどれももっともらしい、と彼は指摘しました。ファイルの中にラベルがなければ、「変な文字」とは、間違った推測の見た目にすぎません。

1963年：ASCIIが128文字に番号を振る

プレーンテキストがファイルになるには、異なる機械が合意できる文字の番号が必要でした。American Standards Associationは1960年8月に符号化文字セットの小委員会を設け、1963年6月17日に規格X3.4-1963、American Standard Code for Information Interchange、つまりASCIIを承認しました。制御文字、数字、句読点、英語のアルファベットのための128個の値を持つ7ビットのコードでした。1963年版は承知のうえで不完全で、表の多くがまだ割り当てられていませんでした。1967年7月7日に承認された改訂版X3.4-1967についての1967年の通知は、ASCIIプロジェクトの関係者の大半が、これを基本となる7ビットコードの最初の本当の完成と見ていると述べています。

7ビットは1バイトにきれいには収まりません。この扱いを述べた最も初期の文書の一つが、1969年10月にVint Cerfが初期のARPANET（インターネットの前身となった研究ネットワーク）のために書いたRFC 20です。そこでは「最上位ビットが常に0である8ビットのバイトに埋め込まれた、標準の7ビットASCII」が提案されました。この使われない8ビット目が、のちの混乱の始まりです。1バイトが256個の値を持てるようになれば、残りの128個は誰でも自由に割り当てられるからです。

CR、LF、それとも両方：行の終わり方

ASCIIはテレタイプライターの機構も符号化しました。Chenの説明では、復帰（CR）は用紙を送らずに印字ヘッドを0桁目へ戻し、改行（LF）はヘッドを動かさずに用紙を1行送るので、新しい行を始めるには両方が必要でした。RFC 20に再掲されたASCIIの1968年版は、LFに「新しい行」の意味を持たせることを認めつつ、その使用には「データの送信側と受信側の合意が必要」と付け加えています。この合意は完全には成立しませんでした。RFC 20自身が、初期のARPANETの拠点の間で意見が分かれていたことを記録しています。SRIは行末文字にピリオドを使い、UCLAは復帰を使っていました。

CP/M、MS-DOS、Windowsは両方の文字を残し、CRLF（バイト0D 0A）にしました。UnixはLF（0A）1つで済ませました。Microsoftの2018年のメモ帳の新しい動作についての発表には、現在扱える3つの慣習が挙げられています。Unix/Linuxの改行（LF）、Macintoshの改行（CR）、Windowsの改行（CRLF）です。それまでメモ帳はWindowsの改行しか正しく表示できず、UnixやLinuxで作ったテキストファイルは崩れて見えた、と発表にはあります。この修正は2018年5月にWindows 10のInsiderビルドに届きました。

1981年：残り128個の値がそれぞれの道へ

IBM PCは1981年に、8ビットのバイトと7ビットの標準を持って登場しました。技術者の一人David Bradleyは、PCが「ASCII文字セットを使った。IBM製品としては根本的な変更だった」（IBMのそれ以前の製品はEBCDICを使っていました）と後に回想し、埋めるべき128個の新しい枠に、外国語の文字、ブロックグラフィックス、数学記号やギリシャ文字を入れたと語っています。彼はこの文字セットを「3人で4時間の会議」で作ったものだと言うのが好きだったそうです。その結果がコードページ437で、Microsoftは英語用の通常のOEM（DOS）コードページと呼んでいます。上半分には、アクセント付き文字、罫線文字、記号が入っています。

その後、Windowsは独自のコードページを作りました。Microsoftのドキュメントによると、Windowsのコードページ1252は、もとはのちにISO 8859-1となるAmerican National Standards Institute（ANSI）の草案に基づいていましたが、規格が確定する前に実装されたため、完全には同じではありません。Windowsのコードページは今でも一般に「ANSIコードページ」と呼ばれますが、実際にはMicrosoft独自のものです。どれも0〜127の値ではASCIIと一致し、それより上では食い違います。バイトE9は、コードページ1252ではé、キリル文字の1251ではй、ギリシャ文字の1253ではιです。日本語や中国語には2バイトのコードページが使われ、一部のバイトは続くバイトと組み合わさって初めて意味を持ちます。Microsoftは、Unicodeが扱う範囲を1つのコードページで網羅するものはないと述べています。

1992年：Unicodeと、ニュージャージーのダイナーの紙のランチョンマット

Unicodeは正反対のアプローチを取りました。すべての文字に1つの番号を与え、コードページを使い分ける必要をなくすのです。最初のバージョン（1991〜1995年）は16ビットの符号化でしたが、1996年7月のUnicode 2.0以降はU+0000〜U+10FFFFの範囲を扱います。ただし番号はファイルではありません。16ビットの値をそのままファイルに保存すると、ヌルバイトやスラッシュのようなASCIIのバイトを前提にした当時のUnixソフトウェアと衝突しました。1992年には、X/Openの委員会がUnixに適したUnicodeの保存方法を検討していました。

当時Bell LabsにいたRob Pikeは、2003年に、UTF-8は「1992年の9月ごろの夜、ニュージャージーのダイナーの紙のランチョンマットの上で、私の目の前で設計された」と書きました。委員会のメンバーが、彼とKen Thompsonに提案の検討を頼んでいたのです。二人は夕食に出かけ、Thompsonがビットの詰め方を考え出し、その後で委員会に電話をかけました。Pikeによれば、Thompsonはその夜のうちにパックとアンパックのコードを書き、金曜日までに彼らのオペレーティングシステムPlan 9は、のちにUTF-8と呼ばれるものだけで動いていたそうです。同僚のRuss Coxが掘り出したメールのアーカイブは、この提案を1992年9月初めと位置づけています。

UTF-8は、1文字を1〜4バイトで保存します。128個のASCII文字は1バイトの値のままで、他の文字のどのバイトもASCIIのようには見えないので、純粋なASCIIのファイルはそのまま有効なUTF-8です。それ以外は2〜4バイトを使い、先頭のビットが読み手に並びの長さを教えます。éはC3 A9になります。François YergeauのRFC 3629（2003年11月）がこれをインターネット標準にし、UnicodeのFAQは「Unicodeテキストファイルの望ましい形式」と呼んでいます。

BOM、そしてメモ帳が推測せざるをえなかった理由

UTF-16は文字を16ビット単位で保存するため、読み手はバイト順も知る必要があります。Unicodeの答えは、ファイルの最初に署名として置く文字U+FEFF、つまりバイト順マークです。UTF-8ではバイトEF BB BFとして現れ、UnicodeのFAQは、UTF-8ではバイト順とは無関係で、ファイルがUTF-8であることを示すだけだと明言しています。さらにFAQは、BOMを想定しないプログラムがある（#!で始まるUnixのシェルスクリプトの1行目が一例）こと、そして「.txtファイルに関するMicrosoftの慣習」のようなプロトコルがBOMを要求することがあるとも述べています。つまり.txtファイルはBOMで始まることも始まらないこともあり、ないときはプログラムが推測しなければなりません。

Chenの2007年の記事「メモ帳のファイルエンコーディング問題」は、推測がうまくいかない理由を説明しています。BOM付きのファイルは簡単です。BOMがなければ、世の中のテキストファイルの大半は8ビットのANSIで、一部のUTF-8やUTF-16のファイルにもBOMがなく、彼が試したどの規則も、あるグループを優遇すれば別のグループを壊しました。彼の例では、コマンドcmd /u /c dir >results.txtは、BOMなしのUTF-16ファイルを書き出します。

Microsoftはメモ帳を2段階で変えました。2018年にUnixとMacの改行を扱えるようになりました。その後、2018年12月10日のWindows 10 Insiderビルド18298で、BOMなしのUTF-8で保存するオプションを追加し、新規ファイルの既定にして、文字コードをステータスバーに表示しました。BOMなしのUTF-8はASCIIと後方互換で、「UTF-8が既定のエンコーディングになった」Webとの相性がよいというのが理由でした。この変更は、2019年5月の更新プログラムであるWindows 10バージョン1903で全員に届きました。それ以前は、メモ帳の新規ファイルの既定はANSIでした。

2007年以降：UTF-8がWebを席巻

Googleは、2007年12月にUnicodeが、同社がインデックスしたWebページで初めて最も多い文字コードになり、ASCIIと西ヨーロッパの文字コードを10日のうちに両方とも追い越したと報告しました。W3Techsは現在、文字コードを判別できるWebサイトの99.1%でUTF-8が使われていると報告しています（2026年11月）。ただしこれはWebサイトの統計です。古いディスクに眠るテキストファイルはこの変化の対象外で、誰もさかのぼって変換し直してはいません。

古いディスクの.txtファイルが2026年でも文字化けする理由

今のソフトウェアはUTF-8を前提にしていますが、多くのテキストはそれ以前に書かれました。DOSのREADME、初期のWindowsのメモ、もう動かないプログラムからのエクスポート、テキストとして保存されたメールやログなどです。これらは作ったPCのコードページで保存されており、それはPCの言語やWindowsのバージョンによって異なり、ラベルもありません。そこに別のシステムの改行や、ときどきBOMなしのUTF-16ファイルが加わると、同じ拡張子.txtの下に、互いに無関係な複数の形式が隠れていることになります。その多くは、元のプログラムに尋ねようがないレガシーファイルです。

Legacy File Converterは、対応ファイル形式ページのドキュメントのカテゴリーにプレーンテキスト（.txt）を掲載しており、お使いのWindows PC上でDOCX、PDF、Markdown、HTMLなどの新しい形式に変換します。何もアップロードされません。変換後は、アクセント付き文字、引用符、記号を元のファイルと見比べ、元のファイルは残しておいてください。中身が主にテキストである他の形式については、BOMがないとExcelがつまずく歴史レッスン：.csvファイルとは？と、歴史レッスン：.rtfファイルとは？をご覧ください。