テキストエディタ 文字化けを調べている人へ先に答えると、文字化けを一つの原因と決めつけず、元バイト列の読み方、保存時の変換、表示側の問題を分けて判定します。固定標本S-20はBOMなし・CRLFの20行で、UTF-8側はUnicode入力「10 変換対象😀」をそのまま持ち、Shift_JIS側は絵文字を格納せず「10 変換対象[U+1F600]」という人手のASCII標識を置きます。二つを同じ文字列や同じバイト列と扱わないことが診断の前提です。破損済み原稿の完全復元、OCR、PDFの文字化けは扱いません。この記事では「読込・保存・表示の三つを同じ現象として扱わない」を、原稿を使わない一般的な確認手順と、公開機能資料から言える範囲に分けて説明します。
文字化けは三層に分ける
画面を開いた瞬間に文字が崩れているなら、元の符号化と読み込み設定の組み合わせを疑います。保存した後だけ崩れるなら、保存時の変換や表現できない文字を見ます。文字は正しいのに一部の表示だけ違うなら、表示環境の問題として別に扱います。
固定標本S-20を二つの符号化標本へ分ける
固定標本をS-20と呼び、BOMなし・CRLFの次の20行をUnicode論理入力として使います。10行目以外は、Shift_JISで表現できる日本語とASCIIだけにします。
01 はじめに。
02 日本語の本文。
03 章番号 1-2。
04 長音と記号：テストー「引用」。
05 半角記号: ABC-123 / _=.
06 改行条件を固定する。
07 引用ID Q-001。
08 代表文を記録する。
09 保存前の内容を残す。
10 変換対象😀
11 変換不能位置を記録する。
12 元原稿を上書きしない。
13 別名保存先を記録する。
14 UTF-8側はUnicode入力とする。
15 Shift_JIS側は表現可能な文字だけにする。
16 文字列の順番を比べる。
17 空白の位置を比べる。
18 CRLFの位置を比べる。
19 表示結果をそのまま書く。
20 確認前に完了と決めない。S-20-utf8.txtはこのUnicode論理入力をそのまま保存します。S-20-sjis.txtは同じ行番号と共通部分を保ち、10行目の😀を人手でリテラルの[U+1F600]へ置きます。これは絵文字をShift_JISで表現したものではなく、変換不能対象を記録するための方針です。10行目の実バイト列は、UTF-8側が 31 30 20 E5 A4 89 E6 8F 9B E5 AF BE E8 B1 A1 F0 9F 98 80 0D 0A、Shift_JIS側が 31 30 20 95 CF 8A B7 91 CE 8F DB 5B 55 2B 31 46 36 30 30 5D 0D 0A です。いずれもBOMはありません。
最初は保存せず読み込みだけを見る
まずファイルを開き、代表文が期待文字列と一致しているか、問題文字がどこにあるか、改行がどう見えるかを記録します。S-20の読み込み前後の期待文字列は、UTF-8側が「10 変換対象😀」、Shift_JIS側が「10 変換対象[U+1F600]」です。対応する10行目の実バイト列も、UTF-8側の 31 30 20 E5 A4 89 E6 8F 9B E5 AF BE E8 B1 A1 F0 9F 98 80 0D 0A とShift_JIS側の 31 30 20 95 CF 8A B7 91 CE 8F DB 5B 55 2B 31 46 36 30 30 5D 0D 0A を記録します。ここで保存を実行すると、誤った読み込み結果を元ファイルへ書き戻す可能性があります。読み込みの問題と保存の問題を分離するため、最初の確認は読み取りだけにします。
次に変換不能文字を文脈で確認する
絵文字などが対象の文字コードで表現できない場合、表示された記号を正しい代替だと決めません。S-20では変換不能位置を10行目の行頭番号と空白を除く5文字目のU+1F600、UTF-8の行内1-based byte 16〜19として固定します。Shift_JIS側にはこの対象に対応するバイト列がなく、[U+1F600]は人手で置いたASCII標識です。章、段落、前後の語を控え、著者や編集方針で代替を決める欄を作ります。文字コードの判定機能は候補を見つける助けであり、文章の意味まで決めるものではありません。
原因ごとに戻り先を変える
読み込みで崩れたら符号化選択へ、保存後に崩れたら別名保存と変換不能文字へ、表示だけが違うなら表示条件へ戻ります。三つを「文字化け」とだけ記録すると、同じ原稿を何度も上書きすることになります。元ファイル、試験用複製、結果ファイルを別名にします。
診断結果を三行で残す
一行目は読み込み前の条件です。「UTF-8側の期待は『10 変換対象😀』」「Shift_JIS側の期待は『10 変換対象[U+1F600]』」のように、選んだ符号化と期待文字列を書きます。二行目は保存前後の差で、10行目のU+1F600がShift_JISに存在しないこと、保存時に?などへ黙って置換されていないかを確認します。三行目は表示環境の差で、同じ保存ファイルを別の表示条件で開いた結果を記録します。正しい表示の期待は、UTF-8側では絵文字、Shift_JIS側ではASCII標識がそのまま見えることです。これは判定欄の固定条件であり、Stage 3での実測成功を意味しません。
この三行があれば、文字化けしたファイルを見つけたときに、読込設定、保存処理、表示条件のどこへ戻るか決められます。問題文字を無断で削除するのではなく、位置と前後の文を残してから代替を判断します。UTF-8へ別名保存したS-20-sjis.txtの再読込期待文字列は「10 変換対象[U+1F600]」で、Unicode入力をそのまま保存したS-20-utf8.txtの再読込期待文字列は「10 変換対象😀」です。二つを取り違えないよう、ファイル名と実バイト列も併記します。
自動判定を最終結論にしない
文字コードの自動判定は、作業を始めるための手がかりです。日本語が一部だけ読める場合や、代表文字が少ない場合は、表示された名前だけで保存へ進みません。S-20は論理上の共通部分を持つ二標本であり、UTF-8側のUnicode入力と、Shift_JIS側で表現できないU+1F600をASCII標識へ置いた入力を分けています。読み込み、保存、再読込の三段階で、期待文字列、変換不能位置、実バイト列、表示結果の差を取ります。
Rune Studioを候補にする範囲
Rune Studioの公開機能資料では、主要な日本語文字コードを判定し、変換不能文字を赤く示し、未解決時の自動保存を停止する機能範囲が確認できます。この範囲は、S-20の期待文字列と変換不能位置を確認し、読込・保存・表示のどこで崩れたかを切り分ける候補として扱います。S-20を実際に読み込み、保存し、表示できたという成功結果はStage 3資料からは述べません。破損した原稿の意味を自動復元した結果や、一般的な「安全な保存」全体を示すものでもありません。
結論：S-20のUnicode入力、Shift_JIS側の非表現対象、前後の期待文字列を並べ、読込・保存・表示を分けて判定する
テキストエディタ 文字化けで持ち帰る判断は、文字化けを一つの原因と決めつけず、元バイト列の読み方、保存時の変換、表示側の問題を分けて判定します。まずは固定標本S-20のUnicode入力を基準にし、UTF-8側の「10 変換対象😀」と、Shift_JIS側の「10 変換対象[U+1F600]」を別標本として用意します。10行目のU+1F600、16進バイト列、変換前後の期待文字列、表示確認を並べ、結果が出ないときは変更した条件だけを一つ戻して元原稿を上書きしません。STUDIO-171はBOMの有無、STUDIO-177は文字コードの違い、STUDIO-180はShift_JISからUTF-8への変換を扱います。Rune Studioを試す場合も、公開資料で確認できる機能範囲と、手元の標本で得た結果を分けて記録します。
この記事が答えるのは「読込・保存・表示の三つを同じ現象として扱わない」までです。STUDIO-171はBOMの有無、STUDIO-177は文字コードの違い、STUDIO-180はShift_JISからUTF-8への変換を扱います。破損済み原稿の完全復元、OCR、PDFの文字化けは扱いません。次の一歩として、S-20をBOMなし・CRLFで用意し、Unicode入力、Shift_JIS側の非表現対象、実バイト列、変換前後の期待文字列、変換不能位置、表示確認を並べてから判定する。