Shift_JIS原稿をUTF-8へ変換するときは、変換不能文字を先に解消し、UTF-8の別名版を開き直して本文・文字数・改行を照合します。今回の標本は要求1,400字に対して実測1,399字、改行はCRLFでした。😀がインデックス16、🚀が17で変換不能として記録され、承認代替後は0件、UTF-8版とShift_JIS版の再読込本文は一致しました。失敗時の戻し先は、原本ではなく「2件を修正して0件になった直後の複製」です。
記事固有のstatusはpartialです。2件の修正と再読込一致は確認できましたが、開始値に1字差があります。想定した外字候補一件の文字・コードポイント・扱いも結果へ残っていません。画面の赤表示、保存前警告、自動保存の停止・再開はCLIで未確認です。
UTF-8変換は三つの合格に分ける
UTF-8へ設定を変えただけでは、変換完了とは言えません。少なくとも次の三つを別々に確認します。
- 元のShift_JIS原稿を正しく読み込めた
- 変換不能文字を承認済みの方法で修正し、残件が0になった
- UTF-8別名版を開き直し、修正本文・文字数・改行が期待値と一致した
一つ目に失敗した状態で保存すると、誤った文字列をUTF-8として固定するおそれがあります。画面が読めることより、原本との照合を先に置きます。
1,400字の予定は実測1,399字だった
標本はShift_JIS由来、CRLF改行、絵文字2件、外字候補1件という予定でした。タイトル固有の結果は次のとおりです。
| 項目 | 実測値 |
|---|---|
| 要求文字数 | 1,400 |
| 実測文字数 | 1,399 |
| 変換不能文字 | 2件 |
| 位置 | 😀＝16、🚀＝17 |
| 承認代替後 | 0件 |
| 修正版UTF-8 | UTF-8として再読込 |
| 比較用Shift_JIS | Shift_JISとして再読込 |
| 元の改行 | CR+LF |
| 修正本文 | 二形式で一致 |
要求値と実測値の1字差を丸めて「1,400字」とは書きません。原因はこの証拠だけでは確定できないため、実測1,399字を変換前後の基準にします。外字候補一件も記録にないので、検証済みの2件へ合算しません。
製品を使わない変換手順
一般的な方法でも、原本を守って別名版を検証できます。
- Shift_JIS原本を複製し、SHA-256、実測1,399字、CRLF、代表文を記録します。
- 複製をShift_JISとして読み、変換不能一覧を位置付きで取得します。
- 位置16と17を原文に照合し、承認した代替だけを反映します。
- 同じ検査を繰り返し、残件0を確認します。
- 0件の修正版をUTF-8で別名保存し、必要なら比較用Shift_JIS版も別名で残します。
- 両方を閉じて開き直し、全文、実測文字数、CRLF、代表文を照合します。
UTF-8へ変換する目的であっても、原本を上書きしません。別名版が不合格なら捨てられる状態を維持します。
2件から0件になってもpartialである理由
今回、記録された2件は0件まで修正され、二形式の本文も一致しました。これは変換工程の重要な部分です。一方で、開始値1,400に対する実測1,399の差は残っています。
また、標本説明にある外字候補一件はresult_valuesに現れません。表現可能だったのか、標本へ入っていなかったのか、検出対象外だったのかは判断できません。この未確認項目を埋めずに「全候補を安全に変換した」とは書けません。
Rune StudioのStage 3機能とStage 4実測
現行Mac版Rune Studioの公開資料では、UTF-8、UTF-8 BOM付き、Shift_JISなどの主要文字コードを扱い、変換不能文字を赤い背景で示し、残っている間は自動保存を一時停止し、手動保存時に警告します。ステータスバーから文字コードと改行コードを切り替えられます。ここまではStage 3の製品範囲です。
タイトル固有Stage 4で確認したのは、1,399字標本の2位置、代替後0件、UTF-8版とShift_JIS版の再読込、CRLF、本文一致です。画面警告や操作感は含みません。
共通Stage 4では、別の短文をUTF-8、Shift_JIS、EUC-JPで39字、UTF-16LE、UTF-16BEで40字、すべてLFとして識別し、作業タブの文字コード設定をUTF-8と再取得しました。この共通結果は対応形式の補助確認であり、1,399字標本の変換結果ではありません。
Mac用エディタ選びの記事とは結論を分ける
MacのUTF-8テキストエディタを選ぶ記事は、元文字コード・改行・文字数・変換不能位置を再確認できる道具かを評価します。この記事は、採用済みの手段で2件を修正し、UTF-8別名版を作って照合する具体的な変換手順です。
エディタの多機能さや価格比較は扱いません。UTF-8へ保存できるという機能一覧ではなく、0件と再読込一致を変換の出口にします。
戻し先と未確認範囲
- 読み込み文字コードを確定できない：保存せず、Shift_JISとしての読み込み確認へ戻る
- 変換不能位置が原文と合わない：代替せず、検出一覧へ戻る
- 代替後に残件がある：UTF-8保存へ進まず、残件一覧へ戻る
- 再読込本文が違う：出力を破棄し、0件確認直後の複製へ戻る
- 1,399字が変わる：どの文字が増減したかを比較し、保存前へ戻る
画面の保存前警告、赤表示、誤復号状態、自動保存の停止・再開、外部アプリや提出先での受理は未確認です。破損済みデータの完全復元、OCR、バイナリ修復も扱いません。
結論：実測1,399字を基準にUTF-8別名版を照合する
今回の変換では、要求1,400字に対して実測1,399字、CRLF、位置16の😀と17の🚀が開始値でした。承認代替後は0件となり、UTF-8版とShift_JIS版の再読込本文は一致しました。1字差と未記録の外字候補を残すため、statusはpartialです。
この記事の役割は変換不能文字を直してUTF-8別名版を検証することです。Shift_JISで表現できない候補を分類する記事、BOMの有無を判定する記事、BOMと改行を選んで保存する記事とは、入口と出口を分けています。現行Mac版の対応範囲はRune Studioの商品ページで確認できます。