5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

ビッグエンディアン、スモールエンディアンについて

1 :youknow:01/08/28 19:26 ID:DpjwJkFE
教えてもらいたい事があるんですが・・・

intel系PCにおいて、ビッグエンディアン、スモールエンディアン(バイト反転)を考えずに
デバッグ出来るツール、アプリが有ったら教えてもらいたいんですが。

出来れば今の環境で(PowerPCを使わないで)そのような事が出来るのがあったら、教えてください。
よろしくお願いいたします。

2 :デフォルトの名無しさん:01/08/28 19:41 ID:SizReSeE
スモールエンディアン-5件
http://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

3 :名無しさん@揚げ足:01/08/28 19:46 ID:/PUWXyoI
関連スレ「リトルインディアンとビッグインディアン」
http://piza.2ch.net/tech/kako/966/966993365.html

4 :デフォルトの名無しさん:01/08/28 20:02 ID:BlBCjJFw
クソスレの1は固定ハンドル説=定説

5 :デフォルトの名無しさん:01/08/28 20:52 ID:WlUgdCDY
Javaにしろ

6 :デフォルトの名無しさん:01/08/29 00:45 ID:355Pw4a2
エンディアン嘘つかない

7 :nanasi:01/08/31 01:06 ID:MTRYrRJs
つーか、リトルエイディアンのマシンでビットストリームをスマートに表現
する方法が知りたいぞ。(MMX以上を使用すること)

メモリというかファイル上のビットの並びと、メモリ上での並びが違うから
簡潔には表現できん。むー、修行不足じゃ。

8 :nanasi:01/08/31 01:07 ID:MTRYrRJs
>7
メモリというか

ここはカットして読んでちょ。

9 :デフォルトの名無しさん:01/08/31 01:16 ID:9rnRfARA
ん?逆でないかい?

10 :デフォルトの名無しさん:01/08/31 01:19 ID:R3B1Jouc
うむ、big endianの方が邪道だね。
bit streamなら little endianの方が楽。

11 :nanasi:01/08/31 01:38 ID:MTRYrRJs
?インテルだと1,2,4バイト毎に並びが違うわけですな。
常に下位、上位(のバイト、ワード、ダブルワード)の順番で並ぶ
から、プログラムの処理中では問題ないけれど、ファイルとして
書き出す処理が面倒くさいぞ。スマートじゃない。

PowerPCみたいにリトル⇔ビッグを切替えられればいいのに。

12 :デフォルトの名無しさん:01/08/31 01:44 ID:R3B1Jouc
よくわからんが、書き出すってどういうことだ??
binary dataままなら write 一発だし。text dataならどっちも
同じようなもんだが。
どう考えても下位バイトが下位アドレスに位置する little endian
の方が素直。IBMと Motorolaいってよし。

13 :デフォルトの名無しさん:01/08/31 02:07 ID:gv.yve5A
>>12
???
意味不明
誰か地球語に翻訳キボーン

14 :デフォルトの名無しさん:01/08/31 02:09 ID:6GgGBKtg
>>13
あまりに明快な気がするが。どこが分からん?

15 :nanasi:01/08/31 02:50 ID:UDsEqWvw
ふむ、俺も混乱しているかもしれん。ちなみにLinux(IA32)では、

main(){
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の種類によってはよきに計らってくれるかも
しれんが・・・。

16 :デフォルトの名無しさん:01/08/31 03:16 ID:BUJpHfZI
レベル低いね

17 :デフォルトの名無しさん:01/08/31 03:20 ID:R3B1Jouc
MP3のヘッダってのは「32bitの bigendianの整数」として定義されてるのか?
だとしたらたこな仕様だ。
普通なら 4つの byte値として定義するもんだと思うので。
char id[]={0x00,0x00,0x01,0xb3}; でいいのではないか。
まあ、ほかの部分で数値を bigendianで書くって決まってるなら、そこで
変換は必要だけど。
network byte orderはなんであっちに決まったんだろう。IBMの策略か?
BSD unixは VAXだったんだから littleのまま突っ走りそうだけどな。

18 :nanasi:01/08/31 03:27 ID:UDsEqWvw
そう。しかし、id[] = {0x00,0x00,0x01,0xb3};と書いても、何も考えずに
fwriteで書き出すと、例のごとく0xb3, 0x01, 0x00, 0x00となるわけさ。

メモリ上のビットストリームに書く毎、あるいは出力直前にでもエイディアン
の変換が必要なのよ。多分ビットストリームに書き込む都度変換するのは難し
いよ。

どちらにせよ美しくないやね。

19 :デフォルトの名無しさん:01/08/31 04:06 ID:R3B1Jouc
それは嘘だろ。
fwrite(id, 1, 4, out) がそうなる環境なんて見たことないぞ...
x86なら memory上での (int)0x000001b3 と (char*){0x00,0x00,0x01,0xb3}
の並びは違うはずだ。普通。

20 :nanasi:01/08/31 07:27 ID:FxI8Q2HI
いかん、嘘書いてしまったスマソ。
char id[]={0x00, 0x00, 0x01, 0xB3};と書いて、fwriteで出力すれば
問題ない。確認した。

しかし、これだとレジスタ上では0x01B30000と表現されるな。

8ビットのデータなら書き込むだけでよいが、それ以下の長さのデータ
ならば、バイトの並びを考慮したシフトルーチンを作らんとダメなのか。

汚いルーチンだ。頭が回らん。もう寝る。

21 :nanasi:01/08/31 07:32 ID:FxI8Q2HI
↑0xB3010000だな、スマソ。スマソ。もう落ちる。

22 :デフォルトの名無しさん:01/08/31 12:00 ID:9rnRfARA
結局どっちがどうなの?
よく理解したいからだれか説明してちょ。

23 :デフォルトの名無しさん:01/08/31 21:28 ID:u3gTIGB2
7bit以下のデータを考えて入出力なんて面倒なことしたくないなー。

普通、8の倍数bitで考えないか?

24 :デフォルトの名無しさん:01/08/31 22:15 ID:SYzSjnws
>>23 ビットオーダーとバイトオーダーを勘違いしてる奴発見
つーかネタ?

25 :デフォルトの名無しさん:01/09/01 00:08 ID:DNDtPrBs
>>24

お前が解って無いに100リラ

26 :デフォルトの名無しさん:01/09/01 00:11 ID:8UdnvL3A
おれ、ここクソスレだと思ってるんだけど
上げないでくれる?>25

27 :デフォルトの名無しさん:01/09/01 00:16 ID:DNDtPrBs
ごめんよ。おれ、ここ良スレだと思ってたから
煽って盛り上げようとしただけなんだ。
ごめんよ>>24

28 :デフォルトの名無しさん:01/09/01 00:24 ID:eWD.Xl96
CPUがビッグかリトルかを判定して1,2,4Byte読み出し関数をポインタでつなげば?
ちなみに bswap(だっけ?)アセンブラレベルでlittle-->big変換できます。

29 :28:01/09/01 00:26 ID:eWD.Xl96
正確にはlittle<-->bigだな。。

30 :デフォルトの名無しさん:01/09/01 00:28 ID:BF0ekyhU
ビットオーダーは機種依存でなく全部下位から上位へ積まれていくの?
それともビットオーダーもやっぱり機種依存?

31 :nanasi:01/09/01 01:06 ID:3HIEX5eQ
MPEG1,2だとよ、書き込むデータは2bitから32ビットまで幅があるんだよ。これを
バイトのオーダーを考慮して書き込むのは手間なんだYO.
そして、これをエレガンスなコードで実現したいのさ。わーった?

厨房以外のレスくれた人にはサンクス。
頭の体操もアセンブラもできん煽り厨房は逝ってヨシ。

夏休みももう終りじゃ。宿題やったか? 捜しておいたから見とけ。
http://www-cms.phys.s.u-tokyo.ac.jp/~naoki/CIPINTRO/NETWORK/endian.html

32 :IDEなんてクソ:01/09/01 01:33 ID:N2P03Y3g
ゆで卵のとがった方から割る人をスモールエンディアン、
平らなほうから割る人をビッグエンディアン。

33 :nanasi:01/09/01 01:49 ID:3HIEX5eQ
おーい、山田君、菊蔵さんの座布団全部持ってっちゃって。

34 :デフォルトの名無しさん:01/09/01 05:22 ID:jNF.zKm2
興味深いスレ発見。
俺もスマートかつ高速な方法知りたい。
はっきり言ってMPEGデコーダ中でのビットストリーム処理の負荷はかなり大きい。
ビッグエンディアンなら大分負荷が減ると思われる。
9bit以上同時に取り出すときは、エンディアンの変換しなきゃいかん。

アセンブラなら確かにbswapがあるんだが、そこだけインラインアセンブラで書いても
コンパイラの最適化処理の流れを狂わすし、レジスタの退避とかあるからかえって遅くなる。
ビットストリーム関数自体を全部アセンブラで書いてもダメだった。
関数自体はサイズ小さくて、呼び出しの回数や個所が多いから、結局コンパイラの最適化を狂わす。
なんだかんだでもっと上のレベルの関数から全部アセンブラにしなきゃいけなくなってかなり萎える。
つーかそれだけ大規模になってくるとやっぱりCコンパイラに任せた方が速かったりするし。

結局取り出すビット数の範囲をあらかじめ決定できるところは、
1bit専用、8bit以下専用、16bit以下専用、24bit以下専用、32bit以下専用
って感じでいくつも作って対処したよ。。。

MPEGとかのビッグエンディアンなビットストリーム以外を扱うには、
リトルエンディアンの方が楽でいいと思うんだけどなぁ。
32->16のキャストとかも、いちいちレジスタに読み込んでシフトしないでも
下位16bitにアクセスするだけでいいわけだし。

あと、x86アセンブラだとビットストリーム命令ってあるが、
あれって、バイト単位のエンディアンは意識しないで使えるのでいいのだが、
ビット単位でのエンディアンが逆だから結局使えないんだよな。。。

ところで
>>31
って何してる人? 同業者かな?

35 :nanasi:01/09/01 09:54 ID:4vAZTrpI
>>34
1割がプロ。9割がアマかな。

ハフマン符号のデコーダはパターンマッチングやるから、作ろうとするとエン
コーダより鬱になるね。プログラム作る人はメモリアクセスをなるべくさせな
いように作るのに、規格はそれを許さないっつーか…

Twin VQはその辺の反省に立っているのだろうか? あれってビットストリーム
じゃないらしいね。だからビット誤りなんかの障害に強い。

36 :デフォルトの名無しさん:01/09/01 19:41 ID:BF0ekyhU
便乗質問させてもらいます。
テキストファイルがどの環境でも共通に読めるということは
ビットオーダーはどの環境でも同じという事でしょうか?
それともファイルに書き込むのに規則があるのですか?
よろしくお願いします。
それか、これについて詳しく書いているページか本を教えてください。

37 :デフォルトの名無しさん:01/09/01 20:18 ID:jNF.zKm2
>>35
TwinVQは一応ビットストリームじゃないか?
つーか、ビットストリームの解析を
こっちでやらなければいけないのがちょっと。。。
ライブラリ側でやってくれよ、って思う。

あとやっぱり複数のファイルを同時に処理できないことが痛いな。
静的変数使うなよ、って思う。

>>36

テキストファイルなら必ずしもどの環境でも読めるわけではない。
おそらく>>36はShift-JISな環境しかつかったこと無いからそう思ってるんだろうが、
文字コードは色々あって、コードが合わなきゃ、適切に変換してやらないと読めない。

そもそも、改行コードからしてOSによって違う。
MS-DOS/Windowsなら、CR+LF
MacならLFのみ
UNIXならCRのみ
MacとUNIX逆かもしれん。うろ覚えでスマソ。

ビットオーダやバイトオーダは、文字コードによって決められているので、
特に、気にすることはない。

38 :デフォルトの名無しさん:01/09/01 20:54 ID:9mI0bLJY
>>37
>ビットオーダやバイトオーダは、文字コードによって決められているので、
>特に、気にすることはない。

なんだそりゃ。
ビットオーダーを規定してる文字コードなんてみ聞いたことない。

39 :デフォルトの名無しさん:01/09/01 22:52 ID:jNF.zKm2
>>38

明記はしてないが、決まってるだろ。
ビット逆順にしたら読めんわ。

40 :デフォルトの名無しさん:01/09/01 23:08 ID:BF0ekyhU
厨房の私でも流石にEUC等のS-JIS以外の文字コードの存在は知っています(笑
言葉足らずの文章だったので質問し直させてもらいます。
なにぶん、文章能力が無い上に、理解してない事を文章にしようと頑張っていますので・・・・

で、質問です。
例えばアスキーコードであれば’A’は65、’B’は66と決まってますよね。
この時に文字コードをちゃんと指定してエディタ等で開けば文字化けはしないのですよね?
このようになるのはビットオーダが決まってないと不可能ではないのでは?と厨房の私は
思いましたが実際はどうなんでしょうか?

私は86系のCPUしか使った事が無いので他の環境はしらないのです。

41 :デフォルトの名無しさん:01/09/01 23:20 ID:D.FkLllo
>>40
そもそも、普通の CPU は「メモリから 1 バイト読み出す/書き込む」
命令はあっても、「メモリから 1 ビット読み出す/書き込む」という
命令は存在しない。

42 :デフォルトの名無しさん:01/09/01 23:42 ID:jNF.zKm2
>>41
x86にはビットストリーム命令があるけど。
BT/BTC/BTR/BTSなど。
それは例外かな?
『普通の』って言ってるし。

43 :デフォルトの名無しさん:01/09/02 00:53 ID:hS5FsHk2
ほんとバカ多いな・・・レベル低すぎ(藁

44 :デフォルトの名無しさん:01/09/02 01:21 ID:AjecLNHI
>>43
そー思うなら正しい方向に持って行ってあげてね。あおるだけじゃなくて。
俺はめんどーだから、しないけど。
(きょーみが無いだけともいう)

45 :デフォルトの名無しさん:01/09/02 01:53 ID:3FtfKw2E
>>44
同意。
その辺で苦労する必要のある人ってホンの一部だから、どうでもいい。
苦労するはずじゃないレイヤのコードを作るのに苦労しているのは、
単にスキルが低いだけ。

46 :デフォルトの名無しさん:01/09/02 04:41 ID:2T5jxtX2
>>40
電話線をデータが流れる時は1bit単位で流れるのかな。
で、その時bit7が先に送信されるかbit0が先かって話?
それだったらその辺はCPUは関係なくて、モデムの方で吸収しちゃうんじゃないかな。
モデムの方で規格が決まってたりして。よく知らないけど。
で、CPUに渡す時は既にバイト単位になってるからビットオーダーは関係なしとか。
ディスクにしても書かれてるデータはビット単位だけどCPUにはバイト単位でしか渡ってこないよね。

ビットオーダーって16bitとか32bitのレジスタでシフト・ローテート命令した時に
bit7が隣のbit0になるか、bit0が隣のbit7になるか、という話かな?
でもよく考えたらこれはビッグとスモールで逆になるけど一意に決まってないとおかしいよね。
シフトして値がきちんと2倍・2分の1にならなかったら変だものね。

47 :nanasi:01/09/02 22:16 ID:ORDU/Dvs
>>37
TwinVQはどうやら固定長のデータを使用しているようだ。
以前TwinVQのサイトでビットストリームは使ってない旨の表示があったが、今は
ない。

インターフェース増刊:「画像&音声圧縮技術のすべて」, P.159
スカラ量子化とベクトル量子化の章には、1ベクトルあたり8ビット程度の固定長
符号を割り当てているように読める。

ベクトルに8ビットの均一な符号を割り当てているなら、ビットストリームではない
、と言えなくはないように思える。

48 :デフォルトの名無しさん:01/09/02 22:46 ID:4.l/Qws.
>>47

そだね。
8bit単位でしか使わないなら、バイトストリームって言うべきかな?
でも、サンプルプログラムにはビットストリームどうのこうのって書いてあったので、
ビットストリームと言ってみた。
実質バイトストリームなのか。

49 :デフォルトの名無しさん:01/09/02 23:31 ID:j5LYTmtQ
8bit 単位は octet stream。

byte は CPU での最小の bit を扱う単位じゃなかったっけ?

50 :デフォルトの名無しさん:01/09/03 00:57 ID:ewvSMjxY
>>49

オクテットというと先頭1bitはフレームビットで最後1bitはステータスビットという
イメージを受けてしまうのは漏れが間違った先入観を持ってる?
漏れは通信以外の世界でオクテットという言葉はあまり聞いたこと無いなぁ。

漏れの手元にある本(あんまあてにならない)での定義
>・ビット
>ビットは、コンピュータ内部での情報表現の単位。
>つまり、プログラム内で扱う記憶の基本単位である。
>装置間では1本の線によりビット情報の伝達が行われる。

>・バイト
>8ビットを1つの単位にまとめたデータ表現で、
>漢字を除く文字を符号で表現する単位のこと。

>・キャラクタ
>文字や記号のことで、コンピュータ処理の場合は、
>データ用に使われるものと制御用に使われるものがある。
>コンピュータ内部では、ふつう、8ビット、または、16ビットで表現する。

>・ワード(語)
>コンピュータ内部での処理単位で、CPUとメモリなどの間で
>1回のアクセスで同時にやり取りされるビット数のことをいう。
>技術計算の場合は、数を2進数に変換して内部表現する単位とみなせる。
>したがって、レジスタの大きさであり、演算器の演算単位でもある。
>1ワードが何ビットであるか(8ビット、16ビット、32ビット、64ビットなど)
>はコンピュータによって異なる。

なんか適当な説明だなぁ。。。

51 :デフォルトの名無しさん:01/09/03 03:04 ID:AI87OzPU
>>50
たぶん間違った先入観。たしかに通信の世界で聞くことが多いが。
RFC とか読むと octet は結構出てくるな。
世の中に 8bit != 1byte なマシンなどが存在する限り、
1byte = 8bit は必ずしも成立しない。
それにその名前「octet」は8を意味する語なんだから、
フレームビットとかステータスビットとかは関係ない。
あなたがたぶん片寄った通信関係の職場で働いていたのでしょう。

漏れ的には
ワード:1回の一般的な命令で扱えるデータレジスタの幅。
キャラクタ:文字を表す数値。または文字そのもの。
バイト:1回の命令で通常の加減算命令等が行える最小ビット数
但し、アセンブラの最中は、
ワード:16bit
バイト:8bit
ダブルワード:32bit

…すいません、逝ってきます。

52 :デフォルトの名無しさん:01/09/03 06:32 ID:19bjYBuQ
byteってのは1文字をあらわすのに必要な bit数。
Unicodeの規格では 16bit= 1byteらしい。又聞きだけど。
でもいまさら 1byte != 8bit の意味で使うやつは
ただの衒学者としてほっとくのがよいと思われ。

53 :デフォルトの名無しさん:01/09/03 06:52 ID:nmjujq7g
>>52
byteは基本中の基本単位だから
実質的定義がころころ変わると困るなぁ

54 :50:01/09/03 12:39 ID:ewvSMjxY
確かにもともとの意味は8個の組を表す言葉だから、
フレームビットとか関係ないよな。
それはわかってるんだけど、なんとなくそれを連想してしまうってだけ。

ちなみにぐーぐるしてみた
一番上に出た奴

>情報量の単位の一つ。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だけど。
一般的には……?

55 :デフォルトの名無しさん:01/09/03 13:03 ID:oDYd29Ko
>バイト 【規格・単位】
>・現代の世界においては、一般的に1バイト=8ビットであるが、
>誰も明確に定義していないもの。
>・故に、虫の居所が悪い時に、鼻につく言い方で「1バイトは
>8ビットなんだよ」とか言っていたりする輩が居ると、「でも
>さ、1バイト=8ビットじゃない機械もあるんだよねぇ、だから
>オクテットなんていう単位もある訳で・・・あ、ニブルって
>言ったら、普通は4ビット。これは豆知識ね」と、横槍を入れ
>てやりたくなるもの。

同サイトのオクテット

>オクテット 【規格・単位】octet
・疾うの昔にほとんどが消滅した、1バイト=8ビットでは
>無い機械のために存在し、資格を取る為だけに覚える
>単位のこと。
同サイトのニブル
>ニブル 【コンピュータ】Nible
>・忘れ去られた単位。
(藁

同サイトの8ビット

>8ビット 【ハードウェア】
>・MSXに代表される8ビットCPUを搭載したパソコンの事。
>・今にして思えば、すべてを自分で制御───いじくり
>倒す事───でき、「あ〜、プログラムって面白いな」と
>夢と希望を持てた時代。
>・あの頃思った、「あと10バイト、メモリがあれば・・・」
>「もっと、色数が出ないかなぁ。」「う〜、遅せぇ〜。 でも、
>これ以上速くできないしなぁ。 16ビットだと良いんだろう
>なぁ。」「こないだ8時間かけて打ちこんだダンプを保存したテ
>ープ、伸びちゃったよ。 あ〜ディスクが欲しい」等々、とり
>あえずあの頃に思った以上の環境になったけれど、何か夢も希
>望もなくなって、ただ絶望と疲労、そして目の前の仕事だけが増えた。

56 :出張あさはかマン:01/09/03 13:49 ID:fsBE3wNw
古い話なので適当に聞き流してください。

・1バイト≠8ビットな系
7bit+1パリティビットの場合(昔のテレタイプ・紙テープの頃の遺物)があります。

・ビットオーダが逆な系
XMODEMなどのCRC計算(MSBから)と、CCITTのCRC計算(LSBから)は
ビットオーダーが逆なのでシフト方向や、計算に使う初期値が異なります。

・なんでビットストリームがビッグエンディアンなのか
シリアル転送でバースト誤りを起こしたとき、ほんの少しだけ強いです。

57 :デフォルトの名無しさん:01/09/03 14:59 ID:nE7dypGU
ヨーロッパとかではファイルサイズの表記に mo(mega octet) とか使ってるね。

58 :デフォルトの名無しさん:01/09/03 18:26 ID:M/nB86do


59 :デフォルトの名無しさん:01/09/04 20:11 ID:Z/bHOcVE
ワンリトル♪
ツーリトル♪
スリーリトルエンディアン♪

60 :デフォルトの名無しさん:01/09/06 02:39 ID:pVDXjO86
日本語(2バイト文字)のバイトオーダーはどうなってるの?
ビッグエンディアン機で見ると「ABC」は
「$8260 8261 8262」ってシフトJISコードがそのまま並んでるけど
これはリトルエンディアン機でもいっしょ?
だとしたらリトルエンディアン機で2バイト文字を扱うのって面倒だったりする?
「全角のA〜Zを半角のA-Zに直す」なんて事を考えた場合
「文字のコードが○○以上○○以下なら…」って判定が素直に書けなかったりとか。

61 :デフォルトの名無しさん:01/09/06 04:45 ID:hYMYaHkg
>>60
これで満足いただけるでしょう。

unsigned pick_one_character( const char *s)
{
 unsigned code = *s++;
 if( iskanji_1stbyte(code) ) code = (code << 8) | *s++;
 return code;
}

62 :60:01/09/06 04:57 ID:3zyOtcVQ
あ、ありがとうございます。
やっぱりひっくり返す処理がいるんですね。

63 :デフォルトの名無しさん:01/09/06 05:11 ID:hYMYaHkg
というか、61 のコードはリトルでもビックでも通るし
エンディアンで書き分ける必要はないです。
motorola の x68000 とかでバイト境界で int サイズと
仮定して読むとバスエラーなんてステキなことが起きます。
エンディアン問題は、int サイズで読み書きすると起きるから。
それを基準に考えればおっけ。

64 :デフォルトの名無しさん:01/09/06 05:15 ID:hYMYaHkg
ユニコードはエンディアン依存なコードも認めているので
unicode.org 見てくればすこし勉強になります。

65 :デフォルトの名無しさん:01/09/06 05:34 ID:hYMYaHkg
うーん。俺は日本語が下手だなぁ。(w

何が言いたいかというと、SJIS とかの文字コードは
エンディアンが関係する16ビットセットじゃなくて
1バイト目が上位、2バイト目が下位を示すだけで
その通りにコーディングしたら、エンディアンで
ひっくり返すとかややこしく考えずにすむのじゃないかと。

16ビットで読むこともできるけど、そうなると
エンディアン問題やバスエラーではまりそう。

66 :デフォルトの名無しさん:01/09/06 08:26 ID:0iK.UQWw
>>62
おいおいひっくり返してないだろう。エンディアン関係ないぞ

67 :デフォルトの名無しさん:01/09/06 16:27 ID:shBL8/Lc
UCS2はバイトオーダ符号(FFFEorFEFF)を頭につけるんだっけ?

68 :62:01/09/07 01:27
>>63-65
どうもありがとうございます。
62を書いた後すぐ寝ちゃったもんで。
詳しい説明のおかげで理解できました。

69 :62:01/09/07 01:40
>>66
えーと、ひっくり返すと言うか、ひっくり返ってると言うか…

変数「code」がメモリ上に格納されたら
やっぱり元のパターンから見てひっくり返ってるという様な意味で。
つまりダイレクトに16bit取って来れないからその為の処理がいるという事で…
えーと、言葉の言い回しだけの問題かな。

(バスエラーを考えなければビッグだといきなり16bit取って来れるというのはOKですよね。)

70 :デフォルトの名無しさん:01/09/07 12:28
>>69
バイトデータ列を扱うのに、エンディアンの違いを考慮しなきゃ
いけないような考え方自体が間違ってるけどな。

マルチバイト文字の場合、読む処理的にはこんなかんじになるでしょ。
・まず1バイト拾ってみて、それが2バイト長の文字だと判断したら
次に2バイト目をバッファ上で連結する

となれば、いきなり2バイト分まとめて読む処理は必要ない。
連結処理はビットシフトなどで済ませればいいので、メモリ上の並びと
上下関係は分離できる。

71 :デフォルトの名無しさん:01/09/07 23:07
>>69
"aあbいcう" って文字列だったら
{ 0x61, 0x82a0, 0x62, 0x82a1, 0x63, 0x82a2 } ってイメージのようだが、

そーじゃなくて、あくまで
{ 0x61, 0x82、0xa0, 0x62, 0x82, 0xa1, 0x63, 0x82, 0xa2 } って気分で扱うべき物だと思われ。

72 :デフォルトの名無しさん:01/09/08 02:00
multi-byte string, wide character stringの違い、分かってない人がいるな。

73 :デフォルトの名無しさん:01/09/08 02:29
おれ様はちゃ〜んとわかっているぜ。
けっけっけ。

74 :厨房:01/09/09 03:11
後学のためにも教えていただけませぬか?
>>73

75 :73じゃないが:01/09/09 12:07
>>74

71の例でいくと
{0x61, 0x82, 0xa0, 0x62, 0x82, 0xa1, 0x63, 0x82, 0xa2}
がマルチバイト(シフトJIS etc)、
{0x0061, 0x82a0, 0x0062, 0x82a1, 0x0063, 0x82a2}
がワイド(Unicode etc)

76 :厨房:01/09/10 01:32
>>75
ありがとうございます。

あ、ワイドでもひっくり返ったり(エンディアンによって)しないんですね。
1byte(octet)ずつ読むならいいけど、ワイドで一気に読んだらひっくりかえったりする事があるのかと思ってました。

77 :デフォルトの名無しさん:01/09/10 14:50
>>76
つーか、どんな順番だろうと、一貫していれば問題なかろう。

> 1byte(octet)ずつ読む
時はprogrammerがendianを意識してassembleしないといけないが、
> ワイドで一気に読んだら
ちゃんとしたcodeをcompilerが生成してくれる。

networkで送る時は、相手のCPUによっては一貫しないことになるので、
protocolでorderを規定したり、negotiationしたりするわけだな。
もちろんその場合は、multi-byte character/stringとして定義する。
serial communicationであればbit orderも。

78 :デフォルトの名無しさん:01/09/10 23:39
>>76
まだ理解してないと思われ
>>75のワイド文字の方はエンディアンの問題が起こる

79 :厨房:01/09/10 23:50
>>78
でしょ?そういう事あるのかなと思っていたんですが。
じゃあひっくりかえる、という理解でいいの?

>>77
それで16bitとかを扱うときにはhto*、nto*を使うのでしょうか。

あ、シリアルではビット列を送る順番もですか。。。なるほど。

80 :デフォルトの名無しさん:01/09/11 07:27
>>79
Unicodeはエンディアンを考慮して読む必要がある。
リトルエンディアンで出力されたデータをビッグで読むときには
「ひっくり返す」必要があるし、逆もまた真なり。

が、ShiftJISならそんなもん関係なし。

81 :デフォルトの名無しさん:01/09/11 15:21
>>80
> が、ShiftJISならそんなもん関係なし。

なんでやねん…sparcでShiftJIS扱う時どうすんねん?
Wintelを暗黙に仮定しているわけ?

82 :デフォルトの名無しさん:01/09/11 16:27
>81
>>61 >>63 >>65 >>70

83 :デフォルトの名無しさん:01/09/12 04:18
思うんですが Unicode のエンディアン設計って良くないんじゃないでしょうか?
交換目的はビッグに統一しても良かったかもしれないと思うんですよね。
処理系と別のエンディアンならエンディアン処理しなくてはならないし
エンディアンの指定コードが入ったり、なかったときのことを考えると
煩雑で見返りが少ないんじゃないかと。
無ければならない、何か致命的な理由でもあるんでしょうか?
ビッグにまとめるとリトル派が、リトルにするとビッグ派が怒るからでしょうか。
複雑になるより統一して単純にしたほうが良かったような気がするのですが…。

84 :デフォルトの名無しさん:01/09/12 04:29
>83
アホ?

85 :83:01/09/12 04:36
よく知らないので、そう言わずに識者の方、教えて下さい。

86 :デフォルトの名無しさん:01/09/12 07:56
>>83
バカ?

87 :デフォルトの名無しさん:01/09/12 07:57
>83
>ビッグにまとめるとリトル派が、リトルにするとビッグ派が怒るからでしょうか。

これが真理。統一しようという話はあったがな。

88 :デフォルトの名無しさん:01/09/12 10:18
まさにガリバーのエンディアン争いを地で行ってる

89 :デフォルトの名無しさん:01/09/12 10:39
>>83
エンディアネスが気になる場合は、UTF-8にエンコードして交換する。
1文字の幅が16bitか32bitかという問題もあるので、
エンディアネスを統一しただけでは問題は解決しない。

90 :デフォルトの名無しさん:01/09/12 10:42
>>83
結局UTF8に落ち着いたんだからどうでもいいかと
プログラム内部でUCS2やUCS4で使ってようが関係ないし

91 :デフォルトの名無しさん:01/09/12 11:14
>>83
情報交換時の標準エンディアンを決めたとすると、
非標準エンディアン同士で交換すると、二回変換が必要。
DCE RPCのように交換前にnegotiationすれば、
変換が0回あるいは1回で済む。

というような理由もあったと想像するが、>>90の言うように意味が薄い。
何でも実現しようとするのは、大きい規格制定作業グループの特徴。

92 :new 名無し( );:01/09/12 15:01
みどるえんでぃあん

93 :83:01/09/13 04:07
皆さんご教示ありがとうございましたv

33 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)