それがこの投稿です。 http://bbs.csdn.net/topics/390807783?page=1#post-397542169
この投稿には詳細な説明があります。この問題を解いた人は240点を獲得できます。このような小さな問題が 2 ～ 3 日間私を悩ませています。http の下部からデータ パケットを調べましたが、まだ解決できません。
----------------------------------------------- - ----------------------------------------
数え切れないほどの専門家が理解できないit out (garbled code) ) エンコードの問題: Linux 上の Chrome でアクセスした場合にのみコードが文字化けします。それ以外はすべて正常です。
Windows 上のどのブラウザでも問題ありません。
Linux 環境下。クロムアクセスのみ文字化けして表示されます。 (もちろん、Chromeのコードを手動で修正すれば正常に表示できます。)
----------------------------------
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 であると判断しますか?それでコードが文字化けしているのでしょうか？
-----------------------
2 階の changjay からの返信を引用:
メモ帳や emeditor などの別のエディタを試してください
変更しました。いくつかのエディタを作成して保存しました。 w3c は、GBK 文字が含まれているかどうかをチェックします。つまり、utf-8 は gbk として認識されます。おかしいですね。何度も変換して保存しました。
http://parttime.wengege.com/h/test.html
上記の接続は、Chrome でも文字化けします (JS を導入すると文字化け、不思議なことに他の部分も文字化けします)。 IE ではまったく正常です。
----------------------------------------------- - ---
ここで問題は、すべてのファイル (css、php、js) がチェックされ、utf-8 でエンコードされていると判断されたことです。
解決できない問題がいくつかあります:
1. 通常の HTML は utf-8 でエンコードされます。 httpレスポンスは実際にはgbk、utf-8なので文字化けしてしまいます。問題は、gbk がどこから来たのかということです。これら 3 つの文字はどこから来たのでしょうか?
3 つの文字 GBK をサイト全体で検索しました。何もない！ ！ ！
2. HTML は時々成功しても、JS は依然として文字化けします。インポートされたエンコーディングを utf-8 として指定します。
3. w3c の不正な Web サイトのチェックを通じて、「成功した識別」コードは依然として「gbk」のままです。その後、w3c の Web サイトは何度もクラッシュしました。
すごいですね、チェックの結果、ある回線に問題があることが分かりました。すべての文字を再入力しましたが、同じままです。ファイルのディレクトリを変更した後でも、thinkphp3.1 のログインは正常に行われます。ただし、この HTML を thinkphp3.2 で実行すると異常です。重要なのは、HTML と thinkphp は互いに何の関係もないということです。
おそらく、Apache の設定に問題があります。Apache の設定に文字セット設定があることを思い出してください
またまたですか?
Windows 上のどのブラウザでも問題ありません。 これは恣意的すぎます！
これは XP 360 速度ブラウザのスクリーンショットです
IE に問題がないことは否定しません
これは、IE には強力な文字セット認識機能があり、Content-Type: text の影響を完全に無視できるためです/html; charset
これが Netscape が崩壊した理由の 1 つでした。
そして、Netscape 崩壊時にリリースされたブラウザ コード (10 MB 以上の C プログラム) に基づいて構築されたさまざまなブラウザは、Microsoft の特許のため、この問題を解決できません
もちろん、これは議論の順序からの余談です
charset=gbk がある場所を見つける必要があります
ツール ソフトウェアをあまり信頼しないでください。手動で 1 行ずつ検索するのが最善です。結局のところ、構成ファイルはほんのわずかしかありません
しかし、この状況を引き起こしたいくつかのプラグインをインストールした可能性は排除されません
この問題は私のローカルマシンでも完全に再現されます
login.html が保存されている限りas utf-8 エンコーディングに BOM がない場合、文字化けするはずです。保存時に BOM は保持され、側面のコード化けはありません。 UltraEdit で何度もテストを繰り返しましたが、結果は同じです。
重要なのは、これまでのプロジェクトでこのようなことが起こったかどうかです。そうでない場合は、コードに問題があります。ある場合は、サーバーの問題、オペレーティング システムの問題、または単にコード入力のエラーである可能性があります (元の SQL ステートメントに間違った文字があり、私はそれを見つけるのに苦労しました)。小さな間違いを犯すことはできないと感じたので、実際にはまだコミットしています。
私の提案は、主にコードか動作環境かを確認することです。
この問題は私のマシンで完全に再現されます
login.html が BOM なしの utf-8 エンコーディングとして保存されている限り、文字化けします。保存時に BOM は保持され、側面のコード化けはありません。 UltraEdit で何度もテストを繰り返しましたが、結果は同じです。
nginx.conf 設定ファイルを確認してください? ＧＢＫってあるの？
またここですか？
Windows 上のどのブラウザでも問題ありません。 これは恣意的すぎます！
これはXP 360スピードブラウザのスクリーンショットです
この問題は私のローカルマシンでも完全に再現されます
login.html が BOM なしの utf-8 エンコードで保存されている限り、文字化けします。保存時に BOM は保持され、側面のコード化けはありません。 UltraEdit で何度もテストを繰り返しましたが、結果は同じです。
他の人の判断を妨げないでください
うわー
明らかに
3c21444f435459504520 には BOM ヘッダーがありません
efbbbf3c21444f435459 には BOM ヘッダーがあります
ブラウザの場合、BOM ヘッダーはせいぜい表示に影響しますstyle 、文字化けを起こさない
$url = 'http://parttime.wengege.com/Public/js/search.js';
$s = file_get_contents($url, false, null, 0, 10);
echo bin2hex($s); ); / /2f2fe6a0b9e68daee7b1
/Public/js/search.js には BOM ヘッダーがありません
ブラウザの場合、BOM ヘッダーは文字化けを引き起こすことなく表示スタイルに影響します
言うまでもなく、サーバーは gbk を返します。 utf8 などのエンコード用の BOM ヘッダーがない場合、gbk または utf8 として表示する必要がありますか?明らかにgbkに従って表示されます。
またここですか？
Windows 上のどのブラウザでも問題ありません。 これは恣意的すぎます！
これは XP 360 速度ブラウザのスクリーンショットです
IE に問題がないことは否定しません
これは、IE には強力な文字セット認識機能があり、Content-Type: text の影響を完全に無視できるためです/html; charset
これが Netscape が崩壊した理由の 1 つでした。
そして、Netscape 崩壊時にリリースされたブラウザ コード (10 MB 以上の C プログラム) に基づいて構築されたさまざまなブラウザは、Microsoft の特許のため、この問題を解決できません
もちろん、これは議論の順序からの余談です
charset=gbk がある場所を見つける必要があります
ツール ソフトウェアをあまり信頼しないでください。手動で 1 行ずつ検索するのが最善です。結局のところ、設定ファイルはほんのわずかしかありません
しかし、インストールしたプラグインがこの状況を引き起こしたという可能性は排除されません
またここですか？
Windows 上のどのブラウザでも問題ありません。
これは恣意的すぎます！
これはXP 360スピードブラウザのスクリーンショットです
xuが大きいので、投稿者はWindows上のサーバーを参照していると思います サーバーを変更しても大丈夫なので、おそらくnginxの構成またはモジュールが原因です。邪魔ですよね？
同じ ngnix 設定では、他のプロジェクトは問題なく、コードはほぼ同じです。
header("Content-Type: text/html; charset=gbk,utf8");
はレスポンスのヘッダーです
get_headers(url)
取得した Content-Type: text/html;はサーバー応答です
いつリクエストを言いましたか?
対応するヘッダーを設定していませんか?それを設定ファイルに入れて自動的に送信します
私はまったく混乱していませんが、あなたは忙しすぎます。
サーバーを変更しても正常になります。これは、問題のサーバーの構成に問題があることを意味します。
重要なのは、これまでのプロジェクトでこのようなことが起こったかどうかです。そうでない場合は、コードに問題があります。ある場合は、サーバーの問題、オペレーティング システムの問題、または単にコード入力のエラーである可能性があります (元の SQL ステートメントに間違った文字があり、私はそれを見つけるのに苦労しました)。実際、私はまだそれを犯していました。
私の提案は、主にコードか動作環境かを確認することです。
この問題は私のマシンで完全に再現されます
login.html が BOM なしの utf-8 エンコードで保存されている限り、文字化けします。保存時に BOM は保持され、側面のコード化けはありません。 UltraEdit で何度もテストを繰り返しましたが、結果は同じです。
Content-Type: text/html; charset= gbk,utf8
この gbk が本当の理由ですが、そのソースを見つけたくありません
xuzuning モデレーターの正解!
問題の原因は、この Web サイトを構成するときに nginx が文字セット gbk,utf-8 を使用したことが判明しました。 gbkを削除すれば大丈夫です。これでコード化けは解消されました。
thinkphp Web サイトのネチズンが私と同じ問題に遭遇しました。問題を解決するには、サーバー上の構成ファイルを確認するよう通知します。
header("Content-Type: text/html; charset=gbk,utf8");
はレスポンスのヘッダーです
get_headers(url)
取得した Content-Type: text/html; utf8
サーバーの応答です
いつリクエストを言いましたか?
対応するヘッダーを設定していませんか?それを設定ファイルに入れて自動的に送信します
私はまったく混乱していませんが、あなたは忙しすぎます。
サーバーを変更しても正常になります。これは、問題のサーバーの構成に問題があることを意味します。
ngix charset が設定されている場合、またはフォルダーに配置されている場合はどうなりますか? ??folder?? も同じ ?charset を使用します。そのため、以前はフロントフォルダーに .htaccess ファイルがあると思っていました。このため、デフォルトの文字セット設定が見つかりませんでした。
ファイルは確かに UTF8 で保存されているとのことですが、各ページの mate タグでブラウジングエンコーディングを設定できるようです
それとも背景コード GBK によって文字が出力されているのでしょうか？
cmsを使用していますか？ gbkからutf8に変換されているのでしょうか
実はphpに詳しくないので推測ですが
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
