UTF-16の原稿をUTF-8へ変換するときは、元ファイルを上書きしないのが最初の安全策です。UTF-16LEとして読める原本を確定し、承認本文を別名のUTF-8ファイルへ書き、閉じた後に再検査します。復号本文が一致して初めて変換完了です。
utf-16 テキストエディタ を探している人が必要なのは、対応形式の一覧より、どのファイルをどう判定して保存するかという順序です。ここでは実測した45文字のUTF-16LE標本と44文字のUTF-8複製を使い、差を隠さず合否を決めます。
UTF-16入力の正本を決める
最初に原本の場所、作成元、読める状態を記録します。BOMの有無やLE/BEを推測で決めず、検査結果を使います。誤った復号で文字化けした画面を正しい原文だと思い、そのまま保存すると、元のバイト列まで失う可能性があります。
検証用の原本は source-UTF-16LE.txt です。永続化したSHA-256は f37fc7485e4b8679e16aa0211fc7146a9e145f31d5134bbf0a4a357906eb1f09。作業対象はこのファイルの複製であり、本番原稿ではありません。
原文の意味も別に固定します。符号化を変える前に、承認されたUnicode文字列を approved-utf8-content.txt に置きました。変換はこの意味を別の符号化で保存する作業で、文字を勝手に削除する作業ではありません。
三形式を検査して対象を取り違えない
比較のため、UTF-8、Shift_JIS、UTF-16LEの三ファイルを用意しました。UTF-16LEへの実命令は rune inspect text --file /private/tmp/rune-g2c3-studio-303-i_ds9byi/source-UTF-16LE.txt --json です。ほかの二形式もパスだけを変えて検査しました。
結果はUTF-8がUTF-8/LF/44文字、Shift_JISがShift_JIS/LF/44文字、UTF-16LEがUTF-16LE/LF/45文字です。全命令の終了コードは0でした。45文字という値を「UTF-8も44だから誤り」と決めず、検証標本から読み取った実値として保持します。
この段階の失敗は、検出形式がファイル名の想定と違う、改行が想定外、復号後の文字列が承認原文と違う、です。一件でも出たら保存へ進みません。正本を選び直し、別の複製で検査します。
変換後の本文を編集判断として承認する
UTF-16からUTF-8への変換では、文字列の意味が維持されることが目的です。変換不能候補があるなら、人名、記号、異体字の前後を読み、残すか代替するかを決めます。ツールが選べる文字へ自動置換しただけでは、編集上の承認になりません。
今回の approved-utf8-content.txt は、UTF-8標本と同じ64バイト、SHA-256 354980a66eef4fc53e93f1a7527407bcc6f898fc7599e0e2679d552f48413a2c です。変換先の期待値を保存前に持つため、保存後の比較ができます。
もし承認文字列が未確定なら、原本を読める状態で止めます。文字コードの変換を急ぐより、正しい本文を失わないほうが重要です。
dry-runで出力先だけを先に確かめる
書き込み前の命令は rune file write --path /private/tmp/rune-g2c3-studio-303-i_ds9byi/STUDIO-303-converted-copy.txt --content-file /private/tmp/rune-g2c3-studio-303-i_ds9byi/approved-utf8-content.txt --dry-run --json です。
ここで見るのは、入力が承認本文、出力が新しい別名であることです。出力先が source-UTF-16LE.txt なら不合格にします。dry-runの終了コード0は、対象確認の関門であって、ファイル保存の完了ではありません。
出力名には変換後だと分かる語を入れます。本番では日時や版番号も加えると、元のUTF-16ファイルと取り違えにくくなります。
別名へ書いて原本を残す
対象を確認後、同じ命令から --dry-run だけを外して書き込みました。作成したファイルは STUDIO-303-converted-copy.txt、元のUTF-16LEとは別パスです。命令は終了コード0でした。
保存失敗や中断が起きたら、新しいファイルを失敗結果として扱います。元のUTF-16LEへ戻して上書きを繰り返しません。別名方式なら、失敗した出力と原本を比較できます。
再読込でUTF-8と本文一致を確認する
保存後は rune inspect text --file /private/tmp/rune-g2c3-studio-303-i_ds9byi/STUDIO-303-converted-copy.txt --json を実行しました。返却値はUTF-8、LF、44文字です。SHA-256は承認本文と同じ 354980a66eef4fc53e93f1a7527407bcc6f898fc7599e0e2679d552f48413a2c、decoded_text_equal=true でした。
合格条件は、出力形式がUTF-8、改行がLF、復号本文が承認値と一致することです。44文字という件数だけでは足りません。同じ長さの別文字へ変わっても件数は一致します。
再読込が失敗したら、出力を残してdry-runの前へ戻ります。承認本文、出力パス、書き込み命令のどこが違ったかを調べます。
原本不変と再読込一致を最後の二条件にする
Rune Studioの公開資料には主要な日本語文字コード判定、変換不能文字の赤表示、自動保存停止が案内されています。今回のCLIは誤復号画面、赤い画素、IME、自動保存の時刻、未保存バッファを測っていません。公開資料の範囲と今回の保存実測を分けます。
破損済みデータの完全復元、OCR、バイナリ修復も対象外です。この記事が確認したのは、UTF-16LE原本を残し、承認本文を別名UTF-8へ書き、再読込で一致を得るところまでです。
現行Mac版の機能範囲はRune Studioの商品ページで確認できます。原本のSHAが変わっていないことと、UTF-8複製の本文が一致すること。この二条件を変換記録へ残してから、次の編集やEPUB生成へ進んでください。