もう少し、技術的な事を書いて見ましょう。 わおっ、かっこいい～ ... 大丈夫？。
通常、余り、意識しなくて済む 文字コード ですが、
専門的になればなる程、或いは、内部動作まで立ち入れば立ち入る程、
理解していないと大変な事になります。
全ての処理の流れにおいて、文字データは符号化･復号化されています。
その状態を文字コードで記録･処理しています。
文字を符号化するのが、エンコード。 符号を文字化（復号）するのが、デコード。
エンコード･デコードと言うと、マルチメディア（音声や動画）の世界で良く目にする言葉ですが、元は同じ意味ですね。.
文字の符号化の規格が、文字コード規格・文字集合。 文字コード規格を定義（実装）したものが符号化方式。
文字集合と符号化方式の線引きは難しいですね。 文字コードにふたつの意味があると考えればいいのかな。.
さて、前回 ご紹介した あの絵を再び。 windows です。
メモ帳 (Notepad.exe) で、 あいうABC123[改行][文字コードの種類] を入力し、それぞれの指定で保存したものを、
バイナリエディタ (xedit.exe Free Soft) で見たものです。 画像編集ソフトでひとつの画面に纏め注記してますが。.
文字 （0-9&A-F） ひとつ が バイト ひとつ を表します。.
EOF は文字コードではなく、状態です、 念の為。 良く細い目を開けて見て下さい。 データは ひとつも ありません。.
メモ帳 (Notepad.exe) では、自分で作成したファイルの文字コードが何なのか判別出来る仕組みがあります。
ファイル冒頭に BOM (Byte Order Mark) が無ければ、ANSI ( OS で採用言語が日本語なら Shift JIS ) 。
ファイル冒頭に バイナリで FFFE があれば、 Unicode ( UTF-16 LE ) 。
ファイル冒頭に バイナリで FEFF があれば、 Unicode B.E. ( UTF-16 BE ) 。
ファイル冒頭に バイナリで EFBBBF があれば、 UTF-8 。
実際には先頭 2 バイト で区別出来る筈ですが、実装がどうなっているか迄は分りません。(?) 。.
さて、ここで、BOM と言う言葉が出て来ました。
Unicode には、実は UTF-8 も UTF-16 も UTF-32 等もあるのですが、
UTF-8 以外は各々2種類の符号化方式が存在します。
UTF-16 の場合、16 ビットのデータ（ひとつかふたつ）で Unicode を現すのですが、
2 バイト毎のペアになっていて、これの順序が２通りあります。
Unicode の 「 あ 」 は U+3042 ですが、UTF-16 では 30 と 42 のペアになっていて、
この順でメモリ上に置くのを Big Endian (Endianness) （大きい方で終わる）、 他方（ 42 30 の順 ）を Little Endian (小さい方で終わる、つまり逆順）、と呼びます。
上の図で見れば、「あ」 は、夫々の表現で、
Shifｔ JIS 0x82 0xA0、Unicode U+3042 UTF-16(LE) 0x42 0x30、 UTF-18(BE) 0x30 0x42、UTF-8 0xE3 0x81 0x82 。
同じ Unicode でも、UTF-16 の Endian 別や UTF-8 では、皆、違う表現になりますね。
Endian は OS （CPU のアーキテクチャ） の種類毎に、この順序が、決まっていますし、
文字集合は 相互の OS 環境を亘る技術において 既定 されていたりします。
UTF-16 の様に、多バイトで表現される 塊 を扱う上では、その順序が重要になります。
そこで、どういう順で書き込まれているかを判別する為に、BOM が付加されます。 バイトの並びの印 ですね。
さて、BOM が元々は必要無い UTF-8 においても、 付加しているのは、 OS(windows) 上で扱い易くする為ですが、
実は、UTF-8 BOM 無し の形式を要求するものもあるのです。 （ 画像処理ソフト GIMP の script-fu 等 ）
以上が、メモ帳 上での お話 ですが、
それ以外でも、似た様な仕組みです。
基本となる 対象の文字コードがあり、 それ以外を扱う時は 何か 印 を付けています。
印 が BOM になっているとは限らず、数ビットのフラグだったりします。
これは、テキストファイルに限らず、バイナリファイルのテキスト部分（メタデータ等）でも言える事です。
皆、独自のルールを作って、数種類を判別しているか、 さもなければ、全く他を受け入れません。
仕様が公開されたりしていれば、その中で確認しなければなりませんが、 通常は、そこまでは しませんよね。
では、データ保存を担う ファイル と 処理を実行する ソフト・システム に分けて考えましょう。
OS 内部で処理をする場合には、様々な文字コードを ひとつ のものに変換して処理している場合が殆どです。 （例外あり）
変換してしまえば、順序を示す BOM 等は必要なく、 これを省いた形で利用される事もある様です。
様々な形式が混在しなければ、区別の必要は無い ですから。
因みに、windows の内部処理は、基本的には Unicode UTF-16 L.E.（恐らく BOM なし）。
表示･入力に係わる基本部分は、ロケール（地域）指定された言語に応じて、日本語なら Shift JIS が使われます。
そして、ソフトやアプリが要求する 文字コードに合わせた処理が行われる訳ですね。
例えば、開発環境を提供する Visual Studio は UTF-8 が基本です。
何も考えなくても、 ソースコードや設定ファイルは UTF-8 で保存されます。
これらのドキュメントは内部で管理されていますので、 敢えて、標準外のエディタを外部で用いる事は少ないとは思いますが、
文字コードを変更して保存すれば、挙動が可笑しくなる事は容易に想像出来ます。
また、HTML 等の Web 上をやり取りされるものは、UTF-8 が基本です。
ここでの問題は、OS を跨いでファイル類が移動・利用される事です。
通常のドキュメント類では問題が少ないですが、 BOM なし UTF-8 が基本の Linux(Unix) では、問題を起こす場合もある様です。
参考迄に、改行のコードも OS に依存します。
windows では CR+LF、 Linux(Unix) では LF、昔のMacintosh(Mac OS 9 まで)では CR、最近のMacintosh では LF。
windows で HTML をメモ帳で開くと、だらだらと、改行無く、何時までも続いているものがありますが、
これは、別の OS で作成されたもの の証ですね。
ブラウザ上の表示が問題なくても、エディタで開くと読み辛い なんて事もあります。
この様に、通常は余り意識しないで使えている文字ですが、
その中には、制御コードや判別フラグが隠れ棲んでいて、便利に使える様に働いてくれています。
でも、その仕組みは複雑で、一歩、中に踏み込むと、奥の深い世界なのですね。
素人レベルでは、ここ迄で、精一杯。 ぼろが出ないうちに閉幕と致しましょう。 もし、記述に間違いがありましたら、勘弁の程 ... 。.
[2015/05/29] 冒頭の前投稿をリンクへ・URL 変更（語句訂正）
0 件のコメント:
コメントを投稿