文書中の示された部分

Edit New

素片識別子 (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] >>388 は fragid と呼んでいます。

[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構文解析器は、素片識別子を正準形に変換します。 この時パーセント符号化では素片パーセント符号化集合が使われます。

[649] 一般の URL の素片識別子の構文には、これ以上の制約はなく、 構造はありません。

[650] 素片識別子が使われる場面によっては、その文脈に依存した追加的な制約が定められていることがあります。

[651] XML文書の URL では XPointer が使われることがありました。 その場合は XPointer 仕様書の規定する制約が適用されました。

文脈

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

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

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

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

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

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

構文解析

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

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

[506] U+0000、U+0009、U+000A、U+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。

[655] corbaname: ではオブジェクト名の記述に使われます。

文書形式と素片識別子

素片識別子と 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] IETF は MIME型によって素片識別子の解釈が決まると言っていますが、 実際には MIME型そのものによらないで決まる場合もあります。

構造化構文と素片識別子

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

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

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

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

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

ID も参照。

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

同文書参照も参照。

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

[52] HTTP や MIME での利用を想定していない (他のプロトコルを使う、プロトコルで転送せずメモリー上のみ存在するなど。)、 マーク付け言語の汎用の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 ブラウザにおける何らかの処理の過程においてこの文書のある要素の ID が id と設定されたとします。すると 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] スクリプトによる状態保存に使う用法は元々 name や id を表すものとして用意された 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ブラウザ (例: WinIE や Mozilla (Gecko)) と、 最後を表示する Webブラウザ (例: Classic Mozilla) があります。

素片識別子とプロトコル

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

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

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

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

この方式は2011年頃に流行しましたが、その後あまり見かけなくなりました。 スクリプトで生成する内容とサーバーが生成する内容との対応関係を維持したいとき、 現在では Pjax (pushState) により path や query を使うのが一般的になっていますから、そのために素片識別子と 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 全体を未読かどうかの判定に用いています。

例えば、 Firefox は URL 全体からリンク先が未読か既読かを判定し、 :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」という用語を使い、 しかも素片識別子も使えるような規定が含まれる仕様も存在し、 混乱の元となっていました。

[643] Fragment Identifiers -- Axioms of Web architecture, , https://www.w3.org/DesignIssues/Fragment.html

テストケース

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

関連

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

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

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

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

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

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

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

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

平名前素片識別子

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

平名前素片識別子参照。

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

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

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

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 リファレンス ( 版) http://earth.google.co.jp/kml/kml_tags_21.html#styleurl

正式な仕様書は KML (OGC 07-147r2) の 6.4 Shared Styles、 9.1.3.10 kml:description、 12.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.0 は id 属性の用法として、 同じ文書の xml-stylesheet から素片識別子によって参照できる >>432 と示しています。ただし他の XML 語彙の文書への埋め込み例であり単独の MIME型での用法を示したものではありませんし、 id 属性を使う際に DTD で ID 型と宣言しなければならないことにも言及があります。

[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] なお、 GML で XLink を使うときの素片識別子には制約があって、 速記、 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-vrml の IANA登録簿の登録雛形 >>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] MathML の definitionURL では素片識別子を含む 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] XPointer は XML の素片識別子の大本命とされていましたが、 開発が混乱し完全な形の実装もほとんどありません。元々は XML の一部だったリンク機能が XLink として分離され、更に素片識別子機能が XPointer として分離されましたが、 CR の後 XPath 相当の部分の開発は凍結され、 残りの基本的な部分のみ W3C勧告となりました。実際に広く実装されているといえるのは、 その内のさらに一部、 ID による識別 (速記指示子) のみです。

詳しくは XPointer の項を参照。

RFC 3023 と分割前の XPointer

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

[6] RFC 2376 の改訂である RFC 3023 は、素片識別子の仕様として確立されたものはないと述べつつも、 XPointer WD が text/xml と application/xml の素片識別子を規定していると言及しています >>323。ここで参照されているのがどの版かは明記されていませんが、 2000年6月の CR (>>324) が記述と合致します。その次の2001年1月 LCWD (>>325) 以降は、 text/xml-external-parsed-entity と application/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/xml、application/xml、 text/xml-external-parsed-entity、 application/xml-external-parsed-entity については完全な実装を、 それ以外の XML MIME型で XPointer を採用するものについてはそれぞれで要求される水準の実装を要求していました >>332。

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

[336] この少し後の時代になると W3C の仕様書で定義された言語の MIME型は W3C の仕様書を出典として IANA に登録されていましたが、 この時代までは RFC を出版して登録する形になっていました。 W3C と IETF で作業が分断されているのはそのためなのでしょうか。 技術的な問題ではなく、手続き的、政治的な問題で不安定な規定が長年放置されていたようにみえますが...
[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] XPointer は CR まで到達した後4分割され、そのうちの3つが W3C勧告 (>>337) となりました。 残り1つの開発は凍結され、しかし完全に廃棄はされず、放置状態となっています。

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

[340] 分割後の XPointer も、 text/xml、 application/xml、 text/xml-external-parsed-entity、 application/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 Group は XPointer 分割後の4つのうちの3つの W3C勧告が出版された後解散し、 以後 XPointer は W3C XML Core Working Group の担当となっています。 RFC 3023 の改訂作業は IETF で進められ、 W3C XML Core Working Group の作業項目にも挙げられていましたが、完了までその後十年以上、 非常にゆっくりとした速度で続けられました。

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

RFC 7303

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

[346] RFC 7303 で定義されている MIME型の素片識別子の構文と意味は、 XPointer Framework によります >>345。該当するのは text/xml、application/xml、 text/xml-external-parsed-entity、 application/xml-external-parsed-entity、 application/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署名以外での素片識別子の利用は明記していなかったりします。

[644] RFC 3075 - XML-Signature Syntax and Processing, , https://tools.ietf.org/html/rfc3075#section-4.3.3.3

XFrames 素片識別子

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

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

Web Annotation

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

selector() 参照。

XPointer の速記指示子

[435] COLLADA は XPointer の速記指示子のみを使っています >>434。

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

その他の XPointer 系素片識別子

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

SML の素片識別子

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

Service Modeling Language, Version 1.1 ( 版) http://www.w3.org/TR/2009/REC-sml-20090512/#URI_Reference_Scheme

ElementPointer

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

MPEG の素片識別子

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

EPUB CFI

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

XTM 2.0 素片識別子

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

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

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

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

XPath

[593] Oracle の XDBURIType は、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+xml でSVG素片識別子が定義されていますし、 WebCGM (image/cgm) にも素片識別子がありますが、これらはまったく言及もされていません。 既存のMIME型の調査としてはとても杜撰と言わざるを得ません。 (MIME型の登録自体に素片識別子の定義が言及されていることを期待しているようですが、 URI の RFC は別にそれを要求していません。)

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

媒体素片参照。

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

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

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

MPD Anchor 参照。

Markdown

[386] Markdown (text/markdown) の RFC は HTML、text/plain、CSV の素片識別子をもとに独自の素片識別子の規定を設けています。

text/markdown 参照。

OAuth 2.0

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

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

認可エンドポイントを参照。

pip

[443] pip は Git や Subversion など VCS の URL 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] XLIFF は XML文書ですが、 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-32 → RFC 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 に一任する形の曖昧性が増した形に改訂されています。

[647] Systems Biology Markup Language (SBML) Level 3Core - sbml-level-3-version-2-release-2-core.pdf, , http://sbml.org/Special/specifications/sbml-level-3/version-2/core/release-2/sbml-level-3-version-2-release-2-core.pdf#page=102

[648] SBML (application/sbml+xml) はMIME型の登録に素片識別子への言及がありません。 ID 属性があり、 埋め込まれた RDF/XML 内では素片識別子 URL がそれを指すことが明記されています >>647。

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

[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 で電話の # ボタンの意味で生の # を使います。

[658] Lモードの独自 HTML 仕様では、 tel: および fax: URL で電話の # ボタンの意味で生の # を使います。 >>659

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

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

[131] この記事はその例を紹介しています:

[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

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

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

[640] Scroll To Text · Issue #392 · w3ctag/design-reviews () https://github.com/w3ctag/design-reviews/issues/392

[645] 『FFBE幻影戦争 リオニス国営放送♯7』「FFVII REMAKE」コラボ詳細発表!気になる情報盛りだくさんスペシャル! - YouTube () https://www.youtube.com/watch?v=8aDTvX8kjGw

[646] KDDI au: 技術情報 > オープンアプリ () https://www.au.com/ezfactory/tec/spec/openappli.html

JadファイルのURLの後ろに#から続くパラメータを記載します。例を以下に示します。

<a href="device:jam?http://www.au.kddi.com/marubatsu/marubatsu.jad#param=1">○×アプリで遊ぶ</a>

上記例の場合、オープンアプリ起動時に " param=1 " の起動引数がシステムプロパティ

" com.kddi.midlet.args " 経由で引き渡されます。

Updated: