分かりやすく説明いただけますと嬉しいです。
よろしくお願い致します。
No.1
1
0
18pt
BOM付き(UTF-8)の場合、先頭に三バイトのBOMを付加してあります。BOMは具体的には0xEF 0xBB 0xBF です。
BOM無し(UTF-8N)にはこの三バイトが付きません。
No.2
897145
17pt
BOM＝バイト順マーク（Byte Order Mark）は、文書ファイルの先頭に付ける EF BB BF という３バイトのバイナリデータです。ファイルの文字コード（符号化方式）がUTF-8であることを明示するために付ける場合があります。
BOM付きかBOM無しかはファイルの先頭にBOMデータを付けるか、付けないかが異なるだけで、ファイルの内容そのものや、文字コード（符号化方式）自体は同じUTF-8であって違いはありません。
但し、アプリケーションによってはBOM付きでないとUTF-8として認識できないもの、あるいはBOM無しでないとファイルを正しく取り扱えないものも存在しますので、アプリケーションや用途によって使い分ける必要があります。
いちおうWikipediaもリンクしておきます。
http://ja.wikipedia.org/wiki/UTF-8#.E3.83.90.E3.82.A4.E3.83.88.E...
ありがとうございます。
No.3
162
17pt
http://ja.wikipedia.org/wiki/%E3%83%90%E3%82%A4%E3%83%88%E3%82%A...
BOMというのが、Byte Order Markの略で、
BOM付きというのは、そのファイルを読み込むプログラム側に「このファイルは文字コードがUnicodeのUTF-8形式で書かれてますよ」と、事前に通知してあげる状態のことを言います。
そのために、ファイルの先頭に目に見えない形で約3バイトほどのデータを付加しています。これがBOMです。
一方BOMなしというのは、この情報を付加しない形のものとなります。
BOMなしの場合、ファイルを処理するプログラムによっては文字エンコーディングがUTF-8なのか、UTF-16、UTF-32なのか、はたまた別の文字エンコーディングなのか判別がつかず、文字化けを起こしてしまう可能性があります。
そういう場合にはBOM付きで保存すると、文字エンコーディングを正しく判別することが出来て文字化けを防ぐことが出来ます。
ただ、必ずしもBOMをつければ良いというわけではなく、このBOMが原因となって逆にプログラムなどが正しく動作しなくなることもあるようです。
http://www.revulo.com/blog/20090129.html
上記はBOMが原因でPHPで処理がうまく動作しなかったという話ですが、こういったケースもあるので、BOM付き、BOM無しの両方の形式が存在しているようです。
ありがとうございます。
No.5
40952
17pt
Unicodeの当初の目的は、世界中の文字を16ビットで表すことでした。
ところがここで問題が起きました。
16ビットは2バイトなのですが、コンピュータ内でバイトを並べるには2つの流儀があります。1つはリトル・エンディアンといい、下位8ビットを先に、上位8ビットを後に記述するものです。インテルのCPUがこの方式をとっています。2つめはビッグ・エンディアンといい、下位8ビットを後に、上位8ビットを先に記述するものです。モトローラやSunのCPUがこの方式をとっています。
結局Unicodeは、リトル・エンディアンでもビッグ・エンディアンでも可能とするという選択肢をとりました。
そこで16進数で FEFF というBOM（Byte Order Mark）をテキストの先頭に置くことにしました。プログラムはテキストの先頭を読み取り、FF, FE の順番であればリトル・エンディアン、逆であればビッグ・エンディアンと解釈するようにしたのです。
これがBOM付きテキストです。
一方、BOM無しテキストは当然のことながら文字化けの原因となり、嫌われれました。
その後、Unicodeを16ビットで表すUTF-16(UTF-2)は衰退していき、インターネットの世界ではBOMを必要としないUTF-8が主流になっていきます。
ありがとうございます。
No.6
15815
17pt
BOMの話をする前に、まずは「バイトオーダー」というものについて理解する必要があります。
現在使われているコンピューターは、データの記憶装置（メモリやファイル）上への保持の論理的な最小単位が１バイト（＝8ビット）です。なので、記憶装置上では、すべてバイトの列として扱う事になります。
すべてのバイトには、それぞれユニークな位置（アドレス）が結びついており、隣り合ったバイトではアドレスが１ずつ増えていきます。
と言った具合です。処理するデータは、それぞれのバイトに格納されており、アドレスを指定してデータを読み取ったり書き込んだりします。
さて、話がこれだけなら単純なのですが、問題なのは，コンピュータが扱うデータの大きさは、１バイト（8ビット）で収まらない事が多いということです。
たとえば、255を越える整数は1バイトに収まらないですし、ASCIIではない、日本語などを含む文字１つを表すにも、1バイトでは足りません。
どうするかというと、もちろん複数のバイトを使うのです。いくつかのバイトを合わせて、１つのデータを表現します。
2バイト（１６ビット）あれば、0から65535までの符号無し整数を表現できますし、あるいは-32768から+32767の符号付き整数を表す事ができます。1バイトで256通りの数をあらわせるのだから、2バイトなら256x256とおりの数を表すことができるというわけです。これは、0から9までの数字を１つ使えば0から9までの数(つまり10とおり)が、2つつかえば、00から99までの数(つまり10x10=100とおり)が表せるという事と同じです。
このように、２つ（もしくは複数）のバイトを使って数値をあらわすとき、上位の桁を表すバイトを「上位バイト」と、下位の桁を表すバイトを「下位バイト」と呼びます。
さて、ここまでは良いでしょう。
問題は、２バイトのサイズが格納に必要なデータを、２バイトで表してメモリ上に保存しようとするとき、バイトの列であるメモリにその２バイトをどうやって並べるかです。
この２の方針のうち、どっちが正しいでしょうか。明らかでしょうか？ いや、この問題は、それほど自明ではないのです。
わたしたちは普通、数字を紙に書くとき、たとえば78という数字を書くとき、７を書いてから、その次に８を並べて書きます。つまり、案１に従っています。
なので、コンピューターも（案１）に従えばいい、というのは確かに一つの見識です。
でも（案２）には捨てがたいものがあるのです。たとえば、足し算をするときには、下の桁から足していって、繰り上がりとか計算しますよね。（案２）の方が計算順序通りに並んでいるので都合が良い。また、「アドレス」でこの２バイトの値をポイントしようとすると、先頭バイトを示すのですが、（案２）であると、アドレスから下位１バイトが何か、をすぐに知る事ができます。コンピューターでは、数値がある範囲を超えたら切り捨てる計算をする事が良くあるのですが、たとえば、256を越えたら0に戻るような計算をするときがあるのですが、複数バイトからなるデータを表すときに、データの先頭アドレスが下位バイトを指していると、その先を「何バイトの整数と見て取り出すか」で切り捨て処理をおこなっていることになり、（多少）都合が良いのです。
ということで、コンピューターの世界では、結局この２つの流儀がまかり通る事になっています。これらをバイトオーダー（バイト順序）の問題と呼びます。
ちなみに（案１）をビッグエンディアン、（案２）をリトルエンディアンと呼びます。これはガリバー旅行記に出てきた、「ゆでたまごを太い方から食べる流儀の人々」と、「細い方から食べる人々」がそれぞれそう呼ばれていた事に由来するそうです。「どっちでもいいのに、とことんこだわって妥協しない事」を揶揄した、ユーモアの或る呼び方ですね。
なお、歴史的には、この２つの流儀は、CPUのメーカによる流派でもありました。つまり、インテル(8080,8086,..)はリトルエンディアン派、モトローラ（MC6800系)はビッグエンディアン派です。細かいことを言うとさらにいろいろあるのですが割愛します。
ここまでをまとめると、複数のバイトで表現しなければならない整数データをバイト列として保存する際には、上位からならべるか、下位から並べるか、といった方針を決めなければならないということです。また、その方針は、１台のコンピュータ上で処理が完結しているならあまり問題にならないのですが、複数のコンピュータ間でデータ交換を行う場合です。データを作成した側と、データを読み取る側で、その方針が一致していなければ，正しいデータを読み取る事は不可能です。
このような、コンピューター間でデータをやり取りする際に、バイトオーダーの問題をどう解決するかですが、
ここまで説明すると、結論は言わずとも明らかだと思いますが、いちおう本題に戻ります。
Unicodeの文字集合の文字データは、まさしく8ビットで収まらないデータであるわけですが、これをどっちの順序（ビッグエンディアン、リトルエンディアン）で保存しているかをデータの始まりに書いておこう、という方式があります。それがどっちかを表すマーカーデータが、バイトオーダーマークであります。
ありがとうございます。
1
1
2
2
1
108
108
ありがとうございます。