UTF-8
Microsoft Visual C++は既定でBOMなしUTF-8を認識せず、システムロケール設定に応じたマルチバイトエンコーディングとみなすが、Visual C++ 2015以降ではコンパイルオプションを指定することでBOMなしUTF-8を認識することができるようになった。 Windows 10のメモ帳アプリは、2019年の19H1アップデートからBOM無しUTF-8がデフォルトになった。
また、BOMがなくともエンコード自動推定によってUTF-8とShift_JISなどを区別することのできるプログラムもあるが、ASCII部以外の文字が少ない場合に誤認することが多い。
プロトコルが常にUTF-8であることを強制しているものである場合はこのシーケンスを禁止するべきで、この場合ファイル先頭にこのシーケンスが現れると “ZERO WIDTH NO-BREAK SPACE” と見なされる。逆にプロトコルがそれを保証しない場合このシーケンスは禁止されずファイル先頭のそれはバイト順マークと見なされる。
第1バイトがEDのときに第2バイトがA0以上となるものはサロゲートペアのための符号位置にあたり、また同F4のときに90以上となるものはUnicodeの範囲外となるため、UTF-8ではやはり許されない。
Unicodeの符号位置を2進表記したものを、上のビットパターンのx, yに右詰めに格納する(最少のバイト数で表現するため、yの部分には最低1回は1が出現する)。符号化されたバイト列は、バイト順に関わらず左から順に出力する。
1バイト目の先頭の連続するビット "1"(その後にビット "0" が1つ付く)の個数で、その文字のバイト数がわかるようになっている。また、2バイト目以降はビットパターン "10" で始まり、1バイト目と2バイト目以降では値の範囲が重ならないので、文字境界を確実に判定できる。すなわち、任意のバイトの先頭ビットが "0" の場合は1バイト文字、"10" の場合は2バイト以上の文字の2番目以降のバイト、"110" の場合は2バイト文字の先頭バイト、"1110" の場合は3バイト文字の先頭バイト、"11110" の場合は4バイト文字の先頭バイトであると判定できる。
7バイト以上の文字は規定されないため、0xFE, 0xFFは使用されない。このため、バイト順マーク (BOM) に0xFEと0xFFを使用するUTF-16やUTF-32が、UTF-8と混同されることはない。