維基百科

URI片段

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_Schema）、OWL或SKOS，片段標識符用於標識同一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（基本）語法支持使用關鍵字t和xywh沿二維（時間和空間）尋址媒體資源。因此，可以在音頻或視頻 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 （頁面存檔備份，存於網際網路檔案館）, 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（英語：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
取自「https://zh.wikipedia.org/w/index.php?title=URI片段&oldid=85284314」