Shift_JISなどの原稿をUTF-8へ変換するときは、元のバイト列を正しい文字コードで読む → 読み取った本文をUTF-8で別ファイルへ書く → 変換前後の本文全体を比べる、という3段階に分けると違いが見えます。これは特定の画面操作ではなく、文字コード変換を成立させる一般原理です。
この記事では、3段階で何を成立させる必要があるかを説明します。rune Studioについて実測できているのは文字コードの判定結果と、逆方向であるUTF-8からShift_JISへの保存拒否までです。Shift_JISからUTF-8への別名保存、再読込、全文一致を一続きに完遂した記事ではありません。
変換は「読む」と「書く」の組み合わせ
文字コードを変えるとは、ある文字コードで読んだものを、別の文字コードで書き直すことです。読む側と書く側は別の処理です。
ここで大事なのは順番です。読む側が正しくないまま書くと、間違った文字がそのまま新しいファイルへ書き込まれます。 だから「開く」段の確認を飛ばしてはいけません。
一括変換の道具で確認したい条件
フォルダの中の原稿をまとめて変換する道具を選ぶなら、元の文字コードをファイルごとに確認できるか、変換先をUTF-8に固定できるか、原本を残せるか、失敗したファイルを特定できるかを先に見ます。処理件数が多くても、読み込み側の判断が正しいことまでは件数から分かりません。
なお、rune Studioに一括変換機能があるかどうかは、今回の検証では確認していません。
3段階を混同すると、何が起きるか
読み込みが誤っていれば、その後のUTF-8出力にも誤った文字が渡ります。 誤って読んだ本文で唯一の原本を上書きし、バックアップもなければ、元のバイト列を使った読み直しができません。原本かバックアップを残すのは、この復号のやり直しを可能にするためです。
読み込みと書き込みの文字コードを同じにしたままでは、UTF-8への変換は成立しません。 ファイルが更新されたことと、UTF-8で書かれたことは別の確認です。
書き込み後の確認がなければ、本文が保たれたかは判断できません。 保存の成否と、変換前後の復号後本文が一致することも別です。
段階1：変換元を正しく読む
rune Studioは原稿を読み込むときに文字コードを判定し、結果を返します。実際に開発版を命令から動かして確かめました。Shift_JISで保存した原稿を読み込むとShift_JIS、UTF-8の原稿を読み込むとUTF-8と返り、改行コード、文字数、行数も一緒に返りました。
変換元を読む段階では、次の3点を確認対象にします。
- 返ってきた文字コードが、その原稿について自分が思っていたものと合っているか
- 本文が読める形になっているか
- 記号が壊れていないか
3つ目が抜けやすいところです。本文が読めても記号だけ違う、ということが起きます。実際に、Shift_JISの原稿へ書いた波ダッシュ（〜）が、読み出すと全角チルダ（～）になって返りました。
段階2：読み取った本文をUTF-8で書く
2段階目の要件は、正しく復号できた本文をUTF-8のバイト列として書くことです。変換元の推定と変換先の指定は同じものではありません。使う道具には、UTF-8を出力先として明示でき、原本とは別の結果を残せることが必要です。
ここで述べているのは道具を選ぶための要件です。rune StudioでShift_JIS原稿をUTF-8の別ファイルとして保存できた、という操作結果を示すものではありません。
段階3：変換結果を別に検証する
変換結果を確認する一般的な条件は、結果をUTF-8として読み、変換元を元の文字コードで読んだ本文と全体で比較できることです。ファイルが作られたことだけでは、本文一致の根拠になりません。
この一続きのShift_JISからUTF-8への保存・再読込・全文一致は、今回のrune Studio検証では完遂していません。そのため、ここでは製品の操作手順や完了結果としては扱いません。
別の文字コードへ保存すると止まる例
実際に開発版で、髙・𠮷・瀨を含むUTF-8原稿をShift_JISで保存しようとしたところ、保存されず、この文字コードでは表せない文字が1か所あるという結果が返り、ファイルは作られませんでした。
この実測から言えるのは、rune Studioが確認した条件では、変換先で表せない文字を位置付きで返し、Shift_JIS保存を行わなかったことです。
この実測はUTF-8からShift_JISへ保存する逆方向の例です。Shift_JISからUTF-8への変換が完遂した証拠にはなりません。
変換前の原稿を残し、全文の差分を見る
複数の原稿を扱う場合も、原本と変換結果を1本ずつ対応づけて残せることが、比較の前提になります。
本文保持の確認に必要なのは、特定の語の件数ではなく、全文の比較です。 変換元をShift_JIS、変換結果をUTF-8として復号し、文章全体が一致するかを比べるのが判定条件です。
特徴的な語の検索は、確認するファイルを絞る手がかりにはなります。ただし、件数が同じでも、別の場所で欠落と追加が相殺することがあるため、完了の根拠にはしません。
向く人と、別の方法が向く人
この3段階の整理が役立つのは、文字コードが混ざった原稿を複数抱えている人です。 共同執筆、古い原稿の再利用、外部からの受け取りでは、読み込み・書き込み・比較を別々に判定できます。
最初からUTF-8だけで書いているなら、変換は要りません。 新しく書き始める原稿なら、そもそも混ざりません。
なお、確かめたのは判定結果が返ること、逆方向のShift_JIS保存が拒否されること、横断して探せることまでです。まとめて変換する機能と、Shift_JISからUTF-8への別名保存・再読込・全文一致は確かめていません。
まとめ
- UTF-8変換は「変換元を正しく読む → 読み取った本文をUTF-8で書く → 復号後の全文を比べる」の3段階
- 読み込みの正しさ、書き込み先がUTF-8であること、本文全体の一致は別々に確認する
- 原本を残し、変換結果と1本ずつ対応づけられる道具を選ぶ
- rune Studioで実測済みなのは文字コード判定と逆方向の保存拒否で、Shift_JISからUTF-8への完遂結果ではない
道具を選ぶときは、変換元の文字コードを確認できるか、UTF-8の別ファイルを書けるか、UTF-8として再読込できるか、復号後の全文を比較できるかを確認します。4条件がそろって初めて、この記事の3段階を最後まで検証できます。