テキストエディタ 文字コード UTF-8比較｜Shift_JIS・EUC-JPを二周で確認

複数の文字コードを読み分けて不一致を見つけるアイキャッチ

テキストエディタの文字コードを選ぶときは、名称を暗記するより、同じ10行標本をUTF-8、Shift_JIS、EUC-JPで保存し、「表現できる文字」「先頭情報」「受け渡し先」の三点を比べます。元ファイルを上書きせず、保存できない文字の警告を確認してから形式を決めます。

一つの標本に差が出る文字を入れる

標本は次の10行に固定します。ASCII、日本語、絵文字、機種依存文字、記号、改行の違いを同じ並びで含めます。作品本文ではなく複製ファイルで試し、候補の文字コードだけを変えます。

ASCII abc XYZ 123
日本語の本文を確認する
ひらがなとカタカナ
漢字の表記をそろえる
絵文字 😀 を一つ置く
機種依存文字 髙﨑①
記号 !? / _ -
数字 2026 と英字 EPUB
改行位置を確認する
END-01

encoding-source.txtを正本として読み取り専用に保ち、保存テストは-utf8、-sjis、-eucjpのように別名へ出します。見た目が同じでもバイト列と表現範囲は異なるため、ファイル名、選択形式、警告、再表示を一表にします。

UTF-8とUTF-8 BOMありを分ける

UTF-8は広い文字を扱いやすく、現代の交換形式として多く使われます。BOMありでは先頭にEF BB BFの3バイトがあります。本文が同じに見えても、受け渡し先がBOMの有無を指定する場合があります。

BOMは文字化け修復の万能印ではありません。指定がなければ既存プロジェクトの規則に合わせ、混在を増やさないようにします。先頭バイトの詳細な見分け方はBOMの記事で別に扱います。

Shift_JIS・EUC-JP・ISO-2022-JPは互換ではない

これらは日本語を扱える方式ですが、同じ文字を同じバイトで表すわけではなく、表現できる範囲も同一ではありません。古いシステムや取引先指定で必要になることがありますが、「日本語ならどれでも同じ」と考えないでください。

元の方式を推測で変えて上書きすると、復元に必要なバイトを失う場合があります。まずコピーを開き、判定された形式、表示結果、保存先要件を記録します。受領元に確認できるなら、推測より仕様を優先します。

UTF-16LE/BEとLatin-1の扱い

UTF-16にはリトルエンディアンとビッグエンディアンがあり、同じUnicode文字でもバイト順が異なります。Latin-1は限られた欧文向けで、日本語原稿の保存先として選ぶ方式ではありません。判定のフォールバックでLatin-1として開けても、内容が正しく解釈されたとは限りません。

文字が並んで見えるだけで合格にせず、標本の各行を正本と比較します。置換記号、消えた文字、意図しない制御文字がないかを見ます。

保存前の表現可否を読む

保存先の文字コードで表現できない文字がある場合、該当箇所を先に特定します。絵文字を削る、別表記へ直す、UTF-8へ変更する、受け渡し先と相談する、のどれを選ぶかは作品要件で決めます。警告を無視して保存することを手順にしません。

自動保存が動いたままだと、判断前に不適切な形式で書き戻す危険があります。表現できない文字がある間は自動保存を止める動作があるか確認し、手動保存の警告と対象箇所を読みます。

Rune Studioで確認できる文字コード範囲

現行Mac版Rune Studioの資料には、UTF-8、UTF-8 BOM、Shift_JIS、EUC-JP、ISO-2022-JP、UTF-16LE、UTF-16BEを判定・読込候補として扱い、Latin-1をフォールバックにすることが記載されています。先頭のBOMを先に確認します。

現在の保存形式で表現できない文字を赤く示し、保存時に警告し、その状態では自動保存を一時停止する機能も記載されています。これは公開資料で確認できる実装範囲の説明で、すべての文字が全方式へ変換できる、失われた文字を自動復元できるという主張ではありません。

編集画面下部に、開いている原稿のUTF-8とLFが表示された画面
編集画面下部に、開いている原稿のUTF-8とLFが表示された画面。

受け渡し表で最終判断する

列は「相手の指定」「元形式」「必要文字」「保存候補」「警告」「再表示結果」にします。指定がUTF-8なら、古い方式へ変換する理由はありません。既存Shift_JISの保守なら、追加文字が表現できるかを先に試します。

保存後は閉じて再度開き、標本10行と形式表示を確認します。保存ダイアログで選んだだけでは完了にしません。

変換結果は往復変換で保証しない

Shift_JISへ保存したコピーをUTF-8へ戻して見た目が同じでも、途中で表現不能文字が置換されていれば元情報は戻りません。往復後の表示だけを成功条件にせず、最初の正本と文字単位で比較します。警告対象、置換判断、保存版を対応させ、変換前コピーを完了まで保持してください。

一条件だけ変えて三形式を二周比較する

最初の一周は、固定した10行をUTF-8、Shift_JIS、EUC-JPの三つの複製へ同じ順番で保存します。各ファイルについて、選択した文字コード、読込時の表示、変換不能文字、改行、保存後の再表示、警告を一行ずつ記録します。絵文字の行と機種依存文字の行は、見えたかどうかだけでなく、置換や欠落がないかを正本と照合します。

二周目は、正本を直接編集せず、三形式の作業コピーへ同じ一件だけを反映します。変更は10行目の識別子をEND-01からEND-02へ変える一箇所に限定し、他の9行、改行、保存先、文字コードの比較条件は変えません。変更前後と実行日時を記録してから、三形式を再保存・再読込します。

初回と二周目は、次の記録単位で横に並べます。未確認は未確認のままとし、文字化けが少なそうという印象を採否理由にしません。

記録単位 一周目 二周目 差分 停止・採否理由
UTF-8の10行表示 三形式の初回結果 END-02反映後の結果 10行目以外の差がないか 他行も変化なら停止
Shift_JISの変換不能文字 初回の警告・置換 一件修正後の警告・置換 絵文字・髙﨑①の差 置換判断を保留・採否記録
EUC-JPの再読込と改行 初回の形式・改行 一件修正後の形式・改行 改行や表示の差 条件不一致なら停止

二周目を採用できるのは、変更が識別子一件だけで、三形式すべての初回・再実行・差分・停止理由を説明できる場合です。ファイルごとに別の行を直した、文字コードと改行を同時に変えた、初回結果を残していない、未確認を合格にした場合は比較を止めます。この二周手順は、全符号化方式を保証したり、文字化けを自動修復したりするものではありません。

結論：コピー保存と二周の再表示で決める

文字コードの違いは、同じ標本を別名保存し、警告、表現可否、再表示、受け渡し要件で比べます。元バイトを残し、表現できない文字を処理してから形式を確定してください。

現行Mac版の判定・保存・警告範囲は、Rune Studioの商品ページで確認できます。

投稿日：