UnicodeとUTF-8の違いは？

UnicodeとUTF-8の違いは？ at TECH

1:デフォルトの名無しさん
07/04/30 20:02:37
ビッグインディアンとかなんとかかんとか

2:デフォルトの名無しさん
07/04/30 20:04:11
戦力の決定的差ではない

3:デフォルトの名無しさん
07/04/30 20:05:48
また、頭の悪そうなスレが・・・

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

4:デフォルトの名無しさん
07/04/30 20:06:49
魚と鮪というよりは、魚と刺身の違いのような気がする。

5:デフォルトの名無しさん
07/04/30 20:09:31
俺もわからん。
誰か詳しく説明してよ。

6:デフォルトの名無しさん
07/04/30 20:11:24
>>5
UNICODE→魚
UTF-8→刺身

7:デフォルトの名無しさん
07/04/30 20:14:40
Unicodeは文字の集合で、UTF-8はそれに(語弊があるが)番号を振る方法の1つ。

8:デフォルトの名無しさん
07/04/30 20:15:39
UNICODE
- 文字集合：１種類
- 符号化方式：UTF-8, UTF-16BE, etc

9:デフォルトの名無しさん
07/04/30 20:19:17
小学生でもわかるように！

10:デフォルトの名無しさん
07/04/30 20:28:13
Unicode => クラスメート
UTF-8 => 身長順に並べー、名前の順に並べー、誕生日の順に並べー

11:デフォルトの名無しさん
07/04/30 20:30:48
自分はUCSとの違いがわからん

12:デフォルトの名無しさん
07/04/30 20:32:18
2chの絵文字の#1234とかがUTF-8なのか？

13:デフォルトの名無しさん
07/04/30 20:32:39
Unicode:
コードポイント: JISの句点コード
UTF-7, UTF-8, UTF-16, UTF-32: Shift_JIS, ISO-2022-JP, EUC-jp

Unicode ⊃ UTF-8

14:デフォルトの名無しさん
07/04/30 20:32:52
unicode => 国民
UTF-8 => 住基コード

15:デフォルトの名無しさん
07/04/30 20:42:09
Unicode = { 'a', 'b', ... }
UTF8 = { utf8encode('a'), utf8encode('b'), ... }

16:デフォルトの名無しさん
07/04/30 20:42:47
UNICODE: JIS
UTF-8: SJIS or UJIS

かな？

17:デフォルトの名無しさん
07/04/30 20:44:05
JISてーと、ISO-2022-JPエンコーディングのことを指すのかJIS X 0201とか08
とかを指すのかはっきりしないが、後者ならそんな感じ。

18:デフォルトの名無しさん
07/04/30 20:44:56
あるいは
UNICODE: DivX or XviD or WMV9
UTF-8: AVI or MKV or OGM or ASF

19:デフォルトの名無しさん
07/04/30 20:51:13
>>1
そもそもUTF-16やUTF-32と違って
バイトストリームのUTF-8にはエンディアン問題はない
UTF-8のBOMはエンディアン対策ではない

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

20:デフォルトの名無しさん
07/04/30 20:53:30
UNICODEって文字セットのことなのか、
文字セット＋符号化方式たち　のことなのかどっち？

21:デフォルトの名無しさん
07/04/30 20:57:06
文字それぞれにも番号は振られているが、これは日本語の文字でいうと
区点コードみたいなもんだな。

22:デフォルトの名無しさん
07/04/30 21:00:55
UTF-8とかってのは一種の圧縮方式みたいなものだよね
前cjk漢字統合で叩かれてたのはUNICODE自体の問題？
それとも非可逆圧縮への批判？

23:デフォルトの名無しさん
07/04/30 21:13:09
なんという他力本願なｽﾚ・・・

24:デフォルトの名無しさん
07/04/30 21:14:46
ていうか、こんだけグチャグチャ言われたらわかるもんも
わからんようになるだろ、普通ｗ

25:デフォルトの名無しさん
07/04/30 21:18:58
>22
UnicodeがCJK漢字を統合するという
非可逆圧縮を選択したことへの批判だったと記憶している。

26:デフォルトの名無しさん
07/04/30 21:26:07
.NET2.0には文字コードを自動判別する機能があるかどうかどうなんだ

27:デフォルトの名無しさん
07/04/30 21:29:11
文字コードスレで聞けよ・・・

28:デフォルトの名無しさん
07/04/30 21:32:55
>>22
>UTF-8とかってのは一種の圧縮方式みたいなものだよね

全然違うから。

29:デフォルトの名無しさん
07/04/30 21:36:55
>>11
UnicodeはUCS-4のサブセットであり、UCS-2のスーパーセット

30:デフォルトの名無しさん
07/05/01 00:35:17
UNICODEには基盤になる文字集合が一つあって、
その文字コードを固定長で(そのまま)使うのがUCS、
可変長で(圧縮して)使うのがUTFだと思ってた俺。

しかし>>28によって否定されてしまった。
調べてもなぜ間違ってるのか分からん。

31:デフォルトの名無しさん
07/05/01 00:46:56
>>30
可変長と圧縮を混同するな。

32:デフォルトの名無しさん
07/05/01 00:55:36
>>31
そりゃ確かに俺らからすれば圧縮とは言えないね。
でもわざわざ可変長にする理由は第一に互換性、第二にサイズぐらいしかない気がする
とりあえず大筋では合ってたようなのでよかった。ｻﾝｸｽ

33:デフォルトの名無しさん
07/05/01 05:53:08
UTF-16LEを指してUnicodeと連呼しているSDKドキュメントが存在するんだが、
あいつらの傲慢さは何とかならんのか？

34:デフォルトの名無しさん
07/05/01 07:31:56
UTFのUとは何か

35:デフォルトの名無しさん
07/05/01 08:12:07
さいたまてれびがうつらないのですが・・・

36:デフォルトの名無しさん
07/05/01 08:18:43
なぁ、ちょっとおしえてくんねーか？
なんでutf8の「ももんが」って文字列を
PerlのJCodeでutf8に変換しようとすると文字化けしちゃうんだ？

37:デフォルトの名無しさん
07/05/01 09:03:46
ももんが！！

38:デフォルトの名無しさん
07/05/01 09:12:48
>>36
utf8からutf8だと、変換してないじゃないか。

39:デフォルトの名無しさん
07/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長まであり。

40:デフォルトの名無しさん
07/05/01 10:19:34
メモ帳でテキストを保存するときに
UnicodeやUTF-8を指定できるが、
Unicodeで保存する
としたときは
UTF-8で保存したのかUTF-16で保存したのか
わたしたちにはわからなくないか？

41:デフォルトの名無しさん
07/05/01 10:22:47
コンソールのfileコマンドでわかるだろ！(：D)|￣|_

42:デフォルトの名無しさん
07/05/01 12:07:35
>>40
Microsoft Windows では "Unicode" といえば UTF-16 のリトルエンディアンという暗黙の了解になっている。

43:デフォルトの名無しさん
07/05/01 12:13:22
>>33
csUnicodeっていうISO-10646-UCS-2のIANA別名があって、
こいつはUTF-16コンパチだから、あながち間違いとはいえない。

44:デフォルトの名無しさん
07/05/01 16:02:40
Visual Studio.NETのSystem.IOでテキストをつくったらとくにコード指定なしのときはUTFいくつなんだ？

45:デフォルトの名無しさん
07/05/01 16:21:05
windowsの標準

46:デフォルトの名無しさん
07/05/01 17:07:42
UTF-8
MSDNに書いてある。

47:デフォルトの名無しさん
07/05/01 17:36:36
ISO-2022でいいじゃんね

48:デフォルトの名無しさん
07/05/01 17:49:18
VB.NETでも結局はBASP21を使わないと文字コード半別できんのか？

49:デフォルトの名無しさん
07/05/01 18:01:26
mlangつかやいいじゃん

50:デフォルトの名無しさん
07/05/01 18:25:37
文字コードのことがイマイチよくわからん・・・・
頭こんがらがり

51:デフォルトの名無しさん
07/05/01 18:48:26
文字コードもOSI参照モデルみたいな階層構造の概念が必要だと思うんだよな
↓みたいな感じで

表示字形（グリフ、フォント）
文字入力（物理デバイス、IME）
符号化方式
文字集合
自然言語

52:デフォルトの名無しさん
07/05/01 19:41:11
とりあえず、M$はUTF-16をUnicodeと呼ぶのを自重すべきだな。
まるでUTF-16だけがUnicodeとしたいようだ。
SJIS(MS漢字コード)を日本語テキストの標準にしたいかのように。

53:デフォルトの名無しさん
07/05/01 19:50:46
自然言語ってのは普段使ってる言葉な
そこで使われてる文字を集めたのが文字集合ってヤツ

英語だとラテン文字a-z,A-Zと数字、記号なんかが文字集合になるわけ
日本語だと異体字なんかの問題があって集合を作るのが難しいんだけど
（土吉／士吉とか、はしご高／くち高みたいな）
とりあえず作って使われてるのがJIS X 0208文字集合ってヤツ
いわゆるJIS第1水準、第2水準漢字ね

54:デフォルトの名無しさん
07/05/01 19:53:30
他の国でも独自に文字集合を作ってて
それらをまとめてひとつの大きな文字集合に
しちゃおうってのがUnicodeの考え方なの

ここでいうUnicodeはUCS(Universal Character Set)と
同じと思ってもらっていい

55:デフォルトの名無しさん
07/05/01 19:58:06
その文字集合を実際にコンピュータ上のゼロイチで
対応させる方法のことを符号化方式っていうの

JIS X 0208文字集合を符号化する主な方法として
EUC-JP、ShiftJIS、ISO-2022-JP(JIS)
っていう３つがあって文字化けとかの問題が出てくるんだけどね

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

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

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

57:デフォルトの名無しさん
07/05/01 20:14:21
UCSという規格の存在を知らず、
UCSという言葉を単にUCS-2やUCS-4などといった符号化形式の
総称としか思っていない奴いるだろ。

58:デフォルトの名無しさん
07/05/01 20:32:56
なるへそ。
そういうことか。

Unicodeが単に世界中の文字を集めたもので、その1文字1文字にゼロとイチ
の組み合わせ対応させたものが、UTF-8と。

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

59:デフォルトの名無しさん
07/05/01 20:43:00
ASP.NETのWebconfigファイルはUTF-8なんだからできればなにもかもUTF-8で統一してもらいたいんだが。
アラビア語とかを考えてUTF-16とかにする必要があるんだろうか

60:デフォルトの名無しさん
07/05/01 20:58:23
Unicodeが16ビット固定長だった頃に書かれたソフトウェアを使うためということが
UTF-16の最大の存在理由だと思う。

個人的には大半の仮名漢字が2オクテットで収まるUTF-16はそんなに嫌いでない。
ASCIIの文字が2バイトになることと、プログラムで扱うときに
サロゲートペアを考慮しなければならないこと、は悩ましいけど。

61:デフォルトの名無しさん
07/05/01 21:19:18
どうせ互換性なくなるならASCIIの制御文字から設計し直せばいいのにな

62:デフォルトの名無しさん
07/05/01 21:29:40
このスレは文字コードスレの内容がサッパリわからない
アフォの俺には非常に助かる

63:デフォルトの名無しさん
07/05/01 21:40:58
なるほど。すごく良く分かった。
エロい人に感謝。

64:デフォルトの名無しさん
07/05/01 21:51:36
それじゃぁ、このスレは目的を果たしたということで埋め？

65:デフォルトの名無しさん
07/05/01 21:52:18
日本で使うコードポイントはどの辺でしょうか？
URLﾘﾝｸ(www.ssec.wisc.edu)

66:デフォルトの名無しさん
07/05/01 21:54:29
ブラウザの実装も大変みたいだね
URLﾘﾝｸ(openmya.hacker.jp)

67:デフォルトの名無しさん
07/05/01 21:58:43
>>39
UTFって、２種類あるんだ。Windowsのはどっちなんだろ？
というかそもそも、UCS-?とUTF-?の違いが良く分からんが。

68:デフォルトの名無しさん
07/05/01 21:59:22
Basic LatinがASCIIの範囲。
CJKなんたらと付くところが漢字関連。
あとHiragana、Katakanaは当然だな。
Halfwidth and Fullwidth Formsが半角カタカナや全角アルファベット。

漏れがあるかも知れないがだいたいこんなとこだろう。

将来的にはHigh/Low Surrogatesに入る文字もあるのかな。(もう入ってる?)

69:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/05/01 22:22:38
UCSは集合でUTFは関数
集合の元に関数を適用するとゼロイチが出てくる

71:デフォルトの名無しさん
07/05/01 22:30:20
>>65
国を意識しないで使えるのがUnicodeのメリットで
全ての国で全てのコードポイントが使える

そもそも日本語だけを使いたいのであれば
Unicodeを使う意味がない
理想論だけど

72:デフォルトの名無しさん
07/05/01 22:30:37
で、実践的に、ネットからダウンロードしたのをUTF-8で保存するとして
ネットのドキュメントのいろいろな文字コードを知るにはどうするんだ？

73:デフォルトの名無しさん
07/05/01 22:36:53
(1)ソース表示→charset=???の部分で判断
(2)いろんなエンコードで開いてみて読めたのが正解

74:デフォルトの名無しさん
07/05/01 22:37:06
>>71
>Unicodeを使う意味がない

２バイトコードの問題から開放されるだけでもすごく意味があるぞ。

75:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/05/01 22:48:19
>>74
Unicodeでも多バイト問題は付いて回るし
EUC-JPとかISO-2022-JPでいいんじゃね？

78:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/05/01 22:54:52
ISO-2022-JPはステートフルなので扱うのが大変。
UTF-8はEUC-JPより多くの文字が扱える。
Shift_JISはYENとかで困るから除外。
XMLのデフォルトエンコーディングはUTF-8。

80:デフォルトの名無しさん
07/05/01 23:05:23
JISX0213（ニアリイコールVistaの文字セット）でサロゲートペアって
ハマりそうだよな。

string s="○";
assert( s.length==1 );

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

81:デフォルトの名無しさん
07/05/01 23:08:04
1区当たり94点しか使わないASCII絶対主義が狂ってると思う
コードポイントの5/7が使われないのはもったいなすぎ

82:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/05/01 23:18:50
>>80
「が」とかなら判るけど、○も文字的に２文字になるケースってあるの？
サロゲートペアだから2だとかでは、バイト長だから4という思想から
変わってないような。文字としてなら1以外ありえないと思うので、
そのassertが不成立ならstringクラスのバグ（か、lengthのバグ仕様）なんでは？

84:デフォルトの名無しさん
07/05/01 23:24:41
任意の文字って意味じゃね＞"○"

85:デフォルトの名無しさん
07/05/02 00:10:36
あ゛、なるほど。でも任意の文字っていっても実装依存で
なるわけじゃなくて、そうなってもおかしくない文字（合字とか）で
なるだけじゃないの？言語的な文字数ではなくて内部的に確保した
記憶スロットの数を返すようなlengthはいくらなんでもバグだろう。

86:デフォルトの名無しさん
07/05/02 00:33:38
>>83
いや、サロゲートペアだから２になるんだわ。
とりあえず.NETはそうなる。

URLﾘﾝｸ(msdn2.microsoft.com)(VS.80).aspx
> Length プロパティは、このインスタンス内の Char オブジェクトの数を返します。Unicode 文字の数ではありません。

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

Java
URLﾘﾝｸ(java.sun.com)()
> この文字列の長さを返します。長さは文字列内の 16 ビット Unicode 文字の数に等しくなります。

JavaScriptも多分？

87:デフォルトの名無しさん
07/05/02 01:48:47
>>86
げーっ、そうなんだ。
「16ビットUnicode文字」の数なんて何の意味もないのにな。
「言語的な文字」の数かどうかだけが問題で、それ以外は
バイト数を返すのと同じこと（＝同じ問題を抱える）なのに。

88:デフォルトの名無しさん
07/05/02 02:08:02
しかし、実際サロゲートペアの
文字なんかほとんど使われないわけで。

それなのにそれを考慮して処理速度を大幅に落とす方が俺は困る。

89:デフォルトの名無しさん
07/05/02 02:09:58
Javaは仕様としてサロゲートペアを
そもそもサポートしないと決められてるはず。

90:デフォルトの名無しさん
07/05/02 03:25:03
>>89
最近のJavaはちょっとサポートしている。
String.codePointCount() とか、Character.codePoint*() とか。

91:デフォルトの名無しさん
07/05/02 05:56:27
>>87
プログラム組む人は、バイト数が欲しい
（書面の）文を書く人は、文字数が欲しい

strcatとかの標準関数が全滅するUTF-16なんて誰が考えたんだろな？
しかも、MSは標準にするし…

92:デフォルトの名無しさん
07/05/02 09:06:46
意味的にはもちろん文字数を返すのが理想なんだけど・・・
そもそもJavaなんて、ｓtringクラス作った時はサロゲートペアなんて無い時代じゃないの

93:デフォルトの名無しさん
07/05/02 09:23:29
>>68
有り難う御座います、結構飛びますね
>>71
ゲームで使うライブラリが使うコードポイントを指定して
テクスチャに書くので決める必要があるからです
海外のフォントが使えなきゃ線画ができませんし

94:デフォルトの名無しさん
07/05/02 10:05:19
>>91
バイト数を気にしてた頃はJIS X 0201カナも普通に使われてたから
SJISなんつー中途半端なモンが重宝されてたんだよな

95:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/05/02 10:37:02
やべえええ
話についていけない
というか、文字コードの変換は出来るけど　実際の詳しい部分知らない俺はヘタレ・・・

97:デフォルトの名無しさん
07/05/02 10:44:11
16bitで足りないのはすぐに判ったろうけど、似た文字はまとめちゃえば入るだろと思ったんだろな
でも、それじゃ納得しない人が出てくるのは当然。

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

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

98:デフォルトの名無しさん
07/05/02 10:54:06
7bitで足りてた人間が考え始めたコトだからｗ

JIS X 0201のGRはISO646ではあるけどASCIIではないからね
バイナリ的に区別付かないからフォント変えれば同じだけど

ASCIIにスラッシュとバックスラッシュが採用されたのは
当時のプログラム言語で使われてた論理記号の∧と∨を表すためらしい

99:デフォルトの名無しさん
07/05/02 11:11:56
歴史的な経緯はこのページが参考になる
URLﾘﾝｸ(www.horagai.com)

100:デフォルトの名無しさん
07/05/02 11:18:53
んじゃ、文字数とかバイト数とかのお話の説明なぞ

UTF-16っていうので16bitで全部の文字を表そうと思ってたのね
でも実際に作り始めたら16bitじゃ全然足りなかったから
その分は16bitをふたつ使って32bitで表しますよっていうコトにしたの
それがサロゲートペアって呼ばれてるモノね（ふたつ組だからペア）

そんなわけで、UTF-16は基本的に16bitで一文字なんだけど
例外的にサロゲートペアだけ32bitで一文字っていう
ヘンテコリンな規格になっちゃったわけ

サロゲートペアの処理がちゃんとされてないプログラムだと
16bitなら一文字、32bitなら二文字っていう風に
機械的に文字数を判断しちゃって困るねっていうこと

101:デフォルトの名無しさん
07/05/02 11:27:33
言ってみればサロゲートペア非対応のプログラムでサロゲートペアを含む文字列を扱おうということは、
マルチバイト文字列非対応のプログラムでマルチバイト文字列を扱おうとするのと同じこと。
まあShift_JISのような駄目文字問題が生まれないのはましだけど。

102:デフォルトの名無しさん
07/05/02 11:28:30
足りない領域に文字を突っ込むという点では
JIS X 0201のカタカナ集合に通じるモノがあるかも
（いわゆる半角カナのコトね）

自然な感覚だと濁点・半濁点が付いてるのも一文字だし
付いてなくても同様に一文字だと思うんだけど、
文字入れる場所がないから濁点・半濁点付き文字は
例外的に8bitふたつで表現してねっていう

「こんにちは」と「こんばんは」
一般的な感覚としては両方とも五文字だけど
8bitカタカナの世界では
「ｺﾝﾆﾁﾊ」は五文字で「ｺﾝﾊﾞﾝﾊ」は六文字になる

103:デフォルトの名無しさん
07/05/02 11:29:18
UTF-16で
1文字16bitだとして1文字32bitのものもあるってことは判った
流石に混在はしないの？

104:デフォルトの名無しさん
07/05/02 11:41:16
>>103
D800-DB7FとDB80-DBFFが上位サロゲート、DC00-DFFFが下位サロゲートの領域になっていて、
任意のUTF-16 1バイト（= 2オクテット）を取り出しても、
それがサロゲートでないか、上位サロゲートか、下位サロゲートかは区別が付く。

駄目文字の問題が起こらないという点において、ASCIIとの対比で言えばShift_JISよりもEUC-JPっぽいという感じ。
EUCは、あるコードがマルチバイトのどこになるかの区別が付かなかった気がするが。

105:デフォルトの名無しさん
07/05/02 11:44:46
>>104
解説ｻﾝｸｽ
なるほど　なんかUTF-16が判ってきた
でもぶっちゃけ存在は知ってるけど使ったことがない俺がいる

106:デフォルトの名無しさん
07/05/02 11:50:43
文字コードなんて本来はユーザが意識するようなものじゃないからなぁ
ユーザが意識して扱わないと問題が起きる設計なんてのは
IT業界じゃなきゃ欠陥商品としてリコール対象だろｗ

107:デフォルトの名無しさん
07/05/02 12:30:22
つまりUTF-16だとサロゲートペアで表す対象になる文字の中で、
俺が有名そうだと思うのは、吉野家の「土吉」（上部が土になっている）U+20BB7 𠮷。
メイリオなんかだとグリフを持っているので表示できる。

108:デフォルトの名無しさん
07/05/02 12:44:27
DOMStringの長さはUTF-16での符号単位数ってことになってるんだよな。
これ決めた奴、死ぬべきだと思うわ。

109:デフォルトの名無しさん
07/05/02 16:42:11
>>108
W3CでDOMを規格化するときには、もうJavaScriptもJavaも16bit単位ベー
スの文字列処理になってしまっていたので、仕方なくそれらに合わせた
んだと記憶してます。

110:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/05/02 21:38:28
1バイトだけ見た場合、

0xxx xxxxならそのバイトだけで1文字
1xxx xxxxなら
-- 10xx xxxxなら多バイト文字の2バイト目以降(先頭は遡って11xxなバイト)
-- 11xx xxxxなら多バイト文字の先頭バイト
---- 110x xxxxなら2バイト文字の先頭バイト
---- 111x xxxxなら3バイト文字の先頭バイト

と判別できるわけだな。

112:デフォルトの名無しさん
07/05/02 21:57:31
>>110-111はUTF-8の場合な

113:デフォルトの名無しさん
07/05/03 06:06:02
>>112
なにが言いたいのかわからんが、
UTF-8はstr系の標準関数が、ほぼそのまま使えるから大好きだぞ。
ASCIIの前半文字との比較だって、何の躊躇もいらない。
str系に限らず、UTF-8のシステムならfopen等までそのままってのはでかい。
w系使えばいいってのは何かの冗談にしか聞こえない。
ま、UTF-16は、何も考えず0x00を織り込んだのが、糞仕様ってことだ。

114:デフォルトの名無しさん
07/05/03 06:28:52
>>100
根本的に認識が間違ってる。
Unicodeの文字表現は元々複数のcode pointを組合わせた可変長
UTF-16でサロゲートが無くても2 byte毎に分割してはだめだし、1文字の長さは2
byte以上の可変長としか言えない。
文字単位に処理したかったらcode pointではなく、grapheme clusterが処理単位
code pointは文字の構成要素であって文字ではない。

115:デフォルトの名無しさん
07/05/03 10:21:11
そこでISO/IEC 10646の実装水準1ですよ(もうすぐ廃止されるけど)

116:デフォルトの名無しさん
07/05/03 11:31:18
>>113
世の主流言語がPascalとかBasicだったら今頃はUTF-16マンセーの時代だったのかもな。

117:デフォルトの名無しさん
07/05/03 11:43:25
なんでPascalやBasicだったらUTF 16マンセーなの？

というか、現代は既にUTF16マンセーだろ？

118:デフォルトの名無しさん
07/05/03 11:48:34
どうだろうね。 Unicodeだとその言語がどの言葉か判らんから翻訳ソフトなんて困ってしまうんじゃないの？
16bitに無理にしたかった弊害がどこまでも付いて回る
今なら24bitなり32bitなりのコードで何の問題もなかった。
ほんの５年待てばよかったのにね。

119:デフォルトの名無しさん
07/05/03 12:16:54
何言ってるんだろね。こいつは。

>どうだろうね。 Unicodeだとその言語がどの言葉か判らんから翻訳ソフトなんて困ってしまうんじゃないの？
文字コードから言語を選択する翻訳ソフトってアホだろ。
自動判定するとしても、使われている文字の種別で判定するだろ。

>16bitに無理にしたかった弊害がどこまでも付いて回る
一文目と文章が繋がってなく唐突で、
何が言いたいのか、根拠は何か、さっぱりわからん。

>今なら24bitなり32bitなりのコードで何の問題もなかった。
24bitは別の問題があるし。

>ほんの５年待てばよかったのにね。
「何を」「どの時点から」5年待てばよかったのかさっぱりわからんな。

120:デフォルトの名無しさん
07/05/03 12:20:56
>使われている文字の種別で判定するだろ

ってどうやるの？

121:デフォルトの名無しさん
07/05/03 12:25:07
>>119
>>99 の話じゃない？

バベル倒壊
・・・
　もう一つ、問題なのは、言語指定の仕組を文字コードレベルから排除してしまったことです。
ISO 2022や DIS 10646 1.0では、コードを見るだけで、それがどこの国の文字かを識別することができます。
それはアルファベットの「a」が、英語領域、フランス語領域、ドイツ語領域等々に重複して登録してあるから
なのですが、そんなことをしていたら16bit単一平面に全世界の文字を詰めこむことはできません。
言語指定などは必要なく、それよりも16bit単一平面におさめる方がメリットがある、というのが当時の
Unicodeの考え方だったのです。

122:デフォルトの名無しさん
07/05/03 12:50:46
Unicodeって多言語を扱う一部の人のためのものではないの？
自国語だけで足りてる人にも使わせようとしてるのはなぜ？

123:デフォルトの名無しさん
07/05/03 12:55:36
>>120
asciiしか使われて無いなら英語とか。
文字コード判別より簡単だろ。

>>122
アプリの多言語化は一部の人だけの問題じゃないだろ。

124:デフォルトの名無しさん
07/05/03 13:11:52
>>123
ウニコードの話してるんだろ？　なんでasciiの話が出るんだ？
EUC-JP なら日本語と判るのに
ウニコードだと基本ラテンが続いてるだけじゃどこの言葉か判らんだろ？

125:デフォルトの名無しさん
07/05/03 13:15:17
＞　アプリの多言語化は一部の人だけの問題じゃないだろ。

そう。一部の人だけの問題じゃないのに、一部、
特にＭ＄とシリコンバレーが利益率を上げる為に必要と突っ走ったのが

126:デフォルトの名無しさん
07/05/03 13:16:42
何語かを考えないで全て等しく文字として扱うための仕組みがUnicodeだろ
どこの国の文字かはコードポイントで判断すればいいだけ

127:デフォルトの名無しさん
07/05/03 13:35:36
そのコードポイントでどう判断するんだ？

128:デフォルトの名無しさん
07/05/03 13:40:50
JIS X 0208でもＡとΑとАはコードポイントで何文字か区別つくっしょ

129:デフォルトの名無しさん
07/05/03 13:42:09
>>124
>ウニコードの話してるんだろ？　なんでasciiの話が出るんだ？
Unicodeの話だろ？
ascii範囲だけが多く使われていたらだよ。わかれよ。
Πが使われていたらロシアとかだよ。わかれよ。

130:デフォルトの名無しさん
07/05/03 13:48:30
ascii　ってのは　基本ラテン文字の事だろ？
URLﾘﾝｸ(code.cside.com)

だったら、どうしてコレだけで英語だとわかるんだ？

131:デフォルトの名無しさん
07/05/03 14:02:01
完全に分かる分けないだろ。
後は単語で判別だわな。

132:デフォルトの名無しさん
07/05/03 14:02:25
>>117
Pascal string と C string。

133:デフォルトの名無しさん
07/05/03 14:09:18
>>132
Pascal stringって、文字列の先頭に文字の長さが格納されてるってもんじゃないの？

なんでPascal stringだとUTF-16マンセーになるか、全然説明になってないよ。

134:デフォルトの名無しさん
07/05/03 14:09:49
標準関数自体が今となっては問題の種な訳だが。

strsafe.h で追加された文字列操作関数について
URLﾘﾝｸ(ir9.jp)

135:デフォルトの名無しさん
07/05/03 14:13:23
kono bunshou ha nihon-go desu.

136:デフォルトの名無しさん
07/05/03 14:53:41
>>124
EUC-JPの半角英数だから日本語と決めつける方がどうかしてる
コメントに日本語が使われてるC言語のソースの単語は全部日本語か?
そもそもISO-8859-1の時点ですでに欧州の文字統一しまくりなわけだが?

137:デフォルトの名無しさん
07/05/03 15:11:27
>>134
バッファオーバーフローは、古い関数だからおこるの？違うだろ。

なんであの会社は作り直しを奨励するようなことをやりたがるの？
仕事を増やすためじゃないの？

138:デフォルトの名無しさん
07/05/03 15:24:04
このスレと文字コード総合スレの違いは?

139:デフォルトの名無しさん
07/05/03 15:29:19
>>137
古い関数だと間違いやすく、新しい関数だと間違えづらいだろ？あってるだろ。

>なんであの会社は作り直しを奨励するようなことをやりたがるの？
古いC関数は使わないってのはもう常識なのに…
お前何十年と情報から隔絶されてたんだ…

>仕事を増やすためじゃないの？
逆逆。古い関数使うお前のようなバカの尻拭い仕事を減らすため。

140:デフォルトの名無しさん
07/05/03 15:37:53
>>139
>古い関数だと間違いやすく、新しい関数だと間違えづらいだろ？あってるだろ。
何の話をしてるのかね？関数名を間違えるのかね？
「間違いが起こりやすく」だろ？日本語でおｋ。

>古いC関数は使わないってのはもう常識なのに…
常識なんつーのは、所詮、てめーの知識でしかねーんだよ。
軽々しく常識なんて単語使うな。
お前は、動いているプログラムを変更するが大好きなのか？
それこそ、お前のようなバカの尻拭い仕事をさせられるぜ。

141:デフォルトの名無しさん
07/05/03 16:04:49
>>133
nullターミネートじゃないからUTF-16で間に0x00が入っててもそのまんま
扱えるってことじゃないの？

142:デフォルトの名無しさん
07/05/03 17:09:13
>>140
バカかお前。動いているプログラムを変更しろなんてダレが言った？

これから間違えにくい関数を用意したら、
>なんであの会社は作り直しを奨励するようなことをやりたがるの？
>仕事を増やすためじゃないの？
こんなバカなこと言うアホは死んでね^^

>何の話をしてるのかね？関数名を間違えるのかね？
はぁ？お前の脳内では「関数名を間違える」としか補完できないの?
「使い方を間違える」とかあるだろ。ホントバカだねお前ｗ

「「使い方を間違える」はおかしい」とか言い出したらバカ確定なw
バッファをオーバーするような「使い方は」「おかしい」から。

143:デフォルトの名無しさん
07/05/03 17:24:43
すいません、もうちょっと高度な話題でケンカしてもらえますか

144:デフォルトの名無しさん
07/05/03 17:33:42
ハンドアセンブル最強

145:デフォルトの名無しさん
07/05/03 18:04:08
理由を言わないといけないわけだが・・・？最強だけ言われても納得するのはどんだけ・・・・

146:デフォルトの名無しさん
07/05/03 18:12:03
諦めろ。　叫んだ方の勝ちだ　

147:デフォルトの名無しさん
07/05/03 19:43:27
>>142
>バカかお前。動いているプログラムを変更しろなんてダレが言った？
…作り直しを推奨する…。作り直し。新規の物に作り直しとは言わない。

>これから間違えにくい関数を用意したら、
用意しても全く構わないが、
#define等で旧式と同じようにも使えるようにするもんだろ。
それをしないから文句言ってんだ。

>「使い方を間違える」とかあるだろ。
予想も出来なかったわ。ま「使い方を間違える」なんて考える馬鹿が、あのs付きを有り難がるわけだ。
しかも、デフォルト設定。
M$も、オーバーフローも考慮できない馬鹿は、放置すりゃいいのに。

148:デフォルトの名無しさん
07/05/03 20:10:56
放置して叩かれるのはWindowsですから。

149:デフォルトの名無しさん
07/05/03 23:21:06
>>147
URLﾘﾝｸ(msdn2.microsoft.com)(VS.80).aspx
Visual C++ 2005の場合では、常に使える訳ではないが、
従来の関数がそのままセキュリティ強化版の関数呼出になるようにできる
_CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMESというマクロがある。

もっとも、C++限定なので、>>134のページと同じく、
そもそもC++ならクラスでカプセル化しろよということになるのだが。

150:デフォルトの名無しさん
07/05/04 00:11:02
>>124
>EUC-JP なら日本語と判るのに
確かにEUC-JPなら日本語だけど、その前に
あるバイナリ列がEUC-JPであるとどうやって判断するんだ？
ISO-8859やEUCであることはわかっても
どこの国のかは単純には判断できないだろ

151:デフォルトの名無しさん
07/05/04 10:34:29
>>129は世界には言語が５つくらいしかないとでも思ってんのか？
例えば、英語とインドネシア語はどうやって判別するんだ？ｗ　統計的手法とか言うなよ。お前の発言と矛盾するからな。
ウィキペディアにあるような、英文の中に日本語の単語が引用されてるテキストの扱いはどうなるの？

152:デフォルトの名無しさん
07/05/04 11:00:39
っ地球上の3人に1人はちうごく人

153:デフォルトの名無しさん
07/05/04 11:34:10
インドも恐ろしい。下手すると、世界の現行文字の３分の１くらいはインド１国で占めかねない。

154:デフォルトの名無しさん
07/05/04 12:52:20
お前ら言語タグ使えよ。

155:デフォルトの名無しさん
07/05/04 13:33:44
> ウィキペディアにあるような、英文の中に日本語の単語が引用されてるテキストの扱いはどうなるの？
それはEUC-JPでも全く同じように問題なわけで
文字コードで言語判別しようとするのがそもそもの間違い

156:デフォルトの名無しさん
07/05/04 13:58:05
「日本語をアルファベットで表記する」なんていうこともあるし、
言語とスクリプト(日本語では「用字」だっけ?)も分けて考えないといかん。

157:デフォルトの名無しさん
07/05/04 14:02:25
yorosikuと夜露死苦と紐育と上海はそれぞれ何人の何語の何文字なのかというやつだな。

158:デフォルトの名無しさん
07/05/04 17:33:09
This site is Japanese only.
と英語で書いてある日本語サイトとはこれいかに

159:デフォルトの名無しさん
07/05/04 17:58:11
Ｓｏｒｒｙ　Ｊａｐａｎｅｓｅ　ｏｎｌｙとか

160:デフォルトの名無しさん
07/05/04 18:11:29
哀れな日本人のみ利用可能

161:デフォルトの名無しさん
07/05/04 18:19:31
しかも全角

162:デフォルトの名無しさん
07/05/04 20:10:22
たまには縦倍角・横倍角・４倍角も思い出してあげて

163:デフォルトの名無しさん
07/05/04 21:08:28
フォントの拡大縮小が自由にできなかった時代の遺物ですね
テラナツカシス

164:デフォルトの名無しさん
07/05/04 21:11:07
半角全角もあぼーんしてくれ

165:デフォルトの名無しさん
07/05/04 21:16:01
半角カナは組み込みでまだ使ってます
Unicode？なにそれ？

炊飯器で使われるようになったらUnicode勝利宣言してもいいかな

166:デフォルトの名無しさん
07/05/04 22:05:58
そこに全角文字、マルチバイト文字はあるのか？

167:デフォルトの名無しさん
07/05/04 23:38:55
笑園漫畫大王

168:デフォルトの名無しさん
07/05/05 00:05:38
This Home Page is Link Free !

169:デフォルトの名無しさん
07/05/05 09:05:28
This Home Page is Link GPL!

170:デフォルトの名無しさん
07/05/05 11:53:34
This Home Page is Open Source.

171:デフォルトの名無しさん
07/05/13 17:05:06
「私のために争わないで」文字コードのUTF8さん、自殺 : bogusnews
URLﾘﾝｸ(bogusne.ws)

ｸｿﾜﾛﾀ

172:デフォルトの名無しさん
07/05/13 17:18:03
ネタにマジレスするのもアレだがUTF8とCP932の年齢がおかしくないか?

173:デフォルトの名無しさん
07/05/17 13:33:45
アスキーとアンジーの違いは？

174:デフォルトの名無しさん
07/05/17 13:49:36
>>173
JIS と JIS X 0201 の違いを聞いてるようなもんかな

175:デフォルトの名無しさん
07/05/17 14:16:28
？

176:デフォルトの名無しさん
07/05/17 14:29:07
UTF-8
と
UTF8
の
どっちが正しい？

177:デフォルトの名無しさん
07/05/17 16:40:25
前者

178:デフォルトの名無しさん
07/05/17 19:01:44
どっちも正しい

179:デフォルトの名無しさん
07/05/17 19:18:30
>>174
JISじゃなくてJSAだろ。

180:デフォルトの名無しさん
07/05/17 19:42:29
>>176
MIME charset名としては前者

181:デフォルトの名無しさん
07/05/17 19:49:39
ISO/IEC 10646の表記も、Unicode Bookの表記も前者。

182:デフォルトの名無しさん
07/05/19 05:55:00
>>177-181
沢山回答頂きありがとうございます
MySQLを使っていてデフォルトを
Latin1からUTF8に変えたんですが
こいつはUTF-8じゃなくてUTF8と
書かないといけないみたいで
なんで2種類あるのかなぁと

183:デフォルトの名無しさん
07/05/19 07:43:53
ハイフンはトークンの区切りになるからでしょ。

184:デフォルトの名無しさん
07/05/29 20:09:42
シフトジスは shift-jis
だけど
ジスは iso-2022-jp

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

185:デフォルトの名無しさん
07/05/29 20:29:25
>>184
ｋｗｓｋ

186:デフォルトの名無しさん
07/05/29 20:47:39
URLﾘﾝｸ(e-words.jp)
URLﾘﾝｸ(e-words.jp)

.NETのエンコードの話なんだけど、ジスコードの規格っていろいろあって、
iso-2022-jp 日本語 (JIS)
csISO2022JP 日本語 (JIS 1 バイトカタカナ可)
iso-2022-jp 日本語 (JIS 1 バイトカタカナ可 - SO/SI)
迷うよな

187:デフォルトの名無しさん
07/05/30 00:17:09
いわゆるシフトJISだってShift_JIS,　Shift_JIS-2004,　CP932　(Windows-31J)と種類豊富
大体CP932以外使わないけどな

188:デフォルトの名無しさん
07/05/30 00:20:07
WEBとかエンコードの柵が強いからいやだなぁ・・・
もう慣れたけど、うっかりで文字が化けたりする敏感なの何とかしてほしいな

189:デフォルトの名無しさん
07/05/30 00:33:06
Unicode以外使ったら罰金。

190:デフォルトの名無しさん
07/05/30 00:38:27
>>189
じゃぁ、まずシフトJISで書き込みを行った >>189 が率先して
UNICODEコンソーシアムに罰金を払ってください。

191:デフォルトの名無しさん
07/05/30 02:45:57
俺専用コード

ロリコードとかだめっすか？

192:デフォルトの名無しさん
07/05/30 03:11:59
>>191
ぷにコード(実在する)でも使ってなさい

193:デフォルトの名無しさん
07/05/30 07:31:56
その括弧がきは馬鹿っぽく見える

194:デフォルトの名無しさん
07/05/30 07:40:08
そういう演出は必要さ。　首相の「ザンキにたえない」発言と同じ。

195:デフォルトの名無しさん
07/05/30 08:41:11
「ザンキにたえない」ってどういう意味なん？

196:デフォルトの名無しさん
07/05/30 08:46:01
URLﾘﾝｸ(www.asahi.com)
＞首相周辺は「こういう結果に至ったことへの自らの責任を、この言葉に込めた」と解説する。

197:デフォルトの名無しさん
07/05/30 10:29:13
スクリューパイルドライバーの吸い込みを防げないことだろう

198:デフォルトの名無しさん
07/05/30 13:14:37
文字コードが乱用されているのはプログラマーとしてはやりづらい。
いっそのことすべてUnicodeにしてくれれば手間が省けるのにorz

199:デフォルトの名無しさん
07/05/30 14:45:29
Unicode自体が何種類もある事態

200:デフォルトの名無しさん
07/05/30 15:55:44
すべてUnicodeにしようってのは
そばの出前も会社の通勤も全てトラックを使おう
ってのと同じくらいナンセンス

201:デフォルトの名無しさん
07/05/30 16:18:43
そのUnicodeだって、結合文字列・合成済み文字とか、文字列の向きとか
UTF-16のサロゲートペアとか、考え込むネタは尽きないわけで

202:デフォルトの名無しさん
07/05/30 18:09:49
字体の扱いもおかしい
利用は辞退させて頂く

203:デフォルトの名無しさん
07/05/30 18:34:53
審議中（AA略

204:デフォルトの名無しさん
07/05/31 07:56:46
16bitじゃ絶対無理って最初からわかってたのに、
16bitに無理やり収めようなんて考えて自爆した欧米人は馬鹿すぎ

205:デフォルトの名無しさん
07/05/31 09:59:32
8bitで十分だったから16bitにするだけでもビビってたのさ

206:デフォルトの名無しさん
07/05/31 11:37:56
かれこれ20年になるのか

207:デフォルトの名無しさん
07/05/31 13:38:31
アメリカに限れば、7bitででも足りてたんだよね？

208:デフォルトの名無しさん
07/05/31 14:06:20
5bitでも足りるわな
URLﾘﾝｸ(www.trans-usa.com)

209:デフォルトの名無しさん
07/05/31 14:58:18
PCのインターフェースもパラレルからシリアルになってきたし、
文字コードも可変長なシリアルに変更しようぜ

210:デフォルトの名無しさん
07/05/31 16:59:59
それとこれとは訳が違う。
しかも例えが逆だろう。

211:デフォルトの名無しさん
07/05/31 17:23:43
>>209
つUTF-8

212:デフォルトの名無しさん
07/05/31 20:31:39
>>201
Unicode「と」他のあらゆるコードを全部相手にするよりはマシ

213:デフォルトの名無しさん
07/06/01 00:11:51
>>192
残念ながらPunycodeはピュニコードと音訳するのが近い。

214:デフォルトの名無しさん
07/06/01 05:31:51
うにこーど
ゆにこーど

どっちが正しいですか？

215:デフォルトの名無しさん
07/06/01 06:57:40
うにっくすとおなじくうにこーどがただしいですよ。

216:デフォルトの名無しさん
07/06/01 09:39:31
URLﾘﾝｸ(www.uny.co.jp)
ここも「ウニー」だしな

217:デフォルトの名無しさん
07/06/01 09:40:30
日本ウニシス

218:デフォルトの名無しさん
07/06/02 08:50:03
ウではじまるとウインドーズみたいで嫌だな

219:デフォルトの名無しさん
07/06/02 08:54:13
シャーペンの替え芯売ってるあのメーカってウニと読むのか

220:デフォルトの名無しさん
07/06/02 10:19:14
いいえ、三菱鉛筆です。

221:デフォルトの名無しさん
07/06/02 12:07:44
ウマ・サーマン？
ユマ・サーマン？

222:デフォルトの名無しさん
07/06/02 12:11:32
ウマ・サーマン！

223:デフォルトの名無しさん
07/06/02 12:26:54
Unimog
Wikipedia項目ﾘﾝｸ

224:デフォルトの名無しさん
07/06/02 14:37:17
ウナイテッド・ステイツ・オブ・アメリカ

225:デフォルトの名無しさん
07/06/02 14:45:19
知り合いのヌーヨーカー(w)は「ヤイェヨ」は変わらないけど「ユ」は「ウ」になるって言ってた。

226:デフォルトの名無しさん
07/06/02 20:24:27
Nuyork ？

227:デフォルトの名無しさん
07/06/02 21:31:38
ewの発音は、元来「ユー」なんだけど、「ウー」に化けているのでnewが「ヌー」になる。

228:デフォルトの名無しさん
07/06/02 21:39:16
４へぇ～

229:デフォルトの名無しさん
07/06/02 22:47:15
最初 knew を /nu:/ と発音されたときはさっぱり理解できんかったなあ。

230:デフォルトの名無しさん
07/06/08 10:40:47
TRONコードに統一しようぜ

231:デフォルトの名無しさん
07/06/09 02:54:12
TRONコードは(少なくとも現在の実装は)日本のことしか考えてません

232:デフォルトの名無しさん
07/06/09 16:03:04
>>230
ｽﾚﾘﾝｸ(os板:7-13番)

233:デフォルトの名無しさん
07/06/09 22:50:28
TRONコードに収録されてる文字のグリフはTRON文字収録センターで公開されてるけど
同定のための情報は提供されてないな。それは超漢字という製品に付けて売ってるから
公開できないだろうし

234:デフォルトの名無しさん
07/06/11 19:41:57
エスペラントでOK

235:デフォルトの名無しさん
07/06/12 09:50:19
Mi estas tre ĝoja konatiĝi kun vi.

236:デフォルトの名無しさん
07/06/12 23:33:50
>>235
これエスペラントなの？
最初スペイン語かと思った。

237:デフォルトの名無しさん
07/06/12 23:37:08
Mi estasでI amなのは覚えてる。
この辺の語彙はラテン語系から採用してるんだよな。

238:デフォルトの名無しさん
07/06/12 23:40:10
あ、やっぱりそうなんだ。

239:デフォルトの名無しさん
07/06/13 00:05:44
だから印欧語族の連中には割と覚えやすいんだよ
日本語とか圧倒的に不利
ある意味Unicodeと一緒だな

240:デフォルトの名無しさん
07/06/13 00:07:46
利用者が単語登録してもいいところとかね。

次ページ