保存した原稿を文字化けさせない！Macのテキストエディタで防ぐ3つの事故

Macのテキストエディタで起きる三つの保存事故は、文字化け、改行変化、BOM変化です。同じ「保存後におかしい」でも、現象も確認先も違います。本記事は最初の分岐を作る概要であり、修復や変換を実行しません。

文字化けは文字の復号化が合わず読めない状態です。改行変化は行末バイトがLFとCRLFの間で変わること、BOM変化はUTF-8先頭のEF BB BFが付く・外れることです。改行やBOMが変わっても、それだけで本文が文字化けしたとは限りません。

分岐1：本文の文字が別の文字に見える

日本語が記号列や不自然な文字へ変わったなら、文字化けの枝です。入力符号化と読込時の解釈が一致しているかを確認します。変換不能文字が?などへ置換された場合も文字内容の損失ですが、「誤った復号」と「表現不能な出力」は原因が別なので事故票内で小分類します。

ここで本文の修復は始めません。正本への上書きを止め、元のバイト列と受領時の符号化申告を文字コード担当へ渡します。可逆変換が必要ならSTUDIO-534、保存停止の状態遷移が必要ならSTUDIO-065の担当です。

分岐2：行の切れ目だけが変わる

文字は読めるのに差分ツールで全行が変更に見える、外部処理で一行扱いになる、といった場合は改行の枝です。LFの0AとCRLFの0D 0Aを確認します。

改行変化を文字化けと呼ぶと、文字コードを変更する誤対応につながります。本記事では「本文表示は読める」「行末属性が変わった」を別主語で記録します。具体的なバイト観測はSTUDIO-521へ渡し、ここでは変換しません。

分岐3：先頭3バイトだけが変わる

本文と改行が同じでも、先頭にEF BB BFが加わる、または消える場合があります。これはUTF-8 BOMの変化です。BOMを必要とする受け渡し先では問題になり得ますが、BOM変化そのものは文字化けではありません。

BOMの有無は先頭3バイトで判定し、改行欄へまとめません。「BOMあり/なし」と「LF/CRLF」は独立した属性です。どちらを採用するかは受け渡し仕様が決めます。

三つを同じ合格条件で判定しない

一つの「問題なし」欄へまとめると、どの証拠が不足しているか分かりません。三枚の事故票ではなく、一枚の分岐票に三行を置き、担当先だけを明示します。

分岐票の状態値は「未分類」「文字」「行末」「先頭」「複数」の五つにします。「複数」を選んだ場合も、下の三行を個別に開きます。観測していない属性は「変化なし」ではなく「未観測」です。受領時と保存後のファイル識別子も添え、別版同士の差を事故と誤認しないようにします。

この票は原因を断定する診断書ではなく、次の検査を選ぶ受付票です。たとえば本文が読めるという理由だけでBOM欄を省略せず、BOMが同じという理由だけで文字内容を正常とはしません。

受付票には修復済みの印を置きません。担当先から検査結果が戻るまで、各行は未観測または調査中のまま維持します。

Rune Studioの役割は文字側に限定する

Stage 3資料では、Rune Studioが主要な日本語文字コードを判定し、変換不能文字を赤表示し、未解決時の自動保存を止めることを確認しています。これは文字化け・文字損失の入口に関係します。

改行やBOMを自動保持・検査するという根拠はありません。したがって、三事故すべてをRune Studioが防いだとは書きません。製品機能と一般のバイト観測を分けます。

複数の変化が同時でも票を一行に戻さない

文字が読めず、改行も変わり、BOMも消えている場合があります。それでも「複合文字化け」と一行にまとめません。文字内容は入力符号化と元バイト、改行は行末、BOMは先頭3バイトをそれぞれ証拠にします。

原因の発生順がまだ分からなくても、現象の三分割はできます。三行に同じファイル識別子を付け、各担当の調査結果を後から結びます。この形なら、一つを直したことで残り二つまで解消したと誤認しません。

修復前に担当先を決める

本文が読めないなら文字コード担当、行の切れ目だけなら改行担当、先頭3バイトだけならBOM仕様担当へ渡します。二つ以上が同時に変わった場合も、行を統合せず、それぞれの証拠を残します。

最初の一手はファイルを直すことではありません。「文字」「行末」「先頭」のどこが変わったかを選ぶことです。この分類ができれば、BOM変化へ文字化け修復を当てるような二次事故を避けられます。三行は別々に閉じてください。