UTF-8とUTF-16およびUTF-32について

質問

Unicodeにおける各文字エンコーディングについてですが
なぜ、UTF-16およびUTF-32の文字コードがビッグエンディアンとリトル・エンディアンの二通りの組み合わせを許容できてUTF-8が許容できないのかがわかりませんなぜでしょうか？

回答No.9

Yune-Kichi

# この回答での前提条件：1バイト = 1オクテット = 8ビット

> UTF-8なら2byteのときあるいあは3byteの時などありますが、
> 文字によって符号化時の上位・下位の有無が存在し（2byteの時は上位・下位存在するが、
> じゃあ3byteの時の上位・下位はどうやってきめるのか？決めようがないよね？という意？）整合性がないからというような捉え方ですかね？

整合性云々ではなく，そもそも存在しないのです。

まず，エンコーディングは「何ビット単位のデータか」ということが規定されます。
UTF-8であれば8ビット単位ですし，UTF-16であれば16ビット単位です。
UTF-8で3バイトになるというのは，8ビットのデータが3つ並ぶという意味であって，24ビット単位のデータを扱う，ということではありません。

次に，現実的なデータの取り扱い(メモリや通信等)は「1バイト = 8ビット単位」です。
便宜的に，以下ではこれを「データ取扱単位」と呼びます。

エンディアンは「エンコーディングでの単位データの並び方」を規定するのではなく，「現実的なデータの取り扱い上での8ビットを越えるデータの並び方」の規定です。
UTF-8は8ビット単位のデータを取り扱います。エンコーディングのデータサイズとデータの取り扱いサイズに違いがないため，エンディアンは発生しません。
UTF-16は16ビット単位のデータを取り扱います。なので，16ビット/8ビット=2データ取扱単位をどう並べるか，という2種類のエンディアンが発生します。
UTF-32は32ビット単位のデータを取り扱います。なので，32ビット/8ビット=4データ取扱単位をどう並べるか，という4!=24種類のエンディアンが発生します。現実的にはビッグ/リトルの2種類ですが。

CPUのエンディアンの話を書かれている方がいましたが，UTF-16/32と直接関わりません。
LEであるIntelプロセッサ上でUTF-16 BE/UTF-16 LEのどちらのデータも読み書きできます。
ただ，CPUにエンディアンがある原因は同じ理由で，「現実的なデータの取り扱い上での8ビットを越えるデータの並び方」をどう定めるか，という問題が発生するためです。

補足

>エンディアンは「エンコーディングでの単位データの並び方」を規定するのではなく，
>「現実的なデータの取り扱い上での8ビットを越えるデータの並び方」の規定です。

うーんつまり、兎にも角にも,8bit単位で符号化されるUTF-8にはエンディアンが発生しようが
ないということなのですね。

wikiからだと

>エンディアン (英: endianness) とは、
>多バイトのデータ（即ち基本情報記憶単位を超えるデータ）を
>メモリ上に配置する方式の種類のこと。

本回答の前の回答にも
>さて，最初に書きましたがエンディアンは「2バイト以上の塊」を取り扱う場合の話です。
とありますね。

で、ひょっとすると今回の質問、エンディアン云々以前の問題かもしれませんが
、なぜマルチバイトのデータだと・・・・うーん伝え方が難しいのですが
【あ】なら　　BEの場合　feff3042 となって
LEの場合 fffe4230というバイト列になります。
なぜ　この　30　と　42　という上位のバイト及び下位バイトとよばれる2つのbyteを
前後入れ替えて表現しようとする仕様ができたのでしょうか？

もう当初の質問とはそれてしまいますが・・・・。
もともと気になっていたのはこの部分かもしれません。
確かに　UTF-16の2byteの場合において1byteごと前後入れ替えてもUnicode上の符号位置に復号しても前バイト列の先頭にfeffやfffeと負荷させておいてコンピューターが復元時にそれぞれの並び順の仕様にもとづいて矛盾は
でてこないのでしょうけれど・・・一つの表現というかそもそもUnicode上の符号位置がビックエンディアンで定義付け
しているのだからわざわざリトル・エンディアンなんて仕様つくらなければよかったのにとおもったのですが・・・・
この理由っていったいなんなのでしょうか？
正直wikiにあるメモリ上のアドレス位置がどうのこうのいわれてもC言語の世界になっていてさっぱりわかりません・・・orz。