URLはどこにでもありますが、開発者はそれらを本当に理解していないようです。なぜなら、スタックオーバーフローでURLを正しく作成する方法を尋ねる人々をよく見ているからです。 URL構文の仕組みを知りたい場合は、Lunatechのこの記事を読むことができます。これは非常に良いことです。
この記事では、URLの構文全体を詳細に紹介しません（URLを完全に理解する場合は、RFC 3986、RFC 1738、および上記の記事、および上記のW3上記のドキュメントを読むことができます）。ここでは、URLを操作する際のいくつかの一般的なライブラリと、URLビルダーを介して正しく使用する方法についてお話したいと思います。これは、URLを正しく作成するために公開したJavaライブラリです。
質問1：JavaのUrlencoder
このクラスは貧弱な名前であるだけでなく、ドキュメント内の最初の文はあまり正しくありません。
HTMLフォームエンコーディングのユーティリティクラス。
なぜそれがurlencoderと呼ばれるのか疑問に思うかもしれませんが、この行を見ると完全に言葉がありません。
Lunatechのブログ投稿を読んだことがある場合は、このクラスを介してURL文字列を安全で正しくエンコードされたURLオブジェクトに奇跡的に変換できないことを理解する必要があります。もちろん、十分な宿題をしていない場合は、理解するのに役立つ小さな例です。
HTTPサービスエンドポイントhttp://foo.com/searchがあり、クエリパラメーターPを受け入れ、pの値が検索する文字列です。文字列「you＆i」を検索すると、初めて作成した検索のURLは次のようなものかもしれません：http：//foo.com/search?q=you＆I。もちろん、これは機能しません。この乱雑なURL文字列を取得した場合、まず第一に、それを正しく解析できないため、あなたは無力です。
OK、Urlencoderを使用しましょう。 urlencoder.encode（ "you＆i"、 "utf-8"）は、+％26+iの結果です。この％26をデコードした後、それは＆、 +記号がクエリ文字列のスペースを表しているため、このURLは正常に機能します。
ここで、クエリ文字列を使用して、URLパスをURLパラメーターに入れるのではなく、URLパスをスプライスするとします。明らかに、http：//foo.com/search/you＆iは間違っています。残念ながら、urlencoder.encode（）の結果も間違っています。 http://foo.com/search/you+%26+iは、+サインがURLパスのスペースに解決しないためです。
UrlenCoderは、シナリオの一部を満たす場合があります。残念ながら、その過度に一般的な名前により、開発者は簡単に誤用することができます。したがって、最良の方法はそれを使用しないことです。そうすれば、他の開発者が他の機能を使用すると間違いを犯します（「HTMLフォームエンコード」を実際に行っていない限り）。
質問2：Groovy httpbuilderとJavaのURI
HTTPビルダーは、GroovyのHTTPクライアントライブラリです。
通常のGETリクエストを作成するのは非常に簡単です：
new httpbuilder（ "http：// localhost：18080"）.request（method.get）{uri.path = "/foo"}このコードは、get /foo http /1.1をサーバーに送信します（NC -L -P 18080を実行してから、このコードを実行して確認できます）。
URLを含むスペースを試してみましょう。
new httpbuilder（ "http：// localhost：18080"）.request（method.get）{uri.path = "/foo bar"}これにより、get /foo％20bar http /1.1が送られます。
ここで、私たちのパスにfoo/barと呼ばれるセクションがあるとします。これは、Foo/Barを送信するだけでは実行できません。これは、パス、Foo、Barの2つのセグメントと見なされるためです。 foo％2fbarを試してみましょう（対応するエンコーディングに置き換えます）。
new httpbuilder（ 'http：// localhost：18080'）.request（method.get）{uri.path = '/foo％2fbar'}これにより、get /foo％252fbar http /1.1が送信されます。これはあまり良くありません。 ％2Fの％が繰り返しエンコードされるため、デコード後に得られたパスはfoo/barの代わりにfoo％2fbarです。ここで責める本当のことはjava.net.uriです。なぜなら、httpbuilderのuribuilderクラスはそれを使用しているからです。
上記のコードの構成閉鎖に公開されているURIプロパティのタイプは、ウリビルダーです。 URI.Path =…を介してURIのパスプロパティを更新すると、最終的にURIのコンストラクターを呼び出します。この方法では、次のように着信パスプロパティについて説明します。
パスパラメーターが提供されている場合、URLに追加されます。パス中の文字は、非予約、句読点、脱出、およびその他のカテゴリではない限りエンコードされます（翻訳者の注：これらのカテゴリはRFC 2396で詳細に説明されています）。
このアプローチはそれほど意味がありません。エンコードの前のテキストに特殊文字が含まれている場合、正しくエンコードされたパスセグメントを生成できないからです。言い換えれば、「私はこの文字列をエンコードします、そして、エンコードした後、それは正しいです」、それはもちろん誤りであり、ウリはたまたまこの誤りの犠牲者です。文字列が正しくエンコードされている場合、問題はありません。そうでない場合は、文字列を解析できないために行われます。実際、ドキュメントが言っていることは、パス文字列が正しくエンコードされていること（つまり、パスを分離するために正しく使用されている）を想定していることを逃がしません。
httpbuilderがURIクラスのこの欠陥のある機能を使用しない場合、それは素晴らしいことです。もちろん、URI自体が問題ない場合はさらに良いでしょう。
それを行う正しい方法
このURLビルダーを書きました。これは、開発者がさまざまな種類のURLを簡単にスプリッドするのに役立ちます。記事の冒頭にある参照資料のエンコーディング仕様に従い、ストリーミングAPIも提供します。次の使用例では、ほぼすべての使用シナリオをカバーできます。
urlbuilder.forhost（ "http"、 "foo.com"）.pathsegment（ "with spaces"）.pathsegments（ "path"、 "with" with "、"＆=？/"）.queryparam（" fancy + name "、" fancy？= value "）。 .fragment（ "＃？="）.tourlstring（）
その結果、http：//foo.com/with%20spaces/with/varargs/& =％3f%2F; matrix=param%3f？fancy%20%2b%20name = fancy？
この例は、URLの各部分の異なるエンコーディングルールを示しています。たとえば、エンコードされていない＆=パス内は許可されていますが、？これはすでにクエリ文字列の一部であるため、番号は必要ありません（翻訳者の注：クエリ文字列は？番号から始まるので、その後の番号を含めることができます）。
読んでくれてありがとう、私はそれがあなたを助けることができることを願っています。このサイトへのご支援ありがとうございます！