- 1 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 20:02:37 ]
- ビッグインディアンとかなんとかかんとか
- 40 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 10:19:34 ]
- メモ帳でテキストを保存するときに
UnicodeやUTF-8を指定できるが、
Unicodeで保存する
としたときは
UTF-8で保存したのかUTF-16で保存したのか
わたしたちにはわからなくないか？
- 41 名前：デフォルトの名無しさん [2007/05/01(火) 10:22:47 ]
- コンソールのfileコマンドでわかるだろ！(：D)|￣|_
- 42 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 12:07:35 ]
- >>40
Microsoft Windows では "Unicode" といえば UTF-16 のリトルエンディアンという暗黙の了解になっている。
- 43 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 12:13:22 ]
- >>33
csUnicodeっていうISO-10646-UCS-2のIANA別名があって、
こいつはUTF-16コンパチだから、あながち間違いとはいえない。
- 44 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 16:02:40 ]
- Visual Studio.NETのSystem.IOでテキストをつくったらとくにコード指定なしのときはUTFいくつなんだ？
- 45 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 16:21:05 ]
- windowsの標準
- 46 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 17:07:42 ]
- UTF-8
MSDNに書いてある。
- 47 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 17:36:36 ]
- ISO-2022でいいじゃんね
- 48 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 17:49:18 ]
- VB.NETでも結局はBASP21を使わないと文字コード半別できんのか？
- 49 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 18:01:26 ]
- mlangつかやいいじゃん
- 50 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 18:25:37 ]
- 文字コードのことがイマイチよくわからん・・・・
頭こんがらがり
- 51 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 18:48:26 ]
- 文字コードもOSI参照モデルみたいな階層構造の概念が必要だと思うんだよな
↓みたいな感じで
表示字形（グリフ、フォント）
文字入力（物理デバイス、IME）
符号化方式
文字集合
自然言語
- 52 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 19:41:11 ]
- とりあえず、M$はUTF-16をUnicodeと呼ぶのを自重すべきだな。
まるでUTF-16だけがUnicodeとしたいようだ。
SJIS(MS漢字コード)を日本語テキストの標準にしたいかのように。
- 53 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 19:50:46 ]
- 自然言語ってのは普段使ってる言葉な
そこで使われてる文字を集めたのが文字集合ってヤツ
英語だとラテン文字a-z,A-Zと数字、記号なんかが文字集合になるわけ
日本語だと異体字なんかの問題があって集合を作るのが難しいんだけど
（土吉／士吉とか、はしご高／くち高みたいな）
とりあえず作って使われてるのがJIS X 0208文字集合ってヤツ
いわゆるJIS第1水準、第2水準漢字ね
- 54 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 19:53:30 ]
- 他の国でも独自に文字集合を作ってて
それらをまとめてひとつの大きな文字集合に
しちゃおうってのがUnicodeの考え方なの
ここでいうUnicodeはUCS(Universal Character Set)と
同じと思ってもらっていい
- 55 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 19:58:06 ]
- その文字集合を実際にコンピュータ上のゼロイチで
対応させる方法のことを符号化方式っていうの
JIS X 0208文字集合を符号化する主な方法として
EUC-JP、ShiftJIS、ISO-2022-JP(JIS)
っていう３つがあって文字化けとかの問題が出てくるんだけどね
- 56 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 20:07:29 ]
- ASCIIなんかだと文字集合と符号化方式が明確に区別されてなくて
規格として「この文字はこのゼロイチの組合せ」ってのが決められてたりして
そこらへんが文字集合と符号化方式を混乱する一因ではあるんだけど
UTF-8ってのはUCSを符号化する方法のひとつっていうだけ
それ以上でもそれ以下でもない
じゃあ、何が混乱の元かっていうと
Unicodeって言葉がUCS（文字集合）だけを指す場合と
符号化方式まで含めて使われる場合があるのだな
区別が付いてる人はいいんだけど、区別が付いてない人が
書いたり読んだりしてるとエスパー助けて状態にｗ
- 57 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 20:14:21 ]
- UCSという規格の存在を知らず、
UCSという言葉を単にUCS-2やUCS-4などといった符号化形式の
総称としか思っていない奴いるだろ。
- 58 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 20:32:56 ]
- なるへそ。
そういうことか。
Unicodeが単に世界中の文字を集めたもので、その1文字1文字にゼロとイチ
の組み合わせ対応させたものが、UTF-8と。
なんかちょっとわかったよ。
- 59 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 20:43:00 ]
- ASP.NETのWebconfigファイルはUTF-8なんだからできればなにもかもUTF-8で統一してもらいたいんだが。
アラビア語とかを考えてUTF-16とかにする必要があるんだろうか
- 60 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 20:58:23 ]
- Unicodeが16ビット固定長だった頃に書かれたソフトウェアを使うためということが
UTF-16の最大の存在理由だと思う。
個人的には大半の仮名漢字が2オクテットで収まるUTF-16はそんなに嫌いでない。
ASCIIの文字が2バイトになることと、プログラムで扱うときに
サロゲートペアを考慮しなければならないこと、は悩ましいけど。
- 61 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 21:19:18 ]
- どうせ互換性なくなるならASCIIの制御文字から設計し直せばいいのにな
- 62 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 21:29:40 ]
- このスレは文字コードスレの内容がサッパリわからない
アフォの俺には非常に助かる
- 63 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 21:40:58 ]
- なるほど。すごく良く分かった。
エロい人に感謝。
- 64 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 21:51:36 ]
- それじゃぁ、このスレは目的を果たしたということで埋め？
- 65 名前：デフォルトの名無しさん [2007/05/01(火) 21:52:18 ]
- 日本で使うコードポイントはどの辺でしょうか？
www.ssec.wisc.edu/~tomw/java/unicode.html
- 66 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 21:54:29 ]
- ブラウザの実装も大変みたいだね
openmya.hacker.jp/hasegawa/public/20061209/momiji.html
- 67 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 21:58:43 ]
- >>39
UTFって、２種類あるんだ。Windowsのはどっちなんだろ？
というかそもそも、UCS-?とUTF-?の違いが良く分からんが。
- 68 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 21:59:22 ]
- Basic LatinがASCIIの範囲。
CJKなんたらと付くところが漢字関連。
あとHiragana、Katakanaは当然だな。
Halfwidth and Fullwidth Formsが半角カタカナや全角アルファベット。
漏れがあるかも知れないがだいたいこんなとこだろう。
将来的にはHigh/Low Surrogatesに入る文字もあるのかな。(もう入ってる?)
- 69 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 22:13:17 ]
- UCS-2⊂UCS-4⊂世界の文字
UTF-8∈( UCS-2→バイト列(1〜4?バイト) )
UTF-16∈( (UCS-2→バイト列(2バイト) ∩ (UCS-4-UCS-2→バイト列(4バイト)) )
こうかな…？
- 70 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 22:22:38 ]
- UCSは集合でUTFは関数
集合の元に関数を適用するとゼロイチが出てくる
- 71 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 22:30:20 ]
- >>65
国を意識しないで使えるのがUnicodeのメリットで
全ての国で全てのコードポイントが使える
そもそも日本語だけを使いたいのであれば
Unicodeを使う意味がない
理想論だけど
- 72 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 22:30:37 ]
- で、実践的に、ネットからダウンロードしたのをUTF-8で保存するとして
ネットのドキュメントのいろいろな文字コードを知るにはどうするんだ？
- 73 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 22:36:53 ]
- (1)ソース表示→charset=???の部分で判断
(2)いろんなエンコードで開いてみて読めたのが正解
- 74 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 22:37:06 ]
- >>71
>Unicodeを使う意味がない
２バイトコードの問題から開放されるだけでもすごく意味があるぞ。
- 75 名前：デフォルトの名無しさん mailto:sage [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も実用上基本的に違いはない。
- 76 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 22:48:04 ]
- UCS-4は、32ビット固定長の内31ビット使用し、UCSの全ての文字を符号化できる。
UCS-2は、16ビット固定長（16ビット使用）で、UCSのうち、BMP（基本多言語面）だけしか符号化できない。
UTF-32は、32ビット固定長の内21ビット使用し、Unicodeの全ての文字を符号化できる。
UTF-16は、16ビット/32ビット（サロゲートペア）の可変長で、Unicodeの全ての文字を符号化できる。
UnicodeのUTF-8は、8ビット単位、1-4オクテットの可変長で、Unicodeの全ての文字を符号化できる。
UCSのUTF-8は、8ビット単位、1-6オクテットの可変長で、UCSの全ての文字を符号化できる。
Unicodeは、UTF-16で全ての文字を符号化できることを念頭においているが、
UCSは、UCS-4で全ての文字を符号化できることを念頭においている。
- 77 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 22:48:19 ]
- >>74
Unicodeでも多バイト問題は付いて回るし
EUC-JPとかISO-2022-JPでいいんじゃね？
- 78 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 22:52:58 ]
- >>69
これくらいすっきりさせろ
UCS-4 = UCSのUTF-8
UTF-32 = UTF-16 = UnicodeのUTF-8
UCS-2 ⊆ UTF-32 ⊆ UCS-4
（そもそもUnicode ⊆ UCS）
- 79 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 22:54:52 ]
- ISO-2022-JPはステートフルなので扱うのが大変。
UTF-8はEUC-JPより多くの文字が扱える。
Shift_JISはYENとかで困るから除外。
XMLのデフォルトエンコーディングはUTF-8。
- 80 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 23:05:23 ]
- JISX0213（ニアリイコールVistaの文字セット）でサロゲートペアって
ハマりそうだよな。
string s="○";
assert( s.length==1 );
これが成り立たない場合があるっていうのも詐欺みたいな。
- 81 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 23:08:04 ]
- 1区当たり94点しか使わないASCII絶対主義が狂ってると思う
コードポイントの5/7が使われないのはもったいなすぎ
- 82 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 23:17:25 ]
- >>76
なるほど・・・だいぶ間違ってたなぁ。こうなるのかな？
BMP(16bit)⊂Unicode(21bit)⊂UCS(31bit)⊂世界の文字
UCS-4∈( UCS→(32bit) )
UCS-2∈( BMP→(16bit) )
(UCS)UTF-8∈( UCS→(8〜48bit) )
(Unicode)UTF-8∈( Unicode→(8〜32bit) )
UTF-16∈( BMP→(16bit) ∩ Unicode-BMP→(32bit) )
UTF-32∈( Unicode→(32bit) )
>>78
俺はずっと文字集合とエンコーディングがごっちゃになってたから
あんまり省略すると不安だったもんで
- 83 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 23:18:50 ]
- >>80
「が」とかなら判るけど、○も文字的に２文字になるケースってあるの？
サロゲートペアだから2だとかでは、バイト長だから4という思想から
変わってないような。文字としてなら1以外ありえないと思うので、
そのassertが不成立ならstringクラスのバグ（か、lengthのバグ仕様）なんでは？
- 84 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 23:24:41 ]
- 任意の文字って意味じゃね＞"○"
- 85 名前：デフォルトの名無しさん mailto:sage [2007/05/02(水) 00:10:36 ]
- あ゛、なるほど。でも任意の文字っていっても実装依存で
なるわけじゃなくて、そうなってもおかしくない文字（合字とか）で
なるだけじゃないの？言語的な文字数ではなくて内部的に確保した
記憶スロットの数を返すようなlengthはいくらなんでもバグだろう。
- 86 名前：デフォルトの名無しさん mailto:sage [2007/05/02(水) 00:33:38 ]
- >>83
いや、サロゲートペアだから２になるんだわ。
とりあえず.NETはそうなる。
msdn2.microsoft.com/ja-jp/library/system.string.length(VS.80).aspx
> Length プロパティは、このインスタンス内の Char オブジェクトの数を返します。Unicode 文字の数ではありません。
Javaもそうなるみたいだけど。
Java
java.sun.com/j2se/1.5.0/ja/docs/ja/api/java/lang/String.html#length()
> この文字列の長さを返します。長さは文字列内の 16 ビット Unicode 文字の数に等しくなります。
JavaScriptも多分？
- 87 名前：デフォルトの名無しさん mailto:sage [2007/05/02(水) 01:48:47 ]
- >>86
げーっ、そうなんだ。
「16ビットUnicode文字」の数なんて何の意味もないのにな。
「言語的な文字」の数かどうかだけが問題で、それ以外は
バイト数を返すのと同じこと（＝同じ問題を抱える）なのに。
- 88 名前：デフォルトの名無しさん mailto:sage [2007/05/02(水) 02:08:02 ]
- しかし、実際サロゲートペアの
文字なんかほとんど使われないわけで。
それなのにそれを考慮して処理速度を大幅に落とす方が俺は困る。
- 89 名前：デフォルトの名無しさん mailto:sage [2007/05/02(水) 02:09:58 ]
- Javaは仕様としてサロゲートペアを
そもそもサポートしないと決められてるはず。
- 90 名前：デフォルトの名無しさん mailto:sage [2007/05/02(水) 03:25:03 ]
- >>89
最近のJavaはちょっとサポートしている。
String.codePointCount() とか、Character.codePoint*() とか。
- 91 名前：デフォルトの名無しさん mailto:sage [2007/05/02(水) 05:56:27 ]
- >>87
プログラム組む人は、バイト数が欲しい
（書面の）文を書く人は、文字数が欲しい
strcatとかの標準関数が全滅するUTF-16なんて誰が考えたんだろな？
しかも、MSは標準にするし…
- 92 名前：デフォルトの名無しさん mailto:sage [2007/05/02(水) 09:06:46 ]
- 意味的にはもちろん文字数を返すのが理想なんだけど・・・
そもそもJavaなんて、ｓtringクラス作った時はサロゲートペアなんて無い時代じゃないの
- 93 名前：デフォルトの名無しさん mailto:sage [2007/05/02(水) 09:23:29 ]
- >>68
有り難う御座います、結構飛びますね
>>71
ゲームで使うライブラリが使うコードポイントを指定して
テクスチャに書くので決める必要があるからです
海外のフォントが使えなきゃ線画ができませんし
- 94 名前：デフォルトの名無しさん mailto:sage [2007/05/02(水) 10:05:19 ]
- >>91
バイト数を気にしてた頃はJIS X 0201カナも普通に使われてたから
SJISなんつー中途半端なモンが重宝されてたんだよな
- 95 名前：デフォルトの名無しさん mailto:sage [2007/05/02(水) 10:35:00 ]
- >>87
.NETの場合、文字数はSystem.Globalization.StringInfo.LengthInTextElementで得られる。
ほかにもStringInfoには、サロゲートペアを考慮して文字単位で操作するメソッドがいくつかある。
>>91
C89の時点で既にwchar_tはあった。
wcscpyなどの関数が入ったのはC95だった気がするが。
そのwchar_tは、今のWindowsだとUTF-16だが、
そもそもwchar_tことC/C++のワイド文字は固定長で処理することを志向していたはずで、
本来のwchar_tの意義からすればUTF-16は良くない罠。
もしもUnicodeが初めから32ビットになっていれば、と思う。
- 96 名前：デフォルトの名無しさん mailto:sage [2007/05/02(水) 10:37:02 ]
- やべえええ
話についていけない
というか、文字コードの変換は出来るけど 実際の詳しい部分知らない俺はヘタレ・・・
- 97 名前：デフォルトの名無しさん mailto:sage [2007/05/02(水) 10:44:11 ]
- 16bitで足りないのはすぐに判ったろうけど、似た文字はまとめちゃえば入るだろと思ったんだろな
でも、それじゃ納得しない人が出てくるのは当然。
24bitあれば足りたろうから24bitで定義しておけば最善だったかもな
それにしても \ の扱いが醜い
- 98 名前：デフォルトの名無しさん mailto:sage [2007/05/02(水) 10:54:06 ]
- 7bitで足りてた人間が考え始めたコトだからｗ
JIS X 0201のGRはISO646ではあるけどASCIIではないからね
バイナリ的に区別付かないからフォント変えれば同じだけど
ASCIIにスラッシュとバックスラッシュが採用されたのは
当時のプログラム言語で使われてた論理記号の∧と∨を表すためらしい
- 99 名前：デフォルトの名無しさん mailto:sage [2007/05/02(水) 11:11:56 ]
- 歴史的な経緯はこのページが参考になる
ttp://www.horagai.com/www/moji/code4.htm
- 100 名前：デフォルトの名無しさん mailto:sage [2007/05/02(水) 11:18:53 ]
- んじゃ、文字数とかバイト数とかのお話の説明なぞ
UTF-16っていうので16bitで全部の文字を表そうと思ってたのね
でも実際に作り始めたら16bitじゃ全然足りなかったから
その分は16bitをふたつ使って32bitで表しますよっていうコトにしたの
それがサロゲートペアって呼ばれてるモノね（ふたつ組だからペア）
そんなわけで、UTF-16は基本的に16bitで一文字なんだけど
例外的にサロゲートペアだけ32bitで一文字っていう
ヘンテコリンな規格になっちゃったわけ
サロゲートペアの処理がちゃんとされてないプログラムだと
16bitなら一文字、32bitなら二文字っていう風に
機械的に文字数を判断しちゃって困るねっていうこと
- 101 名前：デフォルトの名無しさん mailto:sage [2007/05/02(水) 11:27:33 ]
- 言ってみればサロゲートペア非対応のプログラムでサロゲートペアを含む文字列を扱おうということは、
マルチバイト文字列非対応のプログラムでマルチバイト文字列を扱おうとするのと同じこと。
まあShift_JISのような駄目文字問題が生まれないのはましだけど。
- 102 名前：デフォルトの名無しさん mailto:sage [2007/05/02(水) 11:28:30 ]
- 足りない領域に文字を突っ込むという点では
JIS X 0201のカタカナ集合に通じるモノがあるかも
（いわゆる半角カナのコトね）
自然な感覚だと濁点・半濁点が付いてるのも一文字だし
付いてなくても同様に一文字だと思うんだけど、
文字入れる場所がないから濁点・半濁点付き文字は
例外的に8bitふたつで表現してねっていう
「こんにちは」と「こんばんは」
一般的な感覚としては両方とも五文字だけど
8bitカタカナの世界では
「ｺﾝﾆﾁﾊ」は五文字で「ｺﾝﾊﾞﾝﾊ」は六文字になる
- 103 名前：デフォルトの名無しさん mailto:sage [2007/05/02(水) 11:29:18 ]
- UTF-16で
1文字16bitだとして1文字32bitのものもあるってことは判った
流石に混在はしないの？
- 104 名前：デフォルトの名無しさん mailto:sage [2007/05/02(水) 11:41:16 ]
- >>103
D800-DB7FとDB80-DBFFが上位サロゲート、DC00-DFFFが下位サロゲートの領域になっていて、
任意のUTF-16 1バイト（= 2オクテット）を取り出しても、
それがサロゲートでないか、上位サロゲートか、下位サロゲートかは区別が付く。
駄目文字の問題が起こらないという点において、ASCIIとの対比で言えばShift_JISよりもEUC-JPっぽいという感じ。
EUCは、あるコードがマルチバイトのどこになるかの区別が付かなかった気がするが。
- 105 名前：デフォルトの名無しさん mailto:sage [2007/05/02(水) 11:44:46 ]
- >>104
解説ｻﾝｸｽ
なるほど なんかUTF-16が判ってきた
でもぶっちゃけ存在は知ってるけど使ったことがない俺がいる
- 106 名前：デフォルトの名無しさん mailto:sage [2007/05/02(水) 11:50:43 ]
- 文字コードなんて本来はユーザが意識するようなものじゃないからなぁ
ユーザが意識して扱わないと問題が起きる設計なんてのは
IT業界じゃなきゃ欠陥商品としてリコール対象だろｗ
- 107 名前：デフォルトの名無しさん mailto:sage [2007/05/02(水) 12:30:22 ]
- つまりUTF-16だとサロゲートペアで表す対象になる文字の中で、
俺が有名そうだと思うのは、吉野家の「土吉」（上部が土になっている）U+20BB7 𠮷。
メイリオなんかだとグリフを持っているので表示できる。
- 108 名前：デフォルトの名無しさん mailto:sage [2007/05/02(水) 12:44:27 ]
- DOMStringの長さはUTF-16での符号単位数ってことになってるんだよな。
これ決めた奴、死ぬべきだと思うわ。
- 109 名前：デフォルトの名無しさん mailto:sage [2007/05/02(水) 16:42:11 ]
- >>108
W3CでDOMを規格化するときには、もうJavaScriptもJavaも16bit単位ベー
スの文字列処理になってしまっていたので、仕方なくそれらに合わせた
んだと記憶してます。
- 110 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [2007/05/02(水) 21:57:31 ]
- >>110-111はUTF-8の場合な
- 113 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 06:06:02 ]
- >>112
なにが言いたいのかわからんが、
UTF-8はstr系の標準関数が、ほぼそのまま使えるから大好きだぞ。
ASCIIの前半文字との比較だって、何の躊躇もいらない。
str系に限らず、UTF-8のシステムならfopen等までそのままってのはでかい。
w系使えばいいってのは何かの冗談にしか聞こえない。
ま、UTF-16は、何も考えず0x00を織り込んだのが、糞仕様ってことだ。
- 114 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 06:28:52 ]
- >>100
根本的に認識が間違ってる。
Unicodeの文字表現は元々複数のcode pointを組合わせた可変長
UTF-16でサロゲートが無くても2 byte毎に分割してはだめだし、1文字の長さは2
byte以上の可変長としか言えない。
文字単位に処理したかったらcode pointではなく、grapheme clusterが処理単位
code pointは文字の構成要素であって文字ではない。
- 115 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 10:21:11 ]
- そこでISO/IEC 10646の実装水準1ですよ(もうすぐ廃止されるけど)
- 116 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 11:31:18 ]
- >>113
世の主流言語がPascalとかBasicだったら今頃はUTF-16マンセーの時代だったのかもな。
- 117 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 11:43:25 ]
- なんでPascalやBasicだったらUTF 16マンセーなの？
というか、現代は既にUTF16マンセーだろ？
- 118 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 11:48:34 ]
- どうだろうね。 Unicodeだとその言語がどの言葉か判らんから翻訳ソフトなんて困ってしまうんじゃないの？
16bitに無理にしたかった弊害がどこまでも付いて回る
今なら24bitなり32bitなりのコードで何の問題もなかった。
ほんの５年待てばよかったのにね。
- 119 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 12:16:54 ]
- 何言ってるんだろね。こいつは。
>どうだろうね。 Unicodeだとその言語がどの言葉か判らんから翻訳ソフトなんて困ってしまうんじゃないの？
文字コードから言語を選択する翻訳ソフトってアホだろ。
自動判定するとしても、使われている文字の種別で判定するだろ。
>16bitに無理にしたかった弊害がどこまでも付いて回る
一文目と文章が繋がってなく唐突で、
何が言いたいのか、根拠は何か、さっぱりわからん。
>今なら24bitなり32bitなりのコードで何の問題もなかった。
24bitは別の問題があるし。
>ほんの５年待てばよかったのにね。
「何を」「どの時点から」5年待てばよかったのかさっぱりわからんな。
- 120 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 12:20:56 ]
- >使われている文字の種別で判定するだろ
ってどうやるの？
- 121 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 12:25:07 ]
- >>119
>>99 の話じゃない？
バベル倒壊
・・・
もう一つ、問題なのは、言語指定の仕組を文字コードレベルから排除してしまったことです。
ISO 2022や DIS 10646 1.0では、コードを見るだけで、それがどこの国の文字かを識別することができます。
それはアルファベットの「a」が、英語領域、フランス語領域、ドイツ語領域等々に重複して登録してあるから
なのですが、そんなことをしていたら16bit単一平面に全世界の文字を詰めこむことはできません。
言語指定などは必要なく、それよりも16bit単一平面におさめる方がメリットがある、というのが当時の
Unicodeの考え方だったのです。
- 122 名前：デフォルトの名無しさん [2007/05/03(木) 12:50:46 ]
- Unicodeって多言語を扱う一部の人のためのものではないの？
自国語だけで足りてる人にも使わせようとしてるのはなぜ？
- 123 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 12:55:36 ]
- >>120
asciiしか使われて無いなら英語とか。
文字コード判別より簡単だろ。
>>122
アプリの多言語化は一部の人だけの問題じゃないだろ。
- 124 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 13:11:52 ]
- >>123
ウニコードの話してるんだろ？ なんでasciiの話が出るんだ？
EUC-JP なら日本語と判るのに
ウニコードだと基本ラテンが続いてるだけじゃどこの言葉か判らんだろ？
- 125 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 13:15:17 ]
- ＞ アプリの多言語化は一部の人だけの問題じゃないだろ。
そう。一部の人だけの問題じゃないのに、一部、
特にＭ＄とシリコンバレーが利益率を上げる為に必要と突っ走ったのが
- 126 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 13:16:42 ]
- 何語かを考えないで全て等しく文字として扱うための仕組みがUnicodeだろ
どこの国の文字かはコードポイントで判断すればいいだけ
- 127 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 13:35:36 ]
- そのコードポイントでどう判断するんだ？
- 128 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 13:40:50 ]
- JIS X 0208でもＡとΑとАはコードポイントで何文字か区別つくっしょ
- 129 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 13:42:09 ]
- >>124
>ウニコードの話してるんだろ？ なんでasciiの話が出るんだ？
Unicodeの話だろ？
ascii範囲だけが多く使われていたらだよ。わかれよ。
Πが使われていたらロシアとかだよ。わかれよ。
- 130 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 13:48:30 ]
- ascii ってのは 基本ラテン文字の事だろ？
code.cside.com/3rdpage/jp/utf-8/Bacic_Latin.html
だったら、どうしてコレだけで英語だとわかるんだ？
- 131 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 14:02:01 ]
- 完全に分かる分けないだろ。
後は単語で判別だわな。
- 132 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 14:02:25 ]
- >>117
Pascal string と C string。
- 133 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 14:09:18 ]
- >>132
Pascal stringって、文字列の先頭に文字の長さが格納されてるってもんじゃないの？
なんでPascal stringだとUTF-16マンセーになるか、全然説明になってないよ。
- 134 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 14:09:49 ]
- 標準関数自体が今となっては問題の種な訳だが。
strsafe.h で追加された文字列操作関数について
ir9.jp/prog/ayu/strsafe.htm
- 135 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 14:13:23 ]
- kono bunshou ha nihon-go desu.
- 136 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 14:53:41 ]
- >>124
EUC-JPの半角英数だから日本語と決めつける方がどうかしてる
コメントに日本語が使われてるC言語のソースの単語は全部日本語か?
そもそもISO-8859-1の時点ですでに欧州の文字統一しまくりなわけだが?
- 137 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 15:11:27 ]
- >>134
バッファオーバーフローは、古い関数だからおこるの？ 違うだろ。
なんであの会社は作り直しを奨励するようなことをやりたがるの？
仕事を増やすためじゃないの？
- 138 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 15:24:04 ]
- このスレと文字コード総合スレの違いは?
- 139 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 15:29:19 ]
- >>137
古い関数だと間違いやすく、新しい関数だと間違えづらいだろ？あってるだろ。
>なんであの会社は作り直しを奨励するようなことをやりたがるの？
古いC関数は使わないってのはもう常識なのに…
お前何十年と情報から隔絶されてたんだ…
>仕事を増やすためじゃないの？
逆逆。古い関数使うお前のようなバカの尻拭い仕事を減らすため。
- 140 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 15:37:53 ]
- >>139
>古い関数だと間違いやすく、新しい関数だと間違えづらいだろ？あってるだろ。
何の話をしてるのかね？ 関数名を間違えるのかね？
「間違いが起こりやすく」だろ？ 日本語でおｋ。
>古いC関数は使わないってのはもう常識なのに…
常識なんつーのは、所詮、てめーの知識でしかねーんだよ。
軽々しく常識なんて単語使うな。
お前は、動いているプログラムを変更するが大好きなのか？
それこそ、お前のようなバカの尻拭い仕事をさせられるぜ。
|
 |
