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

1 ：02/08/05 〜 最終レス ：8)

表題通りのことを語るスレです。

2 ：

（・∀・）ｽｰﾝｽｰﾝｽｰﾝ♪
(ﾟдﾟ)ﾊｯ!
（・∀・）ｽｰﾝｽｰﾝｽｰﾝ♪
(´Д`)ｲｪｧｽｰﾝｽｰﾝｽｰﾝｽｰﾝ
（・∀・）ｽｰﾝｽｰﾝｽｰﾝ♪
(´Д`)ｲｪｲｪｲｪｧ
（・∀・）ｽｰﾝｽｰﾝｽｰﾝ♪
(´Д`)ｲｪｧｲｪｧｲｪｧｲｪｧｽｰﾝ
(ﾟдﾟ)ﾔ!　
（・∀・）ｽｰﾝｽｰﾝｽｰﾝ♪
(ﾟдﾟ)ﾔ!　
（・∀・）ｽｰﾝｽｰﾝｽｰﾝ♪
(´Д`)ｲｪｧﾓﾝﾓﾝ
(ﾟдﾟ)ﾔ!　
（・∀・）ｽｰﾝｽｰﾝｽｰﾝ♪
(´Д`)ｼｹﾀｼｹﾀ
(ﾟдﾟ)ﾔ!　
（・∀・）ｽｰﾝｽｰﾝｽｰﾝ♪
（・∀・）ｽｰﾝｽｰﾝｽｰﾝ♪
（・∀・）ｲｪｰｱ!
（・∀・）ｽｰﾝｽｰﾝｽｰﾝ♪
（・∀・）ｲｪｰｱ!　
(´Д`)ｽﾝﾍﾞｽﾝﾍﾞｿﾝｽﾝｽﾝﾊﾞ
（・∀・）ｽｰﾝｽｰﾝｽｰﾝ♪
(ﾟдﾟ)ﾌﾞﾍﾞﾗ!
(´Д`)ｽｰﾝｽｰﾝｽｰﾝ

3 ：

バカが建てたスレはやっぱりバカっぽい。

4 ：

UNKO

5 ：

>自動車と同じに考えるところが頭悪いなVHSとベータで考えてみろよ。
両方とも、もう終わっているよ。(藁

6 ：

ZOOMをスーンと聞き違えた馬鹿の作った文章をコピペする
奴が2で居るスレは終わりだろ。
まぁ、1の時点で終わってるが。

7 ：

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 ：

>>6
バカか。

9 ：

つーか、
www.iana.org/assignments/character-sets
に登録されてない、charsetは。。。

10 ：

http://cocoa.2ch.net/linux/kako/1003/10031/1003159137.html
の53も興味深い。
53 名前： login:Penguin 投稿日： 01/10/17 00:30 ID:YQKlNfNV
>>38
TRONコードは、誰かが新しい文字が必要だと思い、申請したら、
例え点を一個追加するだけでも、それは追加される。だから、
> なら別々にして必要に応じて変換ライブラリーみたいなの使えばいいと思うぞ。
は、日々変化する。それは「いい」か？
文字の同定の基準が存在し、かつ無闇に文字集合が変動しない、
という取り決めがなかったら、大変だぞ。
> これは運用の問題だろ？
> 斎藤と斉藤と齋藤を区別したいときもあれば同じに扱いたい時もある。
文字集合が固定されている環境でのみ、その要求は満たされる。
新しい「齊」や「藤」が次々に生まれる環境では、それらを「同じに扱」うことは、
原理的には可能だが、現実問題としては難しい。

11 ：

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

12 ：

トロ吉の反論待ちage

13 ：

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

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

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

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

14 ：

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

15 ：

＞どうするよ、第3、第4水準漢字を?

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

16 ：

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

17 ：

>15 UNICODEに? それだとTRONを笑えんが。

18 ：

>>17
もちろんUnicodeに入っているんだが、
「それだとTRONを笑えん」ってのはどういう意味？

19 ：

UnicodeもTRONコード同様に文字同定の問題を避けている証拠になるから？
（補助漢字と第3、第4水準漢字は収録してる文字に重複がある）

20 ：

Unicodeへの第3〜4水準の漢字追加って既に
収録された漢字と重複してる分は取り除いてな
かったっけ？

21 ：

追加した際、同定基準についてどうしたかが一番知りたい。芝野氏、補助漢字を徹底的に批判してたし。

22 ：

>>16
TRONコードの「思想」かどうかは知らないのですが、現状ですね。

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

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

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

23 ：

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

24 ：

>>21
JIS X 0213の包摂規準で同定し、
補助漢字その他との重複を排除した上で追加申請、と思われ。

25 ：

>24
そうなのか。
文字追加の際、JIS X 0213の基準では補助漢字部分で入れられない物もあるんじゃねーのとか思っていたが、俺の思い違いだったか。
補助漢字以外にもすでに追加されていたし、実際に不可能だと思ってたよ。
ところで、実装された奴って組み込み用の奴?

26 ：

Mac OS Xのことじゃねーの？＞実装

27 ：

>>22
JISは「字形の統合」なんて言ってないだろ。

28 ：

Mac OS Xは違うよ。あれはUNICODEの対応バージョン出すとき問題出るね。

29 ：

>>28
悪いけど意味判らん。

30 ：

おれの間違った認識による書き込み。すまん、Macを愛する方々。

31 ：

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

32 ：

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

33 ：

97 でデザイン差である、と強弁・詭弁を弄して、
「包摂」しちゃった、ってほうか？　はしご高とか。

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

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

34 ：

>>33
脳内で話を作らんように。
97JISは口高と梯子高の違いを「字体差」とした上で
包摂していると思われ。

35 ：

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

36 ：

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

37 ：

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

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

>>38
GB18030ってことは、
Surrogateもオッケーってことっすね。

40 ：

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

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

41 ：

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

>>40
> Mac OS Xでは補助漢字にだけある文字はサポートしていない、っていうのはいまでも?
Unicode3.2をサポートしてるので、
その範囲内ならいくらでもどーぞ。
> はしご高はバリアントで表現してるよね?
variant tagを使って表現ってことか？
違う。はしご高はU+9AD9に入ってる。
ちなみに、OSXについてくるヒラギノフォントを使えば、はしご高は表示可能だよ。
さらにSurrogate文字もちびちび、このフォントには入ってる。
例えば、U+29EBDとかも表示できる。

43 ：

>>41
WWWでしっかりアピールしてんじゃん。

44 ：

>>43
Uniscribeとくらべるとなあ。。。
盛り上げぶりが違うと思う。

45 ：

おー、答えてくれてありがとう。
で、ATSUIのページを見てきたけど、違うみたい。
uniscribeって、リガチャーとかカーニングとかいうやつで使う奴ではないですか?(これをサポートしてないようでは多言語なんて言えないね>超漢字)
質問がわかりづらかったと思うんで、例を上げて説明すると
ある文字の異体字フォントを作った。で、このフォントを使うとき、この文字以外はヒラギノで表示するようにする、みたいな感じです。
(Windowsだとアルファベットしか含まないフォントを漢字にも適用すると、漢字部分はトウフになるけど、Macはどう?こっちのほうがわかりやすい?〉
補助漢字はサポートし始めたんですか。ん〜、じゃあ、Mac OS Xの最初のバージョンで入れていなかったってのはなんでだったんだろう。(これも、俺の記憶違い?〉
はしご高をvariant tag〈こう書くのか、これも知らなかった）使わないのも意外。だいぶ昔、unicodeが言語指定をもたなかったころ、あれは中国の文字のためのコードだから日本語では使えない、とか聞いていたんだけど。
ちなみに、U+29EBDはBBBでは表示できなかったんで、なんの文字かわかりませんでした。(ゲタが4つも表示されたが、アレはなんだったんだろう?)

46 ：

>>45
できるみたいだよ。
例えばOmniWebだと、
デフォルトではLucida Grandeっていう欧文フォント使うようになってるけど、
漢字とかの表示には勝手にヒラギノが使われたりしてる。
どうでもいいことだけど、Lucida Grandeにεがあるのはいいんだけど、
これの字体が気に入らないんだよねぇ。

47 ：

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

>>45
ちゅーか、Unicodeがらみの話をするなら
www.unicode.orgを見るように。
http://www.unicode.org/charts/
にすべての文字がある。で、
http://www.unicode.org/charts/PDF/U2F800.pdf
を見れば、そのglyphがわかる。

49 ：

＞補助漢字はサポートし始めたんですか。
Mac OS Xに付属するヒラギノについて言えば、
補助漢字のすべてを含むわけではない。
ただ、JIS X 0213に含まれない補助漢字であっても
Adobe-Japan1-4などを経由して入っている場合もある。
それから>>42の言うとおりOSの枠組みとしては
Unicode 3.2をサポートしているので、
すべての補助漢字を表示できるかどうかはフォント次第。

50 ：

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

結局ﾄﾛﾘﾝは糞ってこと?

52 ：

＞はしご高を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 ：

http://kado7.ug.to/net/

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

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

54 ：

ヒョデーイ！！！
http://2style.net/maido/R3_temp.swf?inputStr=%83q%83%87%83f%81%5B%83C%81I%81I%81I%81I
＃音量ＯＮにして飛んでね（・∀・）ｲｲ！
参考スレッド 森恒二ホーリーランド拳闘暗黒伝セスタス技来静也4
http://comic.2ch.net/test/read.cgi/comic/1025843878/551-611

55 ：

TRONを擁護する勇者はいないのか？

56 ：

煽られてもねぇ...

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

57 ：

non round-trip conversionの問題は有名だけど
それがどうして52へのレスになってるのかわからん

58 ：

おっと出遅れた。>>57に付け加えることはないな。

59 ：

レス遅れてすいません。いろいろついてるなぁ。
>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 ：

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

61 ：

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

62 ：

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

63 ：

>>61-62
単に異体字（バリアント）をサポートしてるってことじゃねえの。

64 ：

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

65 ：

どんな用語を使おうと、多言語処理でやるべきことは変わらんだろ。
しかしTRONコードの「スクリプト層」は見事に死んだな。

66 ：

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 ：

がしゅつかもしれんが
０２１３には０２１２とダブっている文字もあればそうでない文字もある。
０２１３にはＵｎｉｃｏｄｅに入ってない文字もある。
ＢＴＲＯＮっていつになったらスクリプト層が実装されるんだ？

68 ：

つーか文字属層（重複した文字を同じ文字として扱う）も実装されてないぞ。

69 ：

66で出ていたリンク先を見てきました。まだ漢字用のは規定されていませんね。
しかし、実際にやるとなると統合漢字が問題となってくるような。
あれ、Mac OS XのOSレベルでの対応ってのはなんだったんだ。また俺の勘違いか?
ところで超漢字で実装されてるのはスクリプト層とフォント層なんですが。
文字層で逆転できるもんが出来るのか?(「死んだ」とかまで言われてるし)
それよりも現在作られ続けているスクリプト層だけで出来たデータは将来どうなる?

70 ：

>>67が言ってるのは、インド系文字のリガチャとかを表現する
（本来の意味での）スクリプト層のことだろ。

71 ：

Unicodeによるなんちゃって国際化ってのは簡単にできるけど問題が多すぎ。
それに気づかないLinuxやXFree86は馬鹿。

72 ：

問題は少ないかもしれんが簡単にはできない
本格的国際化とやらが実現する日を夢見て
国際化を見送り続けるよりはずっと現実的。

73 ：

>>72
そしてどんどんドツボにハマっていく罠・・

74 ：

ずっと絵に描いた餅を愛でていれば確かに
ドツボに嵌る機会すらないね。
何も得られないけど。

75 ：

>>74
そうはいうが、
Unicodeは、Shift_JISよりは、かなり良いわけだよね。
それでも不満なやつは、今のOSに関して、どれもだめなわけだよな。
ちなみに、BBBはSurrogateにも対応してない罠。

76 ：

>>71は国際化と多言語化の違いも分かっていない罠。

77 ：

>>75
Unicodeは、最初の策定時に既に広まっていた
各国の文字セットを集めた交換用のテーブルと
しては十分な出来ですもんね。
ただ、漢字圏について言えば中国のGB18030が
素晴らしいので、ちょっと混乱しそうですね。

78 ：

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

79 ：

Unicodeの漢字領域は日本人が中心となって中国
韓国各々の代表者と綿密に検討して作り上げた
事実を知らない奴ﾊｹｰﾝ

80 ：

てめぇらみたいなガキはどせヒマだろ？だったらこっちゃ来い (
夢を見ている人たち
夢を見れない人たち
夢破れた人たち
夢を叶えた人たち
夢を追いかけてる人たち
夢を諦めた人たち
そして
全ての馬鹿たちに送ります
『一炊の夢』
http://www.geocities.co.jp/Hollywood-Screen/9038/

81 ：

>>79
なるほど。そいつらがｱﾒﾘｶﾏﾝｾｰだった訳ですね

82 ：

>>69
確かにスクリプト層自体は実装されている。
インド系の文字あたりを例として問題を列挙すると……。
・スクリプト層に必要なグリフが実装されていない。
・ていうか、それ以前に必要なグリフが仕様化されていない。
・グリフ置換機構が実装されていない。
・ていうか、置換機構が仕様化されてもいない。
・ていうか、その前提となる文字属層の中身が仕様化されていない。
・ていうか、文字属層の仕様化は目途すら立ってないと思われ。

83 ：

>>77
GB 18030が素晴らしいかあ？
「TRONと比べれば」ってのはナシだぞ。

84 ：

>>83
Shift_JISと比べれば。

85 ：

結局 ﾄﾛﾘﾝ は糞ってことでいいですかぁー?

86 ：

>>85
お前は放置されている事にいいかげんに気づけ（ｗ

87 ：

>>83
TRONと比べてもUnicodeと比べても文字鏡と比べても
漢字圏にとっては素晴らしいぞ。
何が素晴らしいって、主だったOSが既に対応可能に
なっているから。しかも、フォント依存ではなく。

88 ：

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

89 ：

>>87
拡張性で言えば、すばらしいのかもしれないけど、
Unicode3.1（正しい？）プラスアルファでしょ？
だからたいしてUnicodeとかわらん気がするんだが。
もちろん異体字においてはUnicodeと同じ問題があるわけで。
ちなみにWinはネイティブキャラクタセットとしては
GB18030はサポートしてないよ。（MacOS Xも）
だから、NotePadとかでGB18030でセーブすることはできない。
UTF-16で、GB18030の文字は扱えると言っているだけ。

90 ：

Winはサポートしてるぞ(藁

91 ：

>>87
比較の対象がよくわからんのだが、
GB 18030って、文字セットとしては
（収録のタイミングが多少ずれることはあっても）
Unicodeと一緒だろ。
>>89
異体字におけるUnicodeと同じ問題って何だ？
骨がどうとかってやつか？

92 ：

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

93 ：

>>91
基本的にGB18030は、Unicodeコンパチだから、
ハンのエリアは、unifiedされてるってこと。

94 ：

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

95 ：

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

96 ：

★超オススメサイト★
ここをクリック！！！
↓↓
http://www.bea.hi-ho.ne.jp/paisen/

97 ：

>>95
WinでいうGB18030対応ってのは、
UTF-16の中にGB18030の文字が入ってるから、
Unicodeアプリであれば、GB18030の文字が扱えますよってことだけ。
つーか、Win2000はオプションなんてないよ。
あるのは、
www.microsoft.com/china/windows2000/downloads/18030.asp
のパッケージを入れるだけ。
そうするとフォントとUnicode - GB18030ファイルの変換ツール、
変換テーブルなんかが入る。

98 ：

>>97
地域と言語のオプションでちゃんと選択できるぞ。

99 ：

>>98
ん？どこだ？
中国語とかは選択できるが、GB18030って選択できないぞ。
俺は、>>97のモジュールはWin2000に入れててあるが。

100 ：

例えばさ、
キャラクタコード表で、宗体-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 ：

>>100
Win2000の場合ね。

102 ：

>>99
中国語だ？簡体字(GB18030)ってのがあるだろ。

103 ：

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

104 ：

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

105 ：

>>103
バカだ(藁
変換テーブルがあるってことは、使えるってことだろ？
小学生でもそのくらいわかるぞ。

106 ：

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

>>105
ネイティブがわかってないんでねーの？
メモ帳だとShift JISはセーブできるけど、
GB18030のキャラクタセットではセーブできん。
セーブしたければ、Unicodeでセーブするしかない。
つまり、Winの拡大解釈で行くと、
Unicodeで、UTF-16 Surrogateまでサポートすれば、
自動的にGB18030サポートってことになる。なんだかなあー。

108 ：

WindowsがGB18030をサポートしているかという
話題を「ネイティブ」サポートしてるかという話に
勝手に摩り替えているバカはここにいるのですか？

109 ：

ああ、メモ帳は確かにサポートしてないかもね(藁
メモ帳がWindowsだと思ってんの？

110 ：

UTF16とGB18030の変換テーブルが搭載されれば、
アプリケーションがGB18030で保存する機能を搭載
するだけで対応完了。

111 ：

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

112 ：

話題になるのはUnicodeやGBばかり
TRONコードはいずこへ

113 ：

>>108
>>83 >>87 >>89
と話がきてるから、Winは、ネイティブサポートしてないってのは
話しの流れからしてあってると思うぞ。

114 ：

>>108-110
それじゃあ、GB18030のキャラクタを含んでる、
WinのUTF-16サポートは、すばらしいねって言うべきだろ？
> アプリケーションがGB18030で保存する機能を搭載
> するだけで対応完了。
それだけじゃだめ。
Win32のUnicode APIに全部置き換えなくちゃ。
メッセージもすべてUnicodeで書き換えなくちゃだめなんす。
つーか、Win32で、Native API、Unicode APIがあるってこと
わかってないだろ、きみ。

115 ：

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

116 ：

>>110
それじゃあ、ICU使ったほうが良いということで。
oss.software.ibm.com/developerworks/opensource/icu/project/

117 ：

>>114
病気ですか？
自分以外はUnicodeAPIを知らないと何を根拠に騒いでいるの？

118 ：

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

119 ：

>>117
つーか、病気は、うぃんちゅうじゃねーか？
>>92に反応しただけで、スレちゃんと読んでねえし、
特に>>95あたり適当なこと言って、反論されて、
虫のいどころがつかねえから、最後まで怒ってる。
話を戻そうぜ。>>87に戻るけどさGB18030はTRONコードの代理にならんよ。
GB18030はUnicodeの定義されてる文字を参考にして作ったという感じがする。

120 ：

WinはGB18030に対応してないと言い張る病気の人はまだいるの？(藁

121 ：

>>115
printfってWinのAPIには無いぞ(藁
対応してないのは君の使ってるライブラリだよ(藁

122 ：

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

123 ：

>>122
TextOut使えばちゃんとGB18030で表示できるぞ。
対応してないのはお前だよ(藁

124 ：

>>122
きみ、苦しすぎ（ｗ

125 ：

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

126 ：

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

127 ：

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

>>125
はあ？？できないっつーの。
ネイティブキャラクタセットがGBKなんだから。
>>126
> それと、勘違いがあるようなので言っておくが、printfを実装しているのは、
> Winではなく、コンパイラのライブラリ。
なんだよそれ。
printfは、Winのmsvcrt.dllに含まれてるよ。
もちろんprintfはstaticリンクもできるけどね。
それとほとんどのWin32 APIはdllへのコールだ。何が違うんだ？

129 ：

>>125
ワラタ。

130 ：

で、
Winのネイティブキャラクタセットは、
Windows2000以降はオプションでGB18030対応しますよ
と言い張る病気の人はまだいるの？(藁

131 ：

つーか、Win2000以降で、GB18030みたいに、
Shift JISのネイティブサポートなかったら、激怒だよ。
よく中国は納得したと思う。

132 ：

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

133 ：

>>132
>>127ですが、どこがまちがってるなら、指摘してくれ。

134 ：

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

135 ：

WinのシステムキャラクタセットはGB18030をサポートしません。

136 ：

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

137 ：

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

138 ：

まだ言ってるのか(藁
メモ帳とWindowsの違いはわかったのか？

139 ：

TextOutがマクロだってことなどが誰でも知ってることで、
メモ帳とprintfでサポートされることがネイティブサポートだという主張が大きな間違い。
その他、突っ込みどころは満載だが、基本的なところからいちいち小学生に説明するのは
時間がかかるので、適当な入門書でも読んでくれ。
WindowsがGB18030対応しているのは、明らかな事実。
それを対応してないと苦しい言い訳をしてるところが恥ずかしい。

140 ：

>>139
じゃあ、TextOutにGB18030のEncodingの4バイト文字を
直接わたせるってのか？
そんなのはMSDNにも書いてないよ。(w

141 ：

>>137
なんかややこしいことになってるが、
・システムレベルで変換ルーチンを持っている
・すべての文字を表示できる（こっちはオプション）
を満たせばGB 18030をサポートしていると言っていいんじゃねーの。
内部コードとして何を使おうが勝手だろ。
Windows XP/2000、Mac OS 10.2はこの条件を満たしているが、
超漢字4はどちらの条件も満たしていない。

142 ：

>>139
> それを対応してないと苦しい言い訳をしてるところが恥ずかしい。
だいたい、その拡大解釈じゃあ、
TRONコードだってUnicodeや、GB18030対応してるよ。
ネイティブキャラクタセット(システムロケール）としては
GB18030は対応してないと言ってるだけだ。
コマンドプロンプトも対応してない。
MultiByteToWideCharと、WideCharToMultiByteはGB18030の
文字コードは入れられるが、(そりゃね。変換するからね)
それ以外のNative APIは,GB18030４バイトコードはだめ。
WM_GETTEXTは、GB18030４バイトコード入れられんし、
TextOut、SetWindowText、もろもろのWin32 APIに対しても、
GB18030の４バイトコードは直接入れられない。
Shift JISは直接入れられるけどね。

143 ：

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

144 ：

>>141
> 超漢字4はどちらの条件も満たしていない。
そうなのか?
超漢字4はGB18030の文字が
TRONコードを使っても表示できないのか？
WinはUTF-16を使えばできるが。

145 ：

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

146 ：

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

147 ：

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

148 ：

ところで>>139は>>125なのか？
>>125にはわらた。
GB18030がprintfで表示できないのは、
> printfで表示できないのはね、printf("...")ってやるからだよ。
> printf("%s", "...")ってやらなくちゃね。
> めっちゃ基本。
だって。ウケタ。。。

149 ：

え？マジで知らないの？
printfを使う時は基本だよ！

150 ：

msvcrt.dllって、VCのランタイムじゃん。
こういうのは、ライブラリの仕様って言うんじゃねーの？

151 ：

まあまあ、そう気張らずにこんなものでもいかが？
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 ：

つーか、Unicodeの統合漢字の2.0から入ってるやつさえ
表示できなかったりするし。＞超漢字4

153 ：

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

>>150
> msvcrt.dllって、VCのランタイムじゃん。
ワラタ。
printfは、msvcrt.dllにあるAPIで、
TextOutA/Wは、gdi32.dllにあるAPIだが、なにか？

155 ：

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

>>141
> ・システムレベルで変換ルーチンを持っている
> ・すべての文字を表示できる（こっちはオプション）
>
> を満たせばGB 18030をサポートしていると言っていいんじゃねーの。
> 内部コードとして何を使おうが勝手だろ。
その通り。それを満たせばサポートしていると言える。

157 ：

>>155
> 話してるのは、WinのGB18030サポートは、Shift JISサポートに比べると
> ださださ、おそまつだねーってことだと思うんだが。
ちがいますね。「サポートしている」という意見に
対して執拗に否定してかかる奴がいますからね。
> GB18030のネイティブキャラクタセットのサポートはされてないし、
「ネイティブキャラクタセットとしての」サポート云々は
話のスリカエですよね。

158 ：

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

159 ：

msvcrt.dllはVCのランタイムです(藁
http://www.vector.co.jp/soft/win95/util/se040499.html

160 ：

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

161 ：

勘違いがあるようなので言っておくが、printfを実装しているのは、
Winではなく、コンパイラのライブラリ。
それはライブラリの仕様であって、Winの仕様ではない。
msvcrt.dllは、その名の通り、MicroSoft Visual C Run Time.dllなわけ。
つまり、動的リンクできるVCのライブラリ。

162 ：

それと、ネイティブって言葉を何か勘違いしているようだが、
君の言ってる「ネイティブ」は、一般に「デフォルト」って言葉で表されてる
概念だと思うぞ。
Winは、GB18030をちゃんとサポートしている。
つまり、OSレベルでのサポートであるから、これを一般にネイティブサポートと言う。
そのうち、UIなどでデフォルトとして扱われるエンコーディングがもちろんあるわけだ。
これのことをネイティブって言ってるんじゃねーの？
これはあくまでデフォルトなわけだから、ちゃんとまじめに作られたアプリなら
デフォルトじゃない設定も使えるわけ。
なぜ君の作ったアプリで使えないのかというと、それは「君のアプリが」GB18030に対応してないってだけだよ。
Winじゃなくてね。
「ロケール」とか「国際化対応」って章をもっと良く読んでみることだね。

163 ：

それから、printfにリテラル文字列を渡す場合、%sを使うのは常識。
でないと、日本語でも、2バイト目に\や%が使われてる文字が不具合を起こす。
これは、printfの仕様、そしてライブラリの仕様であって、それによる
不具合はプログラマの責任。決してOSの責任じゃない。

164 ：

>>157
> ちがいますね。「サポートしている」という意見に
> 対して執拗に否定してかかる奴がいますからね。
> > GB18030のネイティブキャラクタセットのサポートはされてないし、
> 「ネイティブキャラクタセットとしての」サポート云々は
> 話のスリカエですよね。
つーか逆のような気がするが。
>>89の返答として、>>95になったのが変、
ネイティブキャラクタセット -> Win2000はサポートしてる。
にすりかえられたのが最初。ちゃんとスレを読むように。

165 ：

>>161
用は、
msvcrt.dllはWindowsの一部ではなく、
gdi32.dllはWindowsの一部だと言ってるのか？（わら

166 ：

>>160
あんたもばかだ。
> 1. TextOutにエンコーディングを指示するオプションを付ける
> 2. TextOut呼び出しの前にUNICODEに変換できるようAPIを用意する
> があるわけだが、Windowsはその2番目の方法を取った。
ShiftJISはどちらにもあてはまらんぞ。(w

167 ：

>>158
>『BTRONはShift_JISもUnicodeもサポートしていません。
>いずれも、その文字セットど同内容をTRONコードの
>各面内に含んでいるだけに過ぎず、ネイティブサポートは
>あくまでTRONコードだけだから』
それを言うならSJISじゃなくてJIS X 0208だろ。
それから超漢字4は、
Unicodeについては「文字セット」としてもサポートしてないぞ。
超漢字2なら（文字鏡が入っていれば）
Unicode 2.0まではカバーしてたんだけどね。

168 ：

>>158
> 或いはネイティブキャラクタセットとしてのサポートに
> 拘るのも面白いかも。
あのー、その話をしてたら、
Win2000は、GB18030サポートしてるぞって、わけわからん話が
とんできたんですが。。。
あんたの意味での、
BTRONはGB18030サポートすればって話してたら、
ISCIIサポートすれば、ISO-2022-JPサポートすれば、
でCharset一通り言って、このスレおしまいになっちゃうよ。(W

169 ：

>>164
なぜ君は>>89が発端だと言い張るのだ？
最初の>>87に対する君の>>89がズレてるのだと思うが。

170 ：

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

171 ：

>>169
いいんじゃないの？それはそれで間違ってないんだから。
むしろ、そのあとで、それを勘違いして、
WinはGB18030をサポートしているとの主張がいたいと思うんだが。

172 ：

おっと、
>>171はWinはGB18030のサポートをしていないと
言ってるんではないからね。

173 ：

>>166
一つのデフォルト言語に対して特別な処置をとれば処理が単純になるという、それだけの話。
ショートカットのような物。

174 ：

まだネイティブでサポートしてないと騒いでる奴がいるのか(藁
恥の上塗り(藁

175 ：

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

176 ：

>>167
まじでさ、超漢字にICUをポーティングするってのはどう？
そうすりゃあっというまに、
超漢字もXXXサポートしてますって言えると思うんだが。

177 ：

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

178 ：

>>174
> まだネイティブでサポートしてないと騒いでる奴がいるのか(藁
話ぼかすのうまいね。
ネイティブで何をサポートしてないと騒いでるというのだ？

179 ：

>>174の(藁は、やつか？
WinがGB18030サポートしてるってずっと
スレ違いなこと言ってるのは。

180 ：

>>173
わら

181 ：

ところで、utf2000ってどうなった？

182 ：

>>181
最新版は0.19かな。
あれはなんつーか、別世界の話だわな。

183 ：

UTF2000か、TRONコードと比べてどうよ？
emacsの実装してるとか聞いたが。

184 ：

>>178
話ぼかすの下手だね。
Winとメモ帳の区別はつくようになったか？
開発言語のライブラリのAPIとWinAPIの区別はどうだ？

185 ：

WindowsはGB18030に対応してないと言い張る
↓
ボロボロに論破される
↓
そんなこと言ってないと言い張る
↓
ぷぷぷ

186 ：

>>164
> つーか逆のような気がするが。
> >>89の返答として、>>95になったのが変、
なんで話の途中を起点であるかの様に摩り替えるの？
89は87に対する返答でしょ。
>>87
>主だったOSが既に対応可能になっているから。
> しかも、フォント依存ではなく。
どこにネイティブサポートだって書いてあるのさ？

187 ：

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

188 ：

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

189 ：

なんというか、超漢字は、ふざけてるよなあ。
トンパ文字パックが３万近くしているのは、驚いた。

190 ：

WindowsはGB18030ネイティブでWin32 APIを呼べると言い張る
↓
自分の意見がぽろぽろ変わっていく。
↓
最後の牙城は、WinはGB18030サポートしてないと言ったろと主張するだけ
↓
ボロボロに論破される。
↓
Win32 APIでもできるよというが、ソースコードも提示できない。
↓
ぷぷぷ

191 ：

>>185-186
まだ、WinはGB18030サポートしたのしないの話したいのか？おめーは？
つーか、なにをそんなにWinをかばってんだ？うぃん厨君。
WinのGB18030サポートのダサさに話題を移しまいと必死ですな。

192 ：

なんでこの程度で論破とか平気で書けちゃうんだろ。
これのほうがぷぷぷだと思うなあ。
まあ俺は野次馬なわけだが。

193 ：

>>191
まあ、うぃんちゅーはそんなもんだろ。藁

194 ：

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

195 ：

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

196 ：

>>192
> まあ俺は野次馬なわけだが。
あんた張本人のうぃなちゅうだろ。

197 ：

>>195
バカですか？
誰一人として、『Windowsの内部コードはGB18030だ』
なんて書いていないのですが。
争点は、内部コードであるUnicodeとの変換テーブル内蔵
するのが『サポートといえるか』でしょう。
『内部コードとして採用していないからサポートと言えない』
という論点でカキコしている奴がバカなんですよ。
え、そんなこといっていない。ダサいかどうかを論じている
ですって？
それじゃ、そもそもなんで>>87にくってかかってきた
んですか？

198 ：

なんだ、まだ頑張ってるのか(藁

199 ：

>>197
Win2000/XPはGB18030をサポートしていると言える。
なぜかっていうと、MicrosoftがMicrosoft.comで
サポートしてるって言ってるから。
はい。おしまい。さ、もーそー君は帰っていいよ。
あ、そのまえにprintfとTextOutAでGB18030の文字表示する
ソース出してってね。ちゃんと動作方法も書いといてね。
だれも>>87にくってかかってないから、
心配だったら、今日は帰って薬飲んで早めに寝た方ががいいよ。
WinのGB18030サポートはださいのはしょうがない。事実は事実なんだから。

200 ：

>>197
そうそう、Windowsの内部コードの話なんてだれもしてないから。
WinのAPIが受け付けるコードの話をしてるだけ。まあ、帰れって。

201 ：

printfはライブラリ依存だって書いたんだが、理解できなかったか？
用語がむずかちちゅぎまちたかね〜(藁

202 ：

それと、TextOutの前にUNICODEに変換する方法でサポートしてるとも
書いたんだが、幼い子にはちょっと無理だったかな(藁

203 ：

それと、まだmsvcrt.dllがVCのライブラリじゃないって思ってるの？(藁

204 ：

おまいらいい加減おちけつ

205 ：

　Windows2000はGB18030をサポートしている
という意見に噛み付いたあげく、論破されるや
　俺は最初から対応していると主張しているんだが？
といった態度に豹変して逃げをうってるバカが常駐
しているスレはここですか？

206 ：

>>201
> printfはライブラリ依存だって書いたんだが、理解できなかったか？
"%s"でやりゃできるって言ったじゃんかよ。

207 ：

>>202
それは、君の言う前にスレに出てる。
人の言ったことをそのまま繰り返してるおーむがえしくん。
「ぴーちゃん、おはよ。」「ぴーちゃん、おはよ。」みたいな。

208 ：

>>203
> それと、まだmsvcrt.dllがVCのライブラリじゃないって思ってるの？(藁
VCのライブラリかどうかなんでだれも話してないぞ。
Windowsのdllかどうかを話してる。

209 ：

>>205
> Windows2000はGB18030をサポートしている
> という意見に噛み付いたあげく、論破されるや
ひがいもうそう君なんだよな。
WinはGB18030サポートされてます。
-> でも、Shift_JISの他のキャラクタセットに比べてかなりの制限があるよ。
って話しってのが、これだけでてるのに、まだ見えない。
君を攻撃してるわけじゃないから、そんなにおびえるこたない。安心しな。

210 ：

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

211 ：

>>202
つーか、言われて、気が付いて、収拾つかなくなって、
WinはGB18030サポートしてないって言ってるやつがいると思ってる。。。
最初からいないのにね。
へんなものやっちゃったんじゃないか？
俺をねらってるやつがいる、俺をねらってるやつがいるって。

212 ：

>>209
そうそう。
流れとして、MultiByteToWideCharなんかの話がでてるんだが。
やつにはMultiByteToWideCharとかの話が理解不能だったらしい。
MultiByteToWideChar/WideCharToMultiByteがサポートしてるんだから、
WinはGB18030をサポートしてるって話をしてるのあたりまえだ。
まあ、もーそーくんだからしょうがないといえばそうなんだが。

213 ：

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

214 ：

んー、なんか単純に
　　８７に対して勘違いツッコミしてきた８９と、その８９に加勢した奴=バカ
　　８９とそれに加勢した奴をバカと言える奴=まとも
てことで結論でてると思うんだが。

215 ：

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

216 ：

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

217 ：

>>214
まあさ、>>87が>>89を読み違えて被害妄想をここまでひっぱってきてるってのが
正しいところだろうな。
>>89で
「UTF-16で、GB18030の文字は扱えると言っているだけ。」
ってのがなんで
「WinはGB18030サポートしてない」に変わるのかよくわからんと
思ったぞ。

218 ：

>>217
まあ、噛み付かれてると勘違いのもーそー君のことなんだから、
何言ってもしょうがないさ。
しかし、やつは、最後まで、
WinのGB18030サポートはださいと言えないのは、またまたイタイ。

219 ：

>>213
なんで俺をいじめるんだよー。ってか？（わら

220 ：

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

221 ：

いやあ、会社にもこういうやついたよ。
「私が間違ってるっていうんですか！じゃあ何で私に噛み付いてくるんですか！」
って言い出すやつ。
課長が、なだめてるんだけど、会議でそいつずっと怒って、
そのあとの話だいなし、場はしらけるみたいな。

222 ：

>>221
そうそう！そういうの困るんだよね。
別にだれもそうじゃないって言ってないのに、そいつは怒りだして、
なんで俺がなだめなくちゃならないの？ってな雰囲気。

223 ：

「対応可能」という言葉が「サポートしている」という言葉に変わって、
そのサポートがださいのしょぼいのいう話に変わっているわけですね。
まるで伝言ゲームだなぁ。文字という手段を使っているのに情けない。

224 ：

>>206
できるとかできないって誰が書いたんだよ？
ライブラリ依存って書いてあるじゃんよ(藁
ライブラリ依存ってのはね、
「できる場合もあるしできない場合もある」って意味だぞ(藁
そこまで基本からわかんないと、時間かかるねぇ(藁

225 ：

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

226 ：

ほら、「その程度でサポートしてると言えるなら他のどのOSでもサポートしてる」
とか何とか言った奴がいただろ？(藁
それがお前じゃないなら黙ってろよ。
ムキになるからお前だってバレバレなんだけどね(藁

227 ：

>>223
>「対応可能」という言葉が「サポートしている」という言葉に変わって、
そう。具体的な例として、Win（Win2000/XPね）をあげたわけ。
だから別に君に噛み付いてないってことが、やっとわかったか？
被害もーそー君。
「サポートしている」というのは、MSが言っているから。

228 ：

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

229 ：

というわけで、とっととお帰り。頭ひやしたほうがいいぞー。

230 ：

>>227
ほらほら、意味わかんなくなってきたぞ(藁
拡大解釈ならサポートしてると言ってた君。
君の定義じゃサポートしてないんだよね？(藁
それが今度はサポートしてる派に変わったの？(藁
もし君が>>142じゃないなら、噛みつかれてるのは君じゃないから、
引っ込んでなさいな、被害妄想君(藁

231 ：

ついでに言うが、頭冷えてないのは君だけだぞ。
何で自分が噛みつかれてる気がしたの？(藁

232 ：

>>230
なんで意味わかんなくなってきたんだ？拡大解釈だってさ。ぷぷぷ。
MSがサポートしていると言ったらしてるわけよ。あんたが拡大解釈してんだよ。
GB18030はライブラリ依存ですだって。
printfはに含まれてるから表示できないだって。ぷぷぷ。
gdi32.dllはライブラリじゃないのか？
>>142以前にいろいろ変なこと言っといて、なんか>>142だけのネタを
昨日一生懸命考えてたんだね。ぷぷ。

233 ：

>>230
やっと、WinのGB18030対応はださいと、悟ったとたんに、
あとは、とことんテクニカルとは程遠い会話するようになったな。。。

234 ：

ちなみに
printfが「ライブラリ依存だから、」（この表現わけわからん）
GB18030表示「できる場合もあるしできない場合もある」は
まったくでたらめ。
GB18030がコマンドプロンプト上で表示できないのは、
MSがMSのサイトでそう言ってるから。

235 ：

つーことで、
printfでGB18030表示
できる場合をあげてもらおうや。

236 ：

>>95
> Windows2000以降はオプションでGB18030対応
> しますよ。
これって、>>230だろ。
ちなみにWin2000はGB18030のオプションはありません。
Win2000はオプションで対応してない。

237 ：

>>236
つーか、オプションないよ。APIで対応してる。

238 ：

だよな。
Win2000のコンパネの地域ところの設定は、
GB18030なんて何もない。

239 ：

>>235
> つーことで、
> printfでGB18030表示
> できる場合をあげてもらおうや。
特に、4バイトキャラクタ表示できる場合の例をあげてくれ。
よろしく。

240 ：

>>230
> もし君が>>142じゃないなら、噛みつかれてるのは君じゃないから、
> 引っ込んでなさいな、被害妄想君(藁
ちみは、その前からエンジン全開で噛み付いてるじゃん。w

241 ：

煽り合いには参加したくないんだけどさ、SJISやGBKってのは、
当時、内部コードとしてサポートするしかなかったわけだよな。
しかし、GB 18030は変換テーブルでサポートできる。
国際化された環境で、いまさら地域化なんてしたくないのは当然。
たとえばJIS X 0213はSJISを拡張する符号化を提案したが
受け入れられず、Unicode経由でサポートされることになった。
GB 18030（拡張GBK）のサポートはそれと同様の事例であって、
サポートが貧弱だとかってことじゃないだろ。
UNIX系のシステムがGB 18030を内部コードとして
サポートしているのは、もともとISO 2022的な発想が強く
Unicodeすら「文字セットのひとつ」ととらえる文化だからだと思うが、
WindowsやMacintoshはそうじゃなく、Unicodeによる国際化が基本。
いや、その方針に異議があるならそういう議論をしてもらっても
いいんだけどね、サポートが「ださい」とか連呼するばかりなのも
いかがなものかと。

242 ：

まだ続いてるのか(藁
サポートしてるわけねーだろ(藁

243 ：

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

244 ：

>>242
まだ言ってるのか(藁
サポートしてないわけねーだろ(藁

245 ：

>>239
UNICODEに直してからって繰り返し言ってんじゃん。
文盲？

246 ：

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

247 ：

>>243
> 文字列をUNICODEに直して表示するprintfだったら表示されるだろ？
だめなんだよね。
そもそもコマンドプロンプトがGB18030をサポートしてないから。

248 ：

>>243
ソースコードで、よろしく。

249 ：

というか、それ以前にフォントがあるのか？

250 ：

>>249
宗体(SinSum)-18030ってのがGB18030対応。
Surrogate文字は入ってないけどね。
Surrogate文字が入ってるのは、OfficeXP中文版についてる。

251 ：

とりあえず、それを使って、
printfでできたっていうのなら、ソースをくれ。

252 ：

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

>>252
> ユーザがファイルでGB18030を出力することが
入力もね。

254 ：

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

255 ：

変換の変換でバイナリ比較。。。
やる奴いる?

256 ：

>>226
> ほら、「その程度でサポートしてると言えるなら他のどのOSでもサポートしてる」
> とか何とか言った奴がいただろ？(藁
いたよねぇ。(w
しかし、その程度でサポートしていると言えても
超漢字はサポートしているといえない罠。

257 ：

>>252
>中国としては、これから、GB18030をGBKのようにレガシーEncodingとして使っていきたいんだが、
>と、中を開けてみれば、いろいろな制限があって、かつてのGBKのようには使えなくなってしまった。
中国がGB18030をGBKと同じ様なアプローチで
サポートして欲しい…というのは事実？それとも
キミの脳内ストーリー？
W2KのGB18030を中国サイドが承認したという事実は
無視？

258 ：

>>255
バイナリ比較ってのはUnicodeコレーションアルゴリズムじゃなくて、
単にstrcmpとか使ってる場合ってこと。

259 ：

>>251
いい加減、「ライブラリ依存」って言葉くらい調べろよ。
頭悪いにもほどがある。

260 ：

>>256
> 超漢字はサポートしているといえない罠。
そういえば、超漢字だか、BTRONだかの
中国向けパッケージって昔でなかったけ？
あれもGB18030対応できなかったのかな。。。

261 ：

>>259
「できる場合もあるしできない場合もある」
と言うから、わけわからなくなるんだよ。
だから、できる場合を見せてみろってことなんでないの？
ところで、MSが「ライブラリ依存」と言ってるのか？

262 ：

MSが言わなくてもライブラリ依存じゃねーか。
ライブラリの意味わかってるか？
そっから説明すんの？
面倒くせー

263 ：

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

264 ：

>>262
cygwinだとできんの？

265 ：

gcって何？

266 ：

ゲームキューブ

267 ：

で、最初に話してた、VCだと"%s"で、GB18030表示
できるのか？

268 ：

GB18030からUNICODEに変換して、コンソールのコードページをUNICODEに変更し、
printfを使えばいいだろうが。
変換してから使うのがWinの流儀だって、いったい何度言わせる気だ？

269 ：

で、Windowsのmsvcrt.dllだとどうなんだ？

270 ：

msvcrt.dllはVCのライブラリだって何度言わせる気だ？

271 ：

バカは100回聞いてもわかりません。

272 ：

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

273 ：

msvcrt.dllはWindowsのライブラリじゃないのか？
なんでこれには答えんの？

274 ：

>>272
じゃあ、user32.dllはWindowsのライブラリじゃないのか？

275 ：

>>272
msvcrt.dllはソースがくばられてるんだから、
GB18030に対応してるか言えるんでないの？

276 ：

じゃあ、対応してるか言ってもらおう。
その前に、gcって何？

277 ：

>>272
じゃあ、WIndowsってどこからどこまでを言うんだ？
Windowsのretail版を買えばついてくるdllがすべて
Windowsの一部ではないのか？

278 ：

>>87の噛み付き野郎は、朝早く来て、そして２時間噛み付き、
そして帰って行く。。。

279 ：

>>278
２時間なんてもんじゃねーよ。w

280 ：

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

281 ：

もちろん、広義ではmsvcrt.dllもソニーの添付ソフトもWindowsの一部と
言って言えないことはないわけだが、ここで話してるのは、Windowsが
ネイティブにGB18030をサポートしてるかどうかって話だ。
だから、ソニーのソフトがサポートしてなくても、それすなわち
Windowsがサポートしてないことにはならない。ここまではわかるね？
同様に、VCがサポートしてなくても、それすなわちWindowsが
サポートしてないことにはならないわけだよ。
で、msvcrt.dllってのは、VCというれっきとした別商品の一部を、
同じ会社だってことで同梱してるだけ。
user32.dllはWindowsの一部として配布、msvcrt.dllはWindowsに同梱、
この違いもバカには難しいかな？
msvcrt.dllの中のprintfは、GB18030をサポートしてないが、
それはWindowsがサポートしてない根拠には全くならない。
わかるかな？
まだわかんない？
バカだね〜(藁

282 ：

噛み付き野郎が、もどってきた。。。

283 ：

>>281
やっと言ったよ。サポートしてないって。w

284 ：

なんか飽きたな

285 ：

>>281
噛みつき野郎、
じゃあ、次は、コマンドプロンプトだ。
コマンドプロンプトはGB18030をサポートしてるか？

286 ：

>>246
> だから、Win9xをサポートしてきたアプリベンダは、
> まず、Unicode化しなくちゃならないという、けっこう大変なことがまってる。
> ただし、LinuxやAIXやSolarisなんかは、GB18030でAPIを呼べるわけで、
> それからみればそういう不満がでるのは当然だと思うぞ。
そりゃ不満を持つベンダもいるだろうが、
だからといってベタな地域化をいつまでも続けるのもマヌケじゃねえ？
WindowsやMacintoshのGB 18030サポートが貧弱なんじゃなく、
国際化されていないアプリケーションが貧弱なんだと言ってはダメか？
だいたいがGB 18030自体、奇襲攻撃みたいな符号化なんだし。

287 ：

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

288 ：

>>254
> Unicodeの中で、GB18030を扱おうと言った場合、
> 一番の問題は、変換でのラウンドトリップの問題だよね。
ん？　UnicodeとGB 18030の間には
ラウンドトリップコンバージョンが成立していたと思うんだが。
問題があるなら具体例きぼんぬ。

289 ：

>>287
Win32 APIのA関数でUTF-8使えたらもっときれいに行ってたのにとは思う。

290 ：

>>283
VCがな(藁
Windowsじゃなくてな(藁
字が読める？

291 ：

>>285
してる。
コンソールのコードページを変更してみろ。

292 ：

WindowsとVCとメモ帳の区別くらい付けた方がいいぞ(藁

293 ：

まだWinがGB18030をサポートしてないと思ってる奴がいるのか？

294 ：

>>281

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

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

295 ：

>>293

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

296 ：

>>291
MSのサイトに、
GB18030はコマンドシェルをサポートしますか？いいえ。
と書かれているが、これはいつから変わったんだ？

297 ：

>>286
> だからといってベタな地域化をいつまでも続けるのもマヌケじゃねえ？
> WindowsやMacintoshのGB 18030サポートが貧弱なんじゃなく、
> 国際化されていないアプリケーションが貧弱なんだと言ってはダメか？
Unicodeを使うというのは良いが、UTF-16を使ったのがだめ。
だって、UTF-16と、既存のGB18030やShiftJISのcharsetサポートの違いがありすぎる。
WinはUTF-16とその他のcharsetと別のAPIに分けてしまった。
だからアプリ作る側が移行時とかWin9xのサポートに困る。
Unixのように、UTF-8としてUnicodeをサポートするほうが移行しやすい。

298 ：

要は、あるプリンタをサポートするとして
このプリンタは漢字フォントが乗ってないので
イメージ展開しないと印刷されません
でも従来の漢字コード出力を自動的に展開するような
エミュレーションドライバは提供しませんので
従来のソフトでは漢字が印刷できません。
漢字を印刷したい時は画面のハードコピーをとってください。
みたいな状態で本当にサポートがあるって言えるのかよ
って話なのかな？

299 ：

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

300 ：

>>298
何か全然違うような。

301 ：

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

302 ：

>>299
コマンドプロンプトでは、
VCのprintfでは、GB18030表示できないが、
gcのライブラリを使えば、GB18030がそのままprintfで表示できる。
なんて、MSでも言ってないことを、ぐたぐた言ってるからだよ。藁
で、gcって何よ？

303 ：

画面をハードコピーした瞬間、それは文字じゃなくて画像だ。
画像にGB18030もShift_JISもあるか、バカ。
幼稚園レベルの疑問を何個も何個も書くんじゃないよ。
話をごまかそうとしてるんだろうが、何書いても知能の低さが
表れるだけだぞ(藁

304 ：

>>302
gc知らないなんてネタだろ？
VCに対応するgcつったら一つしかねーじゃねーか。
今度はVCって何よ？って言うんじゃねーだろうな？

305 ：

それに、MSが「サードパーティのライブラリを使えばできます」なんて言うわけないだろ。
ライブラリって知ってますか？
知らないなら調べて下さいね。
手間がかかるからもう言わせないで下さいね。

306 ：

>>301
イメージ化までプリンタドライバがしてくれるなら、対応してると言える。
が、「ハードコピー取って下さい」と注意書きのあるプリンタは、
イメージ化を別の手段で取る必要があると見られる。
そういうプリンタは対応しているとは言えない。
Windowsの場合は、GB18030をUNICODEに変換するAPIがちゃんと用意されていて、
まともなプログラマはそれを使うから、立派に対応している。

307 ：

しかし、画像しか印刷できないプリンタが文字に対応してると考える奴がいるとは
思わなかった。バカにも程がある。

308 ：

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

309 ：

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

310 ：

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

311 ：

面白い人だなあ
誰もそんなことは言ってないのに。
ハードコピー取ってくださいというのは
そのソフトが対応してないだけでしょ？
GB18030の話は良くわからないけど変換しなきゃいけないなら、
イメージに変換するそのプリンタと同じだと思うよ。
つまり、そのシステムはサポートしてるってことでしょ？
同意見なのになんで電波とか言われなければいけないんだろう？

312 ：

>>304
gcは知らんが、gccなら知ってるが。

313 ：

>>310
ついでに言えば、コマンドプロンプトがGB18030に対応してると認識してる電波も
お前だけだよ。
MSでもnoって言ってるのにね。

314 ：

glibcなら通じるが、gcといったらGNU-Cではなくガベージコレクタとかを想像する。
それともVisualC++用の「gc」っていうライブラリがあるの？
詳細情報希望。

315 ：

>>305
> それに、MSが「サードパーティのライブラリを使えばできます」なんて言うわけないだろ。
gcのprintfは、コマンドプロンプトでGB18030の文字をネイティブで
表示できるって言ってるのか？
ふーん。そう言ってるgcリリースしてるベンダのURL
とりあえずリンク教えて。
で、gcってどこぞのgcかわからんからそれもURL教えて。

316 ：

msvcrt.dllでも、mbstowcsとwprintf辺りでいけそう。
ロケール周りでCPを直接指定する方法は無かったかな？

317 ：

gccはコンパイラだぞ(藁
gcのライブラリでどうしてガベージコレクタなんだよ(藁
http://www.google.co.jp/search?sourceid=navclient&hl=ja&q=glibc+GB18030
>>311
どうしてシステムで対応してたらプリンタが対応したことになるのかね？(藁
Windowsが対応してるのは自明。
プリンタが対応してないのも自明。
だから、Windowsは対応して無くてプリンタが対応してると言い張るお前が電波。
>>313
勝手な話を作るな。俺は終始、UNICODEで対応と言ってる。

318 ：

>>317
それ、ベンダのリンクじゃないじゃん。

319 ：

>>317
＞どうしてシステムで対応してたらプリンタが対応したことになるのかね？(藁
それは印刷できるからに決まってるでしょ？
文字はイメージとしてね。
CRTにはフォント入ってないけどシステムが持っていれば問題ないわけだし
＞だから、Windowsは対応して無くてプリンタが対応してると言い張るお前が電波
なんか混信してませんか？

320 ：

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

321 ：

>>317
UNICODEじゃなくて、Unicodeなんだが。。。

322 ：

「gcのライブラリ」という言葉でBoehm GCとかを連想しただけの話で、
glibcの事を言っているのか、内部でUNICODE変換してくれる「サードパーティのライブラリ」が存在しているという事なのか知りたかった。
UNICODEで対応しているという事は一人以外はわかっているのでは？

323 ：

>>317
つーか、gcとは具体的にどこぞのgcを指すのかな？
それで、そのgcのprintfはGB18030サポートしてるって言ってる
gcのベンダーはどこよ？

324 ：

>>317
GB18030をprintfで表示するだけなのに
Winは、すげー手間がいるんだな。藁

325 ：

>>320
いや、所詮、噛み付き野郎は、電波だからな。藁
リンクもないところ見ると、
やつがWinのGB18030サポート具合を適当に決めたいんだろうな。

326 ：

>>322
確かに。Open Sourceだと、LCUってのがあるが、
そんなUnicodeエンジン使って
内部でUnicodeで動いてる、libcってあんのか？
まじで、リンク教えろ。

327 ：

いつのまにか『UTF-16とGB18030を語るスレ』になって
しまっており、BTRON仕様OSも多言語もどこかに
逝ってしまったのが笑える。

328 ：

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 ：

ちゃんとGoogleの検索結果をリンクしてやったじゃねーか。
そっからいくらでも見つかるだろ？
見つからない？
バカだから？
しょうがねぇなぁ(藁

330 ：

( ´,_ゝ｀)ﾌﾟｯ…

331 ：

>>329
どうやら時間かけたわりには、やつは見つけられなかったらしい。
ワラタ。

332 ：

>>329
バカだから見つからないんで本当によろしく

333 ：

え、何？
マジで見つけられないの？
大丈夫か？
頭ついてるか？
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 ：

問題1 次の情報ソースを挙げよ
1. WindowsでGB18030が使えない
2. 画像しか印刷できないプリンタはGB18030に対応している
こんなこと本気で言ってる奴がいるんだからなぁ(藁

335 ：

あと、こんなことも言ってたよな(藁
3. printfでリテラル文字を表示するときには第一引数に書くべきである
4. msvcrt.dllはVCのランタイムではない
イタタタタ(藁

336 ：

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

337 ：

>>334-335
やっぱ、もーそーくんだったらしい。
何に対して反論されてるかもわかってない。
>>336
結局やつが言ってる、gcって何なんだろうね。

338 ：

>>335
つーかそんなこと言ってるやつはいたか？
1. コマンドシェルはGB18030サポートしています。
2. gcはGB18030サポートしています。
3. コマンドシェルではVCのprintfはGB18030表示できませんが、gcならOK
はいたけど。イタタタタ(藁

339 ：

>>336
紹介したglibcがWindows用でなくて悪かったね。
普通、応用できると思うからさぁ、つい君が並はずれたバカだってこと
忘れてたよ(藁
ま、でもこれでライブラリを換えることで、GB18030が使えたり使えなかったり
することは理解できただろ？
これを「ラ・イ・ブ・ラ・リ・依・存」って言うんだよ(藁
一つ勉強になったね(藁

340 ：

>>338
つーかそんなこと言ってるやつはいたか？
コンソールのコードページをUNICODEに直してUNICODEで表示しろとは言ったけどね。
日本語読めないのはさぞかし不便だろうね(藁
で、まだWindowsがGB18030サポートしてることが理解できないの？
何年くらいかかりそう？
もう飽きちゃったなぁ(藁

341 ：

>>338
つーか、うちのcygwin、コンパイルするときエラーメッセージが文字化けするの
なんとかならない？
.mo　をSJISに書き換えればいいんだろうか？

342 ：

>>335
> printfでリテラル文字を表示するときには第一引数に書くべきである
たぶん、あんたは、
「printfで第一引数にリテラル文字を書いちゃいけない。」
って、言ってたやつだな？何年前のこと言ってんだ？DOS時代のことか？
そんなちゃちいライブラリ使ってんな。藁
ちなみに、WindowsのVCについてくるprintfの場合、
現在のロケールのchasetがその文字コードをサポートしているなら、
どこに書いても良さそうだぞ。
ちゃんとformatストリング内は、文字tokenはisleadbyteで
１キャラクタごと取ってきてるからな。
ちゅーか、最近のライブラリはDBCS awareになってるから、
現在のロケールにある文字なら動く。
あんたのライブラリは違うらしいが。
もちろん現在のロケールに含まれない文字コードが含まれていた場合は、
そのパースはおかしくなるに決まってるが。

343 ：

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

344 ：

それより、なんで、
ライブラリを使ってイメージに展開すればその文字が印刷できるのに
そのプリンタが文字の印刷に対応してないと言えるのかが知りたいな。

345 ：

>>339
> これを「ラ・イ・ブ・ラ・リ・依・存」って言うんだよ(藁
つーよりMSの「ラ・イ・ブ・ラ・リ・だ・さ・い」って言うんでねーの（藁

346 ：

>>291
が言ってた。

347 ：

>>340
ちなみに>>291は噛み付き野郎だから、おまえじゃねーの？

348 ：

gcのライブラリって、glibcってことだったのか？

349 ：

>>87
GB18030は
> TRONと比べてもUnicodeと比べても文字鏡と比べても
> 漢字圏にとっては素晴らしいぞ。
>
> 何が素晴らしいって、主だったOSが既に対応可能に
> なっているから。しかも、フォント依存ではなく。
つーことで、噛みつき君は、WinのGB18030サポートは、
UTF-16依存でも、素晴らしいと言いたかったのか？
WinくらいのGB18030サポートだったら、
なんで素晴らしいのかぜんぜんわからん。

350 ：

「最初からださいという話をしていたんだよ」と言う
人が絶えないので、どこからださいという話をしだした
か確認してみました。
「ださ」および「ダサ」で検索したところ
>>155でした。
>>87あたりから始まった話で、随分間を空けてから
登場しています。
それも
＞Shift JISサポートに比べると ださださ、おそまつだねーってことだと思うんだが。
と、単に推測しているだけ。

そのカキコより前に>>142 が
＞>>139
＞> それを対応してないと苦しい言い訳をしてるところが恥ずかしい。
＞
＞だいたい、その拡大解釈じゃあ、
＞TRONコードだってUnicodeや、GB18030対応してるよ。
と書いています。>>139の「W2kはGB18030対応している」
という考えを『拡大解釈』だと言っている。
つまり、>>142は、拡大しない普通の解釈では
「W2kはGB18030に対応していない」と主張していることになる。

351 ：

>>350
ま、結論が出たってことで、いいんでないの？
WinのGB18030サポートってダサいよな。

352 ：

そしてバカは何か場をごまかせた気になった満足して帰るのでした。
もう来なくていいぞ(藁

353 ：

まあ、画面に表示されたドットイメージを文字と認識できないらしいから
何言ってもしょうがないよね。

354 ：

で、そんなGB18030がどうして、
TRONと比べてもUnicodeと比べても文字鏡と比べても
すばらしいわけ？
WinのGB18030サポートもださいのに。

355 ：

まあドットイメージにエンコーディングが残ってると認識してる人は
まだいるのね(藁

356 ：

>>355
ぶんれつか？

357 ：

とりあえずローカル文字コード+数値実体参照（それ以外のコード）
じゃ駄目なのかな？
というか文字鏡とかの実体参照は規格化されてるのかな？

358 ：

>>355
どいつに話してるかもわからんらしい。
まだ、もーそー止まらないみたいだな。

359 ：

画像になった文字とテキストが同じだと認識してる人って結構いるよ。
初心者にね。

360 ：

ところで、超漢字4って今何文字サポートしてるの？
BTRONのPC実装系って、超漢字だけ？

361 ：

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

362 ：

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

363 ：

要はGB18030ってのは>>357みたいな多バイトコード系って考えていいの？
GBK+UNICODE みたいな。

364 ：

>>362
Unicodeに登録させる為の既成事実化としてGB18030
にバンバン登録するというのはありえるかな。
JIS第4水準だって、そうやって規格化する事でUnicodeへの
登録を促すという目的があったそうだし。

365 ：

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

366 ：

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

367 ：

>>366
よくわからないけど１バイト+2バイトの混成であるSJISに
４バイトコード系を追加することはできないの？

368 ：

>>367
そりゃあ第3水準・第4水準以前だったら
やってできないことはなかっただろうけど、
誰もそんなの実装しない罠。

369 ：

Shift_JISをいまさらリファインする前にお前ら
ISO-2022-JP-2を使ってください･ﾟ･(ﾉД`)･ﾟ･

370 ：

>>369
JISをﾌﾙｻﾎﾟｰﾄしてないんで却下。
というかなんでそもそも0201-KANAを組み込まなかったのか疑問。
使わない方針で行ってくれというのは知ったこっちゃないが、
両方のカナが混在している環境が多く存在している以上、
相互変換ができないのはやっぱり不便だよね。

371 ：

ISO-2022-JP-3でも可

372 ：

そういえば、ISO-2022-JP-2でHTML書いて、そこに足りない字は数値実体参照で拾ってくれば
　ユニコードの文字セット+包摂前の漢字
で文書が書けるんだよね。

373 ：

>>372
ISO-2022準拠の方法でコード切り替えすら行なわないのに、
ISO-2022-なんとかを名乗るのはおこがましいというか、なんというか。
つーかISO-2022準拠のキャラクタセット全部サポートすると、ｶﾅや
ユニコードの文字セットはともかくとして、絵が書けたり、音楽すら
鳴ってしまったりすると思うのは気のせいだろうか？

374 ：

気のせい

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

375 ：

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

376 ：

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

377 ：

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

378 ：

未確認情報
gc なるライブラリを使うと、GB 18030 がコンソールで使えるらしい
コンソールへの入出力の前に自動変換するものだと推測される

379 ：

>>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
これで、ソースが１つですむ。
Win9x上では、Unicode文字はpartialにサポートになっちゃうけど。

380 ：

>>375
Win2000/XPの内部コードって、UTF-16じゃんか。

381 ：

お前ら「OSの内部コード」を定義してください。
思いつきを書いとけば、
「（文字コード変換ルーチン以外の）APIが直接扱う文字コード」ってとこか？

382 ：

APIってのはインターフェースだ。内部じゃない。
何言ってんの？バカ？

383 ：

内部コード：　何言ってんの？バカ？
外部コード：　意味がわからないから、ちゃんと考えて言ってよ。

384 ：

インターフェースというのは、接続するもののこと。
APIとは、OS(内部)とアプリ(外部)とのインターフェース。
内部で使われているのはUTF-16。
外部で使われているのは様々。

385 ：

システムルーチンのことをAPIとも言うってだけのことだろ。

386 ：

>>384
APIのIはなんだかしっとるけ？

387 ：

Itteyosi

388 ：

内部コード・外部コードという用語は mohta 大先生も使っていますが、何か？

389 ：

>>386
インターフェースだぞ。知らなかったのか？
何だと思ったんだ？

390 ：

モーオタがバカなんだ！

391 ：

RFC1554(ISO-2022-JP-2)のauthorである
mohta氏の用語法にケチをつけて
引っ込みがつかなくなった厨のいるスレはここか?

392 ：

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

393 ：

んーとさー、たとえばATSUIはAppleのUnicode描画APIだ。
で、ATSUIは関数（だけじゃないが）群だ。
その関数群が扱うUTF-16は「Mac OS Xの内部コード」だろ。
まさか「ATSUIはインタフェースだからOSの内部じゃない」とか
言い出すやつはいないだろうな。

394 ：

要は通信用語の内部コードと、今言われているOSの内部コードは
定義が違うって話でしょ？
通信の立場では、情報交換に使う外部コードは統一しなきゃ駄目だけど、
自分や相手の内部コードはなんでもいい。
OSの立場では、ソフトが使う外部コードはなんでもいいけど、
OSに発行するコマンドで使う内部コードは決まっている。
というわけで発想が全く逆なんだよね。

395 ：

>>366
GB18030が中国の好き勝手に迅速に漢字を増やし
ていくことが出来るということは、TRONコードの
様に包摂基準が一貫しなくなる(というか、包摂基準
なんて何も無い状態になる)危険性は無い？
ましてや、GB18030に登録されたという事実を
理由にUnicodeに後追いで追加されていくことになると。

396 ：

>>395
俺の知る限りじゃ、中国（大陸）には
あまり細かい字体差を区別しようという発想はなさそうだ。
Unicodeの包摂規準をぐしゃぐしゃにしているのは、
むしろ台湾と韓国だと思われ。

397 ：

>>396
KS X 1001 とかをネタに言ってるなら、それは筋違い

398 ：

>>397
いや、俺が韓国と書いたのは互換漢字（重複符号化）のことではなく、
Extension Cのソース（高麗大蔵経）のこと。

399 ：

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

400 ：

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

401 ：

ところで数値実体参照でユニコード以外扱う方法ってないの？

402 ：

>>401
標準化機関にネジ込めばいいんじゃねぇの ？

403 ：

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

404 ：

逆に、どんなエンコードでもHTMLならISO10646 BMPの
文字は数値実態参照で書けるのだから、エンコード自体に
ISO10646 BMPに含まれない文字を含むものを使えば、
ISO10646 BMP+αの文書を作成できるね。

405 ：

>>404
HTMLの数値文字参照がBMP限定だという話のソースきぼんぬ。

406 ：

限定とは誰も言っていない罠

407 ：

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

408 ：

＞構造を借りて無関係に実態参照を張るほうがよいかと(UTF2000や文字境)
そこら辺の規格ってあったら知りたい。
というかISO 2022登録（ISOREG?)コードって実体参照で使えるの？

409 ：

> というかISO 2022登録（ISOREG?)コードって実体参照で使えるの？
一部を除き使えない。
Unicode は、0から255までは ISO 8859 と同じ。HTML 3.xまでは、
実体参照は ISO 8859 を指してた。

410 ：

そういや、TRONのアレもアレだな。&Txxyyyy;とかってやつ。

411 ：

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

412 ：

ISO10646とGB18030を同時に使えるエンコード方式を
策定するってか

413 ：

バイトストリームだけ見て UTF-* と GB18030 系って区別可能？

414 ：

>>411
32ビット1バイトのUCS-4（UTF-32）と
8ビット1バイトのGB 18030「4バイト集合」が
32ビット単位で見れば重ならないということに
何か意味があるか？

415 ：

そのまま一緒にしてISO10646とGB18030の文字集合を
併せたエンコードを捏造できるってことでは？
現状、文字は全て重複してるけど。

416 ：

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

417 ：

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

文字鏡の文字がISOに登録されたってどういうこと?

419 ：

マジ？

420 ：

ISO 10036 のレジストラが GLOCOM なんだわ。
で、それに登録されたらしい。

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

421 ：

グリフ情報の交換標準であって、Code for Information Interchange
ではないから、誤解がないように書いてほしい。

422 ：

>>421
ISO 10036 で規定してるのは，
Code for Gryph-Image Information Interchange なんでせうか？
それとも Code と考えるべきではない？

423 ：

http://www.glocom.ac.jp/iso10036/docs/toc.htm

424 ：

ega

425 ：

保守しとくか

426 ：

文字鏡とUnicode3.2を統合した新しい文字集合キボンヌ(嘘)

427 ：

で結局 gc って glibc のことを指す俺用語なわけ?
(俺用語: かなり偏りのある自分用語)

428 ：

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

429 ：

http://www.chip.de/produkte_tests/produkte_tests_8924297.html
http://pc3.2ch.net/test/read.cgi/win/1021371894/l50
　　　　　。ρ。　　　　　　
　　　　　　　　 ρ　　　　　　
　　　　　　　　 mﾄﾞﾋﾟｭｯ 　　　　　　　　　　　
　　　　　　　 C|.| /⌒⌒⌒ヽ／~￣￣￣￣ヽ 　　
　　　　　 /⌒ヽ⌒ヽ＿__　 　|　　∴ヽ　　３　 ）
　　　　 ./　 _　　ゝ＿＿＿）（９　　　　 (｀ ´)　）
　　　　/　 丿ヽ＿__,.───|彡ヽ　―◎-◎-|
　 　 _/　)　　　　　　　　　　（　　 Y￣￣￣￣）
　　 (__／

430 ：

>>426
そりゃ単に文字鏡の次のバージョンじゃねーの？

431 ：

ケータイの文字コードにUnicodeが採用される日は来るかな？

432 ：

μｉＴＲＯＮケータイの文字コードにＴＲＯＮコードが採用される日は来るかな？

433 ：

（＾＾）

434 ：

（＾＾）

435 ：

　　 ∧＿∧
　　（　　＾＾ ）＜ ぬるぽ（＾＾）

436 ：

━―━―━―━―━―━―━―━―━[JR山崎駅（＾＾）]━―━―━―━―━―━―━―━―━―

437 ：

>>431
とっくに採用されてる。

438 ：

http://homepage.mac.com/hitomi18/

439 ：

　　　 　∧＿∧
ﾋﾟｭ.ｰ　(　　＾＾ ） ＜これからも僕を応援して下さいね（＾＾）。
　　＝〔~∪￣￣〕
　　＝ ◎――◎ 　　　　　　　　　　　　　　　　　　　　　山崎渉

440 ：

>>398
高麗大蔵経って例のあれか？

441 ：

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

442 ：

　__∧＿∧_
　|（　　＾＾ ）|　＜寝るぽ（＾＾）
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉
　　 ~￣￣￣￣

443 ：

緊急浮上
http://www.zdnet.co.jp/news/0307/17/nj00_wjsaka_2.html
「ただし私はUnicodeが嫌いなので、Sunに言って超漢字に対応させている」

444 ：

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

445 ：

厨房の夏か．．．

446 ：

http://homepage.mac.com/hiroyuki44/hankaku09.html

447 ：

>>32
戦後の歴史も知らんみたいだな。
マスコミは馬鹿だから講話独立の意味が分かってないだけだ。
それをそのまま採用するなど以ての外。

448 ：

>>33
高校の時調べもので「こけら」を引いたら
「柿」とかいてあって頭が混乱した思い出がある。

449 ：

根本的に文字を１対１対応のコードに割り振るのは無理なんじゃないか。
ユニコードにしろトロンにしろ。

450 ：

たとえそうだとしても、やらねばならぬ。

451 ：

>>450
やる前に考えろって言ってんの！

452 ：

誰に言ったの？

453 ：

RDVD販売です．新作旧作多数在庫あります。
女子校生モノ、Rモノ等多数ご用意してます。
http://d-jupiter.net/

454 ：

　　　 (⌒V⌒)
　　　│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
　　⊂|　　　　|つ
　　　（＿）（＿）　　　　　　　　　　　　　　　　　　　　　　山崎パン

455 ：

　　　 (⌒V⌒)
　　　│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
　　⊂|　　　　|つ
　　　（＿）（＿）　　　　　　　　　　　　　　　　　　　　　　山崎パン

456 ：

ＴＲＯＮの文字コードって、小説なんかの架空の文字も集めてるらしいけど、
ゼビウスのゼビ数字とか、フィネガンズフェイクの変なアルファベット（邦訳版
の変な字も）なんかもあるの？

457 ：

>>456
そういうのは入ってないだろ。
手書き文字の略体化のルールを拡張適用した「架空の文字」なら
入ってそうだけど。

458 ：

>>456
著作者の承諾を得てあなたがTRON文字協会に登録すれば可能。

459 ：

欧米人は表意文字なんて原始人の使う文字ぐらいにしか
おもってないんだろうな。古代の象形文字も漢字も
同じような感覚で接してるんだろうな。

460 ：

>>440
あれだ。

461 ：

文字コードも半導体投資も底なし沼。
漢字の派生は過去の誤字脱字全部添削するようなもの。

462 ：

age.

463 ：

>>461
とりあえず全部包括してしまえばいい。
漢字の総数なんてたいした数じゃない。
漢字の総数は非常に多いが見通しが立つぐらいの有限だから。
他の文字で構造的組合せ型はたちが悪い。
あれはフォントの扱い方を根本から見直さないと
どんなに収録してもキリがない。

464 ：

>>463
おまえ頭悪いだろ。

465 ：

>>464
漢字の多さなんてたいした問題じゃない。
見通しの立つ膨大さなんて質がいい方。

466 ：

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

467 ：

元ソースは共同通信
Ｗｅｂ東奥・ニュース／it　20040310　漢字異体字、欧米ＯＳでも　トロンの坂村教授ら開発
http://www.toonippo.co.jp/news_kyo/news/20040310010030611.asp
漢字異体字、欧米ＯＳでも　トロンの坂村教授ら開発（京都新聞：2004.03.10）
http://www.kyoto-np.co.jp/news/flash/2004mar/10/CN2004031001003061C2Z10.html
ZAKZAK　漢字異体字を欧米ＯＳでも…トロン坂村教授開発
http://www.zakzak.co.jp/top/t-2004_03/1t2004031129.html
　国産基本ソフト（ＯＳ）トロンを推進している坂村健東大教授は１０日、
人名や地名、文学作品などで用いられる漢字の異体字を、ウィンドウズ
やマッキントッシュなど欧米のＯＳ上で自動表示する技術を開発したと発表した。
　印刷、出版業界では異体字をウィンドウズなどの機器で処理する際、
手作業で外字リストの作成や校正を行う手間があったが、
「新技術で大幅な省力化が可能になり、
大手企業で年間数億円規模のコスト削減が可能」（坂村教授）という。
　標準文字にない外字にそれぞれ識別番号を付けた文字コード（トロンコード）
のデータベースを活用。専用の外字変換サーバーを使い、必要な文字を
データベースから検索して表示する仕組み。データベースや専用サーバーは
無償で公開する。
　トロンＯＳ「超漢字」などは、異体字のほか中国などで使われる漢字を含めて
既に計１７万の漢字が表示できる。
　これに対し、欧米のＯＳはアルファベットを基本に設計され、
日本の大漢和辞典で約５万もある漢字を収納できない。このため、
文字数の多いアジア諸国の言語に適していないとの批判もある。
　新技術は自治体や企業合併の際、外字データを整理統合するケースなど
でも有効だという。年内には個人でも利用できるようになる見込み。
ZAKZAK 2004/03/11

468 ：

印刷業界が頭を悩ませる外字問題、坂村氏の提案する解決方法とは? (MYCOM PC WEB)
http://pcweb.mycom.co.jp/news/2004/03/11/014.html
トロンプロジェクトは、「フォント・トレーサビリティ・システム」を発表した。
同プロジェクトリーダーで東京大学教授の坂村健氏が長年取り組んできた
OS「トロン」の多文字技術を他のOSでも利用できるようにし、多文字問題・
外字問題の解決を助けようというシステムだ。
日本で利用される漢字の種類は膨大で、PCで区別可能な数を遙かに
超えている。また、字体の違いを区別できないといった問題も存在する。
こういった問題に対して印刷業界などでは「外字」を使って文字を追加す
ることで対処してきた。しかし、外字を管理するための「外字表」には管理・
整理の手間が掛かり、坂村氏は外字表の取り違えが原因となるトラブルの
存在も指摘する。「フォント・トレーサビリティ・システム」は、こういった多文
字に関する問題を解決するために「TRONコード」を利用して全ての文字を区別し、
外字や異字体などを管理する。これをWindowsやMac OSといった既存のOSでも
扱うことのできるようにするためのシステムだ。また、ユビキタスIDを利用して
外字表の管理も行う。

469 ：

TRONコードでは、既存の文字コードに含まれる文字やあらたに作成された
外字に対し、TRONコードを使って統一番号を付与する。文字コード間での
重複や異字体などに関しては、データベースで管理することで対処する。
Unicodeなど既存の文字コードでは、微妙に違う二つの漢字を異字体とするか
別の文字とするかを議論による判断で決定してきたが、TRONコードでは
細かい違いであっても、全ての文字に一意の文字コードを付与することが
大きな特徴となっている。坂村氏は「(異字体に関する)学問的な研究を
否定はしないが、(細かに異なる2つの文字を)区別するかしないかはユーザが
決めること」と主張する。異字体データベースに関しては複数の存在も認め、
異字体に関する複数の説に対応できるものとする。TRONコードのコード
割り当てについてはウェブサイト「トロン文字収録センター」で公開されており、
文字の読み・おおよその画数・部首などから検索を行うことができ、TRON以外でも
TRONコードに収録される文字の利用が可能となっている。
TRONコードへの新たな文字の追加は既存の文字コードを丸ごと追加する
方法の他にも、1文字だけを追加する方法も用意されている。DTPソフトが
標準で持つ外字セットや自治体で使用される人名用外字のセットなども
収録してコードを割り当てることも可能だ。複数の文字コードを収録する
TRONコードはメタコードとして振る舞うことができ、TRONコードを仲介して
文字コード間の変換を行うこともできる。

470 ：

こういった既存システムの文字コード同士の変換を行う仕組みをTRON以外
のOSからも利用可能とするために「外字変換サーバー」が用意された。
「外字変換サーバ」では、TRONコードで作成された多漢字コンテンツを読み込み、
他のOSで読み込むことができるShift-JISなどのコンテンツと外字表、その
コンテンツで使用される外字を含んだTureTypeフォントを生成する。
クライアントで実装せず、サーバの機能としたのは既存の業務システムの
変更を行う必要がないことや複数システムの統合に有利であるからという。
また、従来出版物毎に作成して管理されてきた外字表や外字フォントセットの
管理を「ucode」を利用して行う。外字対応表毎にucodeを付与し、ユビキタス
IDセンターが出版物との対応を管理する。これによって外字表の管理を容易にし、
コストを下げることが可能となるという。
外字変換サーバとucodeによる外字表の管理によって、これまでTRONで実現
されてきた多漢字の利用を汎用的なソリューションとして、OSを問わずに多くの
プラットフォームで利用可能となる。坂村氏は、「フォント・トレーサビリティ・システム」
について、様々なOSのメリットを利用し、それぞれの得意分野を活かしてコンテンツの
作成を行うことのできるメリットを強調する。また、こういった「役割分担」は
最近のトレンドであると語り、今回のシステムはマイクロソフトとの提携などに見られる、
WindowsやLinuxなど他のOSとTRONの「協力関係」を深める取り組みの一端であるともした。

471 ：

またカラ周りしそうな予感

472 ：

既存の資産を集めて使うという発想はいい。
ただ、これだと用途が限られる。

473 ：

既存のシステムはそれなりに動いてるしな。
いまさら設備投資するところがどれだけあるか?
10年遅かった。

474 ：

ますます超漢字の必要性がなくなるのね……

475 ：

超漢字が死んでもTRONコードが生きれば意義は大きい。

476 ：

既存の外字資産といっても無限にあるわけじゃないからなぁ。

477 ：

Microsoftとの提携効果ですね。＞trutypeフォント生成
Windows の外字交換標準の問題点もこれを換骨してMicrosoftが
使うんじゃない

478 ：

GB18030のTRONコードの割り当てってどうなってるの?
今書体が実装されてるのは634文字だけだけど
コードポイントの割り当てはあるんでしょ?

479 ：

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

480 ：

【社会】人名漢字580字追加へ　「舵」「梗」「琥」「珀」「鷲」など今秋に使用可★２
http://news13.2ch.net/test/read.cgi/newsplus/1085840653/

481 ：

UNICODEの65536を非難するより
BTRONのファイル数65536を改善すべきでは

482 ：

そうだね

483 ：

だね

484 ：

漢字を少々たくさん扱えるだけで
多言語ではないのさ

485 ：

初期のTRONって単純にJISコードだった
UNICODEが出てきたのであわててTRONコードとか言ってまねしたのさ

486 ：

>>484-485
北海道民ですか？

487 ：

>>486
そうですが何か？

488 ：

初めはJISっていうか今昔文字鏡かなんかのコードだったんでは？

489 ：

>>488
もっともっと昔。

490 ：

文字セットをコードとか言うな。

491 ：

JIS X 0208 コードなどでは外字が定義されていますよね。
いわゆる機種依存文字などもこの外字部分に
定義されているのだと思うのですが、
外字部分も Unicode との間でマッピングが定義されているのでしょうか？

492 ：

質問の意味がよくわからんが
JIS X 0208で未使用の区点も対応は定義されてるよ
ただしTRONコードではJIS X 0213:2000に使われてる

493 ：

>>492
> JIS X 0208で未使用の区点も対応は定義されてるよ
回答の意味がよくわからん(笑）。

494 ：

>>492
> JIS X 0208で未使用の区点も対応は定義されてるよ
回答の意味がよくわからん(笑）。

495 ：

たとえば84区08点はJIS X 0208では保留領域だけど
TRONコードT1-7428が予約されていたってこと

496 ：

>>495 さんへ
いやいや、そういうことではなくて、
元々の491の質問は「JIS X 0208 コードの外字部分と Unicode との間のマッピング」
についてだったので、それに対して492の【前半部分】で「対応は定義されてるよ」と
回答しているようにしか読めない。
それで、「回答の意味がよくわからん」と書いたのだが。
X0208とTRONコードとのこと（だけ）を言いたかったのであれば、492でもう少しわか
りやすく書いてくれればよかったんだが。

497 ：

BTRONがいまいちぱっとしないのは
群がっている連中にプログラマが比較的少ないからじゃないかな。
TRONの宿命かも知れんが、SF好きが嵩じてTRONにはまった香具師ってのが珍しくない。
他のOSではあまり見られない現象。
マイナーでも、どこかがとんがったOSだとそれなりのプログラマがハックして盛り上がるんだが。
「データウェア」で盛り上がってもなぁ〜。

498 ：

なんでコピペするのさ。。。

499 ：

諸橋大漢和も草冠を3画にしちゃったのね。
あ、いや、それだけなんだけどね。

500 ：

3画にしたのは「新・漢語林」でしょ。

501 ：

アルファベットの筆記体も形態のぶれが結構ありますが、
個々にコードを割り当てられないんですか。漢字だけ贔屓してるような氣がします。

502 ：

欧米人はそんな頭の悪いことしません

503 ：

おまいら、Nスペで国産OS TRON の出番ですよ。
NHK総合　8/28（日）午後9:00〜
　NHKスペシャル　日本の群像　再起への20年
「第4回　極小コンピューター　技術者たちの攻防」
　 １９８４年、誰もが簡単にコンピューターを使えるようにと
東京大学の坂村健氏が開発した基本ソフト「トロン」。
しかし、無料提供を目的にしたトロンは、
８９年にアメリカから貿易障壁のリストに挙げられ、
普及中止に追い込まれる。
結局、９０年代のパソコン市場は、
世界標準を握ったアメリカ製の基本ソフト
「ウィンドウズ」に支配されることになった。
……
http://www.nhk.or.jp/special/topics/top2_0503a.html

504 ：

昼はアキバに入り浸り　１Ｂソフトを漁ったら
トロい店員奥から出てきて　「開発元に聞いてくれ」
フリーソフトはメチャクチャイケるぜ
市販ソフトはPＭCだけ
いつもメゲ知らずの　ＢＴＲＯＮユーザー
完全無欠の未来派ＯＳ
松下電器に見放され
パーソナルメディアでやっている
馬鹿にするなよマッキントッシュユーザー
使って　使って　使って　使って
夜は夜な夜なネットでサーフィン　トロンサイトの乱れ打ち
Ｆトロ　Ｂフリ　坂研　トロ協　テキストブラウザで〜
作るＯＳ　買うＯＳ
夢を見るなら（イェィ　イェィ　イェィ　イェィ）
メイキング電脳シティ　ＢＴＲＯＮユーザー
完全無欠の未来派ＯＳ
３０１条に潰されて
外圧跳ね除け　生きている
使えや遊べやＢＴＲＯＮユーザー
使って　使って　使って　使って
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
（「完全無欠のロックンローラー」の曲で）

505 ：

漢字12万字表示可能 世界最多のフォント集 東大坂村健教授・東洋文化研究所ら OS問ﾊｽﾞ
http://news18.2ch.net/test/read.cgi/scienceplus/1134388808/

506 ：

保守

507 ：

保守

508 ：

保守

509 ：

２ちゃんねるでどうしてもUNICODEで文字を表示したい時は、実体参照で打込
むことになるが、各板のSETTING.TXT の設定に依り、実体参照で表示できる
板と表示できない板がある。
mixiはそのままUNICODE(UTF-8)が書込めるのだが。

510 ：

TRONコードってwikipediaでも使われてたのねｗ
ttp://ja.wikipedia.org/wiki/%E7%94%BB%E5%83%8F:TRON_2-2436.gif

511 ：

UNICODEの専門スレって無いの？

512 ：

どっかで見かけた気がするな

513 ：

ムズカシイネ

514 ：

＞　広い意味の国粋主義で「国産でいいものを作ろう」というのはまだよかったんだが、 「国産だからいいものに違いない」と妙な脳内変換をして
坂村健　って、語り口が『梅干と日本刀』＋『プロジェクト・Ｘ』だったな。　「マスコミに受けるプレゼン術」だけに長じていた。
B-TRON、C-TRON、I-TRON、・・・　名前と「構想」だけがあって、実体が無い。
予算だけが大規模で、業績が無い。
２０年以上かかって、何の成果も上がらず、「ＴＲＯＮプロジェクト」　は　大　失　敗　。
そこで、坂村健・東大教授が一言：　「ボクは悪くない。世界の反応がおかしい」…

515 ：

炊飯器のマイコン制御使われてるって聞いたぞ
おいしいご飯がたべられるのはトロンのおかげだ

516 ：

ほー

517 ：

罠しかけ　自分がはまる　ナナ六条
阿国だけにおおきに

518 ：

NECやMSに足を引っ張られた割にiTRONは普及してるな

519 ：

とりあえずなんでJUNETコードみたいにRFCが書けなかったの？
そうすればEUCやSJISみたいにJISのおまけ規格にはなれてたんじゃないの？

520 ：

ISO-2022-JP は ISO-2022 の枠組みに沿ってるけど、
TRON コードはそういうコード体系じゃないから。
理屈ではなんでもありのエスケープシーケンスもあることになってる
（ここまでsjis, ここからEUC みたいな）けど、そんなもん誰も使わんから、
登録する手間がかかるだけ無駄。

521 ：

>>520
それがおかしいんだよ
UNICODEみたいなRコード系でも、切り替え文字を割り当ててもらっているので
ISO-2022を名乗れてしまう。
TRONコードになぜそれができなかったのか。

522 ：

時代遅れのマシンでも漢字表示に困らないようにする為のサブセットコード系に
ISO-2022-JPなんてISO標準と錯覚させる大層な名前を許したのがそもそも間違い。

523 ：

つまりTRONは時代遅れって事？

524 ：

>>523
全然違う。
漢字をROMで持っているような時代遅れのマシン為の規格に日本標準みたいな名前を名乗らせたから、
それと互換性のないローカルコードなんてシカトされたってこと。
他の国で採用されてればまた話は別だろうけど。

525 ：

> それがおかしいんだよ
> UNICODEみたいなRコード系でも、切り替え文字を割り当ててもらっているので
> ISO-2022を名乗れてしまう。
実際にそれで運用してるものが存在するか？
てかあんたの言ってる「UNICODE」って何？　UTF-何？　UCF-何？
一体何のことを言ってるのか、わけがわかんない。

526 ：

どこぞの多言語エディタで保存すればできるだろ。

527 ：

運用なんて関係ないんだよ。
そもそも符号化法がうじゃうじゃあって「わけがわかんなく」て、「ユニ」でもなんでもなく
以前のコードとは変換テーブルがないと互換できないようなRコードが後継としてねじ込めたのだから
>>520は理由にならないって話。

528 ：

はいはい。TADの仕様を最初から最後まで読んでからまたどうぞ。
実はTRONコードの仕様という独立したものはなくて、TADのサブセットを便宜的に
そう呼んでるだけだから。

529 ：

それこそJIS X 4401とか、データフォーマットの規格ならいくらでもあるんじゃないの？

530 ：

あるけど、それで？
手間も暇も金もかかるの。あんたがそれ全部提供してくれるわけ？

531 ：

なぜunicodeやOOoにはできたのかってことでしょ？

532 ：

strcmpやstrcollの実装が大変そうだ

533 ：

テ？ト

534 ：

テ？x31F2;ト

535 ：

？x6C49;
？x31F2;

536 ：

すんげー今更だが、あることを確認したので報告する。
1B（1B/V1以前の1B）で使える補助漢字のフォントを売ってたのは「エーアイ出版」で、
文字鏡の「エーアイ・ネット」とは全く関係がなかった。
昔、確か和尚か誰かがそのへんの話で混同してたのを見たことがある
気がするもんだから書いておく。

537 ：8)

とろ〜ん