アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell
1.xのWin32 Binary (スコア:0)
1.3.36もなかった様に思いますし……
2.xに移行せず、自前でコンパイルもしない人は、1.3.35を使い続ける事になって、危険な様な……
#つか、2.x(Win32)でURLエンコードされてないCookieが化けるBug、修正されないかなぁ……
Re:1.xのWin32 Binary (スコア:0)
使っちゃいけない文字をエンコードしないで使ったら化けても文句は言えないと思うけど。バグってるのは apache じゃなくてそういう cookie を吐いてるスクリプトの方でしょ。
Re:1.xのWin32 Binary (スコア:0)
エンコードしないCGI、大量に出回ってるだろうし。全部直せってのはどうかと。
#サーバOSを変更しろ、Win32なら素直にMS-IIS使えって意見もあるだろうけど(汗)
#つか、Unix版でも、Apache2.0.xの初期の頃は化けてた気がするし、直したのならBugと認識したって事でしょう?#Win32だけ放置なのは、なんだかなぁ。RFC違反って事で、全プラットフォーム問答無用で化けて同じ動作なら、納得も行くんだがねぇ。
Re:1.xのWin32 Binary (スコア:4, 参考になる)
出回っていても2.0系が出てから結構立つんだし、まだ直していないのが問題なんじゃないの?
と言うか、出回っていたって、メンテが終わった奴だろ。メンテが続けられているのならばとっくに直っているはず。
俺は最近は見たこと無いな、日本語クッキーは。
とほほのCookie入門でも
>日本語を使用する際にはそれぞれ、%3B、%2C、%20のようにエンコードして記述しなくてはなりません。
http://pzxa85.hp.infoseek.co.jp/www/wwwcook.htm
と%エンコード必須みたいだぞ。
ネットスケープのクッ
Re:1.xのWin32 Binary (スコア:1, すばらしい洞察)
何処からそう言う話が出て来たんでしょうか? AddDefaultCharsetをoff以外にすると、他の文字コードなベージが提供し辛くなって、不便なだけですし、関係ありません。
#もし、CGI側とWebブラウザ側で異なる文字コードを喋っているのなら、其れはApacheの責任では無いでしょう?
>2.0.55で問題無しみたい。今59だろ。「Win32だけ放置」って試していないんじゃないの?
いえ、2.2.2(Win32)で再現する所までは確認しています。問題は無くなっていません。
どうやら、Webブラウザに格納されたCoo
Re:1.xのWin32 Binary (スコア:1)
>何処からそう言う話が出て来たんでしょうか? AddDefaultCharsetをoff以外にすると、他の文字コードなベージが提供し辛くなって、不便なだけですし、関係ありません。
>#もし、CGI側とWebブラウザ側で異なる文字コードを喋っているのなら、其れはApacheの責任では無いでしょう?
あのー、何処が原因で文字化けするのか分からないのですよね?あれが原因で、ソースのここをこう修正すれば直るとか詳しく認識しているの?
「みたく」とは、「この様にしろ」と言う意味で無い事は解っていますか?
#987147は
>まぁ、CGI側が正しくないのは確かなんだが、Apache1.3.xと挙動が異なるってのと、Unix版では化けないって事で、Apacheに問題が無いとも云えん様な。
>エンコードしないCGI、大量に出回ってるだろうし。全部直せってのはどうかと。
と言っていたから、「CGIを弄りたくない」と言う前提があるので、使っている文字コードをCGIで指定していなければ、指定した方が文字化けし難いと判断して、チェック箇所として提案したら、「不便なだけですし、関係ありません」って何それ。
全然的外れのアドバイスで役に立たない邪魔な存在の様な表現ですよね。
原因が解っているのならば、具体的に述べたり、開発している人達に連絡するなり、自分で修正するなりすれば良いんじゃないの?
「Win32だけ放置」と、「放置されている」と言う認識なんでしょ?
何が引き金になっているか解らないからこそ、Charsetとかの話をしたりするのは当然の流れでは?
CGIを弄らないでCharsetをするには、俺のアドバイスは結構良いと思うけど。
>>2.0.55で問題無しみたい。今59だろ。「Win32だけ放置」って試していないんじゃないの?
>いえ、2.2.2(Win32)で再現する所までは確認しています。問題は無くなっていません。
>どうやら、Webブラウザに格納されたCookieを見て、化けていないと判断されている様ですが、残念ながら問題は其処ではありません。
IEとapacheの間に串を挟んで、串を通るデータを見てます。
と言うか、HTTPのリクエストとレスポンスのログにしか見えないはずなんだけど....
>Cookieが化けるのは、Apacheから見て送信時ではなく受信の時です。
それを言わないで、Charsetは関係無いとか言い出しているのは理解出来ないよ。
>#! ruby -Ks
>STDOUT.binmode
>print "Content-type: text/html\r\n"
>print "Set-Cookie: 日本語=文字化け\r\n"
>print "\r\n"
>ENV.each do |key, value|
> print key, " => ", value, "
\r\n"
>end
とやったら、
>HTTP_COOKIE => ?u?{?e=?¶???≫? ̄
と化けてるな。
>#! ruby -Ku
と
>print "Content-type: text/html; charset=UTF-8\r\n"
を変えたら、
>HTTP_COOKIE => ?u?{?e=?????P; a?\a???a?=a??a-?a??a??
エディタで文字コード変えて読んでも駄目だな。
>#! ruby -Ke
と
>print "Content-type: text/html; charset=euc-jp\r\n"
を変えたら、
>HTTP_COOKIE => ?u?{?e=?・゚??≪= ̄; a?\a?&ca?=a??a-?a??a??
と、1個足りない.....
>#何やら「(スコア:4, 参考になる)」なんてモデレートがなされていますが、私からしますと「(スコア:0, 見識が足りない)」と云った感じです。(スコア:-1と迄は云いませんが……)
>
>Webサーバは、クライアントから受信したCookieデータを、サイズオーバーでない限りは、素直に(バイナリ扱いで)其のまんまCGI等に渡してくれるのが良いと私は思うんですけどねぇ。
>其処から先の動作は、CGIとクライアントの責任だと思うので。
アスキー以外を使うのがおかしいのだしさ。そして、「apacheがCGIに渡すところ」なんて一言も言われてなかったのにこの言われようかよ。
あと、安定性を考えるとやはり%エンコードした方が良いよ。
「他の文字コードなベージが提供し辛くなって」と言う考えがある以上、文字コードの統一が図れていないのだろ。
クッキーはサブドメインや下位ディレクトリーにも流れるし、HTTPリクエストに普通文字コード情報は無いし、ブラウザ側の実装で違ったりするかも知れないだろ。
HTTPヘッダーは環境変数に入れる為に、複数行に別れている奴や同じ名前のヘッダーは加工して入れたりするのだろ?