PRELAPS 文字化け直し

メモ帳で UTF-8 で保存したのに文字化けするとき

保存するときに確かに UTF-8 を選んだのに、そのファイルを Excel や他のソフトで開くと 文字 や ｶﾃｶﾅ のようになる場合です。選んだのになぜ駄目なのか、というのがこの記事の主題です。

メモ帳の保存の選択肢が紛らわしい

「名前を付けて保存」の下に文字コードのドロップダウンがあります。Windows のバージョンによって項目が少し違いますが、おおむねこうです。

ここで「Unicode」を選んで UTF-8 を選んだと覚えているのが、いちばんよくある勘違いです。UTF-16 で保存されたファイルは、UTF-8 を期待するソフトで開くと全体がおかしくなるか、そもそも開けません。

ANSI は規格ではない

ANSI はアメリカの標準化団体の名前なので規格のように聞こえますが、Windows でこの語は「このコンピュータの地域コードページ」という意味です。日本語 Windows では Shift_JIS(CP932)、韓国語 Windows では CP949、西欧では Windows-1252 です。

つまりANSI で保存したファイルはコンピュータごとに意味が変わります。日本で作った ANSI ファイルを韓国の Windows で開けば化けますし、逆も同じです。同じ会社の中でも Windows の言語が違えばこれが起きます。

古い文書が今になって化ける理由はたいていこれです。当時は全員が同じコードページを使っていたので問題が表に出なかっただけです。

既定値が途中で変わった

Windows 10 の2019年の更新(バージョン1903)から、メモ帳の既定の文字コードが ANSI から UTF-8 に変わりました。つまり、それ以前に作ったファイルと以後に作ったファイルが同じフォルダに混ざっている可能性があります。

そのため、同じフォルダのメモのうち、あるものは正常に開き、あるものは化けるという状況が生まれます。ファイルごとに文字コードが違うのであって、ファイル名やアイコンでは区別がつきません。

BOM は付けるべき場面と外すべき場面がある

BOM はファイルの先頭に付く三バイトの印です。「このファイルは UTF-8 だ」と知らせる役割で、画面には見えません。やっかいなのは、これを求める側と受け付けない側に分かれることです。

つまり「UTF-8 なら大丈夫」ではありません。誰に渡すファイルかによって BOM を付けるかどうかが分かれます。メモ帳に二つの項目が別々にある版なら、渡す先に合わせて選んでください。

ファイルは UTF-8 なのに読む側が失敗する場合

保存は正しくできていて、開くソフトの推測が外れることもあります。テキストファイルには文字コードを書く場所がないので、BOM がなければソフトが中身を見て推測するしかありません。

短いファイルほど推測が外れます。数文字しか入っていないメモは判断する手がかりが足りません。同じ内容でも長いファイルでは正常に開き、短いファイルでだけ化けるならこれです。

今どの文字コードなのか確かめる

メモ帳でファイルを開くと、ウィンドウ下部のステータスバーの右に現在の文字コードが表示されます。見えない場合は「表示 → ステータスバー」を有効にしてください。ここが UTF-8 ではなく ANSI になっていれば原因が見つかったことになります。

ただしこの表示も推測に頼っています。化けて見えるファイルをメモ帳で開いた時点ですでに化けているなら、表示された文字コードも疑ってください。

このツールでの直し方

文字化け直しのファイルタブにそのまま入れてください。どの文字コードで保存されているかを判定して候補を並べるので、正しく読めるものを選んで UTF-8 で取り直せば済みます。

取得するときは「Excel で開くファイルなら BOM を付ける」のチェックを渡す先に合わせてください。.csv・.tsv・.txt は既定で有効です。シェルスクリプトや設定ファイルなら外します。

ファイルはサーバーに上がりません。ブラウザの中だけで処理されるので、社内の資料もそのまま使えます。

次から化けさせないために