UTF-8化は、文章を言い換える作業ではなく、表現できない文字を保存前に見つけ、必要な文字を失わずUTF-8へ残す作業です。画面で日本語が読めただけでは、別の文字コードへ保存したときに同じ文字が残る証拠にはなりません。原本を残し、変換不能文字を数え、UTF-8を指定して保存し、閉じた後のファイルを再検査するところまでを一単位にします。
STUDIO-173では「𠮷」「🙂」「☕」を含むUTF-8の合成原稿を使いました。utf-8 テキストエディタ を受け渡しに使うとき、Shift_JISへ変えると失われる3文字を実際に検出し、UTF-8保存で0件にするまでを確認します。
目標は「UTF-8で再検出でき、三地点が読める」
最初に制作側の受け入れ値を決めます。今回の目標は、保存先ファイルがUTF-8、改行がLFとして再検出され、冒頭見出し、中ほどの3文字、末尾の検証印が読めることです。変換不能文字0件と、元の文字列との完全一致を別々に記録します。字数だけが同じでも似た字へ置換されていれば不合格です。
原本は上書きしません。受領ファイル、作業用複製、受け渡し用UTF-8ファイルを別名にし、どれをRune Studioへ開いたかを記録します。すでに � や ? へ置き換わった原稿は、UTF-8で保存し直しても失われた文字が戻りません。その場合は変換を続けず、正しく復号できる原本へ戻ります。
チェック地点には、ひらがなだけの平易な箇所ではなく、著者名、難しい地名、長音、三点リーダ、全角記号などを混ぜます。符号化の誤りがあっても英数字だけは読めることがあるため、半角だけの識別子を唯一の判定材料にはしません。末尾印は保存途中の切断を見つける役割も持ちます。
Shift_JISへ保存できない三文字を実際に数える
合成原稿を1文字ずつShift_JISへ厳密変換する下見では、「𠮷」U+20BB7、「🙂」U+1F642、「☕」U+2615の3件が変換不能になりました。これは文字化けの予想ではなく、保存前の実検出です。似た漢字、絵文字の削除、クエスチョンマークへの置換で件数を消してはいけません。
Rune Studioのset-encodingをShift_JISで下見したところ、開発用CLIは設定値を返しましたが、この3件をエラーとして返しませんでした。そのため、設定応答を合格には使わず、厳密な文字検査の3件を停止条件にしました。UIの赤表示を今回見たという主張にも置き換えません。
Rune StudioのタブでUTF-8を指定し、保存先を固定する
専用ワークスペースでUTF-8原稿の複製をrune tab openし、Shift_JISの保存経路を不採用にした後、rune tab set-encoding --encoding UTF-8を実行しました。タブの応答はUTF-8でした。保存先はSTUDIO-173の合成作業ファイルであり、受領原本ではありません。
Rune StudioのMac版資料では、選んだ文字コードで表せない文字を赤く示し、その状態では自動保存を止める機能が説明されています。ただし今回のCLI実測では、警告色と自動保存停止の画面挙動を測定していません。資料上の機能と、今回確認した保存ファイルの値を混同しないでください。UIで赤い文字が出た場合は、その文字を勝手に似た字へ置換せず、UTF-8を選び直すか、納品側と表現を相談します。
受け渡しログは閉じたファイルから作る
タブの設定応答だけで完了にせず、閉じた保存ファイルへrune inspect textを実行しました。再検出値はUTF-8、LFです。厳密なUTF-8検査では不正バイト0件、UTF-8で表せない文字0件となり、3文字を含むdecoded textも修正前の合成原稿と完全一致しました。
ログには入力パス、保存先、Shift_JISで変換不能だった3文字、保存後のUTF-8検査0件、照合語、日時を残します。相手は同じ画面操作を再現しなくても、ファイルを検査してUTF-8と文字の維持を確認できます。ハッシュを添えると、検査したファイルと渡したファイルが同一かも追跡できます。
失敗した地点だけを戻し、未測定範囲を広げない
開いた直後から文字が崩れているなら、復号指定または原本選択へ戻ります。タブでは正しいのに保存後の検出値がUTF-8でなければ、保存先とencoding設定を見直します。保存ファイルは正しいのにEPUBのXHTMLで崩れるなら、章選択やEPUB変換の工程を調べ、原稿を再変換しません。
今回の合格条件は、Shift_JISでは変換不能3件を検出して保存を止めること、UTF-8保存後は不正バイト0件・変換不能0件・decoded text一致となることです。未知の旧式符号化の自動復元、すでに失われた文字の回復、全電子書籍端末での表示一致までは確認していません。
複数章をまとめて扱う場合も、一つの合格値を全章へ流用しません。新しい固有文字を含む章、外部から差し替えられた章、クレジットページをそれぞれ検査し、受け渡す版の一覧へ紐付けます。合格済みの章は変換対象から外し、問題のあるファイルだけを再処理します。
最終的に渡すのは「UTF-8を選んだ」という説明ではなく、保存後にもUTF-8と再検出されたファイルです。表示、設定、保存、再読込を分け、異常が出た一地点だけを戻すことで、正常な文章を余計な変換から守れます。