違いがひと目で分かる！KDPの文字化け、文字コード原因の診断

複数の文字コードを比べてKDP入稿前に文字化け原因を診断するアイキャッチ

KDP用データで文字化けを見つけたら、最初に文字コードを変えるのではなく、どの段階で初めて化けたかを確定します。原稿を開いた時点、保存後、EPUB生成後、Kindle Previewerでの変換・表示後では、調べる対象が違うからです。

この記事では、KDP入稿前後の症状を4段階に分ける診断表を作ります。文字コードの自動判定機構や、別の文字コードで開き直す具体操作は近接記事に譲り、ここでは次に調べる場所を決めることへ集中します。

診断前に3つを保存する

原因を調べる前に、次を別名で残します。

  1. 受け取ったままの原稿
  2. EPUBへ変換する直前の原稿
  3. KDPへ送る予定のEPUB

元ファイルを上書きしてしまうと、「もともとのバイト列」と「変換後の文字」を比べられません。正しい文字コードで読み直して戻せる可能性があるのは、誤った読み方のまま保存されておらず、元のバイト列が残っている場合に限られます。

段階A：原稿を開いた時点ですでに化けている

テキストエディタで原稿を開いた時点から、文字がまとまって別の記号に見える場合です。この段階では、KDPやEPUB生成はまだ関与していません。

確認するものは次です。

rune Studioの操作検証では、Shift_JISの原稿はShift_JIS、UTF-8の原稿はUTF-8と判定され、改行コードと文字数も返りました。この表示は現在どの文字コードとして読んでいるかを確認する材料になります。

ただし、判定表示だけで原稿が正しいとは確定しません。受け渡し元の仕様や未変更の原稿と照合します。すでに誤読した内容で上書きしていた場合、文字コードを選び直すだけでは元へ戻らないことがあります。

段階B：保存したあとに文字が変わった

開いた直後は正常で、保存後または再度開いたあとに特定の文字が変わった場合です。ここでは保存先の文字コードと、変換先で表せない文字を調べます。

操作検証では、𠮷 を含むUTF-8原稿をShift_JISで保存しようとすると、表せない文字1件が位置付きで返り、保存は停止しました。また、Shift_JISで保存した波ダッシュ（〜）を読み出すと全角チルダ（～）になった例がありました。

この段階で見るのは、次の差です。

UTF-8へ統一すると、Shift_JISなどとの符号化不一致が原因の一部は避けやすくなります。しかし、すでに置換された文字、フォントの字形差、EPUB変換、配信後の表示まで防げるわけではありません。

段階C：原稿は正常で、EPUBの本文が化けている

原稿は正常に読めるのに、生成したEPUBを展開して本文を見ると文字が変わっている場合です。この段階では、原稿の読み込みからEPUB内部のHTMLを作るまでを調べます。

確認項目は次です。

rune Studioには、書き出したファイルの中身を調べる機能があります。この記事では、その結果だけで文字化けの原因を決めず、問題の文字を原稿とEPUB内部で直接比較します。内部検査はKDPでの文字表示を保証するものではありません。

原稿では正しく、EPUB内部ですでに違うなら、KDPへ送る前に生成工程を見直します。

段階D：EPUB内部は正常で、Kindle Previewer以降で違って見える

EPUB内部の本文HTMLには意図した文字が残っているのに、Kindle Previewerや端末で別の形に見える場合です。ここでは入力文字コードだけに原因を限定できません。

候補には、次が含まれます。

今回の操作検証は、KDPへの入稿処理や端末表示を確かめていません。したがって、この段階の原因をrune Studioの内部値だけから断定はできません。Kindle Previewerの表示、選んだファイル名、EPUB内部の該当文字を並べて記録し、差が生まれた境界をKDP側の資料と照合します。

症状から次の確認先を決める

迷ったら、次の順で判断します。

この順序なら、原稿を直すべきなのか、EPUBを作り直すべきなのか、KDP側の表示を調べるべきなのかが分かれます。

診断記録の最小形

問題の文字を1つ選び、次の4欄を埋めます。

「全部文字化けしている」と書くより、同じ1文字を段階ごとに追うほうが境界を特定できます。別の症状がある場合は、2文字目を追加します。

まとめ

まず、化けた文字を1つだけ選び、元原稿、保存後、EPUB内部、Kindle Previewerの4欄へ写してください。最初に違った欄が、次に調べる段階です。

Rune Studioの商品ページを見る

投稿日：