587

URL を無効にする文字はどれですか?

これらの URL は有効ですか?

  • example.com/file[/].html
  • http://example.com/file[/].html
4

10 に答える 10

660

一般に、 RFC 3986で定義されている URI ( Section 2: Charactersを参照) には、次の 84 文字のいずれかを含めることができます。

ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-._~:/?#[]@!$&'()*+,;=

このリストは、これらの文字が URI のどこに出現するかを示していないことに注意してください。

その他の文字は、パーセント エンコーディング ( %hh) でエンコードする必要があります。URI の各部分には、パーセントでエンコードされた単語で表現する必要がある文字について、さらに制限があります。

于 2009-10-10T13:26:14.147 に答える
233

いくつかの明確化を追加し、上記の質問に直接対処するために、URL と URI で問題を引き起こす文字のクラスがいくつかあります。

許可されておらず、URL/URI に表示してはならない文字、予約文字 (後述)、および場合によっては問題を引き起こす可能性があるその他の文字がありますが、「賢明でない」または「安全でない」とマークされています。文字が制限される理由の説明は、RFC-1738 (URL) およびRFC-2396 (URI) に明確に記載されています。新しいRFC-3986 (RFC-1738 への更新) では、特定のコンテキストで許可される文字の構造が定義されていますが、古い仕様では、次の規則で許可されていない文字について、より単純で一般的な説明が提供されていることに注意してください。

URI 構文内で許可されていない除外された US-ASCII 文字:

   control     = <US-ASCII coded characters 00-1F and 7F hexadecimal>
   space       = <US-ASCII coded character 20 hexadecimal>
   delims      = "<" | ">" | "#" | "%" | <">

文字「#」は、フラグメント識別子から URI を区切るために使用されるため、除外されます。パーセント文字「%」は、エスケープ文字のエンコードに使用されるため除外されます。つまり、「#」と「%」は、特定のコンテキストで使用する必要がある予約文字です。

不適切な文字のリストは許可されていますが、問題が発生する可能性があります:

   unwise      = "{" | "}" | "|" | "\" | "^" | "[" | "]" | "`"

クエリ コンポーネント内で予約されている文字、および/または URI/URL 内で特別な意味を持つ文字:

  reserved    = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" | "$" | ","

上記の「予約済み」構文クラスは、URI 内で許可されているが、一般的な URI 構文の特定のコンポーネント内では許可されていない可能性がある文字を指します。「予約済み」セットの文字は、すべてのコンテキストで予約されているわけではありません。たとえば、ホスト名にはオプションのユーザー名を含めることができるためftp://user@hostname/、「@」文字に特別な意味があるようなものにすることができます。

以下は、無効で不適切な文字 (「$」、「[」、「]」など) が含まれており、適切にエンコードする必要がある URL の例です。

http://mw1.google.com/mw-earth-vectordb/kml-samples/gp/seattle/gigapxl/$[level]/r$[y]_c$[x].jpg

URI および URL の文字制限の一部は、プログラミング言語に依存します。たとえば、「|」(0x7C) 文字は、URI 仕様で「賢明でない」とマークされているだけですが、Java のjava.net.URIコンストラクターでURISyntaxExceptionをスローするため、URL のようなものは許可されず、URI オブジェクト インスタンスで Java を使用しているかのようにエンコードする必要があります。http://api.google.com/q?exp=a|bhttp://api.google.com/q?exp=a%7Cb

于 2012-11-21T18:50:11.747 に答える
145

ここでの既存の回答のほとんどは、次のようなアドレスの実際の使用法を完全に無視しているため、実用的ではありません。

まず、用語の余談です。これらのアドレスは何ですか? それらは有効な URL ですか?

歴史的に、答えは「いいえ」でした。RFC 3986によると、2005 年以降、そのようなアドレスは URI ではありません (したがって、URLは URI の一種であるため、URL ではありません)。2005 IETF 標準の用語に従って、 RFC 3987で定義されているように、IRI (Internationalized Resource Identifier) と適切に呼ぶ必要があります。これは技術的には URI ではありませんが、IRI 内のすべての非 ASCII 文字をパーセントでエンコードするだけで URI に変換できます。 .

最新の仕様によると、答えは「はい」です。WHATWG Living Standardは、以前は「URI」または「IRI」と呼ばれていたすべてのものを単に「URL」として分類しています。これは、仕様の用語を、仕様を読んでいない普通の人が仕様の目標の 1 つである「URL」という言葉をどのように使用するかに合わせます。

WHATWG Living Standard で許可されている文字は?

「URL」のこの新しい意味では、どの文字が許可されていますか? クエリ文字列やパスなど、URL の多くの部分で、任意の「URL ユニット」を使用できます。

URL コード ポイントとパーセント エンコード バイト。

「URL コード ポイント」とは何ですか?

URL コード ポイントは、ASCII 英数字、U+0021 (!)、U+0024 ($)、U+0026 (&)、U+0027 (')、U+0028 左括弧、U+0029 右括弧、U+ です。 002A (*)、U+002B (+)、U+002C (,)、U+002D (-)、U+002E (.)、U+002F (/)、U+003A (:)、U+003B (;)、U+003D (=)、U+003F (?)、U+0040 (@)、U+005F (_)、U+007E (~)、および U+00A0 から U の範囲のコード ポイント+10FFFD (サロゲートと非文字を除く)。

%(「URL コード ポイント」のリストにはが含まれていませんが%、パーセント エンコーディング シーケンスの一部である場合、「URL コード単位」で許可されていることに注意してください。)

このセットにない文字の使用が仕様で許可されている場所を見つけることができる唯一の場所は、IPv6 アドレスが文字と文字で囲まれているhostです。URL のその他の場所では、URL 単位が許可されるか、さらに制限の厳しい文字セットが使用されます。[]

古い RFC で許可されていた文字は?

歴史のために、ここでの回答の他の場所では完全に調査されていないため、古い仕様のペアで許可されていることを調べてみましょう.

まず、RFC 3986予約文字には次の 2 種類があります。

  • :/?#[]@RFC 3986 で定義されている URI の一般的な構文の一部です。
  • !$&'()*+,;=RFC の一般的な構文の一部ではありませんが、特定の URI スキームの構文コンポーネントとして使用するために予約されています。たとえば、セミコロンとコンマはデータ URI の構文の一部として使用さ&れ、クエリ文字列=のユビキタス形式の一部として使用されます ( RFC 3986 では指定されていません)。?foo=bar&qux=baz

上記の予約文字はいずれも、構文上の目的を果たすため、または構文上の目的を果たす文字として誤解されない場所で、データ内のリテラル文字として、エンコードせずに URI で合法的に使用できます。(たとえば/、URL では構文上の意味がありますが、クエリ文字列では意味がないため、クエリ文字列でエンコードされていない状態で使用できます。)

RFC 3986 では、予約されていない文字もいくつか指定されています。これらの文字は、エンコードなしでデータを表すために常に使用できます。

  • abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-._~

最後に、%文字自体はパーセント エンコーディングに使用できます。

これにより、URL での表示が禁止されている次の ASCII 文字のみが残ります。

  • 改行、タブ、キャリッジ リターンを含む制御文字 (文字 0 ～ 1F および 7F)。
  • "<>^`{|}

ASCII の他のすべての文字は、合法的に URL に含めることができます。

次に、RFC 3987 は、その予約されていない文字のセットを次の Unicode 文字範囲で拡張します。

  %xA0-D7FF / %xF900-FDCF / %xFDF0-FFEF
/ %x10000-1FFFD / %x20000-2FFFD / %x30000-3FFFD
/ %x40000-4FFFD / %x50000-5FFFD / %x60000-6FFFD
/ %x70000-7FFFD / %x80000-8FFFD / %x90000-9FFFD
/ %xA0000-AFFFD / %xB0000-BFFFD / %xC0000-CFFFD
/ %xD0000-DFFFD / %xE1000-EFFFD

古い仕様からのこれらのブロックの選択は、最新の Unicodeブロック定義を考えると、奇妙で​​恣意的であるように見えます。これはおそらく、RFC 3987 が作成されてから 10 年でブロックが追加されたためです。

最後に、特定の文字列が URL の特定の部分でのみ有効であるため、特定の文字列が有効な URL であるかどうかを判断するには、URL にどの文字が合法的に表示されるかを知るだけでは十分ではないことに注意してください。たとえば、予約文字[と]は、http://[1080::8:800:200C:417A]/foo のような URL の IPv6 リテラル ホストの一部として有効ですが、他のコンテキストでは有効ではないため、 OPの例http://example.com/file[/].htmlは違法です。

于 2016-04-16T17:17:49.437 に答える
19

www.example.com/file[/].html補足の質問で、有効な URLかどうかを尋ねました。

URL は URI の一種であり、有効な URI には次のようなスキームが必要であるため、その URL は有効ではありませんhttp:( RFC 3986を参照)。

が有効な URLかどうかを尋ねるつもりだった場合http://www.example.com/file[/].html、角括弧文字が有効でないため、答えはまだいいえです。

角括弧文字は、次の形式の URL 用に予約されていますhttp://[2001:db8:85a3::8a2e:370:7334]/foo/bar(つまり、ホスト名ではなく IPv6 リテラル)。

問題を完全に理解したい場合は、RFC 3986 を注意深く読む価値があります。

于 2009-12-03T15:46:05.540 に答える
12

URI ( URLはURIの一種)で使用できるすべての有効な文字は、 RFC 3986で定義されています。

他のすべての文字は、最初に「URL エンコード」されていれば、URL で使用できます。これには、特定の「コード」の無効な文字 (通常はパーセント記号 (%) の後に 16 進数が続く形式) の変更が含まれます。

このリンクHTML URL Encoding Referenceには、無効な文字のエンコードのリストが含まれています。

于 2009-10-10T13:22:26.247 に答える
2

これは実際にはあなたの質問に対する答えではありませんが、URL の検証は本当に深刻な問題です。おそらく、ドメイン名を検証して、URL のクエリ部分をそのままにしておく方がよいでしょう。それが私の経験です。

URL に ping を実行して、有効な応答が得られるかどうかを確認することもできますが、このような単純なタスクには多すぎる可能性があります。

URL を検出するための正規表現は豊富にあります。Google で検索してください :)

于 2009-10-10T13:19:42.460 に答える
-5

テキスト内の URL をアンカー タグに変換する PHP 用の正規表現をいくつか考え出しました。(最初にすべてのwww. URL をhttp://に変換し、次にhttps?://を含むすべての URL をhref=... HTML リンクに変換します。

$string = preg_replace('/(https?:\/\/)([!#$&-;=?\-\[\]_a-z~%]+)/sim', '<a href="$1$2">$2</a>', preg_replace('/(\s)((www\.)([!#$&-;=?\-\[\]_a-z~%]+))/sim', '$1http://$2', $string) );

于 2016-12-26T18:36:55.427 に答える