文字コードの種類は何故複数あるのでしょうか？

立ってないことろを見ると、ここが「文字コード総合スレ」の後継スレでつか？

立てるか。
テンプレ面倒過ぎるな。1 だけでいい？

VSネタまだやるなら分けてほしいな

結局争点はなんだったのだろう？

>>211
俺、utf8非万能説についてた人だが、俺の争点はそこだったんだが、相手の争点はそこじゃなかった気がするんだ。
一体何が争点だったのか、当事者にも分からない。

>>211
もおたが飲み仲間なのか、それとも憎いかでしょう。

それじゃ、争点を洗い出すスレが別に要る？それともここがそれ？

>>214
もういらないだろ。

文字コードのスレは何故複数あるのでしょうか？

コードもスレも統合出来ないお馬鹿さんたちwww

馬鹿が来たぞー

>>211
争点は、UTF8はUTF16やUTF32よりも優れている。
特にASCIIとの互換性に優れており、
既存のソフト・・・多くはASCIIやEUC-JPなどの
ASCII互換用として作られているソフトや
そこで使われているライブラリの互換性がよく
ほとんど修正無しに動く。
UTF16やUTF32だと修正のコストが膨大になる。
ということ。

wchar_tとロケールとファイルシステム(fopen)がごっちゃになってた気がするんだが。

全部charをwchar_tに置き換えるだけでOKとかいう
能天気やろうもいたしな。

それが全ソースコード修正＆再テストという
意味だというのを気づいていない。

その膨大さに気づいていないから、
置き換えるだけにコストがかかるというんですか？
なんてことを平気でいえてしまう。

>>219
それは争点じゃなくて、君の意見。

そしてUTF16,UTF32に拘りすぎ。
それを最初に持ち出した人(同一人物かは知らんが)は、
UTF8でも修正コストが膨大だと主張していて、UTF16は別にどうでもいい感じだった。

>>220
その通り。ファイルシステムどころかOSの仕様まで混ざってきて、複雑になるばかりの泥仕合。

>>222
お前の意見も、「君の意見」でしかないよ。

鏡見ろ

>>221
置き換えずにそのまま使うのにコストがかかるんですか？というのと同レベルの話。

>>223
俺は争点について話してない。>>219は争点について話しているはずなのに、君の意見しか入ってない。
自分の考え方に囚われるな。

>>222
文字コードを変えるのにOSの仕様まで出てくるってこと自体が、
文字コード変えるのがいかに難しいかを示しているんだけどなぁ。

この話は続ける必要はない。落ちたスレで既に話は終わっていたのだから。

999 名前：デフォルトの名無しさん [sage]： 2010/06/26(土) 22:19:28
>>972

>UTF-8にすると何もかも上手くいくよ派は、何を言いたいのかよくわからん

そんな奴いたか？　wchar_tにすれば何もかもうまくいくよ派は居たけど。

---

UTF-8にすると何もかも上手くいくよ派がいないのなら、
>>212が争点にしてたことは、元々誰も否定してなかったことだし、
>>219が争点にしてたことは、元々誰も言っていなかったこと。
wchar_tにすることが全てを解決する方法じゃないのは自明。

結論は既に出ていた。

>>219が争点にしてたことは、元々誰も言っていなかったこと。

言っていたレスはあった

じゃあここは「文字コード総合スレ」がなぜ立たないのか、立てた場合のテンプレの話のスレにする？

なにもなければ放置されるだけのスレの埋め草としてちょうどいいな。

>>228
それよりも俺はwchar_tにすれば何もかもうまくいくよ派がいたのかどうかが気になるが。

>>229
いらないからだろ。

さっさと次スレ立てろよボケ

>>231
> >>228
> それよりも俺はwchar_tにすれば何もかもうまくいくよ派がいたのかどうかが気になるが。
>
WindowsかJavaしか知らなくて、Unixのロケールを知らなければそういう発想になるかも。

>>233
意味が分からん。2chに書いてあったか書いてなかったかと、Unixのロケールがどう関係するんだ？

情報の受け手側に理解する能力がなければ書かれてても気付かないってことだろう

>>234
> >>233
> 意味が分からん。2chに書いてあったか書いてなかったかと、Unixのロケールがどう関係するんだ？
fopenのwchar_tは規格化されていない、から泥仕合が始まったのだが。

知らないことは誰だってあるけど、いいやんとか言って違いも調べず思考停止するやつは向上心もう少し持とうぜ

>>236
・fopenの話が出たことと、wchar_tにすれば何もかもうまくいくという人がいたことは関係がない
・fopenが出てくる前から、どうせ泥試合だった
・どっちにせよ、fopenでそのままutf8渡して(文字化けすらしないという意味で)うまくいくのはロケールもutf8のときのみ
と認識しているが。

> ・どっちにせよ、fopenでそのままutf8渡して(文字化けすらしないという意味で)うまくいくのはロケールもutf8のときのみ
> と認識しているが。

ロケール間違ったまま使っていることなんてしょっちゅうあるが？
日本語化しないままOS使えるだろ。
文字がちゃんと表示されないだけで

Linuxのext2,ext3でSJIS,EUC-JP,UTF-8のファイル名混在は時々ある。
LinuxでもCD-ROM,vfat,ntfs,smbfsをマウントできて、その時に文字コードを指定しないと痛い目にあう。

>>239
日本語使えるロケールでも日本語がちゃんと表示されないんだったら、それは正常に動作してるとは言わない。
たとえ内部的にはちゃんと保持できていたとしても、関係ない。

>>240
それぞれのパーティションごとに文字コードが違うのは指定すればいいけど、
同一パーティションに複数の文字コードが混在してるのはやめてほしいが……

LANG=Cでもきちんと表示できなかったらだめだって言い切っちゃうの？

>>242
それは日本語使えるロケールじゃないだろ。

つか、例えば仕様書に「ロケールはja_JP.eucjp」って明記してあっても、
utf8で書いてもなんにも問題はないからutf8で書いて、
utf8なら問題なくfopen使えるからutf8でfopen使って、
結果、表示が文字化けしていても、utf8なら問題なく読めるから問題ないって言いきるつもりなのか？

内部的にはutf8使ってもいいけど、必要に応じて変換しないとダメなんじゃないの。

>>241
表示が化けるのはあくまで端末側の問題。
fopen自体はロケール関係なく正常に動作している。
まったく同じコードでね。
UTF8がASCII互換だからちゃんと動く。

「日本語が使える」の定義が知りたい。

>>245
ロケールがEUC-JPなのにファイルをUTF8で書き込むのは正常動作って言えるのか？
日本語ロケールでUIが全部韓国語になるのと同じくらい馬鹿げてると思うぞ。

>>238

>・どっちにせよ、fopenでそのままutf8渡して(文字化けすらしないという意味で)うまくいくのはロケールもutf8のときのみ
>と認識しているが。

それはそうだけど、fopenの機能としてはちゃんと動作するよね。
wchar_tの渡した場合、fopenが正しく機能しない・・・というか渡せない　つまりfopenでは動作しない

どちらもうまく動いてないといえるけど、その動かない箇所のレイヤーが違うんだよね。
それを同じ土俵で較べ合ってもしょうがないと思うんだが。

>>248
1. 意図した通りの結果にならないのなら、どこで失敗しても五十歩百歩
2. wchar_tでもcharでも意図した通りの結果にしたければ、一旦ロケールに合わせて変換しないといけないという点で同じ
3. なんでそんなにwchar_tに拘ってるの？
　　　>>227
　　　> wchar_tにすることが全てを解決する方法じゃないのは自明。
　　　>>231
　　　> それよりも俺はwchar_tにすれば何もかもうまくいくよ派がいたのかどうかが気になるが。

> 2. wchar_tでもcharでも意図した通りの結果にしたければ、一旦ロケールに合わせて変換しないといけないという点で同じ

意図したとおりの結果にするには表示するときにデータを整えれば良いだけの話。
それはfopenには関係ない話。

>>247
> ロケールがEUC-JPなのにファイルをUTF8で書き込むのは正常動作って言えるのか？
普通にロケールがEUC-JPだけど、
UTF-8のファイルを読み書きしたり
データベースがUTF-8だったりするけど？

何を言いたいのかさっぱりわからん。

fopen(3)はNULLを返さなければ、open(2)は-1を返さなければ正常。

内部的にはutf8使う香具師なんているのか

なぜ内部にこだわる？

>>253
> 内部的にはutf8使う香具師なんているのか
Gtk+

GTKは糞

wchar_tが２バイト４バイト、エンディアンの違いを考えると、
gtkの内部utf-8はマルチプラットフォームって意味では合理的だと思うが。

>>249

>1. 意図した通りの結果にならないのなら、どこで失敗しても五十歩百歩

結果で見ればそうだけど、ここはプログラム板。
システムで採用されているロケールの文字を使う限り文字化けはしないわけでしょ。
ASCIIでもShift_JISでもUTF-8でも。
それらに対してprintfはそのまんま使える汎用性がある。

wchar_tの場合は、そこまで汎用性が持たせられない。というかそこまで汎用的に
使える標準関数が整備されていない。

その違いによる（プラットフォーム間の移植などで）発生するコストをどう捉えるかの
問題じゃないの？

ばかっ。
wchar_tとか不用意に持ち出すと今度はCSI vs UCS Normalizationで不毛な戦火の拡大が……

>>250
eucjpロケールの環境で、ファイル名も全部eucjpで保存されてるのに、どっかの誰かがお構いなしにutf8で書いて文字化けしたら、
その人のためにわざわざlsをeucjpとutf8混在しててもちゃんと使えるように書き換えろって言うの？

> 結果で見ればそうだけど、ここはプログラム板。
関係がない。どこの板でも、表示上文字化けするかしないかは重要な基準。

utf8の利点言いたい人がfopenなんて持ち出したのが間違いとしか思えない。
むしろ、俺ならそこに触れないわ。

>>251
ごめんよー、ファイル名の間違いだわ。

>>260
文字化けするが書けるだろう？

それは違う文字コードでちゃんと書けていることを意味するんだよ。

>>258
>>249の2.には異論ないのかな？
だったら、
fopenがそのまんま使えるには使えるけれども、意図した通りの結果にしたければ、一旦ロケールに合わせて変換しないといけない
が結論なわけだな。

>>262
それでいいんだったら、utf8自体いらない。
UTF16をbase64エンコーディングしたらASCIIだけで事足りるんだから。

意図した通りってなんだよ。

ファイル名が「テスト」だとしてEUC-JPで書き込んだ場合と
UTF-8で書き込んだ場合、文字コードが違うのだから
それをあらわすバイナリ列も違う。

だから違うファイル名として扱うのが意図した動作だが？

逆に言えば、fopenはバイナリ列しか見ておらず
それがEUC-JPかUTF-8なのかは気にしていない。
わざわざ文字コードを変換する機能を入れるのが意図した動作だと？

>>265
そしたら、君は何のためにファイル名に非ASCII文字を使うの？

酷い流れだ。もう結論これでいい？

表示上文字化けしないようにファイル作りたかったら、文字コード変換しろ。
表示上文字化けしてもバイナリ列が保存されていればどうでもいいなら、utf8使っても構わん。

>>266
何のためにじゃなくて、Unixでは'/'と'\0'以外パス名に制限が無いから、
それ以外何を使っても良い、でしょ。

>>268
何使ってもいいけど、そんなキーボードで入力しにくいファイル名使って何がしたいの？

>>268
じゃあ、Windowsじゃutf8でfopenは残念なことになるって思っていい？

>>270
cygwin

>>269
確かにウムラウトとか入力しずらいね。

>>270
はい。残念なことになっています。

fopenはワイド文字を扱う場合は、_wfopenを使うようにと
一時期は使えない関数とされ、今は一応使えるようになりましたが、
標準を満たしていない独自の引数をとるようになりました。

もはや互換性の無い別物です。

>>272
うん。表示に拘らないのなら、半角英数だけで事足りる。ドットくらいは使うかもしれんが。
実際、人が読む必要がないキャッシュファイルやら一時ファイルはそういう風な名付け方になってることが多い気がする。

WindowsでfopenでUNICODE文字列のファイル名って開けるのか？

http://www.game-create.com/archives/320
>
> よく使う標準関数の UNICODE 対応表を作ってみました。
>
> Windows では UNICODE 対応時と UNICODE 未対応時で
> 呼び出す関数を振り分ける必要がありますが、 _t で始まる
> 標準関数を使っておくことで、コンパイル時に自動的に関数を振り分けることができます。

あー、これは残念だｗ

TCHAR 型ってｗｗｗ
http://www.ruche-home.net/?%A5%D7%A5%ED%A5%B0%A5%E9%A5%DF%A5%F3%A5%B0%2F%BE%AE%A5%CD%A5%BF%BD%B8%2FUnicode%C2%D0%B1%FE%A5%B3%A1%BC%A5%C7%A5%A3%A5%F3%A5%B0

>>275
言葉自体が曖昧。
まず、Windowsは内部ではファイル名をutf-16で管理してる。
そして、fopenは実装依存。とりあえずVC++のfopenで、日本語ロケールでの使用を想定する。
つまりfopenはcp932(sjisのMS拡張と思ってよし)でエンコードされたchar*をとって、内部でutf-16に変換してる。

そういう意味で、全ファイル名がUNICODE文字列であって、fopenではcp932を経由してUNICODE文字列のファイル名を開ける、と言える。

あるいは、cp932入れるべきところに強引にUNICODE文字列をねじこんで、
それをWindowsが内部でcp932のつもりでutf-16に変換したもの、という意味なら。

まず、それがファイル名として妥当なものになるのか(つまり、そんなファイル作れない。ないものは読めない)というのがひとつ。
次に、UNICODE文字列とはutf8か16か32か(あるいは7か...)。
16,32ならNULを含むことになって作れないだろうなぁ。
8なら、sjisのバックスラッシュ問題にコンパイラが対応してるか、ユーザが小細工してるか。
それによって別の文字になるので調整しないといけないが、うまくすれば読める。

>>270
CP_UTF8ってのがあるよ。

>>278
なんでファイル名にUNICODE使えるのかの話で
cp932を持ち出してるの？

WindowsではfopenにASCII非互換のSJISなどを
認めてしまったため、ASCII互換のものならなんでも受け付けられる
なんて変更は出来なかった。

そのためUNICODEに対応するには、fopenではない
別の関数を使うしかない。それが_wfopen（MS独自関数）ただし
これはUNICODE(UTF-16)限定のためWin9xでは動かない。
そのために_tfopenというマクロが作られた。これを使っていると
define定数でfopen、_wfopenどちらを使うか自動的に変更できる。

これは関数だけではなく、文字列も一緒で、L”文字列"なんて書き方をすると
自動的に変換してくれるがなんか_Tマクロとか_TEXTマクロとかいろいろあって
誰か、きれいにまとめて書いてくれ。

めちゃくちゃすぎてわからん。あぁ、fopenだけでUTF-8で
もEUC-JPにもなんにでも対応できるLinux楽だよ。

>>280
>>278を読んだのにその疑問が沸いたのなら、君でも分かるように説明するのはあまりに面倒だ。

>>281
で、Linuxに関しては>>267でいいの？　あと>>274にも異論は無い？