そのため、URLEncoder のエンコードと URLDecoder のデコードの javadoc には、次の注記が含まれています。
Note: The World Wide Web Consortium Recommendation states that UTF-8 should be used. Not doing so may introduce incompatibilites."
しかし、誰かが別のエンコード タイプのリクエストを送信した場合、UTF-8 でエンコードするのは悪い考えではないでしょうか? ヘッダーをチェックして (存在する場合)、そこで指定されているエンコーディングを使用することに問題はありますか? おそらく、誰かがそれを提供できれば、このメモの背景をもう少し説明することで、私にとってより意味のあるものになるでしょう.
同資料には
推奨されるエンコード方式は UTF-8 です。ただし、互換性の理由から、エンコーディングが指定されていない場合は、プラットフォームのデフォルトのエンコーディングが使用されます。
エンコーディングを変更できますが、W3C に準拠していないため、お勧めできません。
資力 ：
Tomcat およびその他の一部の Web サーバーには、GET 要求で URL に使用されるデコーダーを制御する個別の設定があります。URIEncoding具体的には、「Connector」の属性で指定されていない限り、Tomcat はサーバーのデフォルトの文字エンコーディングを使用します。
同様の問題に対処していたときに、この投稿の議論が役立つことがわかりました。
一部の国の Web サイトでは、他のエンコーディングを使用しています。これは、UTF-8 がその言語では非効率的であるためです。
URL は一般に不透明です。これは、Web サイトによって生成され、同じ Web サイトによって消費される一連の ASCII 文字です。Web サイト自体がそれを解析できる限り、それで問題ありません。
一方で、人々は URL を調べて、より詳細な情報を理解しようとします。ブラウザは、% でエンコードされたオクテットでいっぱいの URL を表示するときに、それらを文字に変換したい場合があります。残念ながら、文字エンコーディングを推測する必要があります。理論的には、エンコーディングは独自のものであっても何でもかまいません。
また、サード パーティが管理していない Web サイトへの URL を生成する場合もあります。Google 検索 URL を動的に生成したプログラムはいくつありますか? 繰り返しになりますが、Web サイトでサポートされているエンコーディングは推測する必要があります。
したがって、あなたが Web サイトの所有者であり、親切に対応したい場合は、UTF-8 でエンコードされた URL をサポートすることをお勧めします。もちろん、そうである必要はありません。それはあなたの URL です。それはあなた次第です。