Shift_JISで表現できない文字を保存前に見つけるには、「機種依存文字」という大きな分類ではなく、実際の文字と位置を一件ずつ検査します。今回の1,000字標本では、インデックス23の😀と24の🚀の2件が変換不能でした。承認した代替後は0件となり、UTF-8版とShift_JIS版の再読込本文も一致しました。失敗時は保存先ではなく、1,000字の原本複製と代替承認表へ戻ります。
記事固有のstatusはpartialです。数値検査では2件から0件、再読込一致まで確認できましたが、想定にあった「機種依存文字三件」の文字・コードポイント・可否は結果へ残っていません。Rune Studio画面の赤表示、保存前警告、自動保存の停止・再開もCLIでは確認していません。
「機種依存文字」ではなく文字単位で判定する
Shift_JISで表現できるかどうかは、文字ごとに確認します。見た目が特殊、環境依存と呼ばれる、といった分類だけで一律に変換不能とは決められません。
検査票には、対象文字、コードポイント、原稿内の位置、Shift_JIS可否、採用する代替を分けて記録します。今回、証拠に残った対象は😀と🚀です。想定していた三つの候補が検出されなかった理由は、この結果だけでは確定できません。
1,000字標本の開始値と結果
標本の要求文字数と実測文字数はともに1,000でした。変換先をShift_JISとし、検出前後を次の値で比較しました。
| 項目 | 実測値 |
|---|---|
| 要求文字数 | 1,000 |
| 実測文字数 | 1,000 |
| 変換不能文字 | 2件 |
| 位置 | 😀＝23、🚀＝24 |
| 承認代替後 | 0件 |
| UTF-8別名版 | UTF-8として再読込 |
| Shift_JIS別名版 | Shift_JISとして再読込 |
| 改行 | LF |
| 修正本文 | 二つの別名版で一致 |
この表が示すのは、記録された2文字の処理結果です。「候補五件をすべて検査した」「機種依存文字三件はShift_JISで安全だった」とは言えません。記録がない候補は未確認のまま残します。
製品を使わない一般手順
保存前検査は、次のように原本と判断を分けます。
- 原本を複製し、文字数、文字コード、改行を固定します。
- Shift_JISへ変換できない文字を位置付きで一覧にします。
- 一覧の文字を原文と照合し、意味を保てる代替だけを承認します。
- 複製側で代替し、同じ検査を繰り返して0件を確認します。
- UTF-8版とShift_JIS版を別名保存し、閉じて開き直して本文全体を比較します。
警告が消えただけでは完了にしません。検出位置、代替の承認、0件、再読込一致の四つがそろって初めて、記録された対象について次工程へ進めます。
発見記事の出口はShift_JIS保存可否
この記事の中心は「どの文字がShift_JISで表せないか」を保存前に確定することです。EPUB変換時の文字抜けを防ぐ記事では、出力工程の出口として0件と生成物を確認します。こちらは、Shift_JISという保存先を採用できるか、別の文字コードへ切り替えるべきかを判断します。
代替によって原文の意味が変わる場合は、0件へすることを優先しません。Shift_JIS保存を中止してUTF-8を採用する判断も正解です。件数を0にすることは、内容を損なってよいという意味ではありません。
Rune StudioのStage 3機能
現行Mac版Rune Studioの公開資料では、主要な日本語文字コードに対応し、選択中の文字コードで表現できないUnicode文字を赤い背景で示し、変換不能文字が残る間は自動保存を一時停止し、手動保存時に警告することが確認できます。これはStage 3の製品範囲です。
タイトル固有Stage 4で確認したのは、1,000字標本に対する2件の位置、承認代替後0件、二つの別名版の文字コード、LF、本文一致です。画面の赤表示、警告の文言、誤復号状態、自動保存の停止・再開は未確認なので、数値検査から見え方を推定しません。
別の共通Stage 4では、短文をUTF-8、Shift_JIS、EUC-JPで39字、UTF-16LE、UTF-16BEで40字、すべてLFとして識別し、作業タブ設定をUTF-8と再取得しました。これは文字コード識別の補助結果で、1,000字標本の2件を検出した証拠とは分けます。
partialのまま残す境界
- 想定した機種依存文字三件の文字、コードポイント、Shift_JIS可否
- Rune Studio画面での保存前警告と赤表示
- 自動保存が停止し、修正後に再開する一連の画面操作
- 誤復号状態の見え方と、その状態からの上書き
- 外部アプリや提出先での受理
破損済みデータの完全復元、OCR、バイナリ修復も扱いません。これらを未確認のまま、partialを成功へ読み替えません。
失敗時の戻し先
- 位置と原文が一致しない：文字コードを変えず、検出一覧の作成へ戻る
- 代替が未承認：置換前の複製と代替承認表へ戻る
- 修正後に1件以上残る：残件一覧へ戻り、保存を中止する
- 再読込本文が違う：二つの出力を破棄し、0件確認直後の複製へ戻る
- 意味を保つ代替がない：Shift_JIS保存を中止し、UTF-8など別の方針を検討する
結論：2件の結果と未確認候補を混ぜない
今回の1,000字標本では、😀が位置23、🚀が位置24でShift_JIS変換不能として記録され、承認代替後は0件、UTF-8版とShift_JIS版の再読込本文は一致しました。一方、想定した機種依存文字三件の内訳は証拠にないため、記事全体の状態はpartialです。
この記事はShift_JISで表現できない文字の発見と保存可否を扱います。CR／LF比較、UTF-8変換後の照合、BOMと改行を選ぶ保存手順とは、中心操作と結論を分けています。現行Mac版の対応範囲はRune Studioの商品ページで確認できます。