この記事は、私が数年前に検索エンジンのプロジェクトに取り組んでいたときに解決できなかった問題の終結とみなすことができます。あまり役に立ちませんが、私の後悔の 1 つを補うことはできます。
その時の光景はこんな感じでした。 普通の人は検索ボックスに普通の検索語を入力して検索するのが常ですが、中には賢いと思ってアドレスバーからURLをコピーする人もいます。 http://www.xxx.com/search?keyword =%E4%B8%AD%E6%96%87 のようにパラメータを変更します (IE で表示されます。Chrome と Firefox では中国語が表示されます)。アドレスバー))、ユーザーが送信したリクエストが IE で http://www.xxx.com/search?keyword = 中国語である場合、サーバー (Web 処理バックエンド) がそのような文字をまったく認識できないことがわかります。これが、ブラウザーがバックエンドにリクエストを送信するときに、そのパラメーターが iso-8859-1 仕様の URLEncode である必要がある理由です。Web プログラムを作成する場合、IE ではエンコードを手動で変換する必要がありますが、Chrome と Firefox ではエンコードを手動で変換できます。変換するかどうかは、送信中に自動的に変換されるためです。
バックエンドが文字を認識できない、これがよく文字化けと呼ばれるものです。この種のコードが文字化けする原因は、デコード エラーにもあります。この時点で、Web コンテナ (Java の Jetty/tomcat/jboss や Python の django に似たフレームワーク) は、この文字列を自動的に UrlDecode します。エンコードされていない文字はデコードされ、二度と元に戻ることはできないと考えられます (私と同じようにこの種の文字化けしたコードを見て気分が悪くなり、医者に駆け込んだ人がどれほどいるでしょうか)。
この問題には実際には 2 つの解決策があります。1 つ目は、Web バックエンドに到達する前、つまり、ユーザーがアドレス バーで Enter キーを直接押す前です。サーバーのフロントエンド (nginx) は前処理を実行し、エンコードされていない文字を URL エンコードします。 2 つ目は、Web コンテナ内のサーブレット処理パラメータをデコードするロジックを再コンパイルして、URL デコードが必要かどうかを判断することです。
実装の難しさを考慮して、私は最初の方法を選択しました。これは、nginx で処理し、nginx の lua を使用してパラメータをトランスコードし、Web バックエンドにリバースプロキシすることです。
ここでは、プロジェクトが UTF-8 エンコードか GBK エンコードか、お客様の環境が UTF-8 か GBK かなど、注意すべき状況がいくつかあります。たとえば、私のシステムはブラウザが配置されている Windows であるため、クライアントのエンコーディングは GBK であり、プロジェクトは UTF-8 であるため、URL コーディングの前に GBK-》UTF-8 の操作を変換する必要があります。
set_by_lua $arg_name ' local iconv = require("luaiconv") local cd = iconv.new( "utf-8","gbk") if(string.find(ngx.var.arg_name,"%")){ ngx.var.arg_name, err = cd:iconv(ngx.var.arg_name) } return ngx.escape_uri(ngx.var.arg_name) ';
3 年前、IE のアドレス バーへの中国語の文字入力を手動で処理できる検索エンジンは Google だけでした。しかし、今日振り返ってみると、多くの企業がすでにこれを行っています。
以上、IEブラウザのアドレスバーにparamに中国語を直接入力した場合に発生するコード文字化けの解決策を、関連内容も含めて紹介しましたので、PHPチュートリアルに興味のある友人の参考になれば幸いです。