【GUI】wxWidgets(旧wxWindows) その3【サイザー】

1 名前：デフォルトの名無しさん mailto:sage [2006/09/09(土) 00:06:30 ] クロスプラットフォーム GUI ライブラリの wxWidgets (旧 wxWindows)について語りましょう。 本家 　www.wxwidgets.org/ wxWindows日本語プロジェクト 　wxwindowsjp.sourceforge.jp/ Let's wxWidgets dot-gray.s33.xrea.com/ (*)準備中(*) www.geocities.co.jp/SiliconValley-Cupertino/8526/ wxWindowsで始めるC++ GUIプログラミング www.h3.dion.ne.jp/~k5_n/wxwin/ wxWidgets でクロスプラットフォーム GUIアプリを作ろう namazu.org/~satoru/pub/uu-2004-08/ dW : Linux : wxWindowsの概要 　www-6.ibm.com/jp/developerworks/linux/010413/j_l-wxwin.html SunWorld Online：wxWindows――無名だが成熟したGUIツールキット 　www.idg.co.jp/sw/back/200102/20010219_01_report.html 152 名前：デフォルトの名無しさん mailto:sage [2007/03/18(日) 22:42:36 ] みなさん。 wxFrameにwxGLCanvasセットしているときって、 なぜかwxMessageBoxの表示が全面に出てこなくて、wxFrameを最小化するか、クイック起動の「デスクトップを表示」をするかしないと、 wxMessageBoxが現れなかったりしませんか？ ちなみに当方wxWidgets1.6.3使用。 1.8.2だと治ってるかなぁ・・・。 153 名前：デフォルトの名無しさん mailto:sage [2007/03/19(月) 08:48:42 ] >>152 2.8じゃなくて？ 154 名前：デフォルトの名無しさん mailto:sage [2007/03/19(月) 09:16:38 ] >>153 そうでした。2.6.3使用で、2.8だと直ってるかな、でした。 155 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 09:01:33 ] Mac の wxPython で使ってみてるんだけど、 wx.DC.GetTextExtent() がラテン文字以外は正しい幅を返してこないようだ。 Windows だとちゃんととれるのに。 これはどこの問題なんだ？ 156 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 17:10:57 ] wxWidgetsの問題．諦めよ． 157 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 17:52:33 ] べつに諦めなくても自分で書いて送りつければいいんだけどね。 結構反応はやいよ。時々永遠に放置されるけどw 実装具合はポートによって様々。 一応実装されていても細かいところで違っていて、それを吸収する クラスを書かないといけないこともある。 158 名前：デフォルトの名無しさん mailto:sage [2007/04/04(水) 16:41:07 ] groups.yahoo.co.jp/group/wxmljp/ 日本語版メーリングリストが無いから作っといた テンプレにいれといて 159 名前：デフォルトの名無しさん mailto:sage [2007/04/07(土) 00:08:15 ] なぁなぁ wxWidgetsってさ、UTFの扱いどうなってるな？F8とか押すとさ、たまーにゴミ文字列 挿入されるんだがあれまじキレそうになるからなんとかしたいんだけど どうすればいい？ 160 名前：デフォルトの名無しさん mailto:sage [2007/04/07(土) 00:49:26 ] コンパイラをUnicodeにすればいいんでない？ 161 名前：デフォルトの名無しさん mailto:sage [2007/04/07(土) 01:42:17 ] 155だけど、日本語のフォントにしたら日本語についてはちゃんと取れた。 フォントのフォールバックが起こると取れなくなるみたい。 157のいう実装上の差異というところか。直せるのかな。 wxMAC のソースをちょっと覗いてみたら、元のAPIの仕様でそうなってるようにも見える。 Mac 詳しくないのでわかんないけど。 wxて Unicode や XML に詳しい人がコアにいないんじゃないかと思うことがある。 XRC の文法もなんか素人くさいよね。size をリテラルとして指定するとことか。 Uniscribe や TextLayoutManager（だっけ？）相当の機能がつくといいんだけどな。 ワイド文字列でコンパイルしただけじゃUnicode対応とはいえなかろう。 でも古典的な範囲でふつうに使ってる分にはやりやすい。嫌いなわけではないのよ。 あとインプットメソッドまわりは日本人がやらないと絶対始まらないと思うぞ。 162 名前：デフォルトの名無しさん mailto:sage [2007/04/07(土) 10:10:45 ] ソース見てきた。Unicode実装してない 嘘Unicode絶対間違って実装してるからバグバグになる。 最悪buffer overflowとかも平気でありありな実装で こいつら死ねよって今からメール送りまくろうと思ってます。 メインの開発者全員にしねよねﾊｹﾞゴルァメールを送りつけて気を引き締めて あげたいであります。 163 名前：デフォルトの名無しさん mailto:sage [2007/04/07(土) 23:49:22 ] >>162 そんなことよりパッチ送ってやれ。 どーせ理解できねーんだから。 164 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 04:19:49 ] ソース見てないけど Unicodeが問題になることといえばコードの上下関係だけじゃないの？ 日本語をソートするとばらばらになるとかでしょ 基底はWindowsAPIをUnicode版に切り替えるだけだから切り替えミスでもしてない限りはOverFlowはないと思うけど 切り替えしてないならアフォだけど LinuxとMacは単純にUnicodeAPIが無いから非対応という話ではないのか？ ちなみに一からlinuxやMacでUnicode作ろうと思ったら全部書き換えないと無理だろ 165 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 07:36:26 ] >>164 >LinuxとMacは単純にUnicodeAPIが無い UnicodeAPI って何だよw もしかして Windows 以外では UTF-8 とか 16 とか弄れないと思ってるの? 166 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 13:27:31 ] kernelレベルでデフォルトキャラセットをUnicodeにしないと無理でしょ 167 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 14:31:15 ] ふぅん、カーネルレベルねぇ... デフォルトキャラセットとな... 全部書き換えないと無理と... Linux も Mac も使ったこと無いのに色々知ってるんだ 偉いねえ 168 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 16:54:12 ] Unicodeはkernelレベルでサポートするべきものだったんだよ! 169 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 16:55:32 ] な，なんだってーっ! 170 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 17:47:29 ] >>168 当然そうあるべきだと思うが。 ファイルシステムやカーネルオブジェクト等に使われる名前の エンコーディングに一貫性が無いとロクなことにならない。 名前のエンコーディングが不明では、文字列として正しく処理をしようが無い。 一方名前にエンコーディング情報も付与することにしたら無駄に データ量が増えインタフェースも複雑化するだけ。 だから、Windows NTやPlan 9はUnicodeだよな。 Unixが時代遅れなだけ。 171 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 17:59:31 ] 一応書いておくと、カーネルモジュールでもファイルシステムとかは Unicode 扱えないとちょっとダサイ。でもこれはユーザランドのアプリ とは関係無い話。 172 名前：171 mailto:sage [2007/04/08(日) 18:04:28 ] ｽﾏﾝ。ボーッとしてたら被った。 >>170 "カーネルオブジェクト等に使われる名前" って何? ASCII Code の範囲を超える文字を使うケースってあるの? つか、カーネルモジュールで Unicode サポートが必要なのって ファイルシステムだけだよね?　そして普通の Un*x なら kiconv とか（似た様な名前の）機構が既に入ってるよね? >>170 が時代遅れなだけ? 173 名前：171 mailto:sage [2007/04/08(日) 18:12:33 ] 最後ちょっと下らない煽りっぽくなっちゃったが、カーネル内で実装されていようがいまいが、 ユーザランドのアプリで Unicode を使うには全く問題無いよ。全部書き換える必要なんて 全く無い。それと Mac も Linux もデフォで Unicode 使えるようになってるので、その意味 でも問題無い。 174 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 18:35:28 ] いや別にネットからダウンロードしたUTF-8の文字をバッファにいれてカーネルEUCの状態で表示しようがしまいが勝手だし そのためのクラス郡はwxWidgetsに用意されてるのだから好きにすればいいのでは？ 今の話ってそういう話じゃないよね Unicodeの入ったバッファの中身をEUCのAPIにパスして文字が化けるんですけどとかそういうこと言ってんでしょ？ そりゃ当たり前だって言ってるだけｗ 175 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 18:40:56 ] strcpyとかstrlenとかAPIだよ Unicodeの中身そのまま渡したらおかしくなるって 176 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 18:42:08 ] >>174 >EUCのAPI もっとくやしく。 177 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 18:51:32 ] Windowsは２個用意してる strcpyだとstrcpyAとstrcpyWと２種類のAPIが存在してコンパイルする時に何をベースにプログラムを動かすかで 自動的に切り替わるようになってる linuxやMacはこういう機構が無いのだから完全にカーネル依存になる 基本的にカーネルの扱う文字コード以外ではコンパイルしてはいけない 別の文字コードを扱う時はバッファ内で変換してからすべての処理に引き渡すようにしないといけない 178 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 19:26:12 ] >カーネル依存になる だから、ならねっての。 C/C++ の標準ライブラリとカーネルの話をごっちゃにしてるね。 ついでに言うとロケールについても分かっちゃいない。 179 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 19:40:11 ] kiconvって、kernel内部コードをUTF-8で統一 全てのシステムコールの界面でLC_CTYPEを使ってchar*のエンコード変換を 行うと解釈していいのかな？ それならWindowsの動作に近いんだが。 いや、kernel側にはユーザ側のLC_CTYPEは分からないか。 むしろシステムコールにラッパーかませるべき？どういう実装になってるの？ 180 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 19:44:56 ] 話が全然噛み合ってねえな… 181 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 19:45:09 ] >>177 > strcpyだとstrcpyAとstrcpyW 1. 存在しません。 2. strcpy()はWindows APIではなくC標準のランタイムライブラリです。 3. MSVC++はC標準ランタイムライブラリに対しても、TCHARベースの 　汎用テキストマッピングの仕掛けは提供しています。 　strcpy()の場合は、_tcscpy() -> strcpy() / wcscpy()です。 182 名前：179 mailto:sage [2007/04/08(日) 19:47:41 ] よくわからないんだけど。 kiconvってカーネルパッチでしょ？ コールゲート通過後の、カーネル空間に入っちゃったただのchar*のデータを どうエンコード変換すべきか、どうやって判断してるんだ？ Windows APIの場合は、APIのレイヤで全部UTF-16にしてるよ。 その層だと判断できるし、カーネル内部がUTF-16に閉じてクリーンになるから。 183 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 19:51:06 ] ネット斜め読みしただけで分かった風に書くなよ… 184 名前：179 mailto:sage [2007/04/08(日) 19:56:40 ] >>183 単純な話なんだから、分かってるのなら答えて欲しいんだけど。 ・マルチユーザシステムであるUnixでは、ユーザ毎にLC_CTYPE設定が異なり得る。 　これが前提。 ・何もしなければ（少なくとも昔のUnixでは）システムコールにchar*を渡せば 　それは「そのまま」kernelに素通しで渡るはず。つまり、一貫性の無い 　異なるエンコーディングの名前がkernelに渡されることになる。しかも 　kernelに渡ってしまった後はそのエンコーディングを判断するすべが無い。 　ユーザモードで呼ばれるシステムコールのCインタフェース（ラッパ）には 　呼び出し側プロセスの環境のLC_CTYPEが分かっているので、多分ロケールに 　従った変換をかけるならここがベストである、ように俺には見える。 で、 ・↑のような変換を行うシステムコールラッパの仕掛けなんですか ・kernel内部はUTF-8で統一されているのですか というのが質問。 間違っているのなら、どこがどう間違っているのか説明してほしい。 185 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 20:09:41 ] >>184 何つーかさ、↓こういう質問が出る時点で答えるのを躊躇しちゃうのよ。 >・kernel内部はUTF-8で統一されているのですか 正直、君のレベルに合わせて回答を作るのは「単純な話」じゃないと思うよ。 誰にとっても。 186 名前：179 mailto:sage [2007/04/08(日) 20:13:21 ] >>185 >・kernel内部はUTF-8で統一されているのですか なぜ、この疑問がそんなに問題なの？ Windows NTは、kernelが扱う「名前」「テキスト」は、全てUTF-16だよ。 kernelの扱う名前のエンコーディングに一貫性が無いと、例えばファイルシステム のファイル名のエンコーディングが統一されていないと、問題でしょ？ UTF-16に統一することで、そのような問題を避けつつ、ASCIIよりはるかに 大きな文字集合を無問題に扱うことが出来ているわけ。 少なくともWindowsでは。 無論ファイルの中に入っていたりネットワークを流れるデータ（バイト列）の 具体的な中身にはkernelは関与しないよ。それはユーザレベルの話。 187 名前：179 mailto:sage [2007/04/08(日) 20:19:48 ] 例えば fd = creat(filename, 0666); を実行した時に、 1) filenameはどこかでUTF-8に変換されますか 2) それはどこで行われますか 3) 変換されないならば、「全ての」ユーザコードが「各自」適切な 　エンコーディングを指定しない限り、 　ファイルシステムのエンコーディングの一貫性は保障されないということで 　良いですね。 ということなんだが。 188 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 20:31:18 ] >>186 前にも書いたけどさ、符号化方式はファイルシステム固有の話であって 「カーネル内部で統一」という言い方はおかしいよね? 単に一個のカーネルモジュールに過ぎない訳だから。 君も一応マイクロカーネルな OS 使ってるんでしょ? これはｵｹ? 189 名前：179 mailto:sage [2007/04/08(日) 20:52:19 ] >>188 ・非Unicodeの符号化形式を採用しているファイルシステムは、それだけで 　i18n/m17n対応においてUnicodeベースのもの(FAT32やNTFS)より劣ると 　いわざるを得ないだろう。 ・ファイルシステムが非Unicodeの符号化形式を用いている場合、ファイルシステムの 　モジュールなりドライバなりが、相互変換を行うべき。そしてその層に 　それが閉じているならば、カーネルとしてはUnicodeで考えることが出来るので 　「統一」と呼べるのでは。 　統一されていれば、異なるファイルシステム上の名前を比較したり、ファイル 　システム間で名前をコピーすることの問題も無くなるし、 　ユーザの実行環境のロケールが何であろうと、そのロケールとの相互変換を 　どこかのレイヤが行いさえすれば、問題なくファイル名を取り扱うことが出来る。 ・今きづいたのだが、ファイルシステムの符号化形式との間の決めウチ変換を 　行うのがkiconvの役目？もしかして。 　だとすれば、それだけではWindowsの提供する環境より 　随分劣るといわざるを得ない。 190 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 20:57:58 ] 相変わらず、話が全然噛み合ってねえな… 191 名前：179 mailto:sage [2007/04/08(日) 21:10:05 ] >>187のような単純な質問には誰も答えてくれないの？ filenameの中身がUTF-8エンコードされていないなら、結局どうなるの？ 1) EILSEQエラーなどではじかれる。 2) 普通にテキストと解釈できないへんな名前のファイルが出来る。 3) プロセス実行環境のLC_CTYPEに応じて、UTF-8に誰かが変換してくれる。 4) ファイルシステムに甚大な被害を及ぼす可能性がある。 192 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 21:14:45 ] >>191 何答えても屁理屈こねられそうだからみんな嫌がってんだよ。 193 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 21:15:33 ] >>187 1. いいえ 3. はい 194 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 21:16:49 ] >>191 2 195 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 21:17:24 ] ↓勝ち誇った書き込みｷﾀｰ 196 名前：179 mailto:sage [2007/04/08(日) 21:19:08 ] >>192 具体的に俺の「どの」発言が屁理屈なの。 誤っている箇所があるなら指摘してくれよ。 俺はそもそも屁理屈をこねるほど最近のLinuxのことを知らないから、 聞いてるだけなんだが。 197 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 21:21:54 ] >>196 ↓これ >>189 >・ファイルシステムが非Unicodeの符号化形式を用いている場合、ファイルシステムの >　モジュールなりドライバなりが、相互変換を行うべき。そしてその層に >　それが閉じているならば、カーネルとしてはUnicodeで考えることが出来るので >　「統一」と呼べるのでは。 >　統一されていれば、異なるファイルシステム上の名前を比較したり、ファイル >　システム間で名前をコピーすることの問題も無くなるし、 >　ユーザの実行環境のロケールが何であろうと、そのロケールとの相互変換を >　どこかのレイヤが行いさえすれば、問題なくファイル名を取り扱うことが出来る。 198 名前：179 mailto:sage [2007/04/08(日) 21:22:24 ] >>193, 194 教えてくれてあんがと。 んじゃ、問題ないとか言い切ってる>>171は勇み足さんかな。 事実上そのUTF-8対応したLinuxとそうでない従来型ロケールベースでは 運用方法から何から全然変わってこない？ 皆が皆UTF-8に移行してるわけじゃないでしょ？ どっちでも動くプログラムとか書くの、面倒じゃないの？ 199 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 21:25:00 ] >>198 >>>171は勇み足さんかな。 勝手にあんたの持論に巻き込むな。 200 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 21:31:09 ] >>198 >事実上そのUTF-8対応したLinuxとそうでない従来型ロケールベースでは >運用方法から何から全然変わってこない？ 誰か俺にも分かるように翻訳してくれ。 201 名前：179 mailto:sage [2007/04/08(日) 21:42:51 ] >>200 非UTF-8カーネルでユーザ毎にLC_CTYPEが異なる昔ながらのL10N環境と、 カーネルからユーザロケールまでUTF-8を前提とした環境と、 UTF-8カーネルに従来型ロケールの環境では、 ユーザコードでiconv()やwcstombs()等を用いた変換が必要な箇所が 変わってくるんでは？と思ったんだけど。 気のせいだというのならいい。 202 名前：179 mailto:sage [2007/04/08(日) 21:43:50 ] >>197 えーと、俺は見ての通り頭が悪いし最近のLinuxのことは知らないので、 誤りはもっとピンポイントかつ具体的に指摘してくれると嬉しいのですが。 203 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 21:54:41 ] >>202 > 誤りはもっとピンポイントかつ具体的に指摘してくれると嬉しいのですが。 スレ違い 204 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 23:46:39 ] よくある逃げ方だな。 ごくろーさんｗ 205 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 23:52:15 ] ↑捨て台詞ｷﾀｰ 206 名前：179 mailto:sage [2007/04/09(月) 00:00:11 ] >>204は俺ではないですよ。どうでもよいことですが。 207 名前：デフォルトの名無しさん mailto:sage [2007/04/09(月) 00:54:49 ] で結局 EUCベースのlinuxでwxWidgetsでUTF-8を用いたアプリを開発するにはどうすればよいかという話でしょ １．wxWidgetsが馬鹿なので書き換える ２．アプリをEUCで作る ３．linuxをUTF-8に対応させる さあどれだｗ 208 名前：デフォルトの名無しさん mailto:sage [2007/04/09(月) 00:57:38 ] 話の発端はwxMACだっけ ということはMACのカーネルは何のコードがデフォなんだ？ 209 名前：デフォルトの名無しさん mailto:sage [2007/04/09(月) 01:32:03 ] わかってもいないし調べる気もない奴らばっかだということはよくわかったから もうここで続けるな。どこか他所でやってくれよ。 210 名前：デフォルトの名無しさん mailto:sage [2007/04/09(月) 01:55:55 ] >>193-194を見る限り、 $ touch ほげ とかやった場合、要するにロケール設定によって全然別の名前のファイルが 作られるわけか？ なんかもう脳死してるっていうか、どうしようもないんじゃねぇのこれ 211 名前：デフォルトの名無しさん mailto:sage [2007/04/09(月) 02:04:26 ] wow　wxWidgetsの話はどこに行ったのさ？ 212 名前：デフォルトの名無しさん mailto:sage [2007/04/09(月) 02:04:34 ] つか、非ASCII文字を含むファイル名を表示するまともな方法、存在すんのか？ ほげ：sjis ほげ：euc-jp ほげ：utf-8 みたいなファイル名が混在し得るんでしょ？ 一つのファイルシステムに。 213 名前：デフォルトの名無しさん mailto:sage [2007/04/09(月) 02:28:20 ] >>211 readdir()やftsを使ってで読み取ったファイル名のリスト をリストボックスか何かに表示したいです。 どうするのが正しいのでしょうか。 214 名前：デフォルトの名無しさん mailto:sage [2007/04/09(月) 02:41:11 ] WindowsだってeucとかUTF-8のファイル作ろうと思えば作れる罠 215 名前：デフォルトの名無しさん mailto:sage [2007/04/09(月) 02:45:52 ] リストボックスは当然ながらKDEとかGNOME依存でこれらは結局kernelの文字コードにあわしてある kernelがEUCなら当然XシステムもEUCでフォントデータベースもEUCだからEUCのフォントインデックスじゃないと いわゆる文字化けした状態になる 216 名前：デフォルトの名無しさん mailto:sage [2007/04/09(月) 02:56:42 ] >>215 > kernelの文字コード > kernelがEUCなら いみが わかりません。 Linuxでは、文字エンコーディングを指定してカーネルを再構築するのでしょうか？ それによって、具体的にkernelの何が変わるのですか？ Unixはマルチユーザシステムですが、他のLocale設定を使いたいユーザは どうすればよいのでしょうか？ 217 名前：デフォルトの名無しさん mailto:sage [2007/04/09(月) 03:06:44 ] >>214 「やろうと思えば出来る」のと、「通常の使用でそういう事故が起きる」 のとでは、当然ながら全然違うんだが。 WindowsのコードページはUnixのロケールほど揮発性でも動的でもないし、 むしろ日本語Windowsなら実質CP932決めウチ、みたいな世界だ。 そしてAnsi版APIは、APIレベルでUTF-16への変換を試みるから、そこで 妙な名前はガードされる。 Unicode版APIは素通しだけどな。CreateFileW()にUTF-16として 正しくない並びの文字列を渡してもそのファイルを作れてしまうのは確か。 ただし、「ユーザが」「普通に」使用していてそういう事態に陥ることは まずない。 218 名前：デフォルトの名無しさん mailto:sage [2007/04/09(月) 03:55:56 ] >>215 もうそのネタを引っ張るのは無理でしょ。流石にフォントの並びは変わらねえw 「カーネルの文字コード」という概念は個人的に破壊力抜群だったけどww 「EUC ベースの Linux」は後々まで語り継がれる名言だったなwww 釣り、なんだよね? 219 名前：デフォルトの名無しさん mailto:sage [2007/04/09(月) 04:06:30 ] また過去においては Linux の C Library にはロケール機構の実装は行われて おらず X Window System の提供するロケール機構を使用していた。近年になっ て X のロケールから GNU C Library version 2 に実装されたロケールへの移 行が進んでいる。残念ながら現時点では日本語をはじめとする多バイト文字の ロケール機構は機能していないが実装作業が進行中であり、近日中に利用可能 になるものと思われる。 220 名前：デフォルトの名無しさん mailto:sage [2007/04/09(月) 04:20:33 ] >>210,>>212,>>217 Windows だって一緒やがな。メールに添付されたファイルのファイル名が EUC-JP だったら誰が valid なファイル名を探してくれるのでしょうね。zip に入っていたファイルの ファイル名が UTF-16 のエンディアン違いだったらどうするのかな? スレ違いなんで↓続きはこっちでやってね。 文字コード総合スレ part2 pc11.2ch.net/test/read.cgi/tech/1143375639/ >>219 残念ながらそのネタも面白くないと思われるよ。 221 名前：デフォルトの名無しさん mailto:sage [2007/04/09(月) 04:49:56 ] >>220 ちゃんと規格確認してから言ってる? 特定の実装の問題を全体に拡大解釈するなよ 222 名前：デフォルトの名無しさん mailto:sage [2007/04/09(月) 05:18:41 ] >>221 規格って、zip に入れるファイル名の文字コードの規格があるの? 特定の実装って何の実装の事? 実際には Linux だってわざわざファイル名に複数の文字コードを混在させて使おうと する人間はいない。混在可能ってだけだし、それは Windows でも一緒。 223 名前：デフォルトの名無しさん mailto:sage [2007/04/09(月) 05:35:45 ] 知識自慢ばっかで解決策を語れるスマートな人間はまったくいないな wxWidgetsのソースをいじるなんてのは非現実的だし ロケールをわざわざUnicodeに変換したって既存のソフトが動かなくなるだけ 答えは１つ、デフォルトロケールにアプリを合わせて自前でコード変換するだけ それ以外の方法はない それ以外の方法しか考えられないやつはただの馬鹿 224 名前：デフォルトの名無しさん mailto:sage [2007/04/09(月) 05:38:24 ] 知識自慢というか、正しい認識を持つことは重要だよ。 で、何の解決策が必要なんだっけ? 225 名前：デフォルトの名無しさん mailto:sage [2007/04/09(月) 06:06:24 ] ボケ老人は無理して話に加わらなくていいのに・・・。 226 名前：デフォルトの名無しさん mailto:sage [2007/04/09(月) 06:51:00 ] > zip に入れるファイル名の文字コードの規格があるの? zip に入れるファイル名の文字コードの規格はないの? 227 名前：デフォルトの名無しさん mailto:sage [2007/04/09(月) 07:26:40 ] 無い 228 名前：デフォルトの名無しさん mailto:sage [2007/04/09(月) 08:08:56 ] 無いよなぁ… 229 名前：デフォルトの名無しさん mailto:sage [2007/04/09(月) 08:11:09 ] >>223 >wxWidgetsのソースをいじるなんてのは非現実的だし ノンサポートのライブラリなんだから、きちんと全容を把握して 自分で手を入れられるようになっておいた方が良いぜ。 230 名前：デフォルトの名無しさん mailto:sage [2007/04/09(月) 08:54:57 ] >>223 オープンソースなんだし常識じゃないの？ カーネルのソースも、wxWidgetsのソースも動作がおかしい場合は、 読んで修正しないとねぇ。 231 名前：デフォルトの名無しさん mailto:sage [2007/04/09(月) 12:06:11 ] >>220 あのさぁ。メールの添付ファイルだのzipアーカイブの中身だのに含まれる ファイル名をどうシステムのファイル名にマップするかってのは、 そのプロトコルなりRFCなりファイルフォーマットなりの話であって OSの仕事ではないでしょ？ そこに不備があるのなら、それはOSでなくて、符号化形式が self-containedではないそれらの不備ってだけだろ？ 232 名前：デフォルトの名無しさん mailto:sage [2007/04/09(月) 12:08:37 ] 少なくともWindowsでは 単にシェルでファイルをとりあつかうだけのことで問題が生じることは無い。 ファイル名はUTF-16「である」のがWindowsだ。 Windowsのファイル名はコードページに依存しないし、コードページによらず 漢字や拡張ラテン文字を含むファイル名を同時に正しく扱える。 Linuxでは $ >ほげ とかやるとどうなるんだっけ？ 233 名前：デフォルトの名無しさん [2007/04/09(月) 12:36:11 ] スレ違いage 234 名前：デフォルトの名無しさん mailto:sage [2007/04/09(月) 13:32:49 ] 結局、>>213の答えは？ 235 名前：デフォルトの名無しさん mailto:sage [2007/04/09(月) 13:38:35 ] >>229 入れられるのと実際に入れるのとでは意味が違う 手を加えたらパッチが当たった時にまたそれに合わせて全部拾い出していくのか？ よっぽど暇なんですね 236 名前：デフォルトの名無しさん mailto:sage [2007/04/09(月) 13:41:47 ] せっかくクロスプラットフォームで多くのチェックが入ってバランス統一されたものに わざわざ手を加えてクロスプラットフォームじゃなくならせるなんてよっぽど馬鹿なんですね 237 名前：デフォルトの名無しさん mailto:sage [2007/04/09(月) 17:45:41 ] >>234 見ればわかると思うけど、ここ能無ししかいないから 誰も答えられません。 238 名前：デフォルトの名無しさん mailto:sage [2007/04/09(月) 18:26:14 ] じゃあお前が答えろよｗ 239 名前：デフォルトの名無しさん mailto:sage [2007/04/09(月) 18:34:55 ] 知識が無いことより、分かっている振りをすることのほうがはるかに馬鹿な事なのに プログラマはそれがわからない馬鹿が多くて本当に嫌な人種だな むしろ人間じゃねーな 240 名前：デフォルトの名無しさん mailto:sage [2007/04/09(月) 20:18:26 ] >>231 そこまで書いたら自分で気付けよw 241 名前：デフォルトの名無しさん mailto:sage [2007/04/09(月) 21:49:34 ] >>240 要するに、Windowsのファイル名はUTF-16固定だが Unixのファイル名のエンコーディングに関しては、規約も標準も 何も無い無法地帯で、かつシステムグローバルでも何でもないLC_CTYPE 環境変数の設定でエンコーディングがころころ変わってしまい、 結果としてプログラム的にどうあるべき、という正しい判断のしようが無いから 糞なんだろ？ どこが「Windowsも同じ」なの？ Zipのようなファイル形式で困ったことになる点だけは確かに同じだな。 だが、それはOSの問題ではないし、論点ずらしだろ。 242 名前：デフォルトの名無しさん mailto:sage [2007/04/09(月) 21:51:50 ] >>241 惜しい。あと一歩真実へ踏み出してみよう。 243 名前：デフォルトの名無しさん mailto:sage [2007/04/09(月) 21:56:50 ] つづきまだ〜？（ﾁﾝﾁﾝ（AAｒｙ 244 名前：デフォルトの名無しさん mailto:sage [2007/04/09(月) 22:02:56 ] ちゃんと考えなきゃダメだぜ。 245 名前：デフォルトの名無しさん mailto:sage [2007/04/09(月) 22:10:28 ] 例えばプレーンなテキストファイルのエンコーディングは分からない （符号化形式がselfcontainedでない）ってのはOSに限らない 普遍的かつ伝統的な問題なわけで、 ファイルの中のデータを扱う部分はどうしても汚い仕事にならざるを 得ないと思うのよ。典型的なのが日本語のエンコーディングの自動判別の ようなヒューリスティック。 Unixの世界ではファイル名もこれと同じなわけだけど、Unicodeに 統一できるなら、したほうがいいに決まってるし、完璧ではないにしろ それが可能な世界だと思うんだ。 Windowsではそうなってるわけでしょ。 246 名前：デフォルトの名無しさん mailto:sage [2007/04/09(月) 22:18:35 ] 少なくともWindowsでは、何かファイル名を外部からもらった時に、 それをOSに渡す際にはUTF-16に変換するのが「正しい」ことは分かる。 どうやったらUTF-8に変換できるのか分からないならば、それは貰い方、例えば ファイル形式やプロトコル等に問題があると言うことが出来る。 それはWindowsの問題ではない。 Unixはそれ以前の問題。それが非ASCII文字を含む場合、どう扱うのが 「正しい」のかが全く分からない。 一般解は存在せず、環境・プログラム毎の特殊解のみがあるのだろう。 247 名前：デフォルトの名無しさん mailto:sage [2007/04/09(月) 23:07:08 ] >>246 >どう扱うのが「正しい」のかが全く分からない。 どう扱うのが正しいのかを決めるのはユーザ様な世界なんだよ。 分からないんじゃなくて、勝手な決め打ちしないだけ。 全能なるユーザ様が入力なされた物を勝手に変換するなと。 "touch ほげ" の結果生成されるファイル名がロケール依存で 変化するのは UN*X 的に正しい世界。何故ならユーザ様が ロケールを設定しているから。アプリはロケールに従ってデータを 読み出せば全く問題無い。これが UN*X 的な正しい扱い方。 入力には寛容に。 ファイル名のエンコードは一応それなりに決まっていて、HFS+ なんかは UTF-16 になっている。決まっているだけで EUC でも 書き込めるのは Windows と一緒だね。 248 名前：デフォルトの名無しさん mailto:sage [2007/04/09(月) 23:26:45 ] UNIXの世界において、kernelのレイヤでは全て単なるバイト列。 \0と/は特別扱いやけどな。 エンコーディング等は、kernelの知・っ・た・こ・と・で・は・な・い。 249 名前：デフォルトの名無しさん mailto:sage [2007/04/09(月) 23:39:55 ] 正しいとか正しくないとか俺様理論は他でやってくれないか？ 250 名前：デフォルトの名無しさん mailto:sage [2007/04/09(月) 23:41:01 ] あのな\0が特別って\0だけで十分にエンコード依存なんだよ馬鹿 251 名前：デフォルトの名無しさん [2007/04/09(月) 23:42:50 ] 俺様理論っつうか、エンコードとかkernelの話は他でやってくれ 252 名前：デフォルトの名無しさん mailto:sage [2007/04/09(月) 23:47:16 ] 何度も言うけども wxWidgetsを正常に使いたかったらわざわざロケールを変更するような暇なことしたり wxWidgetsを自分好みに作り変えたりするのは馬鹿のすることだ デフォルトロケールのエンコードにあわせるのが正当なやり方だ Windowsの場合はSJISとUnicodeの両者が共存出来るようなうまいしくみがあるから選べるだけ

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef