BTRON仕様OSとUNICODEの多言語を語るスレ
おれの間違った認識による書き込み。すまん、Macを愛する方々。 >>27 ああ、「統合」とは言ってないんでしょうね。私の念頭にあった のは、たとえば(月並みですが)「鴎」の偏の問題です。 まあいろんな人が言っていることなのでここで書いてもしょうがない ことでした。 >>31 了解。その例は「通用字体の準用」。 新聞で使われている字体を採用したもので「作った」わけではない。 といっても、83年JISの変更を擁護する気はさらさらないけどね。 97 でデザイン差である、と強弁・詭弁を弄して、 「包摂」しちゃった、ってほうか? はしご高とか。 凶悪なのは「かき」と「こけら」なんかで、頭痛100%モノ だったりするのな。 「統合」という用語が使われるのは、Unicode および ISO 10646 の 'CJK Unified Ideographs' の訳で、 「CJK 統合漢字」だね >>33 脳内で話を作らんように。 97JISは口高と梯子高の違いを「字体差」とした上で 包摂していると思われ。 >>33 いえ、意図は >>32 の通りです。珍妙で無理のある「準用」でした。 すみまそんがこの話はもう止めにしましょう。 ちょっと勉強してきた。確認した限り、Mac OS Xてまだ全部の第三、第四水準の漢字を入れてはいなかったんだ。その態度、立派です。(提案の位置や外字領域に入れてると思ってました) >>36 それはMac OS X 10.0の理解としては間違いではないが、 いかんせん情報が古い。 JIS X 0213のBMP未収録分はExtension Bの一部として 2001年5月のUnicode 3.1で規格化され、 2001年9月のMac OS X 10.1でサポートされている。 >>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. って書いてあるぞ。 >>38 GB18030ってことは、 Surrogateもオッケーってことっすね。 突っ込みサンクス! ついでに質問。 Mac OS Xでは補助漢字にだけある文字はサポートしていない、っていうのはいまでも? はしご高はバリアントで表現してるよね? フォントに含まれていない文字を表示しなければならないとき、別のフォントを使って自動的に表示する機能はある? 暇があれば教えてくれるとありがたい。 >>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はなんかやりました!みたいな感じでアピールするけど。 >>40 > Mac OS Xでは補助漢字にだけある文字はサポートしていない、っていうのはいまでも? Unicode3.2をサポートしてるので、 その範囲内ならいくらでもどーぞ。 > はしご高はバリアントで表現してるよね? variant tagを使って表現ってことか? 違う。はしご高はU+9AD9に入ってる。 ちなみに、OSXについてくるヒラギノフォントを使えば、はしご高は表示可能だよ。 さらにSurrogate文字もちびちび、このフォントには入ってる。 例えば、U+29EBDとかも表示できる。 >>43 Uniscribeとくらべるとなあ。。。 盛り上げぶりが違うと思う。 おー、答えてくれてありがとう。 で、ATSUIのページを見てきたけど、違うみたい。 uniscribeって、リガチャーとかカーニングとかいうやつで使う奴ではないですか?(これをサポートしてないようでは多言語なんて言えないね>超漢字) 質問がわかりづらかったと思うんで、例を上げて説明すると ある文字の異体字フォントを作った。で、このフォントを使うとき、この文字以外はヒラギノで表示するようにする、みたいな感じです。 (Windowsだとアルファベットしか含まないフォントを漢字にも適用すると、漢字部分はトウフになるけど、Macはどう?こっちのほうがわかりやすい?〉 補助漢字はサポートし始めたんですか。ん〜、じゃあ、Mac OS Xの最初のバージョンで入れていなかったってのはなんでだったんだろう。(これも、俺の記憶違い?〉 はしご高をvariant tag〈こう書くのか、これも知らなかった)使わないのも意外。だいぶ昔、unicodeが言語指定をもたなかったころ、あれは中国の文字のためのコードだから日本語では使えない、とか聞いていたんだけど。 ちなみに、U+29EBDはBBBでは表示できなかったんで、なんの文字かわかりませんでした。(ゲタが4つも表示されたが、アレはなんだったんだろう?) >>45 できるみたいだよ。 例えばOmniWebだと、 デフォルトではLucida Grandeっていう欧文フォント使うようになってるけど、 漢字とかの表示には勝手にヒラギノが使われたりしてる。 どうでもいいことだけど、Lucida Grandeにεがあるのはいいんだけど、 これの字体が気に入らないんだよねぇ。 >>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"だよ。 >>45 ちゅーか、Unicodeがらみの話をするなら www.unicode.orgを見るように。 http://www.unicode.org/charts/ にすべての文字がある。で、 http://www.unicode.org/charts/PDF/U2F800.pdf を見れば、そのglyphがわかる。 >補助漢字はサポートし始めたんですか。 Mac OS Xに付属するヒラギノについて言えば、 補助漢字のすべてを含むわけではない。 ただ、JIS X 0213に含まれない補助漢字であっても Adobe-Japan1-4などを経由して入っている場合もある。 それから>>42 の言うとおりOSの枠組みとしては Unicode 3.2をサポートしているので、 すべての補助漢字を表示できるかどうかはフォント次第。 >はしご高を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との対応関係を持っているわけで、 現実にはこれを含まない実装は珍しいかと。 http://kado7.ug.to/net/ 朝までから騒ぎ!! 小中高生 コギャル〜熟女まで メル友 i/j/PC/対応 女性の子もたくさん来てね 小中高生大歓迎です 全国デ−トスポット情報も有ります。 全国エステ&ネイル情報あります。 激安携帯情報あります。 煽られてもねぇ... ついでに。>>52 ↓こういう現象があったりしますな。実際 ttp://www.microsoft.com/japan/support/kb/articles/J041/1/42.HTM non round-trip conversionの問題は有名だけど それがどうして52へのレスになってるのかわからん おっと出遅れた。>>57 に付け加えることはないな。 レス遅れてすいません。いろいろついてるなぁ。 >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ですか。憶えておきます。 >実現するかどうか不明ってのは、ちょっと不思議。いまでも、おんなじことやってるはずなのに。 >なにか問題でもあったんですか? variation selector(variant tag)は、 UnicodeあるいはISO 10646という「文字コード規格」が提供する機能であって、 当然、プレーンテキストでの情報交換を想定している。 要するにグリフ置換機構を意味する一般名詞「ではない」ってこと。 variation selectorで情報を交換するには、 そのための「異体字リスト」が必要となるが、まだそんなものはないし、 今後(漢字用のものが)策定されるかどうかも不明。 Appleがやってるグリフ置換はvariation selectorによるものではなく、 現状ではPDFなりを使わないと情報交換できない。 >60さん "Appleがやってるグリフ置換はvariation selectorによるものではなく、"この部分ですが、24日発売の新しいMac OS Xでは、OSレベルでのバリアントのサポートを実現するらしいので、たぶんv ariation selectorを使っていると思います。識者の方突っ込みお願いします。(前回の書き込み、途中で切れてた。これだからBBBは……) >>61-62 単に異体字(バリアント)をサポートしてるってことじゃねえの。 >63 いや、それは前からやってるんで。わざわざ発表することでもないと思う。 ところで、Mac OS Xのフォント呼び出しのメカニズムが書かれてたけどBTRONの【本来の】多言語処理ににてると思った。 unicodeやShiftJISが文字層で実際のフォントに割り当てられているIDがスクリプト層、と考えるとどうですか? どんな用語を使おうと、多言語処理でやるべきことは変わらんだろ。 しかしTRONコードの「スクリプト層」は見事に死んだな。 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. がしゅつかもしれんが 0213には0212とダブっている文字もあればそうでない文字もある。 0213にはUnicodeに入ってない文字もある。 BTRONっていつになったらスクリプト層が実装されるんだ? つーか文字属層(重複した文字を同じ文字として扱う)も実装されてないぞ。 66で出ていたリンク先を見てきました。まだ漢字用のは規定されていませんね。 しかし、実際にやるとなると統合漢字が問題となってくるような。 あれ、Mac OS XのOSレベルでの対応ってのはなんだったんだ。また俺の勘違いか? ところで超漢字で実装されてるのはスクリプト層とフォント層なんですが。 文字層で逆転できるもんが出来るのか?(「死んだ」とかまで言われてるし) それよりも現在作られ続けているスクリプト層だけで出来たデータは将来どうなる? >>67 が言ってるのは、インド系文字のリガチャとかを表現する (本来の意味での)スクリプト層のことだろ。 Unicodeによるなんちゃって国際化ってのは簡単にできるけど問題が多すぎ。 それに気づかないLinuxやXFree86は馬鹿。 問題は少ないかもしれんが簡単にはできない 本格的国際化とやらが実現する日を夢見て 国際化を見送り続けるよりはずっと現実的。 >>72 そしてどんどんドツボにハマっていく罠・・ ずっと絵に描いた餅を愛でていれば確かに ドツボに嵌る機会すらないね。 何も得られないけど。 >>74 そうはいうが、 Unicodeは、Shift_JISよりは、かなり良いわけだよね。 それでも不満なやつは、今のOSに関して、どれもだめなわけだよな。 ちなみに、BBBはSurrogateにも対応してない罠。 >>71 は国際化と多言語化の違いも分かっていない罠。 >>75 Unicodeは、最初の策定時に既に広まっていた 各国の文字セットを集めた交換用のテーブルと しては十分な出来ですもんね。 ただ、漢字圏について言えば中国のGB18030が 素晴らしいので、ちょっと混乱しそうですね。 >>76 は国際化と「アジアの猿共の言葉なんかどーでもいいよ、こんだけコード数増やしてやってんだから おとなしく俺らの考えた規格にしたがってろよ。アメリカマンセー」の違いも分かっていない罠 Unicodeの漢字領域は日本人が中心となって中国 韓国各々の代表者と綿密に検討して作り上げた 事実を知らない奴ハケーン てめぇらみたいなガキはどせヒマだろ?だったらこっちゃ来い ( 夢を見ている人たち 夢を見れない人たち 夢破れた人たち 夢を叶えた人たち 夢を追いかけてる人たち 夢を諦めた人たち そして 全ての馬鹿たちに送ります 『一炊の夢』 http://www.geocities.co.jp/Hollywood-Screen/9038/ >>79 なるほど。そいつらがアメリカマンセーだった訳ですね >>69 確かにスクリプト層自体は実装されている。 インド系の文字あたりを例として問題を列挙すると……。 ・スクリプト層に必要なグリフが実装されていない。 ・ていうか、それ以前に必要なグリフが仕様化されていない。 ・グリフ置換機構が実装されていない。 ・ていうか、置換機構が仕様化されてもいない。 ・ていうか、その前提となる文字属層の中身が仕様化されていない。 ・ていうか、文字属層の仕様化は目途すら立ってないと思われ。 >>77 GB 18030が素晴らしいかあ? 「TRONと比べれば」ってのはナシだぞ。 >>85 お前は放置されている事にいいかげんに気づけ(w >>83 TRONと比べてもUnicodeと比べても文字鏡と比べても 漢字圏にとっては素晴らしいぞ。 何が素晴らしいって、主だったOSが既に対応可能に なっているから。しかも、フォント依存ではなく。 その「主だったOS」に携帯のは入ってる? (クッキー使用強制でBBBから書き込めなくなった。こういう「主だったOS」しか考えないやつなんて大嫌いだ) >>87 拡張性で言えば、すばらしいのかもしれないけど、 Unicode3.1(正しい?)プラスアルファでしょ? だからたいしてUnicodeとかわらん気がするんだが。 もちろん異体字においてはUnicodeと同じ問題があるわけで。 ちなみにWinはネイティブキャラクタセットとしては GB18030はサポートしてないよ。(MacOS Xも) だから、NotePadとかでGB18030でセーブすることはできない。 UTF-16で、GB18030の文字は扱えると言っているだけ。 >>87 比較の対象がよくわからんのだが、 GB 18030って、文字セットとしては (収録のタイミングが多少ずれることはあっても) Unicodeと一緒だろ。 >>89 異体字におけるUnicodeと同じ問題って何だ? 骨がどうとかってやつか? >>90 何をサポートしてる? XPの中国語版であったって、ネイティブキャラクタセットは あいかわらずGBKだよ。GetACP()呼ぶと936って返ってくる。 GB18030のコードページ54936はMultiByteToWideCharとかのAPIでしか使えない。 だからnon-Unicodeアプリは、GBKでしかのデータを処理(たとえばセーブとかね)できない。 XPであっても、あくまでもGB18030は変換用のキャラクタセット。 それはネイティブキャラクタセットじゃあない。 >>91 基本的にGB18030は、Unicodeコンパチだから、 ハンのエリアは、unifiedされてるってこと。 >>89 Windows2000以降はオプションでGB18030対応 しますよ。 >>95 WinでいうGB18030対応ってのは、 UTF-16の中にGB18030の文字が入ってるから、 Unicodeアプリであれば、GB18030の文字が扱えますよってことだけ。 つーか、Win2000はオプションなんてないよ。 あるのは、 www.microsoft.com/china/windows2000/downloads/18030.asp のパッケージを入れるだけ。 そうするとフォントとUnicode - GB18030ファイルの変換ツール、 変換テーブルなんかが入る。 >>97 地域と言語のオプションでちゃんと選択できるぞ。 >>98 ん?どこだ? 中国語とかは選択できるが、GB18030って選択できないぞ。 俺は、>>97 のモジュールは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文字あたり2バイトしか対応してないから。 これって、Winの制限らしいよ。 IBMのAIXとかSunのSolarisは、ネイティブでGB18030のロケールがあるらしいけど。 >>99 中国語だ?簡体字(GB18030)ってのがあるだろ。 >>102 XPの話をしてるんだと思うが、 地域と言語のオプションのどこにでてくる? 詳細設定タブのコードページ変換テーブルのことを言ってる? それは、Unicodeとそのコードページのキャラクタセットの変換テーブルを インストールするかっていう設定だぞ。 >>95 つーか、このプログラムを走らせれば、 GBKがネイティブか、GB18030がネイティブかわかるぞ。 ---test.c--- #include<windows.h> void main() {printf("%i\n", GetACP());} ------ で、Cでコンパイルして、コマンドプロンプトでこのプログラムを走らせて味噌。 936ってでたら、GBK。54936ってでたらGB18030がネイティブってこと。 Unicode対応でないアプリケーションはこのキャラクタセットで動く。 ちゃんと「地域と言語のオプション」の「詳細」のところを、 Simplefied Chinese(簡体字中国語だっけ?)に言語を変えておくことね。 >>103 バカだ(藁 変換テーブルがあるってことは、使えるってことだろ? 小学生でもそのくらいわかるぞ。 >>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を使ってね。」 ってこと。 >>105 ネイティブがわかってないんでねーの? メモ帳だとShift JISはセーブできるけど、 GB18030のキャラクタセットではセーブできん。 セーブしたければ、Unicodeでセーブするしかない。 つまり、Winの拡大解釈で行くと、 Unicodeで、UTF-16 Surrogateまでサポートすれば、 自動的にGB18030サポートってことになる。なんだかなあー。 WindowsがGB18030をサポートしているかという 話題を「ネイティブ」サポートしてるかという話に 勝手に摩り替えているバカはここにいるのですか? ああ、メモ帳は確かにサポートしてないかもね(藁 メモ帳がWindowsだと思ってんの? UTF16とGB18030の変換テーブルが搭載されれば、 アプリケーションがGB18030で保存する機能を搭載 するだけで対応完了。 話題になるのはUnicodeやGBばかり TRONコードはいずこへ >>108 >>83 >>87 >>89 と話がきてるから、Winは、ネイティブサポートしてないってのは 話しの流れからしてあってると思うぞ。 >>108-110 それじゃあ、GB18030のキャラクタを含んでる、 WinのUTF-16サポートは、すばらしいねって言うべきだろ? > アプリケーションがGB18030で保存する機能を搭載 > するだけで対応完了。 それだけじゃだめ。 Win32のUnicode APIに全部置き換えなくちゃ。 メッセージもすべてUnicodeで書き換えなくちゃだめなんす。 つーか、Win32で、Native API、Unicode APIがあるってこと わかってないだろ、きみ。 まさーに、>>110 がMSの言ってることなのは確か。(Appleもね) でもこれが困惑させるもとなんだと思う。 メモ帳の問題の話がでてたけど、それだけじゃない。 コマンドプロンプトもGB18030は入力、表示できない。 そもそも、printf()で、GB18030のコードを入れても表示できない。 Win9xで動くようにネイティブAPIのみ使ったアプリは、GB18030データ もちろん壊れる。 それは、中国版WinXPのOSのデフォルトのキャラクタセットは相変わらずGBKだから。 Winが、GB18030ネイティブサポートしてたらこれらは動いたはずなのだが。 >>110 それじゃあ、ICU使ったほうが良いということで。 oss.software.ibm.com/developerworks/opensource/icu/project/ >>114 病気ですか? 自分以外はUnicodeAPIを知らないと何を根拠に騒いでいるの? >>117 おいおい、病気はあんただ。 >>114 読んで、「自分以外はUnicodeAPIを知らないと何を根拠に騒いでいるの?」 とは思えないんだが。。。 つーか、Win2000/XPがGB18030をネイティブキャラクタセットとして サポートしてないのは正しいと思うぞ。 >>117 つーか、病気は、うぃんちゅうじゃねーか? >>92 に反応しただけで、スレちゃんと読んでねえし、 特に>>95 あたり適当なこと言って、反論されて、 虫のいどころがつかねえから、最後まで怒ってる。 話を戻そうぜ。>>87 に戻るけどさGB18030はTRONコードの代理にならんよ。 GB18030はUnicodeの定義されてる文字を参考にして作ったという感じがする。 WinはGB18030に対応してないと言い張る病気の人はまだいるの?(藁 >>115 printfってWinのAPIには無いぞ(藁 対応してないのは君の使ってるライブラリだよ(藁 >>120-121 しつこいうぃなはされ。 >>121 WinのAPIにはCRTというかたちで実装されてるぞ。 Win32 APIのなかにはないが。 >>122 TextOut使えばちゃんとGB18030で表示できるぞ。 対応してないのはお前だよ(藁 printfで表示できないのはね、printf("...")ってやるからだよ。 printf("%s", "...")ってやらなくちゃね。 めっちゃ基本。 それと、勘違いがあるようなので言っておくが、printfを実装しているのは、 Winではなく、コンパイラのライブラリ。 それはライブラリの仕様であって、Winの仕様ではない。 >>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に渡すことはできない。 >>125 はあ??できないっつーの。 ネイティブキャラクタセットがGBKなんだから。 >>126 > それと、勘違いがあるようなので言っておくが、printfを実装しているのは、 > Winではなく、コンパイラのライブラリ。 なんだよそれ。 printfは、Winのmsvcrt.dllに含まれてるよ。 もちろんprintfはstaticリンクもできるけどね。 それとほとんどのWin32 APIはdllへのコールだ。何が違うんだ? read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる