BTRON仕様OSとUNICODEの多言語を語るスレ

BTRON仕様OSとUNICODEの多言語を語るスレ at OS

1:Be名無しさん
02/08/05 14:54
表題通りのことを語るスレです。

2:Be名無しさん
02/08/05 15:04
（・∀・）ｽｰﾝｽｰﾝｽｰﾝ♪
(ﾟдﾟ)ﾊｯ!
（・∀・）ｽｰﾝｽｰﾝｽｰﾝ♪
(´Д`)ｲｪｧｽｰﾝｽｰﾝｽｰﾝｽｰﾝ
（・∀・）ｽｰﾝｽｰﾝｽｰﾝ♪
(´Д`)ｲｪｲｪｲｪｧ
（・∀・）ｽｰﾝｽｰﾝｽｰﾝ♪
(´Д`)ｲｪｧｲｪｧｲｪｧｲｪｧｽｰﾝ
(ﾟдﾟ)ﾔ!　
（・∀・）ｽｰﾝｽｰﾝｽｰﾝ♪
(ﾟдﾟ)ﾔ!　
（・∀・）ｽｰﾝｽｰﾝｽｰﾝ♪
(´Д`)ｲｪｧﾓﾝﾓﾝ
(ﾟдﾟ)ﾔ!　
（・∀・）ｽｰﾝｽｰﾝｽｰﾝ♪
(´Д`)ｼｹﾀｼｹﾀ
(ﾟдﾟ)ﾔ!　
（・∀・）ｽｰﾝｽｰﾝｽｰﾝ♪
（・∀・）ｽｰﾝｽｰﾝｽｰﾝ♪
（・∀・）ｲｪｰｱ!
（・∀・）ｽｰﾝｽｰﾝｽｰﾝ♪
（・∀・）ｲｪｰｱ!　
(´Д`)ｽﾝﾍﾞｽﾝﾍﾞｿﾝｽﾝｽﾝﾊﾞ
（・∀・）ｽｰﾝｽｰﾝｽｰﾝ♪
(ﾟдﾟ)ﾌﾞﾍﾞﾗ!
(´Д`)ｽｰﾝｽｰﾝｽｰﾝ

3:Be名無しさん
02/08/05 16:48
バカが建てたスレはやっぱりバカっぽい。

4:Be名無しさん
02/08/05 17:07
UNKO

5:Be名無しさん
02/08/05 17:16
>自動車と同じに考えるところが頭悪いなVHSとベータで考えてみろよ。

両方とも、もう終わっているよ。(藁

6:Be名無しさん
02/08/05 20:12
ZOOMをスーンと聞き違えた馬鹿の作った文章をコピペする
奴が2で居るスレは終わりだろ。
まぁ、1の時点で終わってるが。

7:Be名無しさん
02/08/05 22:56
URLﾘﾝｸ(news.2ch.net)

の890-902の話題。

902 名前：名無しさん＠3周年投稿日： 02/06/08 01:38 ID:A44OC3l0
>>899

ダブっている文字の数を考えるとカスタマイズ作業だけでも
相当なものになるだろうけど、まあそれは置いておくとして。

同一文字の重複か異体字かを各ユーザが自由にカスタマイズ
するものとすると、TRONコード上では異体字の区別を含めた
厳格な文字の同定ができないということにならない？
(TRONコード上に定義された2つの文字を、ある人は同じ文字だ
と言い、他の人は各々異なった字形を持つのだと言う。)

異体字を逐一区別して片っ端から収録しておきながら、
結局同定できないってのは凄い問題じゃないか、と。

8:Be名無しさん
02/08/05 23:01
>>6
バカか。

9:Be名無しさん
02/08/05 23:13
つーか、
www.iana.org/assignments/character-sets
に登録されてない、charsetは。。。

10:Be名無しさん
02/08/05 23:24
URLﾘﾝｸ(cocoa.2ch.net)
の53も興味深い。

53 名前： login:Penguin 投稿日： 01/10/17 00:30 ID:YQKlNfNV
>>38
TRONコードは、誰かが新しい文字が必要だと思い、申請したら、
例え点を一個追加するだけでも、それは追加される。だから、

> なら別々にして必要に応じて変換ライブラリーみたいなの使えばいいと思うぞ。

は、日々変化する。それは「いい」か？
文字の同定の基準が存在し、かつ無闇に文字集合が変動しない、
という取り決めがなかったら、大変だぞ。

> これは運用の問題だろ？
> 斎藤と斉藤と齋藤を区別したいときもあれば同じに扱いたい時もある。

文字集合が固定されている環境でのみ、その要求は満たされる。
新しい「齊」や「藤」が次々に生まれる環境では、それらを「同じに扱」うことは、
原理的には可能だが、現実問題としては難しい。

11:Be名無しさん
02/08/06 12:39
>>7
まあ、そのあたりが本質だわな。
超漢字ってのは「後回しシステム」なのよ。
符号化する上で最も難しく手間もかかるのが文字の同定。
それを「後回し」にして、手っ取り早く文字数を誇るために
あれもこれも見境なく詰め込んじまった。
だから現状ではまともな運用なんかできっこない。
インド系文字の合成も「後回し」で、
使い道のない符号表上のグリフだけが実装されている。
決まり文句は「今後対応していきます」。
で、原稿プロセッサはどうなったのかと小一時間（略

12:Be名無しさん
02/08/07 08:46
トロ吉の反論待ちage

13:Be名無しさん
02/08/07 17:55
>>7
んー、一般的には、なりますね。異体字のというか文字の同定のためのデータベースみたいなのを
共有しなければならない感じですよね。（全世界のそれを共有する必要はないでしょうが、
それでも標準みたいなのを想定しないと組み合わせの爆発が起きてしまうかな）
逆に言えば、そのDBの共有ができれば問題なさそうですが、ややSF的なのかな。

これはコードに文字同定の問題を持ち込むことを避ける以上、必然的に招く事態じゃないでしょうか。
TRONコードってそういうものなのでしょう。いっぽう、たとえばUNICODEやJISは、文字の同定を
文字コードがやるのだ!! という考え方なんでしょうね。どっちもいまいち要改善って感じですけど、
文字の同定の問題が学問的に解決していない以上、しかたないですね。

本題に戻ると、文字セットを追加するしくみはいちおうあるようなので、前述のDBにユーザーが追加を
できる仕組みが必要ということですか。

ageるほどのスレではないのでsage

14:とろ吉
02/08/08 06:35
反論できず。ただ、UNICODEも日本漢字で補助漢字を使ったことが将来問題になるかも、くらいは言っとく。どうするよ、第3、第4水準漢字を?

15:Be名無しさん
02/08/08 11:15
＞どうするよ、第3、第4水準漢字を?

もう入ってるし、すでに実装もあるぞ。

16:Be名無しさん
02/08/08 12:52
>>13
その「コードに文字同定の問題を持ち込むことを避ける」ってのが
TRONコードの「思想」のように言われているけど、
もともとの計画では、センセも漢字は統合した上で収録するつもりだったんだよ。
同定を避ける云々は後付けの理屈。

17:とろ吉
02/08/08 21:28
>15 UNICODEに? それだとTRONを笑えんが。

18:Be名無しさん
02/08/08 21:56
>>17
もちろんUnicodeに入っているんだが、
「それだとTRONを笑えん」ってのはどういう意味？

19:Be名無しさん
02/08/08 22:34
UnicodeもTRONコード同様に文字同定の問題を避けている証拠になるから？
（補助漢字と第3、第4水準漢字は収録してる文字に重複がある）

20:Be名無しさん
02/08/09 00:11
Unicodeへの第3～4水準の漢字追加って既に
収録された漢字と重複してる分は取り除いてな
かったっけ？

21:とろ吉
02/08/09 00:19
追加した際、同定基準についてどうしたかが一番知りたい。芝野氏、補助漢字を徹底的に批判してたし。

22:Be名無しさん
02/08/09 00:22
>>16
TRONコードの「思想」かどうかは知らないのですが、現状ですね。

> もともとの計画では、センセも漢字は統合した上で収録するつもりだったんだよ。
> 同定を避ける云々は後付けの理屈。

へえ、そうなんですか。それは聞いたことがありませんでした。
言葉足らずでしたが、>>13 は現状に対する私の「解釈」なので、後付けとか前付け
とかいう話ではありませんでした。
「センセ」は「もともと」は文字の同定とかの問題をあまり知らなかっただけじゃ
ないんですか？で、調べていって「だめだこりゃ」。あたりまえですが。

＃JISが字形の統合とか言って新しく珍奇な字を作るから余計ややこしくなるじゃ
＃ないか。ぷんぷん。

23:g
02/08/09 00:34

-------風俗の総合商社・ＭＴＴどこでも-------

〇デリバリーヘルス〇デートクラブ〇女性専用ホストクラブ〇
〇ハードＳＭ奴隷クラブ〇レズビアン倶楽部〇ホモ・オカマ倶楽部
〇変態痴女と遊ぶ会〇痴漢・覗き趣味の会〇変態同好会・各種！
●楽しく遊べます！　090-8002-8356番
-----------美男・美女会員など多数在籍中-----------
　 URLﾘﾝｸ(www.mttdocomo.jp)
-----女性アルバイト随時募集・高収入（日払い）月100万円可能-----
-----レズビアン・スタッフ●ホモスタッフ●女性専用ホストスタッフ同募-----
URLﾘﾝｸ(www.mttdocomo.jp)
------------------------------------------------

24:Be名無しさん
02/08/09 12:48
>>21
JIS X 0213の包摂規準で同定し、
補助漢字その他との重複を排除した上で追加申請、と思われ。

25:とろ吉
02/08/09 14:11
>24
そうなのか。
文字追加の際、JIS X 0213の基準では補助漢字部分で入れられない物もあるんじゃねーのとか思っていたが、俺の思い違いだったか。
補助漢字以外にもすでに追加されていたし、実際に不可能だと思ってたよ。

ところで、実装された奴って組み込み用の奴?

26:Be名無しさん
02/08/09 16:43
Mac OS Xのことじゃねーの？＞実装

27:Be名無しさん
02/08/09 17:18
>>22
JISは「字形の統合」なんて言ってないだろ。

28:とろ吉
02/08/09 21:11
Mac OS Xは違うよ。あれはUNICODEの対応バージョン出すとき問題出るね。

29:Be名無しさん
02/08/09 21:25
>>28
悪いけど意味判らん。

30:とろ吉
02/08/09 22:11
おれの間違った認識による書き込み。すまん、Macを愛する方々。

31:Be名無しさん
02/08/10 14:42
>>27 ああ、「統合」とは言ってないんでしょうね。私の念頭にあった
のは、たとえば(月並みですが)「鴎」の偏の問題です。
まあいろんな人が言っていることなのでここで書いてもしょうがない
ことでした。

32:Be名無しさん
02/08/10 19:22
>>31
了解。その例は「通用字体の準用」。
新聞で使われている字体を採用したもので「作った」わけではない。
といっても、83年JISの変更を擁護する気はさらさらないけどね。

33:Be名無しさん
02/08/11 05:29
97 でデザイン差である、と強弁・詭弁を弄して、
「包摂」しちゃった、ってほうか？　はしご高とか。

凶悪なのは「かき」と「こけら」なんかで、頭痛100%モノ
だったりするのな。

「統合」という用語が使われるのは、Unicode および
ISO 10646 の 'CJK Unified Ideographs' の訳で、
「CJK 統合漢字」だね

34:Be名無しさん
02/08/11 12:15
>>33
脳内で話を作らんように。
97JISは口高と梯子高の違いを「字体差」とした上で
包摂していると思われ。

35:31
02/08/12 09:03
>>33 いえ、意図は >>32 の通りです。珍妙で無理のある「準用」でした。すみまそんがこの話はもう止めにしましょう。

36:とろ吉
02/08/13 13:01
ちょっと勉強してきた。確認した限り、Mac OS Xてまだ全部の第三、第四水準の漢字を入れてはいなかったんだ。その態度、立派です。(提案の位置や外字領域に入れてると思ってました)

37:Be名無しさん
02/08/13 13:54
>>36
それはMac OS X 10.0の理解としては間違いではないが、
いかんせん情報が古い。
JIS X 0213のBMP未収録分はExtension Bの一部として
2001年5月のUnicode 3.1で規格化され、
2001年9月のMac OS X 10.1でサポートされている。

38:Be名無しさん
02/08/13 14:08
>>36
ん？
URLﾘﾝｸ(developer.apple.com)
には、

　Support for the JIS X 0213, HK-SCS, and GB 18030 character sets has been added.

って書いてあるぞ。

39:Be名無しさん
02/08/13 14:09
>>38
GB18030ってことは、
Surrogateもオッケーってことっすね。

40:とろ吉
02/08/13 21:17
突っ込みサンクス！

ついでに質問。
Mac OS Xでは補助漢字にだけある文字はサポートしていない、っていうのはいまでも?
はしご高はバリアントで表現してるよね?
フォントに含まれていない文字を表示しなければならないとき、別のフォントを使って自動的に表示する機能はある?

暇があれば教えてくれるとありがたい。

41:Be名無しさん
02/08/13 22:09
>>40
> フォントに含まれていない文字を表示しなければならないとき、別のフォントを使って自動的に表示する機能はある?

Winで言うUniscribeがあるかってことかな？
Macは、ATSUI(Apple Type Services for Unicode Imaging)があるけど、
URLﾘﾝｸ(developer.apple.com)
font substitutionとかはサポートしてるみたい。（よく知りません）

意外とこのあたりはMacってさらりとやってたりするんだよね。
MUIも対応してたりするし。
Winはなんかやりました！みたいな感じでアピールするけど。

42:Be名無しさん
02/08/13 22:47
>>40
> Mac OS Xでは補助漢字にだけある文字はサポートしていない、っていうのはいまでも?

Unicode3.2をサポートしてるので、
その範囲内ならいくらでもどーぞ。

> はしご高はバリアントで表現してるよね?

variant tagを使って表現ってことか？
違う。はしご高はU+9AD9に入ってる。
ちなみに、OSXについてくるヒラギノフォントを使えば、はしご高は表示可能だよ。
さらにSurrogate文字もちびちび、このフォントには入ってる。
例えば、U+29EBDとかも表示できる。

43:Be名無しさん
02/08/14 18:00
>>41
WWWでしっかりアピールしてんじゃん。

44:Be名無しさん
02/08/14 23:15
>>43
Uniscribeとくらべるとなあ。。。
盛り上げぶりが違うと思う。

45:とろ吉
02/08/15 02:18
おー、答えてくれてありがとう。

で、ATSUIのページを見てきたけど、違うみたい。
uniscribeって、リガチャーとかカーニングとかいうやつで使う奴ではないですか?(これをサポートしてないようでは多言語なんて言えないね>超漢字)
質問がわかりづらかったと思うんで、例を上げて説明すると
ある文字の異体字フォントを作った。で、このフォントを使うとき、この文字以外はヒラギノで表示するようにする、みたいな感じです。
(Windowsだとアルファベットしか含まないフォントを漢字にも適用すると、漢字部分はトウフになるけど、Macはどう?こっちのほうがわかりやすい?〉

補助漢字はサポートし始めたんですか。ん～、じゃあ、Mac OS Xの最初のバージョンで入れていなかったってのはなんでだったんだろう。(これも、俺の記憶違い?〉

はしご高をvariant tag〈こう書くのか、これも知らなかった）使わないのも意外。だいぶ昔、unicodeが言語指定をもたなかったころ、あれは中国の文字のためのコードだから日本語では使えない、とか聞いていたんだけど。
ちなみに、U+29EBDはBBBでは表示できなかったんで、なんの文字かわかりませんでした。(ゲタが4つも表示されたが、アレはなんだったんだろう?)

46:Be名無しさん
02/08/15 03:33
>>45
できるみたいだよ。
例えばOmniWebだと、
デフォルトではLucida Grandeっていう欧文フォント使うようになってるけど、
漢字とかの表示には勝手にヒラギノが使われたりしてる。

どうでもいいことだけど、Lucida Grandeにεがあるのはいいんだけど、
これの字体が気に入らないんだよねぇ。

47:Be名無しさん
02/08/15 09:45
>>45
> で、ATSUIのページを見てきたけど、違うみたい。

端から端まで読んだか？これは見たか？
URLﾘﾝｸ(developer.apple.com)

> (Windowsだとアルファベットしか含まないフォントを漢字にも適用すると、
> 漢字部分はトウフになるけど、Macはどう?こっちのほうがわかりやすい?〉

これはWindows2000やXPでは、Uniscribeと、
表示できるフォントがインストールされていて、
Unicode API、（例えば、TextOutWなんか）の場合は、
英語フォントでもちゃんとfont substituteされて、
漢字なんかは、とーふにならずに表示されるはず。

> ちなみに、U+29EBDはBBBでは表示できなかったんで、なんの文字かわかりませんでした。(ゲタが4つも表示されたが、アレはなんだったんだろう?)

ちょーかんじのブラウザは、
UnicodeのSurrogate文字は対応していないの？
UTF-8で試して味噌。は、U+29EBDは、"\xf0\xa9\xba\xbd"だよ。

48:Be名無しさん
02/08/15 09:46
>>45
ちゅーか、Unicodeがらみの話をするなら
www.unicode.orgを見るように。
URLﾘﾝｸ(www.unicode.org)
にすべての文字がある。で、
URLﾘﾝｸ(www.unicode.org)
を見れば、そのglyphがわかる。

49:Be名無しさん
02/08/15 11:27
＞補助漢字はサポートし始めたんですか。

Mac OS Xに付属するヒラギノについて言えば、
補助漢字のすべてを含むわけではない。
ただ、JIS X 0213に含まれない補助漢字であっても
Adobe-Japan1-4などを経由して入っている場合もある。

それから>>42の言うとおりOSの枠組みとしては
Unicode 3.2をサポートしているので、
すべての補助漢字を表示できるかどうかはフォント次第。

50:Be名無しさん
02/08/15 12:59
>>47
スマソ。
URLﾘﾝｸ(developer.apple.com)
だった。ここは見た？
ATSUSetTransientFontMatching()
なんかまさにそうだと思うんだけど。

51:Be名無しさん
02/08/15 13:08
結局ﾄﾛﾘﾝは糞ってこと?

52:Be名無しさん
02/08/15 14:13
＞はしご高をvariant tag〈こう書くのか、これも知らなかった）使わないのも意外。

Mac OS Xのグリフ切り換えは、variant tagとは無関係で独自のメカニズムを使う。
情報交換のためにvariant tagを使うかもって話は確かにあったが、
それは将来の話だし実現するかどうかは不明。
ちなみにvariant tagというのは古い呼称。今ではvariation selectorと呼ぶ。
URLﾘﾝｸ(www.unicode.org)

＞unicodeが言語指定をもたなかったころ、あれは中国の文字のためのコードだから

言語指定は関係ない。
Unicodeにはさまざまな部分実装があるから、
たとえば「JIS X 0208とJIS X 0212のみ」って実装なら
U+9AD9は含まれないってことだろ。
ただし、ハシゴ高はNECだかIBMだかの外字として存在するから
U+9AD9に入ってなきゃ互換漢字として入ったはずのもので、
言い方を換えればU+9AD9はCP932との対応関係を持っているわけで、
現実にはこれを含まない実装は珍しいかと。

53:コギャルとHな出会い
02/08/15 14:13
URLﾘﾝｸ(kado7.ug.to)

朝までから騒ぎ！！
　　　小中高生
　コギャル～熟女まで
　　　メル友
　　i/j/PC/対応

女性の子もたくさん来てね
　　小中高生大歓迎です　　　　　　　　　　　　　　　　　
全国デ－トスポット情報も有ります。
全国エステ＆ネイル情報あります。

　　激安携帯情報あります。

54:Be名無しさん
02/08/15 14:39

ヒョデーイ！！！
URLﾘﾝｸ(2style.net)

＃音量ＯＮにして飛んでね（・∀・）ｲｲ！

参考スレッド森恒二ホーリーランド拳闘暗黒伝セスタス技来静也4
ｽﾚﾘﾝｸ(comic板:551-611番)

55:Be名無しさん
02/08/16 16:18
TRONを擁護する勇者はいないのか？

56:SAGE名無しさん
02/08/16 20:11
煽られてもねぇ...

ついでに。>>52
↓こういう現象があったりしますな。実際
URLﾘﾝｸ(www.microsoft.com)

57:Be名無しさん
02/08/16 20:35
non round-trip conversionの問題は有名だけど
それがどうして52へのレスになってるのかわからん

58:52
02/08/16 20:55
おっと出遅れた。>>57に付け加えることはないな。

59:とろ吉
02/08/17 22:48
レス遅れてすいません。いろいろついてるなぁ。

>46
超漢字のウェブブラウザBBBの場合、もっとひどいことがあったりする。
補助漢字外字の第三水準漢字を表示しているMac関係のページの文字が汚かったんで調べてみると、中国の文字にしていやがった。

>47、50
>端から端まで読んだか?これは見たか?
う、ほとんど読んでませんでした。ぐーぐるでuniscribを検索して2、3読んだだけでした
UniscribeもATSUIもいろいろ出来ますね。
超漢字の標準ウェブブラウザBBBはサローゲートは未対応みたい。表示できませんでした。

>48
ww.unicode.orgなら見てきました。で、そこで表示されたのがゲタ4つでした。
PDFは今んとこ超漢字で表示する方法無いんで見てません。〈もっとアプリがほしー!〉

>52
variation selectorですか。憶えておきます。
実現するかどうか不明ってのは、ちょっと不思議。いまでも、おんなじことやってるはずなのに。
なにか問題でもあったんですか?

はしご高が表示可能とする理屈も分かりました。
中国の漢字とかの話をいってたのは芝野さんだった記憶があるんで、あの人なら許さんよ、ってかんじで納得できます。

>55
同じとろ吉として頑張って欲しいが、それだと世の中がunicodeだらけになれば問題にならないんで、本質的な問題でもないと思う。
後戻りしない覚悟が必要なのはTAD〈実身／仮身も含む)も、unicodeもいっしょ、と言うことで。
(ついでに俺もどこが52へのレスなのかわからない。力になれずすまない）

60:Be名無しさん
02/08/20 12:13
＞variation selectorですか。憶えておきます。
＞実現するかどうか不明ってのは、ちょっと不思議。いまでも、おんなじことやってるはずなのに。
＞なにか問題でもあったんですか?

variation selector（variant tag）は、
UnicodeあるいはISO 10646という「文字コード規格」が提供する機能であって、
当然、プレーンテキストでの情報交換を想定している。
要するにグリフ置換機構を意味する一般名詞「ではない」ってこと。
variation selectorで情報を交換するには、
そのための「異体字リスト」が必要となるが、まだそんなものはないし、
今後（漢字用のものが）策定されるかどうかも不明。
Appleがやってるグリフ置換はvariation selectorによるものではなく、
現状ではPDFなりを使わないと情報交換できない。

61:とろ吉
02/08/20 20:05
>60さん "Appleがやってるグリフ置換はvariation selectorによるものではなく、"この部分ですが、24日発売の新しいMac OS Xでは、OSレベルでのバリアントのサポートを実現するらしいので、たぶんv

62:とろ吉
02/08/20 20:08
ariation selectorを使っていると思います。識者の方突っ込みお願いします。(前回の書き込み、途中で切れてた。これだからBBBは……)

63:Be名無しさん
02/08/20 21:50
>>61-62
単に異体字（バリアント）をサポートしてるってことじゃねえの。

64:とろ吉
02/08/21 13:00
＞63
いや、それは前からやってるんで。わざわざ発表することでもないと思う。

ところで、Mac OS Xのフォント呼び出しのメカニズムが書かれてたけどBTRONの【本来の】多言語処理ににてると思った。
unicodeやShiftJISが文字層で実際のフォントに割り当てられているIDがスクリプト層、と考えるとどうですか?

65:Be名無しさん
02/08/21 13:59
どんな用語を使おうと、多言語処理でやるべきことは変わらんだろ。
しかしTRONコードの「スクリプト層」は見事に死んだな。

66:Be名無しさん
02/08/21 19:11
URLﾘﾝｸ(www.unicode.org)

> Only the variation sequences specifically defined in the Unicode Character
> Database in the file StandardizedVariants.html are sanctioned for standard
> use; in all other cases the variation selector cannot change the visual
> appearance of the preceding base character from what it would have had,
> in the absence of the variation selector.

URLﾘﾝｸ(www.unicode.org)

> The tables here exhaustively list the valid, registered combinations of
> base character plus variation indicator. All combinations not listed here
> are unspecified and are reserved for future standardization; no conformant
> process may interpret them as standardized variants.

67:Be名無しさん
02/08/22 22:03
がしゅつかもしれんが
０２１３には０２１２とダブっている文字もあればそうでない文字もある。
０２１３にはＵｎｉｃｏｄｅに入ってない文字もある。

ＢＴＲＯＮっていつになったらスクリプト層が実装されるんだ？

68:Be名無しさん
02/08/23 19:44
つーか文字属層（重複した文字を同じ文字として扱う）も実装されてないぞ。

69:とろ吉
02/08/23 20:47
66で出ていたリンク先を見てきました。まだ漢字用のは規定されていませんね。
しかし、実際にやるとなると統合漢字が問題となってくるような。

あれ、Mac OS XのOSレベルでの対応ってのはなんだったんだ。また俺の勘違いか?

ところで超漢字で実装されてるのはスクリプト層とフォント層なんですが。
文字層で逆転できるもんが出来るのか?(「死んだ」とかまで言われてるし)
それよりも現在作られ続けているスクリプト層だけで出来たデータは将来どうなる?

70:Be名無しさん
02/08/23 21:21
>>67が言ってるのは、インド系文字のリガチャとかを表現する
（本来の意味での）スクリプト層のことだろ。

71:Be名無しさん
02/08/24 21:13
Unicodeによるなんちゃって国際化ってのは簡単にできるけど問題が多すぎ。
それに気づかないLinuxやXFree86は馬鹿。

72:Be名無しさん
02/08/25 05:04
問題は少ないかもしれんが簡単にはできない
本格的国際化とやらが実現する日を夢見て
国際化を見送り続けるよりはずっと現実的。

73:Be名無しさん
02/08/25 05:07
>>72
そしてどんどんドツボにハマっていく罠・・

74:Be名無しさん
02/08/25 09:51
ずっと絵に描いた餅を愛でていれば確かに
ドツボに嵌る機会すらないね。

何も得られないけど。

75:Be名無しさん
02/08/25 14:01
>>74
そうはいうが、
Unicodeは、Shift_JISよりは、かなり良いわけだよね。
それでも不満なやつは、今のOSに関して、どれもだめなわけだよな。
ちなみに、BBBはSurrogateにも対応してない罠。

76:Be名無しさん
02/08/25 21:53
>>71は国際化と多言語化の違いも分かっていない罠。

77:Be名無しさん
02/08/25 22:46
>>75

Unicodeは、最初の策定時に既に広まっていた
各国の文字セットを集めた交換用のテーブルと
しては十分な出来ですもんね。

ただ、漢字圏について言えば中国のGB18030が
素晴らしいので、ちょっと混乱しそうですね。

78:Be名無しさん
02/08/26 00:58
>>76は国際化と「アジアの猿共の言葉なんかどーでもいいよ、こんだけコード数増やしてやってんだから
おとなしく俺らの考えた規格にしたがってろよ。ｱﾒﾘｶﾏﾝｾｰ」の違いも分かっていない罠

79:Be名無しさん
02/08/26 08:13
Unicodeの漢字領域は日本人が中心となって中国
韓国各々の代表者と綿密に検討して作り上げた
事実を知らない奴ﾊｹｰﾝ

80:Be名無しさん
02/08/26 09:43
てめぇらみたいなガキはどせヒマだろ？だったらこっちゃ来い (

夢を見ている人たち
夢を見れない人たち
夢破れた人たち
夢を叶えた人たち
夢を追いかけてる人たち
夢を諦めた人たち
そして
全ての馬鹿たちに送ります

『一炊の夢』

URLﾘﾝｸ(www.geocities.co.jp)

81:Be名無しさん
02/08/26 15:06
>>79
なるほど。そいつらがｱﾒﾘｶﾏﾝｾｰだった訳ですね

82:Be名無しさん
02/08/26 17:06
>>69
確かにスクリプト層自体は実装されている。
インド系の文字あたりを例として問題を列挙すると……。

・スクリプト層に必要なグリフが実装されていない。
・ていうか、それ以前に必要なグリフが仕様化されていない。
・グリフ置換機構が実装されていない。
・ていうか、置換機構が仕様化されてもいない。
・ていうか、その前提となる文字属層の中身が仕様化されていない。
・ていうか、文字属層の仕様化は目途すら立ってないと思われ。

83:Be名無しさん
02/08/28 17:12
>>77
GB 18030が素晴らしいかあ？
「TRONと比べれば」ってのはナシだぞ。

84:Be名無しさん
02/08/29 11:49
>>83
Shift_JISと比べれば。

85:Be名無しさん
02/08/29 13:05
結局ﾄﾛﾘﾝは糞ってことでいいですかぁー?

86:Be名無しさん
02/08/29 13:20
>>85
お前は放置されている事にいいかげんに気づけ（ｗ

87:Be名無しさん
02/08/30 00:33
>>83

TRONと比べてもUnicodeと比べても文字鏡と比べても
漢字圏にとっては素晴らしいぞ。

何が素晴らしいって、主だったOSが既に対応可能に
なっているから。しかも、フォント依存ではなく。

88:とろ吉
02/08/30 05:08
その「主だったOS」に携帯のは入ってる?
(クッキー使用強制でBBBから書き込めなくなった。こういう「主だったＯＳ」しか考えないやつなんて大嫌いだ)

89:Be名無しさん
02/08/30 13:31
>>87
拡張性で言えば、すばらしいのかもしれないけど、
Unicode3.1（正しい？）プラスアルファでしょ？
だからたいしてUnicodeとかわらん気がするんだが。
もちろん異体字においてはUnicodeと同じ問題があるわけで。

ちなみにWinはネイティブキャラクタセットとしては
GB18030はサポートしてないよ。（MacOS Xも）
だから、NotePadとかでGB18030でセーブすることはできない。
UTF-16で、GB18030の文字は扱えると言っているだけ。

90:Be名無しさん
02/08/30 16:59
Winはサポートしてるぞ(藁

91:Be名無しさん
02/08/30 20:04
>>87
比較の対象がよくわからんのだが、
GB 18030って、文字セットとしては
（収録のタイミングが多少ずれることはあっても）
Unicodeと一緒だろ。

>>89
異体字におけるUnicodeと同じ問題って何だ？
骨がどうとかってやつか？

92:Be名無しさん
02/08/30 22:12
>>90
何をサポートしてる？
XPの中国語版であったって、ネイティブキャラクタセットは
あいかわらずGBKだよ。GetACP()呼ぶと936って返ってくる。
GB18030のコードページ54936はMultiByteToWideCharとかのAPIでしか使えない。
だからnon-Unicodeアプリは、GBKでしかのデータを処理（たとえばセーブとかね）できない。
XPであっても、あくまでもGB18030は変換用のキャラクタセット。
それはネイティブキャラクタセットじゃあない。

93:Be名無しさん
02/08/30 22:29
>>91
基本的にGB18030は、Unicodeコンパチだから、
ハンのエリアは、unifiedされてるってこと。

94:Be名無しさん
02/08/30 22:51
URLﾘﾝｸ(www.leverage.jp)

95:Be名無しさん
02/08/30 23:03
>>89

Windows2000以降はオプションでGB18030対応
しますよ。

96:Be名無しさん
02/08/30 23:11
★超オススメサイト★

ここをクリック！！！
↓↓

URLﾘﾝｸ(www.bea.hi-ho.ne.jp)

97:Be名無しさん
02/08/31 11:14
>>95
WinでいうGB18030対応ってのは、
UTF-16の中にGB18030の文字が入ってるから、
Unicodeアプリであれば、GB18030の文字が扱えますよってことだけ。

つーか、Win2000はオプションなんてないよ。
あるのは、
www.microsoft.com/china/windows2000/downloads/18030.asp
のパッケージを入れるだけ。
そうするとフォントとUnicode - GB18030ファイルの変換ツール、
変換テーブルなんかが入る。

98:Be名無しさん
02/08/31 12:07
>>97
地域と言語のオプションでちゃんと選択できるぞ。

99:Be名無しさん
02/08/31 13:11
>>98
ん？どこだ？
中国語とかは選択できるが、GB18030って選択できないぞ。
俺は、>>97のモジュールはWin2000に入れててあるが。

100:Be名無しさん
02/08/31 13:33
例えばさ、
キャラクタコード表で、宗体-18030フォント(SimSun-18030)を選んで、
Unicodeで、a000を入力してみな。
この文字はUnicodeで言う、Yi Syllablesの最初の文字ね。
ちなみに、GB18030だと、82 35 98 33で表される文字。
で、その文字をコピーして、メモ帳(NotePad)にペーストして、
そのファイルをセーブしてみなよ。
すると、Unicode(UTF-16かUTF-8)でしかセーブできないでしょ？ANSIじゃセーブできない。
これはなぜかっていうとGB18030をOSがネイティブでサポートしてないから。
Winは、言語が中国語では、GBK(Codepage936)しかサポートできないんだよ。
それは、Win32のNative APIが1文字あたり２バイトしか対応してないから。
これって、Winの制限らしいよ。

IBMのAIXとかSunのSolarisは、ネイティブでGB18030のロケールがあるらしいけど。

101:Be名無しさん
02/08/31 13:34
>>100
Win2000の場合ね。

102:Be名無しさん
02/08/31 16:17
>>99
中国語だ？簡体字(GB18030)ってのがあるだろ。

103:Be名無しさん
02/09/01 12:29
>>102
XPの話をしてるんだと思うが、
地域と言語のオプションのどこにでてくる？
詳細設定タブのコードページ変換テーブルのことを言ってる？
それは、Unicodeとそのコードページのキャラクタセットの変換テーブルを
インストールするかっていう設定だぞ。

104:Be名無しさん
02/09/01 12:45
>>95
つーか、このプログラムを走らせれば、
GBKがネイティブか、GB18030がネイティブかわかるぞ。
---test.c---
#include<windows.h>
void main()
{printf("%i\n", GetACP());}
------
で、Cでコンパイルして、コマンドプロンプトでこのプログラムを走らせて味噌。
936ってでたら、GBK。54936ってでたらGB18030がネイティブってこと。
Unicode対応でないアプリケーションはこのキャラクタセットで動く。
ちゃんと「地域と言語のオプション」の「詳細」のところを、
Simplefied Chinese（簡体字中国語だっけ？）に言語を変えておくことね。

105:Be名無しさん
02/09/01 13:07
>>103
バカだ(藁
変換テーブルがあるってことは、使えるってことだろ？
小学生でもそのくらいわかるぞ。

106:Be名無しさん
02/09/01 13:25
>>105
バカだ(藁
GB18030 - Unicodeの変換テーブルがあるってことと、
GB18030ネイティブキャラクタセットサポートとの違いがわからんらしい。
変換テーブルがあるってのは、そのキャラクタセットとUnicodeの文字変換が可能ってだけ。
GB18030ネイティブキャラクタセットをサポートってのは、
通常のNative Win32 APIにGB18030の4バイト文字とか入れても動くかってこと。
で、これはWinの場合動かないんだよね。あくまでも、GBKしか対応してない。
>>100が言っているように、"82 35 98 33"をテキストファイルに入れても、
メモ帳はそれを表示できないんだよ。

変換テーブルがあっても使えないんだよ、アプリがUnicode API使ってなくちゃね。
だから、Winでは
「OSのネイティブキャラクタセットとしてのGB18030はサポートしてない。
Unicode(UTF-16)の中には、GB18030の文字が含まれてるから、
Unicodeを使ってね。」
ってこと。

107:Be名無しさん
02/09/01 13:43
>>105
ネイティブがわかってないんでねーの？
メモ帳だとShift JISはセーブできるけど、
GB18030のキャラクタセットではセーブできん。
セーブしたければ、Unicodeでセーブするしかない。

つまり、Winの拡大解釈で行くと、
Unicodeで、UTF-16 Surrogateまでサポートすれば、
自動的にGB18030サポートってことになる。なんだかなあー。

108:Be名無しさん
02/09/01 16:04
WindowsがGB18030をサポートしているかという
話題を「ネイティブ」サポートしてるかという話に
勝手に摩り替えているバカはここにいるのですか？

109:Be名無しさん
02/09/01 17:26
ああ、メモ帳は確かにサポートしてないかもね(藁
メモ帳がWindowsだと思ってんの？

110:Be名無しさん
02/09/01 20:59
UTF16とGB18030の変換テーブルが搭載されれば、
アプリケーションがGB18030で保存する機能を搭載
するだけで対応完了。

111:bloom
02/09/01 22:37

URLﾘﾝｸ(www.leverage.jp)

112:Be名無しさん
02/09/02 00:35
話題になるのはUnicodeやGBばかり
TRONコードはいずこへ

113:Be名無しさん
02/09/02 04:52
>>108
>>83 >>87 >>89
と話がきてるから、Winは、ネイティブサポートしてないってのは
話しの流れからしてあってると思うぞ。

114:Be名無しさん
02/09/02 04:59
>>108-110
それじゃあ、GB18030のキャラクタを含んでる、
WinのUTF-16サポートは、すばらしいねって言うべきだろ？

> アプリケーションがGB18030で保存する機能を搭載
> するだけで対応完了。

それだけじゃだめ。
Win32のUnicode APIに全部置き換えなくちゃ。
メッセージもすべてUnicodeで書き換えなくちゃだめなんす。
つーか、Win32で、Native API、Unicode APIがあるってこと
わかってないだろ、きみ。

115:Be名無しさん
02/09/02 07:45
まさーに、>>110がMSの言ってることなのは確か。(Appleもね）
でもこれが困惑させるもとなんだと思う。
メモ帳の問題の話がでてたけど、それだけじゃない。
コマンドプロンプトもGB18030は入力、表示できない。
そもそも、printf()で、GB18030のコードを入れても表示できない。
Win9xで動くようにネイティブAPIのみ使ったアプリは、GB18030データ
もちろん壊れる。
それは、中国版WinXPのOSのデフォルトのキャラクタセットは相変わらずGBKだから。
Winが、GB18030ネイティブサポートしてたらこれらは動いたはずなのだが。

116:Be名無しさん
02/09/02 08:03
>>110
それじゃあ、ICU使ったほうが良いということで。
oss.software.ibm.com/developerworks/opensource/icu/project/

117:Be名無しさん
02/09/02 08:25
>>114

病気ですか？

自分以外はUnicodeAPIを知らないと何を根拠に騒いでいるの？

118:Be名無しさん
02/09/02 09:10
>>117
おいおい、病気はあんただ。
>>114読んで、「自分以外はUnicodeAPIを知らないと何を根拠に騒いでいるの？」
とは思えないんだが。。。
つーか、Win2000/XPがGB18030をネイティブキャラクタセットとして
サポートしてないのは正しいと思うぞ。

119:Be名無しさん
02/09/02 09:36
>>117
つーか、病気は、うぃんちゅうじゃねーか？
>>92に反応しただけで、スレちゃんと読んでねえし、
特に>>95あたり適当なこと言って、反論されて、
虫のいどころがつかねえから、最後まで怒ってる。

話を戻そうぜ。>>87に戻るけどさGB18030はTRONコードの代理にならんよ。
GB18030はUnicodeの定義されてる文字を参考にして作ったという感じがする。

120:Be名無しさん
02/09/02 11:15
WinはGB18030に対応してないと言い張る病気の人はまだいるの？(藁

121:Be名無しさん
02/09/02 11:16
>>115
printfってWinのAPIには無いぞ(藁
対応してないのは君の使ってるライブラリだよ(藁

122:Be名無しさん
02/09/02 11:22
>>120-121
しつこいうぃなはされ。

>>121
WinのAPIにはCRTというかたちで実装されてるぞ。
Win32 APIのなかにはないが。

123:Be名無しさん
02/09/02 11:29
>>122
TextOut使えばちゃんとGB18030で表示できるぞ。
対応してないのはお前だよ(藁

124:Be名無しさん
02/09/02 11:35
>>122
きみ、苦しすぎ（ｗ

125:Be名無しさん
02/09/02 11:36
printfで表示できないのはね、printf("...")ってやるからだよ。
printf("%s", "...")ってやらなくちゃね。

めっちゃ基本。

126:125
02/09/02 11:39
それと、勘違いがあるようなので言っておくが、printfを実装しているのは、
Winではなく、コンパイラのライブラリ。
それはライブラリの仕様であって、Winの仕様ではない。

127:Be名無しさん
02/09/02 11:49
>>123
TextOutはマクロ。
実際は、TextOutWとTextOutAしかない。
TextOutWで表示できて、TextOutAじゃ表示できない。
TextOutWってのは、Unicode(UTF-16)なわけです。
Unicodeは、GB18030を含んでるから、
GB18030とUnicodeに含まれる文字は、当然TextOutWでは表示できる。
でもそれはGB18030のEncodingを使って表示はできない。
で、TextOutAは、GetACP()に基づくキャラクタセットで表示される。
例えば、GetACP()が932だったら、Shift JISの文字列をTextOutAに渡すことができる。
で、GetACP()が、54936を返せば、GB18030の文字列をTextOutAに渡すことができるんだが、
これは不可能。なぜかっていうと中国語版ではGetACP()は54936を返さないから。
936つまりGBKを返す。GB18030の4バイト文字をTextOutAに渡すことはできない。

128:Be名無しさん
02/09/02 12:01
>>125
はあ？？できないっつーの。
ネイティブキャラクタセットがGBKなんだから。

>>126
> それと、勘違いがあるようなので言っておくが、printfを実装しているのは、
> Winではなく、コンパイラのライブラリ。

なんだよそれ。
printfは、Winのmsvcrt.dllに含まれてるよ。
もちろんprintfはstaticリンクもできるけどね。
それとほとんどのWin32 APIはdllへのコールだ。何が違うんだ？

129:Be名無しさん
02/09/02 12:03
>>125
ワラタ。

130:Be名無しさん
02/09/02 12:05
で、
Winのネイティブキャラクタセットは、
Windows2000以降はオプションでGB18030対応しますよ
と言い張る病気の人はまだいるの？(藁

131:Be名無しさん
02/09/02 12:11
つーか、Win2000以降で、GB18030みたいに、
Shift JISのネイティブサポートなかったら、激怒だよ。
よく中国は納得したと思う。

132:Be名無しさん
02/09/02 12:35
いやいや、まったく、誰でも知ってることと、大きな間違いを得意げに
並べてとんだ恥さらしですな(藁
WinでGB18030はサポートされてます。

133:Be名無しさん
02/09/02 12:38
>>132
>>127ですが、どこがまちがってるなら、指摘してくれ。

134:Be名無しさん
02/09/02 12:49
>>132
まあせいぜい、一生かけて、Win2000かXP上で、
printfでGB18030の4バイト文字表示するサンプルコードでもぜひ作ってくれ。
できたらここにソースをのっけてくれ。それまでもどってくんな (w

135:Be名無しさん
02/09/02 12:52
WinのシステムキャラクタセットはGB18030をサポートしません。

136:89だが
02/09/02 13:10
>>132の彼は、どこが大きな間違いだと思って思ってたんだ？
具体的に１つ１つ説明してもらいたい。
でも、やつのprintfとかの話は、ぽかーん。
やつはたぶん>>95だろうと思うんだが、
それならなんで>>89に対してからんでくるんだ？

137:89だが
02/09/02 13:20
まあ、>>132程度のあたりさわりないことなら、
BTRONでもGB18030はサポートしてますってことになる。
Winでも、euc jpとかiso-2022-jpとかもサポートしてると言える。
だが、それは、スレ違いだよな。
OSのネイティブキャラクタセットの話じゃないからね。

138:Be名無しさん
02/09/02 14:26
まだ言ってるのか(藁
メモ帳とWindowsの違いはわかったのか？

139:Be名無しさん
02/09/02 14:32
TextOutがマクロだってことなどが誰でも知ってることで、
メモ帳とprintfでサポートされることがネイティブサポートだという主張が大きな間違い。
その他、突っ込みどころは満載だが、基本的なところからいちいち小学生に説明するのは
時間がかかるので、適当な入門書でも読んでくれ。

WindowsがGB18030対応しているのは、明らかな事実。
それを対応してないと苦しい言い訳をしてるところが恥ずかしい。

140:Be名無しさん
02/09/02 14:39
>>139
じゃあ、TextOutにGB18030のEncodingの4バイト文字を
直接わたせるってのか？
そんなのはMSDNにも書いてないよ。(w

141:Be名無しさん
02/09/02 14:45
>>137
なんかややこしいことになってるが、

・システムレベルで変換ルーチンを持っている
・すべての文字を表示できる（こっちはオプション）

を満たせばGB 18030をサポートしていると言っていいんじゃねーの。
内部コードとして何を使おうが勝手だろ。
Windows XP/2000、Mac OS 10.2はこの条件を満たしているが、
超漢字4はどちらの条件も満たしていない。

142:Be名無しさん
02/09/02 14:52
>>139
> それを対応してないと苦しい言い訳をしてるところが恥ずかしい。

だいたい、その拡大解釈じゃあ、
TRONコードだってUnicodeや、GB18030対応してるよ。

ネイティブキャラクタセット(システムロケール）としては
GB18030は対応してないと言ってるだけだ。
コマンドプロンプトも対応してない。

MultiByteToWideCharと、WideCharToMultiByteはGB18030の
文字コードは入れられるが、(そりゃね。変換するからね)
それ以外のNative APIは,GB18030４バイトコードはだめ。
WM_GETTEXTは、GB18030４バイトコード入れられんし、
TextOut、SetWindowText、もろもろのWin32 APIに対しても、
GB18030の４バイトコードは直接入れられない。
Shift JISは直接入れられるけどね。

143:Be名無しさん
02/09/02 14:56
> だいたい、その拡大解釈じゃあ、
> TRONコードだってUnicodeや、GB18030対応してるよ。

してない。

144:Be名無しさん
02/09/02 14:56
>>141
> 超漢字4はどちらの条件も満たしていない。

そうなのか?
超漢字4はGB18030の文字が
TRONコードを使っても表示できないのか？
WinはUTF-16を使えばできるが。

145:Be名無しさん
02/09/02 14:59
>>144
おれもそれを聞きたい。
BBBがSurrogateをサポートしていないと言う話はでたが、
TRONコードを使ってもGB18030の文字を表示できないとは。。。
だめじゃん。超漢字。

146:141
02/09/02 15:09
144-145
表示できないはず。だが、「できない」ことを立証するのは難しいので
とりあえずTRON者の反論待ち。

147:Be名無しさん
02/09/02 15:11
>>141
> 内部コードとして何を使おうが勝手だろ。

だいたいもとの話はプラットフォームがサポートしてるって
話じゃなかったんだよ。
TRONコードと比べてるあたり、OSの内部コードの話じゃなかったのか？
Win2000はサポートしてるかどうかなんて出すから話がわけわかんなくなる。
そんなのWin2000/XP、OSX, AIX, Solaris, HP, Linux
最近のUnicode対応のOSならあたりまえ。
で、変換の話なら、ICUで一発だよ。

148:Be名無しさん
02/09/02 15:35
ところで>>139は>>125なのか？
>>125にはわらた。
GB18030がprintfで表示できないのは、

> printfで表示できないのはね、printf("...")ってやるからだよ。
> printf("%s", "...")ってやらなくちゃね。
> めっちゃ基本。

だって。ウケタ。。。

149:Be名無しさん
02/09/02 15:47
え？マジで知らないの？
printfを使う時は基本だよ！

150:Be名無しさん
02/09/02 15:59
msvcrt.dllって、VCのランタイムじゃん。
こういうのは、ライブラリの仕様って言うんじゃねーの？

151:Be名無しさん
02/09/02 16:13
まあまあ、そう気張らずにこんなものでもいかが？

URLﾘﾝｸ(adult.misty.ne.jp)
URLﾘﾝｸ(ninkirank.misty.ne.jp)
URLﾘﾝｸ(pakopako.misty.ne.jp)
URLﾘﾝｸ(www.all-mode.net)

152:Be名無しさん
02/09/02 17:24
つーか、Unicodeの統合漢字の2.0から入ってるやつさえ
表示できなかったりするし。＞超漢字4

153:Be名無しさん
02/09/03 05:43
>>150
いや、printfだけじゃなく、すべてのWin32 API
GB18030でエンコードされた文字データを扱うことはできんのよ。
（ただしMultiByteToWideChar(),WideCharToMultiByte()のUnicode変換を除いて）
だからWin APIのライブラリの仕様と言って良いと思うぞ。
MSが言っているWinのGB18030対応は、
実質、MultiByteToWideChar(),WideCharToMultiByte()しかやってない。
Shift JISサポートとは大違い。ShiftJISはWin32 APIで直接扱える。

それに比べて、GB18030をサポートしたUnixなんかは、
localeにzh_CN.GB18030ってセットすれば、APIにGB18030で
Encodeされた文字データを直接渡すことができる。

154:Be名無しさん
02/09/03 07:59
>>150
> msvcrt.dllって、VCのランタイムじゃん。

ワラタ。
printfは、msvcrt.dllにあるAPIで、
TextOutA/Wは、gdi32.dllにあるAPIだが、なにか？

次ページ