ビッグエンディアン、スモールエンディアンについて
■ このスレッドは過去ログ倉庫に格納されています
0001youknow
01/08/28 19:26ID:DpjwJkFEintel系PCにおいて、ビッグエンディアン、スモールエンディアン（バイト反転）を考えずに
デバッグ出来るツール、アプリが有ったら教えてもらいたいんですが。
出来れば今の環境で（PowerPCを使わないで）そのような事が出来るのがあったら、教えてください。
よろしくお願いいたします。
0002デフォルトの名無しさん
01/08/28 19:41ID:SizReSeEhttp://www.google.com/search?q=%83X%83%82%81%5B%83%8B%83G%83%93%83f%83B%83A%83%93&hl=ja&lr=
リトルエンディアン-956件
http://www.google.com/search?q=%83%8A%83g%83%8B%83G%83%93%83f%83B%83A%83%93&hl=ja&safe=off
0003名無しさん＠揚げ足
01/08/28 19:46ID:/PUWXyoIhttp://piza.2ch.net/tech/kako/966/966993365.html
0004デフォルトの名無しさん
01/08/28 20:02ID:BlBCjJFw0005デフォルトの名無しさん
01/08/28 20:52ID:WlUgdCDY0006デフォルトの名無しさん
01/08/29 00:45ID:355Pw4a20007nanasi
01/08/31 01:06ID:MTRYrRJsする方法が知りたいぞ。（MMX以上を使用すること）
メモリというかファイル上のビットの並びと、メモリ上での並びが違うから
簡潔には表現できん。むー、修行不足じゃ。
0008nanasi
01/08/31 01:07ID:MTRYrRJsメモリというか
ここはカットして読んでちょ。
0009デフォルトの名無しさん
01/08/31 01:16ID:9rnRfARA0010デフォルトの名無しさん
01/08/31 01:19ID:R3B1Joucbit streamなら little endianの方が楽。
0011nanasi
01/08/31 01:38ID:MTRYrRJs常に下位、上位（のバイト、ワード、ダブルワード）の順番で並ぶ
から、プログラムの処理中では問題ないけれど、ファイルとして
書き出す処理が面倒くさいぞ。スマートじゃない。
PowerPCみたいにリトル⇔ビッグを切替えられればいいのに。
0012デフォルトの名無しさん
01/08/31 01:44ID:R3B1Joucbinary dataままなら write 一発だし。text dataならどっちも
同じようなもんだが。
どう考えても下位バイトが下位アドレスに位置する little endian
の方が素直。IBMと Motorolaいってよし。
0013デフォルトの名無しさん
01/08/31 02:07ID:gv.yve5A???
意味不明
誰か地球語に翻訳ｷﾎﾞｰﾝ
0014デフォルトの名無しさん
01/08/31 02:09ID:6GgGBKtgあまりに明快な気がするが。どこが分からん？
0015nanasi
01/08/31 02:50ID:UDsEqWvwmain(){
FILE *fp;
uint dat = 0x000001B3;
fp = fopen("sample.dat", "w+");
fwrite(&dat, 4, 1, fp);
fclose(fp);
}
とすると、出力されたファイルは
+0 +1 +2 +3
0xB3, 0x01, 0x00, 0x00
となるんだな。ちなみに0x000001B3はMPEGのヘッダだから、こんな
出力では再生されないわけ。実験してみそ。
ちなみにfwrite((char *)(&dat), 1, 4, fp);としても結果は一緒。
世界標準のフォーマットてのはネットワークバイト即ちビッグエイ
ディアンが標準みたいだから、インテルアーキテクチャのPCでは、
リトルエイディアンとビッグエイディアンの変換がどうしても必要っ
てことさね。
もしかしたら、libcの種類によってはよきに計らってくれるかも
しれんが・・・。
0016デフォルトの名無しさん
01/08/31 03:16ID:BUJpHfZI0017デフォルトの名無しさん
01/08/31 03:20ID:R3B1Joucだとしたらたこな仕様だ。
普通なら 4つの byte値として定義するもんだと思うので。
char id[]={0x00,0x00,0x01,0xb3}; でいいのではないか。
まあ、ほかの部分で数値を bigendianで書くって決まってるなら、そこで
変換は必要だけど。
network byte orderはなんであっちに決まったんだろう。IBMの策略か?
BSD unixは VAXだったんだから littleのまま突っ走りそうだけどな。
0018nanasi
01/08/31 03:27ID:UDsEqWvwfwriteで書き出すと、例のごとく0xb3, 0x01, 0x00, 0x00となるわけさ。
メモリ上のビットストリームに書く毎、あるいは出力直前にでもエイディアン
の変換が必要なのよ。多分ビットストリームに書き込む都度変換するのは難し
いよ。
どちらにせよ美しくないやね。
0019デフォルトの名無しさん
01/08/31 04:06ID:R3B1Joucfwrite(id, 1, 4, out) がそうなる環境なんて見たことないぞ...
x86なら memory上での (int)0x000001b3 と (char*){0x00,0x00,0x01,0xb3}
の並びは違うはずだ。普通。
0020nanasi
01/08/31 07:27ID:FxI8Q2HIchar id[]={0x00, 0x00, 0x01, 0xB3};と書いて、fwriteで出力すれば
問題ない。確認した。
しかし、これだとレジスタ上では0x01B30000と表現されるな。
８ビットのデータなら書き込むだけでよいが、それ以下の長さのデータ
ならば、バイトの並びを考慮したシフトルーチンを作らんとダメなのか。
汚いルーチンだ。頭が回らん。もう寝る。
0021nanasi
01/08/31 07:32ID:FxI8Q2HI0022デフォルトの名無しさん
01/08/31 12:00ID:9rnRfARAよく理解したいからだれか説明してちょ。
0023デフォルトの名無しさん
01/08/31 21:28ID:u3gTIGB2普通、８の倍数ｂｉｔで考えないか？
0024デフォルトの名無しさん
01/08/31 22:15ID:SYzSjnwsつーかネタ？
0025デフォルトの名無しさん
01/09/01 00:08ID:DNDtPrBsお前が解って無いに100ﾘﾗ
0026デフォルトの名無しさん
01/09/01 00:11ID:8UdnvL3A上げないでくれる？>25
0027デフォルトの名無しさん
01/09/01 00:16ID:DNDtPrBs煽って盛り上げようとしただけなんだ。
ごめんよ>>24
0028デフォルトの名無しさん
01/09/01 00:24ID:eWD.Xl96ちなみに bswap(だっけ？)アセンブラレベルでlittle-->big変換できます。
002928
01/09/01 00:26ID:eWD.Xl960030デフォルトの名無しさん
01/09/01 00:28ID:BF0ekyhUそれともビットオーダーもやっぱり機種依存？
0031nanasi
01/09/01 01:06ID:3HIEX5eQバイトのオーダーを考慮して書き込むのは手間なんだYO.
そして、これをエレガンスなコードで実現したいのさ。わーった？
厨房以外のレスくれた人にはサンクス。
頭の体操もアセンブラもできん煽り厨房は逝ってヨシ。
夏休みももう終りじゃ。宿題やったか？ 捜しておいたから見とけ。
http://www-cms.phys.s.u-tokyo.ac.jp/~naoki/CIPINTRO/NETWORK/endian.html
0032IDEなんてクソ
01/09/01 01:33ID:N2P03Y3g平らなほうから割る人をビッグエンディアン。
0033nanasi
01/09/01 01:49ID:3HIEX5eQ0034デフォルトの名無しさん
01/09/01 05:22ID:jNF.zKm2俺もスマートかつ高速な方法知りたい。
はっきり言ってMPEGデコーダ中でのビットストリーム処理の負荷はかなり大きい。
ビッグエンディアンなら大分負荷が減ると思われる。
9bit以上同時に取り出すときは、エンディアンの変換しなきゃいかん。
アセンブラなら確かにbswapがあるんだが、そこだけインラインアセンブラで書いても
コンパイラの最適化処理の流れを狂わすし、レジスタの退避とかあるからかえって遅くなる。
ビットストリーム関数自体を全部アセンブラで書いてもダメだった。
関数自体はサイズ小さくて、呼び出しの回数や個所が多いから、結局コンパイラの最適化を狂わす。
なんだかんだでもっと上のレベルの関数から全部アセンブラにしなきゃいけなくなってかなり萎える。
つーかそれだけ大規模になってくるとやっぱりＣコンパイラに任せた方が速かったりするし。
結局取り出すビット数の範囲をあらかじめ決定できるところは、
1bit専用、8bit以下専用、16bit以下専用、24bit以下専用、32bit以下専用
って感じでいくつも作って対処したよ。。。
MPEGとかのビッグエンディアンなビットストリーム以外を扱うには、
リトルエンディアンの方が楽でいいと思うんだけどなぁ。
32->16のキャストとかも、いちいちレジスタに読み込んでシフトしないでも
下位16bitにアクセスするだけでいいわけだし。
あと、x86アセンブラだとビットストリーム命令ってあるが、
あれって、バイト単位のエンディアンは意識しないで使えるのでいいのだが、
ビット単位でのエンディアンが逆だから結局使えないんだよな。。。
ところで
>>31
って何してる人？ 同業者かな？
0035nanasi
01/09/01 09:54ID:4vAZTrpI1割がプロ。9割がアマかな。
ハフマン符号のデコーダはパターンマッチングやるから、作ろうとするとエン
コーダより鬱になるね。プログラム作る人はメモリアクセスをなるべくさせな
いように作るのに、規格はそれを許さないっつーか…
Twin VQはその辺の反省に立っているのだろうか？ あれってビットストリーム
じゃないらしいね。だからビット誤りなんかの障害に強い。
0036デフォルトの名無しさん
01/09/01 19:41ID:BF0ekyhUテキストファイルがどの環境でも共通に読めるということは
ビットオーダーはどの環境でも同じという事でしょうか？
それともファイルに書き込むのに規則があるのですか？
よろしくお願いします。
それか、これについて詳しく書いているページか本を教えてください。
0037デフォルトの名無しさん
01/09/01 20:18ID:jNF.zKm2TwinVQは一応ビットストリームじゃないか？
つーか、ビットストリームの解析を
こっちでやらなければいけないのがちょっと。。。
ライブラリ側でやってくれよ、って思う。
あとやっぱり複数のファイルを同時に処理できないことが痛いな。
静的変数使うなよ、って思う。
>>36
テキストファイルなら必ずしもどの環境でも読めるわけではない。
おそらく>>36はShift-JISな環境しかつかったこと無いからそう思ってるんだろうが、
文字コードは色々あって、コードが合わなきゃ、適切に変換してやらないと読めない。
そもそも、改行コードからしてＯＳによって違う。
MS-DOS/Windowsなら、CR+LF
MacならLFのみ
UNIXならCRのみ
MacとUNIX逆かもしれん。うろ覚えでスマソ。
ビットオーダやバイトオーダは、文字コードによって決められているので、
特に、気にすることはない。
0038デフォルトの名無しさん
01/09/01 20:54ID:9mI0bLJY>ビットオーダやバイトオーダは、文字コードによって決められているので、
>特に、気にすることはない。
なんだそりゃ。
ビットオーダーを規定してる文字コードなんてみ聞いたことない。
0039デフォルトの名無しさん
01/09/01 22:52ID:jNF.zKm2明記はしてないが、決まってるだろ。
ビット逆順にしたら読めんわ。
0040デフォルトの名無しさん
01/09/01 23:08ID:BF0ekyhU言葉足らずの文章だったので質問し直させてもらいます。
なにぶん、文章能力が無い上に、理解してない事を文章にしようと頑張っていますので････
で、質問です。
例えばアスキーコードであれば’A’は65、’B’は66と決まってますよね。
この時に文字コードをちゃんと指定してエディタ等で開けば文字化けはしないのですよね？
このようになるのはビットオーダが決まってないと不可能ではないのでは？と厨房の私は
思いましたが実際はどうなんでしょうか？
私は86系のCPUしか使った事が無いので他の環境はしらないのです。
0041デフォルトの名無しさん
01/09/01 23:20ID:D.FkLlloそもそも、普通の CPU は「メモリから 1 バイト読み出す／書き込む」
命令はあっても、「メモリから 1 ビット読み出す／書き込む」という
命令は存在しない。
0042デフォルトの名無しさん
01/09/01 23:42ID:jNF.zKm2x86にはビットストリーム命令があるけど。
BT/BTC/BTR/BTSなど。
それは例外かな？
『普通の』って言ってるし。
0043デフォルトの名無しさん
01/09/02 00:53ID:hS5FsHk20044デフォルトの名無しさん
01/09/02 01:21ID:AjecLNHIそー思うなら正しい方向に持って行ってあげてね。あおるだけじゃなくて。
俺はめんどーだから、しないけど。
（きょーみが無いだけともいう）
0045デフォルトの名無しさん
01/09/02 01:53ID:3FtfKw2E同意。
その辺で苦労する必要のある人ってホンの一部だから、どうでもいい。
苦労するはずじゃないレイヤのコードを作るのに苦労しているのは、
単にスキルが低いだけ。
0046デフォルトの名無しさん
01/09/02 04:41ID:2T5jxtX2電話線をデータが流れる時は1bit単位で流れるのかな。
で、その時bit7が先に送信されるかbit0が先かって話？
それだったらその辺はCPUは関係なくて、モデムの方で吸収しちゃうんじゃないかな。
モデムの方で規格が決まってたりして。よく知らないけど。
で、CPUに渡す時は既にバイト単位になってるからビットオーダーは関係なしとか。
ディスクにしても書かれてるデータはビット単位だけどCPUにはバイト単位でしか渡ってこないよね。
ビットオーダーって16bitとか32bitのレジスタでシフト・ローテート命令した時に
bit7が隣のbit0になるか、bit0が隣のbit7になるか、という話かな？
でもよく考えたらこれはビッグとスモールで逆になるけど一意に決まってないとおかしいよね。
シフトして値がきちんと２倍・２分の１にならなかったら変だものね。
0047nanasi
01/09/02 22:16ID:ORDU/DvsTwinVQはどうやら固定長のデータを使用しているようだ。
以前TwinVQのサイトでビットストリームは使ってない旨の表示があったが、今は
ない。
インターフェース増刊：「画像＆音声圧縮技術のすべて」, P.159
スカラ量子化とベクトル量子化の章には、１ベクトルあたり８ビット程度の固定長
符号を割り当てているように読める。
ベクトルに8ビットの均一な符号を割り当てているなら、ビットストリームではない
、と言えなくはないように思える。
0048デフォルトの名無しさん
01/09/02 22:46ID:4.l/Qws.そだね。
8bit単位でしか使わないなら、バイトストリームって言うべきかな？
でも、サンプルプログラムにはビットストリームどうのこうのって書いてあったので、
ビットストリームと言ってみた。
実質バイトストリームなのか。
0049デフォルトの名無しさん
01/09/02 23:31ID:j5LYTmtQbyte は CPU での最小の bit を扱う単位じゃなかったっけ？
0050デフォルトの名無しさん
01/09/03 00:57ID:ewvSMjxYオクテットというと先頭1bitはフレームビットで最後1bitはステータスビットという
イメージを受けてしまうのは漏れが間違った先入観を持ってる？
漏れは通信以外の世界でオクテットという言葉はあまり聞いたこと無いなぁ。
漏れの手元にある本(あんまあてにならない)での定義
>・ビット
>ビットは、コンピュータ内部での情報表現の単位。
>つまり、プログラム内で扱う記憶の基本単位である。
>装置間では１本の線によりビット情報の伝達が行われる。
>・バイト
>8ビットを１つの単位にまとめたデータ表現で、
>漢字を除く文字を符号で表現する単位のこと。
>・キャラクタ
>文字や記号のことで、コンピュータ処理の場合は、
>データ用に使われるものと制御用に使われるものがある。
>コンピュータ内部では、ふつう、8ビット、または、16ビットで表現する。
>・ワード(語)
>コンピュータ内部での処理単位で、CPUとメモリなどの間で
>１回のアクセスで同時にやり取りされるビット数のことをいう。
>技術計算の場合は、数を２進数に変換して内部表現する単位とみなせる。
>したがって、レジスタの大きさであり、演算器の演算単位でもある。
>１ワードが何ビットであるか(8ビット、16ビット、32ビット、64ビットなど)
>はコンピュータによって異なる。
なんか適当な説明だなぁ。。。
0051デフォルトの名無しさん
01/09/03 03:04ID:AI87OzPUたぶん間違った先入観。たしかに通信の世界で聞くことが多いが。
RFC とか読むと octet は結構出てくるな。
世の中に 8bit != 1byte なマシンなどが存在する限り、
1byte = 8bit は必ずしも成立しない。
それにその名前「octet」は８を意味する語なんだから、
フレームビットとかステータスビットとかは関係ない。
あなたがたぶん片寄った通信関係の職場で働いていたのでしょう。
漏れ的には
ワード：１回の一般的な命令で扱えるデータレジスタの幅。
キャラクタ：文字を表す数値。または文字そのもの。
バイト：１回の命令で通常の加減算命令等が行える最小ビット数
但し、アセンブラの最中は、
ワード：16bit
バイト：8bit
ダブルワード：32bit
…すいません、逝ってきます。
0052デフォルトの名無しさん
01/09/03 06:32ID:19bjYBuQUnicodeの規格では 16bit= 1byteらしい。又聞きだけど。
でもいまさら 1byte != 8bit の意味で使うやつは
ただの衒学者としてほっとくのがよいと思われ。
0053デフォルトの名無しさん
01/09/03 06:52ID:nmjujq7gbyteは基本中の基本単位だから
実質的定義がころころ変わると困るなぁ
005450
01/09/03 12:39ID:ewvSMjxYフレームビットとか関係ないよな。
それはわかってるんだけど、なんとなくそれを連想してしまうってだけ。
ちなみにぐーぐるしてみた
一番上に出た奴
>情報量の単位の一つ。1オクテットは8ビットに相当する。
>オクテットに似た情報量の単位にバイトがある。
>多くの場合、バイトとオクテットは同じだが、
>1バイトが何ビットに相当するかは文脈によるため、
>必ずしも1バイトが8ビットとは限らない。
>オクテットは必ず8ビットである。
>オクテットは通信分野でよく出てくる。
お、マトモなこと書いてあるぢゃん
でも、ココでは1byte==8bitとは限らないと書いておきながら、
この辞書サイトの『バイト』を引くと
>情報量の単位。1バイトは8ビットに相当する。
>コンピュータは情報の記憶や処理、
>伝達をバイト単位で行なうことが多い。
言ってること違うぢゃん。。。
アセンブリ言語やってると確かに
>ワード：16bit
>バイト：8bit
>ダブルワード：32bit
だね。アセンブラによって違うのかもしれないけど。
ちなみにWinの定義している変数の型もこのサイズだね。
IA-64用のWin64が出たら、変わる可能性はあるのかな？
変わったら嫌だなぁ。プログラム書き直しもメンドイけど、
頭の切り替えがもっとメンドイ。
ちなみに64bitはQWORD(クワッド)っていう？
漏れはMMX使いだから、アセンブリ中で書く時はほとんどMMWORDなんだけど。
C言語中ではQWORDで書いてるな。
128bitはなんていうんだろう？
アセンブリ中ではやっぱりSSE使いだから、XMMWORDだけど。
一般的には……？
0055デフォルトの名無しさん
01/09/03 13:03ID:oDYd29Ko>・現代の世界においては、一般的に1バイト=8ビットであるが、
>誰も明確に定義していないもの。
>・故に、虫の居所が悪い時に、鼻につく言い方で「1バイトは
>8ビットなんだよ」とか言っていたりする輩が居ると、「でも
>さ、1バイト=8ビットじゃない機械もあるんだよねぇ、だから
>オクテットなんていう単位もある訳で・・・あ、ニブルって
>言ったら、普通は4ビット。これは豆知識ね」と、横槍を入れ
>てやりたくなるもの。
同サイトのオクテット
>オクテット 【規格・単位】octet
・疾うの昔にほとんどが消滅した、1バイト=8ビットでは
>無い機械のために存在し、資格を取る為だけに覚える
>単位のこと。
同サイトのニブル
>ニブル 【コンピュータ】Nible
>・忘れ去られた単位。
（藁
同サイトの８ビット
>8ビット 【ハードウェア】
>・MSXに代表される8ビットCPUを搭載したパソコンの事。
>・今にして思えば、すべてを自分で制御───いじくり
>倒す事───でき、「あ〜、プログラムって面白いな」と
>夢と希望を持てた時代。
>・あの頃思った、「あと10バイト、メモリがあれば・・・」
>「もっと、色数が出ないかなぁ。」「う〜、遅せぇ〜。 でも、
>これ以上速くできないしなぁ。 16ビットだと良いんだろう
>なぁ。」「こないだ8時間かけて打ちこんだダンプを保存したテ
>ープ、伸びちゃったよ。 あ〜ディスクが欲しい」等々、とり
>あえずあの頃に思った以上の環境になったけれど、何か夢も希
>望もなくなって、ただ絶望と疲労、そして目の前の仕事だけが増えた。
0056出張あさはかマン
01/09/03 13:49ID:fsBE3wNw・1バイト≠8ビットな系
7bit+1パリティビットの場合(昔のテレタイプ・紙テープの頃の遺物)があります。
・ビットオーダが逆な系
XMODEMなどのCRC計算(MSBから)と、CCITTのCRC計算(LSBから)は
ビットオーダーが逆なのでシフト方向や、計算に使う初期値が異なります。
・なんでビットストリームがビッグエンディアンなのか
シリアル転送でバースト誤りを起こしたとき、ほんの少しだけ強いです。
0057デフォルトの名無しさん
01/09/03 14:59ID:nE7dypGU0058デフォルトの名無しさん
01/09/03 18:26ID:M/nB86do0059デフォルトの名無しさん
01/09/04 20:11ID:Z/bHOcVEツーリトル♪
スリーリトルエンディアン♪
0060デフォルトの名無しさん
01/09/06 02:39ID:pVDXjO86ビッグエンディアン機で見ると「ＡＢＣ」は
「$8260 8261 8262」ってシフトＪＩＳコードがそのまま並んでるけど
これはリトルエンディアン機でもいっしょ？
だとしたらリトルエンディアン機で２バイト文字を扱うのって面倒だったりする？
「全角のＡ〜Ｚを半角のA-Zに直す」なんて事を考えた場合
「文字のコードが○○以上○○以下なら…」って判定が素直に書けなかったりとか。
0061デフォルトの名無しさん
01/09/06 04:45ID:hYMYaHkgこれで満足いただけるでしょう。
unsigned pick_one_character( const char *s)
{
unsigned code = *s++;
if( iskanji_1stbyte(code) ) code = (code << 8) | *s++;
return code;
}
006260
01/09/06 04:57ID:3zyOtcVQやっぱりひっくり返す処理がいるんですね。
0063デフォルトの名無しさん
01/09/06 05:11ID:hYMYaHkgエンディアンで書き分ける必要はないです。
motorola の x68000 とかでバイト境界で int サイズと
仮定して読むとバスエラーなんてステキなことが起きます。
エンディアン問題は、int サイズで読み書きすると起きるから。
それを基準に考えればおっけ。
0064デフォルトの名無しさん
01/09/06 05:15ID:hYMYaHkgunicode.org 見てくればすこし勉強になります。
0065デフォルトの名無しさん
01/09/06 05:34ID:hYMYaHkg何が言いたいかというと、SJIS とかの文字コードは
エンディアンが関係する１６ビットセットじゃなくて
１バイト目が上位、２バイト目が下位を示すだけで
その通りにコーディングしたら、エンディアンで
ひっくり返すとかややこしく考えずにすむのじゃないかと。
１６ビットで読むこともできるけど、そうなると
エンディアン問題やバスエラーではまりそう。
0066デフォルトの名無しさん
01/09/06 08:26ID:0iK.UQWwおいおいひっくり返してないだろう。エンディアン関係ないぞ
0067デフォルトの名無しさん
01/09/06 16:27ID:shBL8/Lc006962
NGNGえーと、ひっくり返すと言うか、ひっくり返ってると言うか…
変数「code」がメモリ上に格納されたら
やっぱり元のパターンから見てひっくり返ってるという様な意味で。
つまりダイレクトに16bit取って来れないからその為の処理がいるという事で…
えーと、言葉の言い回しだけの問題かな。
（バスエラーを考えなければビッグだといきなり16bit取って来れるというのはOKですよね。）
0070デフォルトの名無しさん
NGNGバイトデータ列を扱うのに、エンディアンの違いを考慮しなきゃ
いけないような考え方自体が間違ってるけどな。
マルチバイト文字の場合、読む処理的にはこんなかんじになるでしょ。
・まず1バイト拾ってみて、それが2バイト長の文字だと判断したら
次に2バイト目をバッファ上で連結する
となれば、いきなり2バイト分まとめて読む処理は必要ない。
連結処理はビットシフトなどで済ませればいいので、メモリ上の並びと
上下関係は分離できる。
0071デフォルトの名無しさん
NGNG"aあbいcう" って文字列だったら
{ 0x61, 0x82a0, 0x62, 0x82a1, 0x63, 0x82a2 } ってイメージのようだが、
そーじゃなくて、あくまで
{ 0x61, 0x82、0xa0, 0x62, 0x82, 0xa1, 0x63, 0x82, 0xa2 } って気分で扱うべき物だと思われ。
0072デフォルトの名無しさん
NGNG0073デフォルトの名無しさん
NGNGけっけっけ。
007573じゃないが
NGNG71の例でいくと
{0x61, 0x82, 0xa0, 0x62, 0x82, 0xa1, 0x63, 0x82, 0xa2}
がマルチバイト（シフトJIS etc）、
{0x0061, 0x82a0, 0x0062, 0x82a1, 0x0063, 0x82a2}
がワイド（Unicode etc）
0076厨房
NGNGありがとうございます。
あ、ワイドでもひっくり返ったり（エンディアンによって）しないんですね。
１ｂｙｔｅ（ｏｃｔｅｔ）ずつ読むならいいけど、ワイドで一気に読んだらひっくりかえったりする事があるのかと思ってました。
0077デフォルトの名無しさん
NGNGつーか、どんな順番だろうと、一貫していれば問題なかろう。
> １ｂｙｔｅ（ｏｃｔｅｔ）ずつ読む
時はprogrammerがendianを意識してassembleしないといけないが、
> ワイドで一気に読んだら
ちゃんとしたcodeをcompilerが生成してくれる。
networkで送る時は、相手のCPUによっては一貫しないことになるので、
protocolでorderを規定したり、negotiationしたりするわけだな。
もちろんその場合は、multi-byte character/stringとして定義する。
serial communicationであればbit orderも。
0078デフォルトの名無しさん
NGNGまだ理解してないと思われ
>>75のワイド文字の方はエンディアンの問題が起こる
0079厨房
NGNGでしょ？そういう事あるのかなと思っていたんですが。
じゃあひっくりかえる、という理解でいいの？
>>77
それで１６ｂｉｔとかを扱うときにはｈｔｏ＊、ｎｔｏ＊を使うのでしょうか。
あ、シリアルではビット列を送る順番もですか。。。なるほど。
0080デフォルトの名無しさん
NGNGUnicodeはエンディアンを考慮して読む必要がある。
リトルエンディアンで出力されたデータをビッグで読むときには
「ひっくり返す」必要があるし、逆もまた真なり。
が、ShiftJISならそんなもん関係なし。
0081デフォルトの名無しさん
NGNG> が、ShiftJISならそんなもん関係なし。
なんでやねん…sparcでShiftJIS扱う時どうすんねん？
Wintelを暗黙に仮定しているわけ？
0083デフォルトの名無しさん
NGNG交換目的はビッグに統一しても良かったかもしれないと思うんですよね。
処理系と別のエンディアンならエンディアン処理しなくてはならないし
エンディアンの指定コードが入ったり、なかったときのことを考えると
煩雑で見返りが少ないんじゃないかと。
無ければならない、何か致命的な理由でもあるんでしょうか？
ビッグにまとめるとリトル派が、リトルにするとビッグ派が怒るからでしょうか。
複雑になるより統一して単純にしたほうが良かったような気がするのですが…。
0084デフォルトの名無しさん
NGNGアホ？
008583
NGNG0086デフォルトの名無しさん
NGNGﾊﾞｶ？
0087デフォルトの名無しさん
NGNG>ビッグにまとめるとリトル派が、リトルにするとビッグ派が怒るからでしょうか。
これが真理。統一しようという話はあったがな。
0088デフォルトの名無しさん
NGNG0089デフォルトの名無しさん
NGNGエンディアネスが気になる場合は、UTF-8にエンコードして交換する。
１文字の幅が16bitか32bitかという問題もあるので、
エンディアネスを統一しただけでは問題は解決しない。
0090デフォルトの名無しさん
NGNG結局UTF8に落ち着いたんだからどうでもいいかと
プログラム内部でUCS2やUCS4で使ってようが関係ないし
0091デフォルトの名無しさん
NGNG情報交換時の標準エンディアンを決めたとすると、
非標準エンディアン同士で交換すると、二回変換が必要。
DCE RPCのように交換前にnegotiationすれば、
変換が0回あるいは1回で済む。
というような理由もあったと想像するが、>>90の言うように意味が薄い。
何でも実現しようとするのは、大きい規格制定作業グループの特徴。
0092new 名無し( )；
NGNG009383
NGNG■ このスレッドは過去ログ倉庫に格納されています