2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

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

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
http://news.2ch.net/newsplus/kako/1023/10232/1023201516.html

の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
http://cocoa.2ch.net/linux/kako/1003/10031/1003159137.html
の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

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

〇デリバリーヘルス〇デートクラブ〇女性専用ホストクラブ〇
〇ハードSM奴隷クラブ〇レズビアン倶楽部〇ホモ・オカマ倶楽部
〇変態痴女と遊ぶ会〇痴漢・覗き趣味の会〇変態同好会・各種!
●楽しく遊べます! 090-8002-8356番
-----------美男・美女会員など多数在籍中-----------
  http://www.mttdocomo.jp/
-----女性アルバイト随時募集・高収入(日払い)月100万円可能-----
-----レズビアン・スタッフ●ホモスタッフ●女性専用ホストスタッフ同募-----
http://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
ん?
http://developer.apple.com/technotes/tn/tn2029.html
には、

 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)があるけど、
http://developer.apple.com/techpubs/macosx/Carbon/text/ATSUI/atsui.html
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のページを見てきたけど、違うみたい。

端から端まで読んだか?これは見たか?
http://developer.apple.com/techpubs/macosx/Carbon/text/ATSUI/Apple_Type_S_code_Imaging/index.html

> (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を見るように。
http://www.unicode.org/charts/
にすべての文字がある。で、
http://www.unicode.org/charts/PDF/U2F800.pdf
を見れば、その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
スマソ。
http://developer.apple.com/techpubs/macosx/Carbon/text/ATSUI/Apple_Type_S_code_Imaging/Functions/Mapping_Font_Fallbacks.html#//apple_ref/C/func/ATSUGetFontFallbacks
だった。ここは見た?
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と呼ぶ。
http://www.unicode.org/charts/PDF/UFE00.pdf

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

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

53 :コギャルとHな出会い:02/08/15 14:13
http://kado7.ug.to/net/


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

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

  激安携帯情報あります。

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

ヒョデーイ!!!
http://2style.net/maido/R3_temp.swf?inputStr=%83q%83%87%83f%81%5B%83C%81I%81I%81I%81I

#音量ONにして飛んでね(・∀・)イイ!

参考スレッド 森恒二ホーリーランド拳闘暗黒伝セスタス技来静也4
http://comic.2ch.net/test/read.cgi/comic/1025843878/551-611



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

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

ついでに。>>52
↓こういう現象があったりしますな。実際
ttp://www.microsoft.com/japan/support/kb/articles/J041/1/42.HTM

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
http://www.unicode.org/unicode/reports/tr28/#13_7_variation_selectors

> 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.

http://www.unicode.org/Public/UNIDATA/StandardizedVariants.html

> 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
がしゅつかもしれんが
0213には0212とダブっている文字もあればそうでない文字もある。
0213にはUnicodeに入ってない文字もある。

BTRONっていつになったらスクリプト層が実装されるんだ?

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
てめぇらみたいなガキはどせヒマだろ?だったらこっちゃ来い (

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

『一炊の夢』

http://www.geocities.co.jp/Hollywood-Screen/9038/


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
お前は放置されている事にいいかげんに気づけ(w

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

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

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

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

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
http://www.leverage.jp/bloom/qry/search.qry?function=search

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

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

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

ここをクリック!!!
↓↓

http://www.bea.hi-ho.ne.jp/paisen/

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文字あたり2バイトしか対応してないから。
これって、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

http://www.leverage.jp/bloom/qry/search.qry?function=Search

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
きみ、苦しすぎ(w

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の彼は、どこが大きな間違いだと思って思ってたんだ?
具体的に1つ1つ説明してもらいたい。
でも、やつの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は,GB180304バイトコードはだめ。
WM_GETTEXTは、GB180304バイトコード入れられんし、
TextOut、SetWindowText、もろもろのWin32 APIに対しても、
GB18030の4バイトコードは直接入れられない。
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
まあまあ、そう気張らずにこんなものでもいかが?

http://adult.misty.ne.jp/rank/enter.cgi?id=jouhouya
http://ninkirank.misty.ne.jp/06/enter.cgi?id=jouhouya
http://pakopako.misty.ne.jp/enter.cgi?id=jouhouya
http://www.all-mode.net/jrank/in.php?id=jouhouya

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だが、なにか?

155 :Be名無しさん:02/09/03 08:43
>>141
つーか、スレ見た限り、
だれもWinはGB18030サポートしてないって、誰が言ってる?何番のやつが言ったんだ?
話してるのは、WinのGB18030サポートは、Shift JISサポートに比べると
ださださ、おそまつだねーってことだと思うんだが。

GB18030のネイティブキャラクタセットのサポートはされてないし、
(つまりGB18030を直接Win32 APIにわたせない)
GB18030のコマンドプロンプトのサポートなし、
GB18030、Unicode間の変換のサポートのみという
おそまつになってしまったのは事実。
(これらは、GBK,ShiftJIS,Big5,Latin1なんかはあたりまえなのに)

そのために、今までに作られたネイティブアプリは
GB18030のためにみんなUnicodeアプリに変更しなくちゃって、
苦労してるアプリベンダって結構多いと思うぞ。
Winが、GB18030ネイティブキャラクタセット対応していれば、
GBKのアプリはそのまま、GB18030で動いたはずだからね。
で、コードの変更なしにWin9xもサポート可能だったのに。

156 :Be名無しさん:02/09/03 08:59
>>141
> ・システムレベルで変換ルーチンを持っている
> ・すべての文字を表示できる(こっちはオプション)
>
> を満たせばGB 18030をサポートしていると言っていいんじゃねーの。
> 内部コードとして何を使おうが勝手だろ。

その通り。それを満たせばサポートしていると言える。

157 :Be名無しさん:02/09/03 09:02
>>155
> 話してるのは、WinのGB18030サポートは、Shift JISサポートに比べると
> ださださ、おそまつだねーってことだと思うんだが。

ちがいますね。「サポートしている」という意見に
対して執拗に否定してかかる奴がいますからね。

> GB18030のネイティブキャラクタセットのサポートはされてないし、

「ネイティブキャラクタセットとしての」サポート云々は
話のスリカエですよね。

158 :Be名無しさん:02/09/03 09:13
或いはネイティブキャラクタセットとしてのサポートに
拘るのも面白いかも。

例えば…

『BTRONはShift_JISもUnicodeもサポートしていません。
 いずれも、その文字セットど同内容をTRONコードの
 各面内に含んでいるだけに過ぎず、ネイティブサポートは
 あくまでTRONコードだけだから』

とか。

159 :Be名無しさん:02/09/03 10:26
msvcrt.dllはVCのランタイムです(藁
http://www.vector.co.jp/soft/win95/util/se040499.html

160 :Be名無しさん:02/09/03 10:30
>>153
だから、ちゃんと変換APIが用意されてるところが、OSとしてのサポートなのよ。
エンコーディングなんか星の数ほどあるんだから、その数だけTextOutを用意するのは
たわけてる。
サポートの方法としては、
1. TextOutにエンコーディングを指示するオプションを付ける
2. TextOut呼び出しの前にUNICODEに変換できるようAPIを用意する
があるわけだが、Windowsはその2番目の方法を取った。
それのどこがサポートでないって言い張れるんだ?
バカなの?

161 :Be名無しさん:02/09/03 10:34
勘違いがあるようなので言っておくが、printfを実装しているのは、
Winではなく、コンパイラのライブラリ。
それはライブラリの仕様であって、Winの仕様ではない。

msvcrt.dllは、その名の通り、MicroSoft Visual C Run Time.dllなわけ。
つまり、動的リンクできるVCのライブラリ。

162 :Be名無しさん:02/09/03 10:41
それと、ネイティブって言葉を何か勘違いしているようだが、
君の言ってる「ネイティブ」は、一般に「デフォルト」って言葉で表されてる
概念だと思うぞ。

Winは、GB18030をちゃんとサポートしている。
つまり、OSレベルでのサポートであるから、これを一般にネイティブサポートと言う。

そのうち、UIなどでデフォルトとして扱われるエンコーディングがもちろんあるわけだ。
これのことをネイティブって言ってるんじゃねーの?
これはあくまでデフォルトなわけだから、ちゃんとまじめに作られたアプリなら
デフォルトじゃない設定も使えるわけ。

なぜ君の作ったアプリで使えないのかというと、それは「君のアプリが」GB18030に対応してないってだけだよ。
Winじゃなくてね。
「ロケール」とか「国際化対応」って章をもっと良く読んでみることだね。

163 :Be名無しさん:02/09/03 10:44
それから、printfにリテラル文字列を渡す場合、%sを使うのは常識。
でないと、日本語でも、2バイト目に\や%が使われてる文字が不具合を起こす。

これは、printfの仕様、そしてライブラリの仕様であって、それによる
不具合はプログラマの責任。決してOSの責任じゃない。

164 :Be名無しさん:02/09/03 11:22
>>157
> ちがいますね。「サポートしている」という意見に
> 対して執拗に否定してかかる奴がいますからね。
> > GB18030のネイティブキャラクタセットのサポートはされてないし、
> 「ネイティブキャラクタセットとしての」サポート云々は
> 話のスリカエですよね。

つーか逆のような気がするが。
>>89の返答として、>>95になったのが変、
ネイティブキャラクタセット -> Win2000はサポートしてる。
にすりかえられたのが最初。ちゃんとスレを読むように。

165 :Be名無しさん:02/09/03 11:24
>>161
用は、
msvcrt.dllはWindowsの一部ではなく、
gdi32.dllはWindowsの一部だと言ってるのか?(わら

166 :Be名無しさん:02/09/03 11:26
>>160
あんたもばかだ。
> 1. TextOutにエンコーディングを指示するオプションを付ける
> 2. TextOut呼び出しの前にUNICODEに変換できるようAPIを用意する
> があるわけだが、Windowsはその2番目の方法を取った。

ShiftJISはどちらにもあてはまらんぞ。(w

167 :Be名無しさん:02/09/03 11:30
>>158

>『BTRONはShift_JISもUnicodeもサポートしていません。
>いずれも、その文字セットど同内容をTRONコードの
>各面内に含んでいるだけに過ぎず、ネイティブサポートは
>あくまでTRONコードだけだから』

それを言うならSJISじゃなくてJIS X 0208だろ。
それから超漢字4は、
Unicodeについては「文字セット」としてもサポートしてないぞ。
超漢字2なら(文字鏡が入っていれば)
Unicode 2.0まではカバーしてたんだけどね。

168 :Be名無しさん:02/09/03 11:30
>>158
> 或いはネイティブキャラクタセットとしてのサポートに
> 拘るのも面白いかも。

あのー、その話をしてたら、
Win2000は、GB18030サポートしてるぞって、わけわからん話が
とんできたんですが。。。

あんたの意味での、
BTRONはGB18030サポートすればって話してたら、
ISCIIサポートすれば、ISO-2022-JPサポートすれば、
でCharset一通り言って、このスレおしまいになっちゃうよ。(W

169 :Be名無しさん:02/09/03 11:34
>>164
なぜ君は>>89が発端だと言い張るのだ?
最初の>>87に対する君の>>89がズレてるのだと思うが。

170 :Be名無しさん:02/09/03 11:40
>>162
つーか、Unicodeアプリで作ればって話は既出。ちゃんとスレよめ。
Nativeってのは、A Functionで実装したら
GB18030は対応できないと言ってるんだよ。
(ShiftJISやBig5やGBKは、A Functionで実装できるが)
ようは、GB18030他のに比べておそまつだって話。
それをWinはGB18030サポートしてるだとさ。
はいはい。それは既知。

171 :Be名無しさん:02/09/03 11:48
>>169
いいんじゃないの?それはそれで間違ってないんだから。
むしろ、そのあとで、それを勘違いして、
WinはGB18030をサポートしているとの主張がいたいと思うんだが。

172 :Be名無しさん:02/09/03 11:49
おっと、
>>171はWinはGB18030のサポートをしていないと
言ってるんではないからね。


173 :Be名無しさん:02/09/03 12:04
>>166
一つのデフォルト言語に対して特別な処置をとれば処理が単純になるという、それだけの話。
ショートカットのような物。

174 :Be名無しさん:02/09/03 12:06
まだネイティブでサポートしてないと騒いでる奴がいるのか(藁
恥の上塗り(藁

175 :Be名無しさん:02/09/03 12:07
>>170
あのさ、ShiftJISとかBig5とかGBKとかってのはさ、
地域化の時代のベタなサポートなわけよ。
それを国際化時代のサポートと比べて、
しかも地域化の観点から優劣を問うのもどうかと思うが。

176 :Be名無しさん:02/09/03 12:07
>>167
まじでさ、超漢字にICUをポーティングするってのはどう?
そうすりゃあっというまに、
超漢字もXXXサポートしてますって言えると思うんだが。

177 :Be名無しさん:02/09/03 12:11
>>175
べたなサポート大事だと思うぞ。
Win,Mac以外はそれに対応してるんだからね。
今までGBKで動いてたアプリを書き換えなくちゃならなくなるとすれば、
そりゃベンダにとっては大変でしょう。
MSは4バイト文字がもう機構上実現できなくなったってのが本音かも。

178 :Be名無しさん:02/09/03 12:15
>>174
> まだネイティブでサポートしてないと騒いでる奴がいるのか(藁

話ぼかすのうまいね。
ネイティブで何をサポートしてないと騒いでるというのだ?

179 :Be名無しさん:02/09/03 12:18
>>174の(藁は、やつか?
WinがGB18030サポートしてるってずっと
スレ違いなこと言ってるのは。

180 :Be名無しさん:02/09/03 12:20
>>173
わら

181 :Be名無しさん:02/09/03 12:49
ところで、utf2000ってどうなった?

182 :Be名無しさん:02/09/03 12:56
>>181
最新版は0.19かな。
あれはなんつーか、別世界の話だわな。

183 :Be名無しさん:02/09/03 12:57
UTF2000か、TRONコードと比べてどうよ?
emacsの実装してるとか聞いたが。

184 :Be名無しさん:02/09/03 14:43
>>178
話ぼかすの下手だね。
Winとメモ帳の区別はつくようになったか?
開発言語のライブラリのAPIとWinAPIの区別はどうだ?

185 :Be名無しさん:02/09/03 16:51
WindowsはGB18030に対応してないと言い張る

ボロボロに論破される

そんなこと言ってないと言い張る

ぷぷぷ

186 :Be名無しさん:02/09/03 19:43
>>164
> つーか逆のような気がするが。
> >>89の返答として、>>95になったのが変、

なんで話の途中を起点であるかの様に摩り替えるの?

89は87に対する返答でしょ。

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

どこにネイティブサポートだって書いてあるのさ?

187 :Be名無しさん:02/09/03 21:23
>>186
>>89がWinはGB18030をサポートしていないとは書いてないんじゃないの?
そのサポートはださいっていう話なんだよ。
だから、>>95はUnicode変換テーブルをインストールするかのオプションだろ?
つーか、そのあとの話で、WinはGB18030サポートは実質変換だけって
話が出てると思うんだが。

188 :Be名無しさん:02/09/03 21:29
>>186
つーか、孟宗君は、TextOutのAバージョンででGB18030の
4バイト文字表示するソースコードと実行の仕方見せてみ?
そうしたらあんたの言ってること信じてやるよ。
まあ、できない孟宗君は、さっさと帰ってね。

189 :Be名無しさん:02/09/03 21:35
なんというか、超漢字は、ふざけてるよなあ。
トンパ文字パックが3万近くしているのは、驚いた。

190 :Be名無しさん:02/09/03 21:35
WindowsはGB18030ネイティブでWin32 APIを呼べると言い張る

自分の意見がぽろぽろ変わっていく。

最後の牙城は、WinはGB18030サポートしてないと言ったろと主張するだけ

ボロボロに論破される。

Win32 APIでもできるよというが、ソースコードも提示できない。

ぷぷぷ

191 :Be名無しさん:02/09/03 21:41
>>185-186
まだ、WinはGB18030サポートしたのしないの話したいのか?おめーは?
つーか、なにをそんなにWinをかばってんだ?うぃん厨君。
WinのGB18030サポートのダサさに話題を移しまいと必死ですな。

192 :Be名無しさん:02/09/03 21:57
なんでこの程度で論破とか平気で書けちゃうんだろ。
これのほうがぷぷぷだと思うなあ。
まあ俺は野次馬なわけだが。


193 :Be名無しさん:02/09/03 22:02
>>191
まあ、うぃんちゅーはそんなもんだろ。藁

194 :Be名無しさん:02/09/03 22:09
>>192
まあさ、今のところは、
ソースが出たら話が面白くなるんでねーの。
TextOutAではどうやってもGB18030の4バイトコードは出せないと思うんだが。

195 :Be名無しさん:02/09/03 23:00
>>186=>>187は、
>>100,>>106あたりを読んだのだろうか?
WinはGB18030サポートしてないと読み違えてるあたりがイタイ。
さらに、それを>>200近くまで、ひっぱってくるあたりがイタイ。


196 :Be名無しさん:02/09/03 23:38
>>192
> まあ俺は野次馬なわけだが。

あんた張本人のうぃなちゅうだろ。


197 :Be名無しさん:02/09/04 09:05
>>195

バカですか?

誰一人として、『Windowsの内部コードはGB18030だ』
なんて書いていないのですが。

争点は、内部コードであるUnicodeとの変換テーブル内蔵
するのが『サポートといえるか』でしょう。

『内部コードとして採用していないからサポートと言えない』
という論点でカキコしている奴がバカなんですよ。

え、そんなこといっていない。ダサいかどうかを論じている
ですって?

それじゃ、そもそもなんで>>87にくってかかってきた
んですか?

198 :Be名無しさん:02/09/04 11:43
なんだ、まだ頑張ってるのか(藁

199 :Be名無しさん:02/09/04 13:45
>>197
Win2000/XPはGB18030をサポートしていると言える。
なぜかっていうと、MicrosoftがMicrosoft.comで
サポートしてるって言ってるから。
はい。おしまい。さ、もーそー君は帰っていいよ。

あ、そのまえにprintfとTextOutAでGB18030の文字表示する
ソース出してってね。ちゃんと動作方法も書いといてね。

だれも>>87にくってかかってないから、
心配だったら、今日は帰って薬飲んで早めに寝た方ががいいよ。
WinのGB18030サポートはださいのはしょうがない。事実は事実なんだから。

200 :Be名無しさん:02/09/04 13:49
>>197
そうそう、Windowsの内部コードの話なんてだれもしてないから。
WinのAPIが受け付けるコードの話をしてるだけ。まあ、帰れって。

201 :Be名無しさん:02/09/04 18:47
printfはライブラリ依存だって書いたんだが、理解できなかったか?
用語がむずかちちゅぎまちたかね〜(藁

202 :Be名無しさん:02/09/04 18:48
それと、TextOutの前にUNICODEに変換する方法でサポートしてるとも
書いたんだが、幼い子にはちょっと無理だったかな(藁

203 :Be名無しさん:02/09/04 18:49
それと、まだmsvcrt.dllがVCのライブラリじゃないって思ってるの?(藁

204 :Be名無しさん:02/09/04 19:04
おまいらいい加減おちけつ

205 :Be名無しさん:02/09/04 21:03
 Windows2000はGB18030をサポートしている

という意見に噛み付いたあげく、論破されるや

 俺は最初から対応していると主張しているんだが?

といった態度に豹変して逃げをうってるバカが常駐
しているスレはここですか?

206 :Be名無しさん:02/09/04 21:51
>>201
> printfはライブラリ依存だって書いたんだが、理解できなかったか?

"%s"でやりゃできるって言ったじゃんかよ。



207 :Be名無しさん:02/09/04 21:54
>>202
それは、君の言う前にスレに出てる。
人の言ったことをそのまま繰り返してるおーむがえしくん。
「ぴーちゃん、おはよ。」「ぴーちゃん、おはよ。」みたいな。

208 :Be名無しさん:02/09/04 21:59
>>203
> それと、まだmsvcrt.dllがVCのライブラリじゃないって思ってるの?(藁

VCのライブラリかどうかなんでだれも話してないぞ。
Windowsのdllかどうかを話してる。

209 :Be名無しさん:02/09/04 22:02
>>205
> Windows2000はGB18030をサポートしている
> という意見に噛み付いたあげく、論破されるや

ひがいもうそう君なんだよな。

WinはGB18030サポートされてます。
-> でも、Shift_JISの他のキャラクタセットに比べてかなりの制限があるよ。

って話しってのが、これだけでてるのに、まだ見えない。
君を攻撃してるわけじゃないから、そんなにおびえるこたない。安心しな。

210 :Be名無しさん:02/09/04 22:03
あ、>>209は、
WinはGB18030サポートされてます。
-> でも、Shift_JISのような他のキャラクタセットに比べてかなりの制限があるよ。
ってことね。

211 :Be名無しさん:02/09/04 22:07
>>202
つーか、言われて、気が付いて、収拾つかなくなって、
WinはGB18030サポートしてないって言ってるやつがいると思ってる。。。
最初からいないのにね。

へんなものやっちゃったんじゃないか?
俺をねらってるやつがいる、俺をねらってるやつがいるって。

212 :Be名無しさん:02/09/04 22:20
>>209
そうそう。
流れとして、MultiByteToWideCharなんかの話がでてるんだが。
やつにはMultiByteToWideCharとかの話が理解不能だったらしい。
MultiByteToWideChar/WideCharToMultiByteがサポートしてるんだから、
WinはGB18030をサポートしてるって話をしてるのあたりまえだ。

まあ、もーそーくんだからしょうがないといえばそうなんだが。

213 :Be名無しさん:02/09/04 22:28
>>212

まだ勘違い君がいたのか。

その話はとっくに出ていて、問題は「それが
『サポートしているじゃん』という意見に対して
なんで噛み付く理由になるの?」ということ
なんだが。

214 :Be名無しさん:02/09/04 22:32
んー、なんか単純に

  87に対して勘違いツッコミしてきた89と、その89に加勢した奴=バカ

  89とそれに加勢した奴をバカと言える奴=まとも

てことで結論でてると思うんだが。

215 :Be名無しさん:02/09/04 22:41
>>205
安心しなよ。WinはGB18030をサポートしてる。
それに君のことをだれもかみついていないよ。だからお帰り。
WinのGB18030サポートがださかったのがいけない。
家にもどって、printfとTextOutAでGB18030を表示するプログラムでも
作ってたほうが良いと思うよ。

216 :bloom:02/09/04 22:42

http://www.leverage.jp/bloom/start/

217 :Be名無しさん:02/09/04 22:49
>>214
まあさ、>>87>>89を読み違えて被害妄想をここまでひっぱってきてるってのが
正しいところだろうな。

>>89
「UTF-16で、GB18030の文字は扱えると言っているだけ。」
ってのがなんで
「WinはGB18030サポートしてない」に変わるのかよくわからんと
思ったぞ。

218 :Be名無しさん:02/09/04 23:17
>>217
まあ、噛み付かれてると勘違いのもーそー君のことなんだから、
何言ってもしょうがないさ。

しかし、やつは、最後まで、
WinのGB18030サポートはださいと言えないのは、またまたイタイ。

219 :Be名無しさん:02/09/04 23:24
>>213
なんで俺をいじめるんだよー。ってか?(わら

220 :Be名無しさん:02/09/04 23:31
>>87を罵倒したやつはいない。だれも噛み付いてない。
だれもWinはGB18030サポートしてないとは言ってない。
大丈夫、大丈夫。なんか>>213は疲れてるんだよ。さあ、お帰り。

221 :Be名無しさん:02/09/04 23:56
いやあ、会社にもこういうやついたよ。
「私が間違ってるっていうんですか!じゃあ何で私に噛み付いてくるんですか!」
って言い出すやつ。
課長が、なだめてるんだけど、会議でそいつずっと怒って、
そのあとの話だいなし、場はしらけるみたいな。

222 :Be名無しさん:02/09/05 00:01
>>221
そうそう!そういうの困るんだよね。
別にだれもそうじゃないって言ってないのに、そいつは怒りだして、
なんで俺がなだめなくちゃならないの?ってな雰囲気。

223 :Be名無しさん:02/09/05 10:21
「対応可能」という言葉が「サポートしている」という言葉に変わって、
そのサポートがださいのしょぼいのいう話に変わっているわけですね。

まるで伝言ゲームだなぁ。文字という手段を使っているのに情けない。

224 :Be名無しさん:02/09/05 10:24
>>206
できるとかできないって誰が書いたんだよ?
ライブラリ依存って書いてあるじゃんよ(藁
ライブラリ依存ってのはね、
「できる場合もあるしできない場合もある」って意味だぞ(藁
そこまで基本からわかんないと、時間かかるねぇ(藁

225 :Be名無しさん:02/09/05 10:27
ウィンはGB18030に対応してます。
そう言ってるだけなのに、「対応してない」と言ってない奴が何でかみつくの?(藁
対応してないと言ってしまったから、自分が責められてるように思うんだろ?(藁
言い訳苦しすぎ。
対応してることが理解できたなら、それでいいじゃん。

226 :Be名無しさん:02/09/05 10:28
ほら、「その程度でサポートしてると言えるなら他のどのOSでもサポートしてる」
とか何とか言った奴がいただろ?(藁
それがお前じゃないなら黙ってろよ。
ムキになるからお前だってバレバレなんだけどね(藁

227 :Be名無しさん:02/09/05 11:47
>>223
>「対応可能」という言葉が「サポートしている」という言葉に変わって、

そう。具体的な例として、Win(Win2000/XPね)をあげたわけ。
だから別に君に噛み付いてないってことが、やっとわかったか?
被害もーそー君。
「サポートしている」というのは、MSが言っているから。

228 :Be名無しさん:02/09/05 11:47
>>142
>だいたい、その拡大解釈じゃあ、
>TRONコードだってUnicodeや、GB18030対応してるよ。
えー?してないよぉ!

229 :Be名無しさん:02/09/05 11:48
というわけで、とっととお帰り。頭ひやしたほうがいいぞー。

230 :Be名無しさん:02/09/05 11:49
>>227
ほらほら、意味わかんなくなってきたぞ(藁
拡大解釈ならサポートしてると言ってた君。
君の定義じゃサポートしてないんだよね?(藁
それが今度はサポートしてる派に変わったの?(藁

もし君が>>142じゃないなら、噛みつかれてるのは君じゃないから、
引っ込んでなさいな、被害妄想君(藁

231 :Be名無しさん:02/09/05 11:50
ついでに言うが、頭冷えてないのは君だけだぞ。
何で自分が噛みつかれてる気がしたの?(藁

232 :Be名無しさん:02/09/05 11:58
>>230
なんで意味わかんなくなってきたんだ?拡大解釈だってさ。ぷぷぷ。
MSがサポートしていると言ったらしてるわけよ。あんたが拡大解釈してんだよ。
GB18030はライブラリ依存ですだって。
printfはに含まれてるから表示できないだって。ぷぷぷ。
gdi32.dllはライブラリじゃないのか?

>>142以前にいろいろ変なこと言っといて、なんか>>142だけのネタを
昨日一生懸命考えてたんだね。ぷぷ。

233 :Be名無しさん:02/09/05 12:00
>>230
やっと、WinのGB18030対応はださいと、悟ったとたんに、
あとは、とことんテクニカルとは程遠い会話するようになったな。。。

234 :Be名無しさん:02/09/05 12:05
ちなみに
printfが「ライブラリ依存だから、」(この表現わけわからん)
GB18030表示「できる場合もあるしできない場合もある」は
まったくでたらめ。
GB18030がコマンドプロンプト上で表示できないのは、
MSがMSのサイトでそう言ってるから。

235 :Be名無しさん:02/09/05 12:06
つーことで、
printfでGB18030表示
できる場合をあげてもらおうや。

236 :Be名無しさん:02/09/05 12:10
>>95
> Windows2000以降はオプションでGB18030対応
> しますよ。

これって、>>230だろ。
ちなみにWin2000はGB18030のオプションはありません。

Win2000はオプションで対応してない。

237 :Be名無しさん:02/09/05 12:11
>>236
つーか、オプションないよ。APIで対応してる。

238 :Be名無しさん:02/09/05 12:12
だよな。
Win2000のコンパネの地域ところの設定は、
GB18030なんて何もない。

239 :Be名無しさん:02/09/05 12:18
>>235
> つーことで、
> printfでGB18030表示
> できる場合をあげてもらおうや。

特に、4バイトキャラクタ表示できる場合の例をあげてくれ。
よろしく。

240 :Be名無しさん:02/09/05 12:21
>>230
> もし君が>>142じゃないなら、噛みつかれてるのは君じゃないから、
> 引っ込んでなさいな、被害妄想君(藁

ちみは、その前からエンジン全開で噛み付いてるじゃん。w

241 :Be名無しさん:02/09/05 14:42
煽り合いには参加したくないんだけどさ、SJISやGBKってのは、
当時、内部コードとしてサポートするしかなかったわけだよな。
しかし、GB 18030は変換テーブルでサポートできる。
国際化された環境で、いまさら地域化なんてしたくないのは当然。
たとえばJIS X 0213はSJISを拡張する符号化を提案したが
受け入れられず、Unicode経由でサポートされることになった。
GB 18030(拡張GBK)のサポートはそれと同様の事例であって、
サポートが貧弱だとかってことじゃないだろ。

UNIX系のシステムがGB 18030を内部コードとして
サポートしているのは、もともとISO 2022的な発想が強く
Unicodeすら「文字セットのひとつ」ととらえる文化だからだと思うが、
WindowsやMacintoshはそうじゃなく、Unicodeによる国際化が基本。
いや、その方針に異議があるならそういう議論をしてもらっても
いいんだけどね、サポートが「ださい」とか連呼するばかりなのも
いかがなものかと。

242 :Be名無しさん:02/09/05 15:18
まだ続いてるのか(藁
サポートしてるわけねーだろ(藁

243 :Be名無しさん:02/09/05 15:34
文字列をUNICODEに直して表示するprintfだったら表示されるだろ?
こういうのをライブラリ依存って言うんだよ。
勉強になったね(藁
わけわからんのは君の勉強不足。
ライブラリ依存って言葉くらい、常識だから知っといてね。

244 :Be名無しさん:02/09/05 15:35
>>242
まだ言ってるのか(藁
サポートしてないわけねーだろ(藁

245 :Be名無しさん:02/09/05 15:49
>>239
UNICODEに直してからって繰り返し言ってんじゃん。
文盲?

246 :Be名無しさん:02/09/05 21:46
>>241
それはアプリ側の都合というより、WinやMacの都合なんだろうな。
だから、Win9xをサポートしてきたアプリベンダは、
まず、Unicode化しなくちゃならないという、けっこう大変なことがまってる。
ただし、LinuxやAIXやSolarisなんかは、GB18030でAPIを呼べるわけで、
それからみればそういう不満がでるのは当然だと思うぞ。

247 :Be名無しさん:02/09/05 21:47
>>243
> 文字列をUNICODEに直して表示するprintfだったら表示されるだろ?

だめなんだよね。
そもそもコマンドプロンプトがGB18030をサポートしてないから。

248 :Be名無しさん:02/09/05 22:06
>>243
ソースコードで、よろしく。

249 :Be名無しさん:02/09/05 22:12
というか、それ以前にフォントがあるのか?

250 :Be名無しさん:02/09/05 22:29
>>249
宗体(SinSum)-18030ってのがGB18030対応。
Surrogate文字は入ってないけどね。
Surrogate文字が入ってるのは、OfficeXP中文版についてる。

251 :Be名無しさん:02/09/05 22:33
とりあえず、それを使って、
printfでできたっていうのなら、ソースをくれ。

252 :Be名無しさん:02/09/05 23:20
>>241
GB18030のケースの場合は、JIS X 0213とかのケースとかなり違うと思う。
GB18030をサポートしていないソフトウェアは中国では売っちゃいけないことになった、
つまり、売った場合違法になる。
で、どこまでなら、GB18030サポートと呼べるのかということだけど、
GB18030表示、入力をはじめ、ユーザがファイルでGB18030を出力することが
できるというところまでが中国の要求。
中国としては、これから、GB18030をGBKのようにレガシーEncodingとして使っていきたいんだが、
Winの場合、

使いにくいGB18030テキストファイル変換アプリをつけた。
コマンドプロンプトでGB18030表示はできない。
システムロケールのCharsetとしてはGB18030はサポートしない。
NativeAPI(A Function)ではGB18030はサポートされない。

と、中を開けてみれば、いろいろな制限があって、かつてのGBKのようには使えなくなってしまった。
やっぱり、アプリベンダや、ユーザは、WinのGB18030に不満があるのはわかる。

253 :Be名無しさん:02/09/05 23:21
>>252
> ユーザがファイルでGB18030を出力することが

入力もね。

254 :Be名無しさん:02/09/05 23:41
>>241
Unicodeの中で、GB18030を扱おうと言った場合、
一番の問題は、変換でのラウンドトリップの問題だよね。
GB18030間でUnicode変換してまたもう一回変換してたりしているうちに、
違うコードポイントになっちゃう。
で、あとでうっかりバイナリ比較した場合、違うなんてことになる。
これは根が深いと思うんだが。

255 :Be名無しさん:02/09/06 01:40
変換の変換でバイナリ比較。。。
やる奴いる?


256 :Be名無しさん:02/09/06 08:05
>>226
> ほら、「その程度でサポートしてると言えるなら他のどのOSでもサポートしてる」
> とか何とか言った奴がいただろ?(藁

いたよねぇ。(w

しかし、その程度でサポートしていると言えても
超漢字はサポートしているといえない罠。

257 :Be名無しさん:02/09/06 08:14
>>252

>中国としては、これから、GB18030をGBKのようにレガシーEncodingとして使っていきたいんだが、

>と、中を開けてみれば、いろいろな制限があって、かつてのGBKのようには使えなくなってしまった。

中国がGB18030をGBKと同じ様なアプローチで
サポートして欲しい…というのは事実?それとも
キミの脳内ストーリー?

W2KのGB18030を中国サイドが承認したという事実は
無視?

258 :Be名無しさん:02/09/06 09:35
>>255
バイナリ比較ってのはUnicodeコレーションアルゴリズムじゃなくて、
単にstrcmpとか使ってる場合ってこと。

259 :Be名無しさん:02/09/06 09:36
>>251
いい加減、「ライブラリ依存」って言葉くらい調べろよ。
頭悪いにもほどがある。

260 :Be名無しさん:02/09/06 09:40
>>256
> 超漢字はサポートしているといえない罠。

そういえば、超漢字だか、BTRONだかの
中国向けパッケージって昔でなかったけ?
あれもGB18030対応できなかったのかな。。。


261 :Be名無しさん:02/09/06 09:48
>>259
「できる場合もあるしできない場合もある」
と言うから、わけわからなくなるんだよ。
だから、できる場合を見せてみろってことなんでないの?

ところで、MSが「ライブラリ依存」と言ってるのか?

262 :Be名無しさん:02/09/06 09:51
MSが言わなくてもライブラリ依存じゃねーか。
ライブラリの意味わかってるか?
そっから説明すんの?
面倒くせー

263 :Be名無しさん:02/09/06 09:53
たとえば、VCじゃなくて、gcのライブラリを使えば、GB18030がそのまま
printfで表示できるだろ?
ライブラリによってできたりできなかったりするからライブラリ依存。
ライブラリの意味くらいは自分で調べてくれるよねぇ?
それとも調べる知能すら無いの?

264 :Be名無しさん:02/09/06 10:05
>>262
cygwinだとできんの?

265 :Be名無しさん:02/09/06 10:06
gcって何?

266 :Be名無しさん:02/09/06 10:22
ゲームキューブ

267 :Be名無しさん:02/09/06 10:27
で、最初に話してた、VCだと"%s"で、GB18030表示
できるのか?

268 :Be名無しさん:02/09/06 10:30
GB18030からUNICODEに変換して、コンソールのコードページをUNICODEに変更し、
printfを使えばいいだろうが。
変換してから使うのがWinの流儀だって、いったい何度言わせる気だ?

269 :Be名無しさん:02/09/06 10:30
で、Windowsのmsvcrt.dllだとどうなんだ?

270 :Be名無しさん:02/09/06 10:31
msvcrt.dllはVCのライブラリだって何度言わせる気だ?

271 :Be名無しさん:02/09/06 10:32
バカは100回聞いてもわかりません。

272 :Be名無しさん:02/09/06 10:35
ソニーが自社のパソコンに自社ソフトを山ほど組み込んで売るように、
MSは自社のOSにVCのライブラリを組み込んで売る。
これは単にVCのライブラリをOEM添付しているだけであって、
msvcrt.dllはWindowsのシステムファイルではない。

273 :Be名無しさん:02/09/06 10:35
msvcrt.dllはWindowsのライブラリじゃないのか?
なんでこれには答えんの?

274 :Be名無しさん:02/09/06 10:37
>>272
じゃあ、user32.dllはWindowsのライブラリじゃないのか?

275 :Be名無しさん:02/09/06 10:39
>>272
msvcrt.dllはソースがくばられてるんだから、
GB18030に対応してるか言えるんでないの?

276 :Be名無しさん:02/09/06 10:44
じゃあ、対応してるか言ってもらおう。
その前に、gcって何?

277 :Be名無しさん:02/09/06 10:47
>>272
じゃあ、WIndowsってどこからどこまでを言うんだ?
Windowsのretail版を買えばついてくるdllがすべて
Windowsの一部ではないのか?

278 :Be名無しさん:02/09/06 11:00
>>87の噛み付き野郎は、朝早く来て、そして2時間噛み付き、
そして帰って行く。。。

279 :Be名無しさん:02/09/06 11:01
>>278
2時間なんてもんじゃねーよ。w

280 :Be名無しさん:02/09/06 12:15
user32.dllはWindowsの一部に決まってんじゃねーか。
ユーザーインターフェースを担うライブラリだ。
どこのバカがこれとVCのランタイムと同列に扱ってるんだ?
おいおい、頭悪いのは十分わかったから、これ以上笑わせるなよ(藁

281 :Be名無しさん:02/09/06 12:22
もちろん、広義ではmsvcrt.dllもソニーの添付ソフトもWindowsの一部と
言って言えないことはないわけだが、ここで話してるのは、Windowsが
ネイティブにGB18030をサポートしてるかどうかって話だ。

だから、ソニーのソフトがサポートしてなくても、それすなわち
Windowsがサポートしてないことにはならない。ここまではわかるね?

同様に、VCがサポートしてなくても、それすなわちWindowsが
サポートしてないことにはならないわけだよ。

で、msvcrt.dllってのは、VCというれっきとした別商品の一部を、
同じ会社だってことで同梱してるだけ。
user32.dllはWindowsの一部として配布、msvcrt.dllはWindowsに同梱、
この違いもバカには難しいかな?

msvcrt.dllの中のprintfは、GB18030をサポートしてないが、
それはWindowsがサポートしてない根拠には全くならない。

わかるかな?
まだわかんない?
バカだね〜(藁

282 :Be名無しさん:02/09/06 13:06
噛み付き野郎が、もどってきた。。。

283 :Be名無しさん:02/09/06 13:08
>>281
やっと言ったよ。サポートしてないって。w

284 :Be名無しさん:02/09/06 13:14
なんか飽きたな

285 :Be名無しさん:02/09/06 13:52
>>281
噛みつき野郎、
じゃあ、次は、コマンドプロンプトだ。
コマンドプロンプトはGB18030をサポートしてるか?

286 :Be名無しさん:02/09/06 13:53
>>246
> だから、Win9xをサポートしてきたアプリベンダは、
> まず、Unicode化しなくちゃならないという、けっこう大変なことがまってる。
> ただし、LinuxやAIXやSolarisなんかは、GB18030でAPIを呼べるわけで、
> それからみればそういう不満がでるのは当然だと思うぞ。

そりゃ不満を持つベンダもいるだろうが、
だからといってベタな地域化をいつまでも続けるのもマヌケじゃねえ?
WindowsやMacintoshのGB 18030サポートが貧弱なんじゃなく、
国際化されていないアプリケーションが貧弱なんだと言ってはダメか?
だいたいがGB 18030自体、奇襲攻撃みたいな符号化なんだし。

287 :Be名無しさん:02/09/06 14:03
>>286
アプリがUTF-16化しないってのもマヌケだが、
Win自体が、システムロケールのcharsetをUTF-8化しないのもマヌケだ
すべてのcharsetが同じデザインで統一されてるのが良いと思う。
やっぱ、UTF-16はすでにSurrogateが来たあたりで、
当初の目的が破綻してしまったからね。

288 :Be名無しさん:02/09/06 14:08
>>254
> Unicodeの中で、GB18030を扱おうと言った場合、
> 一番の問題は、変換でのラウンドトリップの問題だよね。

ん? UnicodeとGB 18030の間には
ラウンドトリップコンバージョンが成立していたと思うんだが。
問題があるなら具体例きぼんぬ。

289 :Be名無しさん:02/09/06 14:27
>>287
Win32 APIのA関数でUTF-8使えたらもっときれいに行ってたのにとは思う。

290 :Be名無しさん:02/09/06 15:44
>>283
VCがな(藁
Windowsじゃなくてな(藁
字が読める?

291 :Be名無しさん:02/09/06 15:45
>>285
してる。
コンソールのコードページを変更してみろ。

292 :Be名無しさん:02/09/06 16:07
WindowsとVCとメモ帳の区別くらい付けた方がいいぞ(藁

293 :Be名無しさん:02/09/06 16:25
まだWinがGB18030をサポートしてないと思ってる奴がいるのか?

294 :Be名無しさん:02/09/06 19:14
>>281


>ここで話してるのは、Windowsが
ネイティブにGB18030をサポートしてるかどうかって話だ。


違うよ。WindowsがGB18030をサポートしてるかどうかって話だよ。

295 :Be名無しさん:02/09/06 19:16
>>293


「その程度でサポートしてると言えるなら他のどのOSでもサポートしてる」
てなことを言ってる奴はいたけど。
これは常識的な日本語理解では「普通その程度でサポートしてるとは言わないんだよ」
という主張を含意していることになるので。

296 :Be名無しさん:02/09/06 22:29
>>291
MSのサイトに、
GB18030はコマンドシェルをサポートしますか?いいえ。
と書かれているが、これはいつから変わったんだ?

297 :Be名無しさん:02/09/06 22:54
>>286
> だからといってベタな地域化をいつまでも続けるのもマヌケじゃねえ?
> WindowsやMacintoshのGB 18030サポートが貧弱なんじゃなく、
> 国際化されていないアプリケーションが貧弱なんだと言ってはダメか?

Unicodeを使うというのは良いが、UTF-16を使ったのがだめ。

だって、UTF-16と、既存のGB18030やShiftJISのcharsetサポートの違いがありすぎる。
WinはUTF-16とその他のcharsetと別のAPIに分けてしまった。
だからアプリ作る側が移行時とかWin9xのサポートに困る。
Unixのように、UTF-8としてUnicodeをサポートするほうが移行しやすい。

298 :Be名無しさん:02/09/07 04:49
要は、あるプリンタをサポートするとして
このプリンタは漢字フォントが乗ってないので
イメージ展開しないと印刷されません
でも従来の漢字コード出力を自動的に展開するような
エミュレーションドライバは提供しませんので
従来のソフトでは漢字が印刷できません。
漢字を印刷したい時は画面のハードコピーをとってください。

みたいな状態で本当にサポートがあるって言えるのかよ
って話なのかな?


299 :Be名無しさん:02/09/07 09:35
そのプリンタはサポートしてない。
Windowsはサポートしてる。
ハードコピーなんかとらなくても、GB18030からUNICODEに変換する
APIが提供されているのでね。
バカはいつまでも同じ質問をするからレスばっか増えて生産性という物が全く無いね(藁

300 :Be名無しさん:02/09/07 09:39
>>298

何か全然違うような。

301 :Be名無しさん:02/09/07 11:17
>>299
でも、ハードコピーができるってことは、
イメージの印刷はサポートしてるということだよ。
そもそもフォントをイメージ化できなきゃ表示すらできないんだから、
あとはソフトがその二つのapiを組み合わせてつかえばいいだけでしょ?

なんでサポートしてないの?

302 :Be名無しさん:02/09/07 11:48
>>299
コマンドプロンプトでは、
VCのprintfでは、GB18030表示できないが、
gcのライブラリを使えば、GB18030がそのままprintfで表示できる。
なんて、MSでも言ってないことを、ぐたぐた言ってるからだよ。藁

で、gcって何よ?

303 :Be名無しさん:02/09/07 11:53
画面をハードコピーした瞬間、それは文字じゃなくて画像だ。
画像にGB18030もShift_JISもあるか、バカ。

幼稚園レベルの疑問を何個も何個も書くんじゃないよ。
話をごまかそうとしてるんだろうが、何書いても知能の低さが
表れるだけだぞ(藁

304 :Be名無しさん:02/09/07 11:54
>>302
gc知らないなんてネタだろ?
VCに対応するgcつったら一つしかねーじゃねーか。
今度はVCって何よ?って言うんじゃねーだろうな?

305 :Be名無しさん:02/09/07 11:56
それに、MSが「サードパーティのライブラリを使えばできます」なんて言うわけないだろ。
ライブラリって知ってますか?
知らないなら調べて下さいね。

手間がかかるからもう言わせないで下さいね。

306 :Be名無しさん:02/09/07 12:01
>>301
イメージ化までプリンタドライバがしてくれるなら、対応してると言える。
が、「ハードコピー取って下さい」と注意書きのあるプリンタは、
イメージ化を別の手段で取る必要があると見られる。
そういうプリンタは対応しているとは言えない。

Windowsの場合は、GB18030をUNICODEに変換するAPIがちゃんと用意されていて、
まともなプログラマはそれを使うから、立派に対応している。

307 :Be名無しさん:02/09/07 12:03
しかし、画像しか印刷できないプリンタが文字に対応してると考える奴がいるとは
思わなかった。バカにも程がある。

308 :Be名無しさん:02/09/07 12:07
しかしこうやって画像として表示した文字を
文字と認識できない人がいるようですね。
・・・確かに変換してしまったらそれは元の符号系とは言えませんけど。


309 :Be名無しさん:02/09/07 12:18
>>308
認識できない人がほとんどだと思うぞ。
画面のハードコピーしか印刷できないプリンタが文字に対応してると
認識してる電波はお前だけだ。

310 :Be名無しさん:02/09/07 12:20
ついでに言えば、WindowsがGB18030に対応してないと認識してる電波も
お前だけだよ。
いい加減にちょっとは成長してくれ。
常に最初から教えなきゃいけないのは面倒すぎる。

311 :298:02/09/07 12:39
面白い人だなあ
誰もそんなことは言ってないのに。

ハードコピー取ってくださいというのは
そのソフトが対応してないだけでしょ?

GB18030の話は良くわからないけど変換しなきゃいけないなら、
イメージに変換するそのプリンタと同じだと思うよ。

つまり、そのシステムはサポートしてるってことでしょ?

同意見なのになんで電波とか言われなければいけないんだろう?


312 :Be名無しさん:02/09/07 12:40
>>304
gcは知らんが、gccなら知ってるが。

313 :Be名無しさん:02/09/07 12:41
>>310
ついでに言えば、コマンドプロンプトがGB18030に対応してると認識してる電波も
お前だけだよ。
MSでもnoって言ってるのにね。

314 :Be名無しさん:02/09/07 12:42
glibcなら通じるが、gcといったらGNU-Cではなくガベージコレクタとかを想像する。
それともVisualC++用の「gc」っていうライブラリがあるの?
詳細情報希望。


315 :Be名無しさん:02/09/07 12:45
>>305
> それに、MSが「サードパーティのライブラリを使えばできます」なんて言うわけないだろ。

gcのprintfは、コマンドプロンプトでGB18030の文字をネイティブで
表示できるって言ってるのか?
ふーん。そう言ってるgcリリースしてるベンダのURL
とりあえずリンク教えて。

で、gcってどこぞのgcかわからんからそれもURL教えて。

316 :Be名無しさん:02/09/07 12:53
msvcrt.dllでも、mbstowcsとwprintf辺りでいけそう。
ロケール周りでCPを直接指定する方法は無かったかな?


317 :Be名無しさん:02/09/07 12:56
gccはコンパイラだぞ(藁
gcのライブラリでどうしてガベージコレクタなんだよ(藁
http://www.google.co.jp/search?sourceid=navclient&hl=ja&q=glibc+GB18030

>>311
どうしてシステムで対応してたらプリンタが対応したことになるのかね?(藁
Windowsが対応してるのは自明。
プリンタが対応してないのも自明。
だから、Windowsは対応して無くてプリンタが対応してると言い張るお前が電波。

>>313
勝手な話を作るな。俺は終始、UNICODEで対応と言ってる。


318 :Be名無しさん:02/09/07 13:08
>>317
それ、ベンダのリンクじゃないじゃん。

319 :298:02/09/07 13:08
>>317
>どうしてシステムで対応してたらプリンタが対応したことになるのかね?(藁
それは印刷できるからに決まってるでしょ?
文字はイメージとしてね。
CRTにはフォント入ってないけどシステムが持っていれば問題ないわけだし

>だから、Windowsは対応して無くてプリンタが対応してると言い張るお前が電波
なんか混信してませんか?


320 :Be名無しさん:02/09/07 13:11
>>317
いや、MSが、コマンドシェルはGB18030サポートしてない。
って言ってるんだから、GB18030サポートしてないんだろう。
Unicode使う使わないに関係ない。
GB18030サポートは、ベンダが決めること。
あんたが決めることじゃない。

321 :Be名無しさん:02/09/07 13:13
>>317
UNICODEじゃなくて、Unicodeなんだが。。。

322 :Be名無しさん:02/09/07 13:19
「gcのライブラリ」という言葉でBoehm GCとかを連想しただけの話で、
glibcの事を言っているのか、内部でUNICODE変換してくれる「サードパーティのライブラリ」が存在しているという事なのか知りたかった。
UNICODEで対応しているという事は一人以外はわかっているのでは?


323 :Be名無しさん:02/09/07 13:23
>>317
つーか、gcとは具体的にどこぞのgcを指すのかな?
それで、そのgcのprintfはGB18030サポートしてるって言ってる
gcのベンダーはどこよ?


324 :Be名無しさん:02/09/07 13:41
>>317
GB18030をprintfで表示するだけなのに
Winは、すげー手間がいるんだな。藁



325 :Be名無しさん:02/09/07 13:43
>>320
いや、所詮、噛み付き野郎は、電波だからな。藁
リンクもないところ見ると、
やつがWinのGB18030サポート具合を適当に決めたいんだろうな。

326 :Be名無しさん:02/09/07 13:48
>>322
確かに。Open Sourceだと、LCUってのがあるが、
そんなUnicodeエンジン使って
内部でUnicodeで動いてる、libcってあんのか?

まじで、リンク教えろ。

327 :Be名無しさん:02/09/07 14:27
いつのまにか『UTF-16とGB18030を語るスレ』になって
しまっており、BTRON仕様OSも多言語もどこかに
逝ってしまったのが笑える。

328 :Be名無しさん:02/09/07 14:36

6763文字のGB2312文字コード規格から、2万7000文字に増やして、2000年7月に中国政府によって制定された、UNICODEを包括し、上位互換を保った1バイト、2バイト、4バイトの可変調コードになっている中華人民共和国の文字コード規格の名称。
ただし、中国語の辞典に掲載されている文字は5〜6万文字あり、その他にも少数民族の特殊な文字もあり、まだ十分とはいえない。

tp://www.kaigisho.ne.jp/literacy/midic/data/g/g36.htm


アルファベットは今後次々と増えてはいかないだろうが
漢字は略字が生まれたりと増えていく可能性がいつも
つきまとう。

全ての漢字を網羅する日なぞ来るのだろうか。

字素に分解して、全てを合字とした方が結局は近道で
『十分』というに相応しいものになるのではなかろうか。

既に4バイトまでの可変長などが使われている昨今、
大して複雑とは言えないだろうし。

329 :Be名無しさん:02/09/07 18:23
ちゃんとGoogleの検索結果をリンクしてやったじゃねーか。
そっからいくらでも見つかるだろ?
見つからない?
バカだから?
しょうがねぇなぁ(藁

330 :Be名無しさん:02/09/07 18:25
( ´,_ゝ`)プッ…

331 :Be名無しさん:02/09/08 02:20
>>329
どうやら時間かけたわりには、やつは見つけられなかったらしい。
ワラタ。

332 :Be名無しさん:02/09/08 03:21
>>329
バカだから見つからないんで本当によろしく

333 :Be名無しさん:02/09/08 08:28
え、何?
マジで見つけられないの?
大丈夫か?
頭ついてるか?
http://www.shuwasystem.co.jp/books/wwwsrch/cgi-bin/content/871/glib/Glibc2-HOWTO-j.htm
ほら、これでバカでもインストールできるだろ。
ソース見てみろよ。
あ、バカにはソース読めないんだっけ(藁

しょうがねぇなぁ。
http://www.asahi-net.or.jp/~ez3k-msym/charsets/cjk-c.htm
>2000年7月には glibc 2.2 でも GB 18030 が使えるようになりました。
ほら、取りあえずこれでわかったろ?
もっと詳しいことが知りたきゃ、ソース読む以外にはないんだけど、
もうちょっと大人になってからね(藁

334 :Be名無しさん:02/09/08 09:14
問題1 次の情報ソースを挙げよ

1. WindowsでGB18030が使えない
2. 画像しか印刷できないプリンタはGB18030に対応している

こんなこと本気で言ってる奴がいるんだからなぁ(藁

335 :Be名無しさん:02/09/08 09:16
あと、こんなことも言ってたよな(藁

3. printfでリテラル文字を表示するときには第一引数に書くべきである
4. msvcrt.dllはVCのランタイムではない

イタタタタ(藁

336 :Be名無しさん:02/09/08 09:37
>Glibc2はGNU Cライブラリの最新版です。
>現在、変更なしで動作するのは、 GNU HurdシステムとLinux i386, m68k, alphaシステムです。
>PowerPC, MIPS, Sparc, Sparc 64, Arm用のLinux向けには2.1版で対応の予定です。
>将来的には、 ほかのアーキテクチャーとオペレーティングシステム用にも順次対応の予定です。



337 :Be名無しさん:02/09/08 09:44
>>334-335
やっぱ、もーそーくんだったらしい。
何に対して反論されてるかもわかってない。

>>336
結局やつが言ってる、gcって何なんだろうね。

338 :Be名無しさん:02/09/08 09:47
>>335
つーかそんなこと言ってるやつはいたか?

1. コマンドシェルはGB18030サポートしています。
2. gcはGB18030サポートしています。
3. コマンドシェルではVCのprintfはGB18030表示できませんが、gcならOK

はいたけど。イタタタタ(藁

339 :Be名無しさん:02/09/08 10:04
>>336
紹介したglibcがWindows用でなくて悪かったね。
普通、応用できると思うからさぁ、つい君が並はずれたバカだってこと
忘れてたよ(藁

ま、でもこれでライブラリを換えることで、GB18030が使えたり使えなかったり
することは理解できただろ?
これを「ラ・イ・ブ・ラ・リ・依・存」って言うんだよ(藁
一つ勉強になったね(藁

340 :Be名無しさん:02/09/08 10:05
>>338
つーかそんなこと言ってるやつはいたか?

コンソールのコードページをUNICODEに直してUNICODEで表示しろとは言ったけどね。

日本語読めないのはさぞかし不便だろうね(藁

で、まだWindowsがGB18030サポートしてることが理解できないの?
何年くらいかかりそう?
もう飽きちゃったなぁ(藁

341 :Be名無しさん:02/09/08 10:12
>>338
つーか、うちのcygwin、コンパイルするときエラーメッセージが文字化けするの
なんとかならない?

.mo をSJISに書き換えればいいんだろうか?


342 :Be名無しさん:02/09/08 10:24
>>335
> printfでリテラル文字を表示するときには第一引数に書くべきである

たぶん、あんたは、
「printfで第一引数にリテラル文字を書いちゃいけない。」
って、言ってたやつだな?何年前のこと言ってんだ?DOS時代のことか?
そんなちゃちいライブラリ使ってんな。藁

ちなみに、WindowsのVCについてくるprintfの場合、
現在のロケールのchasetがその文字コードをサポートしているなら、
どこに書いても良さそうだぞ。
ちゃんとformatストリング内は、文字tokenはisleadbyteで
1キャラクタごと取ってきてるからな。
ちゅーか、最近のライブラリはDBCS awareになってるから、
現在のロケールにある文字なら動く。
あんたのライブラリは違うらしいが。

もちろん現在のロケールに含まれない文字コードが含まれていた場合は、
そのパースはおかしくなるに決まってるが。

343 :Be名無しさん:02/09/08 10:27
>>340
> で、まだWindowsがGB18030サポートしてることが理解できないの?

それは、WinがGB18030サポートするって言った時点から承知だが?
で、まだWindowsがGB18030サポートがださいってことが理解できないの?

344 :Be名無しさん:02/09/08 10:27
それより、なんで、
ライブラリを使ってイメージに展開すればその文字が印刷できるのに
そのプリンタが文字の印刷に対応してないと言えるのかが知りたいな。


345 :Be名無しさん:02/09/08 10:28
>>339
> これを「ラ・イ・ブ・ラ・リ・依・存」って言うんだよ(藁

つーよりMSの「ラ・イ・ブ・ラ・リ・だ・さ・い」って言うんでねーの(藁

346 :Be名無しさん:02/09/08 10:30
>>291
が言ってた。

347 :Be名無しさん:02/09/08 10:32
>>340
ちなみに>>291は噛み付き野郎だから、おまえじゃねーの?

348 :Be名無しさん:02/09/08 10:34
gcのライブラリって、glibcってことだったのか?

349 :Be名無しさん:02/09/08 10:41
>>87
GB18030は
> TRONと比べてもUnicodeと比べても文字鏡と比べても
> 漢字圏にとっては素晴らしいぞ。
>
> 何が素晴らしいって、主だったOSが既に対応可能に
> なっているから。しかも、フォント依存ではなく。

つーことで、噛みつき君は、WinのGB18030サポートは、
UTF-16依存でも、素晴らしいと言いたかったのか?
WinくらいのGB18030サポートだったら、
なんで素晴らしいのかぜんぜんわからん。

350 :Be名無しさん:02/09/08 10:43
「最初からださいという話をしていたんだよ」と言う
人が絶えないので、どこからださいという話をしだした
か確認してみました。

「ださ」および「ダサ」で検索したところ
>>155でした。

>>87あたりから始まった話で、随分間を空けてから
登場しています。
それも
>Shift JISサポートに比べると ださださ、おそまつだねーってことだと思うんだが。

と、単に推測しているだけ。


そのカキコより前に>>142

>>139
>> それを対応してないと苦しい言い訳をしてるところが恥ずかしい。

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

と書いています。>>139の「W2kはGB18030対応している」
という考えを『拡大解釈』だと言っている。
つまり、>>142は、拡大しない普通の解釈では
「W2kはGB18030に対応していない」と主張していることになる。

351 :Be名無しさん:02/09/08 10:50
>>350
ま、結論が出たってことで、いいんでないの?
WinのGB18030サポートってダサいよな。

352 :Be名無しさん:02/09/08 11:02
そしてバカは何か場をごまかせた気になった満足して帰るのでした。
もう来なくていいぞ(藁

353 :Be名無しさん:02/09/08 11:05
まあ、画面に表示されたドットイメージを文字と認識できないらしいから
何言ってもしょうがないよね。


354 :Be名無しさん:02/09/08 11:22
で、そんなGB18030がどうして、
TRONと比べてもUnicodeと比べても文字鏡と比べても
すばらしいわけ?
WinのGB18030サポートもださいのに。

355 :Be名無しさん:02/09/08 11:28
まあドットイメージにエンコーディングが残ってると認識してる人は
まだいるのね(藁

356 :Be名無しさん:02/09/08 11:35
>>355
ぶんれつか?

357 :Be名無しさん:02/09/08 11:38
とりあえずローカル文字コード+数値実体参照(それ以外のコード)
じゃ駄目なのかな?

というか文字鏡とかの実体参照は規格化されてるのかな?


358 :Be名無しさん:02/09/08 11:40
>>355
どいつに話してるかもわからんらしい。
まだ、もーそー止まらないみたいだな。

359 :Be名無しさん:02/09/08 11:42
画像になった文字とテキストが同じだと認識してる人って結構いるよ。
初心者にね。

360 :Be名無しさん:02/09/08 11:48
ところで、超漢字4って今何文字サポートしてるの?
BTRONのPC実装系って、超漢字だけ?

361 :Be名無しさん:02/09/08 17:07
>>354

超漢字以外ではとんと広まらないトロンコードはユーザから見れば
実質的には超漢字専用の独自コードみたいなもんだし、文字鏡は
エンコーディングが標準化されている訳でもなく、フォント変えて文字
化けさせるような姑息な方法ばかりが普及していてダメなので論外。

Unicodeと比べてGB18030がいいのは、漢字の国の人が拡張していく
コードなので、漢字圏としては安心…くらいのもんかね。

362 :Be名無しさん:02/09/09 14:02
>>361
中国がGB 18030で漢字を独自に拡張することなんかないだろ。
漢字の拡張が必要ならUnicodeに提案して入れるはず。
独自の拡張が考えられるとしたら少数民族言語に使われる文字だろうが、
それにしたってGB 18030に入れたら
Unicodeにも入れようという話になるのが自然。
あの異様な拡張性には謎が残るが、
好き勝手なことができる余地を残しておこうということだろうし、
各国の投票で決まるUnicodeと比べて安心とは到底考えられないが。

363 :Be名無しさん:02/09/09 17:40
要はGB18030ってのは>>357みたいな多バイトコード系って考えていいの?
GBK+UNICODE みたいな。


364 :Be名無しさん:02/09/09 20:37
>>362

Unicodeに登録させる為の既成事実化としてGB18030
にバンバン登録するというのはありえるかな。

JIS第4水準だって、そうやって規格化する事でUnicodeへの
登録を促すという目的があったそうだし。

365 :bloom:02/09/09 20:41

http://www.leverage.jp/bloom/start3/

366 :Be名無しさん:02/09/09 20:51
>>364
それもあるし、タイミングの問題もあるだろうね。
ISO 10646/Unicodeに文字の登録を申請しても、
規格化されるまでには時間がかかる。
一方、国内でGB 18030を使っていれば、迅速に実装できる。
JIS X 0213の例で言えば、
Shift JISの壁に阻まれて実装で遅れをとったけど、
GB 18030の拡張性があればその心配もない。

367 :Be名無しさん:02/09/09 21:16
>>366
よくわからないけど1バイト+2バイトの混成であるSJISに
4バイトコード系を追加することはできないの?


368 :Be名無しさん:02/09/10 12:26
>>367
そりゃあ第3水準・第4水準以前だったら
やってできないことはなかっただろうけど、
誰もそんなの実装しない罠。

369 :Be名無しさん:02/09/12 21:37
Shift_JISをいまさらリファインする前にお前ら
ISO-2022-JP-2を使ってください・゚・(ノД`)・゚・

370 :Be名無しさん:02/09/13 00:42
>>369
JISをフルサポートしてないんで却下。
というかなんでそもそも0201-KANAを組み込まなかったのか疑問。
使わない方針で行ってくれというのは知ったこっちゃないが、
両方のカナが混在している環境が多く存在している以上、
相互変換ができないのはやっぱり不便だよね。

371 :Be名無しさん:02/09/13 08:57
ISO-2022-JP-3でも可

372 :Be名無しさん:02/09/13 08:59
そういえば、ISO-2022-JP-2でHTML書いて、そこに足りない字は数値実体参照で拾ってくれば

 ユニコードの文字セット+包摂前の漢字

で文書が書けるんだよね。

373 :Be名無しさん:02/09/13 09:32
>>372
ISO-2022準拠の方法でコード切り替えすら行なわないのに、
ISO-2022-なんとかを名乗るのはおこがましいというか、なんというか。

つーかISO-2022準拠のキャラクタセット全部サポートすると、カナや
ユニコードの文字セットはともかくとして、絵が書けたり、音楽すら
鳴ってしまったりすると思うのは気のせいだろうか?

374 :Be名無しさん:02/09/13 15:06
気のせい

情報交換体系としての側面であって、
あれらをふつう図形文字集合とは考えない。
^G とかと同じ(?)


375 :Be名無しさん:02/09/14 20:11
結論

内部コードとして GB 18030 をサポートしている
入出力用のコードとして GB 18030 をサポートしていない


376 :Be名無しさん:02/09/14 20:14
対策

NT 系では W系API のみを使用する
9X 系では入出力時に自分で変換する


377 :Be名無しさん:02/09/14 20:20
事実

コンソールは GB 18030 のコードを受け付けない


378 :Be名無しさん:02/09/14 20:27
未確認情報

gc なるライブラリを使うと、GB 18030 がコンソールで使えるらしい

コンソールへの入出力の前に自動変換するものだと推測される


379 :Be名無しさん:02/09/15 01:00
>>375
その書き方だと、内部コードってなに?入出力用のコードって何?
ってなぞが多すぎ。あと、GB18030の文字集合か、Encodingかってのもね。

>>376
それより、今後のアプリ開発は、このスタイルでしょう。

Win9x, NT 系では W系API のみを使用する。
ただし、MSLU (Microsoft Layer for Unicode)を使うこと。
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/win9x/unilayer_4wj7.asp
これで、ソースが1つですむ。
Win9x上では、Unicode文字はpartialにサポートになっちゃうけど。

380 :Be名無しさん:02/09/15 13:40
>>375
Win2000/XPの内部コードって、UTF-16じゃんか。

381 :Be名無しさん:02/09/17 15:07
お前ら「OSの内部コード」を定義してください。
思いつきを書いとけば、
「(文字コード変換ルーチン以外の)APIが直接扱う文字コード」ってとこか?

382 :Be名無しさん:02/09/17 19:53
APIってのはインターフェースだ。内部じゃない。
何言ってんの?バカ?

383 :Be名無しさん:02/09/17 22:15
内部コード: 何言ってんの?バカ?

外部コード: 意味がわからないから、ちゃんと考えて言ってよ。

384 :Be名無しさん:02/09/18 09:52
インターフェースというのは、接続するもののこと。
APIとは、OS(内部)とアプリ(外部)とのインターフェース。
内部で使われているのはUTF-16。
外部で使われているのは様々。

385 :Be名無しさん:02/09/18 12:08
システムルーチンのことをAPIとも言うってだけのことだろ。

386 :Be名無しさん:02/09/18 12:16
>>384
APIのIはなんだかしっとるけ?

387 :Be名無しさん:02/09/18 14:51
Itteyosi

388 :Be名無しさん:02/09/18 20:01
内部コード・外部コードという用語は mohta 大先生も使っていますが、何か?

389 :Be名無しさん:02/09/18 20:33
>>386
インターフェースだぞ。知らなかったのか?
何だと思ったんだ?

390 :Be名無しさん:02/09/18 21:01
モーオタがバカなんだ!

391 :Be名無しさん:02/09/19 12:52
RFC1554(ISO-2022-JP-2)のauthorである
mohta氏の用語法にケチをつけて
引っ込みがつかなくなった厨のいるスレはここか?

392 :Be名無しさん:02/09/20 11:38
でも「〜危ない」での mohta 氏の用法では、
同書での議論が目的とする範疇をはっきりさせるために
情報交換用コード=外部コード
プログラムが操作するためのコード=内部コード
と定義してるだけで、ここで問題にしてる
アプリとOSの間のインタフェースとはちょいズレますが?

393 :Be名無しさん:02/09/20 14:50
んーとさー、たとえばATSUIはAppleのUnicode描画APIだ。
で、ATSUIは関数(だけじゃないが)群だ。
その関数群が扱うUTF-16は「Mac OS Xの内部コード」だろ。
まさか「ATSUIはインタフェースだからOSの内部じゃない」とか
言い出すやつはいないだろうな。

394 :Be名無しさん:02/09/21 00:31
要は通信用語の内部コードと、今言われているOSの内部コードは
定義が違うって話でしょ?

通信の立場では、情報交換に使う外部コードは統一しなきゃ駄目だけど、
自分や相手の内部コードはなんでもいい。

OSの立場では、ソフトが使う外部コードはなんでもいいけど、
OSに発行するコマンドで使う内部コードは決まっている。

というわけで発想が全く逆なんだよね。


395 :Be名無しさん:02/09/22 13:43
>>366

GB18030が中国の好き勝手に迅速に漢字を増やし
ていくことが出来るということは、TRONコードの
様に包摂基準が一貫しなくなる(というか、包摂基準
なんて何も無い状態になる)危険性は無い?

ましてや、GB18030に登録されたという事実を
理由にUnicodeに後追いで追加されていくことになると。

396 :Be名無しさん:02/09/24 12:33
>>395
俺の知る限りじゃ、中国(大陸)には
あまり細かい字体差を区別しようという発想はなさそうだ。
Unicodeの包摂規準をぐしゃぐしゃにしているのは、
むしろ台湾と韓国だと思われ。

397 :Be名無しさん:02/09/24 13:25
>>396
KS X 1001 とかをネタに言ってるなら、それは筋違い

398 :Be名無しさん:02/09/24 13:46
>>397
いや、俺が韓国と書いたのは互換漢字(重複符号化)のことではなく、
Extension Cのソース(高麗大蔵経)のこと。

399 :Be名無しさん:02/09/24 20:25
UnicodeとGB18030が収録する文字が結果的に
同じであったとしても、2バイト固定とか言いながら
代理ペアとかで妙な形で建て増ししてる前者よりは
最初から可変長の後者の方が潔くって好き。
使えねえけど。

400 :Be名無しさん:02/09/24 20:54
GB 18030こそ究極の建て増しだろ。
それにサロゲートペアのほうが
先行キャラクタと後続キャラクタの区別がはっきりしている分、
GB 18030の方式よりスマートだと思うが。

401 :Be名無しさん:02/09/25 01:10
ところで数値実体参照でユニコード以外扱う方法ってないの?

402 :Be名無しさん:02/09/25 11:16
>>401
標準化機関にネジ込めばいいんじゃねぇの ?

403 :Be名無しさん:02/09/25 12:48
W3CのHTMLでISO 10646以外の実体参照を定義しろってのは無理な話。
でも、勝手に使っちゃってもSGML・XML的にはOKなんじゃないの。
文字鏡の実体参照あたり、けっこういろんな人が使ってると思うけど。

404 :Be名無しさん:02/09/26 01:33
逆に、どんなエンコードでもHTMLならISO10646 BMPの
文字は数値実態参照で書けるのだから、エンコード自体に
ISO10646 BMPに含まれない文字を含むものを使えば、
ISO10646 BMP+αの文書を作成できるね。

405 :Be名無しさん:02/09/26 19:37
>>404
HTMLの数値文字参照がBMP限定だという話のソースきぼんぬ。

406 :Be名無しさん:02/09/28 15:17
限定とは誰も言っていない罠

407 :Be名無しさん:02/09/29 05:17
>>403
エンコードは登録されてるの以外を使うはダメさ。
基本はISO 2022だからエンコードした文字以外をISO 10646から探すか、構造を借りて無関係に実態参照を張るほうがよいかと(UTF2000や文字境)
>>404
UCS-4を前提にしてるっぽいからBMP限定じゃないよ〜ん

408 :Be名無しさん:02/09/29 11:40
>構造を借りて無関係に実態参照を張るほうがよいかと(UTF2000や文字境)
そこら辺の規格ってあったら知りたい。

というかISO 2022登録(ISOREG?)コードって実体参照で使えるの?


409 :Be名無しさん:02/09/30 10:23
> というかISO 2022登録(ISOREG?)コードって実体参照で使えるの?
一部を除き使えない。
Unicode は、0から255までは ISO 8859 と同じ。HTML 3.xまでは、
実体参照は ISO 8859 を指してた。

410 :Be名無しさん:02/09/30 12:57
そういや、TRONのアレもアレだな。&Txxyyyy;とかってやつ。

411 :Be名無しさん:02/10/02 00:30
ふと思って、 ISO 10646 を調べたんだけど、群オクテットの最上位ビット
は、0ですね。
てことは GB18030 の4バイト集合の部分とは重ならないで、共存可能で合っ
てまつか?

412 :Be名無しさん:02/10/02 08:38
ISO10646とGB18030を同時に使えるエンコード方式を
策定するってか

413 :Be名無しさん:02/10/02 09:00
バイトストリームだけ見て UTF-* と GB18030 系って区別可能?

414 :Be名無しさん:02/10/02 12:37
>>411
32ビット1バイトのUCS-4(UTF-32)と
8ビット1バイトのGB 18030「4バイト集合」が
32ビット単位で見れば重ならないということに
何か意味があるか?

415 :Be名無しさん:02/10/06 09:44
そのまま一緒にしてISO10646とGB18030の文字集合を
併せたエンコードを捏造できるってことでは?
現状、文字は全て重複してるけど。

416 :Be名無しさん:02/10/07 11:34
実際に使われる文字のほとんどは2バイト集合と1バイト集合のほうなので、
4バイト集合だけUCS-4と共存させても無意味でしょ。
つか、すべての文字を共存させることができたとしても
やっぱり無意味だけどさ。

417 :Be名無しさん:02/10/09 18:51
>>405
W3Cの文書ではこうある

http://www.w3.org/TR/REC-html40/charset.htmlの5.1
HTML uses … the Universal Character Set (UCS), defined in [ISO10646].

The character set defined in [ISO10646] is character-by-character equivalent to Unicode ([UNICODE])

http://www.w3.org/TR/REC-html40/references.html#ref-UNICODE
[UNICODE]
The Unicode Consortium. "The Unicode Standard, Version 3.0"…

つまり、超BMPを含んでいる。

ただしこの部分、昔はこうだった
http://www.w3.org/TR/1998/REC-html40-19980424/references.html#ref-UNICODE
[UNICODE]
"The Unicode Standard: Version 2.0"…
405のソースは、古い文書を見ていたと思われ

418 :??:02/10/20 22:15
文字鏡の文字がISOに登録されたってどういうこと?

419 :Be名無しさん:02/10/21 14:42
マジ?

420 :Be名無しさん:02/10/24 15:41
ISO 10036 のレジストラが GLOCOM なんだわ。
で、それに登録されたらしい。

そういう言い方をするなら、
Unicode だって ISO 2022 に登録されてる☆ミ

421 :Be名無しさん:02/10/25 13:16
グリフ情報の交換標準であって、Code for Information Interchange
ではないから、誤解がないように書いてほしい。

422 :Be名無しさん:02/10/25 17:59
>>421
ISO 10036 で規定してるのは,
Code for Gryph-Image Information Interchange なんでせうか?
それとも Code と考えるべきではない?


423 :Be名無しさん:02/10/25 18:05
http://www.glocom.ac.jp/iso10036/docs/toc.htm

424 :Be名無しさん:02/11/21 14:50
ega

425 :Be名無しさん:02/12/17 04:40
保守しとくか

426 :Be名無しさん:02/12/28 12:47
文字鏡とUnicode3.2を統合した新しい文字集合キボンヌ(嘘)

427 :Be名無しさん:02/12/28 14:06
で結局 gc って glibc のことを指す俺用語なわけ?

(俺用語: かなり偏りのある自分用語)

428 :_:02/12/28 14:09






        http://freeweb2.kakiko.com/dengeki/indexf.htm






429 :Be名無しさん:02/12/28 21:29

http://www.chip.de/produkte_tests/produkte_tests_8924297.html
http://pc3.2ch.net/test/read.cgi/win/1021371894/l50
     。ρ。      
         ρ      
         mドピュッ            
        C|.| /⌒⌒⌒ヽ/~ ̄ ̄ ̄ ̄ヽ   
      /⌒ヽ⌒ヽ___   |  ∴ヽ  3  )
     ./  _  ゝ___)(9     (` ´) )
    /  丿ヽ___,.───|彡ヽ ―◎-◎-|
    _/ )          (   Y ̄ ̄ ̄ ̄)
   (__/


430 :Be名無しさん:03/01/06 18:31
>>426
そりゃ単に文字鏡の次のバージョンじゃねーの?

431 :Be名無しさん:03/01/11 11:09
ケータイの文字コードにUnicodeが採用される日は来るかな?

432 :名無しではなくトンパ文字なので表示できません:03/01/12 01:07
μiTRONケータイの文字コードにTRONコードが採用される日は来るかな?

433 :山崎渉:03/01/16 03:30
(^^)

434 :山崎渉:03/04/17 12:05
(^^)

435 :山崎渉:03/04/20 05:53
   ∧_∧
  (  ^^ )< ぬるぽ(^^)

436 :山崎渉:03/05/22 02:08
━―━―━―━―━―━―━―━―━[JR山崎駅(^^)]━―━―━―━―━―━―━―━―━―

437 :Be名無しさん:03/05/22 07:51
>>431
とっくに採用されてる。

438 :動画直リン:03/05/22 09:14
http://homepage.mac.com/hitomi18/

439 :山崎渉:03/05/28 16:43
     ∧_∧
ピュ.ー (  ^^ ) <これからも僕を応援して下さいね(^^)。
  =〔~∪ ̄ ̄〕
  = ◎――◎                      山崎渉

440 :Be名無しさん:03/06/14 02:23
>>398
高麗大蔵経って例のあれか?

441 :Be名無しさん:03/06/18 21:21
XML and Unicode: Mix with care
http://zdnet.com.com/2100-1104_2-1017789.html
XMLとユニコードを一緒に使うときは注意が必要らしい。
だれか、解説してくれ。



442 :山崎 渉:03/07/15 11:22

 __∧_∧_
 |(  ^^ )| <寝るぽ(^^)
 |\⌒⌒⌒\
 \ |⌒⌒⌒~|         山崎渉
   ~ ̄ ̄ ̄ ̄

443 :Be名無しさん:03/07/17 23:07
緊急浮上

http://www.zdnet.co.jp/news/0307/17/nj00_wjsaka_2.html

「ただし私はUnicodeが嫌いなので、Sunに言って超漢字に対応させている」

444 :Be名無しさん:03/08/01 16:13
「ただし私はUnicodeが嫌いなので、Sunに言って超漢字に対応させている」

死ね!

445 :Be名無しさん:03/08/01 16:21
厨房の夏か...

446 :_:03/08/01 16:25
http://homepage.mac.com/hiroyuki44/hankaku09.html

447 :Be名無しさん:03/08/13 08:25
>>32
戦後の歴史も知らんみたいだな。

マスコミは馬鹿だから講話独立の意味が分かってないだけだ。
それをそのまま採用するなど以ての外。

448 :Be名無しさん:03/08/13 08:26
>>33
高校の時調べもので「こけら」を引いたら
「柿」とかいてあって頭が混乱した思い出がある。

449 :Be名無しさん:03/08/13 08:29
根本的に文字を1対1対応のコードに割り振るのは無理なんじゃないか。

ユニコードにしろトロンにしろ。

450 :Be名無しさん:03/08/13 11:37
たとえそうだとしても、やらねばならぬ。

451 :Be名無しさん:03/08/13 16:14
>>450
やる前に考えろって言ってんの!

452 :Be名無しさん:03/08/13 19:55
誰に言ったの?

453 :Be名無しさん:03/08/13 21:00
無修正DVD販売です.新作旧作多数在庫あります。
女子校生モノ、熟女モノ等多数ご用意してます。
http://d-jupiter.net/

454 :山崎 渉:03/08/15 21:47
    (⌒V⌒)
   │ ^ ^ │<これからも僕を応援して下さいね(^^)。
  ⊂|    |つ
   (_)(_)                      山崎パン

455 :山崎 渉:03/08/15 23:00
    (⌒V⌒)
   │ ^ ^ │<これからも僕を応援して下さいね(^^)。
  ⊂|    |つ
   (_)(_)                      山崎パン

456 :Be名無しさん:03/10/31 02:09
TRONの文字コードって、小説なんかの架空の文字も集めてるらしいけど、
ゼビウスのゼビ数字とか、フィネガンズフェイクの変なアルファベット(邦訳版
の変な字も)なんかもあるの?

457 :Be名無しさん:03/10/31 15:59
>>456
そういうのは入ってないだろ。
手書き文字の略体化のルールを拡張適用した「架空の文字」なら
入ってそうだけど。

458 :Be名無しさん:03/11/02 05:07
>>456
著作者の承諾を得てあなたがTRON文字協会に登録すれば可能。

459 :Be名無しさん:03/11/02 19:13
欧米人は表意文字なんて原始人の使う文字ぐらいにしか
おもってないんだろうな。古代の象形文字も漢字も
同じような感覚で接してるんだろうな。

460 :Be名無しさん:03/11/04 19:58
>>440
あれだ。

461 :Be名無しさん:03/11/06 08:05
文字コードも半導体投資も底なし沼。

漢字の派生は過去の誤字脱字全部添削するようなもの。

462 :Be名無しさん:04/02/26 17:12
age.

463 :Be名無しさん:04/03/08 21:26
>>461
とりあえず全部包括してしまえばいい。
漢字の総数なんてたいした数じゃない。
漢字の総数は非常に多いが見通しが立つぐらいの有限だから。

他の文字で構造的組合せ型はたちが悪い。
あれはフォントの扱い方を根本から見直さないと
どんなに収録してもキリがない。

464 :Be名無しさん:04/03/09 12:51
>>463
おまえ頭悪いだろ。

465 :Be名無しさん:04/03/09 20:32
>>464
漢字の多さなんてたいした問題じゃない。
見通しの立つ膨大さなんて質がいい方。

466 :Be名無しさん:04/03/11 10:24
ほとんどの漢字、トロン使いパソコン表示可能に
http://book.2ch.net/test/read.cgi/bizplus/1078926772/

国産基本ソフト「トロン」の開発を手がけるトロンプロジェクト(リーダー・坂村健東大教授)は10日、パソコン上で現在使われているほとんどすべての漢字を
表示可能にするシステムを開発したと発表した。個別の漢字に番号を振り、異なるシステム間で文章を交換した場合も文字化けなどの問題が起きないようにした。
出版・印刷業での利用を見込んでいる。
開発した「トロン・フォント・トレーサビリティー・システム」は、では、トロンで利用可能な約17万字の漢字を「ウィンドウズ」や「マックOS」などトロン以外の
システムでも利用できるようにする仕組み。トロンで利用可能な文字に加え、NECや富士通、日立製作所などが制作した規格外の漢字(外字)にも番号を付与、参照可能にした。
外字を含んだ文章を「トロン文字収録センター」の外字変換サーバーを通じて変換、システム間の互換性を持たせる。コンピューター上で使える漢字は
日本工業規格(JIS)の第一・第二水準6879文字や、国際的な基準である「ユニコード2・0」で約2万字で、微妙に形状が違う異体字などを含んでいなかった。

http://www.nikkei.co.jp/news/main/20040310AT1D1007910032004.html

467 :Be名無しさん:04/03/12 08:13
元ソースは共同通信
Web東奥・ニュース/it 20040310 漢字異体字、欧米OSでも トロンの坂村教授ら開発
http://www.toonippo.co.jp/news_kyo/news/20040310010030611.asp
漢字異体字、欧米OSでも トロンの坂村教授ら開発(京都新聞:2004.03.10)
http://www.kyoto-np.co.jp/news/flash/2004mar/10/CN2004031001003061C2Z10.html

ZAKZAK 漢字異体字を欧米OSでも…トロン坂村教授開発
http://www.zakzak.co.jp/top/t-2004_03/1t2004031129.html

 国産基本ソフト(OS)トロンを推進している坂村健東大教授は10日、
人名や地名、文学作品などで用いられる漢字の異体字を、ウィンドウズ
やマッキントッシュなど欧米のOS上で自動表示する技術を開発したと発表した。

 印刷、出版業界では異体字をウィンドウズなどの機器で処理する際、
手作業で外字リストの作成や校正を行う手間があったが、
「新技術で大幅な省力化が可能になり、
大手企業で年間数億円規模のコスト削減が可能」(坂村教授)という。
 標準文字にない外字にそれぞれ識別番号を付けた文字コード(トロンコード)
のデータベースを活用。専用の外字変換サーバーを使い、必要な文字を
データベースから検索して表示する仕組み。データベースや専用サーバーは
無償で公開する。
 トロンOS「超漢字」などは、異体字のほか中国などで使われる漢字を含めて
既に計17万の漢字が表示できる。

 これに対し、欧米のOSはアルファベットを基本に設計され、
日本の大漢和辞典で約5万もある漢字を収納できない。このため、
文字数の多いアジア諸国の言語に適していないとの批判もある。
 新技術は自治体や企業合併の際、外字データを整理統合するケースなど
でも有効だという。年内には個人でも利用できるようになる見込み。
ZAKZAK 2004/03/11


468 :Be名無しさん:04/03/12 08:20
印刷業界が頭を悩ませる外字問題、坂村氏の提案する解決方法とは? (MYCOM PC WEB)
http://pcweb.mycom.co.jp/news/2004/03/11/014.html

トロンプロジェクトは、「フォント・トレーサビリティ・システム」を発表した。
同プロジェクトリーダーで東京大学教授の坂村健氏が長年取り組んできた
OS「トロン」の多文字技術を他のOSでも利用できるようにし、多文字問題・
外字問題の解決を助けようというシステムだ。

日本で利用される漢字の種類は膨大で、PCで区別可能な数を遙かに
超えている。また、字体の違いを区別できないといった問題も存在する。
こういった問題に対して印刷業界などでは「外字」を使って文字を追加す
ることで対処してきた。しかし、外字を管理するための「外字表」には管理・
整理の手間が掛かり、坂村氏は外字表の取り違えが原因となるトラブルの
存在も指摘する。「フォント・トレーサビリティ・システム」は、こういった多文
字に関する問題を解決するために「TRONコード」を利用して全ての文字を区別し、
外字や異字体などを管理する。これをWindowsやMac OSといった既存のOSでも
扱うことのできるようにするためのシステムだ。また、ユビキタスIDを利用して
外字表の管理も行う。

469 :Be名無しさん:04/03/12 08:20
TRONコードでは、既存の文字コードに含まれる文字やあらたに作成された
外字に対し、TRONコードを使って統一番号を付与する。文字コード間での
重複や異字体などに関しては、データベースで管理することで対処する。
Unicodeなど既存の文字コードでは、微妙に違う二つの漢字を異字体とするか
別の文字とするかを議論による判断で決定してきたが、TRONコードでは
細かい違いであっても、全ての文字に一意の文字コードを付与することが
大きな特徴となっている。坂村氏は「(異字体に関する)学問的な研究を
否定はしないが、(細かに異なる2つの文字を)区別するかしないかはユーザが
決めること」と主張する。異字体データベースに関しては複数の存在も認め、
異字体に関する複数の説に対応できるものとする。TRONコードのコード
割り当てについてはウェブサイト「トロン文字収録センター」で公開されており、
文字の読み・おおよその画数・部首などから検索を行うことができ、TRON以外でも
TRONコードに収録される文字の利用が可能となっている。

TRONコードへの新たな文字の追加は既存の文字コードを丸ごと追加する
方法の他にも、1文字だけを追加する方法も用意されている。DTPソフトが
標準で持つ外字セットや自治体で使用される人名用外字のセットなども
収録してコードを割り当てることも可能だ。複数の文字コードを収録する
TRONコードはメタコードとして振る舞うことができ、TRONコードを仲介して
文字コード間の変換を行うこともできる。

470 :Be名無しさん:04/03/12 08:21
こういった既存システムの文字コード同士の変換を行う仕組みをTRON以外
のOSからも利用可能とするために「外字変換サーバー」が用意された。
「外字変換サーバ」では、TRONコードで作成された多漢字コンテンツを読み込み、
他のOSで読み込むことができるShift-JISなどのコンテンツと外字表、その
コンテンツで使用される外字を含んだTureTypeフォントを生成する。
クライアントで実装せず、サーバの機能としたのは既存の業務システムの
変更を行う必要がないことや複数システムの統合に有利であるからという。

また、従来出版物毎に作成して管理されてきた外字表や外字フォントセットの
管理を「ucode」を利用して行う。外字対応表毎にucodeを付与し、ユビキタス
IDセンターが出版物との対応を管理する。これによって外字表の管理を容易にし、
コストを下げることが可能となるという。

外字変換サーバとucodeによる外字表の管理によって、これまでTRONで実現
されてきた多漢字の利用を汎用的なソリューションとして、OSを問わずに多くの
プラットフォームで利用可能となる。坂村氏は、「フォント・トレーサビリティ・システム」
について、様々なOSのメリットを利用し、それぞれの得意分野を活かしてコンテンツの
作成を行うことのできるメリットを強調する。また、こういった「役割分担」は
最近のトレンドであると語り、今回のシステムはマイクロソフトとの提携などに見られる、
WindowsやLinuxなど他のOSとTRONの「協力関係」を深める取り組みの一端であるともした。

471 :Be名無しさん:04/03/12 19:48
またカラ周りしそうな予感

472 :Be名無しさん:04/03/12 21:01
既存の資産を集めて使うという発想はいい。
ただ、これだと用途が限られる。

473 :Be名無しさん:04/03/13 01:53
既存のシステムはそれなりに動いてるしな。
いまさら設備投資するところがどれだけあるか?
10年遅かった。

474 :Be名無しさん:04/03/15 10:18
ますます超漢字の必要性がなくなるのね……

475 :Be名無しさん:04/03/15 22:24
超漢字が死んでもTRONコードが生きれば意義は大きい。

476 :Be名無しさん:04/03/15 23:57
既存の外字資産といっても無限にあるわけじゃないからなぁ。

477 :Be名無しさん:04/03/16 12:04
Microsoftとの提携効果ですね。>trutypeフォント生成
Windows の外字交換標準の問題点もこれを換骨してMicrosoftが
使うんじゃない

478 :Be名無しさん:04/04/16 10:06
GB18030のTRONコードの割り当てってどうなってるの?
今書体が実装されてるのは634文字だけだけど
コードポイントの割り当てはあるんでしょ?

479 :478:04/04/21 12:13
コード割り当てハケーン
http://www.chokanji.com/download/ck4_100.html
なんか明らかに説明がバグってるんですけど
しかもTRON文字収録センターのほうには割り当てが
書かれてないってどうよ
http://www2.tron.org/repertoire.html

138 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)