9

私は自分のURLにアンカーを使用して、人々がWebアプリケーションで「アクティブなページ」をブックマークできるようにしています。アンカーはGWT履歴メカニズムに簡単に収まるため、アンカーを使用しました。

私の既存の実装は、ナビゲーションとデータ情報を「-」文字で区切ってアンカーにエンコードします。つまり、＃location-location-key-value-key-valueのようなアンカーを作成します

負の値（-1など）が深刻な解析の問題を引き起こすという事実を除けば、それは機能しますが、2つの区切り文字を使用する方がよいことがわかりました。また、負の数の問題を与えるために、「-」を使用して捨てたいと思います。

URLまたはそのGETパラメータに干渉しないURLアンカーで機能する他の文字は何ですか？これらは将来どのくらい安定しますか？

4

1 に答える 1

18

URL の RFC を見ると、セクション 3.5のフラグメント識別子 (あなたが参照していると思われる) は次のように定義されています。

フラグメント = *( pchar / "/" / "?" )

および付録 Aから

pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
未予約 = ALPHA / DIGIT / "-" / "." / "_" / "~"
サブデリム = "!" / "$" / "&" / "'" / "(" / ")"
                 / "*" / "+" / "," / ";" / "="

興味深いことに、仕様には次のようにも書かれています

「文字スラッシュ ("/") と疑問符 ("?") は、フラグメント識別子内のデータを表すことができます。」

したがって、次のような実際のアンカーのようです

<a href="#name?a=1&b=2">
....
<a name="name?a=1&b=2">

合法であるはずであり、通常の URL クエリ文字列と非常によく似ています。(簡単なチェックで、これらが少なくとも chrome、firefox、および ie で正しく機能することが確認されました)

http://www.site.com/foo.html?real=1¶meters=2 #fake=2¶meters=3

問題ありません (たとえば、フラグメント内の「パラメーター」変数は、クエリ文字列内の変数と干渉してはなりません)

必要に応じてパーセントエンコーディングを使用することもできます...そして、使用可能なサブデリムで定義された他の多くの文字があります。

ノート：

また、仕様から：

「フラグメント識別子コンポーネントは、番号記号 ("#") 文字の存在によって示され、URI の末尾で終了します。」

したがって、# の後のすべてがフラグメント識別子であり、GET パラメータに干渉してはなりません。

于 2009-02-19T17:47:56.540 に答える