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
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にパスして文字が化けるんですけどとかそういうこと言ってんでしょ? そりゃ当たり前だって言ってるだけw
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は2個用意してる strcpyだとstrcpyAとstrcpyWと2種類の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 ] よくある逃げ方だな。 ごくろーさんw
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を用いたアプリを開発するにはどうすればよいかという話でしょ 1.wxWidgetsが馬鹿なので書き換える 2.アプリをEUCで作る 3.linuxをUTF-8に対応させる さあどれだw
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に変換したって既存のソフトが動かなくなるだけ 答えは1つ、デフォルトロケールにアプリを合わせて自前でコード変換するだけ それ以外の方法はない それ以外の方法しか考えられないやつはただの馬鹿
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 ] じゃあお前が答えろよw
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 ] つづきまだ〜?(チンチン(AAry
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の両者が共存出来るようなうまいしくみがあるから選べるだけ
253 名前:デフォルトの名無しさん mailto:sage [2007/04/09(月) 23:50:48 ] >>249 核心を突いたね。そう。単一の文字コードに決め打ちして正しいとか言ってるのは 俺様理論なんだよね。簡単に破綻するのにね。しかも UTF-16 だからなあ…
254 名前:デフォルトの名無しさん mailto:sage [2007/04/09(月) 23:53:05 ] >>252 一生 Windows だけ使ってる分にはそれで良いと思うよ。 Microsoft 以外が出しているおかしな OS なんて使う必要無いよ!
255 名前:デフォルトの名無しさん mailto:sage [2007/04/09(月) 23:57:45 ] どうせMACはバージョンによって文字コードが違っても互換性がないのだからw UNIX系なんてそもそもバイナリ配布できるような環境にないだろw どうせそのコンピュータでコンパイルして動かすのだからロケールなんて統一したほうがかえってややこしいことになる コンパイル環境のロケールでそのまま動くように作ればいいだけ 問題になるのはスタティック文字列くらいなもん
256 名前:デフォルトの名無しさん mailto:sage [2007/04/10(火) 00:02:38 ] オケ
257 名前:デフォルトの名無しさん mailto:sage [2007/04/10(火) 01:07:07 ] また一人気違いが……。よそでやれ。
258 名前:デフォルトの名無しさん mailto:sage [2007/04/10(火) 01:10:54 ] >>247 > "touch ほげ" の結果生成されるファイル名がロケール依存で > 変化するのは UN*X 的に正しい世界。何故ならユーザ様が > ロケールを設定しているから。アプリはロケールに従ってデータを > 読み出せば全く問題無い。 touch ほげを実行したユーザが、ファイル名を読み取るユーザと同じとは 限らないのがUnixでしょ。読み取るプロセスはデーモンかもしれないし、 cronあたりから実行されているバッチかもしれない。 ftpやtelnet越しのユーザかもしれない。 実におめでたいね。 >>248 うん、それで? 結果として、単に非ASCII以外の文字を含む名前がひどく扱いにくい世界に なったわけだよね。 時代遅れだね。 >>253 Unixの「自由」は欲しくない自由なんだよ。俺に言わせれば。 プレーンテキストどころか、ファイルの中の行毎にエンコーディングが 異なる、何がなんだか分からないファイルを考えてみればよい。論外だろ? 「自由」にしたいのなら、せめてエンコーディング方式が分かるようにしろと。
259 名前:デフォルトの名無しさん mailto:sage [2007/04/10(火) 01:40:40 ] 「議論」したいのなら、せめて該当するスレに移ってくれと。
260 名前:155 mailto:sage [2007/04/10(火) 02:18:16 ] ぎょえ。なんかすごいことに。 しかもなぜか関係ないファイル名の話になってるし…。 荒れるからもう Unicode の話はふらないよ…。 ゴメンネ。
261 名前:デフォルトの名無しさん mailto:sage [2007/04/10(火) 08:24:38 ] >>258 それで問題無いよ。お仕着せが良いなら Windows を使っていれば良い話。 見掛け上の統一感に満足していれば良い。Windows が最高なんでしょ? 俺は、文字コードの揺らぎは常に存在するものである事を前提に、自分で 自由に制御出来る環境の方が優れていると思う。 いつだって他人の流儀を認められないのが Windows ユーザだよなあ。 ぬるい世界で満足しているなら、そこから出て来なければ良いのにね。
262 名前:デフォルトの名無しさん mailto:sage [2007/04/10(火) 10:12:08 ] >>261 > いつだって他人の流儀を認められないのが Windows ユーザだよなあ。 イラッとして書いたんだろうけどこういうひとくくりにする発言はやめようよ。 使ってるOSの問題じゃないからさ。
263 名前:デフォルトの名無しさん mailto:sage [2007/04/10(火) 10:58:01 ] イラッとして書いたんじゃなくて、そのあたりが>>261 のレベルなんです。 あらゆるコミュニティから「お前は入ってこないで」と思われるタイプ。
264 名前:デフォルトの名無しさん mailto:sage [2007/04/10(火) 12:29:12 ] こーゆー輩は他人を貶して優越感に浸りたいだけだから放って置いたほうが良いよ
265 名前:デフォルトの名無しさん mailto:sage [2007/04/10(火) 12:43:38 ] >>261 ね。 テクニカルな内容がほぼゼロ。本人の品性が良く分かる煽り文ですね。 > 俺は、文字コードの揺らぎは常に存在するものである事を前提に、自分で > 自由に制御出来る環境の方が優れていると思う。 エンコーディング情報が正しく含まれるのならそれもいいだろうけど、 実際には、各行のエンコーディングがごたまぜ、何が使われているか分からない テキストファイルも同然の状態なわけですよ。ファイル名が何でエンコードされてるか どこにも記録されない上に、一貫性のある規約も無いのが現実。 自分の環境は自分の都合のいいように運用するからそれでおk? あなたは仮にもプログラマでしょう? 趣味でLinuxいじってるだけのパソコンオタクじゃないんでしょ? プログラマとしてコードを書くときに、自分の環境しか考えないの? 例えば「ゆらぎがあることを前提に」、あなたなら>>213 のケースにどう 回答するの? Windowsはあなたに言わせればぬるい環境で、Unixは優れてるんでしょ? 俺様環境でしか通用しない糞コードではなく、 素晴らしい回答を期待してますよ。
266 名前:261 mailto:sage [2007/04/10(火) 19:11:39 ] なんか変なのがまとめて沸いてきたなぁ。それとも同一人物か? 自分の痛さを指摘されて逆上した Windows ユーザ? まぁ、まともなレベルのものが書けたら相手してあげるよ。頑張ってね。
267 名前:デフォルトの名無しさん mailto:sage [2007/04/10(火) 20:25:50 ] 自分が痛いとはこれっぽっちも思ってないらしいな(ワラ
268 名前:261 mailto:sage [2007/04/10(火) 21:00:09 ] 痛くないから当然だな。 まともなことを言ってるのに「痛くてすみません」ってな態度を取るのは 謙虚でもなんでもない。ただ間違っているだけだ。 それにしても、本当に逆上してるんだな。 負け癖のついた議論好きってこんな感じなんだよな。
269 名前:デフォルトの名無しさん mailto:sage [2007/04/10(火) 21:01:12 ] 新着で100もレスついてるから何かと思えば…
270 名前:261 mailto:sage [2007/04/10(火) 21:07:58 ] 馬鹿は一匹出てくると立て続けに何十匹も出てくるからな。 スレが無駄に伸びる伸びる。
271 名前:デフォルトの名無しさん mailto:sage [2007/04/10(火) 21:10:27 ] >>266 ,>>268 ,>>270 お、俺がもう一人居る。あんたが >>261 だとすると、俺は誰だw 何にせよ >>261 の書き込みは破壊力抜群だったみたいで何より。 >>262 には悪い事したけど、まともな人はもう居ないと思ってた。 >>265 あんたプログラマだったの? プログラマは平日昼間から 2ch やれて羨ましいなあ。 エンコーディング情報は環境変数からとって来るから良いんだよ。 あんたが思ってる様なカオスの世界では無いよ。