Humanity

UnicodeとUTF-8の違いは？

2ch, 文字コード

という2chのスレがかなり勉強になったのでまとめ。

少しでも有用だと思ったものは載せてあるので結構長いです。

Unicodeのような文字集合(符号化文字集合？)やUTF-8のようなエンコーディング方式に限らず色んな文字コードにまつわる話があります。

たびたび話が繰り替えされますがそれは確認ということで。

(元スレ)

追記：簡単にまとめました。

1 ：デフォルトの名無しさん：2007/04/30(月) 20:02:37

ビッグインディアンとかなんとかかんとか

3 ：デフォルトの名無しさん：2007/04/30(月) 20:05:48

また、頭の悪そうなスレが・・・

>>1

それは魚とマグロの違いを訊ねるようなもんだ。

4 ：デフォルトの名無しさん：2007/04/30(月) 20:06:49

魚と鮪というよりは、魚と刺身の違いのような気がする。

5 ：デフォルトの名無しさん：2007/04/30(月) 20:09:31

俺もわからん。

誰か詳しく説明してよ。

6 ：デフォルトの名無しさん：2007/04/30(月) 20:11:24

>>5

UNICODE→魚

UTF-8→刺身

7 ：デフォルトの名無しさん：2007/04/30(月) 20:14:40

Unicodeは文字の集合で、UTF-8はそれに(語弊があるが)番号を振る方法の1つ。

8 ：デフォルトの名無しさん：2007/04/30(月) 20:15:39

UNICODE

• 文字集合：１種類
• 符号化方式：UTF-8, UTF-16BE, etc

9 ：デフォルトの名無しさん：2007/04/30(月) 20:19:17

小学生でもわかるように！

10 ：デフォルトの名無しさん：2007/04/30(月) 20:28:13

Unicode => クラスメート

UTF-8 => 身長順に並べー、名前の順に並べー、誕生日の順に並べー

14 ：デフォルトの名無しさん：2007/04/30(月) 20:32:52

unicode => 国民

UTF-8 => 住基コード

11 ：デフォルトの名無しさん：2007/04/30(月) 20:30:48

自分はUCSとの違いがわからん

19 ：デフォルトの名無しさん：2007/04/30(月) 20:51:13

>>1

そもそもUTF-16やUTF-32と違って

バイトストリームのUTF-8にはエンディアン問題はない

UTF-8のBOMはエンディアン対策ではない

>>11

UnicodeとUCSは同義といってもいいのでは

20 ：デフォルトの名無しさん：2007/04/30(月) 20:53:30

UNICODEって文字セットのことなのか、

文字セット＋符号化方式たち　のことなのかどっち？

21 ：デフォルトの名無しさん：2007/04/30(月) 20:57:06

文字それぞれにも番号は振られているが、これは日本語の文字でいうと

区点コードみたいなもんだな。

39 ：デフォルトの名無しさん：2007/05/01(火) 10:00:45

Unicode： Unicode Consociumの制定した文字集合。(U+0 - U+1FFFFF)

UTF-8/16/32： Unicode Transformation Format。Unicodeの符号化方式。

　UTF-8： 外字が無いため4Byte長まで。

　UTF-16： UCS-2＋サロゲートペア＋バイナリ符号化。

ISO/IEC 10646： 国際文字集合規格（群、面、区、点）。制定前にUnicodeが出て来たためそのコンパチに。Unicodeの文字はこのうち0群16面まで。

UCS-4： ISO規格の31bit符号集合。規格化文字集合＋外字。

UCS-2： ISO規格の16bit符号集合。基本多言語面のみ。（例：U+1234）

UTF-8/16/32： UCS Transformation Format。UCSのバイナリ符号化方式。（例：0x12 0x34）

　UTF-8： Unicodeの方と違い6Byte長まであり。

67 ：デフォルトの名無しさん：2007/05/01(火) 21:58:43

>>39

UTFって、２種類あるんだ。Windowsのはどっちなんだろ？

というかそもそも、UCS-?とUTF-?の違いが良く分からんが。

75 ：デフォルトの名無しさん：2007/05/01(火) 22:44:55

>>67

Unicodeコンソーシアムが作った文字集合がUnicode。

ISO 10646で定義された文字集合がUCS。

両者は、互換になるように働きかけあっているので、今のところ同じ文字集合と見なして問題ない。

一時期はUnicodeを符号化するのがUTF-?、UCSを符号化するのがUCS-?だったと俺は思うが、

今はISO 10646にUTF-8/16も収録されているらしい。

UTF-8/16の正式名称はUnicodeとUTFで違うが、実際の符号化の方法は同じで、

基の文字集合も上に書いたとおり同じだからどちらのUTF-8/16も実用上基本的に違いはない。

51 ：デフォルトの名無しさん：2007/05/01(火) 18:48:26

文字コードもOSI参照モデルみたいな階層構造の概念が必要だと思うんだよな

↓みたいな感じで

表示字形（グリフ、フォント）

文字入力（物理デバイス、IME）

符号化方式

文字集合

自然言語

53 ：デフォルトの名無しさん：2007/05/01(火) 19:50:46

自然言語ってのは普段使ってる言葉な

そこで使われてる文字を集めたのが文字集合ってヤツ

英語だとラテン文字a-z,A-Zと数字、記号なんかが文字集合になるわけ

日本語だと異体字なんかの問題があって集合を作るのが難しいんだけど

（土吉／士吉とか、はしご高／くち高みたいな）

とりあえず作って使われてるのがJIS X 0208文字集合ってヤツ

いわゆるJIS第1水準、第2水準漢字ね

54 ：デフォルトの名無しさん：2007/05/01(火) 19:53:30

他の国でも独自に文字集合を作ってて

それらをまとめてひとつの大きな文字集合に

しちゃおうってのがUnicodeの考え方なの

ここでいうUnicodeはUCS(Universal Character Set)と

同じと思ってもらっていい

55 ：デフォルトの名無しさん：2007/05/01(火) 19:58:06

その文字集合を実際にコンピュータ上のゼロイチで

対応させる方法のことを符号化方式っていうの

JIS X 0208文字集合を符号化する主な方法として

EUC-JP、ShiftJIS、ISO-2022-JP(JIS)

っていう３つがあって文字化けとかの問題が出てくるんだけどね

56 ：デフォルトの名無しさん：2007/05/01(火) 20:07:29

ASCIIなんかだと文字集合と符号化方式が明確に区別されてなくて

規格として「この文字はこのゼロイチの組合せ」ってのが決められてたりして

そこらへんが文字集合と符号化方式を混乱する一因ではあるんだけど

UTF-8ってのはUCSを符号化する方法のひとつっていうだけ

それ以上でもそれ以下でもない

じゃあ、何が混乱の元かっていうと

Unicodeって言葉がUCS（文字集合）だけを指す場合と

符号化方式まで含めて使われる場合があるのだな

区別が付いてる人はいいんだけど、区別が付いてない人が

書いたり読んだりしてるとエスパー助けて状態にｗ

57 ：デフォルトの名無しさん：2007/05/01(火) 20:14:21

UCSという規格の存在を知らず、

UCSという言葉を単にUCS-2やUCS-4などといった符号化形式の

総称としか思っていない奴いるだろ。

58 ：デフォルトの名無しさん：2007/05/01(火) 20:32:56

なるへそ。

そういうことか。

Unicodeが単に世界中の文字を集めたもので、その1文字1文字にゼロとイチ

の組み合わせ対応させたものが、UTF-8と。

なんかちょっとわかったよ。

40 ：デフォルトの名無しさん：2007/05/01(火) 10:19:34

メモ帳でテキストを保存するときに

UnicodeやUTF-8を指定できるが、

Unicodeで保存する

としたときは

UTF-8で保存したのかUTF-16で保存したのか

わたしたちにはわからなくないか？

42 ：デフォルトの名無しさん：2007/05/01(火) 12:07:35

>>40

Microsoft Windows では "Unicode" といえば UTF-16 のリトルエンディアンという暗黙の了解になっている。

52 ：デフォルトの名無しさん：2007/05/01(火) 19:41:11

とりあえず、M$はUTF-16をUnicodeと呼ぶのを自重すべきだな。

まるでUTF-16だけがUnicodeとしたいようだ。

SJIS(MS漢字コード)を日本語テキストの標準にしたいかのように。

80 ：デフォルトの名無しさん：2007/05/01(火) 23:05:23

JISX0213（ニアリイコールVistaの文字セット）でサロゲートペアって

ハマりそうだよな。

string s="○";

assert( s.length==1 );

これが成り立たない場合があるっていうのも詐欺みたいな。

83 ：デフォルトの名無しさん：2007/05/01(火) 23:18:50

>>80

「が」とかなら判るけど、○も文字的に２文字になるケースってあるの？

サロゲートペアだから2だとかでは、バイト長だから4という思想から

変わってないような。文字としてなら1以外ありえないと思うので、

そのassertが不成立ならstringクラスのバグ（か、lengthのバグ仕様）なんでは？

86 ：デフォルトの名無しさん：2007/05/02(水) 00:33:38

>>83

いや、サロゲートペアだから２になるんだわ。

とりあえず.NETはそうなる。

http://msdn2.microsoft.com/ja-jp/library/system.string.length(VS.80).aspx

> Length プロパティは、このインスタンス内の Char オブジェクトの数を返します。Unicode 文字の数ではありません。

Javaもそうなるみたいだけど。

Java

http://java.sun.com/j2se/1.5.0/ja/docs/ja/api/java/lang/String.html#length()

> この文字列の長さを返します。長さは文字列内の 16 ビット Unicode 文字の数に等しくなります。

JavaScriptも多分？

87 ：デフォルトの名無しさん：2007/05/02(水) 01:48:47

>>86

げーっ、そうなんだ。

「16ビットUnicode文字」の数なんて何の意味もないのにな。

「言語的な文字」の数かどうかだけが問題で、それ以外は

バイト数を返すのと同じこと（＝同じ問題を抱える）なのに。

91 ：デフォルトの名無しさん：2007/05/02(水) 05:56:27

>>87

プログラム組む人は、バイト数が欲しい

（書面の）文を書く人は、文字数が欲しい

strcatとかの標準関数が全滅するUTF-16なんて誰が考えたんだろな？

しかも、MSは標準にするし…

97 ：デフォルトの名無しさん：2007/05/02(水) 10:44:11

16bitで足りないのはすぐに判ったろうけど、似た文字はまとめちゃえば入るだろと思ったんだろな

でも、それじゃ納得しない人が出てくるのは当然。

24bitあれば足りたろうから24bitで定義しておけば最善だったかもな

それにしても \ の扱いが醜い

98 ：デフォルトの名無しさん：2007/05/02(水) 10:54:06

7bitで足りてた人間が考え始めたコトだからｗ

JIS X 0201のGRはISO646ではあるけどASCIIではないからね

バイナリ的に区別付かないからフォント変えれば同じだけど

ASCIIにスラッシュとバックスラッシュが採用されたのは

当時のプログラム言語で使われてた論理記号の∧と∨を表すためらしい

99 ：デフォルトの名無しさん：2007/05/02(水) 11:11:56

歴史的な経緯はこのページが参考になる

ttp://www.horagai.com/www/moji/code4.htm

100 ：デフォルトの名無しさん：2007/05/02(水) 11:18:53

んじゃ、文字数とかバイト数とかのお話の説明なぞ

UTF-16っていうので16bitで全部の文字を表そうと思ってたのね

でも実際に作り始めたら16bitじゃ全然足りなかったから

その分は16bitをふたつ使って32bitで表しますよっていうコトにしたの

それがサロゲートペアって呼ばれてるモノね（ふたつ組だからペア）

そんなわけで、UTF-16は基本的に16bitで一文字なんだけど

例外的にサロゲートペアだけ32bitで一文字っていう

ヘンテコリンな規格になっちゃったわけ

サロゲートペアの処理がちゃんとされてないプログラムだと

16bitなら一文字、32bitなら二文字っていう風に

機械的に文字数を判断しちゃって困るねっていうこと

101 ：デフォルトの名無しさん：2007/05/02(水) 11:27:33

言ってみればサロゲートペア非対応のプログラムでサロゲートペアを含む文字列を扱おうということは、

マルチバイト文字列非対応のプログラムでマルチバイト文字列を扱おうとするのと同じこと。

まあShift_JISのような駄目文字問題が生まれないのはましだけど。

102 ：デフォルトの名無しさん：2007/05/02(水) 11:28:30

足りない領域に文字を突っ込むという点では

JIS X 0201のカタカナ集合に通じるモノがあるかも

（いわゆる半角カナのコトね）

自然な感覚だと濁点・半濁点が付いてるのも一文字だし

付いてなくても同様に一文字だと思うんだけど、

文字入れる場所がないから濁点・半濁点付き文字は

例外的に8bitふたつで表現してねっていう

「こんにちは」と「こんばんは」

一般的な感覚としては両方とも五文字だけど

8bitカタカナの世界では

「ｺﾝﾆﾁﾊ」は五文字で「ｺﾝﾊﾞﾝﾊ」は六文字になる

103 ：デフォルトの名無しさん：2007/05/02(水) 11:29:18

UTF-16で

1文字16bitだとして1文字32bitのものもあるってことは判った

流石に混在はしないの？

104 ：デフォルトの名無しさん：2007/05/02(水) 11:41:16

>>103

D800-DB7FとDB80-DBFFが上位サロゲート、DC00-DFFFが下位サロゲートの領域になっていて、

任意のUTF-16 1バイト（= 2オクテット）を取り出しても、

それがサロゲートでないか、上位サロゲートか、下位サロゲートかは区別が付く。

駄目文字の問題が起こらないという点において、ASCIIとの対比で言えばShift_JISよりもEUC-JPっぽいという感じ。

EUCは、あるコードがマルチバイトのどこになるかの区別が付かなかった気がするが。

105 ：デフォルトの名無しさん：2007/05/02(水) 11:44:46

>>104

解説ｻﾝｸｽ

なるほど　なんかUTF-16が判ってきた

でもぶっちゃけ存在は知ってるけど使ったことがない俺がいる

108 ：デフォルトの名無しさん：2007/05/02(水) 12:44:27

DOMStringの長さはUTF-16での符号単位数ってことになってるんだよな。

これ決めた奴、死ぬべきだと思うわ。

109 ：デフォルトの名無しさん：2007/05/02(水) 16:42:11

>>108

W3CでDOMを規格化するときには、もうJavaScriptもJavaも16bit単位ベー

スの文字列処理になってしまっていたので、仕方なくそれらに合わせた

んだと記憶してます。

110 ：デフォルトの名無しさん：2007/05/02(水) 20:02:03

7bit文字の場合

0xxx xxxx

8-11bit

110x xxxx 10xx xxxx

11-16bit

1110 xxxx 10xx xxxx 10xx xxxx

unicodeの部分がxxxx

111 ：デフォルトの名無しさん：2007/05/02(水) 21:38:28

1バイトだけ見た場合、

0xxx xxxxならそのバイトだけで1文字

1xxx xxxxなら

• 10xx xxxxなら多バイト文字の2バイト目以降(先頭は遡って11xxなバイト)
• 11xx xxxxなら多バイト文字の先頭バイト
  • 110x xxxxなら2バイト文字の先頭バイト
  • 111x xxxxなら3バイト文字の先頭バイト

と判別できるわけだな。

112 ：デフォルトの名無しさん：2007/05/02(水) 21:57:31

>>110-111はUTF-8の場合な

184 ：デフォルトの名無しさん：2007/05/29(火) 20:09:42

シフトジスは shift-jis

だけど

ジスは iso-2022-jp

こういったので迷うのは俺だけ？

186 ：デフォルトの名無しさん：2007/05/29(火) 20:47:39

http://e-words.jp/w/Shift20JISE382B3E383BCE38389.html

http://e-words.jp/w/ISO-2022-JP.html

.NETのエンコードの話なんだけど、ジスコードの規格っていろいろあって、

iso-2022-jp 日本語 (JIS)

csISO2022JP 日本語 (JIS 1 バイト カタカナ可)

iso-2022-jp 日本語 (JIS 1 バイト カタカナ可 - SO/SI)

迷うよな

187 ：デフォルトの名無しさん：2007/05/30(水) 00:17:09

いわゆるシフトJISだってShift_JIS, Shift_JIS-2004, CP932 (Windows-31J)と種類豊富

大体CP932以外使わないけどな

204 ：デフォルトの名無しさん：2007/05/31(木) 07:56:46

16bitじゃ絶対無理って最初からわかってたのに、

16bitに無理やり収めようなんて考えて自爆した欧米人は馬鹿すぎ

205 ：デフォルトの名無しさん：2007/05/31(木) 09:59:32

8bitで十分だったから16bitにするだけでもビビってたのさ

207 ：デフォルトの名無しさん：2007/05/31(木) 13:38:31

アメリカに限れば、7bitででも足りてたんだよね？

208 ：デフォルトの名無しさん：2007/05/31(木) 14:06:20

5bitでも足りるわな

ttp://www.trans-usa.com/mike/BaudCode.htm

273 ：デフォルトの名無しさん：2008/02/12(火) 10:54:25

WindowsXPのメモ帳で保存しようとすると

アンジーがデフォルトになってるんだけどシフトジスってのがみあたらないんだが。でも日本語ドキュメントがうまく保存される。

つまり、

アンジー = シフトジス

だと思う。

274 ：デフォルトの名無しさん：2008/02/12(火) 17:08:33

メモ帳の選択肢のANSIというのは、

現在使用中の言語のANSIコードページの文字コードということ。

日本語の場合、それはコードページ932、つまりMicrosoftのShift_JIS。

言語の設定を変えれば、当然ANSIで保存するときの文字コードも変化する。

275 ：デフォルトの名無しさん：2008/02/12(火) 17:30:56

>>274 そういう意味だったのか !

246 ：デフォルトの名無しさん：2007/10/06(土) 04:33:30

けっきょくいまだにスレタイトルの疑問をだれもがなｔっとくできるほどうまく解説した人があらわれない

247 ：デフォルトの名無しさん：2007/10/06(土) 11:19:13

>>246

>8で充分だろ。Unicodeの符号化方式の一つがUTF-8。

249 ：デフォルトの名無しさん：2007/10/09(火) 18:44:37

>>247

いや、Unicodeは単なる文字集合（レパートリ）ではなく、

あくまでも符号化文字集合だろ。

250 ：デフォルトの名無しさん：2007/10/09(火) 19:20:19

Coded Character Set: Unicode

Character Encoding Form: UTF-8, UTF-16, UTF-32

Character Encoding Scheme:

UTF-8, UTF-16, UTF-16BE, UTF-16LE, UTF-32, UTF-32BE, UTF-32LE

259 ：デフォルトの名無しさん：2008/02/04(月) 14:32:42

unicodeとutf-8の違いは

50音と平仮名の違いと一緒だろ

260 ：デフォルトの名無しさん：2008/02/04(月) 15:59:19

utf-16が片仮名？

261 ：デフォルトの名無しさん：2008/02/04(月) 16:08:46

片仮名でもローマ字でもなんでもいいよ

一つ一つマッピングする意味は無いと思うが

263 ：デフォルトの名無しさん：2008/02/06(水) 08:04:57

50音は平仮名でも片仮名でもないだろ。

読み方を定義したのが50音で、それに割り当てるのが平仮名であったり

片仮名なんだから。

264 ：デフォルトの名無しさん：2008/02/07(木) 01:43:44

世界中の文字を表わせる Unicodeってのを定義しました。

じゃあそれを2オクテットで表現しよう→UCS-2

でも他の文字コードと互換性ないしいちいち全部に2オクテット使うのは不便だから

よく使う文字を1オクテットに対応させて使わないのは2,3,4オクテットに分けて符号化しよう。

これでASCIIコードと互換性できたしよく使う文字は少ないオクテットで表現できる。→UTF-8

でもUnicodeって2オクテットじゃ表現しきれなくなってます。

じゃあ4オクテット(実際は31ビット）使おう。→UCS-4

4オクテットじゃ長すぎるからよく使う文字を以下略で分けて16ビット符号化しよう。

UCS-2の範囲はそのまま表わそう、不足しているUCS-4の部分はあんまり使わないし符号2つを組み合わせて32ビットで表わそう。

内部がややこしくなったけどUnicode全部表現できるからいいよね。→UTF-16

っていう感じの認識しかないな俺は。

265 ：デフォルトの名無しさん：2008/02/07(木) 02:55:54

どっちかというとこんな感じ。

32ビット化してUCS-4/UTF-32作った。

けど、今までのUCS-2なシステムどうしよう？

じゃあマルチバイトっぽいことしよう→UTF-16

271 ：デフォルトの名無しさん：2008/02/12(火) 06:48:24

UCS-2とUTF-16の違いがわからない

272 ：デフォルトの名無しさん：2008/02/12(火) 08:14:34

サロゲートペアでの拡張があるのがUTF-16、それがなくて16ビットだけなのがUCS-2

276 ：271：2008/02/12(火) 23:05:35

>>272

では、Windowsの内部コードというか、hogehogeW系のUNICODE APIは、

UCS-2かUTF-16なのでしょうか？

277 ：デフォルトの名無しさん：2008/02/12(火) 23:10:22

Windows 2000以降はUTF-16

それ以前はUCS-2(つまりサロゲートに対応していなかった)

278 ：271：2008/02/12(火) 23:49:03

サロゲートがいまいちわからん

2バイトで足りないから、上位、下位にわけたってことは、

UCS-2が2バイトとで、サロゲートのあるUTF-16は上下合わせて4バイトってこと？

279 ：デフォルトの名無しさん：2008/02/12(火) 23:58:17

そうだよ

280 ：デフォルトの名無しさん：2008/02/13(水) 00:04:43

>>278

単に未使用領域の2文字分を組み合わせて使ってUCS-2に無い分の文字を表わそうというだけの話だから

・UCS-2 → そもそもその文字が無い

・UTF-16→ その部分だけ4バイト。UCS-2にもある文字は2バイト

という事になる

281 ：271：2008/02/13(水) 04:00:14

>>280

なるほど足りないところだけ4バイトか

つまり、可変長なのね。

2バイト固定かと思ってたよ＞UTF-16

へえ

283 ：デフォルトの名無しさん：2008/02/13(水) 23:46:44

>>281

そう。だからUTF-16の２バイトの部分がUCS-2と同じっていうメリットがあるんよ。

４バイト部分はあんまり使わない部分だからサロゲートペアっつう２つ合わせる方式で表わしてる。

284 ：デフォルトの名無しさん：2008/02/14(木) 03:42:37

UCS-2=文字コード、UTF-16＝文字エンコーディング

じゃなかったっけ？

UTF-16はバイト並びにリトルとビッグがあるし、BOMが引っ付いたりするし。

285 ：デフォルトの名無しさん：2008/02/14(木) 08:16:40

UCSは文字集合。

UTFはエンコーディング。

文字コードというあいまいな語はこういう議論では避けるべき。

286 ：デフォルトの名無しさん：2008/02/14(木) 08:20:31

>UTF-16はバイト並びにリトルとビッグがあるし、BOMが引っ付いたりするし。

Unicodeではエンコーディングをencoding formとencoding schemeの二段階に

分けていてそのへんややこしいことになってる。

292 ：デフォルトの名無しさん：2008/02/14(木) 15:26:33

>>284

UCSは文字集合。

そしてその文字集合から2バイトで表せる部分を切り取ってきて

そのまんま使うのがUCS-2

それを拡張して使用できる文字範囲を広げたのがUTF-16

UTF-8は別のアプローチの符号化方法

287 ：デフォルトの名無しさん：2008/02/14(木) 10:39:55

　国試では、｢UNICODEとは、全ての文字体系が収まる"2byte"の文字コード｣というのが正解答だったりする件。

いつからバイト長が固定されたんだよタコ。

288 ：デフォルトの名無しさん：2008/02/14(木) 10:48:36

3.0未満のUnicodeかよorz

314 ：デフォルトの名無しさん：2008/02/20(水) 12:29:34

>>287

Unicodeは規格/標準の名前なのになあ。

検索とか比較とか符号化とか、文字に関する処理について書いてある。

http://www.unicode.org/glossary/#unicode

http://www.unicode.org/faq/basic_q.html#a

289 ：デフォルトの名無しさん：2008/02/14(木) 11:09:02

2byteだったら1.xじゃない？

293 ：デフォルトの名無しさん：2008/02/14(木) 21:00:42

>>289

それ以前に1バイト=8ビットとは限らない

294 ：デフォルトの名無しさん：2008/02/14(木) 21:04:49

どういう場合に１バイト８ビットじゃなくなるの？

295 ：デフォルトの名無しさん：2008/02/14(木) 21:13:58

マシンがPDP-11だったりした場合

301 ：デフォルトの名無しさん：2008/02/16(土) 01:39:08

>>295

PDP-11 は 16bit マシンだぞ．DEC-10/20（36bit マシン）のことか？

302 ：295：2008/02/16(土) 08:58:39

すまん

>>301 それです

311 ：デフォルトの名無しさん：2008/02/20(水) 02:18:31

9bitはPDP-10だろ。過去にかなり真面目に議論されたし、ちゃんとRFCも出てるぞ。

http://www.rfc-editor.org/rfc/rfc4042.txt

>306の言うとおり、昔は１バイト6bitだってあった。ISO646だって、7bit の他に6bit版の文字コードも

規定されてたし。近年の改正で6bit文字コード規定は残念ながら消滅してしまったけどね。

296 ：デフォルトの名無しさん：2008/02/14(木) 21:26:35

JIS X 0208/0213の規格名ではわざわざ「7ビット及び8ビットの…」と言ってるだろ。

1バイトが8ビットとは限らないからだ。

それに対してUCSは>>291にあるとおり"Universal Multiple-Octet..."で

8ビットであることを明確化している

326 ：デフォルトの名無しさん：2008/03/07(金) 11:56:50

unicodeに含まれる文字には番号はついてるんでしょ。

どうしてそれは使えないの？

327 ：デフォルトの名無しさん：2008/03/07(金) 11:59:19

>>326

どこからの話の流れか分からないが、

それ（コードポイント）をそのまま使う符号化には

UTF-32, UCS-4, UCS-2がある。

329 ：デフォルトの名無しさん：2008/03/07(金) 15:58:57

UTF-32, UCS-4, UCS-2はどう違うの？

330 ：デフォルトの名無しさん：2008/03/07(金) 16:08:50

UTF-32/UCS-4

1文字32ビット。

現在では2つとも同じ中身。

どの規格に含まれているかというだけの違い。>>291に書いてある。

UCS-2

1文字16ビット。U+10000以上のコードポイントを持つ文字は表現できない。

331 ：デフォルトの名無しさん：2008/03/07(金) 16:13:56

UTF-32 は U+110000 以上は無いんじゃ？

340 ：デフォルトの名無しさん：2008/03/07(金) 21:22:58

>>331

UCS-4もU+110000以上は使わないことになった。

>>330に「現在では」と書かれているのはそのへんの含みがあると思われる

337 ：デフォルトの名無しさん：2008/03/07(金) 19:08:01

そういやIPAとUnicodeの対応表みたいなのってないの？

338 ：デフォルトの名無しさん：2008/03/07(金) 20:25:10

http://webos-goodies.jp/archives/51072404.html

342 ：デフォルトの名無しさん：2008/03/12(水) 15:18:27

UTF-8にBOMついてるとまともに動かないソフトが多すぎて嫌すぎる

もっと細分化して、細かく細部まで決めてくれないとどーしよーもないな、実際

344 ：デフォルトの名無しさん：2008/03/12(水) 19:21:59

UTF-8ってBOMつけるんだっけ？

345 ：デフォルトの名無しさん：2008/03/12(水) 19:32:18

RFC 3629 の 6. を見よ

346 ：デフォルトの名無しさん：2008/03/12(水) 19:37:18

なる、つけるべきではないのか。

348 ：デフォルトの名無しさん：2008/03/12(水) 20:25:36

>>346 一般には違う。

付けるべきじゃないのは、UTF-8であることが上位層で規定されている場合。

349 ：デフォルトの名無しさん：2008/03/12(水) 20:28:49

BOMはエンコードを判別するためのものじゃないべさ。

Byte Order Markなんだから。

351 ：デフォルトの名無しさん：2008/03/12(水) 21:18:54

>>349

まぁ元々はそうだったんだけど UTF-8に於いてはUTF-8であることを

あらわすシグネチャという位置付けにされた。

まぁ1バイト文字で済む国はシグネチャなくても全然問題ないんだろうけど

マルチバイト文字使ってる国ではシグネチャない場合は、エンコード誤認の

可能性があるからな。　UTF-8決めうちのソフトならいいんだけど

352 ：デフォルトの名無しさん：2008/03/12(水) 21:20:13

勝手に追加するのはどうかと思うが、テキストファイルの頭にBOMついてるからって

誤動作する方が確実におかしい、無視すべき

360 ：デフォルトの名無しさん：2008/03/20(木) 20:31:17

UTF-8にBOMなんか辞めようと

そもそも、BOM=Byte Order Mark で、UTF-16、UCS-2、UTF-32、UCS-4なんかで使うものだし

そいつ(BOM)をそのままUTF-8変換した値がBOMもどきだし

Visual Studio 2005なんかはUTF-8でソース管理出来るみたいだな

今のPRJはLinuxでUTF-16使ってるから文字列は全てリソース扱い、っつかASCIIだろうとそうすべきではあるけど

ソースコードにUTF-16をhexでどかどか書いても見づらいだけだ

だけど、データ管理はUTF-16のがいい。サロゲートペアなんて使うことはまず無いし、１文字=2バイトと見なして差し支えなければ楽でいい

UTF-8は最近ISO 10646だっけ、RFCだっけ、あれUnicode.orgだっけ？規格変更で1〜4バイトの可変長になって、それとともにUTF-32の領域も狭くなったみたいだが

XMLなんかはエンコーディング付いてるから問題ないし、ソースもSJISやEUCさえなんとかなれば別に問題らしいものはない気がする＞UTF-8

UTF-8自体ASCIIコンパチだしね

364 ：デフォルトの名無しさん：2008/03/20(木) 23:18:25

>>360

>エンコーディング付いてるから問題ないし

そういう場合はBOMを付けるなとちゃんと書いてある

ttp://tools.ietf.org/html/rfc3629#section-6

BOMを付けるのはあくまでもそれがUTF-8と確定できない場合だけだから問題ないだろ

それともエンコード不明のテキストファイルを力技でエンコード推測するのが正しいとでも？

あるいはテキストファイル＝UTF-8として統一するつもり？

Latin-1とかはそうそう無くならないと思うぞ

415 ：デフォルトの名無しさん：2008/04/26(土) 12:32:28

.NETはたとえ完全でないのでもいいから文字コード自動判別クラスを用意すべき

418 ：デフォルトの名無しさん：2008/05/06(火) 07:28:17

>>415

禿同

419 ：デフォルトの名無しさん：2008/05/06(火) 09:11:19

>>415

間違えると「バグだ！金返せ」と言うバカの相手にいいかげんうんざりしたんだろう。

462 ：デフォルトの名無しさん：2008/07/20(日) 18:24:26

Unicodeは16ビットで全ての文字が収まると早合点したことが失敗の始まりですか？

463 ：デフォルトの名無しさん：2008/07/20(日) 18:50:18

いいえ、全ての文字を符号化できると思ったのがそもそもの誤りでした

464 ：デフォルトの名無しさん：2008/07/20(日) 20:32:10

TRONや今昔文字鏡のことですね、わかります

465 ：デフォルトの名無しさん：2008/07/20(日) 20:58:54

もっと言えば、文字とは符号化できるものである、という前提から間違っている。

466 ：デフォルトの名無しさん：2008/07/20(日) 21:00:25

いや、TRONは存在自体が間違っている。

474 ：デフォルトの名無しさん：2008/07/21(月) 01:29:46

人間が文字の生き死にを自由にしようなんて、おこがましいとは思わんかね・・・・・・

475 ：デフォルトの名無しさん：2008/07/21(月) 03:09:30

本間先生？

509 ：デフォルトの名無しさん：2008/07/30(水) 15:04:31

UNICODE: 数社の企業が決めたもの、使用できる文字とその番号を定義。

UCS: 国際標準、内容はUNICODEとほほ同じ

UTF: UNICODEやUCSをコンピュータ上に表現するための仕組み

この認識あってる？

UNICODEとUCSってのはJavaScriptとECMAScriptの関係に似てるんかねぇ。

510 ：デフォルトの名無しさん：2008/07/30(水) 17:01:28

コンソーシアムとその規格が Unicode

国際標準規格が ISO/IEC 10646

そしてそのそれぞれで UCS とか UTF とか定義してる

511 ：デフォルトの名無しさん：2008/07/30(水) 17:16:04

ISO/IEC 10646の名称（の頭文字とったもの）がUCSだろ。

509の理解で合っているぞ。

551 ：デフォルトの名無しさん：2008/08/07(木) 21:56:12

思ったこと。

・広義の「ユニコード」はUTF-8等の規格を含めることがあるので不正確

・>>536指摘済みだけど、音声のenc/decと、文字のenc/decを一緒にするのは

　違和感あり。JISコードは既に「符号(コード)化」されてるから。

　俺的には

　　音楽→(量子化)→PCM→(各種圧縮)→MP3　の３段階が

　　文字→符号化文字集合→テキストエンコーディング　に対応する感じ

・AVIって格納形式の概要だけ決まってて、圧縮アルゴリズムは別じゃなかった？

552 ：デフォルトの名無しさん：2008/08/07(木) 22:59:54

狭義のユニコードっていうのはM$が決めつけたUnicodeのことか？

例えば、ttp://msdn.microsoft.com/ja-jp/library/ms191200.aspx

>Unicode 仕様は 2 バイトを使用して 1 つの文字をエンコードすることでこの問題を解決しました。2 バイトには 65,536 個のパターンがあるため

つーか、広義も狭義もねーよ。バーヤ。

554 ：デフォルトの名無しさん：2008/08/08(金) 01:50:13

>>552

MSが決めつけたというよりも、まだUTF-8もサロゲートペアもなかった昔を引きずっているだけ。

570 ：デフォルトの名無しさん：2008/08/09(土) 13:07:27

以下でOK?

・(文字集合としての)Unicode

扱う文字の一覧を定めて、識別用に符号をつけたもの。

「あ」=U+3042、「A」=U+0041・・・

・UTF-8

Unicodeの文字列を電子データとして扱う際の表現を定める「エンコーディング」の一つ。

あA(U+3042 U+0041)→E3 81 82 41

エンコーディングの他の例としてシフトJIS・UTF-16 BE・マイクロソフトのUnicode 等がある。

よってUnicodeとは

　1. 符号化文字集合の一つ

　2. 文字コードの規格

　3. マイクロソフトのエンコーディングの一つで、UTF-16 LEに等しい

の3つの意味があり、一方UTF-8は、エンコーディングの一つとしての意味しかない。

571 ：デフォルトの名無しさん：2008/08/09(土) 13:21:53

>>570

> よってUnicodeとは

> 　1. 符号化文字集合の一つ

こんな使い方はない。

> 　3. マイクロソフトのエンコーディングの一つで、UTF-16 LEに等しい

アホドキュメント、アホアプリは無視するのがいい。

572 ：デフォルトの名無しさん：2008/08/09(土) 13:24:33

×符号化文字集合

○文字集合

だよね？

MSは無視できないほど規模があるのが憎たらしくて困ったチャンなわけで。

581 ：デフォルトの名無しさん：2008/08/10(日) 02:42:19

>>572

「符号化文字集合」でいいのでは？

文字の集合を定義して、各文字に対して符号化表現(例:A=U+41)を規定してるから。

573 ：デフォルトの名無しさん：2008/08/09(土) 13:39:23

「マイクロソフトの」と書いているが、

まともなドキュメントもあるわけで…

メモ帳の文字コード選択ウィンドウとかそういう部分的なことで、

> 　3. マイクロソフトのエンコーディングの一つで、UTF-16 LEに等しい

を言葉の定義の一つに同列に並べてるのは馬鹿っぽいね。

574 ：デフォルトの名無しさん：2008/08/09(土) 13:42:08

>>573

メモ帳もUnicode/Unicode big endianだけど。

575 ：デフォルトの名無しさん：2008/08/09(土) 13:52:08

とりあえず「UTF-8にBOM」という意味がわからん表現はやめて欲しいもんだ

http://pc11.2ch.net/test/read.cgi/tech/1177930957/

ツイートする

Permalink | コメント(0) | トラックバック(15)