つまずきを減らす！MacテキストエディタのUTF-8変換、BOM・改行コードを確認して保存

Macのテキストエディタで既存ファイルをUTF-8へ変換するなら、最初に元の文字コードで正しく読めていることを確認し、次に別名のUTF-8コピーを作り、BOMと改行コードを独立して選び、最後に保存ファイルを開き直します。「文字コード欄をUTF-8へ変えた」だけでは、変換完了とは判断できません。

この記事のタイトル固有Stage 4で passed なのは、この流れの後半にある保存条件の確認です。同じ日本語30行から、UTF-8・BOMなし・LFの660バイト版と、UTF-8・BOM付き・CRLFの693バイト版を作り、先頭バイトとCR／LF数を確認しました。Shift_JISなどの非UTF-8原本を正しく復号してUTF-8へ別名保存し、再読込する一連の変換は実測していません。したがって、以下では変換全体の手順と、今回確認済みの後半結果を分けます。

MacでUTF-8へ変換する五つの確認点

1. 非UTF-8原本の開始値を記録する

変換元がShift_JIS、EUC-JP、UTF-16などである場合は、原本のファイル名、識別値、検出された文字コードを記録します。検出値が不明なままUTF-8を選ぶと、誤って読んだ文字列をUTF-8として固定するおそれがあります。

今回の30行Stage 4は、すでにUTF-8出力条件へ置いた同一本文から始めています。非UTF-8原本の開始値を持たないため、この第一段階を通過した証拠には使いません。

2. 元の文字コードで正しく読めているか確認する

先頭、中央、末尾の代表文字を原本と照合し、変換不能文字や置換文字がないか確認します。正しい復号を確認できなければ、文字コードを切り替えず、原本の複製と検出方法へ戻ります。

この段階は、文字化けした表示を後から直す作業ではありません。元のバイト列をどの文字コードとして読むかを確定する入口です。Shift_JISからUTF-8へ変換する個別の復号確認は、STUDIO-180の中心範囲へ譲ります。

3. UTF-8コピーを別名保存する

正しく読めた複製を、原本とは別の名前でUTF-8として保存します。ここで初めて「元の文字コードからUTF-8へ変換する」という変更が発生します。原本を上書きせず、変換前へ戻れる状態を保ちます。

4. BOMと改行コードを別々に選ぶ

UTF-8を選んだ後も、BOMの有無と改行コードは未決定です。受け渡し先の仕様または既存の正常ファイルを基準に、BOMなし／ありとLF／CRLF／CRを別項目として選びます。「UTF-8だからBOMなし」「Macだから必ずLF」と決めつけません。

5. 保存ファイルを開き直して確認する

別名保存したファイルを開き直し、検出された文字コード、BOM状態、改行コード、代表文字を確認します。先頭バイトとCR／LF数も確認できれば、保存ダイアログの選択ではなく、実際の出力を記録できます。

この五点のうち一つでも未確認なら、記録上は「UTF-8変換完了」ではなくpartialです。今回の実測は、第三〜第五段階に関係するUTF-8二出力の保存条件だけを裏付けます。

今回測ったのは二つのUTF-8出力条件

同じ日本語30行を、次の二条件で保存しました。

BOMなし版は先頭にBOMがなく、LFだけが30個ありました。BOM付き版は EF BB BF で始まり、CRとLFが30個ずつありました。この範囲では、BOMと改行コードを独立した保存条件として出力結果から区別できます。

二ファイルの差は33バイトです。内訳はBOMの3バイトと、CRLF化で追加されたCR 30個の30バイトです。この一致により、ファイルサイズ差を本文の欠落と誤認せず、保存条件の差として説明できます。

ただし、この表は非UTF-8原本からの変換全体を証明しません。開始時点の正しい復号、変換前後の代表文字一致、非UTF-8原本からの再読込は測っていないためです。

製品に依存しない変換記録を残す

変換の記録は、一行の「UTF-8へ変更」ではなく、次のように分けます。

この表なら、文字コード変換の失敗と、BOMまたは改行コードの選択ミスを別々に戻せます。受け渡し条件が違っていた場合は、正しく復号できた変換前コピーから別名で出力し直します。

Rune Studioで確認できる範囲

現行Mac版Rune Studioの公開資料では、UTF-8とUTF-8（BOM付き）を含む複数の文字コード、LF、CRLF、CRを扱い、ステータスバーから文字コードと改行コードを確認・切り替えられます。読み込みではBOMを先に判定してから自動検出へ進みます。

選択した文字コードで表現できないUnicode文字が残る場合は、該当範囲を赤く示し、手動保存時に警告します。自動保存は一時停止し、通知が表示されます。これらはStage 3の製品仕様です。

今回のStage 4はRune Studio画面の操作撮影ではなく、生成した二ファイルの先頭バイト、CR／LF数、バイト数を確認した証拠です。Stage 3の対応機能を、非UTF-8原本からの変換成功へ広げません。

近接記事とは変換工程の担当を分ける

STUDIO-180は、Shift_JIS原本を正しく復号し、変換不能を判断してUTF-8へ別名保存する個別変換を扱います。STUDIO-524はBOM有無の判定、STUDIO-526はCR、LF、CRLFの診断が中心です。

この記事は、UTF-8変換全体の五つの確認点を示したうえで、特に変換後のBOMと改行コードを独立して保存・再確認する役割を持ちます。元文字コードの復号を省略して「UTF-8変換済み」とする記事でも、BOM判定だけで終わる記事でもありません。

結論：変換完了と保存条件のpassedを分ける

MacでUTF-8へ変換するときは、非UTF-8原本の開始値を記録し、正しい復号を確認し、UTF-8コピーを別名保存し、BOMと改行コードを独立して選び、保存後に開き直します。これがタイトルのUTF-8変換を回収する一連の手順です。

今回確認済みなのは、同一30行をUTF-8・BOMなし・LFで660バイト、UTF-8・BOM付き・CRLFで693バイトとして出力し、BOM3バイトとCR 30バイトの差を説明できたことです。この保存条件比較はpassedです。一方、非UTF-8原本からの正しい復号と変換完了、このMac以外の環境で動作するアプリによる自動変換、受け渡し先での受理は未確認のためpartialとして残します。現行Mac版の対応範囲はRune Studioの商品ページで確認できます。