文字コード総合スレ part5

いやあ、保証があるかの話で具体例は知らんのだけど。
>>949がありえない話なのだろうか？という疑問

「ゼロ終端されたバイト列」の説明が必要では？

>>952
それは、幽霊肯定派が、幽霊は本当にいないのだろうか？って言っているようなもんだな。

幽霊がいるというのなら、幽霊がいるという証拠をもってこい。
ありえないといいたいのなら、ありえない証拠をもってこい。

>>953
え？説明されんとわからんのか？

だから話が通じないのかｗ

>>951
fopenのプロトタイプはsjis期待してないけど、中の実装は期待してる。

Windows環境(パスの区切り文字は0x5c)を仮定するとだな。
ファイル"\x61\x5c\x61"は、ディレクトリ./a上のファイルaと解釈されるが、
ファイル"\x95\x5c\x62"は、ディレクトリ./上のファイル表aと解釈される。

つまり文字コード厄介だからおまえらナメてかかるんじゃないぞという理解でよろしいか？

>>957
うん。あるいはutf-8にすれば全てが嘘のようにうまくいく。どっちか信じたい方。

SJIS, Windowsの話は出てきたけど、UTF-8-MACは？

MACてなに

>>956
だがな。UTF8はその0x5Cを
二バイト以降に配置しないようにしているから、
何の問題も無いんだよ。

互換性問題を解決した文字コード。
fopenを何の問題も無く使える。

全てが嘘のようにうまくいくように
考えて作られたUTF8で
全てが嘘のようにうまくいくのは当たり前。

LinuxってSJISに対応していないんだな。
ASCII互換ではないかららしい。
http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?forum=10&topic=17296

逆に言えばASCII互換なら全て問題が解決する。
ということでUTF8が選ばれた。

Sambaはutf8にしても安全になったの？

>>956
それは、Windowsが特別にそういう実装になっているだけだな。
SJISはMSが作ったのだから、そういう変則的なことに対応していても不思議は無い。

だが、一般的なfopenではそんな実装をするとは決まってないし、
実際に実装されてない。ASCII互換でないものをもってきても
ASCII互換であるUTF8の例えにはならない。

というかSJISで開くべきならSJIS使いなさい、
UTF-8で開くべきならUTF-8使いなさい以上の話ではないなという。

UTF8の互換性の高さの話だろ。
なにも修正しないでも多くの関数でそのまま使える。

>>961
でも0x95が2バイト目以降に来る場合はあるでしょ？
そしたら、その次の0x5cはバックスラッシュを意図しているはずだけど、そう解釈されない場合が出てくる。

>>965
特殊実装扱いにするにはメジャーすぎるよ。
けどそういうのはどうでもよくて、もともと>>956出したのは、
sjisを要求するfopenが存在しないかのように書いた人がいたからなんだけどね。

そして、sjis程度のascii非互換性でutf8神話は崩壊するって思っていいんだね。

>>966
全くその通り。それが一番正しいし、ほとんどの人にとってそれが当たり前。

>>968
> でも0x95が2バイト目以降に来る場合はあるでしょ？
ASCII互換のUTF8は無い
そうならないように作られた。

>>969
ﾑﾁｬｲｳﾅ

ツッコミどころがおかしいんだよ！
SJIS期待してるとこにUTF-8でしかもASCII外の文字食わして何する気だってとこなんだよ！
だから>>966で解決なんだよ！

色々な論点がごっちゃになっとるなあ
プログラムの内部エンコーディングと外側でユーザが設定するロケールは
別物だろうし…

UTF-8にすると何もかも上手くいくよ派は、何を言いたいのかよくわからん
ユーザに、UTF-8ロケールにしてファイルも何もかもUTF-8にしなさい
そうでなきゃ僕は知りませんと言いたいのか？

>>972
Windowsのような特殊環境以外はfopenは文字コード関係なく'\0'で終わったchar*で問題無いって話なんじゃないの？

>>973
char*でやろうがwchar_tでやろうが別にかまわないが
エンコーディングの問題からは逃げられんだろ
一般に、localeや処理するテキストファイルの中身がUTF-8だとは限らないのだし
UTF-8だとしてもテキスト処理においてはマルチバイト処理を必要とする
Shift-JISよりはずっと性質のいいエンコーディングではあるが

>>974
fopenの話に収斂していたと思うけど、どこから遡ればいいの？

fopen()だけ取り出してエンコーディングの問題を論じるのはナンセンスじゃないのか
まあそういう話ならどうでもいいし、特に言うべきことはないが

>>971
必死だなｗ

ASCII期待しているLinuxに
UTF8を食わして問題無いんだよ。
互換性だからな。

>>974
> >>973
> char*でやろうがwchar_tでやろうが別にかまわないが
wchar_tじゃだめでしょって話で、
ここまでやって例が１つもないから作った。

#include <stdio.h>
#include <stdlib.h>

int main(int arvg, char* argc[])
{
wchar_t *w = L"aaa";
FILE *f ;
f = fopen((char *)w,"w");
fclose(f);
return 0;
}

他の文字コードを使う積極的理由がなければ、utf-8に統一していくのが今のところベストだと思うよ。
「何があってもutf-8以外は認めない」

>>978
内部コードをそのままI/Oに使うとは、アホかｗ
内部のテキストをwchar_tで持っている場合、I/Oでは変換するのが普通だし
Unix系のOSでファイル名をわざわざwchar_tで扱う意味も無い

その変換が必要ないのがUTF-8なわけだ。
これも互換性の高さゆえだな。

変換が必要が無いのは、外部エンコーディングがUTF-8である場合だけだろ
Unixではユーザが任意にlocaleを設定できるのだし
テキストには多様なエンコードが使われている（メールは今でもiso-2022-jpだ）

単にそうなればいいね、便利だね、というだけの話？
実はそこで話がずれてんの？

> Unixではユーザが任意にlocaleを設定できるのだし
だから、Unixで指定できるlocaleは
ASCII互換で無ければならないんだよな。

SJISとかUTF16とかUnixは対応していない。

>>977
いつからLinux限定の話になったんだ? euc-jpじゃダメなのか?

euc-jpもASCII互換だからね。
日本語だけしか扱えないけど。

>>983
だから、EUC-JPとかは普通に使えるし、伝統的に使われてただろ
EUC-JPとUTF-8でテキスト処理を書く場合、同じコードにはならない
EUC-JPではリードバイトと後続バイトの区別がつかないから
文字の区切りが知りたければ先頭から舐めるしかないからだ

それにファイルの中のデータとして使われるエンコーディングならもっと範囲が広い
2chは言うまでも無くShift_JISだ

>>986
うん、だけど、EUC-JPは2バイト目に0x80以下の文字を含まないから、
たいていの日本語に特に対応していないプログラムでも普通に処理できてしまうわけさ。
これが互換性の高さ。UTF8も同じだよね。

それに引き換えSJISやUTF16は2バイト目に0x80以下の文字を含むから
別途対応が必要。

おまいら>>1にマッタリって書いてんだろ
一日でどんだけ伸ばしてんだよ
シバくぞ

> たいていの日本語に特に対応していないプログラムでも普通に処理できてしまう
甘い
EUC-JPもUTF-8もバイト数＝文字幅ではないし
半角カナ絡みで問題を起こすプログラムは非常に多かったし
文字を文字として認識しなければ、文字の真ん中で文字列を区切ることも普通に
有り得る

「たいていの」は言い過ぎ
「ほとんどテキスト処理を必要としないプログラム」ぐらいが本当のところだろ

実は共通認識が多いんだけど、喧嘩する為にお互いあえて無視しているスメル
そろそろ次スレでつね

うめ

2chはどうして糞で最悪のSJISを標準エンコードにしたんだろｗ

>>989
だが文字がずれる程度でたいていは処理出来てしまう。

うめ

>>993
じゃあ、後ろ1文字消す処理はどうするの？

>993
半角ｶﾀｶﾅが含まれてると固まったり落ちたりするﾒｲﾙｸﾗｲｱﾝﾄが沢山あったんだよ

>>951

だなw

相手がsjisを期待していようがutf-8を期待していようが、fopenは
変わらず、相手の期待する文字列をchar *で渡してやればいい。

wchar_tだと、そうはいかないって話なのにね。

>>995
後ろ1バイトが消えるだけ。

>>996
それは8bitコードに対応していないだけだね。
今は普通8bitに対応しているから問題なく動くという。

>>972

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

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

>>997
じゃあ、wchar_tに全部置き換えればいいだけ。
define でcharをwchar_tにすれば
解決する話だ。

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。