URL 與網路資源分享

  • 2019 年 11 月 25 日
  • 筆記

前晚在整理 0xFFFF 的帖子的時候,意外地發現這一篇文:

Web 在繼續離我們遠去 – 知乎

這篇文其中提到了 internet 和 Web 的概念,引用如下:

中文世界一直混淆互聯網(internet)和萬維網(web)。人們念茲在茲的「互聯網開放精神」,實乃萬維網的開放精神。萬維網的開放主要就體現在一點:任何萬維網上的文章之間都可以通過網址隨意互相鏈接。如果我想在文章里介紹 UbuWeb 這個網站,我就可以直接在 UbuWeb 這六個字母上添加它的網址 ubu.com。妳或許覺得這是廢話,但在微信公眾號的文章里妳做不到;妳只能添加微信生態圈內的鏈接,比如這個:https://weixin.qq.com/cgi-bin/readtemplate?t=weixin_external_links_content_management_specification(即上述《規範》的鏈接)

這時候我突然反應過來,我過去其實一直沒有區分清楚這裡的概念的差別,World Wide Web,簡稱 WWW,中文「萬維網」,又叫 Web,而不是 internet 這個只有物理意義的一層。加之如今移動互聯網發達,許多接觸網路的新人,對於網路的了解可能僅限於微信、QQ 和各種各樣的 APP,已不知道 WWW 為何物。所以,我也嘗試通過一些簡單的語言,理一理其中涉及的概念。

關於萬維網的種種

萬維網(WWW),簡單地說是一個在互聯網(internet)上運行的一個巨型公開資源庫,這裡的資源可以是文字、圖片、影片、音樂、各種文件等等,人們通過開啟了 Web 服務的聯網的電腦來提供資源,需要資源的人則通過某種方式,利用工具來連接提供資源的電腦,並且從中獲得對應的資源。

這裡所說的某種方式,也就是本文的主題 — URL(通常叫網址、鏈接)。

對於獲取到的一些可以直接被展示的資源,一般我們用的最多的是 超文本(Hypertext),也就是網頁,除了基本的內容以外,它的內部也可能會包含一些指向其他資源的 URL。這個指向其它資源的部分則被稱作超鏈接,英文名是 Hyperlink;網頁的源程式碼(HTML)中超鏈接被命名為 Anchor,也就是「錨」;日常大家都叫它「網址(web address)」、「鏈接(link)」。

腦洞地說,於我們而言,我們上網就像是駕駛著一艘船在資訊的海洋飄著,錨也就是在海洋中的一個個落腳點。於資訊而言,一個個超鏈接之間形成的錯綜複雜的連接關係,讓 WWW 成為了全球最大的資訊網路。

萬維網畢竟還是依賴電腦,我們作為用戶並不能直接訪問,這裡就有了 Web 瀏覽器來幫助我們做連接伺服器、展示或者下載資源等等工作,作為我們在萬維網世界中的代理角色(User Agent)。Web 瀏覽器乾的事情,也正是通過某個URL,連接到資源的提供者,然後下載展示這個資源。

結合前面所說,一個 Web 瀏覽器在用戶可見之處至少包含這三個部分:

  1. 地址欄:當前展示網頁的 URL(網址)
  2. 導航:後退、前進、刷新、回到主頁等等功能
  3. 展示網頁內容的區域

URL是什麼?

上面說了這麼多 URL 這個術語,也知道它就是網址、鏈接,那它究竟是個什麼呢?這裡參考維基百科,做一個簡單的不完全介紹。

URL,全名為 Uniform Resource Locator,中文名 統一資源定位器,形式上是一小段有特殊意義的字元。名稱三個單詞,對應了它的三個屬性:

  1. Uniform: 統一的標準
  2. Resource: 針對某個特定資源
  3. Locator: 定位器,也就是獲取這個資源的途徑和方法

以下是幾個簡單的 URL 的例子:

在這裡的對比之下,看似雜亂無章的一串字元之中,你可能會發現一些規律所在,這裡的規律最初是這樣定義的:

URL = scheme:[//authority]path[?query][#fragment]

各個部分的解釋如下:

  • scheme: 資源的請求方法(使用的網路協議)
  • authority: 關於需要請求的提供者的伺服器的地址、埠資訊
  • path: 資源在提供者的伺服器的路徑
  • query: 針對這個資源的查詢參數
  • fragment: 查詢片段

其中,[] 內的內容是可選的,也就是說,並不需要所有部分都滿足,可能只有 scheme:[//authority]path 這部分。

伺服器(authority)資訊具體是這麼定義的:

authority = [[email protected]]host[:port]

日常我們能看到最多的是其中的 host 部分,它可能是 www.baidu.com 這樣子的域名,也可以是 202.115.72.8 這樣的 IP 地址,偶爾可能會有 port 這部分。

下面是一個 URL 的例子:

https://cs50.harvard.edu/college/2019/fall/guide.pdf

這個 URL,其中包含的資訊點有:

元素

資訊

https

這個資源的獲取過程遵循 https 協議

cs50.harvard.edu

通過 cs50.harvard.edu 所指向的伺服器獲得資源

/college/2019/fall/guide.pdf

這個資源在伺服器的具體路徑是 /college/2019/fall/guide.pdf

再舉兩個例子:

1. ftp://ftp.freebsd.org/pub/FreeBSD/

元素

資訊

ftp

這個資源的獲取過程遵循 ftp 協議

ftp.freebsd.org

這個資源是通過 ftp.freebsd.org 所指向的伺服器獲得的

/pub/FreeBSD/

這個資源在伺服器的具體路徑是 /pub/FreeBSD/

2. http://202.115.72.8/dzzn.htm

元素

資訊

http

這個資源的獲取過程遵循 http 協議

202.115.72.8

這個資源是通過 202.115.72.8 所指向的伺服器獲得的

/dzzn.htm

這個資源在伺服器的具體路徑是 /dzzn.htm

瀏覽器的內部得到地址欄裡面的 URL,將這串字元分解,得到以上說的請求方法伺服器地址路徑等資訊,然後按照協議的請求方法,連接上這裡描述的伺服器地址,然後請求下載對應的資源。

一般來說,為了方便記憶,很多時候上網只需要記一個域名,剩下的請求方法,TCP 的埠號,路徑什麼的瀏覽器會自動幫我們補全,比如說,我們在瀏覽器輸入 qq.com,實際上瀏覽器會自動補充到 http://qq.com/ 這個完整的 URL,然後再訪問目標。

正是瀏覽器和服務商們都遵循了這個統一的標準,我們只需要簡單幾個字母和符號,便可以把我們帶入一個個精彩紛呈的資訊世界。

分享 URL 的姿勢

一般來說,分享一個網路資源,我們只需要把它的 URL 複製出來,然後直接粘貼發送給想分享給的對象即可,基本過程雖簡單,但背後還是蠻多細節值得留意。

去除不必要的參數

如今許多手機APP,在打開鏈接的時候,會在其背後加上某些參數,方便統計和跟蹤之用。另一方面,這些參數帶來了複雜和不美觀,乃至於可能存在隱私泄露,被跟蹤的風險。

比如說,微信分享的鏈接,一般會加上類似 ?from=groupmessage&isappinstalled=0 這樣的查詢參數,它的存在並沒有必要,所以分享的過程中可以直接去掉這一部分。

再如,網易雲音樂分享的鏈接,會包含一個 userid 的欄位,通過 userid 參數,我們可以立刻定位到分享這首歌的用戶。

一般來說,我們可以利用瀏覽器測試修改後的鏈接,避免去掉某些重要參數以後出現問題。

摘要的重要性

考慮到URL的資源需要從資源提供方的伺服器中獲取,網路環境的複雜,網頁開發品質的參差不齊,移動互聯網的弱網環境等等因素,對方點擊打開一個 URL 的過程就可能出現許多不確定的情況,無形中可能增加許多的時間成本。基於此,在對方收到這個 URL,點開之前,如果能提前快速知道一些關於這個 URL 背後的資源的一些簡單介紹的話,這裡的分享會友好很多,節約對方判斷是否值得一看的時間成本。所以這裡涉及到了一個摘要的需求。

舉個例子,假如你收到這樣的鏈接,沒有任何的上下文:

https://zhuanlan.zhihu.com/p/25167289 https://www.zhihu.com/question/267397696/answer/325352426 https://0xffff.one/d/292/5

一眼望去,有沒有一種懵逼的感覺?如果我們在前面給它一個比較簡短的一句話介紹,比如說對應頁面的標題:

Web 在繼續離我們遠去 – 知乎 https://zhuanlan.zhihu.com/p/22561084 有沒有什麼軟體適合寫寫東西的? – 知乎 https://www.zhihu.com/question/267397696/answer/325352426 URL連接之所見(Java) – 0xFFFF https://0xffff.one/d/292/4

是不是清晰了許多!

btw: 如果你平時有細心留意,你也許會留意到有的網頁的 URL 是包括了網頁的標題的,比如說 StackOverflow, Quora 之類的網站中的問題頁:

https://stackoverflow.com/questions/36303919/python-3-0-open-default-encoding https://stackoverflow.com/questions/56547714/why-does-my-vue-spa-not-work-in-mobile-offline-mode https://www.quora.com/Why-is-the-anchor-tag-named-anchor-tag

可以發現,URL的本身就能夠包含一些摘要作用的資訊,但由於URL本身只支援 ASCII 字元,在表示其它的語言的時候,需要進行 URLencode 編碼,所以這樣的操作也僅僅是在英文世界通用。

類似這樣:

https://zh.wikipedia.org/wiki/%E8%B6%85%E6%96%87%E6%9C%AC

一堆的百分號混在一起,基本喪失了可讀性,然後又回到了摘要的問題。

自動生成摘要

一般來說,一個設計良好的 Web 頁面本身會提供摘要和關鍵字等資訊,我們在一些程式分享 URL 時,程式會自動抓取關於這個 URL 的摘要資訊,甚至還可以直接預覽全文,方便用戶快速確定這個資源的基本情況。

一般的社交網站會提供一些特殊的功能標籤,類似微信的 JSSDK 的分享設置,臉書的標籤等等,網頁開發者可以針對特定平台產生合適的摘要。知乎在粘貼鏈接的時候也會自動獲取目標頁面的標題。

但在中國的人文環境和大眾的網路素養等種種因素,也決定了一下子開放的思維並不是很行得通,絕大多數時候,這個選項存在著門檻,大部分的網站在微信中並不會有比較好的摘要表現。

在微信的體系中,體驗最好的,也就只能是微信公眾號這類自家平台了,實際上,轉發到微信的公眾號文章的背後,也是一個 URL,只是被微信有意地隱藏了起來,微信公眾平台也對摘要這樣的操作做了一些可視化的要求:

在這門檻之下,對於外部的 URL,在粘貼之前,儘可能做一小段詳細介紹會比較好。實際測試之下,感覺效果還是很不錯的,QQ 與微信都會對 URL 進行高亮操作,然後變的可點擊:

為了方便產生這樣的摘要,根據我之前的實踐,有一個名為 TabCopy 的 Chrome 插件,可以實現一鍵複製網頁標題和鏈接,快速實現鏈接摘要的需求。

甚至還能批量生成:

圖片海報形式分享

圖片具有方便製作(只需簡單截屏),傳播效率極高的屬性,在 4G 時代,圖片發送在速度上和到達率上已經接近於文字,其中的流量消耗相比於影片可以說是九牛一毛。一定程度上可以用來解決部分內容的快速預覽的問題了(類似早期的長微博)。

但這裡的缺點是,一張發出去的圖片就像一張印好的傳單,若只有內容而無任何標記,追溯來源就變得十分困難。就算有標記,字元的標記的轉換過程更多依賴於手動輸入,對於 URL 這樣的相對較為複雜又要求準確的數據,手動輸入並不友好。

在這個需求下,很容易可以想到二維碼這個載體,對於影像資訊轉移的需求來說,二維碼讀取非常快速又準確,可以把許多 URL 背後的對於人類的複雜隱藏起來。如今移動設備十分方便的掃碼功能,以及類似微信、QQ 的長按識別二維碼的方式,無疑是一個很好的助力。

這裡的製作方式也超級簡單,只需要截圖,然後生成這個 URL 對應的二維碼,拼起來即可,用著名截圖工具 Snipaste 可以很快速地完成這個過程。

這一招在朋友圈、微信推文分享可以說是屢試不爽,微信讀書和網易雲音樂我覺得可以說是其中典範。

我們可以留意到,微信讀書和網易雲音樂分享出來的東西,僅僅只展示了二維碼。需要留意的是,二維碼背後實際上還是 URL,同樣可能存在隱私跟蹤參數、釣魚鏈接等不可控的風險。

URL本身有可能從域名的可信度,路徑和參數看出其中可能存在的問題,而二維碼的形式,我們是完全無法下意識感知出那些細微的差異和隱藏的資訊,所以我認為,掃碼工具在獲得二維碼背後的 URL,儘可能在圖片中展示一個完整的 URL 也是很重要的,打開之前,應該對不明的 URL 有所提示。

微信並沒有做到這一點,而是把這個本應用戶自行驗證的過程悄悄地交給了並不完全可靠的「網址安全檢測」,黑灰產們不斷地研究如何繞過,騰訊的安全中心不斷與之較量,在這愈演愈烈的戰鬥之下,防線加強,許多原本正常的域名也被一刀切,帶來的是無盡的資源浪費。

二維碼的本質,就像超市商品的條碼、書籍的 ISBN 條碼一般,只是一個輔助輸入的工具,並不能完全取代 URL 的一切。在二維碼普及的今天,若不普及 URL 的知識,人們對於二維碼背後是啥漠不關心的話,強調再多的「別掃」、「別點」、「別接」,帶來的更多的還是因噎廢食。

做好預覽海報分享這一塊的體驗的關鍵,還是需要在平面設計方面多下一些功夫。設計一批通用而舒適但又不失對用戶的知情權和隱私的尊重、還能激發探索的好奇心的海報模板和輔助生成預覽海報的程式,應該會是一件非常有意思的事情。

寫在最後

萬維網的種種屬性,也註定了它適合那些開放的,長存的知識的連接和分享。作為知識工作者,我們始終都不能忽視萬維網的存在,網路中的那些能持續沉澱的,往往也只能長久存在於萬維網中。

只是,在我們的身邊,地區的不平衡、教育本身的不健全、在商業的推動下過於高速發展的科技與大眾較低的文化水平兩者之間的矛盾也愈演愈烈。結果便是商業的平台攻略了這裡的知識盲區,早早地做了一層帶著利益外衣的不可靠的抽象。

參考這裡的數據,想像一下,大學本科以上僅占人口的 10% 左右,就算是我所在的所謂「211」大學的電腦學院,能清晰地體會到 Web 概念的人也寥寥無幾,更何況更廣大的國民?

在這背景之下,微信也正是在這有著巨大差異的國人的溝通需求之間權衡、妥協後的產物,無形中承擔了許多數不清的本應每個人獨立承擔的責任(例如,騰訊遊戲的「成長守護平台」),背後也存在著許多善與惡之間,劣幣與良幣之間的鬥爭。

這個世界有很多 shit,這是我們無法避免的,shit 要一點點鏟掉,而人們能否始終保持著一顆向善的心而不迷失在那些 shit 之間,也是一個問題。不過也有理由相信,構建起整個科技世界的根基,是知識、是實打實的技術,並不是商業寡頭們的需求出發就能達到的。那些妥協和封閉起來的事物,在短視的利益面前,當它失去了所謂流量關注和商業價值以後,也將隨之隕落,註定不會長存,這也註定了他們走不到第一梯隊。

前段時間有看到這個帖子: 從尋找 qq20 周年活動鏈接,看互聯網分享精神的退化 – V2EX

實際上,人們的分享精神還在,只是如今許多的平台的門檻做得更低,那些還不知 Web 為何物的人們,在速食麵前,也失去了跨越門檻的動力,Web 也漸漸地式微。我們能做的,大概也是認清這些平台的妥協本質,在我們力所能及的範圍內用更好的方式來表達和分享自我。

那麼,就讓我們在網上的分享,從認識和更好地使用 URL 開始吧!

參考鏈接

  1. Web 在繼續離我們遠去 – 知乎
  2. 萬維網 – 維基百科
  3. URL – Wikipedia
  4. Why are they called anchor tags? – Quora
  5. URL連接之所見(Java) – 0xFFFF
  6. 超文本 – 維基百科
  7. 第43次《中國互聯網路發展狀況統計報告》