日本語テキストエディタで文字コードを扱うとき、ファイル名や見た目だけでUTF-8、Shift_JIS、EUC-JP、UTF-16を決めないでください。同じ代表文を読み、BOM、改行コード、変換できない文字の四点を確認してから保存形式を選びます。
代表文は「普通の日本語＋差が出る文字」にする
四十行ほどの短い複製を作り、ひらがな、カタカナ、漢字、長音、全角数字、半角英字、句読点を入れます。提出先で使う固有名詞も一つ加えます。絵文字や機種依存文字を使う原稿なら、それも別の行に置きます。
比較用の代表文を決めずに開くと、文字化けしていても文章の内容を推測して読めた気になります。既知の一文と文字数があれば、復号結果を機械的に比べられます。
開いた直後は保存しない
Rune StudioはBOMを先に見て、システムの自動検出と主要な日本語文字コードを順に試します。UTF-8、UTF-8 BOM付き、Shift_JIS、EUC-JP、ISO-2022-JP、UTF-16LE、UTF-16BEなどを扱います。
ファイルを開いたら、ステータスバーの文字コードと改行コードを読み、代表文を確認します。文字化けしている状態で保存すると、元のバイト列を別の文字として上書きする危険があります。判定が疑わしいときは閉じ、複製で別の文字コードを指定して読み直します。
五形式で分かったBOMの影響
同じ日本語をUTF-8、Shift_JIS、EUC-JP、UTF-16LE、UTF-16BEで保存して読み比べたところ、UTF-8、Shift_JIS、EUC-JPは代表文と一致しました。UTF-16LEとUTF-16BEはBOMを含む状態の比較で一文字分の差が出ましたが、BOMを除いて本文を比べると代表文は一致しました。
BOMは文字コードを示す先頭の印です。本文の一字として数えるべきではありません。UTF-16だけ文字数が違ったとき、直ちに「本文が壊れた」とせず、BOMを含めた比較になっていないかを見ます。
文字コードと改行コードを別々に読む
文字コードがUTF-8でも、改行がLF、CRLF、CRのどれかで差が出ます。提出先が指定しているなら両方を記録します。今回の五形式の代表文では改行をLFに揃えて比較しました。文字化けの原因と改行の違いを同時に変えないためです。
ステータスバーから切り替えるときは、文字コードを一つ選び、保存後に閉じて開き直します。その後で必要なら改行コードを変えます。一度に二条件を変えると、行数や文字の差がどちらから生まれたか分かりません。
Shift_JISへ渡す前に探す文字
絵文字、丸付き数字、一部の異体字などはShift_JISで表現できない場合があります。Rune Studioの製品資料では、選択中の文字コードで変換できない範囲を赤い背景で示し、保存時に警告し、自動保存を一時停止します。
表示を見つけたら、UTF-8のまま渡せないかを最初に確認します。Shift_JISが必須なら、意味を保つ文字へ置き換えます。すべての拡張文字や壊れたバイト列を自動で復旧できるわけではありません。
比較表より安全な一ファイルずつの確認
五形式を同時に開いて見比べると、どのタブを保存したか分からなくなることがあります。元のUTF-8を閉じずに固定し、検査対象は一形式ずつ開きます。代表文、固有名詞、行数、BOM、改行を読み、結果をメモして閉じてから次へ進みます。
この方法なら、UTF-16のBOM差も、Shift_JISの変換不能文字も別々に扱えます。IMEの変換精度や日本語校正の正しさは文字コード機能の範囲外です。
最初の一手
提出先の指定がなければ、元原稿はUTF-8で残すのが無理のない出発点です。別形式が必要なときだけ複製を作り、既知の代表文とともに再読込してください。Rune Studioの対応文字コードと保存保護は商品ページで確認できます。
受け渡し相手へ二つの情報を添える
別の人へ原稿を渡すときは、「Shift_JISです」だけでなく、改行コードと変換時の置換有無も伝えます。たとえば「Shift_JIS／CRLF、絵文字一件を語句へ置換」のように書けば、相手が開いた後の差を追えます。
受け取った側でも、代表文と固有名詞を最初に確認してもらいます。文字コードは保存した側だけで完了するものではありません。読み手の環境で再読込できて初めて、受け渡し用ファイルとして役割を果たします。
ISO-2022-JPやLatin-1相当のフォールバックも、提出先が指定した場合に限って候補にします。対応一覧にあることと、その原稿へ適していることは別です。日本語の代表文字を保てない形式を、ファイルが開けたという理由だけで選ばないでください。
