画面に「UTF-8」と出ていても、「髙」「①」「〜」「é」「😀」が保存後に同じ姿で戻るとは限りません。このテキストエディタ エンコード検査では、UTF-8、BOM付きUTF-8、Shift_JISの三複製を用意し、五文字、BOM、改行、再読込を一項目ずつ照合します。実機確認で確認できたのはShift_JISという選択値の保持までで、実ファイルはUTF-8・LFのままでした。物理変換と別名保存は未確認のまま採否表へ残します。文字化け原因診断は「文字化けの原因診断」、変換手順は「Shift_JISからUTF-8へ変換する手順」、文字コード概論は「文字コードの基礎」の担当です。
五文字の再読込を画面の文字コード名より先に確かめる
テキストエディタのエンコード判定は、画面に『UTF-8』と表示されたら終わりではありません。最初の答えは、元ファイルを複製し、髙・①・〜・é・😀の五つを先頭、中央、末尾で確認し、別名保存した複製を閉じて開き直すことです。文字列、改行位置、先頭のBOM有無が保存前と一致して初めて、その読み込み方を採用できます。
五つの文字には役割があります。髙は異体字、①は機種依存と誤解されやすい記号、〜は波形の違い、éは日本語以外の文字、😀はShift_JISで表現できない文字の例です。全部を『見えた』でまとめず、どの文字が読め、どの文字が保存時に拒否または変化したかを別々に記録します。
BOMと改行は本文の見た目だけでは判定できない
UTF-8とBOM付きUTF-8は、本文だけを見れば同じに見えることがあります。BOMはファイル先頭に置かれる識別用のバイト列なので、エディタの表示か、別の確認手段で有無を確かめます。BOMを消してよいかは提出先の仕様で決まり、BOM付きが古い・BOMなしが常に正しい、とは決められません。
改行も同様です。LFとCRLFは画面上ではどちらも改行に見えます。ステータス表示で現在値を確認し、保存前後で行数と段落境界が変わっていないかを見ます。文字コードの変更と改行コードの変更を同時に行うと、差の原因を追えません。最初の試行では片方だけを変えてください。
三つの複製で判定する具体例
正本は触らず、sample-utf8.txt、sample-utf8-bom.txt、sample-sjis.txtの三つを作ります。各ファイルには同じ五文字と三段落を置きます。開いた直後に五文字を確認し、表示された文字コードと改行コードを控えます。次に末尾へ『再読込確認』と一行だけ追加し、別名で保存して閉じます。
開き直したとき、UTF-8系では五文字と追記行が保持されるかを見ます。Shift_JISでは😀など表現できない文字が残るため、警告や保存停止が起きる可能性があります。そこで無理に疑問符へ置換せず、『この原稿はShift_JISのまま安全に保存できない』と判定します。判定の目的は変換を成功させることではなく、採用できない条件を見つけることです。
自動判定が外れたように見えるときの切り分け
自動判定は出発点です。日本語を含まない短いASCIIだけのファイルは、複数の文字コードで同じように読めるため、表示名だけから元の方式を確定できません。作成元の情報、BOM、実際に使われている文字の範囲を合わせて判断します。
開いた瞬間から崩れていれば読み込み候補を変え、保存後だけ崩れるなら出力側の表現可能範囲を疑います。一台だけ字形が違うならフォントの問題かもしれません。この原因診断の全体は「文字化けの原因診断」へ譲り、ここでは『候補ごとの再読込結果から採否を決める』ことだけに集中します。
Rune Studioの選択値を実バイトの証拠にしない
公開機能資料では、現行Mac版Rune Studioの対応文字コード、ステータス領域での文字コード・改行コード選択、表現できない文字の赤い背景、保存警告、自動保存停止が説明されています。これらは資料仕様です。
2026年8月14日の複製した標本での動作確認では、UTF-8・LFの実ファイルに対し、タブの選択値をShift_JISへ変更して再読込しても選択メタデータは保持されました。しかし実バイトはUTF-8・LFのままでした。したがって、画面の選択値を物理変換や実コードの証拠にはできません。
BOM付きUTF-8、Shift_JISの実ファイル、CRLFへの物理変換、変換不能文字の赤表示、保存警告、自動保存停止は今回の実操作では未確認です。三複製と五文字は受入テストの設計であり、Rune Studioで完遂済みの実測標本ではありません。
採用・保留・不採用を一行で残す
採用は、五文字、行数、BOM条件、改行コード、追記行が再読込後も期待どおりだった場合です。保留は、ASCIIだけで方式を区別できない、作成元の情報がない、提出先がBOMを要求するか不明な場合。不採用は、保存によって文字が変わる、改行が増減する、警告を無視しなければ保存できない場合です。
最初の行動は、実原稿を変換することではありません。五文字を含む三つの短い複製を用意し、文字コードと改行コードを一つずつ確認してください。変換方法は「Shift_JISからUTF-8へ変換する手順」へ、文字化けの原因分岐は「文字化けの原因診断」へ進めます。現行Mac版の対応範囲はRune Studioの商品ページでも確認できます。
三候補の差を同じ記録欄で比べる
UTF-8候補では五文字が戻り、絵文字を含む別名保存も通るかを見ます。BOM付きUTF-8候補では文字列が同じでも、再読込後にBOMが維持されたかを別欄にします。Shift_JIS候補では、髙や①が読めたという理由だけで採用せず、éと😀を保存できるか、赤表示になったかまで確認します。比較する値を候補ごとに変えると都合のよい結果だけが残るため、五文字、BOM、改行、再読込の四列は固定します。
たとえばUTF-8候補だけが五文字を保ち、BOMなし、LF維持、再読込一致なら、その四点を採用理由にします。Shift_JIS候補で😀が赤くなり保存が止まった場合は、失敗ではなく「この原稿をShift_JISで表現できない」という判定材料です。文字を削って保存を通すのではなく、提出先がShift_JISを必須とするかを確認して変換記事へ渡します。
提出先の条件を判定表へ加える
同じファイルでも、提出先がUTF-8 BOMなしを指定する場合と、Windows向け処理がBOMを前提にする場合では採否が変わります。判定表には『読めた』だけでなく、提出先が求める文字コード、BOM、改行コードを先に書きます。要件が不明なら保留にし、見た目が正常という理由で決めません。
三つの複製は、元原稿の候補を当てるためだけでなく、提出条件に合う再保存ができるかを確かめる標本です。文字コードを選び直した後は、五文字、行数、ファイル先頭、末尾の追記行をもう一度確認します。元のバイト列と新しい成果物を混同せず、変換前ファイルを残しておけば、後から要件が変わっても戻れます。
採用する複製で照合する値
-
正本は読み取り用として残し、判定用の三複製と混ぜない
-
五つの代表文字を先頭・中央・末尾へ分散して一部だけの成功を見逃さない
-
UTF-8とBOM付きUTF-8は本文表示ではなくファイル先頭の条件で区別する
-
文字コード変更と改行コード変更を一度に行わない
-
別名保存した成果物を閉じ、同じエディタだけでなく提出条件に沿う方法で再確認する
-
Shift_JISで表現できない文字は疑問符へ変えて成功扱いしない
-
採用・保留・不採用の理由に文字、BOM、改行、再読込のどれを使ったか書く
-
提出先の指定が不明なら見た目だけで採用せず保留にする
五文字・BOM・改行の判定票を引き継ぐ
まず元ファイルを触らず三つの複製を作り、UTF-8、BOM付きUTF-8、Shift_JISとして五つの代表文字と改行を記録してください。閉じて開き直した複製だけを採用候補にします。赤表示や保存停止が出た複製は失敗を消さず、文字位置と選択した文字コードを添えて「文字化けの原因診断」の原因診断、必要なら「Shift_JISからUTF-8へ変換する手順」の変換手順へ渡します。複製を開く前に、Rune Studioの商品ページで対応文字コードと保存停止の範囲を確認できます。