URI片段在計算機超文本中是指從屬於主資源的子資源的標識字符串。主資源由統一資源標識符(URI)標識,片段標識符指向從屬資源。

井號#引入的片段標識符是文檔的URL的可選最後部分。通常用於標識該文檔的一部分。在RFC 3986中指定了其通用語法。[1]URI中的井號#分隔符不是片段標識符的一部分。

概述

編輯

在URI中,井號#在URL末尾附近引入可選片段。RFC 3986定義的URI通用語法還允許使用問號?引入可選的查詢部分。在帶有查詢和片段的URI中,片段位於查詢之後。查詢部分取決於URI方案並由伺服器評估,例如,http:支持與ftp:不同的查詢。片段取決於文檔MIME類型並由客戶端(Web 瀏覽器)評估。客戶端在獲取文檔時不應將URI片段發送到伺服器,並且如果沒有本地應用程式的幫助,片段不會參與HTTP重定向。

井號#結尾的URI是通用語法允許的,並且這是一種空片段。在MIME文檔類型(例如text/html或任何XML類型)中,不允許使用空標識符來匹配此語法上合法的構造。 Web瀏覽器通常會在文檔頂部顯示一個空片段。

片段標識符的功能與URI的其餘部分不同:它的處理完全是客戶端進行的,沒有Web伺服器的參與,儘管伺服器通常幫助確定MIME類型,並且MIME類型決定片段的處理。當代理(例如Web瀏覽器)從Web伺服器請求Web資源時,代理將URI發送到伺服器,但不發送片段。相反,代理等待伺服器發送資源,然後代理根據文檔類型和片段值處理資源。[2]

在HTML網頁中,代理將查找由HTML標記標識的錨點,該標記包含等於片段標識符的id=name=屬性。

例子

編輯
  • 在MIME為text/html頁面的URI(例如http://www.example.org/foo.html#bar)中,片段引用id="bar"的元素。
    • 圖形Web瀏覽器通常滾動到位置頁面,以便由片段id標識的元素的頂部與視口(viewport)的頂部對齊;因此片段標識符經常用在目錄和永久連結中。
    • 可以通過CSS偽類:target更改被標識的元素的外觀;維基百科使用它來高亮顯示所選的參考文獻。值得注意的是,CSS的display: block僅當內容是目標時才可用於顯示內容,否則通過display: none隱藏。
    • 已棄用的name屬性(僅允許某些元素)在現已過時的瀏覽器中具有類似的用途。如果存在name,則必須和id相同。
  • 在所有XML文檔類型中,包括對應於xml:id或類似id屬性的XHTML片段,都遵循Name語法並以字母、下劃線或冒號開頭。值得注意的是,它們不能以數字或連字符開頭。[3]
    • xml:id是少數通用XML屬性之一,例如xml:lang,無需顯式聲明命名空間即可使用。[4]在XHTML中必須使用id,因為 XHTML 是在xml:id存在之前指定的。
  • 在XML應用中,某種語法中的片段標識符可以是XPointer; 例如,URI http://www.example.org/foo.xml#xpointer(//Rube) 中的片段標識符指的是由URI http://www.example.org/foo.xml標識的文檔中名為「Rube」的所有XML元素。給定該URI,XPointer處理器將獲取文檔的表示(例如通過從Internet請求)並返回文檔的「Rube」元素的表示。
  • RDF詞彙表中,例如RDFS英語RDF_SchemaOWLSKOS,片段標識符用於標識同一XML命名空間中的資源,但不一定對應於文檔的特定部分。例如,http://www.w3.org/2004/02/skos/core#broader標識了SKOS Core詞彙中的「broader」概念,但它並不指代http://www.w3.org/2004/02/skos/core標識的資源的特定部分。它是一個完整的 RDF 文件,其中聲明了該特定概念的語義以及同一詞彙表中的其他概念。
  • 在 MIME text/plain文檔的URI中,RFC 5147 使用關鍵字「char」和「line」指定文檔內字符和行位置和範圍的片段標識符。瀏覽器支持似乎缺乏。[5]以下示例標識文本文檔的第 11 行到第 20 行:
    • http://example.com/document.txt#line=10,20
  • 在 MIME text/csv 文檔的 URI 中,RFC 7111 使用關鍵字"row" , "col", "cell"指定片段標識符作為行、列和單元格的選擇器,例如:
    • http://example.com/data.csv#row=4 –選擇第4行.
    • http://example.com/data.csv#col=2 – 選擇第二列.
    • http://example.com/data.csv#row=5-7 – 選擇從第5行開始的三個連續行.
    • http://example.com/data.csv#row=5-* – 選擇從第5行開始的所有行.
    • http://example.com/data.csv#cell=4,1-6,2 – 選擇從第4行第1列開始到第6行第2列結束的區域.
  • 在MIME audio/*、image/*、video/* 文檔的 URI 中,很少有定義片段或片段語義。[6]媒體片段 URI 1.0(基本)語法支持使用關鍵字txywh沿二維(時間和空間)尋址媒體資源。因此,可以在音頻或視頻 HTML5 元素的src屬性中使用以下媒體片段 URI:
    • http://example.com/foo.mp4#t=10,20
    • http://example.com/bar.webm#t=40,80&xywh=160,120,320,240
    • 其他網站使用片段部分將一些額外信息傳遞給在其上運行的腳本 - 例如,Google Video理解#01h25m30s格式的永久連結以在指定位置開始播放,[7]而YouTube使用類似的代碼,例如#t=3m25s.[8]
  • JavaScript中,當前HTML或XHTML頁面的片段標識符可以在「hash」屬性location.hash中訪問 - 請注意,JavaScript 也可以與其他文檔類型一起使用。 隨著AJAX的興起,一些網站使用片段標識符來模擬瀏覽器的後退按鈕行為,以進行不需要重新加載的頁面更改,或模擬子頁面。
    • 例如,Gmail幾乎每個界面都使用單個URL – 郵箱、個人郵件、搜索結果、設置 – 該片段用於使這些界面可以直接連結。[9]
    • Adobe Flash網站可以使用片段部分來通知用戶網站或Web應用程式的狀態,並促進深度連結,通常在SWFAddress JavaScript庫的幫助下。
  • 連結到JSON文檔的URI可以指定指向特定值的指針。[10]
    • 例如,以#/foo結尾的URL可用於從以{ "foo": ["bar", "baz"], ... }開頭的文檔中的「鍵-值對」中提取值。
  • 在 MIME application/pdf 文檔的 URI 中,PDF查看器可識別許多片段標識符。[11][12]例如,以 .pdf#page=35結尾的 URL 將導致大多數讀者打開 PDF 並滾動到第35頁。其他幾個參數也是可能的,包括#nameddest=(類似於HTML錨點)、#search="word1 word2", #zoom=等。多個參數可以用 & 符號組合:
    • http://example.org/doc.pdf#view=fitb&nameddest=Chapter3.
  • SVG中,片段可以指定viewBox(), preserveAspectRatio(), transform()等參數。[13]

W3C提案

編輯

對於與純文本文檔(無法存儲錨元數據)一起使用的片段標識符,或者引用 HTML 文檔中作者未使用錨標記的位置,已經提出了一些W3C提案:

  • 2012年9月,Media Fragments URI 1.0 (basic)已成為W3C推薦標準。[14]
  • Chrome版本80及更高版本[15][16]實現了WICG頁面存檔備份,存於網際網路檔案館Text Fragments,[17]因此#:~:text=foo將導致瀏覽器搜索foo,突出顯示匹配的文本,然後滾動到它。除了開始和結束之外,代碼片段還可以指定上下文:必須在foo之前或之後但不會突出顯示的文本(例如搜索前面帶有「night」的「vision」)。
  • Python的Package Index將文件的MD5哈希值附加到URL作為片段標識符。[18]如果MD5未被破壞,這可以用來確保包的完整性。
    https://pypi.python.org ... zodbbrowser-0.3.1.tar.gz#md5=38dc89f294b24691d3f0d893ed3c119c
  • hash-bang[19]片段是以感嘆號!開頭的片段。它用於索引動態單頁應用程式的現已被棄用的方法中。感嘆號在HTML4、XHTML和XML標識符中是非法的,因此與該功能有一定程度的分離。然而,它在HTML5中是允許的。[20]
    • 2009年至2015年間,Google網站管理員中心提出並推薦了一種「AJAX 抓取方案」[21][22],在有狀態AJAX頁面的片段標識符中使用初始感嘆號:
      http://example.com/page?query#!state
    • 另一個實現是替換#!?_escaped_fragment_=[21]
    • Hash-bang URI 被W3C的Jeni Tennison等許多人認為是有問題的,因為它們使那些沒有在瀏覽器中激活JavaScript的人無法訪問頁面。它們還會破壞HTTP Referer標頭,因為瀏覽器不允許發送Referer標頭中的片段標識符。[19]
    • 2015 年,Google 棄用了他們的hash-bang AJAX抓取提案,轉而建議使用漸進增強和HTML5的history.pushState()[23]方法。[24]
    • Mozilla基金會Gervase Markham提出了一種用於搜索的片段標識符,其形式為#!s!search terms。 在s(#!s10!) 後添加數字表示瀏覽器應搜索第n次出現的搜索詞。負數(#!s-3!)從文檔末尾開始向後搜索。Greasemonkey腳本可用於將此功能添加到兼容瀏覽器。[25]
      http://example.com/index.html#!s3!search terms
  • 蘇黎世聯邦理工學院的Erik Wilde和Marcel Baschnagel將其擴展為使用正則表達式(使用關鍵字「match」)來識別純文本文檔中的片段。[26]他們還描述了一個原型實現作為Firefox瀏覽器的擴展。例如,以下命令將在文檔中的任何位置查找不區分大小寫的文本「RFC」:
    http://example.com/document.txt#match=[rR][fF][cC]
  • Foresight Institute的K. Yee提出了用冒號和關鍵字分隔的「擴展片段標識符」,以將它們與錨標識符區分開來。具有「片段規範方案」id「words」的文本搜索片段標識符是該方案中的第一個提案。[27]以下示例將在文檔中搜索字符串「some context for a search term」的第一次出現,然後突出顯示單詞「search term」:
    http://example.com/index.html#:words:some-context-for-a-(search-term)
    • 上述方案在Chrome 80版本中實現。[28]
  • LiveURLs項目[29]提出了一種片段標識符格式,用於引用頁面內的文本區域,其形式為#FWS+C,其中 F 是第一個單詞的長度(最多5個字符),W是第一個單詞本身,S是所選文本的長度,C是所選文本的32位CRC[30]他們使用#LFWS+C的形式實現了該方案的變體作為 Firefox 瀏覽器的擴展[31],其中L是片段本身的長度,採用兩個十六進制數字。使用已實現的變體連結到單詞「Fragment」將產生:
    http://example.com/index.html#115Fragm8+-52f89c4c
  • 在 Firefox 5 之前,Firefox 支持 XPath 連結,例如 #xpath:/html/body/div[3],它可以與書籤結合使用,例如 http://antimatter15.com/wp/2009/11/xpath- bookmark-bookmarklet/ 用於連結缺少正確 ID 的 HTML 文檔。 此功能已作為 https://bugzilla.mozilla.org/show_bug.cgi?id=457102頁面存檔備份,存於網際網路檔案館) 中代碼清理的一部分被刪除
  • EPUB電子書格式中,EPUB Canonical Fragment Identifier (epubcfi,[32] 2011-2017)定義了一種W3C/IDPF標準化方法,用於使用片段標識符引用任意內容,通過文檔結構和模式匹配來定位非錨定文本範圍。 這些動態深層連結有助於在文本更新和使用後定位內容,例如在Apple Books中。

參見

編輯

參考文獻

編輯
  1. ^ RFC 3986 Uniform Resource Identifier (URI): Generic Syntax. Internet Engineering Task Force. January 2005 [2012-03-06]. (原始內容存檔於2023-04-08). 
  2. ^ Representation types and fragment identifier semantics. Architecture of the World Wide Web, Volume One. W3C. 2004 [2011-07-13]. (原始內容存檔於2015-02-09). 
  3. ^ Validity constraint: ID. XML 1.0 (Fifth Edition). W3C. 2008 [2011-07-13]. (原始內容存檔於2020-01-10). 
  4. ^ xml:id Version 1.0. W3C. 2005 [2011-07-13]. (原始內容存檔於2023-11-13). 
  5. ^ Issue 77024. Chromium. 2011 [2011-07-13]. (原始內容存檔於2015-11-19). 
  6. ^ Media Type Review. W3C Media Fragments Working Group. 2009 [2009-04-29]. (原始內容存檔於2023-08-19). 
  7. ^ New Feature: Link within a Video. 2006-07-19 [2011-07-13]. (原始內容存檔於2023-08-19). 
  8. ^ Link to Specific Content in Gmail頁面存檔備份,存於網際網路檔案館), Google Blogoscoped, 2007-11-17
  9. ^ Bryan, P. RFC 6901 – JavaScript Object Notation (JSON) Pointer. The Internet Society. 2 April 2013 [14 July 2022]. (原始內容存檔於2023-11-14). 
  10. ^ Parameters for Opening PDF Files – Specifying parameters in a URL (PDF). Adobe. April 2007 [2017-09-20]. (原始內容存檔 (PDF)於2017-09-18). 
  11. ^ Taft, E.; Pravetz, J.; Zilles, S.; Masinter, L. RFC 3778 – The application/pdf Media Type. The Internet Society. May 2004 [2017-09-20]. doi:10.17487/RFC3778. (原始內容存檔於2021-02-24). 
  12. ^ Linking – SVG 1.1 (Second Edition). [2023-08-19]. (原始內容存檔於2019-06-25). 
  13. ^ Media Fragments URI 1.0 (basic) W3C Recommendation. [2012-09-25]. (原始內容存檔於2012-09-20). 
  14. ^ Scroll to Text Fragment. Chrome Platform Status. Google Chrome. [2020-05-18]. (原始內容存檔於2023-08-24) (英語). 
  15. ^ Kelly, Gordon. Google Chrome 80 Released With Controversial Deep Linking Upgrade. Forbes. [2020-06-04]. (原始內容存檔於2023-06-05) (英語). 
  16. ^ WICG/scroll-to-text-fragment: Proposal to allow specifying a text snippet in a URL fragment. GitHub. WebPlatform.org Incubator Community Group at W3C. [2020-05-18]. (原始內容存檔於2023-08-19) (英語). 
  17. ^ Pypi md5 check support. [2011-07-13]. (原始內容存檔於2016-08-01). Pypi has the habit to append an md5 fragment to its egg urls, we'll use it to check the already present distribution files in the cache 
  18. ^ 19.0 19.1 Hash URIs. W3C Blog. 2011-05-12 [2011-07-13]. (原始內容存檔於2013-09-01). 
  19. ^ HTML 5.1 2nd Edition. W3C. 2017 [2018-08-03]. (原始內容存檔於2021-07-18). 
  20. ^ 21.0 21.1 Proposal for making AJAX crawlable. 2009-10-07 [2011-07-13]. (原始內容存檔於2020-12-12). 
  21. ^ (Specifications) Making AJAX Applications Crawlable. Google Inc. [2013-05-04]. (原始內容存檔於2020-12-12). 
  22. ^ Manipulating the browser history. Mozilla Developer Network. [2017-02-23]. (原始內容存檔於2015-08-24) (美國英語). 
  23. ^ Deprecating our AJAX crawling scheme. Official Google Webmaster Central Blog. [2017-02-23]. (原始內容存檔於2021-02-17) (美國英語). 
  24. ^ Fragment Search頁面存檔備份,存於網際網路檔案館), gerv.net
  25. ^ Fragment identifiers for plain text files, Erik Wilde and Marcel Baschnagel, Swiss Federal Institute of Technology (ETH Zürich), Proceedings of the sixteenth ACM conference on Hypertext and hypermedia doi:10.1145/1083356.1083398
  26. ^ Text-Search Fragment Identifiers頁面存檔備份,存於網際網路檔案館), K. Yee, Network Working Group, Foresight Institute, March 1998
  27. ^ bmcquade; bokan; nburris. Feature: Scroll to Text Fragment. Chrome Platform Status. chromium.org. 2022-03-24 [3 May 2022]. (原始內容存檔於2023-08-24). 
  28. ^ LiveURLs project. [2023-08-19]. (原始內容存檔於2019-08-15). 
  29. ^ The technology behind LiveURLs頁面存檔備份,存於網際網路檔案館), accessed 2011-03-13
  30. ^ "Web Marker" Firefox add-on頁面存檔備份,存於網際網路檔案館), accessed 2011-03-13
  31. ^ EPUB Canonical Fragment Identifiers 1.1. idpf.org. [2020-06-03]. (原始內容存檔於2023-10-23). 

外部連結

編輯
  • W3C Media Fragments頁面存檔備份,存於網際網路檔案館) Working Group, establishing a URI syntax and semantics to address media fragments in audiovisual material (such as a region in an image or a sub-clip of a video)
  • MediaMixer Community Portal collects presentations, tutorials, use cases and demonstrators related to use of Media Fragment technology