URI片段

出自Local Chinese Wikipedia
(重新導向自URI fragment
跳至導覽 跳至搜尋

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]
  • 前瞻學會的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英語International Digital Publishing Forum標準化方法,用於使用片段標識符引用任意內容,通過文檔結構和模式匹配來定位非錨定文本範圍。 這些動態深層連結有助於在文本更新和使用後定位內容,例如在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. blogoscoped.com. [2025-02-10]. (原始內容存檔於2024-02-28). 
  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) (English). 
  15. Kelly, Gordon. Google Chrome 80 Released With Controversial Deep Linking Upgrade. Forbes. [2020-06-04]. (原始內容存檔於2023-06-05) (English). 
  16. WICG/scroll-to-text-fragment: Proposal to allow specifying a text snippet in a URL fragment. GitHub. WebPlatform.org英語WebPlatform.org Incubator Community Group at W3C. [2020-05-18]. (原始內容存檔於2023-08-19) (English). 
  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) (en-US). 
  23. Deprecating our AJAX crawling scheme. Official Google Webmaster Central Blog. [2017-02-23]. (原始內容存檔於2021-02-17) (en-US). 
  24. Fragment Search. www.gerv.net. [2025-02-10]. (原始內容存檔於2022-10-24). 
  25. Wilde, Erik; Baschnagel, Marcel. Fragment identifiers for plain text files. ACM. 2005-09-06 [2025-02-10]. ISBN 978-1-59593-168-9. doi:10.1145/1083356.1083398. (原始內容存檔於2024-07-09) (English). 
  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. liveurls: tech. mozdev.org. [2025-02-10]. (原始內容存檔於2020-04-29). 
  30. Web Marker. addons.mozilla.org. [2025-02-10]. (原始內容存檔於2018-11-03) (en-US). 
  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