ノート:エンディアン
最新のコメント：5 年前 ｜ トピック：C言語の処理系定義について | 投稿者：2409:11:1201:E300:5C24:9D1C:B0FB:9798
バイトオーダーマークの説明で，
> バイトオーダーマーク (BOM) と呼ばれる特殊なコード (0xFEFF) が予約されており
とありますが，U+FEFF はバイトオーダーマークとして定義されているわけではなく，あくまでもアラビア系文字の中で用いる ZERO WIDTH NO-BREAK SPACE でしょう。U+FEFF が存在するのに対し，U+FFFE は存在しないので，U+FEFF を入れておけばバイトオーダーが判別できるだろうということではないでしょうか。
- UTF-16、UTF-32において、U+FEFFをストリームの冒頭に配置することによるバイトオーダーの明示は規格化されています。ZERO WIDTH NO-BREAK SPACEとして用途では、語の間に用いるのが当然で、文書の頭に表れることはあり得ない、ということからバイトオーダーマーク（以下BOM）としての使用も定義されたわけです。U+FFFEを予約し、そこに文字を定義しないと決定したのも、BOMとしての利用も目的としていたためです。そして、エンディアンを予め規定した交換方式であるUTF-16BE/LE、UTF-32BE/LEなどにはBOMの使用は禁止（もしあってもBOMとして扱わない）であるわけですが、冒頭U+FEFFが現れた場合でも、ZERO WIDTH NO-BREAK SPACEであれば、何らの表示上、意味上の問題も発生し得ないということも期待しての多重定義となっています。単に、そのように使えるから、アプリケーションレベルやユーザーレベルで独自に転用してきて文化が生まれた、というような話ではありません。
- また、Unicode 3.2においては、U+FEFFがBOM、および、ZERO WIDTH NO-BREAK SPACEの両方として使われる、多重定義状態にあることを問題とし、U+2060“WORD JOINER”が追加されました。BOMとして使わない場合、すなわちZERO WIDTH NO-BREAK SPACEとしての機能を期待する場合、こちらを用いることが強く推奨されることになったようです。これをして、U+FEFFは専ら、BOMとしての利用を推奨されることになります。
- --220.9.188.2 2015年10月24日 (土) 02:18 (UTC)
バイトオーダーについて 編集
バイトオーダーが存在せず、エンディアンと同義なので
バイトオーダーをリダイレクトページにさせてもらいました。
C言語の処理系定義について 編集
C言語の union による例で処理系定義とありますが、C99以降では違うのではないでしょうか? type punning や strict aliasing について調べていたときに、C99以降は変わったというような記述を見ました。 (ちゃんと調べたわけではないので確証はないです) --2409:11:1201:E300:5C24:9D1C:B0FB:9798 2018年8月16日 (木) 16:17 (UTC)