テキストエディタ 文字コード 変換を調べている人へ先に答えると、Shift_JISの原稿を直接上書きせず、読込符号化・変換不能文字・改行・別名保存・再読込の五点を確認してUTF-8版へ渡します。固定標本S-20はBOMなし・CRLFの20行で、UTF-8側はUnicode入力「10 変換対象😀」をそのまま持ち、Shift_JIS側は絵文字を格納せず「10 変換対象[U+1F600]」という人手のASCII標識を置きます。二つを同じ文字列や同じバイト列と扱わないことが、変換前の条件です。壊れた元データの完全復元、バイナリ形式、未知の文字の意味を自動で決める処理は扱いません。この記事では「変換結果ではなく、戻れる変換票を残す」を、原稿を使わない一般的な確認手順と、公開機能資料から言える範囲に分けて説明します。
変換前に原本とUnicode入力を固定する
文字コード変換は、画面で日本語が読めたから成功とは限りません。Shift_JISの元原稿を残し、試験用の複製を別名で作ります。元の文字コード、改行、代表的な三行、文字数を記録してからUTF-8版を作ると、戻れない上書きを避けられます。
固定標本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では、変換不能位置を10行目の行頭番号と空白を除く5文字目のU+1F600、UTF-8の行内1-based byte 16〜19として記録します。Shift_JIS側にはこの対象に対応するバイト列がありません。本文が読めることは五点の一つにすぎず、改行が意図せず変わった場合も、本文の見た目だけで合格にしません。
変換は一度に一条件だけ進める
まず複製を正しい符号化で開き、問題文字を確認します。Unicode論理入力をShift_JISへ保存する操作では、10行目のU+1F600で停止または変換不能として記録し、勝手に?を書きません。Shift_JISからUTF-8へ渡す操作は、S-20-sjis.txtを読み込んで別名保存し、保存後の期待文字列を「10 変換対象[U+1F600]」と固定します。変換後の10行目のUTF-8バイト列は 31 30 20 E5 A4 89 E6 8F 9B E5 AF BE E8 B1 A1 5B 55 2B 31 46 36 30 30 5D 0D 0A です。最後に保存したファイルを閉じて開き直し、代表文、文字数、改行、表示文字列を比べます。符号化変換による差と本文修正による差を一緒に数えないことが重要です。
文字化けしたときの戻り先
開いた時点で文字が崩れているなら、保存せず読込符号化へ戻ります。特定の文字だけが変わるなら、変換不能文字の位置と原文へ戻ります。保存後に改行が変わったなら、保存設定へ戻ります。元原稿を再保存して直そうとすると、最初の状態を失うので避けます。
変換票の記入例を作る
変換票には次の期待値をそのまま書きます。変換前の期待文字列はS-20-sjis.txtの「10 変換対象[U+1F600]」、変換後の期待文字列は別名のUTF-8版でも同じ標識を含む文字列です。変換不能位置は10行目の内容5文字目、U+1F600で、Shift_JISの実バイトはありません。表示確認は、Shift_JISを正しく読むと標識がそのまま見え、UTF-8へ別名保存して再読込しても標識が?や別の文字列に変わらないことです。別途、Unicode入力のUTF-8版では「10 変換対象😀」が期待文字列であり、これをShift_JIS側の入力結果とは混ぜません。ハッシュ値が変わること自体は、文字コードを変えたなら自然です。重要なのは、意図して変えた項目と、意図せず変わった項目を分け、代表文と文字数が説明できることです。
UTF-8版を保存したら、元のShift_JIS原稿を閉じたまま、別名のUTF-8版を開き直します。再読込では、S-20-sjis.txtからの変換なら「10 変換対象[U+1F600]」、Unicode入力をそのまま保存したUTF-8版なら「10 変換対象😀」と照合します。再読込で文字が変わったときは、UTF-8版をさらに上書きせず、変換前の複製から原因をたどります。
変換後の確認で見るべき代表文
代表文は、通常の日本語だけでなく、数字・長音・記号・問題になった位置を含む三箇所を選びます。S-20の10行目は、Shift_JIS版の期待文字列とUTF-8版の期待文字列を取り違えない確認点です。変換前後で読めるかだけではなく、文字の順番、空白、改行の位置、実バイト列、表示された文字列も見ます。UTF-8版で内容が一致していても、元原稿が上書きされていれば戻り先がありません。別名と変換票を一緒に残して、次の工程へ渡します。
Rune Studioを候補にする範囲
Rune Studioの公開機能資料では、UTF-8やShift_JISなどの文字コードを扱い、変換できない文字を示し、未解決のまま自動保存を進めない範囲が示されています。変換前の安全確認の候補にはできますが、今回の20行を変換完了した実測結果や、失われた文字の自動復元を意味しません。
結論：S-20のUnicode入力、Shift_JIS側の非表現対象、前後の期待文字列を記録してから別名変換する
テキストエディタ 文字コード 変換で持ち帰る判断は、Shift_JISの原稿を直接上書きせず、固定標本S-20のUnicode入力、Shift_JIS側で表現できないU+1F600の位置、実バイト列、変換前後の期待文字列、表示確認を先に記録してからUTF-8版へ別名保存することです。S-20の「同じ20行」は行番号と共通部分を指し、UTF-8側の「10 変換対象😀」とShift_JIS側の「10 変換対象[U+1F600]」を同じ文字列とは扱いません。結果が出ないときは、変更した条件だけを一つ戻し、元原稿を上書きしないでください。STUDIO-171はUTF-8とBOMの見分け方、STUDIO-177は複数文字コードの違い、STUDIO-183は文字化けの原因切り分けを扱います。Rune Studioを試す場合も、公開資料で確認できる機能範囲と、手元の標本で得た結果を分けて記録します。
この記事が答えるのは「変換結果ではなく、戻れる変換票を残す」までです。STUDIO-171はUTF-8とBOMの見分け方、STUDIO-177は複数文字コードの違い、STUDIO-183は文字化けの原因切り分けを扱います。壊れた元データの完全復元、バイナリ形式、未知の文字の意味を自動で決める処理は扱いません。次の一歩として、S-20を複製し、Unicode入力、Shift_JIS側の非表現対象、16進バイト列、変換前後の期待文字列、変換不能位置、表示確認を変換前に記録する。