hash fragment

素片識別子 (URL)

[135] 素片識別子 (fragment identifier) は、 URL の一部分であり、素片識別子以外の部分により識別される資源の一部分、 あるいは表現の一種を識別するために使われます。

[349] URL に現れる # とそれ以降の部分が素片識別子です。

[560] <https://www.example.com/foo#hello> では、 #hello の部分が素片識別子です。

仕様書

呼称

[512] URL の現行仕様である URL Standard は、 「素片 (fragment) 」と呼んでいます。

[513] 一般的には、単に素片だけでは文脈上意味が明確でないこともあるので、 素片識別子 (fragment identifier) URL素片 (URL fragment) などと修飾して呼ぶこともあります。

[136] 俗称: DOM では、素片識別子を表す属性名として「hash」 を使っています。これは、素片識別子の先頭を表す文字#」 の俗称に由来しています。

[137] 特に HTML 文書素片識別子については、「アンカー」や 「アンカー名」と呼ばれることもあります。

[389] >>388fragid と呼んでいます。

[21] 日本語訳: 「素片識別子」 (fragment identifier) は、 フラグメント識別子断片識別子などとも訳されます。

[462] hash fragment と呼ぶこともあります >>461

意味

[503] URL (を表すデータ構造) は、素片を持ちます。 素片 (fragment) は、 null か、 URL の他の部分が識別する資源の更なる処理に使うことができるデータを保持する文字列のいずれかです >>318

[516] URL 一般に対しては、素片識別子の意味はこのように抽象的なもので、 構文もほとんど何でもありになっています。 URL が表す資源の形式 (MIME型) によっては構文上の制限を規定したり、意味や処理方法を規定したりしています。

[517] 例えば HTML (text/html) では要素id 属性値と一致するなら、その要素を表すと規定されています。

[518] 歴史的には MIME型によって解釈が定められるというのが仕様書の「正式」 な素片識別子の意味でしたが、実際には徐々に意味が拡大し、 色々な用法が存在しています。

詳細は後述。

構文

[504] 素片は、0個以上URL符号位置の列でなければなりません >>320

[509] 定義上、最初の #素片の一部ではありません。
[510] 空文字列でも構いません。長さの上限はありません。
[511] 非ASCII文字が含まれることがあります。
  1. #
  2. *
    1. URL符号位置

[628] URL構文解析器は、素片識別子正準形に変換します。 この時パーセント符号化では素片パーセント符号化集合が使われます。

文脈

[8] 素片識別子は、 URL の一部として使うことができます。 素片識別子のみで構成される URL もあります (それを特に同文書参照ということがあります)。

素片識別子だけを使うプロトコル要素

[17] SMILfragment 属性は、 HTMLname 属性や id 属性や、 XML の素片識別子を使ってある資源の一部を識別するために使うことができます。

[18] XIncludexpointer 属性は、 XPointer を使って XML の一部を識別するために使うことができます。

[586] Web AnnotationFragmentSelector素片識別子# の後 (# は含まない。) を使っています >>585

[529] HTMLusemap 属性値は、元々は URL でした。現在では #name 属性値を指定するものと再定義されています。

構文解析

[505] URL構文解析器は、最初の # の後を素片として扱います。 基本的には、 # よりも後に記述された文字列がそのまま素片となります。 >>319

パーセント復号は行われません。

[506] U+0000U+0009U+000AU+000D は、無視されます >>319

[507] # がなければ、素片null です >>318, >>319

[508] 次の場合は、構文解析誤りです。

処理

誤り

[414] 素片識別子は、それが文書中の何らかの部分を示す場合の他に、 構文的に誤りがある場合、構文的に誤ってはいないが指すものが存在しない場合があります。 >>391

[415] しかし、そのような誤りであっても、

... のように正当な理由があることもあります >>391

[419] >>418 が正当な理由と言えるのかは怪しいですが...

[420] ですから、MIME型素片識別子の規定は構文の制約を設けるものではなく、 認識できる素片識別子をどう解釈するかを決めるものとなります >>391。 解決できない素片識別子を与えられた応用の動作は、実装定義とするべきです >>391

[421] >>415 のような理由があるから実装定義だと >>391 は言っていますが、 そうであるからこそ実装定義ではなく処理モデルを明確に決めないと相互運用性に問題が出る気がしますが...

API

素片識別子と URI scheme

[23] URI の素片識別子と scheme 以外の部分の構文は、 (URI 全体の規定の範囲内で) 使用している URI scheme によって規定されています。 古くは素片識別子も URI scheme に依存すると考えられたこともあり、 古い URI scheme の中には素片識別子の扱いについて触れているものもあります。 しかし、現在では素片識別子は URI によって識別される資源の性質に依存するものであり、 URI scheme とは独立であると考えられています。

[142] URI scheme によっては、歴史的、その他の理由により、 構文的に素片識別子と矛盾する規定・実装がなされていることがあります。 詳しくは >>95 を参照してください。

[480] ws:/wss: では素片識別子が禁止されています >>479

文書形式と素片識別子

素片識別子と MIME 型

[468] 素片識別子の解釈は、当該 URL解決して得られる文書の種別によって異なります。

[469] MIME型に関するIANA登録簿への登録の際には、 当該MIME型における素片識別子の解釈を規定できます >>467

[470] しかしこれは義務ではなく、規定していないMIME型が大多数です。

[24] URI の仕様書によれば、素片識別子の構文はその URI 参照による取出し行為 (RDF のように仮想的な取出し行為も含まれます。) の結果得られる資源媒体型に依存するとされています。 取出しが行われなければ、素片識別子の構文と解釈はできず、 実質無制約になります WebArch 3.2.1

[25] URI 参照によって識別される資源は内容折衝の対象になっているかもしれません。 そうでなくても、一つの URI 参照に対応する資源を取出す手段 (仮想的なものかもしれません。) が複数あれば、 それぞれによって違うものが取出されるかもしれません。 動的表現 (>>26) をも一つの URI 参照に対応する資源表現の一種と考えることもできます。

取出された資源の媒体型が異なると、同じ素片識別子であっても異なるものを指し得ます。 あるいは、一方に対しては構文や意味が定義されていなかったり正しくなかったりすることも起こり得ます。

実際に識別されるものが意味的に異なっている場合は、 鯖の設定の誤りと考えられます。構文や意味が未定義であるのは、 すべての媒体型が同じ機能を提供していないのですから仕方が無いことです。 WebArch 3.2.2

このような問題をできるだけ避けるために、 各媒体型で素片識別子の構文や意味論は大きく変えてしまわないことが好ましいと考えられています。

[29] 素片識別子を媒体型から独立したものにしようという提案もありますが、 今のところ広く受け入れられてはいません。

[96] URIが単なる所在指示子としてだけではなく、識別子として重要性を帯びてからは、 素片識別子もが取出しを伴わない文脈で用いられるようになりました。 仕様の側もそれを容認すると明記しています。 構文と素片識別子単体での意味も事実上不定になります。 (>>24, [WebArch], [RFC 3986])

[97] この問題に遭遇したRDFは、 (当時のURI仕様であるRFC 2396との整合性のため) RDF URI参照における素片識別子は、application/rdf+xmlで解釈することとするとのやや無理のある規定を設けています。

[104] xmpp: URI scheme: xmpp: URI scheme では、 XMPP においては資源表現を持たないので、 媒体型もなく、 RFC 3986 にある通り実質無制約になり、 XMPP 応用は好きに使って良い、とされています。 RFC 4622 2.6, >>543

[98] 名前空間URIでは局所名と結合した時に素片識別子付きURIとなることを期待して#で終わらせたURIを使うことがよくありますが、 これも取出して得られる表現とは (あったとしても) なんら関係がなく、単に形式的なものです。

[390] MIME型IANA登録簿への登録には、素片識別子の情報を含められることになっています。 しかし登録時期が古い MIME型のほとんどには、素片識別子の情報が含まれていません。

[393] MIME型素片識別子の解釈を定義するに当っては、 次の目標を念頭に調整しなければならない >>391 とされています。

[483] IETFMIME型によって素片識別子の解釈が決まると言っていますが、 実際には MIME型そのものによらないで決まる場合もあります。

構造化構文と素片識別子

[403] XMLJSON のような構造化構文に関しては、 XPointerJSON Pointer のように構文一般に適用される素片識別子の仕組みもありますし、 特定の応用で必要な素片識別子を規定することもあります。

[471] 一般にMIME型は意味的に似たMIME型が使っている素片識別子の形式を採用することを推奨 (encourage) されています >>467

[472] 特に登録された構造化構文接尾辞を使う場合には、 構造化構文接尾辞における素片識別子の規則に従わなければなりません >>467

[397] 構造化構文の場合には、特定のMIME型の知識を持った応用と、 そうでない共通処理器とで素片識別子は同じものを識別する (ように素片識別子の構文と意味が規定される) べきです >>391

[404] 特定の応用のみの素片識別子の構文と意味を規定してはいけないということではなく、 共通の構文と意味に矛盾しない形で拡張するべきだということです。

[398] これは構造化構文のみならず、 text/*image/* のような最上位型など、 共通処理器によって処理されるもの一般に適用される >>391 とされています。

[402] 構造化構文共通処理器による処理と最上位型共通処理器による処理とが両方適用される場合、 両者で素片識別子の処理が衝突してしまうことが無いように規定するべきですが、 それができない場合には構造化構文接尾辞を使わないべきです >>391

[256] 構造化構文接尾辞 (+xml+json のような接尾辞) は IANA 登録時に素片識別子についての欄があります。

... に関しては、次のように規定があります。

  1. [258] 構造化構文接尾辞素片識別子の構文と意味は、 相当する単体の MIME型 (+tlv の場合、 application/vnd.oma.lwm2m+tlv) の素片識別子の構文と意味と同じとする
  2. [259] 所属するMIME型素片識別子の構文と意味は、
    1. [260] 構造化構文接尾辞で定義されている場合、
      1. [573] それにより解決できる場合は、それによる
      2. [261] 解決できない場合は、MIME型による
    2. [262] 構造化構文接尾辞で定義されていない場合は、MIME型による

[574] この規定は、 +tlvapplication/vnd.oma.lwm2m+tlv のように、参照先で素片識別子の構文と意味が規定されていない場合にも存在しています。 実質的にMIME型によると言っているのと同じなのですが、将来の改訂で構造化構文接尾辞全体の素片識別子を追加できる余地を最初から設けておくという趣旨なのでしょうか。

内部参照に使う URI 参照としての素片識別子

[50] 同じ文書内で参照を行うためには SGMLIDREF のように専用の機構を用意しているものもありますが、 URI参照IRI参照を採用して外部への参照と兼用していることもよくあります。 その場合、当然素片識別子が使われることになります。

素片識別子の構文と意味は、 その参照先の資源表現媒体型によります (>>24)。ですから、 そのような使い方をする文書形式では素片識別子の構文と意味が陽に定義されている必要があります。

[51] ところが、特に XML 系の文書形式の仕様で、 ID 属性を参照先として使っている場合には自明なためか明確に規定されることがあまりありません。 XML の場合、名前空間を使って複数の語彙を混在させられるのですから、 素片識別子の解釈が異なる語彙が共存するとき、どう処理されるのかが問題となります (>>538)。そうでなくても、 XML には多くの文脈でそれぞれの ID の定義が用意されており、どれに従うべきかを本来は明確に規定しなければならないはずですが、 おざなりにされています。

ID も参照。

[575] また、基底URLを指定できる時、内部参照のつもりの素片識別子のみの URL をどう解釈するかが問題となることもあります。

同文書参照も参照。

MIME 型のない形式と素片識別子

[52] HTTPMIME での利用を想定していない (他のプロトコルを使う、プロトコルで転送せずメモリー上のみ存在するなど。)、 マーク付け言語の汎用のMIME型 (text/xml など) を使う、 といったような理由で専用の MIME型を持たない文書形式も存在します。 中には、にも関わらず、独自の素片識別子を (明示的または暗示的に) 規定するものもあります。

複合文書との関係

[538] XML のように複数の語彙を組み合わせることができるマーク付け言語では、 それぞれの語彙素片識別子の解釈を持っている時、その組み合わせで素片識別子をどう解釈するべきかが問題となります。

[539] XML としてはその解決方法を持っておらず、 本来なら語彙を組み合わせたマーク付け言語の側で明確に規定する必要があるのですが、 実際には曖昧なままにされていることがほとんどです。

[540] 特に XML署名 (>>49) や XML Events (>>53) のように他の語彙と組み合わせることが想定された語彙では問題となります。 RDF/XML (>>13) も、他の語彙と組み合わせた時に意味が衝突する例です。

[53] 例: XML事象handler 属性などで URI参照を使っていますが、 それが同文書参照である時の意味を特に規定していません。 意味的には IDREF として扱われることが期待されていますが、 XML事象ホスト言語と組合せて使うものですから、 その組合せのプロファイルでこれと矛盾しないように素片識別子の規定を行わなければなりません。 (その例: SVG 1.2)

XML Events <http://www.w3.org/TR/2003/REC-xml-events-20031014/>

[482] XHTML+Voice の仕様書は、 XML Events同文書参照を使う例を示しています。 X+V 本体仕様書は MIME型には言及していないのですが、 MIME型 application/xv+xml (>>103) を規定する RFC では、 ID を指すと解釈することが規定されています。

[541] 理論上は、MIME型によって素片識別子の解釈は変わるはずで、 規定がなければ何を表すか不明になってしまいます。しかし、 特に同じ文書内の他の要素を指している場合には、 著者にとって難解で、実装も複雑になってしまいます。

[542] 実際上は、平名前素片識別子 (XPointer 速記指示子) によって他の要素ID を指すことがほとんどで、 それ以外の方法は実装もほぼされていないので、あまり問題とはなりません。 MIME型で明確に素片識別子が規定されていない XMLマーク付け言語でも、 (素片識別子を使うなら) そう実装されているのが普通です。

内容折衝との関係

[399] 内容折衝により同じ URL で違う表現が返される可能性がある場合、 素片識別子は同等のものを指していることもあれば、 一方でしか存在しないものを指している場合や、一方ではエラーになる場合もあります。 同じ素片識別子が異なるものを指す場合もあり得ます。

[400] これは内容折衝を使うのが好ましくない理由の一つでもあります。

[401] MIME型素片識別子を規定する場合には、内容折衝される可能性のある他の MIME型との整合性を検討しなければならない >>391 と指摘されています。

[425] 著者は、内容折衝で提供される表現間で同じ素片識別子が意味的に同じ構造を指すように、 また意味的に同じ構造は同じ素片識別子で参照できるようにするべきです >>358

[426] 素片識別子を使って参照する場合は、何らかの手段で単一の表現しか無いと確認できない限り、 構文に基づく素片識別子構造を使うべきではありません >>358

[427] そのような手段は事実上存在しないので、実質的に著者以外は使わないよう求めていることになります...

動的表現との関係や状態保存のための用法

[410] 文書の状態がスクリプトその他によって変化すると、 素片識別子が指すもの、あるいは差し得るものが変化することがあります。 またスクリプト素片識別子を参照し、何らかの処理を実行したり、 表示状態を変化させたりすることがあります。 特に後者は、MIME型によって規定される素片識別子の意味を実質的に拡張するもの >>391 です。

[26] 例えばある XML 文書 <http://www.example.org/xml> で、 はじめ id という識別子は定義されていなかったとします。 この時、 URI 参照 <http://www.example.org/xml#id> は指すものがありません。

ところが、 Web ブラウザにおける何らかの処理の過程においてこの文書のある要素の IDid と設定されたとします。すると URI 参照 <http://www.example.org/xml#id> はその要素を識別するようになります。

このような状況は、便利なこともありますし、混乱を招くこともあります。

[27] ある XML 文書を XSLT スタイル・シートによって変換したとします。 変換した結果には、元の文書に存在していた ID が (それに対応する要素と共に) 残っているかもしれませんし、 残っていないかもしれません。ある原始要素に対応する結果要素の識別子は元とは違った識別子になっているかもしれません。 ある識別子に対応するのは原始要素に対応する結果要素とは違う (関係のない別の) 要素かもしれません。元の文書とは無関係に、 スタイル・シートが新しい識別子を導入するかもしれません。

このような状況は、便利なこともありますし、混乱を招くこともあります。

[448] DocBook では同じXML文書要素IDREF 型の属性で参照できますが、 XInclude で取り込まれた部分の要素を参照する時には素片識別子を使う必要が生じます >>447。つまり IDREF は読み込み時点での状態を指しており、 素片識別子は参照時点での状態を指していると思われます。

[165] Webアプリケーションでは、1つの HTML 文書が複数の「状態」を持つことがあります。 例えば Webメイルメイル一覧画面を表す HTML 文書1つでクライアントスクリプトを使って日付順、送信者順など複数の表示方法を実現している場合に、 素片識別子にその「状態」の情報を詰め込むことで、1つの文書の「状態」を URL として表すことができます。

[166] スクリプトによる状態保存に使う用法は元々 nameid を表すものとして用意された HTML素片識別子の使い方からは外れていますが、 ある資源の一部分や一表現法を表すとの URL 一般の素片識別子の意味論的には間違ってはいません。 URL の一部分という性質上、多量・大容量の「状態」を詰め込むのには適していませんが、 手軽に実現可能かつハイパーリンク可能な点が優れています。

[167] HTML5 はこのような用法の応用への期待が高まっていることも踏まえて、 hashchange 事象を追加しました。

[411] 著者スクリプトによる素片識別子の解釈が MIME型による素片識別子の解釈と衝突しないようにする必要がありますから、 MIME型素片識別子の規定の際は著者が動作を理解しやすいように配慮し、 著者がどのような構文を使うことができるのか明確にする必要があります。 >>391

[412] 2011年頃には #!スクリプトによる解釈に使う構文とすることが流行りました (が2,3年で廃れました)。

#! 参照。
[413] >>391>>411 のような構文の例として #! を挙げています。

[409] <https://twitter.com/#!/twitter><https://twitter.com/twitter> に相当する内容がスクリプトによって表示されるようになっていました。

[430] OAuth 2.0から利用者エージェント上で動作する JavaScript 応用への情報伝達に素片識別子を使っています (>>428)。

[431] postMessage が実装される以前には、 異なる起源URL (の iframe 内の文書) との通信に素片識別子を使う手法が用いられることもありました。

部分資源を識別しない、あるいは何を識別するか未定義の場合

[140] 本来、媒体型についての素片識別子の仕様書は、 素片識別子がどのような部分資源を識別するのかを完全に定義するべきです。 例えば、 id 属性の値が一致する要素を識別するような場合、 一致する要素が存在しない場合に何を識別するのか (しないのか)、 実装がどのように動作するべきなのかを規定しておくべきです。

[141] ですが、現実には、多くの仕様はそれを曖昧にしています。 更には、ほとんどの媒体型については、そもそも素片識別子が定義されていません。

[3] HTML 文書 (text/html) の場合、 文書内に存在しない素片識別子つきの URI参照レンダリングさせようとすると、 文書の最初を表示する Webブラウザ (例: WinIEMozilla (Gecko)) と、 最後を表示する Webブラウザ (例: Classic Mozilla) があります。

素片識別子とプロトコル

[523] HTTP では、要求URL素片識別子は含まれません。 ハイパーリンクなどで指定された URL のうち、素片識別子以外の部分が HTTP で送信され、その結果の資源に対してクライアント側で素片識別子を解釈します。

[524] 素片識別子サーバーが取得できる方が便利な場合もあるとして、 素片識別子を送信させるような HTTP の拡張が提案されたこともありました。 しかし現在まで受け入れられるには至っていません。

[527] 媒体素片は、クライアントが解釈する素片識別子構文とサーバーが解釈する URL query 構文の両方を用意しています。しかしこの両者を自由に相互変換できるというものでもありません。 素片識別子に基づき範囲要求を送信する方式も提案されていましたが、 未完成に終わっています。

[525] 検索エンジンなどは #! 構文 (>>412) により、 スクリプトが使う素片識別子path との変換規則を定めていたことがあります。

この方式は2011年頃に流行しましたが、その後あまり見かけなくなりました。 スクリプトで生成する内容とサーバーが生成する内容との対応関係を維持したいとき、 現在では Pjax (pushState) により pathquery を使うのが一般的になっていますから、そのために素片識別子path との対応関係を定めて使う必然性が無いのでしょう。

[528] OAuth 2.0認可エンドポイントは、クライアント上のスクリプトに向けた (サーバーに送られるべきではない) 引数URL に入れて引き渡すとき、 素片識別子を使っています。

[526] 素片識別子サーバーに送ってはいけないという決まりはありませんから、 (HTTP 以外のプロトコルでは) 素片識別子サーバーに送られないと仮定するべきではありません。

[559] 実際のところ、 HTTP であっても、 Webページで動作するスクリプトは表示中の文書URL の一部として素片識別子を取得できます。 スクリプトはいつでもこれをサーバーに送信できます。 つまり素片識別子は不用意に情報をサーバーに送信してしまわないために使うことはできますが、 漏洩してはまずい情報のために使ってはいけません。

文書の示された部分

[181] 文書DOM で表される場合、 「文書の示された部分 (the indicated part of the document) 」 は素片識別子によって表される文書の部分のことをいいます。 この場合に素片識別子から DOM節点にどう対応付けられるかは、 その文書MIME型の仕様によって決められることとなっています >>146

[359] 現時点でこれが厳密に規定されているのは、 HTML (text/html) の場合 (>>360) のみです。

[367] 文書の示された部分は、要素であることもあれば、 「文書先頭 (top) 」であることや、 存在しないこともあります。

[473] XML においては XPointer 仕様書によりXML情報集合上で一致する要素情報項目が規定されていますから、それに相当する DOM 上の要素が (あれば) 文書の示された部分と解釈するべきと思われます。 ただし、かつて DOM3 ではXML情報集合DOMの関係が規定されていましたが、 現在はどこにもそれに相当する規定がありません。

[474] また、 XML でも #top が先頭を表すのかどうか不明です。

[564] 現実には HTML の場合と同じ処理が行われているのではないかと思われます。 例えば a 要素name 属性へとスクロールされます。

[475] 平文でも理論上は示された部分が存在しますが、そのような実装が存在するのかは不明です。

[570] 平文媒体文書の場合、スクリプトで適宜変形して任意の DOM を構築することができますが、文書内容型に関わらず HTML と同じ方法で文書の示された部分が決められるとも考えられます。

[369] 擬似クラス :target は、文書の示された部分要素の場合、その要素一致します >>146

[370]文書の先頭」が文書の示された部分の場合や文書の示された部分が存在しない場合には、 :target一致するものはありません。

[476] 素片識別子へのスクロールは、viewport 上に文書の示された部分を表示する操作です。

素片識別子構造

[240] 素片識別子の意味や構文、処理方法の規定のことを素片識別子構造と呼びます >>297素片識別子の共通の意味や構文、処理方法の他に、 適用対象の文書MIME型などによって個別の規定があります。

[298] 具体的な素片識別子構造については、本項の以降の章や各 MIME型の項を参照してください。

[299] 特定のMIME型専用の素片識別子構造を発明するよりは、 できるだけMIME型共通の素片識別子構造を共有するべき >>297 とされています。

資源取得のためのメタ情報を埋め込む用法

要約値の埋め込み

[143] 素片識別子を、 URL によって識別される資源表現が正当なものである、 あるいはある特定の版であることを確認するためのハッシュ値、 あるいは指紋を埋め込む場所として用いようとする提案があります。

[112] Link Fingerprints <http://www.gerv.net/security/link-fingerprints/> (名無しさん 2006-11-11 03:36:08 +00:00)

[144] 詳しくは #hash() の項を参照してください。

[145] このような提案は、実装実験も行われている一方で、 元々の素片識別子の意味から逸脱しているとの批判もあります。

[458] JWT で使われることがあります (>>455)。

[150] >>15>>90 のようなを指定する素片識別子もこれに類するといえるかもしれません。

履歴管理制御のための用法

[161] Webブラウザーによっては、素片識別子を含む URL 全体を未読かどうかの判定に用いています。

例えば、 FirefoxURL 全体からリンク先が未読既読かを判定し、 :visited 擬似クラス一致するかを決めています。 WinIE素片識別子を除く URL によって判断しているようです。

[162] アンテナwiki の更新頁一覧などリンク先が頻繁に変更されることが前提となっている場面では、 Webブラウザーによる未読既読判定をある程度制御するため、 日付などの適当な文字列を素片識別子として付与することがあります。

[163] 例えばアンテナが a.html が2009年12月31日に更新されたことを検知した場合、 URL として a.html#20091231 を使います。利用者がそのリンクをたどると、 Webブラウザーは a.html#20091231 を履歴データベース上で既読とします。 利用者が次にそのアンテナの頁を見たときには、 a.html#20091231 へのリンクは既読になっています。

次にアンテナが a.html が 2010年1月2日に更新されたことを検知すると、 URL は a.html#20100102 になります。利用者がそのアンテナの頁を見たときには a.html#20100102 へのリンクは未読になっています。

[164] 同様の目的で照会を用いる方法もあります。照会を使えばどのWebブラウザーでもこの効果が得られるという利点がありますが、 素片識別子とは違って照会は実際にに送信されるため相手方に動作が依存してしまうという欠点があります。

複数の素片識別子

[514] 素片識別子は、1つの URL に高々1つしか記述できません。 #URL符号位置なので、素片識別子内で # を使うこともできません。

[515] が、それでも使われていた場合は、素片識別子の一部とみなされます。

[2] GNOME VFS URI とやら (Writing Modules <http://developer.gnome.org/doc/API/gnome-vfs/writing-modules.html#URIS>) は、素片識別子 (のようなもの) を複数つけることができます。 (例: ftp://username:password@host.net/path/to/file.tar.gz#gzip#tar/path/to/hello.c)

[28] WinIE'behavior'default behavior (組み込みの HTC) を参照するために #default という URL と機能を指定する素片識別子の組み合わせを使っており、 つまり # が2つ入った文字列の指定を受け付けていました。

素片識別子と基底 URL

この項は書きかけです。 基底URL の解説とあわせて内容をなんとかしたいところです。。。

[79] The Linear Topic Map Notation <http://www.ontopia.net/download/ltm.html#N565>

LTM (線形Topic Map記法) の BASEURI 指令は、RFC 2396 的解釈に基づき、 素片識別子だけの URI には適用されないことになっています。

歴史

[20] 主たる仕様:

[137] 関連仕様:

定義

[1] ISO-HTML における定義:

素片識別子 (Fragment identifier)
href 属性値の # に続く部分。ISO‐HTML 4.9

[152] RELAX NG における定義:

3.6 fragment identifier
additional information in a URI reference used by a user agent after the retrieval action on a URI has been successfully performed
ISO/IEC 19757‐2:2003

生成規則 fragment

[227] URI 系規格で構文規則 fragment は、素片識別子を表しています。

  1. [228] fragmentid := xalphas ;; RFC 1630
  2. [229] fragment := *( uchar / reserved ) ;; RFC 1808
  3. [230] fragment := *uric ;; RFC 2396 4.1

URI/URL と素片識別子

[22] RFC 2396 においては素片識別子URI の一部とはされていませんでした。 絶対URI, 相対URI, 素片識別子をあわせたものを URI参照と呼んでいました。

[138] 新しい RFC 3986 は、素片識別子URI の一部としています。

[139] 非公式には、以前から素片識別子URI の一部としている人も多くいました。 (単なる無知からそうしている人もいれば、そう定義するべきと考えてそうしている人もいました。) HTML 4 のように、素片識別子URI の一部としない仕様書を参照しておきながら、 (「URI参照」ではなく) 「URI」という用語を使い、 しかも素片識別子も使えるような規定が含まれる仕様も存在し、 混乱の元となっていました。

テストケース

[207] ( 版) <http://people.mozilla.org/~dholbert/dataURIHashTests/tests_v1.xhtml>

関連

[16] jar: URI scheme は、 ZIP 形式の圧縮ファイルの中のファイルを識別できます。 本来、ある資源の中に含まれる資源ですから、 素片識別子を使って表現するのが適当にも思えますが、 jar:資源の中の資源まで一つの URI 本体だけで識別できます。

(この方式を推進する人は、ある資源の中の資源の中の資源 のような入れ子の場合を素片識別子は綺麗に表現できないことを問題視しています。)

同様な URI schemezip:, tar:, pack: など多数あります。

[32] >>16 他に、素片識別子を使った表現の方法を採ると相対参照が使えなくなってしまう問題もあります。

[123] CSS などで用いられる識別子選択子は本質的に素片識別子と同じものです。

[132] HTMLusemap 属性の値は元々 URI参照であるとされていましたが、諸々の事情により、 現在は # の後に参照する map 要素name 属性の値を指定することになっています。

[151] Webブラウザで表示中の文書ナビゲーションの結果素片識別子が変更された時に発生する DOM 事象 hashchangeHTML 5 で定義されています。

[626] MRLURL を含み、その前後に追加の文字列で指定ができるものです。 MRL 自体が URL であるか否かはどちらとも明言されていません。 その MRL の中の URL の直後の部分は、 # から始まることになっています。つまり見た目は素片識別子を使うことができる URL と区別できません。

平名前素片識別子

[405] 素片識別子の全体が文書中の構造の識別子であるような素片識別子を、 平名前素片識別子と呼ぶことがあります。

[406] HTML では idの値を素片識別子として指定することで、 その要素を示すことができます。

[407] 識別子のみで識別することができる構造がある MIME型では、 平名前素片識別子をその用途に使うよう定義するべき >>391 と言われています。

[408] 平名前素片識別子は最も基本的で古くからある素片識別子の形態で、 HTMLXML など多くの言語で広く採用されています。

HTML の素片識別子

[566] HTML では、文書木中の任意の要素id 属性と、 a 要素name 属性が、 その要素を表す素片識別子の値として使えることになっています。

[616] 構文その他の制約については、それぞれの属性の項を参照。

[612] <a name>廃止され id に置き換えられましたが、 互換性のため、 Webブラウザーは両方に対応しなければなりません。

[613] 同じ識別子の要素が複数ある場合、 id 属性が優先され、 同じ属性では木順で先にある方が優先されることになっています。

[614] 互換性のため、素片識別子パーセント符号化された状態でも、 復号した状態でも、どちらでも構わないことになっています。 パーセント符号化された状態で一致するものが先に探されます。

[617] 特別な値である top は、一致する要素がない場合には、 文書の先頭を表すことになっています。

[621] HTML文書DOM木は、いつでも変異する可能性があります。 素片識別子の指すものの評価は、必要になった時点での結果となります。

[622] 素片識別子 #abc のついた URL への navigate に伴う文書構文解析の途中でスクリプトにより id=abc要素挿入される場合、 navigate の最後の素片識別子へのスクロールで、その要素が表示された状態になります。

[623] 利用者リンククリックして同じ文書#abc という素片識別子へのnavigate が発生した場合、擬似クラス :target に一致する要素は、その時点で id=abc要素となります。

[624] スクリプトは、その他の任意の方法で素片識別子を活用できます。 Webブラウザーの処理では何の意味も持ちませんが、害もありません。

[625] スクリプトは、素片識別子#edit であるとき、 当該文書の編集モードに切り替える、という処理にすることができます。 文書中に id=edit要素が存在していなくても、問題ありません。


[360] text/html では、文書文書文書の示された部分 (>>181) は次の方法で決定します >>146

  1. [361] 素片を、文書番地素片に設定します。
  2. [362] 素片空文字列なら、
    1. [565] 文書先頭 (top) を返し、ここで停止します。
  3. [602] 結果を、文書素片について find a potential indicated element した結果に設定します。
  4. [603] 結果null 以外の場合、
    1. [604] 結果を返し、ここで停止します。
  5. [363] 復号素片を、素片文字列パーセント復号し、 utf-8 decode without BOM を適用した結果に設定します。
  6. [605] 結果を、文書復号素片について find a potential indicated element した結果に設定します。
  7. [606] 結果null 以外の場合、
    1. [607] 結果を返し、ここで停止します。
  8. [365] 復号素片ASCII大文字・小文字不区別top の場合、
    1. [569]文書先頭 (top) 」を返し、ここで停止します。
  9. [366] null を返します。
[608] 要素、「文書の先頭」、null のいずれかが返されます。

[609] find a potential indicated element は、文書素片について、 次のようにします >>146

  1. [610] 文書文書木中ID素片要素が存在する場合、
    1. [567] 文書文書木中ID素片である、 木順で最初の要素を返し、ここで停止します。
  2. [364] 文書文書木中name 属性値素片a 要素が存在する場合、
    1. [568] 文書文書木中name 属性値素片である、木順で最初の a 要素を返し、 ここで停止します。
  3. [611] null を返します。
[618] 素片失敗かもしれませんが、その場合どの要素にも一致せず null が返されることになります。つまりパーセント符号化復号して正しい UTF-8 にならない場合には、何にも一致しません。

[615] 現在は HTML Standard で厳密な動作が規定されていますが、 過去には色々な仕様書でそれぞれの曖昧な挙動が説明されていました。

名前や識別子だけの素片識別子

[76] EMMA (application/emma+xml) は仕様書中に媒体型登録のための雛形がありますが、素片識別子については言及がありません。

仕様書中の例には同文書参照が頻出しますが、 同じ文書内の xs:ID属性の値を使っているようです。

[114] APEX (application/beep+xml)

[153] KML (application/vnd.google-earth.kml+xml, application/vnd.google-earth.kmz) では要素xs:ID 属性値素片識別子に使えるようです。

正式な仕様書は KML (OGC 07-147r2) の 6.4 Shared Styles9.1.3.10 kml:description12.9.3.1 kml:href、他何箇所か。 12.9.3.1 は XPointer 速記指示子を使って KML 内の要素を表せると述べています。 9.1.3.10 は escape された HTML 中のリンクについて触れていますが、 そこでは速記指示子になる前に指令部分を削ぎ落とさないといけないと規定しています。

いろいろややこしいな。

[563] TTML (application/ttml+xml) は、 素片識別子xml:id 属性を参照するものとしています >>384, >>562

[433] XSLT 1.0id 属性の用法として、 同じ文書xml-stylesheet から素片識別子によって参照できる >>432 と示しています。ただし他の XML 語彙文書への埋め込み例であり単独の MIME型での用法を示したものではありませんし、 id 属性を使う際に DTDID と宣言しなければならないことにも言及があります。

[500] GEDCOM X XML serialization format (application/x-gedcomx-v1+xml) は id 属性の値を使います >>499

[502] GEDCOM X JSON serialization format (application/x-gedcomx-v1+json) も相当する id 特性の値を使います >>501

GML・SensorML

[156] GML では gml:id 属性を指すと規定されています。

[155] SensorML は、明確な規定はありませんが、 ID 属性を指しているようです。

[157] なお、 GMLXLink を使うときの素片識別子には制約があって、 速記element()xmlns() 0個以上 + xpointer() のいずれかでなければなりません。

[255] 国土数値情報GML を埋め込んだ文書型を使っています。 XLink で同じ文書内の GML要素gml:id 値と速記により参照しています。

[584] application/gml+xml の登録には、 「gml:id を使っており、これは xs:ID である」 と述べています >>583

VRML / X3D

[67] X3D 系 (視点の名前を指定)

[547] model/v3d-vrmlIANA登録簿の登録雛形 >>546 は、素片識別子を「UTF-8 でなければならない」と(だけ)述べています。

XTM

[154] XTM 1.0 は、明確な規定はないのですが、 Note として、素片識別子だけの URI参照topic 要素id 属性値を指しているものとして使っている旨の記述があります。 (XTM 1.0 では URI参照 (に変換されるもの) は XLink 1.0 xlink:href 属性で使われています。)

WS-EventDescriptions

[216] WS-EventDescriptions (application/evd+xml) では事象記述文書 (Event Description document) 事象型 (Event Type) を指します。 これは id 属性 (xs:ID 型) の値によって識別します。 >>215

ALPS

[379] ALPS (application/alps+xml, application/alps+json) では id 属性値を参照しています >>378, >>550

明記されていないが XML ID を参照するらしいもの

[310] xml:id を参照している例が何度も出てきます。

その他の名前型素片識別子

[281] MathMLdefinitionURL では素片識別子を含む URL の構文が決められています。 (RDF などが想定されていますが、特定のデータ形式の素片識別子として定義されているわけではありません。)

Git の素片識別子

[272] Gitフロントエンドである Cogito (旧 git-pasky) は GitリポジトリーURL素片識別子としてブランチの名前を付加できました。

[274] npm >>273 (git: も参照。) や Heroku (buildpack の指定 >>374) も同様に素片識別子としてコミット的なもの (SHA-1 値、ブランチ名等) を指定できるとしています。

[381] Git 本家も同様の構文を使っています >>380

hyper-item

[596] hyper-item (application/vnd.hyper-item+json) は id の値を素片識別子として使えるとしています。

XPointer に基づく素片識別子

[321] XPointerXML素片識別子の大本命とされていましたが、 開発が混乱し完全な形の実装もほとんどありません。元々は XML の一部だったリンク機能が XLink として分離され、更に素片識別子機能が XPointer として分離されましたが、 CR の後 XPath 相当の部分の開発は凍結され、 残りの基本的な部分のみ W3C勧告となりました。実際に広く実装されているといえるのは、 その内のさらに一部、 ID による識別 (速記指示子) のみです。

詳しくは XPointer の項を参照。

RFC 3023 と分割前の XPointer

[322] text/xmlapplication/xml をはじめに定義した RFC 2376 は、素片識別子に関する規定を含んでいませんでした。

[6] RFC 2376 の改訂である RFC 3023 は、素片識別子の仕様として確立されたものはないと述べつつも、 XPointer WDtext/xmlapplication/xml素片識別子を規定していると言及しています >>323。ここで参照されているのがどの版かは明記されていませんが、 2000年6月の CR (>>324) が記述と合致します。その次の2001年1月 LCWD (>>325) 以降は、 text/xml-external-parsed-entityapplication/xml-external-parsed-entity にも適用範囲が拡大されています。

[326] application/xml-dtd には言及がありません。

[327] この通り RFC 3023 はほとんど素片識別子の規定が無い状態ですが、 RFC 3023 時代に登録された多くの XML MIME型は「RFC 3023 と同じ」 のような形の規定を含んでいます。従ってこの時代の XML MIME型の多くは、 素片識別子をどう解釈するべきか明確ではありません。

[331] 後に規定された構造化構文接尾辞素片識別子に関する要件 (>>256) によれば、素片識別子が定義されていないXML MIME型素片識別子は、 RFC 3023 に従い解釈することに (RFC 7303 出版以前は) なっていました。

[333] 分割前の XPointer 仕様書では、 XML MIME型で使われることを想定した XPointer と呼ばれる構文を定義していました。応用においては、 text/xmlapplication/xmltext/xml-external-parsed-entityapplication/xml-external-parsed-entity については完全な実装を、 それ以外の XML MIME型XPointer を採用するものについてはそれぞれで要求される水準の実装を要求していました >>332

[335] 分割前の XPointer 仕様書は、 RFC 3023 より後に出版されていますが、 これは異なる標準化団体の手続きでタイミングを揃えるのが難しいためとしつつも、 W3C会員に対して XPointer素片識別子として採用する改訂を IETF に求めるべきか否か意見を求めています >>332

[336] この少し後の時代になると W3C の仕様書で定義された言語の MIME型W3C の仕様書を出典として IANA に登録されていましたが、 この時代までは RFC を出版して登録する形になっていました。 W3CIETF で作業が分断されているのはそのためなのでしょうか。 技術的な問題ではなく、手続き的、政治的な問題で不安定な規定が長年放置されていたようにみえますが...
[334] XPointer についての詳細は、 XPointer の項を参照してください。
[328] 分割以後の XPointer 仕様の状況については、次章 (>>329) を参照してください。

[307] EmotionML (application/emotionml+xml) は RFC 3023 application/xml を参照しています >>305 が、 XPointer Framework を参照しつつ速記指示子によって id 属性 (xsd:ID) を識別できるという説明 >>306 をしています。

[308] EmotionML 文書には XML Schema への参照を含めることが義務付けられているわけでは無いようですし、 実装も XML Schema の処理が義務付けられているわけではなさそうですが、 EmotionML における id 属性xsd:ID と定義されていることにより、 (XML Schema 妥当性検証によらない応用特有の方法で) PSVI における属性の型が xsd:ID となり、schema決定IDとみなせることから速記指示子により識別できる、という解釈でいいのでしょうか...

分割後の XPointer

[329] XPointerCR まで到達した後4分割され、そのうちの3つが W3C勧告 (>>337) となりました。 残り1つの開発は凍結され、しかし完全に廃棄はされず、放置状態となっています。

詳細は XPointer の項を参照してください。

[340] 分割後の XPointer も、 text/xmlapplication/xmltext/xml-external-parsed-entityapplication/xml-external-parsed-entity素片識別子として使えることになっています。また、他の XML MIME型素片識別子を定義するための基礎としても使えるとされています。 >>337

[341] LCWD 時点では、 XPointer Framework を4つのMIME型素片識別子で対応するべき最低水準として推奨するべきかどうか意見を求めたい、 とされていました。しかし RFC 3023 の改訂で規定することになるだろうとも述べていました。 >>339 こうした記述は PR 以後削除されています。最終的な W3C勧告にも Normative Reference として RFC 3023 への参照は残っていますが、 なぜか本文中ではまったく言及がなくなっています。

[342] XPointer の開発を担当していた W3C XML Linking Working GroupXPointer 分割後の4つのうちの3つの W3C勧告が出版された後解散し、 以後 XPointerW3C XML Core Working Group の担当となっています。 RFC 3023 の改訂作業は IETF で進められ、 W3C XML Core Working Group の作業項目にも挙げられていましたが、完了までその後十年以上、 非常にゆっくりとした速度で続けられました。

[343] そんな無責任な状態で十年間も誰も困らなかったのか、 と不思議な感じもしますが、 RFC 3023XPointer が事実上世間から無視された、 実効性のない仕様書であった (から誰も困らなかった) と理解せざるを得ないでしょう。 実世界で使われているのは HTML 以来の ID による参照 (XPointer で言うところの速記指示子) だけで、それ以外は誰も使っていませんでした。 MozillaFIXptr を実装したり、数年経って誰も使わなかったので削除したりしましたが、 これらの仕様書からは離れたところでの出来事でした。真の XPointer はほとんど誰も実装しませんでした。

RFC 7303

[344] RFC 7303RFC 3023 の改訂版ですが、素片識別子としては正式に XPointer (分割後) を参照しています。

[346] RFC 7303 で定義されている MIME型素片識別子の構文と意味は、 XPointer Framework によります >>345。該当するのは text/xmlapplication/xmltext/xml-external-parsed-entityapplication/xml-external-parsed-entityapplication/xml-dtd です。ただし application/xml-dtd について XPointer Framework は言及しておらず、これをどう解釈するべきかは不明です。

[351] +xml 構造化構文接尾辞を使う MIME型を登録する際は、 素片識別子の定義に当たって RFC 7303 を参照しなければなりません >>350

[347] 適合する応用は、 XPointer Framework と、 XPointer scheme を定義する各仕様書に従って素片識別子を解釈しなければなりませんelement() XPointer scheme は対応しなければなりませんが、他の XPointer scheme に対応する義務はありません。汎用の XML MIME実体処理器は、 XPointer Registry に登録されていない XPointer scheme を実装するべきではありません>>345

[348] XPointer Framework誤りも参照してください。

[352] +xml 構造化構文接尾辞を使う MIME型の登録の際は、

SVG 素片識別子

XML 署名における XPointer

[49] XML署名や、 XML暗号化 (application/xenc+xml) は、単体の文書として存在したり、他の言語に埋め込まれたりして存在しますが、 いずれにせよ、処理対象を表すために URL素片識別子を使っています。

[536] XML署名素片識別子の処理方法を規定していますが、 MIME型は規定していません。理論上は利用する MIME型において XML署名と (つまり XPointer と) 整合する素片識別子の規定が必要ですが、 そのような言及はありません。

[535] XML暗号化 (application/xenc+xml) の仕様書やその中の登録雛形には素片識別子に関する明確な規定がありませんが、 XML署名の仕様の処理モデルに従うようです。

[235] XML署名1.0 では素片識別子XPointer CR とされています >>49

[237] XML署名1.1 では素片識別子XPointer 勧告 (および xpointer() WD) を参照しており、 xpointer()非推奨 (discouraged) とされています >>286

[267] XML署名 2.0では素片識別子ID を表すものとされており、 xpointer() は認められていません >>268, >>532。ただし互換モードでは、 従前の例に倣って処理されます >>531

[537] 両仕様における URL素片識別子は、外部からの参照を目的としたものではなく、 同じ文書内の処理対象を識別することを目的としたものです。ネットワークアクセスを伴わない処理では、 (元の URL 仕様の想定とは異なるとはいえ) MIME型に紐付かない定義と処理も頷けますし、 むしろ MIME型によって識別されるものが違ってしまうのでは処理も複雑になりそうです。 XML署名 2.0 ではこの辺りの規定と理論上の整合性を整理しようとした痕跡が見られ、 同文書参照ではXML署名の規定に従い XPointer として処理し、 そうでない URL素片識別子は取得した資源MIME型により処理するよう求めています。

[450] その他XML署名を使う仕様もXML署名の規定にそった素片識別子の利用を明記していることがあります >>449

XML署名以外での素片識別子の利用は明記していなかったりします。

XFrames 素片識別子

[38] XFramesXPointer scheme に似た構文の frames() を規定しています。ただし XPointer であるとは書かれていません。

[39] 単純な XFrames素片識別子は単純な XPointerframes() scheme を使ったものと互換性がある、と言える程度ではあります。 ただし現時点で W3CXPointer scheme 登録簿に frames() はありません。

Web Annotation

[591] Web AnnotationXPointer scheme のようにも見える (と仕様書にも書いてあるが具体的な構文の規定が無い) 独自の selector() 構文を用意しています。

selector() 参照。

XPointer の速記指示子

[435] COLLADAXPointer速記指示子のみを使っています >>434

[552] application/rfc+xmlanchor 属性値XPointer 速記指示子として使っています >>551, >>581

その他の XPointer 系素片識別子

「RFC 3023 またはその改訂版」を参照

SML の素片識別子

[170] SML 1.1SML URI Reference Scheme では、素片識別子速記指示子または smlxpath1() XPointer scheme のいずれかが利用できることになっています。

ElementPointer

[442] ElementPointer は、動画などを含む「任意のコンテンツ」 を対象として、 XPointer 風の構文を定義しています。 (構文としては XPointer scheme の形を取っていますが、独自の素片識別子構文としています。)

MPEG の素片識別子

[188] ISO/IEC 21000-17MP3MP4 のための素片識別子を規定しています。 これは実質的には XPointerプロファイルですが、 XPointer を引用しつつも独自に定義しています。

EPUB CFI

[234] EPUBCFI と呼ばれる XPointer ベースの独自の構文を素片識別子として採用しています。

XTM 2.0 素片識別子

[436] XTM 2.0 (ISO 13250-3) は、 素片識別子の意味を明確に規定しているわけではないのですが、 その topic 要素 >>437topicRef 要素 >>438 の規定より、次のように解釈できます。

[439] XTM 2.0 文書素片識別子は、百分率符号化を解いて UTF-8 文字列として解釈した時、

  1. [440] id が一致する topic があれば、その (名前の) 話題を指します
  2. [441] なければ、その名前話題を指します

[316] 構文的には、素片識別子を解いた文字列XPointer 速記指示子でなければなりません >>438

XPath

[593] OracleXDBURIType は、XML文書素片識別子XPath (XPointer ではないただの XPath) を採用しています >>276

メモ

[107] Re: XPointer considered incomprehensible from Bjoern Hoehrmann on 2006-09-05 (www-tag@w3.org from September 2006) <http://lists.w3.org/Archives/Public/www-tag/2006Sep/0019.html> (名無しさん 2006-09-07 23:21:03 +00:00)

*/*+xml 媒体型素片識別子の定義の実態を調査した報告です。

[130] Numbers as anchors (Henry S. Thompson 著, 2008-02-15 02:28:33 +09:00 版) <http://lists.w3.org/Archives/Public/public-xml-core-wg/2008Feb/0026.html>

数値からはじまる素片識別子XML では定義できないことが問題提起されています。

この問題は、連番や日付を使いたいときによく遭遇します。

[283] OMDoc では XPointer が使えるようです。

引数構文の素片識別子

[9] いくつかの MIME型では name=value;name=value のような形式が採用されています。

PDF

[31] application/pdf でも param 型構文で命令を指定できます。

詳しくは application/pdf 参照。

版番号指定

[491] Microsoft番号の指定に素片識別子を使っています。

[15] CABファイルDLLファイルOCXファイルで版を指定できます >>493

CODEBASE="http://example.microsoft.com/mydir/polygon.dll#version=1,0,0,1"
CODEBASE="http://example.microsoft.com/mydir/polygon.cab#version=1,0,0,1"

媒体素片 URL

[245] W3C媒体素片作業部会 (Media Fragments Working Group) による媒体素片URL (Media Fragments URL) 仕様は、 画像音声動画の一部を識別する素片識別子の構文を規定しています。ただし、 (URL 全般の原則に従い、) 実際にその規定を適用するためには当該 MIME型の仕様から本仕様を参照しないといけないことになっています。

[248] この仕様の策定の過程で既存のMIME型素片識別子の調査が行われています。それによると、 MIME型の登録で素片識別子を定義しているものはなく、(仕様上は) 本仕様と衝突するおそれはないとされています。

ただし、この調査自体では当時知られていた audio/mpeg 等の素片識別子の定義 (MIME型の登録には含まれておらず ISO の仕様で規定されている。) を検出できていません。 また、当時未登録とはいえ同じ W3C 内の image/svg+xmlSVG素片識別子が定義されていますし、 WebCGM (image/cgm) にも素片識別子がありますが、これらはまったく言及もされていません。 既存のMIME型の調査としてはとても杜撰と言わざるを得ません。 (MIME型の登録自体に素片識別子の定義が言及されていることを期待しているようですが、 URIRFC は別にそれを要求していません。)

[423] 媒体素片は、 HTML媒体要素において様々な動画音声のデータに対して用いられています。

媒体素片参照。

[126] >>127媒体素片の元となった仕様で、素片識別子に関してはほぼ同じものが規定されています。 媒体素片W3C勧告で削除された機能の分、こちらの方がより大きな仕様となっています。 (しかしメンテナンスはされていないようです。)

[424] >>127HTTP のみならず、 rtsp: URLRTSP/1.0 での素片識別子の利用方法も規定しています。

[454] MPEG DASH (application/dash+xml) は、 媒体素片の拡張である MPD Anchor素片識別子として使っています。

MPD Anchor 参照。

Markdown

[386] Markdown (text/markdown) の RFCHTMLtext/plainCSV素片識別子をもとに独自の素片識別子の規定を設けています。

text/markdown 参照。

OAuth 2.0

[428] OAuth 2.0application/x-www-form-urlencoded素片識別子による引数の記述の構文に採用しています。

[429] 普通、これはHTML文書に埋め込まれた JavaScript 等により処理されます。

pip

[443] pipGitSubversion など VCSURL scheme を独自に規定していますが、素片識別子については

git+https://git.repo/some_repo.git#egg=subdir&subdirectory=subdir_path
... のような構文を使っています。

[445] ドキュメント >>444 には次のような説明があります。

The “project name” component of the url suffix “egg=<project name>-<version>” is used by pip in its dependency logic to identify the project prior to pip downloading and analyzing the metadata. The optional “version” component of the egg name is not functionally important. It merely provides a human-readable clue as to what version is in use.

[446] なお Git の標準的な方法 (>>272) とは互換性がありません。 コミットやブランチの指定には素片識別子ではなく、独自の @ 構文を採用しています。 (VCSのURL参照。)

[451] https://pypi.python.org/packages/source/s/six/six-1.9.0.tar.gz#md5=476881ef4012262dfc8adc645ee786c4 のように MD5 要約値を指定するためにも素片識別子を使っています。

XLIFF 素片識別子

[600] XLIFFXML文書ですが、 XPointer とは異なる独自の素片識別子構文を規定しています。

OData 素片識別子

[377] OData ではメタデータ文書 (application/xml) の一部を表す素片識別子 >>376 が規定されています。

Blorb 素片識別子

[111] Suggested Interactive Fiction Mediatypes <http://purl.org/int-fiction/ifmi/documents/mediatypes>

Blorb (application/prs.blorb, */*+blorb) の素片識別子として、 #Pict(n)#Fspc のようなものを提案しています。

また、関連して、 TADS 3 (application/prs.t3vm.image) の素片識別子として #mres(path) を提案してます。

ファイル名の素片識別子

[580] PHP が実装する rar: URL では、RAR 内のファイル名素片識別子として使えることになっています。

rar: 参照。

プログラムコードの素片識別子

変数名

[292] JsonT ファイルの素片識別子として、 JavaScript 変数名が用いられることがあります >>291

関数呼び出し型素片識別子

プログラム片

Android Intents

[266] intent: URL scheme では Androidインテントを表す素片識別子の構文が定義されています。

Microsoft PE

[477] Microsoft PE (application/vnd.microsoft.portable-executable) では、外部に晒されているデータの名前や番地を素片識別子として使うことができます。

[489] >>453, >>490 では DLLファイルで同様な素片識別子が使われています。

>>453

<object id="myCtl" 
  classid="http://www.mycode.Microsoft.com/mycode.dll#myClass"> 
</object>

>>490

<OBJECT id="ctrl" classid="YourDllName.dll#ActiveXSourcing.MyWindowControl">

>>491 も参照。

JSON Pointer

[252] JSON Pointer素片識別子としての利用が想定されています。

[330] ただしなぜか application/json の定義は更新されていません。 この後 RFC 7159 が発行されていますが、やはり何の言及もありません。

[549] 次の MIME型RFC 6901素片識別子として採用しています >>548

数値型素片識別子

[481] azur は、 #.18642-18898 のような素片識別子HTML文書中の表示上の文字数指定による選択範囲を表すようです。

ブックマークも参照。

バージョン番号素片識別子

[464] bower は次の通りバージョンやバージョンの範囲の指定を素片識別子により行っています >>465

semver version#1.2.3
version range#1.2, #~1.2.3, #^1.2.3, #>=1.2.3 <2.0
Git tag#<tag>
Git commit SHA#<sha>
Git branch#<branch>
Subversion revision#<revision>
[466] Git素片識別子 (>>272) も含まれています。
[492] >>491 も参照。

ハッシュ値素片識別子

[455] OpenID Connect は、 JWT素片識別子をその資源の内容の SHA-256 ハッシュ値base64url 符号化したものとすることを求めています >>456, >>460

[457] 現時点 (draft-ietf-oauth-json-web-token-32RFC 7519) で JWT 側に素片識別子の規定はなく、 OpenID Connect 独自のものとみられます。

フォント

[277] font collection に含まれるフォントを識別する素片識別子として、 文字列を記述して名前で選択する方式と、 数値を記述して順序で選択する方式があります。

RDF 系素片識別子

[13] RDF 1.0>>97 のような事情から、 RDF URI参照における素片識別子application/rdf+xml表現のものである、 などといった辻褄あわせともいえる規定を持っています。

[147] RDF具象構文の1つ、 N3 は、 RDF を直接参照せず、このように素片識別子を規定しています。

[303] RDF 1.1 は、なぜか参考として、 RDF における素片識別子は、RDFグラフ中でその素片識別子つき URL によって表されるものを意味する >>302 としています。

[304] RDFグラフが他の文書に埋め込まれる時はその埋め込み先、内容折衝される時には他の表現素片識別子の意味とも整合する使い方をするべきである >>302 ともされています。

[496] JSON-LD (application/ld+json) は、 RDF 1.1 と同じと規定しています >>495

[498] 以前の仕様案では比較的 (現在より少しは) 正確な規定がありましたが >>497、 なぜかその後 RDF に一任する形の曖昧性が増した形に改訂されています。

含まれている内容に依存する素片識別子

[211] multipart/x-mixed-replace素片識別子は、 含まれている本体部分それぞれに、それぞれのMIME型に従い適用されます。

素片識別子は未定義と明記されている MIME 型

[105] 素片識別子を定義している媒体型はほんの一握りで、 IANA に登録されているほとんどの媒体型の仕様では素片識別子は言及すらされていません。 しかし、一部の媒体型に関しては、「素片識別子は未定義」 の旨が明確に規定されています。

未定義

N/A

JSON と同じ

意味を持たない

URL scheme の規定で未定義とされているもの

特別な値

[368] HTML文書では、 #top は、 (他に一致する要素がなければ) 「文書の先頭」を表します。

#top を参照。

[422] #! から始まる素片識別子に特別な意味を与える実装もあります。

#! 参照。

URL scheme 依存のデータを構成する素片識別子

[95] RFC 3986/RFC 3987 の定義に従えば、 URI 中の文字 #素片識別子のはじまりを表します。これは URI scheme によらず、 すべての URI に適用されます。

[62] ですが、現実には、URI の中で使われる文字 #素片識別子の始まりとして扱われないことがあります (もちろん仕様違反です)。

[63] Vodafone の独自 HTML 仕様では、 tel: URI scheme および vtel: URI scheme電話# ボタンの意味で生の # を使います。

[133] irc: URI schemeは、 IRCチャンネル名#が使われるのをそのままURIで用いることがあり、 標準化案 (Internet Draft) もそれを容認し、さらに拡張しようとしていました。

[134] Webブラウザの実装では data:, javascript:, mailto: のような URL scheme#素片識別子のはじまりとして扱われないことがあります。

[558] file: URL の実装によっては、 #ファイル名の一部と扱うことがあります。

メモ

[59] XML Schema Datatypes in RDF and OWL <http://www.w3.org/TR/2005/WD-swbp-xsch-datatypes-20050427/#sec-user-defined-problem>

XML Schema で定義されたデータ型をどういう URI (素片識別子) で識別するべきかという議論があります。

[121] Fragment Search (2007-02-10 03:37:54 +09:00 版) <http://www.gerv.net/software/fragment-search/> (名無しさん 2007-02-14 22:56:14 +00:00)

Fragment Search is a Greasemonkey script which allows people to create URLs which link to content within a page without having control over that page.

So, for example, http://www.gerv.net/#!s!design searches for the word "design" on the front page of this site. "#" starts the fragment identifier, "!" is the special character so it's obvious it's not a normal fragment identifier, "s" stands for search (there are several other things we want to do with the fragment identifier, like link fingerprints, so we need to keep them all separate) and the second "!" separates the command name from the instruction - i.e. what to search for, in this case "design".

[160] 秋元@サイボウズラボ・プログラマー・ブログ: ブラウザのアドレスバーに動くアスキーアートを組み込む ( 版) <http://labs.cybozu.co.jp/blog/akky/archives/2009/01/ascii-art-animation-on-browser-addressbar.html>

[168] Usage Patterns For Client-Side URI parameters ( 版) <http://www.w3.org/TR/2009/WD-hash-in-uri-20090415/>

[169] Use cases and requirements for Media Fragments ( 版) <http://www.w3.org/TR/2009/WD-media-frags-reqs-20090430/>

[173] auでLocatiuonヘッダにフラグメント識別子を入れた場合の挙動 - maru.cc@はてな ( 版) <http://d.hatena.ne.jp/maru_cc/20080208/1202436438>

[174] XForms 1.1 ( 版) <http://www.w3.org/TR/2009/REC-xforms-20091020/#def-schema-applicable>

[175] (X)HTML5 Tracking ( 版) <http://html5.org/tools/web-apps-tracker?from=4402&to=4403>

[176] Media Fragments URI 1.0 ( 版) <http://www.w3.org/TR/2010/WD-media-frags-20100413/>

[182] IRC logs: freenode / #whatwg / 20100525 ( 版) <http://krijnhoetmer.nl/irc-logs/whatwg/20100525>

[183] Media Fragments URI 1.0 ( 版) <http://www.w3.org/TR/2010/WD-media-frags-20100624/>

[184] Getting Started - Making AJAX Applications Crawlable - Google Code ( ( 版)) <http://code.google.com/intl/ja/web/ajaxcrawling/docs/getting-started.html>

[187] Repurposing the Hash Sign for the New Web ( ( 版)) <http://www.w3.org/2001/tag/2011/01/HashInURI-20110115>

[190] Tagneto: Cross Domain Frame Communication with Fragment Identifiers (for Comet?) ( ( 版)) <http://tagneto.blogspot.com/2006/06/cross-domain-frame-communication-with.html>

[191] Media Fragments URI 1.0 ( ( 版)) <http://www.w3.org/TR/2011/WD-media-frags-20110317/>

[192] MediaTypeReview - Media Fragments Working Group Wiki ( ( 版)) <http://www.w3.org/2008/WebVideo/Fragments/wiki/MediaTypeReview>

[193] RFC 5122 - Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP) ( ( 版)) <http://tools.ietf.org/html/rfc5122#section-2.6>

[196] draft-hoehrmann-javascript-scheme-03 - The \x27javascript\x27 resource identifier scheme ( ( 版)) <http://tools.ietf.org/html/draft-hoehrmann-javascript-scheme-03#section-4>

[206] Web Applications 1.0 r6519 Allow frag IDs to be used by scripts rather than having them point to IDs only. ( ( 版)) <http://html5.org/tools/web-apps-tracker?from=6518&to=6519>

[213] Media Fragments URI 1.0 ( ( 版)) <http://www.w3.org/TR/2011/CR-media-frags-20111201/>

[214] Protocol for Media Fragments 1.0 Resolution in HTTP ( ( 版)) <http://www.w3.org/TR/2011/WD-media-frags-recipes-20111201/>

[217] Identifying Application State ( ( 版)) <http://www.w3.org/2001/tag/doc/IdentifyingApplicationState>

[218] mozdev.org - mdhashtool: lfinfo ( 版) <http://mdhashtool.mozdev.org/lfinfo.html>

[220] Media Fragments URI 1.0 (basic) ( ( 版)) <http://www.w3.org/TR/2012/PR-media-frags-20120315/>

[221] TAG Product: Fragment Identifiers and Mime Types ( ( 版)) <http://www.w3.org/2001/tag/products/fragids.html>

[222] Best Practices for Fragment Identifiers and Media Type Definitions ( ( 版)) <http://www.w3.org/2001/tag/doc/mimeTypesAndFragids.html>

[223] Session on mime types and fragids ( (Jeni Tennison 著, 版)) <http://lists.w3.org/Archives/Public/www-tag/2011May/0089.html>

[224] Web Application Description Language ( ( 版)) <http://www.w3.org/Submission/2009/SUBM-wadl-20090831/#x3-60002.1>

[225] Best Practices for Fragment Identifiers and Media Type Definitions ( ( 版)) <http://www.w3.org/TR/2012/WD-fragid-best-practices-20120726/>

[226] The SMIL 3.0 Linking Modules ( 版) <http://www.w3.org/TR/2008/REC-SMIL3-20081201/smil-extended-linking.html#SMILLinking-Fragment>

[231] Media Fragments URI 1.0 (basic) ( 版) <http://www.w3.org/TR/2012/REC-media-frags-20120925/#standardisation-terminology>

URI fragment: The fragment component is indicated by the presence of a number sign ("#") character and terminated by the end of the URI.

[232] Best Practices for Fragment Identifiers and Media Type Definitions ( ( 版)) <http://www.w3.org/TR/2012/WD-fragid-best-practices-20121025/>

[238] IRC logs: freenode / #whatwg / 20130424 ( ( 版)) <http://krijnhoetmer.nl/irc-logs/whatwg/20130424>

[242] Bug 100841 – Allow CSS selectors as fragment identifiers ( ( 版)) <https://bugs.webkit.org/show_bug.cgi?id=100841>

[243] Floating Quotable Citations (FQC) ( (David Cuenca 著, 版)) <http://lists.w3.org/Archives/Public/public-cssselfrags/2013Feb/0000.html>

[249] zip fragments ( ( 版)) <https://gist.github.com/annevk/6295844>

[250] IRC logs: freenode / #whatwg / 20130822 ( ( 版)) <http://krijnhoetmer.nl/irc-logs/whatwg/20130822>

[269] 905766 – Allow XPaths, RegExps and CSS selectors as fragment identifiers in URLs ( ( 版)) <https://bugzilla.mozilla.org/show_bug.cgi?id=905766>

[275] Web Applications 1.0 r8323 Make the fragment identifier handling rules match browsers better ( ( 版)) <http://html5.org/tools/web-apps-tracker?from=8322&to=8323>

[284] Metadata API for Media Resources 1.0 ( ( 版)) <http://www.w3.org/TR/mediaont-api-1.0/#widl-MediaAnnotation-fragmentIdentifier>

[288] chapmanu/fragmentions ( ( 版)) <https://github.com/chapmanu/fragmentions>

[289] [charter] Addressable Ranges? ( (Doug Schepers 著, 版)) <http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0180.html>

[290] IRC logs: freenode / #whatwg / 20140419 ( ( 版)) <http://krijnhoetmer.nl/irc-logs/whatwg/20140419#l-70>

[293] ( ( 版)) <http://zesty.ca/crit/draft-yee-url-textsearch-00.txt>

[294] fragmention - IndieWebCamp ( ( 版)) <http://indiewebcamp.com/fragmention>

[295] mozdev.org - liveurls: tech ( ( 版)) <http://liveurls.mozdev.org/tech.html>

[296] minitage.recipe.egg 1.41 : Python Package Index ( ( 版)) <https://pypi.python.org/pypi/minitage.recipe.egg/1.41#pypi-md5-check-support>

[300] IRC logs: freenode / #whatwg / 20140424 ( ( 版)) <http://krijnhoetmer.nl/irc-logs/whatwg/20140424>

[314] ( ( 版)) <http://www16.ocn.ne.jp/~sanbou/li1.html>
 <A HREF="index.html#最初の入り口に戻ります" TARGET="_parent"><IMG SRC="sozai/to1.gif" ALT="最初の入り口に行きます。" ALIGN=BOTTOM></A><BR>
 <A HREF="r1/in02.htm#もっきりやトイレ風呂等を紹介します。" TARGET="r1"><IMG SRC="sozai/to2.gif" ALT="トイレや風呂等の写真があります。" ALIGN=BOTTOM></A><BR>
 <A HREF="r1/in03.htm#料金やお願い等を書いてあります。" TARGET="r1"><IMG SRC="sozai/to3.gif" ALT="料金、お願い等書いてあります。" ALIGN=BOTTOM></A><BR>
リンクに対する注釈として素片識別子が用いられているようです。 (リンク先に該当するアンカーはありません。)

[371] Protocol for Media Fragments 1.0 Resolution in HTTP ( ( 版)) <http://www.w3.org/TR/media-frags-recipes/>

[373] Bug 23492 – Linking to a page with a fragment identifier that causes a particular media element to be shown and to seek to a particular position ( ( 版)) <https://www.w3.org/Bugs/Public/show_bug.cgi?id=23492>

[375] Bug 26988 – We need a way to parse URLs without decoding the fragment identifier ( ( 版)) <https://www.w3.org/Bugs/Public/show_bug.cgi?id=26988>

[383] Annoshape ( ( 版)) <http://shepazu.github.io/annoshape/annoshape.html>

[463] returnurl - Facebook Callback appends '#_=_' to Return URL - Stack Overflow ( 版) <http://stackoverflow.com/questions/7131909/facebook-callback-appends-to-return-url>

[530] URLの#(シャープ)から後の部分の名称=「ハッシュ」「フラグメント」「ページ内リンクアンカー」と,SEO対策上の重要性 - プログラミングとIT技術をコツコツ勉強するブログ ( 版) <http://d.hatena.ne.jp/TipsMemo+computer-technology/20141230/p1>

URLのハッシュには,呼び方がいくつかある。

[553] Use utf-8 decode without BOM rather than UTF-8 decoder · whatwg/html@39a2e6c ( 版) <https://github.com/whatwg/html/commit/39a2e6cde3b4820db56fabe1859de0dc0e6ed8d9>

[554] Let the URL Standard deal with application/x-www-form-urlencoded · whatwg/html@0fef169 ( 版) <https://github.com/whatwg/html/commit/0fef169e6fca7433e3aac2a3640b4665b791ff8e>

[555] Align with URL spec's terminology: "fragment identifier" => "fragment" · whatwg/html@472bd07 ( 版) <https://github.com/whatwg/html/commit/472bd07726db580b97b9d775996e9d895cda8be0>

[571] Fragments can only point to nodes in documents ( (annevk著, )) <https://github.com/whatwg/html/commit/fc90400dfd72fd99072668248161c90c993014bc>

[572] Make :target definition sticky based on last scroll-to-fragment ( (domenic著, )) <https://github.com/whatwg/html/commit/1488bb6f765e41558bb221dc247012a35d88527b>

[576] ページ単位の広告の設定方法 - AdSense ヘルプ () <https://support.google.com/adsense/answer/6245305?hl=ja&ref_topic=1307438>

(オプション)プレビュー ツールでページ単位の広告のテストを実施します。

ページ単位の広告は最適なタイミングでのみサイトに表示されるため、プレビュー ツールを使って広告が正しく配信されることを確認する必要があります。

ページ単位の広告のテストを実施するページにモバイル デバイスでアクセスします。

モバイル ブラウザのアドレスバーの URL 末尾に #googleads という文字列を追加します(例: www.example.com#googleads)。

テストを実施する広告のフォーマットを選択します。

テスト結果をデバイスで確認します。

[577] Editorial: give URL syntax components their own terms (annevk著, ) <https://github.com/whatwg/url/commit/451696e4297c4c676fae21dbc926aeafb2477e6c>

[578] Percent encode fragments too (annevk著, ) <https://github.com/whatwg/url/commit/373dbedbbf0596f723ce8a195923da98b698aeb0>

[579] Percent encode fragments too (annevk著, ) <https://github.com/whatwg/url/commit/373dbedbbf0596f723ce8a195923da98b698aeb0>

[582] 芸名に句読点が含まれる芸能人の一覧 - Wikipedia () <https://ja.wikipedia.org/wiki/%E8%8A%B8%E5%90%8D%E3%81%AB%E5%8F%A5%E8%AA%AD%E7%82%B9%E3%81%8C%E5%90%AB%E3%81%BE%E3%82%8C%E3%82%8B%E8%8A%B8%E8%83%BD%E4%BA%BA%E3%81%AE%E4%B8%80%E8%A6%A7>

[587] Web Annotation Vocabulary () <https://w3c.github.io/web-annotation/vocab/wd/#h-fragmentselector>

[588] Embedding Web Annotations in HTML () <https://w3c.github.io/web-annotation/serialization-html-note/#embed-json-ld>

While an HTML <script> node may itself have an id attribute, implementers are discouraged from using an HTML URL with fragment identifier to identify an annotation. An HTML fragment identifier is only intended to indicate and help navigate to a specific DOM node in an HTML document (see HTML5 Recommendation [html5] Section 5.6.9, "Navigating to a fragment identifier"). A fragment identifier does not unambiguously identify the contents of this node as a separate resource.

[589] Wikipedia だと「独自研究」って注記が付きそうですけど、 W3C WG Note にはさも事実かのようにこんな適当なことが書けるようです。 こんなわけのわからない理屈がまかり通るなら、「IRI利用者エージェントの取得操作のためだけのもので、 資源表現を独立した資源として曖昧なく識別するものではない」 ってことになりますよね (書いててわけがわからない)。

[590] Selectors and States () <https://w3c.github.io/web-annotation/selector-note/#h-fragmentselector_def>

Instance

An element of a group of Resources represented by a particular Class.

[594] Linked Data Notifications () <https://linkedresearch.org/ldn/#test-consumer-header-discovery>

Senders and consumers should omit the Link header discovery when specifically targeting URIs with fragment identifiers.

[595] RFC 8141 - Uniform Resource Names (URNs) () <https://tools.ietf.org/html/rfc8141#section-2.3.3>

[601] Fix scrolling to fragments (annevk著, ) <https://github.com/whatwg/html/commit/c230f55027b070f7a663efc3bc360316168e30bb>

[619] Interoperability of 'The indicated part of the document' for HTML documents · Issue #2902 · whatwg/html () <https://github.com/whatwg/html/issues/2902>

[620] Fix scrolling to fragments by annevk · Pull Request #2901 · whatwg/html () <https://github.com/whatwg/html/pull/2901>

[627] Percent-encode additional characters in "fragment state" (mikewest著, ) <https://github.com/whatwg/url/commit/7a3c69f8a1583b33e730c3fea85141a618e7c697>

[629] Percent-encode additional characters in "fragment state" (mikewest著, ) <https://github.com/whatwg/url/commit/7a3c69f8a1583b33e730c3fea85141a618e7c697>

[630] Consider percent-encoding more characters in "fragment state" · Issue #344 · whatwg/url () <https://github.com/whatwg/url/issues/344>

[631] Percent-encode additional characters in "fragment state". by mikewest · Pull Request #347 · whatwg/url () <https://github.com/whatwg/url/pull/347>

[632] bryanmcquade/scroll-to-css-selector: Explainer for supporting CSS selectors when navigating to a URL fragment () <https://github.com/bryanmcquade/scroll-to-css-selector>

[633] () <http://zesty.ca/crit/draft-yee-url-textsearch-00.txt>

[634] fragmention - IndieWeb () <https://indieweb.org/fragmention>

[635] Do not use percent decode on strings (annevk著, ) <https://github.com/whatwg/html/commit/ce8404fa5d8c2c91725c5262fd69d0d45c227ec8>

[636] Do not use percent decode on strings by annevk · Pull Request #3111 · whatwg/html () <https://github.com/whatwg/html/pull/3111>

[637] import.meta.url needs its fragment censored · Issue #3622 · whatwg/html () <https://github.com/whatwg/html/issues/3622>