(ﾟдﾟ)ﾊｯ!
（・∀・）ｽｰﾝｽｰﾝｽｰﾝ♪
(´Д`)ｲｪｧｽｰﾝｽｰﾝｽｰﾝｽｰﾝ
（・∀・）ｽｰﾝｽｰﾝｽｰﾝ♪
(´Д`)ｲｪｲｪｲｪｧ
（・∀・）ｽｰﾝｽｰﾝｽｰﾝ♪
(´Д`)ｲｪｧｲｪｧｲｪｧｲｪｧｽｰﾝ
(ﾟдﾟ)ﾔ!
（・∀・）ｽｰﾝｽｰﾝｽｰﾝ♪
(ﾟдﾟ)ﾔ!
（・∀・）ｽｰﾝｽｰﾝｽｰﾝ♪
(´Д`)ｲｪｧﾓﾝﾓﾝ
(ﾟдﾟ)ﾔ!
（・∀・）ｽｰﾝｽｰﾝｽｰﾝ♪
(´Д`)ｼｹﾀｼｹﾀ
(ﾟдﾟ)ﾔ!
（・∀・）ｽｰﾝｽｰﾝｽｰﾝ♪
（・∀・）ｽｰﾝｽｰﾝｽｰﾝ♪
（・∀・）ｲｪｰｱ!
（・∀・）ｽｰﾝｽｰﾝｽｰﾝ♪
（・∀・）ｲｪｰｱ!
(´Д`)ｽﾝﾍﾞｽﾝﾍﾞｿﾝｽﾝｽﾝﾊﾞ
（・∀・）ｽｰﾝｽｰﾝｽｰﾝ♪
(ﾟдﾟ)ﾌﾞﾍﾞﾗ!
(´Д`)ｽｰﾝｽｰﾝｽｰﾝ
両方とも、もう終わっているよ。(藁
奴が2で居るスレは終わりだろ。
まぁ、1の時点で終わってるが。
ttp://news.2ch.net/newsplus/kako/1023/10232/1023201516.html の890-902の話題。
902 名前： 名無しさん＠3周年 投稿日： 02/06/08 01:38 ID:A44OC3l0
： Be名無しさん [sage] NGNG
バカか。
www.iana.org/assignments/character-sets
に登録されてない、charsetは。。。
ttp://cocoa.2ch.net/linux/kako/1003/10031/1003159137.htmlの53も興味深い。
53 名前： login:Penguin 投稿日： 01/10/17 00:30 ID:YQKlNfNV
： Be名無しさん [] NGNG
まあ、そのあたりが本質だわな。
超漢字ってのは「後回しシステム」なのよ。
符号化する上で最も難しく手間もかかるのが文字の同定。
それを「後回し」にして、手っ取り早く文字数を誇るために
あれもこれも見境なく詰め込んじまった。
だから現状ではまともな運用なんかできっこない。
インド系文字の合成も「後回し」で、
使い道のない符号表上のグリフだけが実装されている。
決まり文句は「今後対応していきます」。
で、原稿プロセッサはどうなったのかと小一時間（略
んー、一般的には、なりますね。異体字のというか文字の同定のためのデータベースみたいなのを
共有しなければならない感じですよね。（全世界のそれを共有する必要はないでしょうが、
それでも標準みたいなのを想定しないと組み合わせの爆発が起きてしまうかな）
逆に言えば、そのDBの共有ができれば問題なさそうですが、ややSF的なのかな。
これはコードに文字同定の問題を持ち込むことを避ける以上、必然的に招く事態じゃないでしょうか。
TRONコードってそういうものなのでしょう。いっぽう、たとえばUNICODEやJISは、文字の同定を
文字コードがやるのだ!! という考え方なんでしょうね。どっちもいまいち要改善って感じですけど、
文字の同定の問題が学問的に解決していない以上、しかたないですね。
本題に戻ると、文字セットを追加するしくみはいちおうあるようなので、前述のDBにユーザーが追加を
できる仕組みが必要ということですか。
ageるほどのスレではないのでsage
もう入ってるし、すでに実装もあるぞ。
その「コードに文字同定の問題を持ち込むことを避ける」ってのが
TRONコードの「思想」のように言われているけど、
もともとの計画では、センセも漢字は統合した上で収録するつもりだったんだよ。
同定を避ける云々は後付けの理屈。
もちろんUnicodeに入っているんだが、
「それだとTRONを笑えん」ってのはどういう意味？
（補助漢字と第3、第4水準漢字は収録してる文字に重複がある）
収録された漢字と重複してる分は取り除いてな
かったっけ？
TRONコードの「思想」かどうかは知らないのですが、現状ですね。
> もともとの計画では、センセも漢字は統合した上で収録するつもりだったんだよ。
> 同定を避ける云々は後付けの理屈。
へえ、そうなんですか。それは聞いたことがありませんでした。
言葉足らずでしたが、 は現状に対する私の「解釈」なので、後付けとか前付け
とかいう話ではありませんでした。
「センセ」は「もともと」は文字の同定とかの問題をあまり知らなかっただけじゃ
ないんですか？ で、調べていって「だめだこりゃ」。あたりまえですが。
＃JISが字形の統合とか言って新しく珍奇な字を作るから余計ややこしくなるじゃ
＃ないか。ぷんぷん。
JIS X 0213の包摂規準で同定し、
補助漢字その他との重複を排除した上で追加申請、と思われ。
そうなのか。
文字追加の際、JIS X 0213の基準では補助漢字部分で入れられない物もあるんじゃねーのとか思っていたが、俺の思い違いだったか。
補助漢字以外にもすでに追加されていたし、実際に不可能だと思ってたよ。
ところで、実装された奴って組み込み用の奴?
JISは「字形の統合」なんて言ってないだろ。
悪いけど意味判らん。
のは、たとえば(月並みですが)「鴎」の偏の問題です。
まあいろんな人が言っていることなのでここで書いてもしょうがない
ことでした。
了解。その例は「通用字体の準用」。
新聞で使われている字体を採用したもので「作った」わけではない。
といっても、83年JISの変更を擁護する気はさらさらないけどね。
「包摂」しちゃった、ってほうか？ はしご高とか。
凶悪なのは「かき」と「こけら」なんかで、頭痛100%モノ
だったりするのな。
「統合」という用語が使われるのは、Unicode および
ISO 10646 の 'CJK Unified Ideographs' の訳で、
「CJK 統合漢字」だね
脳内で話を作らんように。
97JISは口高と梯子高の違いを「字体差」とした上で
包摂していると思われ。
それはMac OS X 10.0の理解としては間違いではないが、
いかんせん情報が古い。
JIS X 0213のBMP未収録分はExtension Bの一部として
2001年5月のUnicode 3.1で規格化され、
2001年9月のMac OS X 10.1でサポートされている。
ん？
ttp://http://developer.apple.com/technotes/tn/tn2029.html には、
Support for the JIS X 0213, HK-SCS, and GB 18030 character sets has been added.
って書いてあるぞ。
GB18030ってことは、
Surrogateもオッケーってことっすね。
ついでに質問。
Mac OS Xでは補助漢字にだけある文字はサポートしていない、っていうのはいまでも?
はしご高はバリアントで表現してるよね?
フォントに含まれていない文字を表示しなければならないとき、別のフォントを使って自動的に表示する機能はある?
暇があれば教えてくれるとありがたい。
> フォントに含まれていない文字を表示しなければならないとき、別のフォントを使って自動的に表示する機能はある?
Winで言うUniscribeがあるかってことかな？
Macは、ATSUI(Apple Type Services for Unicode Imaging)があるけど、
ttp://http://developer.apple.com/techpubs/macosx/Carbon/text/ATSUI/atsui.html font substitutionとかはサポートしてるみたい。（よく知りません）
意外とこのあたりはMacってさらりとやってたりするんだよね。
MUIも対応してたりするし。
Winはなんかやりました！みたいな感じでアピールするけど。
> Mac OS Xでは補助漢字にだけある文字はサポートしていない、っていうのはいまでも?
Unicode3.2をサポートしてるので、
その範囲内ならいくらでもどーぞ。
> はしご高はバリアントで表現してるよね?
variant tagを使って表現ってことか？
違う。はしご高はU+9AD9に入ってる。
ちなみに、OSXについてくるヒラギノフォントを使えば、はしご高は表示可能だよ。
さらにSurrogate文字もちびちび、このフォントには入ってる。
例えば、U+29EBDとかも表示できる。
WWWでしっかりアピールしてんじゃん。
Uniscribeとくらべるとなあ。。。
盛り上げぶりが違うと思う。
で、ATSUIのページを見てきたけど、違うみたい。
uniscribeって、リガチャーとかカーニングとかいうやつで使う奴ではないですか?(これをサポートしてないようでは多言語なんて言えないね>超漢字)
質問がわかりづらかったと思うんで、例を上げて説明すると
ある文字の異体字フォントを作った。で、このフォントを使うとき、この文字以外はヒラギノで表示するようにする、みたいな感じです。
(Windowsだとアルファベットしか含まないフォントを漢字にも適用すると、漢字部分はトウフになるけど、Macはどう?こっちのほうがわかりやすい?〉
補助漢字はサポートし始めたんですか。ん〜、じゃあ、Mac OS Xの最初のバージョンで入れていなかったってのはなんでだったんだろう。(これも、俺の記憶違い?〉
はしご高をvariant tag〈こう書くのか、これも知らなかった）使わないのも意外。だいぶ昔、unicodeが言語指定をもたなかったころ、あれは中国の文字のためのコードだから日本語では使えない、とか聞いていたんだけど。
ちなみに、U+29EBDはBBBでは表示できなかったんで、なんの文字かわかりませんでした。(ゲタが4つも表示されたが、アレはなんだったんだろう?)
できるみたいだよ。
例えばOmniWebだと、
デフォルトではLucida Grandeっていう欧文フォント使うようになってるけど、
漢字とかの表示には勝手にヒラギノが使われたりしてる。
どうでもいいことだけど、Lucida Grandeにεがあるのはいいんだけど、
これの字体が気に入らないんだよねぇ。
> で、ATSUIのページを見てきたけど、違うみたい。
端から端まで読んだか？これは見たか？
ttp://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"だよ。
ちゅーか、Unicodeがらみの話をするなら
www.unicode.orgを見るように。
ttp://http://www.unicode.org/charts/ にすべての文字がある。で、
ttp://http://www.unicode.org/charts/PDF/U2F800.pdf を見れば、そのglyphがわかる。
Mac OS Xに付属するヒラギノについて言えば、
補助漢字のすべてを含むわけではない。
ただ、JIS X 0213に含まれない補助漢字であっても
Adobe-Japan1-4などを経由して入っている場合もある。
それからの言うとおりOSの枠組みとしては
Unicode 3.2をサポートしているので、
すべての補助漢字を表示できるかどうかはフォント次第。
スマソ。
ttp://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()
なんかまさにそうだと思うんだけど。
Mac OS Xのグリフ切り換えは、variant tagとは無関係で独自のメカニズムを使う。
情報交換のためにvariant tagを使うかもって話は確かにあったが、
それは将来の話だし実現するかどうかは不明。
ちなみにvariant tagというのは古い呼称。今ではvariation selectorと呼ぶ。
ttp://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との対応関係を持っているわけで、
現実にはこれを含まない実装は珍しいかと。
ttp://http://kado7.ug.to/net/ 朝までから騒ぎ！！
小中高生
コギャル〜熟女まで
メル友
i/j/PC/対応
女性の子もたくさん来てね
小中高生大歓迎です
全国デ−トスポット情報も有ります。
全国エステ＆ネイル情報あります。
激安携帯情報あります。
ヒョデーイ！！！
ttp://http://2style.net/maido/R3_temp.swf?inputStr=%83q%83%87%83f%81%5B%83C%81I%81I%81I%81I ＃音量ＯＮにして飛んでね（・∀・）ｲｲ！
参考スレッド 森恒二ホーリーランド拳闘暗黒伝セスタス技来静也4
ttp://comic.2ch.net/test/read.cgi/comic/1025843878/551-611 ついでに。
↓こういう現象があったりしますな。実際
ttp://www.microsoft.com/japan/support/kb/articles/J041/1/42.HTM それがどうして52へのレスになってるのかわからん
>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へのレスなのかわからない。力になれずすまない）
＞実現するかどうか不明ってのは、ちょっと不思議。いまでも、おんなじことやってるはずなのに。
＞なにか問題でもあったんですか?
variation selector（variant tag）は、
UnicodeあるいはISO 10646という「文字コード規格」が提供する機能であって、
当然、プレーンテキストでの情報交換を想定している。
要するにグリフ置換機構を意味する一般名詞「ではない」ってこと。
variation selectorで情報を交換するには、
そのための「異体字リスト」が必要となるが、まだそんなものはないし、
今後（漢字用のものが）策定されるかどうかも不明。
Appleがやってるグリフ置換はvariation selectorによるものではなく、
現状ではPDFなりを使わないと情報交換できない。
単に異体字（バリアント）をサポートしてるってことじゃねえの。
いや、それは前からやってるんで。わざわざ発表することでもないと思う。
ところで、Mac OS Xのフォント呼び出しのメカニズムが書かれてたけどBTRONの【本来の】多言語処理ににてると思った。
unicodeやShiftJISが文字層で実際のフォントに割り当てられているIDがスクリプト層、と考えるとどうですか?
しかしTRONコードの「スクリプト層」は見事に死んだな。
ttp://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.
ttp://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.
０２１３には０２１２とダブっている文字もあればそうでない文字もある。
０２１３にはＵｎｉｃｏｄｅに入ってない文字もある。
ＢＴＲＯＮっていつになったらスクリプト層が実装されるんだ？
しかし、実際にやるとなると統合漢字が問題となってくるような。
あれ、Mac OS XのOSレベルでの対応ってのはなんだったんだ。また俺の勘違いか?
ところで超漢字で実装されてるのはスクリプト層とフォント層なんですが。
文字層で逆転できるもんが出来るのか?(「死んだ」とかまで言われてるし)
それよりも現在作られ続けているスクリプト層だけで出来たデータは将来どうなる?
（本来の意味での）スクリプト層のことだろ。
それに気づかないLinuxやXFree86は馬鹿。
本格的国際化とやらが実現する日を夢見て
国際化を見送り続けるよりはずっと現実的。
そしてどんどんドツボにハマっていく罠・・
ドツボに嵌る機会すらないね。
何も得られないけど。
そうはいうが、
Unicodeは、Shift_JISよりは、かなり良いわけだよね。
それでも不満なやつは、今のOSに関して、どれもだめなわけだよな。
ちなみに、BBBはSurrogateにも対応してない罠。
Unicodeは、最初の策定時に既に広まっていた
各国の文字セットを集めた交換用のテーブルと
しては十分な出来ですもんね。
ただ、漢字圏について言えば中国のGB18030が
素晴らしいので、ちょっと混乱しそうですね。
おとなしく俺らの考えた規格にしたがってろよ。ｱﾒﾘｶﾏﾝｾｰ」の違いも分かっていない罠
韓国各々の代表者と綿密に検討して作り上げた
事実を知らない奴ﾊｹｰﾝ
夢を見ている人たち
夢を見れない人たち
夢破れた人たち
夢を叶えた人たち
夢を追いかけてる人たち
夢を諦めた人たち
そして
全ての馬鹿たちに送ります
『一炊の夢』
ttp://http://www.geocities.co.jp/Hollywood-Screen/9038/ なるほど。そいつらがｱﾒﾘｶﾏﾝｾｰだった訳ですね
確かにスクリプト層自体は実装されている。
インド系の文字あたりを例として問題を列挙すると……。
・スクリプト層に必要なグリフが実装されていない。
・ていうか、それ以前に必要なグリフが仕様化されていない。
・グリフ置換機構が実装されていない。
・ていうか、置換機構が仕様化されてもいない。
・ていうか、その前提となる文字属層の中身が仕様化されていない。
・ていうか、文字属層の仕様化は目途すら立ってないと思われ。
GB 18030が素晴らしいかあ？
「TRONと比べれば」ってのはナシだぞ。
Shift_JISと比べれば。
お前は放置されている事にいいかげんに気づけ（ｗ
TRONと比べてもUnicodeと比べても文字鏡と比べても
漢字圏にとっては素晴らしいぞ。
何が素晴らしいって、主だったOSが既に対応可能に
なっているから。しかも、フォント依存ではなく。
(クッキー使用強制でBBBから書き込めなくなった。こういう「主だったＯＳ」しか考えないやつなんて大嫌いだ)
拡張性で言えば、すばらしいのかもしれないけど、
Unicode3.1（正しい？）プラスアルファでしょ？
だからたいしてUnicodeとかわらん気がするんだが。
もちろん異体字においてはUnicodeと同じ問題があるわけで。
ちなみにWinはネイティブキャラクタセットとしては
GB18030はサポートしてないよ。（MacOS Xも）
だから、NotePadとかでGB18030でセーブすることはできない。
UTF-16で、GB18030の文字は扱えると言っているだけ。
比較の対象がよくわからんのだが、
GB 18030って、文字セットとしては
（収録のタイミングが多少ずれることはあっても）
Unicodeと一緒だろ。
異体字におけるUnicodeと同じ問題って何だ？
骨がどうとかってやつか？
何をサポートしてる？
XPの中国語版であったって、ネイティブキャラクタセットは
あいかわらずGBKだよ。GetACP()呼ぶと936って返ってくる。
GB18030のコードページ54936はMultiByteToWideCharとかのAPIでしか使えない。
だからnon-Unicodeアプリは、GBKでしかのデータを処理（たとえばセーブとかね）できない。
XPであっても、あくまでもGB18030は変換用のキャラクタセット。
それはネイティブキャラクタセットじゃあない。
基本的にGB18030は、Unicodeコンパチだから、
ハンのエリアは、unifiedされてるってこと。
ttp://http://www.leverage.jp/bloom/qry/search.qry?function=search Windows2000以降はオプションでGB18030対応
しますよ。
ここをクリック！！！
↓↓
ttp://http://www.bea.hi-ho.ne.jp/paisen/ WinでいうGB18030対応ってのは、
UTF-16の中にGB18030の文字が入ってるから、
Unicodeアプリであれば、GB18030の文字が扱えますよってことだけ。
つーか、Win2000はオプションなんてないよ。
あるのは、
www.microsoft.com/china/windows2000/downloads/18030.asp
のパッケージを入れるだけ。
そうするとフォントとUnicode - GB18030ファイルの変換ツール、
変換テーブルなんかが入る。
地域と言語のオプションでちゃんと選択できるぞ。
ん？どこだ？
中国語とかは選択できるが、GB18030って選択できないぞ。
俺は、のモジュールはWin2000に入れててあるが。
キャラクタコード表で、宗体-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のロケールがあるらしいけど。
