
EPUBへ渡す原稿は、変換を実行しただけでは受け入れません。入力条件、受取票、停止条件、受取側の再検査がそろい、同じファイルを双方が指せたときにだけ引き渡し完了とします。この記事の成果物はEPUBではなく「この原稿をEPUB工程へ入れてよい」と判断できる受取票です。
文字コードの変換実行そのものは「Shift_JISからUTF-8へ変換する手順」に譲ります。本記事は、その結果を受け取る側が何を確認し、どの状態なら止めるかを決めます。画面に表示された文字コード名と、保存されたファイルの実バイトが一致するとは限らないためです。
変換作業と引き渡し判定を分ける
変換担当は、元原稿を保護し、対象コードを選び、別名候補を作ります。受取担当は、その操作を追体験するのではなく、渡された候補が条件を満たすかを独立して判定します。同じ人が兼務する場合も、工程と記録は分けます。
「Shift_JISからUTF-8へ変換する手順」の終了点は「候補ファイルを作り、変換結果を確認した」です。本記事の開始点は、その候補と記録を受け取った時点です。候補をさらに保存し直したり、警告を消すために文字を置換したりしません。変更が必要なら受入停止にして変換工程へ戻します。
入力条件を四つに固定する
受け入れ前に、次の四点をそろえます。
- 元原稿と候補原稿のパス
- 元原稿と候補原稿のハッシュ
- 申告された文字コード、BOM、改行コード
- 未解決文字の件数と位置記録
ハッシュは「内容が同じか違うか」を確認する識別子です。文字コードを変換すれば元と候補のハッシュが違うことはあります。重要なのは、受取票に書かれた候補のハッシュと、受取側が実際に開くファイルのハッシュが一致することです。
BOMや改行コードが納品条件にない場合も、空欄にせず「指定なし」と記録します。未確認と指定なしを混ぜると、受取側が推測で合格にしてしまいます。
受取票には表示値と実測値を分けて書く
受取票の最小欄は、引渡しID、候補パス、候補ハッシュ、画面の選択値、実バイトの判定、BOM、改行、未解決件数、判定、差戻し先です。
| 欄 | 記入例 | 判定で使う理由 |
|---|---|---|
| 引渡しID | EPUB-HO-016-01 | 口頭の「最新版」を避ける |
| 候補パス | chapter01-utf8-candidate.txt | 開く対象を固定する |
| 候補ハッシュ | SHA-256の値 | 受取前後の同一性を確認する |
| 画面の選択値 | Shift_JIS | UI上の状態として残す |
| 実バイト | UTF-8 | 保存結果を別手段で確認する |
| BOM/改行 | なし/LF | 納品条件との一致を見る |
| 未解決件数 | 0または件数と位置 | 内容判断を保留できる |
| 判定 | 受入/保留/差戻し | 次の担当を明確にする |
画面の選択値は補助情報です。実バイトの根拠にはしません。選択値と実測値が食い違えば、どちらかへ都合よく寄せず「不一致」として止めます。
一件でも該当したらEPUB生成を止める
停止条件は先に決めます。
- 受取票の候補ハッシュと実ファイルが一致しない
- 画面の文字コード選択値と実バイトが一致しない
- 未解決文字が一件以上ある
- BOMまたは改行コードが要求されているのに未確認
- 受取側で読み取り専用の再読込ができない
- 元原稿、候補、位置記録の対応が追えない
停止は失敗ではありません。不確かな原稿をEPUBへ入れ、後工程で文字抜けの原因を探す時間を増やさないための判定です。修正が必要なら「Shift_JISからUTF-8へ変換する手順」へ差し戻し、更新された候補には新しい引渡しIDとハッシュを付けます。
受取側は保存せずに再検査する
受取側は候補を読み取り専用で開き、まずハッシュを採ります。次に、バイトを判定できる手段で文字コード、BOM、改行コードを確認します。編集画面の表示だけを証拠にしません。
その後、位置記録にある代表箇所へ移動します。異体字、絵文字、ルビ記号、章境界など、変換で影響を受けやすい箇所を照合します。ここで保存操作をすると、受取側の環境でファイルが変わり、引渡し証拠を壊す可能性があります。差異を見つけたら記録だけを残し、候補は更新しません。
再検査後にも同じハッシュであることを確認すれば、「確認のために開いた結果、内容を変えていない」ことも示せます。
Rune Studioで確認できた範囲と判断待ちを分ける
2026年8月14日の現行Mac版による複製した標本での動作確認では、実ファイルはUTF-8・LFでした。タブの文字コード選択をShift_JISへ変更すると操作は成功し、閉じて開き直しても選択メタデータは残りました。一方、実ファイルのバイトはUTF-8・LFのままでした。
この結果から確認できたのは、文字コードの選択値が保持されることです。選択値の変更だけで物理ファイルがShift_JISへ変換された、とは言えません。表示値と実バイトを分けて受取票へ書く理由がここにあります。
BOM付きファイル、実際のShift_JISファイル、CRLFへの物理変換、変換不能文字の赤表示、保存警告、自動保存停止は今回の操作では確認していません。CRLF指定は最初に使った表記では受理されず、別の指定表記が認識されることまでは分かりましたが、物理変換の完了までは確認できませんでした。これらは公開資料に書かれた範囲と手元の結果を分け、保留として扱います。

受入・保留・差戻しの三つで結論を出す
受入は、候補の同一性、実バイト、要求されたBOM・改行、未解決件数、読み取り専用再検査がすべて合格した状態です。保留は、要求が未定または証拠が不足している状態です。差戻しは、ハッシュ不一致や未解決文字など修正が必要な状態です。
「画面にUTF-8と出た」「見た目が読めた」だけでは受入にしません。逆に、資料に書かれた機能が未検証だから原稿全体を不合格にするのでもありません。受取票の各欄を、確認済み、未確認、対象外に分けて判断します。
結論:EPUBへ渡すのはファイルではなく証拠付きの候補
EPUB変換前の文字コード対策は、変換操作と引き渡し判定を分けると安定します。「Shift_JISからUTF-8へ変換する手順」で候補を作り、本記事の受取票へ入力条件、ハッシュ、表示値、実バイト、停止条件、受取側検査を残してください。
最初の行動は、受け取る候補のパスとSHA-256を受取票へ記入することです。Rune Studioを候補にする場合は、Rune Studioの商品ページで現行の文字コード関連機能を確認し、資料仕様と自分の実測を別欄へ記録してください。


