UTF-8 テキストエディタ BOM確認方法｜BOMあり・なしを二周で見分ける

UTF-8対応テキストエディタでBOMあり・なしを見分けるには、画面に見える本文だけを比べません。同じ一文を二つのファイルへ保存し、先頭3バイト、エディタの判定表示、再保存後の形式を記録します。UTF-8のBOMは先頭のEF BB BFであり、本文が同じに見えてもファイルは同一ではありません。

BOMは本文の先頭に置かれる識別用バイト

UTF-8 BOMは16進数でEF BB BFの3バイトです。対応アプリでは通常、本文の文字として表示されません。そのため「日本語の原稿です」という一文をBOMありとなしで開いても、見た目だけでは区別できないことがあります。

BOMは文字化けを必ず防ぐ印でも、UTF-8ファイルすべてに必須の印でもありません。受け渡し先がBOMあり・なしのどちらを要求するかに従います。目的は優劣を決めることではなく、現在の形式を保つか変えるかを意識して選ぶことです。

二つの標本を別名で用意する

sample-no-bom.txtとsample-bom.txtを作り、同じ一文「横書きの電子書籍を作る。」だけを入れます。本文、改行、ファイル名以外の条件をそろえます。作成元が形式を指定できるなら、片方をUTF-8 BOMなし、もう片方をBOMありで保存します。絵文字や別の行を足さないのは、二つのファイルで比較する条件を一文に固定するためです。

先頭バイトを確認できる信頼できる手段で、前者が本文先頭から始まり、後者がEF BB BFから始まることを記録します。本文全体をバイナリとして読む必要はありません。先頭3バイトとファイルの識別だけを対応させます。

エディタの判定表示と照合する

それぞれをエディタで開き、表示された文字コード名、BOMの有無、本文の見え方を表へ書きます。本文が同じでも、形式表示が違うのが期待です。判定が表示されないエディタでは、保存ダイアログの初期値や外部の先頭バイト確認を使います。

開いた瞬間に形式を変換しないことが重要です。自動保存がある場合は止めるか複製で試し、観察前にファイルを書き換えないようにします。

再保存テストはコピーで行う

BOMありをBOMなしとして保存したコピー、BOMなしをBOMありとして保存したコピーを作ります。元の二ファイルは残します。保存後に再び先頭3バイトとエディタ表示を確認し、本文の一文、文字数、改行が同じかを読みます。

変換が必要ない場合は、元形式を維持して保存できるかを確かめます。共同作業や変換工程では、内容の変更がなくてもBOM差だけで差分が出ることがあります。プロジェクトの規則を一つに決めます。

一条件だけ変えて二周の差分を記録する

正本の二ファイルを固定したら、最初の一周でsample-no-bom.txtとsample-bom.txtのファイル名、先頭3バイト、文字数、改行数、エディタの表示、保存形式を記録します。本文は同じ一文「横書きの電子書籍を作る。」であり、BOMの有無だけが異なる状態を出発点にします。どちらかを開いただけで判定を終えず、二ファイルを同じ欄へ並べます。

二周目は、正本ではなく作業コピーの一条件だけを変更します。具体的にはsample-no-bom.txtのコピーだけを「UTF-8 BOMなし」から「UTF-8 BOMあり」へ変更して保存し、本文、改行、ファイル名、開くエディタは変えません。保存後に同じ先頭3バイト、文字数、表示、形式を再確認します。BOMの有無以外まで変わった場合は、一条件変更にならないためその時点で停止します。

初回と二周目は次の記録単位で比較します。結果が取れていない欄は「未確認」と書き、見た目が同じことだけで採否を決めません。

採用できるのは、変更した条件がBOMの有無だけで、本文・文字数・改行・ファイル識別を別欄で説明できる場合です。どの条件を変えたか不明、二周目だけ別の一文を使った、初回の記録がない、または停止理由を残していない場合は、結果がよく見えても採用しません。この二周比較は実測成功を約束するものではなく、同じ標本で判断を再現するための記録手順です。

Rune Studioで確認できる範囲

現行Mac版Rune Studioの資料では、ファイル先頭のBOMを最初に検出し、UTF-8 BOMなしとUTF-8 BOMありを扱うことが記載されています。文字コード表示と保存時の形式選択も機能範囲です。

これは資料を照合した機能範囲の説明で、この二標本の操作を完遂した実測ではありません。BOMを見れば内容が正しい、任意の受け渡し先に適合する、文字化けが必ず直るとは断定しません。

受け渡し先の要件で決める

プログラム、組版、投稿システム、共同編集者の指定を確認します。指定がなければ、既存プロジェクトの形式を維持し、混在を増やさない判断が実務的です。新規ファイルだけ別形式にすると、同じフォルダ内で差が見えにくくなります。

表にはファイル名、先頭3バイト、エディタ判定、保存形式、受け渡し要件を残します。これで「見た目は同じ」という説明から、一意に確認できる記録へ変わります。

チーム内で規則を決める場合は、新規作成、既存ファイルを編集、外部から受領、外部へ納品の四場面を書き分けます。新規はBOMなしでも、取引先から受け取ったBOMありを維持する運用はあり得ます。一律変換するなら、対象一覧と変換前コピーを残します。

差分レビューでは本文変更とBOM変更を別にします。同じコミットや受け渡しで両方を行うと、文字修正が形式差に埋もれます。先に形式だけを確定し、その後で本文を編集するか、本文編集後に形式を変えた理由を明記してください。

検査日も添えます。

納品時はファイル単位の検査値を渡す

複数ファイルを渡す場合、代表一件だけでなく各ファイルのBOM有無を記録します。フォルダ内で新規原稿だけBOMなし、旧稿だけBOMありという混在が起きるためです。納品一覧にファイル名、バイト数、先頭3バイト、エディタ表示を置けば、受領側は本文を変更せず形式だけ照合できます。

結論：先頭3バイトと表示を二周で確認する

UTF-8のBOMあり・なしは、本文画面ではなく、EF BB BFとエディタの判定表示で見分けます。元ファイルを残してコピーを相互変換し、再保存後の先頭と本文を確認してください。

現行Mac版の文字コード判定・保存範囲は、Rune Studioの商品ページで確認できます。