BTRON仕様OSとUNICODEの多言語を語るスレ
それと、勘違いがあるようなので言っておくが、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へのコールだ。何が違うんだ? で、 Winのネイティブキャラクタセットは、 Windows2000以降はオプションでGB18030対応しますよ と言い張る病気の人はまだいるの?(藁 つーか、Win2000以降で、GB18030みたいに、 Shift JISのネイティブサポートなかったら、激怒だよ。 よく中国は納得したと思う。 いやいや、まったく、誰でも知ってることと、大きな間違いを得意げに 並べてとんだ恥さらしですな(藁 WinでGB18030はサポートされてます。 >>132 >>127 ですが、どこがまちがってるなら、指摘してくれ。 >>132 まあせいぜい、一生かけて、Win2000かXP上で、 printfでGB18030の4バイト文字表示するサンプルコードでもぜひ作ってくれ。 できたらここにソースをのっけてくれ。それまでもどってくんな (w WinのシステムキャラクタセットはGB18030をサポートしません。 >>132 の彼は、どこが大きな間違いだと思って思ってたんだ? 具体的に1つ1つ説明してもらいたい。 でも、やつのprintfとかの話は、ぽかーん。 やつはたぶん>>95 だろうと思うんだが、 それならなんで>>89 に対してからんでくるんだ? まあ、>>132 程度のあたりさわりないことなら、 BTRONでもGB18030はサポートしてますってことになる。 Winでも、euc jpとかiso-2022-jpとかもサポートしてると言える。 だが、それは、スレ違いだよな。 OSのネイティブキャラクタセットの話じゃないからね。 まだ言ってるのか(藁 メモ帳とWindowsの違いはわかったのか? TextOutがマクロだってことなどが誰でも知ってることで、 メモ帳とprintfでサポートされることがネイティブサポートだという主張が大きな間違い。 その他、突っ込みどころは満載だが、基本的なところからいちいち小学生に説明するのは 時間がかかるので、適当な入門書でも読んでくれ。 WindowsがGB18030対応しているのは、明らかな事実。 それを対応してないと苦しい言い訳をしてるところが恥ずかしい。 >>139 じゃあ、TextOutにGB18030のEncodingの4バイト文字を 直接わたせるってのか? そんなのはMSDNにも書いてないよ。(w >>137 なんかややこしいことになってるが、 ・システムレベルで変換ルーチンを持っている ・すべての文字を表示できる(こっちはオプション) を満たせばGB 18030をサポートしていると言っていいんじゃねーの。 内部コードとして何を使おうが勝手だろ。 Windows XP/2000、Mac OS 10.2はこの条件を満たしているが、 超漢字4はどちらの条件も満たしていない。 >>139 > それを対応してないと苦しい言い訳をしてるところが恥ずかしい。 だいたい、その拡大解釈じゃあ、 TRONコードだってUnicodeや、GB18030対応してるよ。 ネイティブキャラクタセット(システムロケール)としては GB18030は対応してないと言ってるだけだ。 コマンドプロンプトも対応してない。 MultiByteToWideCharと、WideCharToMultiByteはGB18030の 文字コードは入れられるが、(そりゃね。変換するからね) それ以外のNative APIは,GB180304バイトコードはだめ。 WM_GETTEXTは、GB180304バイトコード入れられんし、 TextOut、SetWindowText、もろもろのWin32 APIに対しても、 GB18030の4バイトコードは直接入れられない。 Shift JISは直接入れられるけどね。 > だいたい、その拡大解釈じゃあ、 > TRONコードだってUnicodeや、GB18030対応してるよ。 してない。 >>141 > 超漢字4はどちらの条件も満たしていない。 そうなのか? 超漢字4はGB18030の文字が TRONコードを使っても表示できないのか? WinはUTF-16を使えばできるが。 >>144 おれもそれを聞きたい。 BBBがSurrogateをサポートしていないと言う話はでたが、 TRONコードを使ってもGB18030の文字を表示できないとは。。。 だめじゃん。超漢字。 144-145 表示できないはず。だが、「できない」ことを立証するのは難しいので とりあえずTRON者の反論待ち。 >>141 > 内部コードとして何を使おうが勝手だろ。 だいたいもとの話はプラットフォームがサポートしてるって 話じゃなかったんだよ。 TRONコードと比べてるあたり、OSの内部コードの話じゃなかったのか? Win2000はサポートしてるかどうかなんて出すから話がわけわかんなくなる。 そんなのWin2000/XP、OSX, AIX, Solaris, HP, Linux 最近のUnicode対応のOSならあたりまえ。 で、変換の話なら、ICUで一発だよ。 ところで>>139 は>>125 なのか? >>125 にはわらた。 GB18030がprintfで表示できないのは、 > printfで表示できないのはね、printf("...")ってやるからだよ。 > printf("%s", "...")ってやらなくちゃね。 > めっちゃ基本。 だって。ウケタ。。。 え?マジで知らないの? printfを使う時は基本だよ! msvcrt.dllって、VCのランタイムじゃん。 こういうのは、ライブラリの仕様って言うんじゃねーの? つーか、Unicodeの統合漢字の2.0から入ってるやつさえ 表示できなかったりするし。>超漢字4 >>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された文字データを直接渡すことができる。 >>150 > msvcrt.dllって、VCのランタイムじゃん。 ワラタ。 printfは、msvcrt.dllにあるAPIで、 TextOutA/Wは、gdi32.dllにあるAPIだが、なにか? >>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もサポート可能だったのに。 >>141 > ・システムレベルで変換ルーチンを持っている > ・すべての文字を表示できる(こっちはオプション) > > を満たせばGB 18030をサポートしていると言っていいんじゃねーの。 > 内部コードとして何を使おうが勝手だろ。 その通り。それを満たせばサポートしていると言える。 >>155 > 話してるのは、WinのGB18030サポートは、Shift JISサポートに比べると > ださださ、おそまつだねーってことだと思うんだが。 ちがいますね。「サポートしている」という意見に 対して執拗に否定してかかる奴がいますからね。 > GB18030のネイティブキャラクタセットのサポートはされてないし、 「ネイティブキャラクタセットとしての」サポート云々は 話のスリカエですよね。 或いはネイティブキャラクタセットとしてのサポートに 拘るのも面白いかも。 例えば… 『BTRONはShift_JISもUnicodeもサポートしていません。 いずれも、その文字セットど同内容をTRONコードの 各面内に含んでいるだけに過ぎず、ネイティブサポートは あくまでTRONコードだけだから』 とか。 >>153 だから、ちゃんと変換APIが用意されてるところが、OSとしてのサポートなのよ。 エンコーディングなんか星の数ほどあるんだから、その数だけTextOutを用意するのは たわけてる。 サポートの方法としては、 1. TextOutにエンコーディングを指示するオプションを付ける 2. TextOut呼び出しの前にUNICODEに変換できるようAPIを用意する があるわけだが、Windowsはその2番目の方法を取った。 それのどこがサポートでないって言い張れるんだ? バカなの? 勘違いがあるようなので言っておくが、printfを実装しているのは、 Winではなく、コンパイラのライブラリ。 それはライブラリの仕様であって、Winの仕様ではない。 msvcrt.dllは、その名の通り、MicroSoft Visual C Run Time.dllなわけ。 つまり、動的リンクできるVCのライブラリ。 それと、ネイティブって言葉を何か勘違いしているようだが、 君の言ってる「ネイティブ」は、一般に「デフォルト」って言葉で表されてる 概念だと思うぞ。 Winは、GB18030をちゃんとサポートしている。 つまり、OSレベルでのサポートであるから、これを一般にネイティブサポートと言う。 そのうち、UIなどでデフォルトとして扱われるエンコーディングがもちろんあるわけだ。 これのことをネイティブって言ってるんじゃねーの? これはあくまでデフォルトなわけだから、ちゃんとまじめに作られたアプリなら デフォルトじゃない設定も使えるわけ。 なぜ君の作ったアプリで使えないのかというと、それは「君のアプリが」GB18030に対応してないってだけだよ。 Winじゃなくてね。 「ロケール」とか「国際化対応」って章をもっと良く読んでみることだね。 それから、printfにリテラル文字列を渡す場合、%sを使うのは常識。 でないと、日本語でも、2バイト目に\や%が使われてる文字が不具合を起こす。 これは、printfの仕様、そしてライブラリの仕様であって、それによる 不具合はプログラマの責任。決してOSの責任じゃない。 >>157 > ちがいますね。「サポートしている」という意見に > 対して執拗に否定してかかる奴がいますからね。 > > GB18030のネイティブキャラクタセットのサポートはされてないし、 > 「ネイティブキャラクタセットとしての」サポート云々は > 話のスリカエですよね。 つーか逆のような気がするが。 >>89 の返答として、>>95 になったのが変、 ネイティブキャラクタセット -> Win2000はサポートしてる。 にすりかえられたのが最初。ちゃんとスレを読むように。 >>161 用は、 msvcrt.dllはWindowsの一部ではなく、 gdi32.dllはWindowsの一部だと言ってるのか?(わら >>160 あんたもばかだ。 > 1. TextOutにエンコーディングを指示するオプションを付ける > 2. TextOut呼び出しの前にUNICODEに変換できるようAPIを用意する > があるわけだが、Windowsはその2番目の方法を取った。 ShiftJISはどちらにもあてはまらんぞ。(w >>158 >『BTRONはShift_JISもUnicodeもサポートしていません。 >いずれも、その文字セットど同内容をTRONコードの >各面内に含んでいるだけに過ぎず、ネイティブサポートは >あくまでTRONコードだけだから』 それを言うならSJISじゃなくてJIS X 0208だろ。 それから超漢字4は、 Unicodeについては「文字セット」としてもサポートしてないぞ。 超漢字2なら(文字鏡が入っていれば) Unicode 2.0まではカバーしてたんだけどね。 >>158 > 或いはネイティブキャラクタセットとしてのサポートに > 拘るのも面白いかも。 あのー、その話をしてたら、 Win2000は、GB18030サポートしてるぞって、わけわからん話が とんできたんですが。。。 あんたの意味での、 BTRONはGB18030サポートすればって話してたら、 ISCIIサポートすれば、ISO-2022-JPサポートすれば、 でCharset一通り言って、このスレおしまいになっちゃうよ。(W >>164 なぜ君は>>89 が発端だと言い張るのだ? 最初の>>87 に対する君の>>89 がズレてるのだと思うが。 >>162 つーか、Unicodeアプリで作ればって話は既出。ちゃんとスレよめ。 Nativeってのは、A Functionで実装したら GB18030は対応できないと言ってるんだよ。 (ShiftJISやBig5やGBKは、A Functionで実装できるが) ようは、GB18030他のに比べておそまつだって話。 それをWinはGB18030サポートしてるだとさ。 はいはい。それは既知。 >>169 いいんじゃないの?それはそれで間違ってないんだから。 むしろ、そのあとで、それを勘違いして、 WinはGB18030をサポートしているとの主張がいたいと思うんだが。 おっと、 >>171 はWinはGB18030のサポートをしていないと 言ってるんではないからね。 >>166 一つのデフォルト言語に対して特別な処置をとれば処理が単純になるという、それだけの話。 ショートカットのような物。 まだネイティブでサポートしてないと騒いでる奴がいるのか(藁 恥の上塗り(藁 >>170 あのさ、ShiftJISとかBig5とかGBKとかってのはさ、 地域化の時代のベタなサポートなわけよ。 それを国際化時代のサポートと比べて、 しかも地域化の観点から優劣を問うのもどうかと思うが。 >>167 まじでさ、超漢字にICUをポーティングするってのはどう? そうすりゃあっというまに、 超漢字もXXXサポートしてますって言えると思うんだが。 >>175 べたなサポート大事だと思うぞ。 Win,Mac以外はそれに対応してるんだからね。 今までGBKで動いてたアプリを書き換えなくちゃならなくなるとすれば、 そりゃベンダにとっては大変でしょう。 MSは4バイト文字がもう機構上実現できなくなったってのが本音かも。 >>174 > まだネイティブでサポートしてないと騒いでる奴がいるのか(藁 話ぼかすのうまいね。 ネイティブで何をサポートしてないと騒いでるというのだ? >>174 の(藁は、やつか? WinがGB18030サポートしてるってずっと スレ違いなこと言ってるのは。 >>181 最新版は0.19かな。 あれはなんつーか、別世界の話だわな。 UTF2000か、TRONコードと比べてどうよ? emacsの実装してるとか聞いたが。 >>178 話ぼかすの下手だね。 Winとメモ帳の区別はつくようになったか? 開発言語のライブラリのAPIとWinAPIの区別はどうだ? WindowsはGB18030に対応してないと言い張る ↓ ボロボロに論破される ↓ そんなこと言ってないと言い張る ↓ ぷぷぷ >>164 > つーか逆のような気がするが。 > >>89 の返答として、>>95 になったのが変、 なんで話の途中を起点であるかの様に摩り替えるの? 89は87に対する返答でしょ。 >>87 >主だったOSが既に対応可能になっているから。 > しかも、フォント依存ではなく。 どこにネイティブサポートだって書いてあるのさ? >>186 >>89 がWinはGB18030をサポートしていないとは書いてないんじゃないの? そのサポートはださいっていう話なんだよ。 だから、>>95 はUnicode変換テーブルをインストールするかのオプションだろ? つーか、そのあとの話で、WinはGB18030サポートは実質変換だけって 話が出てると思うんだが。 >>186 つーか、孟宗君は、TextOutのAバージョンででGB18030の 4バイト文字表示するソースコードと実行の仕方見せてみ? そうしたらあんたの言ってること信じてやるよ。 まあ、できない孟宗君は、さっさと帰ってね。 なんというか、超漢字は、ふざけてるよなあ。 トンパ文字パックが3万近くしているのは、驚いた。 WindowsはGB18030ネイティブでWin32 APIを呼べると言い張る ↓ 自分の意見がぽろぽろ変わっていく。 ↓ 最後の牙城は、WinはGB18030サポートしてないと言ったろと主張するだけ ↓ ボロボロに論破される。 ↓ Win32 APIでもできるよというが、ソースコードも提示できない。 ↓ ぷぷぷ >>185-186 まだ、WinはGB18030サポートしたのしないの話したいのか?おめーは? つーか、なにをそんなにWinをかばってんだ?うぃん厨君。 WinのGB18030サポートのダサさに話題を移しまいと必死ですな。 なんでこの程度で論破とか平気で書けちゃうんだろ。 これのほうがぷぷぷだと思うなあ。 まあ俺は野次馬なわけだが。 >>191 まあ、うぃんちゅーはそんなもんだろ。藁 >>192 まあさ、今のところは、 ソースが出たら話が面白くなるんでねーの。 TextOutAではどうやってもGB18030の4バイトコードは出せないと思うんだが。 >>186 =>>187 は、 >>100 ,>>106 あたりを読んだのだろうか? WinはGB18030サポートしてないと読み違えてるあたりがイタイ。 さらに、それを>>200 近くまで、ひっぱってくるあたりがイタイ。 >>192 > まあ俺は野次馬なわけだが。 あんた張本人のうぃなちゅうだろ。 >>195 バカですか? 誰一人として、『Windowsの内部コードはGB18030だ』 なんて書いていないのですが。 争点は、内部コードであるUnicodeとの変換テーブル内蔵 するのが『サポートといえるか』でしょう。 『内部コードとして採用していないからサポートと言えない』 という論点でカキコしている奴がバカなんですよ。 え、そんなこといっていない。ダサいかどうかを論じている ですって? それじゃ、そもそもなんで>>87 にくってかかってきた んですか? >>197 Win2000/XPはGB18030をサポートしていると言える。 なぜかっていうと、MicrosoftがMicrosoft.comで サポートしてるって言ってるから。 はい。おしまい。さ、もーそー君は帰っていいよ。 あ、そのまえにprintfとTextOutAでGB18030の文字表示する ソース出してってね。ちゃんと動作方法も書いといてね。 だれも>>87 にくってかかってないから、 心配だったら、今日は帰って薬飲んで早めに寝た方ががいいよ。 WinのGB18030サポートはださいのはしょうがない。事実は事実なんだから。 >>197 そうそう、Windowsの内部コードの話なんてだれもしてないから。 WinのAPIが受け付けるコードの話をしてるだけ。まあ、帰れって。 printfはライブラリ依存だって書いたんだが、理解できなかったか? 用語がむずかちちゅぎまちたかね〜(藁 それと、TextOutの前にUNICODEに変換する方法でサポートしてるとも 書いたんだが、幼い子にはちょっと無理だったかな(藁 それと、まだmsvcrt.dllがVCのライブラリじゃないって思ってるの?(藁 Windows2000はGB18030をサポートしている という意見に噛み付いたあげく、論破されるや 俺は最初から対応していると主張しているんだが? といった態度に豹変して逃げをうってるバカが常駐 しているスレはここですか? >>201 > printfはライブラリ依存だって書いたんだが、理解できなかったか? "%s"でやりゃできるって言ったじゃんかよ。 >>202 それは、君の言う前にスレに出てる。 人の言ったことをそのまま繰り返してるおーむがえしくん。 「ぴーちゃん、おはよ。」「ぴーちゃん、おはよ。」みたいな。 >>203 > それと、まだmsvcrt.dllがVCのライブラリじゃないって思ってるの?(藁 VCのライブラリかどうかなんでだれも話してないぞ。 Windowsのdllかどうかを話してる。 >>205 > Windows2000はGB18030をサポートしている > という意見に噛み付いたあげく、論破されるや ひがいもうそう君なんだよな。 WinはGB18030サポートされてます。 -> でも、Shift_JISの他のキャラクタセットに比べてかなりの制限があるよ。 って話しってのが、これだけでてるのに、まだ見えない。 君を攻撃してるわけじゃないから、そんなにおびえるこたない。安心しな。 あ、>>209 は、 WinはGB18030サポートされてます。 -> でも、Shift_JISのような他のキャラクタセットに比べてかなりの制限があるよ。 ってことね。 >>202 つーか、言われて、気が付いて、収拾つかなくなって、 WinはGB18030サポートしてないって言ってるやつがいると思ってる。。。 最初からいないのにね。 へんなものやっちゃったんじゃないか? 俺をねらってるやつがいる、俺をねらってるやつがいるって。 >>209 そうそう。 流れとして、MultiByteToWideCharなんかの話がでてるんだが。 やつにはMultiByteToWideCharとかの話が理解不能だったらしい。 MultiByteToWideChar/WideCharToMultiByteがサポートしてるんだから、 WinはGB18030をサポートしてるって話をしてるのあたりまえだ。 まあ、もーそーくんだからしょうがないといえばそうなんだが。 >>212 まだ勘違い君がいたのか。 その話はとっくに出ていて、問題は「それが 『サポートしているじゃん』という意見に対して なんで噛み付く理由になるの?」ということ なんだが。 んー、なんか単純に 87に対して勘違いツッコミしてきた89と、その89に加勢した奴=バカ 89とそれに加勢した奴をバカと言える奴=まとも てことで結論でてると思うんだが。 >>205 安心しなよ。WinはGB18030をサポートしてる。 それに君のことをだれもかみついていないよ。だからお帰り。 WinのGB18030サポートがださかったのがいけない。 家にもどって、printfとTextOutAでGB18030を表示するプログラムでも 作ってたほうが良いと思うよ。 >>214 まあさ、>>87 が>>89 を読み違えて被害妄想をここまでひっぱってきてるってのが 正しいところだろうな。 >>89 で 「UTF-16で、GB18030の文字は扱えると言っているだけ。」 ってのがなんで 「WinはGB18030サポートしてない」に変わるのかよくわからんと 思ったぞ。 >>217 まあ、噛み付かれてると勘違いのもーそー君のことなんだから、 何言ってもしょうがないさ。 しかし、やつは、最後まで、 WinのGB18030サポートはださいと言えないのは、またまたイタイ。 >>213 なんで俺をいじめるんだよー。ってか?(わら >>87 を罵倒したやつはいない。だれも噛み付いてない。 だれもWinはGB18030サポートしてないとは言ってない。 大丈夫、大丈夫。なんか>>213 は疲れてるんだよ。さあ、お帰り。 いやあ、会社にもこういうやついたよ。 「私が間違ってるっていうんですか!じゃあ何で私に噛み付いてくるんですか!」 って言い出すやつ。 課長が、なだめてるんだけど、会議でそいつずっと怒って、 そのあとの話だいなし、場はしらけるみたいな。 >>221 そうそう!そういうの困るんだよね。 別にだれもそうじゃないって言ってないのに、そいつは怒りだして、 なんで俺がなだめなくちゃならないの?ってな雰囲気。 「対応可能」という言葉が「サポートしている」という言葉に変わって、 そのサポートがださいのしょぼいのいう話に変わっているわけですね。 まるで伝言ゲームだなぁ。文字という手段を使っているのに情けない。 >>206 できるとかできないって誰が書いたんだよ? ライブラリ依存って書いてあるじゃんよ(藁 ライブラリ依存ってのはね、 「できる場合もあるしできない場合もある」って意味だぞ(藁 そこまで基本からわかんないと、時間かかるねぇ(藁 ウィンはGB18030に対応してます。 そう言ってるだけなのに、「対応してない」と言ってない奴が何でかみつくの?(藁 対応してないと言ってしまったから、自分が責められてるように思うんだろ?(藁 言い訳苦しすぎ。 対応してることが理解できたなら、それでいいじゃん。 ほら、「その程度でサポートしてると言えるなら他のどのOSでもサポートしてる」 とか何とか言った奴がいただろ?(藁 それがお前じゃないなら黙ってろよ。 ムキになるからお前だってバレバレなんだけどね(藁 >>223 >「対応可能」という言葉が「サポートしている」という言葉に変わって、 そう。具体的な例として、Win(Win2000/XPね)をあげたわけ。 だから別に君に噛み付いてないってことが、やっとわかったか? 被害もーそー君。 「サポートしている」というのは、MSが言っているから。 >>142 >だいたい、その拡大解釈じゃあ、 >TRONコードだってUnicodeや、GB18030対応してるよ。 えー?してないよぉ! というわけで、とっととお帰り。頭ひやしたほうがいいぞー。 >>227 ほらほら、意味わかんなくなってきたぞ(藁 拡大解釈ならサポートしてると言ってた君。 君の定義じゃサポートしてないんだよね?(藁 それが今度はサポートしてる派に変わったの?(藁 もし君が>>142 じゃないなら、噛みつかれてるのは君じゃないから、 引っ込んでなさいな、被害妄想君(藁 ついでに言うが、頭冷えてないのは君だけだぞ。 何で自分が噛みつかれてる気がしたの?(藁 >>230 なんで意味わかんなくなってきたんだ?拡大解釈だってさ。ぷぷぷ。 MSがサポートしていると言ったらしてるわけよ。あんたが拡大解釈してんだよ。 GB18030はライブラリ依存ですだって。 printfはに含まれてるから表示できないだって。ぷぷぷ。 gdi32.dllはライブラリじゃないのか? >>142 以前にいろいろ変なこと言っといて、なんか>>142 だけのネタを 昨日一生懸命考えてたんだね。ぷぷ。 >>230 やっと、WinのGB18030対応はださいと、悟ったとたんに、 あとは、とことんテクニカルとは程遠い会話するようになったな。。。 ちなみに printfが「ライブラリ依存だから、」(この表現わけわからん) GB18030表示「できる場合もあるしできない場合もある」は まったくでたらめ。 GB18030がコマンドプロンプト上で表示できないのは、 MSがMSのサイトでそう言ってるから。 つーことで、 printfでGB18030表示 できる場合をあげてもらおうや。 >>95 > Windows2000以降はオプションでGB18030対応 > しますよ。 これって、>>230 だろ。 ちなみにWin2000はGB18030のオプションはありません。 Win2000はオプションで対応してない。 >>236 つーか、オプションないよ。APIで対応してる。 だよな。 Win2000のコンパネの地域ところの設定は、 GB18030なんて何もない。 >>235 > つーことで、 > printfでGB18030表示 > できる場合をあげてもらおうや。 特に、4バイトキャラクタ表示できる場合の例をあげてくれ。 よろしく。 >>230 > もし君が>>142 じゃないなら、噛みつかれてるのは君じゃないから、 > 引っ込んでなさいな、被害妄想君(藁 ちみは、その前からエンジン全開で噛み付いてるじゃん。w 煽り合いには参加したくないんだけどさ、SJISやGBKってのは、 当時、内部コードとしてサポートするしかなかったわけだよな。 しかし、GB 18030は変換テーブルでサポートできる。 国際化された環境で、いまさら地域化なんてしたくないのは当然。 たとえばJIS X 0213はSJISを拡張する符号化を提案したが 受け入れられず、Unicode経由でサポートされることになった。 GB 18030(拡張GBK)のサポートはそれと同様の事例であって、 サポートが貧弱だとかってことじゃないだろ。 UNIX系のシステムがGB 18030を内部コードとして サポートしているのは、もともとISO 2022的な発想が強く Unicodeすら「文字セットのひとつ」ととらえる文化だからだと思うが、 WindowsやMacintoshはそうじゃなく、Unicodeによる国際化が基本。 いや、その方針に異議があるならそういう議論をしてもらっても いいんだけどね、サポートが「ださい」とか連呼するばかりなのも いかがなものかと。 まだ続いてるのか(藁 サポートしてるわけねーだろ(藁 文字列をUNICODEに直して表示するprintfだったら表示されるだろ? こういうのをライブラリ依存って言うんだよ。 勉強になったね(藁 わけわからんのは君の勉強不足。 ライブラリ依存って言葉くらい、常識だから知っといてね。 >>242 まだ言ってるのか(藁 サポートしてないわけねーだろ(藁 >>239 UNICODEに直してからって繰り返し言ってんじゃん。 文盲? >>241 それはアプリ側の都合というより、WinやMacの都合なんだろうな。 だから、Win9xをサポートしてきたアプリベンダは、 まず、Unicode化しなくちゃならないという、けっこう大変なことがまってる。 ただし、LinuxやAIXやSolarisなんかは、GB18030でAPIを呼べるわけで、 それからみればそういう不満がでるのは当然だと思うぞ。 >>243 > 文字列をUNICODEに直して表示するprintfだったら表示されるだろ? だめなんだよね。 そもそもコマンドプロンプトがGB18030をサポートしてないから。 >>249 宗体(SinSum)-18030ってのがGB18030対応。 Surrogate文字は入ってないけどね。 Surrogate文字が入ってるのは、OfficeXP中文版についてる。 とりあえず、それを使って、 printfでできたっていうのなら、ソースをくれ。 >>241 GB18030のケースの場合は、JIS X 0213とかのケースとかなり違うと思う。 GB18030をサポートしていないソフトウェアは中国では売っちゃいけないことになった、 つまり、売った場合違法になる。 で、どこまでなら、GB18030サポートと呼べるのかということだけど、 GB18030表示、入力をはじめ、ユーザがファイルでGB18030を出力することが できるというところまでが中国の要求。 中国としては、これから、GB18030をGBKのようにレガシーEncodingとして使っていきたいんだが、 Winの場合、 使いにくいGB18030テキストファイル変換アプリをつけた。 コマンドプロンプトでGB18030表示はできない。 システムロケールのCharsetとしてはGB18030はサポートしない。 NativeAPI(A Function)ではGB18030はサポートされない。 と、中を開けてみれば、いろいろな制限があって、かつてのGBKのようには使えなくなってしまった。 やっぱり、アプリベンダや、ユーザは、WinのGB18030に不満があるのはわかる。 >>252 > ユーザがファイルでGB18030を出力することが 入力もね。 >>241 Unicodeの中で、GB18030を扱おうと言った場合、 一番の問題は、変換でのラウンドトリップの問題だよね。 GB18030間でUnicode変換してまたもう一回変換してたりしているうちに、 違うコードポイントになっちゃう。 で、あとでうっかりバイナリ比較した場合、違うなんてことになる。 これは根が深いと思うんだが。 >>226 > ほら、「その程度でサポートしてると言えるなら他のどのOSでもサポートしてる」 > とか何とか言った奴がいただろ?(藁 いたよねぇ。(w しかし、その程度でサポートしていると言えても 超漢字はサポートしているといえない罠。 >>252 >中国としては、これから、GB18030をGBKのようにレガシーEncodingとして使っていきたいんだが、 >と、中を開けてみれば、いろいろな制限があって、かつてのGBKのようには使えなくなってしまった。 中国がGB18030をGBKと同じ様なアプローチで サポートして欲しい…というのは事実?それとも キミの脳内ストーリー? W2KのGB18030を中国サイドが承認したという事実は 無視? >>255 バイナリ比較ってのはUnicodeコレーションアルゴリズムじゃなくて、 単にstrcmpとか使ってる場合ってこと。 >>251 いい加減、「ライブラリ依存」って言葉くらい調べろよ。 頭悪いにもほどがある。 >>256 > 超漢字はサポートしているといえない罠。 そういえば、超漢字だか、BTRONだかの 中国向けパッケージって昔でなかったけ? あれもGB18030対応できなかったのかな。。。 >>259 「できる場合もあるしできない場合もある」 と言うから、わけわからなくなるんだよ。 だから、できる場合を見せてみろってことなんでないの? ところで、MSが「ライブラリ依存」と言ってるのか? MSが言わなくてもライブラリ依存じゃねーか。 ライブラリの意味わかってるか? そっから説明すんの? 面倒くせー たとえば、VCじゃなくて、gcのライブラリを使えば、GB18030がそのまま printfで表示できるだろ? ライブラリによってできたりできなかったりするからライブラリ依存。 ライブラリの意味くらいは自分で調べてくれるよねぇ? それとも調べる知能すら無いの? で、最初に話してた、VCだと"%s"で、GB18030表示 できるのか? GB18030からUNICODEに変換して、コンソールのコードページをUNICODEに変更し、 printfを使えばいいだろうが。 変換してから使うのがWinの流儀だって、いったい何度言わせる気だ? で、Windowsのmsvcrt.dllだとどうなんだ? msvcrt.dllはVCのライブラリだって何度言わせる気だ? ソニーが自社のパソコンに自社ソフトを山ほど組み込んで売るように、 MSは自社のOSにVCのライブラリを組み込んで売る。 これは単にVCのライブラリをOEM添付しているだけであって、 msvcrt.dllはWindowsのシステムファイルではない。 msvcrt.dllはWindowsのライブラリじゃないのか? なんでこれには答えんの? >>272 じゃあ、user32.dllはWindowsのライブラリじゃないのか? >>272 msvcrt.dllはソースがくばられてるんだから、 GB18030に対応してるか言えるんでないの? じゃあ、対応してるか言ってもらおう。 その前に、gcって何? >>272 じゃあ、WIndowsってどこからどこまでを言うんだ? Windowsのretail版を買えばついてくるdllがすべて Windowsの一部ではないのか? >>87 の噛み付き野郎は、朝早く来て、そして2時間噛み付き、 そして帰って行く。。。 user32.dllはWindowsの一部に決まってんじゃねーか。 ユーザーインターフェースを担うライブラリだ。 どこのバカがこれとVCのランタイムと同列に扱ってるんだ? おいおい、頭悪いのは十分わかったから、これ以上笑わせるなよ(藁 もちろん、広義ではmsvcrt.dllもソニーの添付ソフトもWindowsの一部と 言って言えないことはないわけだが、ここで話してるのは、Windowsが ネイティブにGB18030をサポートしてるかどうかって話だ。 だから、ソニーのソフトがサポートしてなくても、それすなわち Windowsがサポートしてないことにはならない。ここまではわかるね? 同様に、VCがサポートしてなくても、それすなわちWindowsが サポートしてないことにはならないわけだよ。 で、msvcrt.dllってのは、VCというれっきとした別商品の一部を、 同じ会社だってことで同梱してるだけ。 user32.dllはWindowsの一部として配布、msvcrt.dllはWindowsに同梱、 この違いもバカには難しいかな? msvcrt.dllの中のprintfは、GB18030をサポートしてないが、 それはWindowsがサポートしてない根拠には全くならない。 わかるかな? まだわかんない? バカだね〜(藁 >>281 やっと言ったよ。サポートしてないって。w >>281 噛みつき野郎、 じゃあ、次は、コマンドプロンプトだ。 コマンドプロンプトはGB18030をサポートしてるか? >>246 > だから、Win9xをサポートしてきたアプリベンダは、 > まず、Unicode化しなくちゃならないという、けっこう大変なことがまってる。 > ただし、LinuxやAIXやSolarisなんかは、GB18030でAPIを呼べるわけで、 > それからみればそういう不満がでるのは当然だと思うぞ。 そりゃ不満を持つベンダもいるだろうが、 だからといってベタな地域化をいつまでも続けるのもマヌケじゃねえ? WindowsやMacintoshのGB 18030サポートが貧弱なんじゃなく、 国際化されていないアプリケーションが貧弱なんだと言ってはダメか? だいたいがGB 18030自体、奇襲攻撃みたいな符号化なんだし。 >>286 アプリがUTF-16化しないってのもマヌケだが、 Win自体が、システムロケールのcharsetをUTF-8化しないのもマヌケだ すべてのcharsetが同じデザインで統一されてるのが良いと思う。 やっぱ、UTF-16はすでにSurrogateが来たあたりで、 当初の目的が破綻してしまったからね。 >>254 > Unicodeの中で、GB18030を扱おうと言った場合、 > 一番の問題は、変換でのラウンドトリップの問題だよね。 ん? UnicodeとGB 18030の間には ラウンドトリップコンバージョンが成立していたと思うんだが。 問題があるなら具体例きぼんぬ。 >>287 Win32 APIのA関数でUTF-8使えたらもっときれいに行ってたのにとは思う。 >>283 VCがな(藁 Windowsじゃなくてな(藁 字が読める? >>285 してる。 コンソールのコードページを変更してみろ。 WindowsとVCとメモ帳の区別くらい付けた方がいいぞ(藁 まだWinがGB18030をサポートしてないと思ってる奴がいるのか? >>281 >ここで話してるのは、Windowsが ネイティブにGB18030をサポートしてるかどうかって話だ。 違うよ。WindowsがGB18030をサポートしてるかどうかって話だよ。 >>293 「その程度でサポートしてると言えるなら他のどのOSでもサポートしてる」 てなことを言ってる奴はいたけど。 これは常識的な日本語理解では「普通その程度でサポートしてるとは言わないんだよ」 という主張を含意していることになるので。 >>291 MSのサイトに、 GB18030はコマンドシェルをサポートしますか?いいえ。 と書かれているが、これはいつから変わったんだ? >>286 > だからといってベタな地域化をいつまでも続けるのもマヌケじゃねえ? > WindowsやMacintoshのGB 18030サポートが貧弱なんじゃなく、 > 国際化されていないアプリケーションが貧弱なんだと言ってはダメか? Unicodeを使うというのは良いが、UTF-16を使ったのがだめ。 だって、UTF-16と、既存のGB18030やShiftJISのcharsetサポートの違いがありすぎる。 WinはUTF-16とその他のcharsetと別のAPIに分けてしまった。 だからアプリ作る側が移行時とかWin9xのサポートに困る。 Unixのように、UTF-8としてUnicodeをサポートするほうが移行しやすい。 要は、あるプリンタをサポートするとして このプリンタは漢字フォントが乗ってないので イメージ展開しないと印刷されません でも従来の漢字コード出力を自動的に展開するような エミュレーションドライバは提供しませんので 従来のソフトでは漢字が印刷できません。 漢字を印刷したい時は画面のハードコピーをとってください。 みたいな状態で本当にサポートがあるって言えるのかよ って話なのかな? そのプリンタはサポートしてない。 Windowsはサポートしてる。 ハードコピーなんかとらなくても、GB18030からUNICODEに変換する APIが提供されているのでね。 バカはいつまでも同じ質問をするからレスばっか増えて生産性という物が全く無いね(藁 >>299 でも、ハードコピーができるってことは、 イメージの印刷はサポートしてるということだよ。 そもそもフォントをイメージ化できなきゃ表示すらできないんだから、 あとはソフトがその二つのapiを組み合わせてつかえばいいだけでしょ? なんでサポートしてないの? >>299 コマンドプロンプトでは、 VCのprintfでは、GB18030表示できないが、 gcのライブラリを使えば、GB18030がそのままprintfで表示できる。 なんて、MSでも言ってないことを、ぐたぐた言ってるからだよ。藁 で、gcって何よ? 画面をハードコピーした瞬間、それは文字じゃなくて画像だ。 画像にGB18030もShift_JISもあるか、バカ。 幼稚園レベルの疑問を何個も何個も書くんじゃないよ。 話をごまかそうとしてるんだろうが、何書いても知能の低さが 表れるだけだぞ(藁 >>302 gc知らないなんてネタだろ? VCに対応するgcつったら一つしかねーじゃねーか。 今度はVCって何よ?って言うんじゃねーだろうな? それに、MSが「サードパーティのライブラリを使えばできます」なんて言うわけないだろ。 ライブラリって知ってますか? 知らないなら調べて下さいね。 手間がかかるからもう言わせないで下さいね。 >>301 イメージ化までプリンタドライバがしてくれるなら、対応してると言える。 が、「ハードコピー取って下さい」と注意書きのあるプリンタは、 イメージ化を別の手段で取る必要があると見られる。 そういうプリンタは対応しているとは言えない。 Windowsの場合は、GB18030をUNICODEに変換するAPIがちゃんと用意されていて、 まともなプログラマはそれを使うから、立派に対応している。 しかし、画像しか印刷できないプリンタが文字に対応してると考える奴がいるとは 思わなかった。バカにも程がある。 しかしこうやって画像として表示した文字を 文字と認識できない人がいるようですね。 ・・・確かに変換してしまったらそれは元の符号系とは言えませんけど。 >>308 認識できない人がほとんどだと思うぞ。 画面のハードコピーしか印刷できないプリンタが文字に対応してると 認識してる電波はお前だけだ。 ついでに言えば、WindowsがGB18030に対応してないと認識してる電波も お前だけだよ。 いい加減にちょっとは成長してくれ。 常に最初から教えなきゃいけないのは面倒すぎる。 面白い人だなあ 誰もそんなことは言ってないのに。 ハードコピー取ってくださいというのは そのソフトが対応してないだけでしょ? GB18030の話は良くわからないけど変換しなきゃいけないなら、 イメージに変換するそのプリンタと同じだと思うよ。 つまり、そのシステムはサポートしてるってことでしょ? 同意見なのになんで電波とか言われなければいけないんだろう? >>304 gcは知らんが、gccなら知ってるが。 >>310 ついでに言えば、コマンドプロンプトがGB18030に対応してると認識してる電波も お前だけだよ。 MSでもnoって言ってるのにね。 glibcなら通じるが、gcといったらGNU-Cではなくガベージコレクタとかを想像する。 それともVisualC++用の「gc」っていうライブラリがあるの? 詳細情報希望。 >>305 > それに、MSが「サードパーティのライブラリを使えばできます」なんて言うわけないだろ。 gcのprintfは、コマンドプロンプトでGB18030の文字をネイティブで 表示できるって言ってるのか? ふーん。そう言ってるgcリリースしてるベンダのURL とりあえずリンク教えて。 で、gcってどこぞのgcかわからんからそれもURL教えて。 msvcrt.dllでも、mbstowcsとwprintf辺りでいけそう。 ロケール周りでCPを直接指定する方法は無かったかな? gccはコンパイラだぞ(藁 gcのライブラリでどうしてガベージコレクタなんだよ(藁 http://www.google.co.jp/search?sourceid=navclient&hl=ja&q=glibc+GB18030 >>311 どうしてシステムで対応してたらプリンタが対応したことになるのかね?(藁 Windowsが対応してるのは自明。 プリンタが対応してないのも自明。 だから、Windowsは対応して無くてプリンタが対応してると言い張るお前が電波。 >>313 勝手な話を作るな。俺は終始、UNICODEで対応と言ってる。 >>317 >どうしてシステムで対応してたらプリンタが対応したことになるのかね?(藁 それは印刷できるからに決まってるでしょ? 文字はイメージとしてね。 CRTにはフォント入ってないけどシステムが持っていれば問題ないわけだし >だから、Windowsは対応して無くてプリンタが対応してると言い張るお前が電波 なんか混信してませんか? >>317 いや、MSが、コマンドシェルはGB18030サポートしてない。 って言ってるんだから、GB18030サポートしてないんだろう。 Unicode使う使わないに関係ない。 GB18030サポートは、ベンダが決めること。 あんたが決めることじゃない。 >>317 UNICODEじゃなくて、Unicodeなんだが。。。 「gcのライブラリ」という言葉でBoehm GCとかを連想しただけの話で、 glibcの事を言っているのか、内部でUNICODE変換してくれる「サードパーティのライブラリ」が存在しているという事なのか知りたかった。 UNICODEで対応しているという事は一人以外はわかっているのでは? >>317 つーか、gcとは具体的にどこぞのgcを指すのかな? それで、そのgcのprintfはGB18030サポートしてるって言ってる gcのベンダーはどこよ? >>317 GB18030をprintfで表示するだけなのに Winは、すげー手間がいるんだな。藁 >>320 いや、所詮、噛み付き野郎は、電波だからな。藁 リンクもないところ見ると、 やつがWinのGB18030サポート具合を適当に決めたいんだろうな。 >>322 確かに。Open Sourceだと、LCUってのがあるが、 そんなUnicodeエンジン使って 内部でUnicodeで動いてる、libcってあんのか? まじで、リンク教えろ。 いつのまにか『UTF-16とGB18030を語るスレ』になって しまっており、BTRON仕様OSも多言語もどこかに 逝ってしまったのが笑える。 6763文字のGB2312文字コード規格から、2万7000文字に増やして、2000年7月に中国政府によって制定された、UNICODEを包括し、上位互換を保った1バイト、2バイト、4バイトの可変調コードになっている中華人民共和国の文字コード規格の名称。 ただし、中国語の辞典に掲載されている文字は5〜6万文字あり、その他にも少数民族の特殊な文字もあり、まだ十分とはいえない。 tp://www.kaigisho.ne.jp/literacy/midic/data/g/g36.htm アルファベットは今後次々と増えてはいかないだろうが 漢字は略字が生まれたりと増えていく可能性がいつも つきまとう。 全ての漢字を網羅する日なぞ来るのだろうか。 字素に分解して、全てを合字とした方が結局は近道で 『十分』というに相応しいものになるのではなかろうか。 既に4バイトまでの可変長などが使われている昨今、 大して複雑とは言えないだろうし。 ちゃんとGoogleの検索結果をリンクしてやったじゃねーか。 そっからいくらでも見つかるだろ? 見つからない? バカだから? しょうがねぇなぁ(藁 >>329 どうやら時間かけたわりには、やつは見つけられなかったらしい。 ワラタ。 >>329 バカだから見つからないんで本当によろしく え、何? マジで見つけられないの? 大丈夫か? 頭ついてるか? 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 が使えるようになりました。 ほら、取りあえずこれでわかったろ? もっと詳しいことが知りたきゃ、ソース読む以外にはないんだけど、 もうちょっと大人になってからね(藁 問題1 次の情報ソースを挙げよ 1. WindowsでGB18030が使えない 2. 画像しか印刷できないプリンタはGB18030に対応している こんなこと本気で言ってる奴がいるんだからなぁ(藁 あと、こんなことも言ってたよな(藁 3. printfでリテラル文字を表示するときには第一引数に書くべきである 4. msvcrt.dllはVCのランタイムではない イタタタタ(藁 >Glibc2はGNU Cライブラリの最新版です。 >現在、変更なしで動作するのは、 GNU HurdシステムとLinux i386, m68k, alphaシステムです。 >PowerPC, MIPS, Sparc, Sparc 64, Arm用のLinux向けには2.1版で対応の予定です。 >将来的には、 ほかのアーキテクチャーとオペレーティングシステム用にも順次対応の予定です。 >>334-335 やっぱ、もーそーくんだったらしい。 何に対して反論されてるかもわかってない。 >>336 結局やつが言ってる、gcって何なんだろうね。 >>335 つーかそんなこと言ってるやつはいたか? 1. コマンドシェルはGB18030サポートしています。 2. gcはGB18030サポートしています。 3. コマンドシェルではVCのprintfはGB18030表示できませんが、gcならOK はいたけど。イタタタタ(藁 >>336 紹介したglibcがWindows用でなくて悪かったね。 普通、応用できると思うからさぁ、つい君が並はずれたバカだってこと 忘れてたよ(藁 ま、でもこれでライブラリを換えることで、GB18030が使えたり使えなかったり することは理解できただろ? これを「ラ・イ・ブ・ラ・リ・依・存」って言うんだよ(藁 一つ勉強になったね(藁 >>338 つーかそんなこと言ってるやつはいたか? コンソールのコードページをUNICODEに直してUNICODEで表示しろとは言ったけどね。 日本語読めないのはさぞかし不便だろうね(藁 で、まだWindowsがGB18030サポートしてることが理解できないの? 何年くらいかかりそう? もう飽きちゃったなぁ(藁 >>338 つーか、うちのcygwin、コンパイルするときエラーメッセージが文字化けするの なんとかならない? .mo をSJISに書き換えればいいんだろうか? >>335 > printfでリテラル文字を表示するときには第一引数に書くべきである たぶん、あんたは、 「printfで第一引数にリテラル文字を書いちゃいけない。」 って、言ってたやつだな?何年前のこと言ってんだ?DOS時代のことか? そんなちゃちいライブラリ使ってんな。藁 ちなみに、WindowsのVCについてくるprintfの場合、 現在のロケールのchasetがその文字コードをサポートしているなら、 どこに書いても良さそうだぞ。 ちゃんとformatストリング内は、文字tokenはisleadbyteで 1キャラクタごと取ってきてるからな。 ちゅーか、最近のライブラリはDBCS awareになってるから、 現在のロケールにある文字なら動く。 あんたのライブラリは違うらしいが。 もちろん現在のロケールに含まれない文字コードが含まれていた場合は、 そのパースはおかしくなるに決まってるが。 >>340 > で、まだWindowsがGB18030サポートしてることが理解できないの? それは、WinがGB18030サポートするって言った時点から承知だが? で、まだWindowsがGB18030サポートがださいってことが理解できないの? それより、なんで、 ライブラリを使ってイメージに展開すればその文字が印刷できるのに そのプリンタが文字の印刷に対応してないと言えるのかが知りたいな。 >>339 > これを「ラ・イ・ブ・ラ・リ・依・存」って言うんだよ(藁 つーよりMSの「ラ・イ・ブ・ラ・リ・だ・さ・い」って言うんでねーの(藁 >>340 ちなみに>>291 は噛み付き野郎だから、おまえじゃねーの? gcのライブラリって、glibcってことだったのか? >>87 GB18030は > TRONと比べてもUnicodeと比べても文字鏡と比べても > 漢字圏にとっては素晴らしいぞ。 > > 何が素晴らしいって、主だったOSが既に対応可能に > なっているから。しかも、フォント依存ではなく。 つーことで、噛みつき君は、WinのGB18030サポートは、 UTF-16依存でも、素晴らしいと言いたかったのか? WinくらいのGB18030サポートだったら、 なんで素晴らしいのかぜんぜんわからん。 「最初からださいという話をしていたんだよ」と言う 人が絶えないので、どこからださいという話をしだした か確認してみました。 「ださ」および「ダサ」で検索したところ >>155 でした。 >>87 あたりから始まった話で、随分間を空けてから 登場しています。 それも >Shift JISサポートに比べると ださださ、おそまつだねーってことだと思うんだが。 と、単に推測しているだけ。 そのカキコより前に>>142 が >>>139 >> それを対応してないと苦しい言い訳をしてるところが恥ずかしい。 > >だいたい、その拡大解釈じゃあ、 >TRONコードだってUnicodeや、GB18030対応してるよ。 と書いています。>>139 の「W2kはGB18030対応している」 という考えを『拡大解釈』だと言っている。 つまり、>>142 は、拡大しない普通の解釈では 「W2kはGB18030に対応していない」と主張していることになる。 >>350 ま、結論が出たってことで、いいんでないの? WinのGB18030サポートってダサいよな。 そしてバカは何か場をごまかせた気になった満足して帰るのでした。 もう来なくていいぞ(藁 まあ、画面に表示されたドットイメージを文字と認識できないらしいから 何言ってもしょうがないよね。 で、そんなGB18030がどうして、 TRONと比べてもUnicodeと比べても文字鏡と比べても すばらしいわけ? WinのGB18030サポートもださいのに。 まあドットイメージにエンコーディングが残ってると認識してる人は まだいるのね(藁 とりあえずローカル文字コード+数値実体参照(それ以外のコード) じゃ駄目なのかな? というか文字鏡とかの実体参照は規格化されてるのかな? >>355 どいつに話してるかもわからんらしい。 まだ、もーそー止まらないみたいだな。 画像になった文字とテキストが同じだと認識してる人って結構いるよ。 初心者にね。 ところで、超漢字4って今何文字サポートしてるの? BTRONのPC実装系って、超漢字だけ? >>354 超漢字以外ではとんと広まらないトロンコードはユーザから見れば 実質的には超漢字専用の独自コードみたいなもんだし、文字鏡は エンコーディングが標準化されている訳でもなく、フォント変えて文字 化けさせるような姑息な方法ばかりが普及していてダメなので論外。 Unicodeと比べてGB18030がいいのは、漢字の国の人が拡張していく コードなので、漢字圏としては安心…くらいのもんかね。 >>361 中国がGB 18030で漢字を独自に拡張することなんかないだろ。 漢字の拡張が必要ならUnicodeに提案して入れるはず。 独自の拡張が考えられるとしたら少数民族言語に使われる文字だろうが、 それにしたってGB 18030に入れたら Unicodeにも入れようという話になるのが自然。 あの異様な拡張性には謎が残るが、 好き勝手なことができる余地を残しておこうということだろうし、 各国の投票で決まるUnicodeと比べて安心とは到底考えられないが。 要はGB18030ってのは>>357 みたいな多バイトコード系って考えていいの? GBK+UNICODE みたいな。 >>362 Unicodeに登録させる為の既成事実化としてGB18030 にバンバン登録するというのはありえるかな。 JIS第4水準だって、そうやって規格化する事でUnicodeへの 登録を促すという目的があったそうだし。 ?>>364 それもあるし、タイミングの問題もあるだろうね。 ISO 10646/Unicodeに文字の登録を申請しても、 規格化されるまでには時間がかかる。 一方、国内でGB 18030を使っていれば、迅速に実装できる。 JIS X 0213の例で言えば、 Shift JISの壁に阻まれて実装で遅れをとったけど、 GB 18030の拡張性があればその心配もない。 >>366 よくわからないけど1バイト+2バイトの混成であるSJISに 4バイトコード系を追加することはできないの? >>367 そりゃあ第3水準・第4水準以前だったら やってできないことはなかっただろうけど、 誰もそんなの実装しない罠。 Shift_JISをいまさらリファインする前にお前ら ISO-2022-JP-2を使ってください・゚・(ノД`)・゚・ >>369 JISをフルサポートしてないんで却下。 というかなんでそもそも0201-KANAを組み込まなかったのか疑問。 使わない方針で行ってくれというのは知ったこっちゃないが、 両方のカナが混在している環境が多く存在している以上、 相互変換ができないのはやっぱり不便だよね。 そういえば、ISO-2022-JP-2でHTML書いて、そこに足りない字は数値実体参照で拾ってくれば ユニコードの文字セット+包摂前の漢字 で文書が書けるんだよね。 >>372 ISO-2022準拠の方法でコード切り替えすら行なわないのに、 ISO-2022-なんとかを名乗るのはおこがましいというか、なんというか。 つーかISO-2022準拠のキャラクタセット全部サポートすると、カナや ユニコードの文字セットはともかくとして、絵が書けたり、音楽すら 鳴ってしまったりすると思うのは気のせいだろうか? 気のせい 情報交換体系としての側面であって、 あれらをふつう図形文字集合とは考えない。 ^G とかと同じ(?) 結論 内部コードとして GB 18030 をサポートしている 入出力用のコードとして GB 18030 をサポートしていない 対策 NT 系では W系API のみを使用する 9X 系では入出力時に自分で変換する 事実 コンソールは GB 18030 のコードを受け付けない 未確認情報 gc なるライブラリを使うと、GB 18030 がコンソールで使えるらしい コンソールへの入出力の前に自動変換するものだと推測される >>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にサポートになっちゃうけど。 >>375 Win2000/XPの内部コードって、UTF-16じゃんか。 お前ら「OSの内部コード」を定義してください。 思いつきを書いとけば、 「(文字コード変換ルーチン以外の)APIが直接扱う文字コード」ってとこか? APIってのはインターフェースだ。内部じゃない。 何言ってんの?バカ? 内部コード: 何言ってんの?バカ? 外部コード: 意味がわからないから、ちゃんと考えて言ってよ。 インターフェースというのは、接続するもののこと。 APIとは、OS(内部)とアプリ(外部)とのインターフェース。 内部で使われているのはUTF-16。 外部で使われているのは様々。 システムルーチンのことをAPIとも言うってだけのことだろ。 内部コード・外部コードという用語は mohta 大先生も使っていますが、何か? >>386 インターフェースだぞ。知らなかったのか? 何だと思ったんだ? RFC1554(ISO-2022-JP-2)のauthorである mohta氏の用語法にケチをつけて 引っ込みがつかなくなった厨のいるスレはここか? でも「〜危ない」での mohta 氏の用法では、 同書での議論が目的とする範疇をはっきりさせるために 情報交換用コード=外部コード プログラムが操作するためのコード=内部コード と定義してるだけで、ここで問題にしてる アプリとOSの間のインタフェースとはちょいズレますが? んーとさー、たとえばATSUIはAppleのUnicode描画APIだ。 で、ATSUIは関数(だけじゃないが)群だ。 その関数群が扱うUTF-16は「Mac OS Xの内部コード」だろ。 まさか「ATSUIはインタフェースだからOSの内部じゃない」とか 言い出すやつはいないだろうな。 要は通信用語の内部コードと、今言われているOSの内部コードは 定義が違うって話でしょ? 通信の立場では、情報交換に使う外部コードは統一しなきゃ駄目だけど、 自分や相手の内部コードはなんでもいい。 OSの立場では、ソフトが使う外部コードはなんでもいいけど、 OSに発行するコマンドで使う内部コードは決まっている。 というわけで発想が全く逆なんだよね。 >>366 GB18030が中国の好き勝手に迅速に漢字を増やし ていくことが出来るということは、TRONコードの 様に包摂基準が一貫しなくなる(というか、包摂基準 なんて何も無い状態になる)危険性は無い? ましてや、GB18030に登録されたという事実を 理由にUnicodeに後追いで追加されていくことになると。 >>395 俺の知る限りじゃ、中国(大陸)には あまり細かい字体差を区別しようという発想はなさそうだ。 Unicodeの包摂規準をぐしゃぐしゃにしているのは、 むしろ台湾と韓国だと思われ。 >>396 KS X 1001 とかをネタに言ってるなら、それは筋違い >>397 いや、俺が韓国と書いたのは互換漢字(重複符号化)のことではなく、 Extension Cのソース(高麗大蔵経)のこと。 UnicodeとGB18030が収録する文字が結果的に 同じであったとしても、2バイト固定とか言いながら 代理ペアとかで妙な形で建て増ししてる前者よりは 最初から可変長の後者の方が潔くって好き。 使えねえけど。 GB 18030こそ究極の建て増しだろ。 それにサロゲートペアのほうが 先行キャラクタと後続キャラクタの区別がはっきりしている分、 GB 18030の方式よりスマートだと思うが。 ところで数値実体参照でユニコード以外扱う方法ってないの? >>401 標準化機関にネジ込めばいいんじゃねぇの ? W3CのHTMLでISO 10646以外の実体参照を定義しろってのは無理な話。 でも、勝手に使っちゃってもSGML・XML的にはOKなんじゃないの。 文字鏡の実体参照あたり、けっこういろんな人が使ってると思うけど。 逆に、どんなエンコードでもHTMLならISO10646 BMPの 文字は数値実態参照で書けるのだから、エンコード自体に ISO10646 BMPに含まれない文字を含むものを使えば、 ISO10646 BMP+αの文書を作成できるね。 >>404 HTMLの数値文字参照がBMP限定だという話のソースきぼんぬ。 >>403 エンコードは登録されてるの以外を使うはダメさ。 基本はISO 2022だからエンコードした文字以外をISO 10646から探すか、構造を借りて無関係に実態参照を張るほうがよいかと(UTF2000や文字境) >>404 UCS-4を前提にしてるっぽいからBMP限定じゃないよ〜ん >構造を借りて無関係に実態参照を張るほうがよいかと(UTF2000や文字境) そこら辺の規格ってあったら知りたい。 というかISO 2022登録(ISOREG?)コードって実体参照で使えるの? > というかISO 2022登録(ISOREG?)コードって実体参照で使えるの? 一部を除き使えない。 Unicode は、0から255までは ISO 8859 と同じ。HTML 3.xまでは、 実体参照は ISO 8859 を指してた。 そういや、TRONのアレもアレだな。&Txxyyyy;とかってやつ。 ふと思って、 ISO 10646 を調べたんだけど、群オクテットの最上位ビット は、0ですね。 てことは GB18030 の4バイト集合の部分とは重ならないで、共存可能で合っ てまつか? ISO10646とGB18030を同時に使えるエンコード方式を 策定するってか バイトストリームだけ見て UTF-* と GB18030 系って区別可能? >>411 32ビット1バイトのUCS-4(UTF-32)と 8ビット1バイトのGB 18030「4バイト集合」が 32ビット単位で見れば重ならないということに 何か意味があるか? そのまま一緒にしてISO10646とGB18030の文字集合を 併せたエンコードを捏造できるってことでは? 現状、文字は全て重複してるけど。 実際に使われる文字のほとんどは2バイト集合と1バイト集合のほうなので、 4バイト集合だけUCS-4と共存させても無意味でしょ。 つか、すべての文字を共存させることができたとしても やっぱり無意味だけどさ。 >>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のソースは、古い文書を見ていたと思われ 文字鏡の文字がISOに登録されたってどういうこと? ISO 10036 のレジストラが GLOCOM なんだわ。 で、それに登録されたらしい。 そういう言い方をするなら、 Unicode だって ISO 2022 に登録されてる☆ミ グリフ情報の交換標準であって、Code for Information Interchange ではないから、誤解がないように書いてほしい。 >>421 ISO 10036 で規定してるのは, Code for Gryph-Image Information Interchange なんでせうか? それとも Code と考えるべきではない? 文字鏡とUnicode3.2を統合した新しい文字集合キボンヌ(嘘) で結局 gc って glibc のことを指す俺用語なわけ? (俺用語: かなり偏りのある自分用語) 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 ̄ ̄ ̄ ̄) (__/ >>426 そりゃ単に文字鏡の次のバージョンじゃねーの? ケータイの文字コードにUnicodeが採用される日は来るかな? μiTRONケータイの文字コードにTRONコードが採用される日は来るかな? ━―━―━―━―━―━―━―━―━[JR山崎駅(^^)]━―━―━―━―━―━―━―━―━― ∧_∧ ピュ.ー ( ^^ ) <これからも僕を応援して下さいね(^^)。 =〔~∪ ̄ ̄〕 = ◎――◎ 山崎渉 XML and Unicode: Mix with care http://zdnet.com.com/2100-1104_2-1017789.html XMLとユニコードを一緒に使うときは注意が必要らしい。 だれか、解説してくれ。 __∧_∧_ |( ^^ )| <寝るぽ(^^) |\⌒⌒⌒\ \ |⌒⌒⌒~| 山崎渉 ~ ̄ ̄ ̄ ̄ 「ただし私はUnicodeが嫌いなので、Sunに言って超漢字に対応させている」 死ね! >>32 戦後の歴史も知らんみたいだな。 マスコミは馬鹿だから講話独立の意味が分かってないだけだ。 それをそのまま採用するなど以ての外。 >>33 高校の時調べもので「こけら」を引いたら 「柿」とかいてあって頭が混乱した思い出がある。 根本的に文字を1対1対応のコードに割り振るのは無理なんじゃないか。 ユニコードにしろトロンにしろ。 無修正DVD販売です.新作旧作多数在庫あります。 女子校生モノ、熟女モノ等多数ご用意してます。 http://d-jupiter.net/ (⌒V⌒) │ ^ ^ │<これからも僕を応援して下さいね(^^)。 ⊂| |つ (_)(_) 山崎パン (⌒V⌒) │ ^ ^ │<これからも僕を応援して下さいね(^^)。 ⊂| |つ (_)(_) 山崎パン TRONの文字コードって、小説なんかの架空の文字も集めてるらしいけど、 ゼビウスのゼビ数字とか、フィネガンズフェイクの変なアルファベット(邦訳版 の変な字も)なんかもあるの? >>456 そういうのは入ってないだろ。 手書き文字の略体化のルールを拡張適用した「架空の文字」なら 入ってそうだけど。 >>456 著作者の承諾を得てあなたがTRON文字協会に登録すれば可能。 欧米人は表意文字なんて原始人の使う文字ぐらいにしか おもってないんだろうな。古代の象形文字も漢字も 同じような感覚で接してるんだろうな。 文字コードも半導体投資も底なし沼。 漢字の派生は過去の誤字脱字全部添削するようなもの。 >>461 とりあえず全部包括してしまえばいい。 漢字の総数なんてたいした数じゃない。 漢字の総数は非常に多いが見通しが立つぐらいの有限だから。 他の文字で構造的組合せ型はたちが悪い。 あれはフォントの扱い方を根本から見直さないと どんなに収録してもキリがない。 >>464 漢字の多さなんてたいした問題じゃない。 見通しの立つ膨大さなんて質がいい方。 ほとんどの漢字、トロン使いパソコン表示可能に 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 元ソースは共同通信 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 印刷業界が頭を悩ませる外字問題、坂村氏の提案する解決方法とは? (MYCOM PC WEB) http://pcweb.mycom.co.jp/news/2004/03/11/014.html トロンプロジェクトは、「フォント・トレーサビリティ・システム」を発表した。 同プロジェクトリーダーで東京大学教授の坂村健氏が長年取り組んできた OS「トロン」の多文字技術を他のOSでも利用できるようにし、多文字問題・ 外字問題の解決を助けようというシステムだ。 日本で利用される漢字の種類は膨大で、PCで区別可能な数を遙かに 超えている。また、字体の違いを区別できないといった問題も存在する。 こういった問題に対して印刷業界などでは「外字」を使って文字を追加す ることで対処してきた。しかし、外字を管理するための「外字表」には管理・ 整理の手間が掛かり、坂村氏は外字表の取り違えが原因となるトラブルの 存在も指摘する。「フォント・トレーサビリティ・システム」は、こういった多文 字に関する問題を解決するために「TRONコード」を利用して全ての文字を区別し、 外字や異字体などを管理する。これをWindowsやMac OSといった既存のOSでも 扱うことのできるようにするためのシステムだ。また、ユビキタスIDを利用して 外字表の管理も行う。 TRONコードでは、既存の文字コードに含まれる文字やあらたに作成された 外字に対し、TRONコードを使って統一番号を付与する。文字コード間での 重複や異字体などに関しては、データベースで管理することで対処する。 Unicodeなど既存の文字コードでは、微妙に違う二つの漢字を異字体とするか 別の文字とするかを議論による判断で決定してきたが、TRONコードでは 細かい違いであっても、全ての文字に一意の文字コードを付与することが 大きな特徴となっている。坂村氏は「(異字体に関する)学問的な研究を 否定はしないが、(細かに異なる2つの文字を)区別するかしないかはユーザが 決めること」と主張する。異字体データベースに関しては複数の存在も認め、 異字体に関する複数の説に対応できるものとする。TRONコードのコード 割り当てについてはウェブサイト「トロン文字収録センター」で公開されており、 文字の読み・おおよその画数・部首などから検索を行うことができ、TRON以外でも TRONコードに収録される文字の利用が可能となっている。 TRONコードへの新たな文字の追加は既存の文字コードを丸ごと追加する 方法の他にも、1文字だけを追加する方法も用意されている。DTPソフトが 標準で持つ外字セットや自治体で使用される人名用外字のセットなども 収録してコードを割り当てることも可能だ。複数の文字コードを収録する TRONコードはメタコードとして振る舞うことができ、TRONコードを仲介して 文字コード間の変換を行うこともできる。 こういった既存システムの文字コード同士の変換を行う仕組みをTRON以外 のOSからも利用可能とするために「外字変換サーバー」が用意された。 「外字変換サーバ」では、TRONコードで作成された多漢字コンテンツを読み込み、 他のOSで読み込むことができるShift-JISなどのコンテンツと外字表、その コンテンツで使用される外字を含んだTureTypeフォントを生成する。 クライアントで実装せず、サーバの機能としたのは既存の業務システムの 変更を行う必要がないことや複数システムの統合に有利であるからという。 また、従来出版物毎に作成して管理されてきた外字表や外字フォントセットの 管理を「ucode」を利用して行う。外字対応表毎にucodeを付与し、ユビキタス IDセンターが出版物との対応を管理する。これによって外字表の管理を容易にし、 コストを下げることが可能となるという。 外字変換サーバとucodeによる外字表の管理によって、これまでTRONで実現 されてきた多漢字の利用を汎用的なソリューションとして、OSを問わずに多くの プラットフォームで利用可能となる。坂村氏は、「フォント・トレーサビリティ・システム」 について、様々なOSのメリットを利用し、それぞれの得意分野を活かしてコンテンツの 作成を行うことのできるメリットを強調する。また、こういった「役割分担」は 最近のトレンドであると語り、今回のシステムはマイクロソフトとの提携などに見られる、 WindowsやLinuxなど他のOSとTRONの「協力関係」を深める取り組みの一端であるともした。 既存の資産を集めて使うという発想はいい。 ただ、これだと用途が限られる。 既存のシステムはそれなりに動いてるしな。 いまさら設備投資するところがどれだけあるか? 10年遅かった。 超漢字が死んでもTRONコードが生きれば意義は大きい。 既存の外字資産といっても無限にあるわけじゃないからなぁ。 Microsoftとの提携効果ですね。>trutypeフォント生成 Windows の外字交換標準の問題点もこれを換骨してMicrosoftが 使うんじゃない GB18030のTRONコードの割り当てってどうなってるの? 今書体が実装されてるのは634文字だけだけど コードポイントの割り当てはあるんでしょ? UNICODEの65536を非難するより BTRONのファイル数65536を改善すべきでは 漢字を少々たくさん扱えるだけで 多言語ではないのさ 初期のTRONって単純にJISコードだった UNICODEが出てきたのであわててTRONコードとか言ってまねしたのさ 初めはJISっていうか今昔文字鏡かなんかのコードだったんでは? JIS X 0208 コードなどでは外字が定義されていますよね。 いわゆる機種依存文字などもこの外字部分に 定義されているのだと思うのですが、 外字部分も Unicode との間でマッピングが定義されているのでしょうか? 質問の意味がよくわからんが JIS X 0208で未使用の区点も対応は定義されてるよ ただしTRONコードではJIS X 0213:2000に使われてる >>492 > JIS X 0208で未使用の区点も対応は定義されてるよ 回答の意味がよくわからん(笑)。 >>492 > JIS X 0208で未使用の区点も対応は定義されてるよ 回答の意味がよくわからん(笑)。 たとえば84区08点はJIS X 0208では保留領域だけど TRONコードT1-7428が予約されていたってこと >>495 さんへ いやいや、そういうことではなくて、 元々の491の質問は「JIS X 0208 コードの外字部分と Unicode との間のマッピング」 についてだったので、それに対して492の【前半部分】で「対応は定義されてるよ」と 回答しているようにしか読めない。 それで、「回答の意味がよくわからん」と書いたのだが。 X0208とTRONコードとのこと(だけ)を言いたかったのであれば、492でもう少しわか りやすく書いてくれればよかったんだが。 BTRONがいまいちぱっとしないのは 群がっている連中にプログラマが比較的少ないからじゃないかな。 TRONの宿命かも知れんが、SF好きが嵩じてTRONにはまった香具師ってのが珍しくない。 他のOSではあまり見られない現象。 マイナーでも、どこかがとんがったOSだとそれなりのプログラマがハックして盛り上がるんだが。 「データウェア」で盛り上がってもなぁ〜。 諸橋大漢和も草冠を3画にしちゃったのね。 あ、いや、それだけなんだけどね。 アルファベットの筆記体も形態のぶれが結構ありますが、 個々にコードを割り当てられないんですか。漢字だけ贔屓してるような氣がします。 おまいら、Nスペで国産OS TRON の出番ですよ。 NHK総合 8/28(日)午後9:00〜 NHKスペシャル 日本の群像 再起への20年 「第4回 極小コンピューター 技術者たちの攻防」 1984年、誰もが簡単にコンピューターを使えるようにと 東京大学の坂村健氏が開発した基本ソフト「トロン」。 しかし、無料提供を目的にしたトロンは、 89年にアメリカから貿易障壁のリストに挙げられ、 普及中止に追い込まれる。 結局、90年代のパソコン市場は、 世界標準を握ったアメリカ製の基本ソフト 「ウィンドウズ」に支配されることになった。 …… http://www.nhk.or.jp/special/topics/top2_0503a.html 昼はアキバに入り浸り 1Bソフトを漁ったら トロい店員奥から出てきて 「開発元に聞いてくれ」 フリーソフトはメチャクチャイケるぜ 市販ソフトはPMCだけ いつもメゲ知らずの BTRONユーザー 完全無欠の未来派OS 松下電器に見放され パーソナルメディアでやっている 馬鹿にするなよマッキントッシュユーザー 使って 使って 使って 使って 夜は夜な夜なネットでサーフィン トロンサイトの乱れ打ち Fトロ Bフリ 坂研 トロ協 テキストブラウザで〜 作るOS 買うOS 夢を見るなら(イェィ イェィ イェィ イェィ) メイキング電脳シティ BTRONユーザー 完全無欠の未来派OS 301条に潰されて 外圧跳ね除け 生きている 使えや遊べやBTRONユーザー 使って 使って 使って 使って (「完全無欠のロックンローラー」の曲で) 2ちゃんねるでどうしてもUNICODEで文字を表示したい時は、実体参照で打込 むことになるが、各板のSETTING.TXT の設定に依り、実体参照で表示できる 板と表示できない板がある。 mixiはそのままUNICODE(UTF-8)が書込めるのだが。 TRONコードってwikipediaでも使われてたのねw ttp://ja.wikipedia.org/wiki/%E7%94%BB%E5%83%8F:TRON_2-2436.gif > 広い意味の国粋主義で「国産でいいものを作ろう」というのはまだよかったんだが、 「国産だからいいものに違いない」と妙な脳内変換をして 坂村健 って、語り口が『梅干と日本刀』+『プロジェクト・X』だったな。 「マスコミに受けるプレゼン術」だけに長じていた。 B-TRON、C-TRON、I-TRON、・・・ 名前と「構想」だけがあって、実体が無い。 予算だけが大規模で、業績が無い。 20年以上かかって、何の成果も上がらず、「TRONプロジェクト」 は 大 失 敗 。 そこで、坂村健・東大教授が一言: 「ボクは悪くない。世界の反応がおかしい」… 炊飯器のマイコン制御使われてるって聞いたぞ おいしいご飯がたべられるのはトロンのおかげだ 罠しかけ 自分がはまる ナナ六条 阿国だけにおおきに NECやMSに足を引っ張られた割にiTRONは普及してるな とりあえずなんでJUNETコードみたいにRFCが書けなかったの? そうすればEUCやSJISみたいにJISのおまけ規格にはなれてたんじゃないの? ISO-2022-JP は ISO-2022 の枠組みに沿ってるけど、 TRON コードはそういうコード体系じゃないから。 理屈ではなんでもありのエスケープシーケンスもあることになってる (ここまでsjis, ここからEUC みたいな)けど、そんなもん誰も使わんから、 登録する手間がかかるだけ無駄。 >>520 それがおかしいんだよ UNICODEみたいな変態コード系でも、切り替え文字を割り当ててもらっているので ISO-2022を名乗れてしまう。 TRONコードになぜそれができなかったのか。 時代遅れのマシンでも漢字表示に困らないようにする為のサブセットコード系に ISO-2022-JPなんてISO標準と錯覚させる大層な名前を許したのがそもそも間違い。 >>523 全然違う。 漢字をROMで持っているような時代遅れのマシン為の規格に日本標準みたいな名前を名乗らせたから、 それと互換性のないローカルコードなんてシカトされたってこと。 他の国で採用されてればまた話は別だろうけど。 > それがおかしいんだよ > UNICODEみたいな変態コード系でも、切り替え文字を割り当ててもらっているので > ISO-2022を名乗れてしまう。 実際にそれで運用してるものが存在するか? てかあんたの言ってる「UNICODE」って何? UTF-何? UCF-何? 一体何のことを言ってるのか、わけがわかんない。 運用なんて関係ないんだよ。 そもそも符号化法がうじゃうじゃあって「わけがわかんなく」て、「ユニ」でもなんでもなく 以前のコードとは変換テーブルがないと互換できないような変態コードが後継としてねじ込めたのだから >>520 は理由にならないって話。 はいはい。TADの仕様を最初から最後まで読んでからまたどうぞ。 実はTRONコードの仕様という独立したものはなくて、TADのサブセットを便宜的に そう呼んでるだけだから。 それこそJIS X 4401とか、データフォーマットの規格ならいくらでもあるんじゃないの? あるけど、それで? 手間も暇も金もかかるの。あんたがそれ全部提供してくれるわけ? なぜunicodeやOOoにはできたのかってことでしょ? すんげー今更だが、あることを確認したので報告する。 1B(1B/V1以前の1B)で使える補助漢字のフォントを売ってたのは「エーアイ出版」で、 文字鏡の「エーアイ・ネット」とは全く関係がなかった。 昔、確か和尚か誰かがそのへんの話で混同してたのを見たことがある 気がするもんだから書いておく。 UNICODEも16bitから始まり、サロゲートペアができて、さらにISVまで追加... TRON CODE は、はじめから16bitの複数個の可変長だった。 Unicodeの組み合わせによってOSが落ちることなんて本当にあるのかよ 高速化のためにグラフィックドライバが特権モードのコードになっている、とかありそうな話だし、 そこに U+FF?? あたりのコードを叩き込んだら変な動作をして落ちるようなバグがあったり、 というのもありそうな話。 ⛅ ⛵ 〰〰〰 超漢字は18万個の漢字扱えるけどファイルは65535個しか扱えない そもそも文字の書けない役人がバカみたいに増やした異体字抹殺したら漢字なんか6万個程度で収まるんじゃね? 誰でも簡単にネットで稼げる方法など 参考までに、 ⇒ 『半藤のブブイウイウレレ』 というサイトで見ることができます。 グーグル検索⇒『半藤のブブイウイウレレ』 LYO3ZQHHGK (^-^)y- (^o^)y-。o0○ ( ;゜゜)ノ⌒-~ ←……( ̄ー|柱| ポイステキンシ read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる