この記事の要点

TXT は装飾も構造も持たないプレーンテキストファイル。最も基本的かつ移植性の高い形式 中身は単なるバイト列であり、解釈には文字エンコーディングと改行コードの情報が不可欠 主な文字コード: ASCII (7bit) / UTF-8 (世界標準) / Shift_JIS (旧 Windows 日本語) / EUC-JP / UTF-16 改行コード: LF (Unix/Mac) / CRLF (Windows/HTTP/SMTP) / CR (古い Mac OS Classic) BOM (Byte Order Mark): UTF-8 BOM EF BB BF / UTF-16 LE BOM FF FE / UTF-16 BE BOM FE FF エンコーディング判別は file -i / nkf -g / chardet / uchardet。100% 正確な自動判別は原理的に不可能 Windows メモ帳は 2018 年以降 LF を扱えるようになったが、それ以前は CRLF 強制で改行が消える落とし穴あり

概要

TXT (.txt) は、装飾情報・構造情報を持たない素のテキストデータを保存するためのファイル形式である。中身は文字エンコーディングに従って符号化されたバイト列でしかなく、見出しや太字・色・フォントといった視覚的属性は一切含まない。最も基本的なフォーマットでありながら、文字エンコーディング・改行コード・BOM の組み合わせによってトラブルが発生しやすい形式でもある。

世界中のあらゆる OS・プログラミング言語・エディタ・端末が TXT を読み書きできるため、移植性は最高クラスである。設定ファイル・ログ・README・ライセンス文書・スクレイピング結果の中間保存など、用途は無数にある。MIME タイプは text/plain。

内部構造 (文字コードと改行)

TXT ファイルの中身は単なるバイト列であり、それを「どの文字エンコーディングで解釈するか」「どの改行コードで行を区切るか」がファイル外の文脈で決まる。主要なエンコーディングを示す。

エンコーディング	バイト数	BOM	備考
ASCII	1 byte (7bit)	なし	英数字のみ、UTF-8 のサブセット
UTF-8	1〜4 byte (可変長)	EF BB BF (任意)	世界標準、Web の事実上唯一の文字コード
UTF-16 LE	2 byte (BMP 内)	FF FE	Windows API の内部表現
UTF-16 BE	2 byte (BMP 内)	FE FF	Java の char、SJIS-Mac の旧仕様
Shift_JIS / CP932	1〜2 byte	なし	Windows 日本語 (Windows-31J=CP932 が実態)
EUC-JP	1〜3 byte	なし	旧 Unix / 旧 Web 日本語
ISO-2022-JP (JIS)	1〜2 byte + エスケープ	なし	メール本文の従来規格

改行コードは次の 3 種類。

• LF (\n / 0x0A): Unix / Linux / macOS (10.0 以降) / インターネット標準 (XML, JSON, YAML, Markdown)
• CRLF (\r\n / 0x0D 0x0A): Windows / DOS / HTTP / SMTP / RFC 文書のテキスト部
• CR (\r / 0x0D): 古い Mac OS Classic (9.x まで)。現代ではほぼ絶滅

BOM は「このファイルは Unicode で書かれていますよ、バイトオーダーはこちらですよ」を示す先頭マーカー。UTF-8 では本来不要だが、Windows 系ツール (特に Excel) が UTF-8 を自動判別する目印として利用するため、互換性のために付けることがある。逆に Java の InputStreamReader や bash スクリプトのシバン解釈では BOM が 1 文字目として読まれて事故になる。

主な用途

• ログファイル: アプリケーション・Web サーバ・systemd journal の保存先 (.log も中身は txt)。
• 設定ファイル: .ini / .conf / .env / .gitignore 等、拡張子は違うが本質は TXT。
• ライセンス・README: LICENSE.txt / README.txt / CHANGELOG.txt。
• データ受け渡し: 固定長フォーマット・LTSV・JSON Lines・CSV/TSV はすべて TXT の派生。
• スクレイピング / クロール結果の中間保存: HTML を抜き取った後の生テキスト。
• メモ・原稿: メモ帳・vim・Emacs・Sublime Text・VSCode などで日常的に編集される。

関連形式との比較

形式	装飾	構造	サイズ効率	備考
TXT	なし	なし	低 (圧縮なし)	最も移植性が高い
RTF	あり (太字/色)	軽量	低	古典的なリッチテキスト
Markdown	記法ベース	軽量	低	平文だが見出し等の意味あり
HTML	あり	あり	低	Web 標準
docx	あり	あり	中 (zip 圧縮)	Word のリッチ文書

編集・パーサ・ツール

# エンコーディング判別
file -i mystery.txt           # MIME タイプ + charset 推定
nkf -g mystery.txt            # Japanese encoding guess
uchardet mystery.txt          # Mozilla 由来の判別器
python -c "import chardet,sys; print(chardet.detect(open(sys.argv[1],'rb').read()))" mystery.txt

# 文字コード変換
iconv -f CP932 -t UTF-8 sjis.txt > utf8.txt
nkf -w --overwrite sjis.txt
nkf -s --overwrite utf8.txt   # UTF-8 → Shift_JIS

# 改行コード変換
dos2unix file.txt             # CRLF → LF
unix2dos file.txt             # LF → CRLF
sed -i 's/\r$//' file.txt     # CRLF → LF (sed 版)

# BOM の除去
sed -i '1s/^\xEF\xBB\xBF//' file.txt

# 16 進ダンプで先頭バイトを確認
xxd file.txt | head -1
od -c file.txt | head -1

# 行末空白の除去
sed -i 's/[[:space:]]*$//' file.txt

注意点・落とし穴

• Windows メモ帳の罠: 2018 年 (Windows 10 1809) 以前のメモ帳は LF を改行と認識せず、すべての行が 1 行に表示された。今でも古い環境ではこの挙動が残る。VSCode や Notepad++ を使う。
• BOM の二重事故: PowerShell の Out-File はデフォルトで UTF-16 LE BOM 付き、-Encoding utf8 でも UTF-8 BOM 付きになる (PS 5.1 まで)。bash や Python で読むと先頭の  が混入する。-Encoding utf8NoBOM (PS 6+) か [System.IO.File]::WriteAllText を使う。
• 文字化け (mojibake): Shift_JIS を UTF-8 として読むと「縺ゅÝ縺後…」のような典型的化け。逆も同様。原因は判別ミス。常にファイルヘッダで charset を確定させる。
• 自動判別の限界: 短いファイルや英数字のみのファイルは UTF-8 / Shift_JIS / Latin-1 が区別できない。判別ライブラリでも確率値が返るのみ。
• サロゲートペア: 絵文字や JIS X 0213 第三・第四水準は UTF-16 でサロゲートペア (2 個の 16bit) になり、文字数カウントが UTF-8 / UTF-16 / UTF-32 で揃わない。
• 改行末尾の有無: POSIX は「テキストファイルは改行で終わる」と規定するが、Windows メモ帳は末尾改行なしで保存することもある。git diff や diff が「No newline at end of file」を吐く原因。
• Mac の濁点問題 (NFD): macOS の HFS+ は濁点・半濁点を NFD (合成可能形) で保存するため、「が」が「か + ゛」の 2 文字として扱われる。Linux サーバ転送時に検索 / マッチング失敗の原因になる。

関連リンク

• テキスト・ドキュメント形式 (親カテゴリ)
• ファイル拡張子とは (概論)
• PDF (.pdf) / CSV (.csv) / Markdown (.md)
• Unicode Consortium
• RFC 3629 — UTF-8