テキストが文字化けするとき: Shift_JIS と青空文庫の記法

.txt を開いたら、日本語のかわりに意味のない記号が並んでいます。ファイルは壊れていません。バイトはすべてそこにあり、間違った対応表で読まれているだけです。

日本語では見た目の似た症状に二つの別々の原因があります。先にどちらかを見分けるのが早道です。

まず見分ける

画面に出ているものをよく見てください。

日本語は正しく読めるが、《 や ｜ や ［＃ といった記号が混ざっている場合。 これは文字コードの問題ではありません。青空文庫の記法がそのまま表示されています。

日本語がまったく読めず、見慣れない記号の列になっている場合。 これが文字コードの問題です。

青空文庫のテキストは、ルビと注記を本文中に記号で書き込む方式を採っています。

この記法を解釈するアプリでは、ルビが小さく振られ、注記は表示されません。解釈しないアプリでは記号がそのまま出ます。

ファイルは正常で、変換の必要もありません。記号が気になる場合は、同じ作品の HTML 版を使うか、ウィキソースの EPUB を探すのが手早い解決です。

日本語の古いファイルは Shift_JIS であることが多く、まれに EUC-JP や ISO-2022-JP も出てきます。

文字コード	よくある出どころ
UTF-8	現在の標準
Shift_JIS	Windows で保存された古い日本語ファイル、青空文庫の旧版
EUC-JP	Unix 系、初期のウェブ
ISO-2022-JP	古い電子メール
UTF-16	一部の Windows ソフトの書き出し

はっきり書いておくほうがよいでしょう。Aurora Reader は最初に UTF-8 を試し、失敗すると Latin-1 に退避します。Shift_JIS も EUC-JP も判定せず、設定に文字コードを選ぶ項目もありません。

Latin-1 は、エラー表示ではなく文字化けが出る理由も説明します。あの文字コードではどのバイトにも何かしらの記号が対応するため、退避経路は必ず「成功」します。ただし誤った文字を返すだけです。

この挙動は不具合として記録してあります。

パソコン上で複製を変換し、それを端末に戻します。

iconv -f SHIFT_JIS -t UTF-8 book.txt > book-utf8.txt

変わらなければ -f EUC-JP、次に -f ISO-2022-JP を試してください。この三つでほぼ片が付きます。

Windows ならメモ帳で開き、文字コードを UTF-8 にして保存し直す方法もあります。大きなファイルでは時間がかかります。

必ず複製で作業してください。指定を誤った変換は元に戻せません。

逆のこともあります。中身の文字は正常なのに、展開したファイル名が化けている。

これは別の話です。ZIP 形式は長らくファイル名の文字コードを規定しておらず、Windows の圧縮ソフトは Shift_JIS で書き込みます。一方 Android の展開ツールはたいてい UTF-8 として読みます。中身には影響しません。

数が少なければ名前を直すのが早く、多ければパソコンで文字コードを指定できる展開ソフトを使い、それから転送してください。

文字は正しいのに目次が空、ということもあります。

これは文字コードとは無関係です。アプリが章を探すときに照合するのは Chapter 1 や Part 2 といった英語の書き方で、「第一章」は当てはまりません。同じ箇所のコードが単語数を空白で数えるため、ページ数の推定も外れます。どちらも章の検出と単語数の計算として記録済みです。

壊れたファイルはたいてい開かないか、途中で切れます。最初から最後まで一定して誤った文字が出るなら、バイトは無事です。区別はファイルが壊れているかの判断にあります。

拡張子を変えても意味はありません。拡張子は中身のバイトと何の関係もありません。

その場合は文字コードではなくフォントの問題です。

Noto Sans CJK や源ノ角ゴシックは JP、TC、SC、KR に分かれており、同じコードポイントでも字形が地域ごとに違います。中国語版で日本語を読むと「骨」「直」「戸」などが中国の字形で表示されます。解決は日本語版のフォントを入れることです。

同じ作品が EPUB であればそちらを選んでください。EPUB は文字コードをファイル内で宣言するため、この問題自体が起きません。ウィキソースの EPUB 書き出しが便利なのはこのためです。