テキストエディタのBOM判定で今回答えるのは、「BOMの一般的な見分け方」ではなく、先頭バイトと検出結果を同じファイルの証拠として採用できるかです。先頭が EF BB BF で検出結果がUTF-8 (BOM)ならBOMあり、先頭にその3バイトがなく検出結果がUTF-8ならBOMなしとして採用できます。二つが食い違う場合は、どちらかを都合よく選ばず、判定を保留して保存前へ戻ります。
今回の40行標本では、BOMなし版の先頭が10進数48・49・232（16進数 30 31 E8）、検出結果がUTF-8でした。BOMあり版は239・187・191（EF BB BF）、検出結果がUTF-8 (BOM)でした。どちらも520文字です。二つの観測が一致したため、この組み合わせの判定結果は passed です。BOMを付けるべきか外すべきか、外部の受け渡し先が受理するかは、この合格に含みません。
この判定の中心は「証拠が一致しているか」
本文が同じに見えることや、文字数が同じことは、BOM判定の決め手になりません。今回の判定では、ファイル先頭のバイトを第一の証拠、テキストエディタの検出結果を第二の証拠として扱います。
| 先頭バイト | エディタの検出結果 | この場での判断 |
|---|---|---|
EF BB BF |
UTF-8 (BOM) | BOMありとして採用 |
EF BB BF ではない |
UTF-8 | BOMなしとして採用 |
EF BB BF |
UTF-8または別形式 | 不一致。保存せず保留 |
EF BB BF ではない |
UTF-8 (BOM) | 不一致。保存せず保留 |
この表の目的は、片方の表示をもう片方より優先することではありません。不一致を「たぶんBOMあり」「見た目は読めるから問題なし」と丸めず、別の検査手段へ戻すための停止条件を作ることです。
40行・520文字の二ファイルで合否を決めた
標本は、同じ日本語40行をUTF-8 BOMなしとBOMありで保存した二ファイルです。文字内容をそろえ、BOM状態だけを比較対象にしました。
| 確認項目 | BOMなし版 | BOMあり版 |
|---|---|---|
| 論理行数 | 40 | 40 |
| 先頭3バイト（10進数） | 48, 49, 232 | 239, 187, 191 |
| 先頭3バイト（16進数） | 30 31 E8 |
EF BB BF |
| 検出結果 | UTF-8 | UTF-8 (BOM) |
| 文字数 | 520 | 520 |
BOMあり版は、BOMのバイト列と検出結果が一致しました。BOMなし版も、EF BB BFで始まらず、検出結果がUTF-8で一致しました。ここで重要なのは、BOMなし版の 30 31 E8 を一般的な識別記号にしないことです。この値は標本の本文冒頭に由来します。別の原稿では別の値になります。
同じ520文字という結果は、「BOMが文字数へ加算されなかった」ことをこの標本で確認する補助値です。520という数値だけからBOM有無を逆算することはできません。
不一致なら保存せず、判定対象を固定し直す
判定作業は次の順で進めます。一般的なBOM標本の作り方や相互変換を繰り返すのではなく、観測が食い違ったときの戻し先を固定します。
- 判定対象のファイル名とSHA-256などの識別値を記録し、以後は同じ複製だけを調べます。
- その複製の先頭3バイトを取得し、
EF BB BFか、それ以外かを記録します。 - 同じ複製をテキストエディタで開き、検出結果を別欄へ記録します。
- 二つが上の判定表で一致した場合だけ、BOMあり／なしを確定します。
- 食い違った場合は自動検出を確定値にせず、保存もせず、元の複製を別のバイト検査手段で再確認します。
この順序なら、観測中のファイルと保存後のファイルを混ぜません。BOMを追加・削除して別名保存する操作はSTUDIO-536へ譲り、一般的な二標本の作成と相互変換はSTUDIO-171へ譲ります。
Rune Studioは第二の観測を担う
現行Mac版Rune Studioの公開資料では、UTF-8とUTF-8 BOM付きに対応し、読み込み時にBOMを先に調べてから自動検出へ進む仕様が確認できます。この記事では、その検出結果を先頭バイトとは別の観測として使います。
一方、指定資料からは、Rune Studioの画面で生の先頭バイトを表示する機能を確認できません。したがって、EF BB BFまたは 30 31 E8 は外部のバイト検査結果、UTF-8／UTF-8 (BOM)はRune Studio側の検出結果として分離します。製品表示だけで生バイトを確認したとは書きません。
別の共通Stage 4では、同一短文をUTF-8、Shift_JIS、EUC-JPで各39字、UTF-16LE、UTF-16BEで各40字として検査し、作業タブの設定をUTF-8として再取得しました。この結果は複数文字コードを調べられることの補助証拠であり、今回の40行二ファイルの一致判定を置き換えません。
STUDIO-171と役割を分ける
STUDIO-171は、BOMあり・なしの標本を用意し、見た目、先頭3バイト、エディタ表示、コピーの相互変換まで確認する一般的な見分け方を扱います。
この記事は、その一般手順をもう一度説明する記事ではありません。40行・520文字の実測を使い、バイト証拠と検出表示が一致したときだけ判定を採用し、不一致なら保存せず保留することが中心です。検索者の次の行動はBOMを付け外しすることではなく、観測の一致・不一致を決め、再検査の戻し先を残すことです。
保存方針と外部受理は別の合否
BOMありとなしのどちらが常に正しいとは言えません。受け取り側がBOMを要求するなら付け、禁止するなら外します。条件が不明なら、今回の判定結果を記録したうえで現在値を維持します。
外部サービスや別アプリでの受理、破損済みデータの完全復元、OCR、バイナリ修復は確認していません。誤った復号状態の視覚表示や、その状態からの上書き保存も実行していません。
結論：一致した二つの証拠だけを採用する
テキストエディタでUTF-8 BOMあり・なしを判定するときは、先頭バイトと同じファイルの検出結果を一組にします。EF BB BFとUTF-8 (BOM)、または非BOMの先頭とUTF-8が一致した場合だけ採用します。食い違った場合は多数決にせず、保存せずに判定対象と検査方法へ戻ります。
今回の40行標本では、BOMなしが 30 31 E8／UTF-8、BOMありが EF BB BF／UTF-8 (BOM)、どちらも520文字で、二つの証拠は一致しました。このpassedは判定一致の合格です。BOMの採否、再保存、外部受理は別の確認として残します。現行Mac版の対応範囲はRune Studioの商品ページで確認できます。