Humanity

Edit the world by your favorite way

UnicodeとUTF-8の違いは?

という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


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-16UTF-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
UnicodeUnicode Consociumの制定した文字集合。(U+0 - U+1FFFFF)
UTF-8/16/32: Unicode Transformation Format。Unicodeの符号化方式。
 UTF-8: 外字が無いため4Byte長まで。
 UTF-16UCS-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-8Unicodeの方と違い6Byte長まであり。


67 :デフォルトの名無しさん:2007/05/01(火) 21:58:43
>>39
UTFって、2種類あるんだ。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)
っていう3つがあって文字化けとかの問題が出てくるんだけどね


56 :デフォルトの名無しさん:2007/05/01(火) 20:07:29
ASCIIなんかだと文字集合と符号化方式が明確に区別されてなくて
規格として「この文字はこのゼロイチの組合せ」ってのが決められてたりして
そこらへんが文字集合と符号化方式を混乱する一因ではあるんだけど

UTF-8ってのはUCSを符号化する方法のひとつっていうだけ
それ以上でもそれ以下でもない

じゃあ、何が混乱の元かっていうと
Unicodeって言葉がUCS(文字集合)だけを指す場合と
符号化方式まで含めて使われる場合があるのだな
区別が付いてる人はいいんだけど、区別が付いてない人が
書いたり読んだりしてるとエスパー助けて状態にw


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
メモ帳でテキストを保存するときに
UnicodeUTF-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-16Unicodeと呼ぶのを自重すべきだな。
まるで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文字になるケースってあるの?
サロゲートペアだから2だとかでは、バイト長だから4という思想から
変わってないような。文字としてなら1以外ありえないと思うので、
そのassertが不成立ならstringクラスのバグ(か、lengthのバグ仕様)なんでは?


86 :デフォルトの名無しさん:2007/05/02(水) 00:33:38
>>83
いや、サロゲートペアだから2になるんだわ。
とりあえず.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で足りてた人間が考え始めたコトだからw

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を規格化するときには、もうJavaScriptJavaも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、つまりMicrosoftShift_JIS

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


275 :デフォルトの名無しさん:2008/02/12(火) 17:30:56
>>274 そういう意味だったのか !


246 :デフォルトの名無しさん:2007/10/06(土) 04:33:30
けっきょくいまだにスレタイトルの疑問をだれもがなtっとくできるほどうまく解説した人があらわれない


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
unicodeutf-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-2UTF-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-2UTF-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の2バイトの部分がUCS-2と同じっていうメリットがあるんよ。
4バイト部分はあんまり使わない部分だからサロゲートペアっつう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
どういう場合に1バイト8ビットじゃなくなるの?


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の言うとおり、昔は1バイト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
そういやIPAUnicodeの対応表みたいなのってないの?


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-16UCS-2UTF-32、UCS-4なんかで使うものだし
そいつ(BOM)をそのままUTF-8変換した値がBOMもどきだし

Visual Studio 2005なんかはUTF-8でソース管理出来るみたいだな
今のPRJはLinuxUTF-16使ってるから文字列は全てリソース扱い、っつかASCIIだろうとそうすべきではあるけど
ソースコードUTF-16をhexでどかどか書いても見づらいだけだ
だけど、データ管理はUTF-16のがいい。サロゲートペアなんて使うことはまず無いし、1文字=2バイトと見なして差し支えなければ楽でいい
UTF-8は最近ISO 10646だっけ、RFCだっけ、あれUnicode.orgだっけ?規格変更で1〜4バイトの可変長になって、それとともにUTF-32の領域も狭くなったみたいだが

XMLなんかはエンコーディング付いてるから問題ないし、ソースもSJISEUCさえなんとかなれば別に問題らしいものはない気がする>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ってのはJavaScriptECMAScriptの関係に似てるんかねぇ。


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 の3段階が
  文字→符号化文字集合→テキストエンコーディング に対応する感じ
・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

エンコーディングの他の例としてシフトJISUTF-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/