入稿後の手戻りを防ぐ!テキストエディタのエンコード、変換不能文字を修正して保存

変換不能文字を見つけたら、最初にするのは削除ではありません。その文字が固有名、異体字、装飾記号、意図的な記号のどれかを文脈で判断し、残す・代替する・表記を変えるという編集方針を決めます。保存先のエンコードを選ぶのはその後です。

テキストエディタ エンコード の事故は、技術的に保存できる文字へ機械的に寄せたときにも起きます。ここでは三つの符号化標本と別名UTF-8複製を使い、「意味が先、保存形式が後」という手順を具体化します。

四種類の候補を同じ修正にしない

人名の異体字は、別の字へ変えると登場人物名が変わるかもしれません。歴史的表記は注記を付けて残す判断があります。装飾記号は文章上不要なら削除できます。意図的な記号は、代替表記を著者へ確認する必要があります。

候補ごとに、原文、前後文、著者の意図、採用表記、保存形式を一行にします。件数を0へすることではなく、全行に理由が付くことが編集側の合格です。

Rune Studioの公開資料では、変換不能文字を赤く示し、問題が残る間は自動保存を止める範囲が案内されています。しかし赤い表示が「削除すべき文字」という意味ではありません。警告は判断を促す材料です。

原文の意味を確定してから承認本文を作る

検証用のUTF-8、Shift_JIS、UTF-16LEを rune inspect text で調べました。結果はUTF-8/LF/44文字、Shift_JIS/LF/44文字、UTF-16LE/LF/45文字です。三ファイルは同じ短い日本語を異なる符号で保存した合成標本です。

変換不能候補を四件と想定しても、CLIの件数だけから四件の正しい代替文字は決まりません。四つの編集判断を済ませた結果を approved-utf8-content.txt として固定しました。SHA-256は 6244b7850324ea7565a8ef0162441e40ce505a4c5b429cf4d3decd99713c2424 です。

判断できない行が一つあれば、保存は保留します。「とりあえず?へ置換」すると、後で原文を探せなくなります。候補の場所と周辺文を残したまま、著者または編集責任者へ戻してください。

保存先エンコードと別名を決める

今回の出力先は STUDIO-306-converted-copy.txt です。先に rune file write --path /private/tmp/rune-g2c3-studio-306-38st8g2a/STUDIO-306-converted-copy.txt --content-file /private/tmp/rune-g2c3-studio-306-38st8g2a/approved-utf8-content.txt --dry-run --json を実行しました。

入力は承認本文、出力は別名複製です。UTF-8、Shift_JIS、UTF-16LEのどの原本も出力先にしません。dry-runでパスを確認した後、同じ命令から --dry-run を外して書き込みました。

Shift_JISでの納品が必須なら、採用した文字が表現可能かをその形式で別に検査します。UTF-8なら常に内容が正しいという意味ではありません。保存形式は承認された文字列を保てる器かどうかで選びます。

保存後の検査で判断票へ戻る

出力後は rune inspect text --file /private/tmp/rune-g2c3-studio-306-38st8g2a/STUDIO-306-converted-copy.txt --json を実行しました。結果はUTF-8、LF、44文字。SHA-256は承認本文と一致し、復号文字列も同一でした。

これで、四件の編集判断を反映した承認本文が、別名UTF-8として保存され、再読込できたことを確認できます。44文字という件数だけで合格にせず、SHAと復号本文一致を使います。

失敗した場合は、原本へ保存し直しません。失敗出力を残し、判断票の採用表記、承認本文、writeの入力、出力先を順番に比べます。どの段で意味が変わったかを特定してから、新しい名前で再試行します。

UIの案内と今回の実測を分けて結論を出す

今回のCLI実測は符号化の検査、dry-run、別名書き込み、再読込です。画面の赤背景、自動保存が停止するまでの時間、IMEの入力、選択状態は測っていません。公開資料で確認できる機能を、今回の操作で目視確認したとは書けません。

破損済みファイルの完全復元、OCR、バイナリ修復も扱いません。保存前に意味を決められる原稿が対象です。すでに上書きで失われた文字は、バックアップや別資料から復元する別工程になります。

四欄の判断票には、候補文字の前後の文脈、採用した表記、保存先文字コード、別名出力のSHAを記録します。人名なら著者原稿、記号なら入稿仕様というように、決定の根拠も並べます。エラーが消えても根拠が空欄なら不合格です。誤った候補を選んだ場合は原本から別名でやり直し、原本と不合格出力をその場で書き換えません。

Rune Studioは文字コード判定や警告を同じMacの編集環境で扱う候補ですが、採用文字を決めるのは著者・編集者です。現行機能はRune Studioの商品ページで確認できます。候補の意味、採用表記、別名保存、再読込一致の四欄を埋め、件数0ではなく説明可能な状態を入稿条件にしてください。