文字コードのUTF-8について、BOM無しと、BOM付き、というのがあったのですが、具体的に、どう異なるのでしょうか?

分かりやすく説明いただけますと嬉しいです。
よろしくお願い致します。

回答の条件
  • 1人5回まで
  • 13歳以上
  • 登録:2010/03/27 17:23:29
  • 終了:2010/04/03 17:25:03

回答(7件)

id:uzakadeu No.1

uzakadeu回答回数1ベストアンサー獲得回数02010/03/27 17:39:38

ポイント18pt

BOM付き(UTF-8)の場合、先頭に三バイトのBOMを付加してあります。BOMは具体的には0xEF 0xBB 0xBF です。

BOM無し(UTF-8N)にはこの三バイトが付きません。

id:comcom9

ありがとうございます。

2010/03/28 16:53:56
id:ardarim No.2

ardarim回答回数892ベストアンサー獲得回数1422010/03/27 17:46:52

ポイント17pt

BOM=バイト順マーク(Byte Order Mark)は、文書ファイルの先頭に付ける EF BB BF という3バイトのバイナリデータです。ファイルの文字コード(符号化方式)が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...

id:comcom9

ありがとうございます。

2010/03/28 16:53:59
id:anoncom No.3

あのん回答回数16ベストアンサー獲得回数22010/03/27 17:51:40

ポイント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無しの両方の形式が存在しているようです。

id:comcom9

ありがとうございます。

2010/03/28 16:54:13
id:ko8820 No.4

ko8820回答回数1221ベストアンサー獲得回数692010/03/27 18:02:57

ポイント17pt

ファイルの先頭に挿入するBOM(Byte Order Mark)です。

ファイルの先頭だけ違います。

http://www.nishishi.com/blog/2007/05/unicode_bom.html

id:comcom9

ありがとうございます。

2010/03/28 16:54:19
id:Bombastus No.5

ホーエンハイム回答回数409ベストアンサー獲得回数522010/03/27 20:00:48

ポイント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が主流になっていきます。

id:comcom9

ありがとうございます。

2010/03/28 16:54:22
id:uehaj No.6

uehaj回答回数158ベストアンサー獲得回数152010/03/27 20:57:53

ポイント17pt

BOMの話をする前に、まずは「バイトオーダー」というものについて理解する必要があります。

現在使われているコンピューターは、データの記憶装置(メモリやファイル)上への保持の論理的な最小単位が1バイト(=8ビット)です。なので、記憶装置上では、すべてバイトの列として扱う事になります。

すべてのバイトには、それぞれユニークな位置(アドレス)が結びついており、隣り合ったバイトではアドレスが1ずつ増えていきます。

  • バイト1 →アドレスn
  • バイト2 →アドレスn+1
  • :

と言った具合です。処理するデータは、それぞれのバイトに格納されており、アドレスを指定してデータを読み取ったり書き込んだりします。


さて、話がこれだけなら単純なのですが、問題なのは,コンピュータが扱うデータの大きさは、1バイト(8ビット)で収まらない事が多いということです。


たとえば、255を越える整数は1バイトに収まらないですし、ASCIIではない、日本語などを含む文字1つを表すにも、1バイトでは足りません。


どうするかというと、もちろん複数のバイトを使うのです。いくつかのバイトを合わせて、1つのデータを表現します。


2バイト(16ビット)あれば、0から65535までの符号無し整数を表現できますし、あるいは-32768から+32767の符号付き整数を表す事ができます。1バイトで256通りの数をあらわせるのだから、2バイトなら256x256とおりの数を表すことができるというわけです。これは、0から9までの数字を1つ使えば0から9までの数(つまり10とおり)が、2つつかえば、00から99までの数(つまり10x10=100とおり)が表せるという事と同じです。


このように、2つ(もしくは複数)のバイトを使って数値をあらわすとき、上位の桁を表すバイトを「上位バイト」と、下位の桁を表すバイトを「下位バイト」と呼びます。


さて、ここまでは良いでしょう。


問題は、2バイトのサイズが格納に必要なデータを、2バイトで表してメモリ上に保存しようとするとき、バイトの列であるメモリにその2バイトをどうやって並べるかです。


  • (案1)上位バイト、下位バイトの順序に並べる
  • (案2)下位バイト、上位バイトの順序に並べる

この2の方針のうち、どっちが正しいでしょうか。明らかでしょうか? いや、この問題は、それほど自明ではないのです。


わたしたちは普通、数字を紙に書くとき、たとえば78という数字を書くとき、7を書いてから、その次に8を並べて書きます。つまり、案1に従っています。


なので、コンピューターも(案1)に従えばいい、というのは確かに一つの見識です。


でも(案2)には捨てがたいものがあるのです。たとえば、足し算をするときには、下の桁から足していって、繰り上がりとか計算しますよね。(案2)の方が計算順序通りに並んでいるので都合が良い。また、「アドレス」でこの2バイトの値をポイントしようとすると、先頭バイトを示すのですが、(案2)であると、アドレスから下位1バイトが何か、をすぐに知る事ができます。コンピューターでは、数値がある範囲を超えたら切り捨てる計算をする事が良くあるのですが、たとえば、256を越えたら0に戻るような計算をするときがあるのですが、複数バイトからなるデータを表すときに、データの先頭アドレスが下位バイトを指していると、その先を「何バイトの整数と見て取り出すか」で切り捨て処理をおこなっていることになり、(多少)都合が良いのです。


ということで、コンピューターの世界では、結局この2つの流儀がまかり通る事になっています。これらをバイトオーダー(バイト順序)の問題と呼びます。


ちなみに(案1)をビッグエンディアン、(案2)をリトルエンディアンと呼びます。これはガリバー旅行記に出てきた、「ゆでたまごを太い方から食べる流儀の人々」と、「細い方から食べる人々」がそれぞれそう呼ばれていた事に由来するそうです。「どっちでもいいのに、とことんこだわって妥協しない事」を揶揄した、ユーモアの或る呼び方ですね。


なお、歴史的には、この2つの流儀は、CPUのメーカによる流派でもありました。つまり、インテル(8080,8086,..)はリトルエンディアン派、モトローラ(MC6800系)はビッグエンディアン派です。細かいことを言うとさらにいろいろあるのですが割愛します。


ここまでをまとめると、複数のバイトで表現しなければならない整数データをバイト列として保存する際には、上位からならべるか、下位から並べるか、といった方針を決めなければならないということです。また、その方針は、1台のコンピュータ上で処理が完結しているならあまり問題にならないのですが、複数のコンピュータ間でデータ交換を行う場合です。データを作成した側と、データを読み取る側で、その方針が一致していなければ,正しいデータを読み取る事は不可能です。


このような、コンピューター間でデータをやり取りする際に、バイトオーダーの問題をどう解決するかですが、


  • (案A)決める。例えば、「案2」を「ネットワークバイトオーダー」と名付け、通信ではこれを使うのだと決める。TCP/IPの通信の世界ではこうやっています。あるいはDOSのファイルではこうだとかプロトコルやフォーマットとして決めます。
  • (案B)データ中に、どっちの順序を使っているかを示すマーカーを含め、それをデータ自体と合わせて送受信し、データの読み取り処理はそれに合わせて変化させる。

ここまで説明すると、結論は言わずとも明らかだと思いますが、いちおう本題に戻ります。


Unicodeの文字集合の文字データは、まさしく8ビットで収まらないデータであるわけですが、これをどっちの順序(ビッグエンディアン、リトルエンディアン)で保存しているかをデータの始まりに書いておこう、という方式があります。それがどっちかを表すマーカーデータが、バイトオーダーマークであります。

id:comcom9

ありがとうございます。

2010/04/01 11:41:21
id:kmymt No.7

Komi回答回数3ベストアンサー獲得回数12010/03/29 18:15:00

ポイント17pt

このファイルは、UTF-8だよーという情報がある。->BOMあり

上記のような情報がない -> BOMなし

id:comcom9

ありがとうございます。

2010/04/01 11:41:24

コメントはまだありません

トラックバック

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません