文字コードの種類は何故複数あるのでしょうか？ (395ﾚｽ)
上下前次1-新
233(2): 2010/07/03(土)15:13 AAS
>>231
> >>228
> それよりも俺はwchar_tにすれば何もかもうまくいくよ派がいたのかどうかが気になるが。
>
WindowsかJavaしか知らなくて、Unixのロケールを知らなければそういう発想になるかも。
234(1): 2010/07/03(土)15:21 AAS
>>233
意味が分からん。2chに書いてあったか書いてなかったかと、Unixのロケールがどう関係するんだ？
235: 2010/07/03(土)15:24 AAS
情報の受け手側に理解する能力がなければ書かれてても気付かないってことだろう
236(1): 2010/07/03(土)15:26 AAS
>>234
> >>233
> 意味が分からん。2chに書いてあったか書いてなかったかと、Unixのロケールがどう関係するんだ？
fopenのwchar_tは規格化されていない、から泥仕合が始まったのだが。
237: 2010/07/03(土)15:28 AAS
知らないことは誰だってあるけど、いいやんとか言って違いも調べず思考停止するやつは向上心もう少し持とうぜ
238(1): 2010/07/03(土)15:43 AAS
>>236
・fopenの話が出たことと、wchar_tにすれば何もかもうまくいくという人がいたことは関係がない
・fopenが出てくる前から、どうせ泥試合だった
・どっちにせよ、fopenでそのままutf8渡して(文字化けすらしないという意味で)うまくいくのはロケールもutf8のときのみ
と認識しているが。
239(1): 2010/07/03(土)16:01 AAS
> ・どっちにせよ、fopenでそのままutf8渡して(文字化けすらしないという意味で)うまくいくのはロケールもutf8のときのみ
> と認識しているが。
ロケール間違ったまま使っていることなんてしょっちゅうあるが？
日本語化しないままOS使えるだろ。
文字がちゃんと表示されないだけで
240(1): 2010/07/03(土)17:02 AAS
Linuxのext2,ext3でSJIS,EUC-JP,UTF-8のファイル名混在は時々ある。
LinuxでもCD-ROM,vfat,ntfs,smbfsをマウントできて、その時に文字コードを指定しないと痛い目にあう。
241(1): 2010/07/03(土)17:47 AAS
>>239
日本語使えるロケールでも日本語がちゃんと表示されないんだったら、それは正常に動作してるとは言わない。
たとえ内部的にはちゃんと保持できていたとしても、関係ない。
>>240
それぞれのパーティションごとに文字コードが違うのは指定すればいいけど、
同一パーティションに複数の文字コードが混在してるのはやめてほしいが……
242(1): 2010/07/03(土)18:27 AAS
LANG=Cでもきちんと表示できなかったらだめだって言い切っちゃうの？
243: 2010/07/03(土)19:37 AAS
>>242
それは日本語使えるロケールじゃないだろ。
244: 2010/07/03(土)19:41 AAS
つか、例えば仕様書に「ロケールはja_JP.eucjp」って明記してあっても、
utf8で書いてもなんにも問題はないからutf8で書いて、
utf8なら問題なくfopen使えるからutf8でfopen使って、
結果、表示が文字化けしていても、utf8なら問題なく読めるから問題ないって言いきるつもりなのか？
内部的にはutf8使ってもいいけど、必要に応じて変換しないとダメなんじゃないの。
245(1): 2010/07/03(土)19:44 AAS
>>241
表示が化けるのはあくまで端末側の問題。
fopen自体はロケール関係なく正常に動作している。
まったく同じコードでね。
UTF8がASCII互換だからちゃんと動く。
246: 2010/07/03(土)19:52 AAS
「日本語が使える」の定義が知りたい。
247(2): 2010/07/03(土)20:34 AAS
>>245
ロケールがEUC-JPなのにファイルをUTF8で書き込むのは正常動作って言えるのか？
日本語ロケールでUIが全部韓国語になるのと同じくらい馬鹿げてると思うぞ。
248(1): 2010/07/03(土)20:38 AAS
>>238
>・どっちにせよ、fopenでそのままutf8渡して(文字化けすらしないという意味で)うまくいくのはロケールもutf8のときのみ
>と認識しているが。
それはそうだけど、fopenの機能としてはちゃんと動作するよね。
wchar_tの渡した場合、fopenが正しく機能しない・・・というか渡せない つまりfopenでは動作しない
どちらもうまく動いてないといえるけど、その動かない箇所のレイヤーが違うんだよね。
それを同じ土俵で較べ合ってもしょうがないと思うんだが。
249(2): 2010/07/03(土)20:52 AA×
>>248>>227>>231
250(1): 2010/07/03(土)20:59 AAS
> 2. wchar_tでもcharでも意図した通りの結果にしたければ、一旦ロケールに合わせて変換しないといけないという点で同じ
意図したとおりの結果にするには表示するときにデータを整えれば良いだけの話。
それはfopenには関係ない話。
251(1): 2010/07/03(土)21:01 AAS
>>247
> ロケールがEUC-JPなのにファイルをUTF8で書き込むのは正常動作って言えるのか？
普通にロケールがEUC-JPだけど、
UTF-8のファイルを読み書きしたり
データベースがUTF-8だったりするけど？
何を言いたいのかさっぱりわからん。
252: 2010/07/03(土)21:03 AAS
fopen(3)はNULLを返さなければ、open(2)は-1を返さなければ正常。
253(1): 2010/07/03(土)21:26 AAS
内部的にはutf8使う香具師なんているのか
254: 2010/07/03(土)21:28 AAS
なぜ内部にこだわる？
255: 2010/07/03(土)21:29 AAS
>>253
> 内部的にはutf8使う香具師なんているのか
Gtk+
256: 2010/07/03(土)21:36 AAS
GTKは糞
257: 2010/07/03(土)21:47 AAS
wchar_tが２バイト４バイト、エンディアンの違いを考えると、
gtkの内部utf-8はマルチプラットフォームって意味では合理的だと思うが。
258(1): 2010/07/03(土)22:45 AAS
>>249
>1. 意図した通りの結果にならないのなら、どこで失敗しても五十歩百歩
結果で見ればそうだけど、ここはプログラム板。
システムで採用されているロケールの文字を使う限り文字化けはしないわけでしょ。
ASCIIでもShift_JISでもUTF-8でも。
それらに対してprintfはそのまんま使える汎用性がある。
wchar_tの場合は、そこまで汎用性が持たせられない。というかそこまで汎用的に
使える標準関数が整備されていない。
その違いによる（プラットフォーム間の移植などで）発生するコストをどう捉えるかの
問題じゃないの？
259: 2010/07/03(土)23:17 AAS
ばかっ。
wchar_tとか不用意に持ち出すと今度はCSI vs UCS Normalizationで不毛な戦火の拡大が……
260(1): 2010/07/03(土)23:33 AAS
>>250
eucjpロケールの環境で、ファイル名も全部eucjpで保存されてるのに、どっかの誰かがお構いなしにutf8で書いて文字化けしたら、
その人のためにわざわざlsをeucjpとutf8混在しててもちゃんと使えるように書き換えろって言うの？
> 結果で見ればそうだけど、ここはプログラム板。
関係がない。どこの板でも、表示上文字化けするかしないかは重要な基準。
261: 247 2010/07/03(土)23:36 AAS
utf8の利点言いたい人がfopenなんて持ち出したのが間違いとしか思えない。
むしろ、俺ならそこに触れないわ。
>>251
ごめんよー、ファイル名の間違いだわ。
262(1): 2010/07/03(土)23:37 AAS
>>260
文字化けするが書けるだろう？
それは違う文字コードでちゃんと書けていることを意味するんだよ。
上下前次1-新書関写板覧索設栞歴
あと 133 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.018s