文字コードの設定は、読み込み方と保存方法の両方に関係します。テキストエディタ 文字コードで安全に変更するには、Shift_JISの原本をUTF-8として無理に開くのではなく、正しく復号した作業用複製をUTF-8へ符号化し直します。読み込みと書き出しの方向を反対にしないことが要点です。
Shift_JIS原稿をUTF-8複製へ変換した
合成標本のShift_JIS版は288文字として復号されました。それを作業タブでUTF-8に設定し、同じ行列をUTF-8バイトで保存してから再検査しました。最終値はUTF-8・LF、復号後の内容は変換前と一致しました。これは「Shift_JISをUTF-8と誤認させた」結果ではなく、復号後の文字をUTF-8で新しく表現した結果です。
失敗のサインは、保存後に「漢字とカタカナ」のような混在行が崩れること、または文字数が予期せず変わることです。その場合は壊れた複製を更に保存せず、Shift_JIS原本から再び複製します。文字を1つずつ打ち直すと、見落としの場所と原因の両方が分からなくなります。
製品資料の赤背景と自動保存停止は、変換不能文字を見つけるためのUI機能です。今回のCLI試験はその画面を測っていないため、警告の色やタイミングは独自実測として扱いません。合格は、原本が残り、UTF-8複製の再読込みで重要行と末尾語が合うことです。
Shift_JIS原本を読み取り専用の比較基準にする
変換前ファイルは退避し、以後の編集対象から外します。正しい復号結果をUTF-8の新規複製へ書き、原本との文字列比較で差が0であることを確かめます。文字コード名の検出だけでは、機種依存文字や置換記号を見逃すため、固有名詞と記号を含む確認語も使います。差があれば、その文字だけの対応表を作って人が採否を決めます。
変換版が合格した後も、原本ハッシュと変換版ハッシュを一緒に引き渡します。後日問題が起きたとき、どのShift_JIS原稿から作ったか追跡できるためです。EPUB出力の成功は変換版の次工程であり、原本を上書きしてよい理由にはなりません。
変換不能文字を黙って置換しない
Shift_JISにない文字や機種依存文字が含まれると、変換時に疑問符や置換文字へ変わることがあります。変換ログで置換件数を取り、0でない場合は元文字、前後文、Unicode値、採用候補を保留表へ移します。自動的に近い字へ変えると固有名詞の意味を損なうため、人が決定します。
採用後はその文字を含む確認語を追加し、UTF-8版を再読込みします。原本との文字列比較では、承認済みの置換だけを許容差として登録します。これにより、「ハッシュが違うから失敗」でも「読めるから成功」でもない、説明可能な変換になります。
後工程へは保留0の版だけを渡し、元のShift_JISファイルは監査用に保存します。出力EPUBから同じ確認語を検索すれば、変換後にさらに欠落していないことも追跡できます。
𠮷・🙂・☕が示した三つの停止理由
追加の合成標本はUTF-8で保存し、Shift_JISへ厳密に符号化できるかを文字単位で調べました。結果は𠮷、🙂、☕の3文字が変換不能です。Runeのtab set-encoding ... Shift_JIS --dry-run自体は終了コード0でしたが、その応答だけでは三文字の位置や、画面の警告状態を取得できません。そこで保存可否は厳密な事前検査の3件を根拠に止めました。
製品資料には、選択中の方式で表せないUnicode文字を編集領域で赤く示し、保存時に警告し、解消まで自動保存を止める動作が説明されています。しかし今回のCLI実測は画面を描画せず、赤背景、警告ダイアログ、自動保存停止を目視していません。資料上の機能と観測した数値を混ぜず、「画面は未実測」と明記するのが安全です。
置換して通す経路を採用しなかった
疑問符へ置き換えればShift_JISファイルを作ることはできますが、固有名や記号が別内容になります。この試験では損失保存を実行せず、元のUTF-8を保持して別名のUTF-8納品ファイルを作りました。これはエラーを消したのではなく、三文字を表現できる納品方式へ判断を戻したということです。
UTF-8複製を二段階で読み直す
保存後の複製をRuneで検査すると方式はUTF-8でした。さらに厳密なUTF-8符号化エラーは0件、復号した全文は元標本と一致し、SHA256は1f5ee3a48eda919483f04c5f659916f5a249c5a52a7d0c10007447433e2d49afです。メニュー表示ではなく、再読込み、エラー数、全文一致を同じ合否票へ並べました。
入稿先へ残す短い判断記録
引き渡し票には、試したShift_JIS、変換不能3件、損失保存なし、採用UTF-8、再検査0件を書きます。入稿先がShift_JIS必須なら、この本番文字列を勝手に直さず、表記変更の編集判断を依頼します。UTF-8が受け付けられるなら、元原稿と納品複製の両方を保持したまま進めます。完了とは「赤く見えない」ことではなく、納品ファイルが0件で再読込みでき、元文と一致することです。
入稿後の照会に備え、三文字のコードポイントと出現位置も証拠JSONへ残しました。置換案を検討する場合は、著者または編集者が文字ごとに承認し、その承認後の新しい本文を別の版として再検査します。技術担当が都合のよい似た字へ自動変換しないことで、形式要件と内容責任の境界を守れます。