エンコーディングの問題: 明らかに UTF-8 ですが、応答が gbk と表示されるのはなぜですか?

http://parttime.wengege.com/h/login.html

応答エンコーディングは実際には: gbk,utf-8 です

HTTP/1.1 200 OK
サーバー: nginx/1.4.1
日付: 月09 Jun 2014 15:28:28 GMT
Content-Type: text/html; charset=gbk,utf-8
Content-Length: 1843
Last-Modified: Mon, 09 Jun 2014 15:28:16 GMT
接続: keep -alive
ETag: "5395d290-733"
Accept-Ranges: bytes

/login.html のコンテンツは editplus で開かれ、utf-8 として表示され、何度か utf-8 として保存されています。

ブラウザはどこでそれが gbk であると判断しますか?それでコードが文字化けしているのでしょうか？

ディスカッションへの返信 (解決策)

Content-Type: text/html; charset=gbk,utf-8? ? ?
このような文字セット宣言はありますか?
ブラウザはどのようにしてどれが gbk でどれが utf-8 であるかを知るのでしょうか?

メモ帳や emeditor などの別のエディタを試してください

Content-Type: text/html? ? ?
このような文字セット宣言はありますか?
ブラウザはどのようにしてどれが gbk でどれが utf-8 であるかを知るのでしょうか?

これがまさに私が聞きたい質問です。
上記はステートメントではなく、http 応答です。

メモ帳やemeditorなどの別のエディタを試してください

いくつかのエディタを変更して保存しました。 GBKのキャラクターが入っています。つまり、utf-8 は gbk として認識されます。おかしいですね。
私は 10 年間コーディングを勉強しています。コーディングに問題があったことはありません。
上記の問題は Linux でのみ発生し、Windows では再現できません。

さらに、別のテストディレクトリに変更しました。内容はそのまま表示されます。

ステータス コードを除いて、http ヘッダーの内容はすべて宣言です
header('Content-type: text/html;charset=gbk,utf-8'); の場合、
HTTP は Content-Type を持ちます: text/html;charset=gbk,utf-8

php.iniのdefault_charset
httpd.confのdefault_charset
など全て設定可能

サーバーのデフォルト設定だと思います

全く分かりませんどこに問題があるのか​​調べてみましょう

同じサーバー上に正常に表示できるコードがない場合は、設定に問題があるはずです。
正常に表示できるコードがある場合は、正常なコードをこのファイルと同じ内容に変更してください。 異常であれば文章を変更すると問題が発生します
これに変更したテキストであればまだ表示可能です。通常、2 つのファイルを比較するには 16 進ビューアを使用します

これはおそらくサーバーのデフォルト設定です

何が問題なのか本当にわかりません

同じファイル上で正常に表示できるコードがない場合サーバーの場合、設定に問題があるはずです。
正常に表示できるコードがある場合は、正常なコードをこのファイルと同じ内容に変更してください。 異常であれば文章を変更すると問題が発生します
これに変更したテキストであればまだ表示可能です。通常、2 つのファイルを比較するには 16 進ビューアを使用します

私のサーバー上の他のコードには問題ありません。
さらに、
このファイルをディレクトリに移動したところ、正常にアクセスできるようになりました。 。 。 。
http://parttime.wengege.com/h/test.html

上記のリンクもChrome下では文字化けします（JSを導入すると文字化け、不思議なことに他の部分も文字化けします）。 IE ではまったく正常です。

nginx の設定に問題がありますか? Apacheを変更してテストしますか？

結論は自明です

ログインテンプレートファイルはutf-8でエンコードされていますが、phpプログラムのヘッダーステートメントまたはサーバーのデフォルト設定によって出力されるレスポンスヘッダーはgbk、utf-8、およびwebkitですとChromeでは文字化けコードが表示されますが、IEは正常です

テストテンプレートファイル自体はgb2312でエンコードされており、レスポンスヘッダーはgbk、utf-8のままで、9階の状況が表示されます

そのWebkitとChrome はエンコーディングを認識し、応答ヘッダーは DOM 内のヘッダー ステートメントより優先されます。IE はその逆です
ホストのサーバー上の js ファイルの応答ヘッダーの文字セットは gbk、utf-8 であることがわかりました。サーバーのデフォルト出力に問題がある可能性があります

上記の返信を読んで、私は???を思いつきました。

ディレクトリに .htaccess が設定されていない場合、デフォルトの文字セットが .htaccess に設定されている場合はどうなりますか?

結論は自明です

はい、GBK はどこから来たのでしょうか?重要なのは、GBK がどこから来たのかということです。モデレータ。ハニー。方向が間違っています。また、GBK はどこから来たのか、とも考えています。
GBK で問題が発生することはわかっています。 GBK は結果であり、始まりではありません。

上記の返信を読んで、一つのことが頭に浮かびました。
ディレクトリに .htaccess が設定されていない場合、デフォルトの文字セットが .htaccess に設定されている場合はどうなりますか?

昨日確認しましたが、何も見つかりませんでした。 htaccess ファイルにエンコードの問題があります。

ログインテンプレートファイルはutf-8でエンコードされていますが、PHPプログラムのヘッダーステートメントまたはサーバーのデフォルト設定によって出力される応答ヘッダーはgbk、utf-8であるため、Webkitとchromeの文字化けが発生しますが、IEは正常です
テストテンプレートファイル自体は gb2312 エンコーディング、レスポンスヘッダーは gbk、utf-8 のままで、9 階の状況が表示されます

おそらく webkit と chrome がエンコーディングを認識しており、レスポンスヘッダーが優先されると思われますDOM の header ステートメント、IE はその逆です
投稿者のサーバーでそれを見ました。js ファイルの応答ヘッダーの文字セットはすべて gbk、utf-8 です。サーバーのデフォルトの出力に問題があるはずです

どこにもヘッダーの問題は見つかりませんでした。同時にログインテンプレートはありません。これはテンプレートではなく、単なる通常の HTML です。ご清聴ありがとうございました。

.htaccess にはありません
AddDefaultCharset gbk
AddDefaultCharset utf-8
結果は Content-Type: text/html; charset=utf-8 です
つまり、最後の命令のみが有効です

ただし、
AddDefaultCharset gbk の場合、 ut f -8
次に、Content-Type: text/html; charset=gbk,utf-8

したがって、問題は再び戻りますが、文字セット宣言は組み込みではなく設定されています




上記に応じて、何かが思い浮かびます。

ディレクトリに .htaccess が設定されていない場合、デフォルトの文字セットが .htaccess に設定されている場合はどうなりますか?

ここで問題は、すべてのファイル (css、php、js) がチェックされ、utf-8 でエンコードされていることが確認されたことです。 いくつかの問題があります:

。 httpレスポンスは実際にはgbk、utf-8なので文字化けしてしまいます。問題は、gbk がどこから来たのかということです。これら 3 つの文字はどこから来たのでしょうか?
3 つの文字 GBK をサイト全体で検索しました。何もない！ ！ ！ M 2. HTML はたまに成功しても、JS の導入は依然として文字化けします。コーディングの導入を UTF-8 として指定します。

3. W3C の腐った Web サイトのチェックを通じて、「成功した識別」コーディングはまだ「GBK」です。その後、W3C の Web サイトは何度もクラッシュしました。 ， 奇は本当に素晴らしいです。検査の結果、問題があるとのことです。すべての文字を再入力しましたが、同じままです。ファイルのディレクトリを変更した後でも、thinkphp3.1 のログインは正常に行われます。ただし、この HTML を thinkphp3.2 で実行すると異常です。重要なのは、HTML と thinkphp は互いに何の関係もないということですか?

js ファイルには Content-Type: text/html; charset=gbk,utf-8 もあります

明らかに、これは Web サーバー設定ファイルの中にあります

サーバー内で gbk という単語を検索すると見つかるはずです設定ファイル

本当に見つけたくない場合は、.htaccess に
AddDefaultCharset utf-8 を追加してください

これにより、元の設定が上書きされます

🎜 保存するときに、no bom を選択して、もう一度お試しください。 HTML に bom ヘッダーがあることがわかりました 🎜 🎜 新しい発見: 実際にブラウザのエンコード メニューがグレー表示になるギミックがあるのでしょうか。 🎜 🎜 🎜 ヘッダーの問題はどこにも見つかりませんでした。同時にログインテンプレートはありません。これはテンプレートではなく、単なる通常の HTML です。ご清聴ありがとうございました。 🎜 🎜 HTMLとテンプレートも同様です〜 IEが常に安定していて安定していること（応答ヘッダーとDOMエンコード宣言の優先順位が異なる）と、テスト本体が乱雑ではないこと（おそらく）の2つの理由が考えられます。 test.html ファイルは gbk でエンコードされており、login.html は utf-8 です) さらに、別の test ディレクトリに変更すると、コンテンツはそのまま表示されます。ファイルが gbk エンコードになったのはそれが原因でしょうか?レスポンスヘッダーに gbk が含まれる最も重要な理由については、私の知識の範囲を超えていますので、注意して学習してください 🎜 🎜 問題の原因は、nginx がこれを設定するときに charset gbk、utf-8 を使用することが判明しました。 Webサイト。 gbkを削除すれば大丈夫です。これでコード化けは解消されました。 🎜

この問題の原因は、この Web サイトを構成するときに nginx が文字セット gbk,utf-8 を使用したことが判明しました。 gbkを削除すれば大丈夫です。これでコード化けは解消されました。

最初から10階で構成の問題が提起されていましたが、存在感の薄さは無視されました

さらに、別のテストディレクトリに変更しました。内容はそのまま表示されます。

が批判されました。

現在のバージョンと番号はすべて古いです。デフォルトの文字セットは gbk、utf8 であるためです。

あなたが言及した nginx 設定は大きすぎます。私が言及している構成は、この仮想ホストの構成です。このnginxには多くのWebサイトがあり、他に問題はありません。

問題の原因は、この Web サイトを構成するときに nginx が文字セット gbk,utf-8 を使用したことが判明しました。 gbkを削除すれば大丈夫です。これでコード化けは解消されました。

最初から10階で設定の問題が提起されていましたが、存在感の薄さは無視されました

さらに、他のテストディレクトリに変更しました。内容はそのまま表示されます。

が批判されました。

現在のバージョンと番号はすべて古いです。デフォルトの文字セットは gbk, utf8 なので、

ディレクトリを変更した後、BOM ヘッダーを追加する方法がわかりませんが、これで OK です。

親愛なる、あなたが言及した nginx 構成は大きすぎます。私が言及している構成は、この仮想ホストの構成です。このnginxには多くのWebサイトがあり、他に問題はありません。

他のWebサイトは大丈夫です。 12階で、jsファイルのレスポンスヘッダーがgbk、utf-8で、ターゲットを即座にロックできると述べました〜
あなたは長い間phpスクリプトとBOMを勉強してきました。初心者が正しく理解できるのは珍しいです