文字コード結果が違うのはなぜでしょうか？

質問

文字コード結果が違うのはなぜでしょうか？

いつも参考にさせていただいております。ありがとうございます。
VBAにて、文字コード(16進表記)を取得したいのですが、
１．hex(ascw("あ"))

２．Dim ByteData() As Byte
　ByteData = "あ"
Debug.Print Hex(ByteData(0)) & Hex(ByteData(1))

の２通り行っているのですが、結果が違いました。
１．3042
２．4230
となってしまいます。
UNICODEのリトルエンディアン・ビックエンディアンの違いなのかとも思いましたが、
上記はどちらもVBAで行っているため、式によって扱いが違うとも考えられません。

この違いはなぜなのでしょうか？

ご教授よろしくお願いいたします。

回答No.1

kmee · ベストアンサー

ascwは"あ"のUnicodeのコードを返すので &H3042です。
このとき、メモリー上にどんな順番に並んでいるかは関係ありません。
メモリーから2バイト分読み出して16bitの整数にする段階で、LE/BEに合せた正しい順番にしているからです。

対して、2. の方は、"あ"というUnicode文字列のメモリー上での1バイト目,2バイト目がそれぞれ、ByteData(0),ByteData(1)になります。どちらが上位バイトになるかはシステム依存、ということになります。
リトルエンディアンなら1バイト目が下位の8bit(&h42)、2バイト目が上位の8bit(&h30)になります。

お礼

kmee様、ご回答ありがとうございます！

とても分かりやすかったです。

ところで、VBAはLE/BEどちらなのでしょうか？
今回の判定プログラムは、どちらもVBAに記述しているので、
１．「LE/BEにあわせた正しい順番」
２．「どちらが上位バイトになるかはシステム依存」
の考えが同じになると考えたのですが。。。

再度ご指導よろしくお願いいたします！

回答No.4

kmee

このような内部表現は、CPUが扱いやすいようにするのが一般的です。
よって、Windowsで使われているIntel系のCPUならリトルエンディアンを使うのが一般的です。

お礼

kmee様、再度ご回答ありがとうございます。

＞Windowsで使われているIntel系のCPUならリトルエンディアンを使うのが一般的
そうなのですね。ビックエンディアンのほうが分かりやすいので、こちらが一般的なのだと思っていました。

そして、
kmee様、BellBell様、notnot様、ご回答ありがとうございました。

皆様の情報により、すっきり解決させることができました！
これでプログラミングを進められます。
本当にありがとうございます！

皆様にありがとうポイントをつけたいところですが、
申し訳ありません。
最初に投稿してくださったkmee様にポイントをつけさせていただきます。

皆様本当にありがとうございました！

回答No.3

notnot

BE/LEというのは、ユニコード文字やCのint型データなどの複数バイトデータをバイト列に並べるときに出てくる概念なので、「"あ"の文字コードは何？」と聞かれたときはBE/LEは関係ありません。16進で3042です。

VBはBEかLEか？と聞かれると、x86アーキテクチャのCPUで動いているのでLEということですね。

お礼

notnot様、ご回答ありがとうございました！

＞BE/LEというのは、ユニコード文字やCのint型データなどの複数バイトデータを
＞バイト列に並べるときに出てくる概念なので、
＞「"あ"の文字コードは何？」と聞かれたときはBE/LEは関係ありません。16進で3042です。

「概念」というところでなるほど！と思いました。
あくまでも16進で3042なのですね。
BE/LEが変わると、「"あ"の文字コード」そのものが変わるものだと思っていました。

＞VBはBEかLEか？と聞かれると、x86アーキテクチャのCPUで動いているのでLEということですね。
こちらも納得です！

ありがとうございました！

回答No.2

BellBell

ご推察の通り、リトルエンディアンが理由です。

実際には動きませんが、
Debug.Print Hex("あ")
と書いてもし動作した場合、4230が返る事が予測されます。

おそらく、人間が理解しやすいのはビッグエンディアンであるという理由で、アスキーコード(表)はビッグエンディアンで書かれているのでしょう。

そこで1と先の動作しない例と比較すると
Debug.Print Hex(AscW("あ"))→3042
Debug.Print Hex("あ")→4230

AscWは、人間が(直感的に)理解しにくいリトルエンディアンの生の文字列データを、人間の理解しやすいビッグエンディアンのアスキーコード表通りに変換する機能も持った関数と考える事ができます。

そこで、貴殿の質問の2に戻った場合、生の文字列データを直接扱っている為、リトルエンディアンで結果が返っているという事になります。

あくまでわかりやすさを優先して、正確さ等は無視しています。

お礼

BellBell様、ご回答ありがとうございます!

>AscWは、人間が(直感的に)理解しにくいリトルエンディアンの生の文字列データを、
>人間の理解しやすいビッグエンディアンのアスキーコード表通りに変換する機能も持った関数と
>考える事ができます

なるほどですね！変換してくれる、ということで納得できました！

ありがとうございました！