【GUI】wxWidgets(旧wxWindows) その3【サイザー】
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2006/09/09(土) 00:06:30本家
http://www.wxwidgets.org/
wxWindows日本語プロジェクト
http://wxwindowsjp.sourceforge.jp/
Let's wxWidgets
http://dot-gray.s33.xrea.com/
(*)準備中(*)
http://www.geocities.co.jp/SiliconValley-Cupertino/8526/
wxWindowsで始めるC++ GUIプログラミング
http://www.h3.dion.ne.jp/~k5_n/wxwin/
wxWidgets でクロスプラットフォーム GUIアプリを作ろう
http://namazu.org/~satoru/pub/uu-2004-08/
dW : Linux : wxWindowsの概要
http://www-6.ibm.com/jp/developerworks/linux/010413/j_l-wxwin.html
SunWorld Online：wxWindows――無名だが成熟したGUIツールキット
http://www.idg.co.jp/sw/back/200102/20010219_01_report.html
0171デフォルトの名無しさん
2007/04/08(日) 17:59:31Unicode 扱えないとちょっとダサイ。でもこれはユーザランドのアプリ
とは関係無い話。
0172171
2007/04/08(日) 18:04:28>>170
"カーネルオブジェクト等に使われる名前" って何?
ASCII Code の範囲を超える文字を使うケースってあるの?
つか、カーネルモジュールで Unicode サポートが必要なのって
ファイルシステムだけだよね? そして普通の Un*x なら kiconv
とか（似た様な名前の）機構が既に入ってるよね?
>>170 が時代遅れなだけ?
0173171
2007/04/08(日) 18:12:33ユーザランドのアプリで Unicode を使うには全く問題無いよ。全部書き換える必要なんて
全く無い。それと Mac も Linux もデフォで Unicode 使えるようになってるので、その意味
でも問題無い。
0174デフォルトの名無しさん
2007/04/08(日) 18:35:28そのためのクラス郡はwxWidgetsに用意されてるのだから好きにすればいいのでは？
今の話ってそういう話じゃないよね
Unicodeの入ったバッファの中身をEUCのAPIにパスして文字が化けるんですけどとかそういうこと言ってんでしょ？
そりゃ当たり前だって言ってるだけｗ
0175デフォルトの名無しさん
2007/04/08(日) 18:40:56Unicodeの中身そのまま渡したらおかしくなるって
0176デフォルトの名無しさん
2007/04/08(日) 18:42:08>EUCのAPI
もっとくやしく。
0177デフォルトの名無しさん
2007/04/08(日) 18:51:32strcpyだとstrcpyAとstrcpyWと２種類のAPIが存在してコンパイルする時に何をベースにプログラムを動かすかで
自動的に切り替わるようになってる
linuxやMacはこういう機構が無いのだから完全にカーネル依存になる
基本的にカーネルの扱う文字コード以外ではコンパイルしてはいけない
別の文字コードを扱う時はバッファ内で変換してからすべての処理に引き渡すようにしないといけない
0178デフォルトの名無しさん
2007/04/08(日) 19:26:12だから、ならねっての。
C/C++ の標準ライブラリとカーネルの話をごっちゃにしてるね。
ついでに言うとロケールについても分かっちゃいない。
0179デフォルトの名無しさん
2007/04/08(日) 19:40:11全てのシステムコールの界面でLC_CTYPEを使ってchar*のエンコード変換を
行うと解釈していいのかな？
それならWindowsの動作に近いんだが。
いや、kernel側にはユーザ側のLC_CTYPEは分からないか。
むしろシステムコールにラッパーかませるべき？どういう実装になってるの？
0180デフォルトの名無しさん
2007/04/08(日) 19:44:560181デフォルトの名無しさん
2007/04/08(日) 19:45:09> strcpyだとstrcpyAとstrcpyW
1. 存在しません。
2. strcpy()はWindows APIではなくC標準のランタイムライブラリです。
3. MSVC++はC標準ランタイムライブラリに対しても、TCHARベースの
汎用テキストマッピングの仕掛けは提供しています。
strcpy()の場合は、_tcscpy() -> strcpy() / wcscpy()です。
0182179
2007/04/08(日) 19:47:41kiconvってカーネルパッチでしょ？
コールゲート通過後の、カーネル空間に入っちゃったただのchar*のデータを
どうエンコード変換すべきか、どうやって判断してるんだ？
Windows APIの場合は、APIのレイヤで全部UTF-16にしてるよ。
その層だと判断できるし、カーネル内部がUTF-16に閉じてクリーンになるから。
0183デフォルトの名無しさん
2007/04/08(日) 19:51:060184179
2007/04/08(日) 19:56:40単純な話なんだから、分かってるのなら答えて欲しいんだけど。
・マルチユーザシステムであるUnixでは、ユーザ毎にLC_CTYPE設定が異なり得る。
これが前提。
・何もしなければ（少なくとも昔のUnixでは）システムコールにchar*を渡せば
それは「そのまま」kernelに素通しで渡るはず。つまり、一貫性の無い
異なるエンコーディングの名前がkernelに渡されることになる。しかも
kernelに渡ってしまった後はそのエンコーディングを判断するすべが無い。
ユーザモードで呼ばれるシステムコールのCインタフェース（ラッパ）には
呼び出し側プロセスの環境のLC_CTYPEが分かっているので、多分ロケールに
従った変換をかけるならここがベストである、ように俺には見える。
で、
・↑のような変換を行うシステムコールラッパの仕掛けなんですか
・kernel内部はUTF-8で統一されているのですか
というのが質問。
間違っているのなら、どこがどう間違っているのか説明してほしい。
0185デフォルトの名無しさん
2007/04/08(日) 20:09:41何つーかさ、↓こういう質問が出る時点で答えるのを躊躇しちゃうのよ。
>・kernel内部はUTF-8で統一されているのですか
正直、君のレベルに合わせて回答を作るのは「単純な話」じゃないと思うよ。
誰にとっても。
0186179
2007/04/08(日) 20:13:21>・kernel内部はUTF-8で統一されているのですか
なぜ、この疑問がそんなに問題なの？
Windows NTは、kernelが扱う「名前」「テキスト」は、全てUTF-16だよ。
kernelの扱う名前のエンコーディングに一貫性が無いと、例えばファイルシステム
のファイル名のエンコーディングが統一されていないと、問題でしょ？
UTF-16に統一することで、そのような問題を避けつつ、ASCIIよりはるかに
大きな文字集合を無問題に扱うことが出来ているわけ。
少なくともWindowsでは。
無論ファイルの中に入っていたりネットワークを流れるデータ（バイト列）の
具体的な中身にはkernelは関与しないよ。それはユーザレベルの話。
0187179
2007/04/08(日) 20:19:48fd = creat(filename, 0666);
を実行した時に、
1) filenameはどこかでUTF-8に変換されますか
2) それはどこで行われますか
3) 変換されないならば、「全ての」ユーザコードが「各自」適切な
エンコーディングを指定しない限り、
ファイルシステムのエンコーディングの一貫性は保障されないということで
良いですね。
ということなんだが。
0188デフォルトの名無しさん
2007/04/08(日) 20:31:18前にも書いたけどさ、符号化方式はファイルシステム固有の話であって
「カーネル内部で統一」という言い方はおかしいよね?
単に一個のカーネルモジュールに過ぎない訳だから。
君も一応マイクロカーネルな OS 使ってるんでしょ?
これはｵｹ?
0189179
2007/04/08(日) 20:52:19・非Unicodeの符号化形式を採用しているファイルシステムは、それだけで
i18n/m17n対応においてUnicodeベースのもの(FAT32やNTFS)より劣ると
いわざるを得ないだろう。
・ファイルシステムが非Unicodeの符号化形式を用いている場合、ファイルシステムの
モジュールなりドライバなりが、相互変換を行うべき。そしてその層に
それが閉じているならば、カーネルとしてはUnicodeで考えることが出来るので
「統一」と呼べるのでは。
統一されていれば、異なるファイルシステム上の名前を比較したり、ファイル
システム間で名前をコピーすることの問題も無くなるし、
ユーザの実行環境のロケールが何であろうと、そのロケールとの相互変換を
どこかのレイヤが行いさえすれば、問題なくファイル名を取り扱うことが出来る。
・今きづいたのだが、ファイルシステムの符号化形式との間の決めウチ変換を
行うのがkiconvの役目？もしかして。
だとすれば、それだけではWindowsの提供する環境より
随分劣るといわざるを得ない。
0190デフォルトの名無しさん
2007/04/08(日) 20:57:580191179
2007/04/08(日) 21:10:05filenameの中身がUTF-8エンコードされていないなら、結局どうなるの？
1) EILSEQエラーなどではじかれる。
2) 普通にテキストと解釈できないへんな名前のファイルが出来る。
3) プロセス実行環境のLC_CTYPEに応じて、UTF-8に誰かが変換してくれる。
4) ファイルシステムに甚大な被害を及ぼす可能性がある。
0192デフォルトの名無しさん
2007/04/08(日) 21:14:45何答えても屁理屈こねられそうだからみんな嫌がってんだよ。
0193デフォルトの名無しさん
2007/04/08(日) 21:15:331. いいえ
3. はい
0194デフォルトの名無しさん
2007/04/08(日) 21:16:492
0195デフォルトの名無しさん
2007/04/08(日) 21:17:240196179
2007/04/08(日) 21:19:08具体的に俺の「どの」発言が屁理屈なの。
誤っている箇所があるなら指摘してくれよ。
俺はそもそも屁理屈をこねるほど最近のLinuxのことを知らないから、
聞いてるだけなんだが。
0197デフォルトの名無しさん
2007/04/08(日) 21:21:54↓これ
>>189
>・ファイルシステムが非Unicodeの符号化形式を用いている場合、ファイルシステムの
> モジュールなりドライバなりが、相互変換を行うべき。そしてその層に
> それが閉じているならば、カーネルとしてはUnicodeで考えることが出来るので
> 「統一」と呼べるのでは。
> 統一されていれば、異なるファイルシステム上の名前を比較したり、ファイル
> システム間で名前をコピーすることの問題も無くなるし、
> ユーザの実行環境のロケールが何であろうと、そのロケールとの相互変換を
> どこかのレイヤが行いさえすれば、問題なくファイル名を取り扱うことが出来る。
0198179
2007/04/08(日) 21:22:24教えてくれてあんがと。
んじゃ、問題ないとか言い切ってる>>171は勇み足さんかな。
事実上そのUTF-8対応したLinuxとそうでない従来型ロケールベースでは
運用方法から何から全然変わってこない？
皆が皆UTF-8に移行してるわけじゃないでしょ？
どっちでも動くプログラムとか書くの、面倒じゃないの？
0199デフォルトの名無しさん
2007/04/08(日) 21:25:00>>>171は勇み足さんかな。
勝手にあんたの持論に巻き込むな。
0200デフォルトの名無しさん
2007/04/08(日) 21:31:09>事実上そのUTF-8対応したLinuxとそうでない従来型ロケールベースでは
>運用方法から何から全然変わってこない？
誰か俺にも分かるように翻訳してくれ。
0201179
2007/04/08(日) 21:42:51非UTF-8カーネルでユーザ毎にLC_CTYPEが異なる昔ながらのL10N環境と、
カーネルからユーザロケールまでUTF-8を前提とした環境と、
UTF-8カーネルに従来型ロケールの環境では、
ユーザコードでiconv()やwcstombs()等を用いた変換が必要な箇所が
変わってくるんでは？と思ったんだけど。
気のせいだというのならいい。
0202179
2007/04/08(日) 21:43:50えーと、俺は見ての通り頭が悪いし最近のLinuxのことは知らないので、
誤りはもっとピンポイントかつ具体的に指摘してくれると嬉しいのですが。
0203デフォルトの名無しさん
2007/04/08(日) 21:54:41> 誤りはもっとピンポイントかつ具体的に指摘してくれると嬉しいのですが。
スレ違い
0204デフォルトの名無しさん
2007/04/08(日) 23:46:39ごくろーさんｗ
0205デフォルトの名無しさん
2007/04/08(日) 23:52:150207デフォルトの名無しさん
2007/04/09(月) 00:54:49EUCベースのlinuxでwxWidgetsでUTF-8を用いたアプリを開発するにはどうすればよいかという話でしょ
１．wxWidgetsが馬鹿なので書き換える
２．アプリをEUCで作る
３．linuxをUTF-8に対応させる
さあどれだｗ
0208デフォルトの名無しさん
2007/04/09(月) 00:57:38ということはMACのカーネルは何のコードがデフォなんだ？
0209デフォルトの名無しさん
2007/04/09(月) 01:32:03もうここで続けるな。どこか他所でやってくれよ。
0210デフォルトの名無しさん
2007/04/09(月) 01:55:55$ touch ほげ
とかやった場合、要するにロケール設定によって全然別の名前のファイルが
作られるわけか？
なんかもう脳死してるっていうか、どうしようもないんじゃねぇのこれ
0211デフォルトの名無しさん
2007/04/09(月) 02:04:260212デフォルトの名無しさん
2007/04/09(月) 02:04:34ほげ：sjis
ほげ：euc-jp
ほげ：utf-8
みたいなファイル名が混在し得るんでしょ？
一つのファイルシステムに。
0213デフォルトの名無しさん
2007/04/09(月) 02:28:20readdir()やftsを使ってで読み取ったファイル名のリスト
をリストボックスか何かに表示したいです。
どうするのが正しいのでしょうか。
0214デフォルトの名無しさん
2007/04/09(月) 02:41:110215デフォルトの名無しさん
2007/04/09(月) 02:45:52kernelがEUCなら当然XシステムもEUCでフォントデータベースもEUCだからEUCのフォントインデックスじゃないと
いわゆる文字化けした状態になる
0216デフォルトの名無しさん
2007/04/09(月) 02:56:42> kernelの文字コード
> kernelがEUCなら
いみが
わかりません。
Linuxでは、文字エンコーディングを指定してカーネルを再構築するのでしょうか？
それによって、具体的にkernelの何が変わるのですか？
Unixはマルチユーザシステムですが、他のLocale設定を使いたいユーザは
どうすればよいのでしょうか？
0217デフォルトの名無しさん
2007/04/09(月) 03:06:44「やろうと思えば出来る」のと、「通常の使用でそういう事故が起きる」
のとでは、当然ながら全然違うんだが。
WindowsのコードページはUnixのロケールほど揮発性でも動的でもないし、
むしろ日本語Windowsなら実質CP932決めウチ、みたいな世界だ。
そしてAnsi版APIは、APIレベルでUTF-16への変換を試みるから、そこで
妙な名前はガードされる。
Unicode版APIは素通しだけどな。CreateFileW()にUTF-16として
正しくない並びの文字列を渡してもそのファイルを作れてしまうのは確か。
ただし、「ユーザが」「普通に」使用していてそういう事態に陥ることは
まずない。
0218デフォルトの名無しさん
2007/04/09(月) 03:55:56もうそのネタを引っ張るのは無理でしょ。流石にフォントの並びは変わらねえw
「カーネルの文字コード」という概念は個人的に破壊力抜群だったけどww
「EUC ベースの Linux」は後々まで語り継がれる名言だったなwww
釣り、なんだよね?
0219デフォルトの名無しさん
2007/04/09(月) 04:06:30おらず X Window System の提供するロケール機構を使用していた。近年になっ
て X のロケールから GNU C Library version 2 に実装されたロケールへの移
行が進んでいる。残念ながら現時点では日本語をはじめとする多バイト文字の
ロケール機構は機能していないが実装作業が進行中であり、近日中に利用可能
になるものと思われる。
0220デフォルトの名無しさん
2007/04/09(月) 04:20:33Windows だって一緒やがな。メールに添付されたファイルのファイル名が EUC-JP
だったら誰が valid なファイル名を探してくれるのでしょうね。zip に入っていたファイルの
ファイル名が UTF-16 のエンディアン違いだったらどうするのかな?
スレ違いなんで↓続きはこっちでやってね。
文字コード総合スレ part2
http://pc11.2ch.net/test/read.cgi/tech/1143375639/
>>219
残念ながらそのネタも面白くないと思われるよ。
0221デフォルトの名無しさん
2007/04/09(月) 04:49:56ちゃんと規格確認してから言ってる?
特定の実装の問題を全体に拡大解釈するなよ
0222デフォルトの名無しさん
2007/04/09(月) 05:18:41規格って、zip に入れるファイル名の文字コードの規格があるの?
特定の実装って何の実装の事?
実際には Linux だってわざわざファイル名に複数の文字コードを混在させて使おうと
する人間はいない。混在可能ってだけだし、それは Windows でも一緒。
0223デフォルトの名無しさん
2007/04/09(月) 05:35:45wxWidgetsのソースをいじるなんてのは非現実的だし
ロケールをわざわざUnicodeに変換したって既存のソフトが動かなくなるだけ
答えは１つ、デフォルトロケールにアプリを合わせて自前でコード変換するだけ
それ以外の方法はない
それ以外の方法しか考えられないやつはただの馬鹿
0224デフォルトの名無しさん
2007/04/09(月) 05:38:24で、何の解決策が必要なんだっけ?
0225デフォルトの名無しさん
2007/04/09(月) 06:06:240226デフォルトの名無しさん
2007/04/09(月) 06:51:00zip に入れるファイル名の文字コードの規格はないの?
0227デフォルトの名無しさん
2007/04/09(月) 07:26:400228デフォルトの名無しさん
2007/04/09(月) 08:08:560229デフォルトの名無しさん
2007/04/09(月) 08:11:09>wxWidgetsのソースをいじるなんてのは非現実的だし
ノンサポートのライブラリなんだから、きちんと全容を把握して
自分で手を入れられるようになっておいた方が良いぜ。
0230デフォルトの名無しさん
2007/04/09(月) 08:54:57オープンソースなんだし常識じゃないの？
カーネルのソースも、wxWidgetsのソースも動作がおかしい場合は、
読んで修正しないとねぇ。
0231デフォルトの名無しさん
2007/04/09(月) 12:06:11あのさぁ。メールの添付ファイルだのzipアーカイブの中身だのに含まれる
ファイル名をどうシステムのファイル名にマップするかってのは、
そのプロトコルなりRFCなりファイルフォーマットなりの話であって
OSの仕事ではないでしょ？
そこに不備があるのなら、それはOSでなくて、符号化形式が
self-containedではないそれらの不備ってだけだろ？
0232デフォルトの名無しさん
2007/04/09(月) 12:08:37単にシェルでファイルをとりあつかうだけのことで問題が生じることは無い。
ファイル名はUTF-16「である」のがWindowsだ。
Windowsのファイル名はコードページに依存しないし、コードページによらず
漢字や拡張ラテン文字を含むファイル名を同時に正しく扱える。
Linuxでは
$ >ほげ
とかやるとどうなるんだっけ？
0233デフォルトの名無しさん
2007/04/09(月) 12:36:110234デフォルトの名無しさん
2007/04/09(月) 13:32:490235デフォルトの名無しさん
2007/04/09(月) 13:38:35入れられるのと実際に入れるのとでは意味が違う
手を加えたらパッチが当たった時にまたそれに合わせて全部拾い出していくのか？
よっぽど暇なんですね
0236デフォルトの名無しさん
2007/04/09(月) 13:41:47わざわざ手を加えてクロスプラットフォームじゃなくならせるなんてよっぽど馬鹿なんですね
0237デフォルトの名無しさん
2007/04/09(月) 17:45:41見ればわかると思うけど、ここ能無ししかいないから
誰も答えられません。
0238デフォルトの名無しさん
2007/04/09(月) 18:26:140239デフォルトの名無しさん
2007/04/09(月) 18:34:55プログラマはそれがわからない馬鹿が多くて本当に嫌な人種だな
むしろ人間じゃねーな
0240デフォルトの名無しさん
2007/04/09(月) 20:18:26そこまで書いたら自分で気付けよw
0241デフォルトの名無しさん
2007/04/09(月) 21:49:34要するに、Windowsのファイル名はUTF-16固定だが
Unixのファイル名のエンコーディングに関しては、規約も標準も
何も無い無法地帯で、かつシステムグローバルでも何でもないLC_CTYPE
環境変数の設定でエンコーディングがころころ変わってしまい、
結果としてプログラム的にどうあるべき、という正しい判断のしようが無いから
糞なんだろ？
どこが「Windowsも同じ」なの？
Zipのようなファイル形式で困ったことになる点だけは確かに同じだな。
だが、それはOSの問題ではないし、論点ずらしだろ。
0242デフォルトの名無しさん
2007/04/09(月) 21:51:50惜しい。あと一歩真実へ踏み出してみよう。
0243デフォルトの名無しさん
2007/04/09(月) 21:56:500244デフォルトの名無しさん
2007/04/09(月) 22:02:560245デフォルトの名無しさん
2007/04/09(月) 22:10:28（符号化形式がselfcontainedでない）ってのはOSに限らない
普遍的かつ伝統的な問題なわけで、
ファイルの中のデータを扱う部分はどうしても汚い仕事にならざるを
得ないと思うのよ。典型的なのが日本語のエンコーディングの自動判別の
ようなヒューリスティック。
Unixの世界ではファイル名もこれと同じなわけだけど、Unicodeに
統一できるなら、したほうがいいに決まってるし、完璧ではないにしろ
それが可能な世界だと思うんだ。
Windowsではそうなってるわけでしょ。
0246デフォルトの名無しさん
2007/04/09(月) 22:18:35それをOSに渡す際にはUTF-16に変換するのが「正しい」ことは分かる。
どうやったらUTF-8に変換できるのか分からないならば、それは貰い方、例えば
ファイル形式やプロトコル等に問題があると言うことが出来る。
それはWindowsの問題ではない。
Unixはそれ以前の問題。それが非ASCII文字を含む場合、どう扱うのが
「正しい」のかが全く分からない。
一般解は存在せず、環境・プログラム毎の特殊解のみがあるのだろう。
0247デフォルトの名無しさん
2007/04/09(月) 23:07:08>どう扱うのが「正しい」のかが全く分からない。
どう扱うのが正しいのかを決めるのはユーザ様な世界なんだよ。
分からないんじゃなくて、勝手な決め打ちしないだけ。
全能なるユーザ様が入力なされた物を勝手に変換するなと。
"touch ほげ" の結果生成されるファイル名がロケール依存で
変化するのは UN*X 的に正しい世界。何故ならユーザ様が
ロケールを設定しているから。アプリはロケールに従ってデータを
読み出せば全く問題無い。これが UN*X 的な正しい扱い方。
入力には寛容に。
ファイル名のエンコードは一応それなりに決まっていて、HFS+
なんかは UTF-16 になっている。決まっているだけで EUC でも
書き込めるのは Windows と一緒だね。
0248デフォルトの名無しさん
2007/04/09(月) 23:26:45\0と/は特別扱いやけどな。
エンコーディング等は、kernelの知・っ・た・こ・と・で・は・な・い。
0249デフォルトの名無しさん
2007/04/09(月) 23:39:550250デフォルトの名無しさん
2007/04/09(月) 23:41:010251デフォルトの名無しさん
2007/04/09(月) 23:42:500252デフォルトの名無しさん
2007/04/09(月) 23:47:16wxWidgetsを正常に使いたかったらわざわざロケールを変更するような暇なことしたり
wxWidgetsを自分好みに作り変えたりするのは馬鹿のすることだ
デフォルトロケールのエンコードにあわせるのが正当なやり方だ
Windowsの場合はSJISとUnicodeの両者が共存出来るようなうまいしくみがあるから選べるだけ
0253デフォルトの名無しさん
2007/04/09(月) 23:50:48核心を突いたね。そう。単一の文字コードに決め打ちして正しいとか言ってるのは
俺様理論なんだよね。簡単に破綻するのにね。しかも UTF-16 だからなあ…
0254デフォルトの名無しさん
2007/04/09(月) 23:53:05一生 Windows だけ使ってる分にはそれで良いと思うよ。
Microsoft 以外が出しているおかしな OS なんて使う必要無いよ！
0255デフォルトの名無しさん
2007/04/09(月) 23:57:45UNIX系なんてそもそもバイナリ配布できるような環境にないだろｗ
どうせそのコンピュータでコンパイルして動かすのだからロケールなんて統一したほうがかえってややこしいことになる
コンパイル環境のロケールでそのまま動くように作ればいいだけ
問題になるのはスタティック文字列くらいなもん
0256デフォルトの名無しさん
2007/04/10(火) 00:02:380257デフォルトの名無しさん
2007/04/10(火) 01:07:070258デフォルトの名無しさん
2007/04/10(火) 01:10:54> "touch ほげ" の結果生成されるファイル名がロケール依存で
> 変化するのは UN*X 的に正しい世界。何故ならユーザ様が
> ロケールを設定しているから。アプリはロケールに従ってデータを
> 読み出せば全く問題無い。
touch ほげを実行したユーザが、ファイル名を読み取るユーザと同じとは
限らないのがUnixでしょ。読み取るプロセスはデーモンかもしれないし、
cronあたりから実行されているバッチかもしれない。
ftpやtelnet越しのユーザかもしれない。
実におめでたいね。
>>248
うん、それで？
結果として、単に非ASCII以外の文字を含む名前がひどく扱いにくい世界に
なったわけだよね。
時代遅れだね。
>>253
Unixの「自由」は欲しくない自由なんだよ。俺に言わせれば。
プレーンテキストどころか、ファイルの中の行毎にエンコーディングが
異なる、何がなんだか分からないファイルを考えてみればよい。論外だろ？
「自由」にしたいのなら、せめてエンコーディング方式が分かるようにしろと。
0259デフォルトの名無しさん
2007/04/10(火) 01:40:400260155
2007/04/10(火) 02:18:16しかもなぜか関係ないファイル名の話になってるし…。
荒れるからもう Unicode の話はふらないよ…。
ゴメンネ。
0261デフォルトの名無しさん
2007/04/10(火) 08:24:38それで問題無いよ。お仕着せが良いなら Windows を使っていれば良い話。
見掛け上の統一感に満足していれば良い。Windows が最高なんでしょ?
俺は、文字コードの揺らぎは常に存在するものである事を前提に、自分で
自由に制御出来る環境の方が優れていると思う。
いつだって他人の流儀を認められないのが Windows ユーザだよなあ。
ぬるい世界で満足しているなら、そこから出て来なければ良いのにね。
0262デフォルトの名無しさん
2007/04/10(火) 10:12:08＞ いつだって他人の流儀を認められないのが Windows ユーザだよなあ。
イラッとして書いたんだろうけどこういうひとくくりにする発言はやめようよ。
使ってるOSの問題じゃないからさ。
0263デフォルトの名無しさん
2007/04/10(火) 10:58:01あらゆるコミュニティから「お前は入ってこないで」と思われるタイプ。
0264デフォルトの名無しさん
2007/04/10(火) 12:29:120265デフォルトの名無しさん
2007/04/10(火) 12:43:38テクニカルな内容がほぼゼロ。本人の品性が良く分かる煽り文ですね。
> 俺は、文字コードの揺らぎは常に存在するものである事を前提に、自分で
> 自由に制御出来る環境の方が優れていると思う。
エンコーディング情報が正しく含まれるのならそれもいいだろうけど、
実際には、各行のエンコーディングがごたまぜ、何が使われているか分からない
テキストファイルも同然の状態なわけですよ。ファイル名が何でエンコードされてるか
どこにも記録されない上に、一貫性のある規約も無いのが現実。
自分の環境は自分の都合のいいように運用するからそれでおｋ？
あなたは仮にもプログラマでしょう？
趣味でLinuxいじってるだけのパソコンオタクじゃないんでしょ？
プログラマとしてコードを書くときに、自分の環境しか考えないの？
例えば「ゆらぎがあることを前提に」、あなたなら>>213のケースにどう
回答するの？
Windowsはあなたに言わせればぬるい環境で、Unixは優れてるんでしょ？
俺様環境でしか通用しない糞コードではなく、
素晴らしい回答を期待してますよ。
0266261
2007/04/10(火) 19:11:39自分の痛さを指摘されて逆上した Windows ユーザ?
まぁ、まともなレベルのものが書けたら相手してあげるよ。頑張ってね。
0267デフォルトの名無しさん
2007/04/10(火) 20:25:500268261
2007/04/10(火) 21:00:09まともなことを言ってるのに「痛くてすみません」ってな態度を取るのは
謙虚でもなんでもない。ただ間違っているだけだ。
それにしても、本当に逆上してるんだな。
負け癖のついた議論好きってこんな感じなんだよな。
0269デフォルトの名無しさん
2007/04/10(火) 21:01:120270261
2007/04/10(火) 21:07:58スレが無駄に伸びる伸びる。
■ このスレッドは過去ログ倉庫に格納されています