問題タブ [rfc3986]

質問する

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

49 問題
Newest
Active
Bountied
318
Unanswered
0 投票する
1 に答える
7290 参照

uri - { や } (中かっこ) などの文字を URL でパーセント エンコードする必要があるのはいつですか?

RFC 3986によると、次の文字は予約されており、予約された用途以外の URI で使用するには、パーセントでエンコードする必要があります。 :/?#[]@!$&'()*+,;=

さらに、特に予約されていないいくつかの文字を指定します。a-zA-Z0-9\-._~

一般に、(誤解を防ぐために) 予約文字をエンコードし、(読みやすくするために) 予約されていない文字をエンコードしないことは明らかですが、どちらのカテゴリにも該当しない文字はどのように処理する必要がありますか? たとえば、{and}はどちらのリストにも表示されませんが、標準の ASCII 文字です。

最新のブラウザーにガイダンスを求めると、動作が異なる場合があるようです。たとえば、URLhttps://www.google.com/search?q={を Web ブラウザーのアドレス バーに貼り付けることを検討してください。

  • Chrome 34.0.1847.116 m は変更しません。
  • Firefox 28.0 では変更されていません。
  • Internet Explorer 9.0 では変更されません。
  • Safari 5.1.7 では次のように変更されますhttps://www.google.com/search?q=%7B

ただし、貼り付けるhttps://www.google.com/#q={と (「検索」を削除して を に変更し?、#クエリ文字列ではなくフラグメント/ハッシュの文字部分を作成)、次のことがわかります。

  • Chrome 34.0.1847.116 m に変更しhttps://www.google.com/#q=%7Bます（JavaScript経由）
  • Firefox 28.0 では変更されていません。
  • Internet Explorer 9.0 では変更されません。
  • Safari 5.1.7 ではhttps://www.google.com/#q=%7B(JavaScript を実行する前に) に変更します。

さらに、JavaScript を使用して要求を非同期に実行する場合 (つまり、この MDN の例を の URL を使用するように変更して使用する場合?q={)、URL は自動的にパーセント エンコードされません。(これは、XMLHttpRequest API が URL が事前にエンコード/エスケープされていることを想定しているためだと思います。)

私は (奇妙な顧客の要求に関連する理由で) URL のファイル名部分で (1) 物事を壊すことなく、理想的には (2) 最新のネットワーク パネルで見苦しいパーセント エンコードされたエントリを作成することなく、{andを使用したいと考えています。}ブラウザーの Web インスペクター/デバッガー。

0 投票する
2 に答える
2016 参照

http - URLの正式名称「スキームプラスオーソリティ」

http または https の絶対 URL を想定します。URL のパスの前にある部分の「公式」または一般的に受け入れられている名前を探しています。

RFC 3986では、URL 構文部分を次のように定義しています。

RFC 6454では、URL のオリジン (「同じオリジン」) をトリプル (スキーム、ホスト、ポート) として定義しています。

したがって、どちらの用語も適切ではありません。私が見ている部分に適切な用語はありますか、それとも「スキーム（プラス://）プラス権限」で立ち往生していますか？

0 投票する
1 に答える
2480 参照

url - URLの疑問符はクエリ文字列の一部ですか?

TL;TR: URL の (最初の) クエスチョン マークはクエリの一部ですか、それとも区切り記号の後にクエリが続くだけですか?

RFC 1738のセクション 3.3 では、「?」(疑問符) はクエリ文字列の一部ではなく、パスから分離するだけです。

RFC 3986の付録 A に示されている文法も、「?」を示しています。実際のクエリ文字列の一部ではありません:

ここで、2 つの URL を考えてみましょう。

  1. http://server.com/api/item.json
  2. http://server.com/api/item.json?

それらは同等ですか、それとも異なりますか？

それらを区別して、2 つの異なるリソースを識別するために使用することは有効ですか?

0 投票する
0 に答える
83 参照

swift - URL(string:) には有効で URLComponents(string:) には無効な文字列の例は?

URL(string:)文字列が RFC 1808 で定義されている URL を表していない場合、Foundation の初期化子は失敗する可能性があります。

URLComponents(string:)文字列が RFC 3986 で定義されている URL を表していない場合、初期化子は失敗する可能性があります。

URL(string:)を返すURLがをURLComponents(string:)返す文字列の例はnil? (RFC 1808 では有効で、RFC 3986 では無効な URL 文字列はありますか?)


12345678910