- ベストアンサー
UTF-8とASCIIコードの互換性について
- UTF-8とASCIIはそのASCIIコードの範囲のおいて互換性を持っています。
- ただし、UTF-8で符号化される際にはUnicode上のコードポイントの値に復元されるため、互換性がなくなることがあります。
- 具体的には、UTF-8で符号化した際のバイト列には上位バイトが付加されるため、ASCIIと一致しないUnicodeコードポイントが得られることがあります。
- 1000vicki
- お礼率17% (40/226)
- その他（プログラミング・開発）
- 回答数9
- ありがとう数1
- みんなの回答 （9）
- 専門家の回答
質問者が選んだベストアンサー
その他の回答 (8)
- salsberry
- ベストアンサー率69% (495/711)
- Yune-Kichi
- ベストアンサー率74% (465/626)
- notnot
- ベストアンサー率47% (4903/10364)
No1,3です。 No3の補足について。 「文字→文字コード」の変換をunpack、その逆をpackと表現しているのであれば、その通りです。
補足
このひとつ前の回答の内容ですが >英字の A を、0x41 というコードで表現すると言う意味でUS-ASCIIもUTF-8も同じです。 これはたとえば CGIの類をUTF-8で書いた時、明確にいうと#coding: utf-8 と明示してスクリプトファイルを書いた時 そのファイル内で変数なりリテラルなりで記述したアスキーコード内の文字に関しては hoge = "A" とあった時、おそらくどの言語でもそうだと思うのですが、スクリプトファイル内の 特定の文字列はそれぞれ個別にエンコーディング情報を持つと思います。（※言語によっては持たいない？） hogeUtf8 = hoge #utf-8という文字コード情報をもつリテラル hogeAscii = hoge. toAsciiFromUtf8() #メソッドは架空です。 とした場合 hogeUtf8はUTF-8 hogeAsciiはUS-ASCII と異なる文字コードだけども、 こ両変数は スクリプトファイルがASCIIでかかれていても、UTF-8でかかれていても 動作する。 これを実現するために UTF-8のアスキー範囲内の文字はUS-ASCIIと同じ符号化を行なっているという 解釈でおｋ？
- Yune-Kichi
- ベストアンサー率74% (465/626)
えーっと，「符号化文字集合」と「エンコーディング」の関係がわかっていないのでしょう。 # 規格によって言葉が色々異なるのですが……。 まず，「文字集合」が存在します。 Unicodeなどの他に，常用漢字表なども「文字集合」です。 数値が振られていないため，コンピューターで取り扱う上では「文字集合」は現実的には使われませんが。 そして，「文字集合」に数値を振った物が「符号化文字集合」です。 Unicode, JIS X 0208やUS-ASCIIは「符号化文字集合」です。 Unicodeのコードポイントとは，この「符号化文字集合」に振られた数値のことになります。 JIS X 0208では区点値です。 「エンコーディング」は「符号化文字集合」をどのようにコンピューター上で取り扱うか，という取り決めです。 UTF-16, UTF-8，Shift_JISやUS-ASCIIは「エンコーディング」です。 US-ASCIIは「符号化文字集合」であり「エンコーディング」でもあります。 で，「符号化文字集合」にISO/IEC 10646-1 (≒Unicode) で，「エンコーディング」はShift_JISということもよくあります。 # HTML 4.01のShift_JIS文書など。HTML 4.01は文字集合がISO/IEC 10646-1と規定されています。 > UTF-8とASCIIはそのASCIIコードの範囲のおいて互換性を持ちます。 というのは，「エンコーディング」の取り決めの話です。 Unicodeが文字集合である場合，U+0000 - U+007Fの範囲はUS-ASCII/UTF-8ともに0x00 - 0x7Fに符号化されます。
補足
別の方の回答補足にも書いたのですが、 >Unicodeが文字集合である場合，U+0000 - U+007Fの範囲は >US-ASCII/UTF-8ともに0x00 - 0x7Fに符号化されます。 これは hoge ="A"とあった場合 UTF-16だった場合 0x0041と符号化されますね？ このhoge(0x0041)っていう変数をpack()やGetString()などを用いてASCIIコードとして Aという文字に復元 （※これが気になってますが、符号化されたバイト列を再度文字集合の文字に 戻す場合の表現・いいまわしって復号化というような言い方をするのでしょうか ？） することはできないけれども、 hoge = "A" これが、UTF-8の場合、 0x41となって これは ASCIIコードにおける【A】という文字を符号化した値と同一だから コンピューター的にはこの0x41がもともとASCIIの文字を符号化したものなのか それともUTF-8から符号化されたものなのかという点問題ではないということですかね？ ※>US-ASCIIは「符号化文字集合」であり「エンコーディング」でもあります。 どうやら見落としていたのはここだったようです。 ASCIIの場合、ASCII文字集合上のコードポイントと符号化した際のバイト値は同一なのですね。
- Gotthold
- ベストアンサー率47% (396/832)
- notnot
- ベストアンサー率47% (4903/10364)
No1です。 コードポイントを求めた時点ですでにUTF-8では無くなっていますけど。 英字の A を、0x41 というコードで表現すると言う意味でUS-ASCIIもUTF-8も同じです。
補足
>英字の A を、0x41 というコードで表現すると言う意味でUS-ASCIIもUTF-8も同じです。 あー・・・。 ひょっとしてこう考えるといいのかな？ 0x41（何かしらの方法でAという文字をunpackしたあと）というバイト列を 再度なにかしら言語でpackして任意の文字コードの文字集合上のAに復帰させる場合に 0x41はpackしてAという文字に戻すにしてもASCIIコードとしても復帰させれるし、 UTF-8エンコーディングとしても復帰できるといった感じ。 うーん。 あるいはUTF-8のAをunpackしても0x41が返ってくるし US-ASCIIで記述したファイルのAでもunpackすると0ｘ41が返ってくる。 こう捉えたほうがいいのでしょうか？
- Gotthold
- ベストアンサー率47% (396/832)
> 結局Unicodeコードポイントに直した場合【00】という上位バイトが無駄にくっついてきて【0x0041】となり 上位に00をつけた時点でUTF-8じゃないよね。 あなたはUTF-8じゃないものとASCIIコードを比較して互換性がないと言っているだけ。
補足
>上位に00をつけた時点でUTF-8じゃないよね。 いえ、ですからUTF-8はUnicodeの文字集合上の符号位置をそれぞれ1byteや2byteあるいは3byteのバイト列に符号化することをいいますよね？ この点はお分かりですよね？ で2byteや3byteのマルチバイトに符号化されたバイト列は Unicode上の符号位置に復帰させないとどのような文字をいみしているかがわからないわけですよね？ そこでRFC等で定義されている計算仕様で例えば【E38182】というバイト列を【3042】 というUnicode上の文字集合に復帰させると思います。 でこれは、1byteで符号化されたバイト列も例外ではないですよね？ とするならば、【41】というバイト列もUnicode上の符号位置へ復帰させるために Unicode上の符号位置とバイト数をあわせるために【00】を付ける必要があるのでは？ という意味です。
- notnot
- ベストアンサー率47% (4903/10364)
Aを0x0041で表現するのはUTF-16であり、UTF-8ではありませんので、関係ありません。 ユニコードの A (U+0041) を 0x41 として表現するのがUTF-8です。 ユニコードの A (U+0041) は ASCIIの A (0x41) と同じ文字であると定義されていて、UTF-8ではそれが同じコードで表現されているというのが互換性です。 ＞UTF-8っていうことは最終的にはUnicode上のコードポイントの値・・・つまり0x0041という値に復元？（というのでしょうか）するわけですよね？ このあたりが意味不明の文になってしまっています。「最終的」とは？ もしかして、画面表示のためにフォントファイルの中からAに相当するフォントデータを探してくるということを言ってますか？それは実装依存でしょうね。
補足
>ユニコードの A (U+0041) を 0x41 として表現するのがUTF-8です。 Unicodeのコードポイント上にあるU+0041という符号位置をUTF-8の符号化定義に則って Aという文字は符号化されて0x41というバイト値であらわされているわけですよね？ 例えば【あ】という文字の場合Unicode上ではU+3042となっているコードポイントを UTF-8の符号化規則にのっとって【e38182】という16進数の3byte値になります。 ただこれは、符号化した結果であって、【e38182】=>【U+3042】ともとのUnicode上のコードポイントU+3042を参照する必要があるとおものですが 【A】という文字も【41】=>【U+0041】の位置に復元する必要があるのでは？と思ったのです。 ただ、 >ユニコードの A (U+0041) は ASCIIの A (0x41) と同じ文字であると定義されていて、 >UTF-8ではそれが同じコードで表現されているというのが互換性です。 とありますが？ 例えばUTF-8の UCS-4 範囲 (hex.) UTF-8 8 ビットバイトシーケンス (binary) 0000 0000-0000 007F 0xxxxxxx 0000 0080-0000 07FF 110xxxxx 10xxxxxx 0000 0800-0000 FFFF 1110xxxx 10xxxxxx 10xxxxxx 0001 0000-001F FFFF 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx 0020 0000-03FF FFFF 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 0400 0000-7FFF FFFF 1111110x 10xxxxxx ... 10xxxxxx 【あ】という日本語はUTF-8という符号化仕様であれば、３行目の 0000 0800-0000 FFFF 1110xxxx 10xxxxxx 10xxxxxx が当てはまります。 これを元にUnicode上のU+3042という符号位置を求める計算をするわけですが・・・。 では、【A】の場合は1行目の 0000 0000-0000 007F 0xxxxxxx に当てはまります。 UTF-8による符号化の場合で、かつ1byte以下の数値・・・つまり01111111以下の数値の場合は Unicode上のコードポイントを参照せず、そのままASCIIコードを直接参照するということですか？ もっと言えば、 UTF-8による符号化は0～01111111（0xxxxxxx）の範囲はUS-ASCIIの文字集合参照 それ以降（110xxxxx 10xxxxxx ～）はUTF-8の符号化仕様にのっとって符号化する という捉え方でよいのでしょうか？
補足
>その際、元のファイルで'A'を表していた文字は内部表現でも >やはり'A'を表すものとして処理されます。そういう意味で互換性があります。 なるほど、符号化した値がASCIIとUTF-8で同じだから相互変換ができるというだけでなく ASCIIの0x41 と UTF-16における0x0041も同じAを指すように文字コード上でも定義しているというプログラム的な互換性だけでなく、仕様上の互換性も兼用しているという意ですか。 その点は頭から抜け落ちていました。 なるほど。すこし疑問が氷解しました。