Unicode 入門の記事 に対するコメントで おこめ さんから「BOM 付きの場合単に UTF-8 と呼び、BOM なしの場合 UTF-8N と呼ぶ」のは間違いだというツッコミがありましたので、自分自身の理解を整理するためにも再度調査してみました。
まず、ja.wikipedia.org によりますと、
BOMありの方をUTF-8、なしの方をUTF-8Nと呼ぶこともあるが、このような呼び分けは日本以外ではほとんど知られておらず、また公的規格などによる裏付けもない。
http://ja.wikipedia.org/wiki/UTF-8
とされています。
また、unicode.org の FAQ のページによると、
Q: Can a UTF-8 data stream contain the BOM character (in UTF-8 form)? If yes, then can I still assume the remaining UTF-8 bytes are in big-endian order?
A: Yes, UTF-8 can contain a BOM. However, it makes no difference as to the endianness of the byte stream. UTF-8 always has the same byte order. An initial BOM is only used as a signature — an indication that an otherwise unmarked text file is in UTF-8. Note that some recipients of UTF-8 encoded data do not expect a BOM. Where UTF-8 is used transparently in 8-bit environments, the use of a BOM will interfere with any protocol or file format that expects specific ASCII characters at the beginning, such as the use of "#!" of at the beginning of Unix shell scripts. [AF] & [MD]
http://unicode.org/faq/utf_bom.html#bom5
とのことで、拙訳・要約すると
- UTF-8 でエンコーディングしたデータストリームに BOM を含めることは可能。（もちろん、含めなくてもよい）
- ただし、BOM をつけると、ASCII 文字だけを期待しているプロトコルとかファイルフォーマットには使えなくなる。（たとえば、Unix のシェルスクリプトの先頭の #! (sheban) とかが BOM の後になってしまうので BOM をつけてはいけない）
とのことですので、本来の意味としては、BOM の有り無しにかかわらず UTF-8 と呼ぶのが正しいようです。
つまり、元記事に対するおこめさんの指摘どおり、「BOM 付きの場合単に UTF-8 と呼び、BOM なしの場合 UTF-8N と呼ぶ」のは正しくないようです。
実用上の意味を考えると、特にテキストエディタでファイルを保存したりするときに、BOM をつけるかつけないかを制御できたほうがうれしいと思いますが、それは UTF-8N という呼称を使うかどうかはまた別次元の問題ですしね。
ここで俄然興味がわいてきたのが、UTF-8N という呼称を誰が使い始めたのだろう？ということです。
http://suika.fam.cx/~wakaba/wiki/sw/n/BOM
によると、「Unicode Consortium のそれなりに偉い人（誰かは忘れた）」だそうですが・・・
以下、話題はそれて。
そもそも UTF-8 に BOM をつけること自体に対して賛否両論があるように感じますが、それぞれの主張は主に以下の点にあるようです：
賛成：
- フォーマットの識別が容易になる
（先頭の3バイトを読むだけで、UTF-8 でエンコーディングされているとみなすことができる） - ASCII 文字しか含まれないデータであっても、UTF-8 であることを明示できる
（後の修正でデータに ASCII 範囲外の文字が含められてしまっても、エンコーディングを気にする必要がない）
反対：
- ASCII 文字しか使用しない場合に ASCII と完全に一致するというメリットを捨てることになる
私個人としては、BOM をつけられる場面ではなるべくつけておくべき（特にテキストファイルの場合）と思います。
というのも、仕事上で以下のようなことがあったからです：
- ソフトウェア開発プロジェクトで、バージョン管理システムや統合開発環境、その他ツールとの相性を考えて、ソースコードはすべて UTF-8 で保存するようにルールを決定した。
- ある小さなソースコードには日本語がまったく含まれず、BOM なしの UTF-8 で保存したところ、次回そのファイルを開いたときにテキストエディタによってエンコーディングは ASCII と判断された。
- そのことに気づかないままそのソースコードを編集し、ASCII 以外の文字（日本語など）が含まれた状態で上書き保存した。このとき、テキストエディタは日本語 Windows のデフォルトエンコーディングである Shift-JIS (CP932) で保存した。
- そのファイルを Subversion リポジトリにコミット、日本語版以外の Windows や、Linux を使用している開発者の環境でそのファイルをチェックアウトして開いたところ、文字化けが発生。
もし、BOM なしではなくて BOM ありの UTF-8 でファイルを保存していたとしたら、2. の段階で UTF-8 として開きなおされるはずなので、このような問題が起こらなかったはずです。
これが、上のリストで「後の修正でデータに ASCII 範囲外の文字が含められてしまっても、エンコーディングを気にする必要がない」と書いた理由です。
上記は UTF-8 でエンコーディングする側の論理ですが、UTF-8 を読み取る側のプログラムを書いたりしている人は、BOM をつけてもつけなくても UTF-8 であると決まっている以上、つべこべ言わずにどちらの場合にも対応しなければならないでしょう。
結局のところ送り手は謙虚に、受け手は寛容に、という Postel 則がここにもあてはまりそうです。
[追記 2008.01.05]
はてブで
「#!が動かなくなる害」＞＞＞＞＞＞＞＞＞「文字化け」と思う。見りゃ分かる害と、見てすぐ分からない害では後者の方が深刻
というツッコミをいただきました。
確かにそのような考え方もありますね。（というか、僕自身それでハマったことがある気がします）
vim では EF BB BF が入っていると <feff> って表示してくれたり、他のエディタでもいろいろサポートしてくれるので、開いてみれば気づくといえば気づくのですが・・・これは反論としては弱いですね。（むしろ、vim がそうやってあからさまに表示してくれるというのは、この問題にハマる人の多さを物語っているような気もします）
/bin/sh なりのインタプリタ(?)が、U+FEFF 付きの UTF-8 にも寛大に対応してくれればみんながハッピーになれる気がするのですが、そうなっていないのはやっぱり UTF-8 に U+FEFF が付いているのは邪道だということでしょうかね。
それとも、何か他の理由があるのかな・・・？