Edit

Page

Page title:

Page body:

[11] 「大きいもの順」と「小さいもの順」の違いを、[DFN[[RUBYB[エンディアン]@en[endian]]]]といいます。

* 種別

[13] 大きいもの順を[[[RUBY[大][ビッグ]]エンディアン][大エンディアン]]、
小さいもの順を[[[RUBY[小][リトル]]エンディアン][リトルエンディアン]]といいます。

;; 「[[ネットワークバイト順]]」のような専用の呼び名がある場合もあります。

[23] 
3つ[[以上]]の構成要素があるとき、大でも小でもない種別が出てきます。

[24] 
[[UCS-4]]

[FIG(quote)[
[FIGCAPTION[
[21] [CITE@ja[エンディアン - アンサイクロペディア]]
([TIME[2023-07-11T21:45:44.000Z]], [TIME[2023-08-09T02:08:07.267Z]])
<https://ja.uncyclopedia.info/wiki/%E3%82%A8%E3%83%B3%E3%83%87%E3%82%A3%E3%82%A2%E3%83%B3>
]FIGCAPTION]

> リトルエンディアン、日/月/年の順。ヨーロッパ 使用されている。
> ビッグエンディアン、年/月/日の順。おまえら生まれた(だよね?)日本 使用されている。
> ミドルエンディアン、月/日/年の順。俺たちの国 使用されている。大絶賛。

]FIG]

[8] >>6 両エンディアン対応を ''[RUBY[bi-endian] [バイ・エンディアン]]'' と呼ぶそうです。例えば [[MIPS]] [[マイクロプロセッサ]]はバイト順について bi-endian です。

* 文脈

[12] [[エンディアン]]は、次のようなものに存在します。

[FIG(list short)[
- [[地名]]
- [[人名]]
- [[ビット順]]
- [[バイト順]]
- [[位取り記数法]]
- [[ドメイン名]]
- [CODE(HTMLe)@en[title]] [[要素]]の[[内容]]
- [[日付]]
- [[RDN]]
]FIG]

[14] [[エンディアン]]と呼ばれる対象をみると、
一連なりのものをそれより大きな単位に詰め込むときにどちら向きに並べるか、という問題と、
階層的な分類を使って識別するときに大分類と小分類のどちらから並べるか、という問題の2種類に大別できそうですね。

[25] 
分類パターンではどの[[エンディアン]]を選ぶかに、[[自然言語]]における[[修飾語]]の前置、後置が強く関係しているようですが、
それだけでもなく事情は個々に複雑です。

[FIG(list)[ [26] [[エンディアン]]と似たような[[順序]]問題

- [27] 和式の[[履歴書]] (古い順) と洋式の[[職務経歴書]] (新しい順)
- [28] ニュースとアンチニュース, [[ChangeLog]]; 変更履歴
- [29] [[論文]]の[[共著者]]の[[名前][人名]]

]FIG]

* バイト順

[SEE[ [[大エンディアン]], [[小エンディアン]] ]]

* ビット順

[REFS[
[FIG(quote)[
[FIGCAPTION[
[1] [CITE@en[RFC 1951 - DEFLATE Compressed Data Format Specification version 1.3]]
([TIME[2016-07-03 09:57:20 +09:00]])
<https://tools.ietf.org/html/rfc1951#section-3>
]FIGCAPTION]

>       Bytes stored within a computer do not have a "bit order", since
>       they are always treated as a unit.  However, a byte considered as
>       an integer between 0 and 255 does have a most- and least-
>       significant bit, and since we write numbers with the most-
>       significant digit on the left, we also write bytes with the most-
>       significant bit on the left.  In the diagrams below, we number the
>       bits of a byte so that bit 0 is the least-significant bit, i.e.,
>       the bits are numbered:
>          +--------+
>          |76543210|
>          +--------+

]FIG]

- [15] [CITE@en[RFC 1950 - ZLIB Compressed Data Format Specification version 3.3]] ([TIME[2017-09-17 17:15:13 +09:00]]) <https://tools.ietf.org/html/rfc1950#section-2>
- [16] [CITE@en[RFC 1952 - GZIP file format specification version 4.3]] ([TIME[2017-09-17 16:34:04 +09:00]]) <https://tools.ietf.org/html/rfc1952#section-2>
]REFS]

* 関連

[SEE[ [[整列]], [[昇順]], [[降順]] ]]

* メモ

[10] 卵は丸い方ととがった方と、どっちが上だと思いますか。

- [1] あるいは、どちらで殻を割りますか。どちらを先に食べますか。
- [2] [[ガリバー旅行記]]で[[ガリバー]]が漂流した小人国では、太い (丸い) 方だという意見と細い (とがった) 方だという意見が対立しており、[[戦争]]まで勃発してしまいますた。
- [3] さて、大きい方と答えたあなたは[[大エンディアン]], 小さい方と答えたあなたは[[小エンディアン]]がお好きなようです。
- [4] ちなみに、ガリバー旅行記では ''endian'' は ''end-ian'' と書かれていたそうです。すなわち語源は ''end'' (端) ''-ian'' (な人) だったわけです。
- [5] ここから転じて、[[重み]]がある方が先なのが[[大エンディアン]], 重みの小さい方が先なのが[[小エンディアン]]と呼ばれるようになりました。
- [6] 特に[[計算機]]の世界では、複数[[バイト]]のデータを扱う時の方法をエンディアンと呼ぶことが多いです。
- [7] この他例えば、[[住所]]を''国名''から''[[番地]]''に向かって書くのを大エンディアン, ''番地''から''国名''に向かって書くのを小エンディアンと言ったりもするみたいです。

- [9] バイト順問題は[[プログラマ]]を悩ませてきましたが、 [[UCS]] や [[TRONコード]]で問題が[[文字コード]]層に波及するに至って悲劇的なことになってます。 [[BOM]] の登場でバイト順非依存の[[文字コード]]なども被害を受けています。

[17] [CITE@ja[JSFさんはTwitterを使っています: 「227 батальйону 127 бригади これは第127旅団の第227大隊という意味。日本語と違って小さな方が先に来る。」 / Twitter]]
([TIME[2022-05-15T05:18:25.000Z]], [TIME[2022-05-16T01:20:42.907Z]])
<https://twitter.com/rockfish31/status/1525943469952249857>

[18] [CITE[3.6 図形描画セグメント]], [TIME[2011-01-26T00:45:20.000Z]], [TIME[2022-08-25T14:15:06.898Z]] <http://www.chokanji.com/developer/doc/btron3/shared_data/tad3.html#aev>

> TADデータ構成では、 異なるプロセッサ間を含めたデータの互換性を完全に保証するために8ビット以上のビット長を持つデータのバイトオーダーは、 上位バイトが先にくるビッグエンディアン形式に統一している。
>
しかしながら、この形式はリトルエンディアン形式の CPU 上で動作する既存のアプリケーションを移植する場合等には負担となる場合もあるため、 これを救済するために、 リトルエンディアンのデータ形式を持つTADデータ構成を、 準TAD規格として規定する。

[19] [CITE[第4章 フロッピーディスク形式]], [TIME[2011-01-26T00:45:12.000Z]], [TIME[2022-08-25T14:20:06.724Z]] <http://www.chokanji.com/developer/doc/btron3/shared_data/fd_format.html#agh>

> TRON 標準フロッピーディスク形式では、 異なるプロセッサ間を含めたフロッピーディスクの交換を完全に保証するために 8 ビット以上のビット長を持つデータのバイトオーダーは、 上位バイトが先にくるビッグエンディアン形式に統一している。
>
しかしながら、 この形式はリトルエンディアン形式の CPU 上で動作する BTRON では負担となる場合もあるため、 これを救済するために、 リトルエンディアンのデータ形式を持つフロッピーディスク形式を、 準標準フロッピーディスク形式として規定する。

[20] [CITE@ja[Terrible MapsさんはTwitterを使っています: 「Road distances order in Europe https://t.co/wdLhjONk9a」 / Twitter]], [TIME[午前8:45 · 2022年12月28日][2022-12-27T23:45:38.000Z]], [TIME[2023-01-01T09:33:14.000Z]] <https://twitter.com/TerribleMaps/status/1607885446855512065>

[22] 
[[エンディアン]]的めんどくささの別の例として[[座標系]]の[[Y軸]]が上向き、下向き、ってのもある。
三次元 ([[3DCG]] など) だとこれを[[右手系]]、[[左手系]]とか言っている。

- [30] [CITE@ja[Xユーザーのスドー🍞さん: 「東京地裁は「民事第1部」のように数字を後置するが、大阪地裁は「第1民事部」のように前置する。京都地裁は「第1民事部」、名古屋地裁は「民事第1部」派なので、三重か滋賀あたりに境界線があるものと思われる」 / X]], [TIME[午後0:06 · 2025年3月7日][2025-03-07T03:06:30.000Z]], [TIME[2025-03-07T04:33:21.000Z]] <https://x.com/stdaux/status/1897846292098830809>
-- [31] [CITE@ja[Xユーザーの瀬戸内ジャクソン🍥さん: 「@stdaux 大分は、何故か東京方式なんです。左陪席の方が真面目に由来を調べていましたが…。 原告・被告の座る位置(右側・左側)も、地裁によって違う気がします。不思議ですね。 https://t.co/PUfpxHjYBG」 / X]], [TIME[午後1:04 · 2025年3月7日][2025-03-07T04:04:56.000Z]], [TIME[2025-03-07T04:33:21.000Z]] <https://x.com/ikuzamu/status/1897860995802144927>

Historical Legal Sensitive Parent: [Help / License]

Edit

Page

Errors

Page name(s)