為何HTTP被翻譯為“超文字傳輸協議”是一次歷史上的重大翻譯錯誤？

答：HTTP 1.0協議（RFC1945）是在1996年5月釋出的，其中文名“超文字傳輸協議”估計大約也是在1996年左右誕生的。從此以後，這個名稱就被固定了下來，一直沿用到今天。 非常遺憾，這是一個錯誤的翻譯，而且錯誤的性質很嚴重。具體來說，就是將“Hypertext Transfer Protocol”其中的“transfer”翻譯錯了。不應該將“transfer”翻譯為“傳輸”，而應該翻譯為“轉移”或者“傳遞”。“傳輸”的英文單詞應該是“transport”，而不是“transfer”。其實如果最初的譯者確實曾經認真讀過一些網際網路協議，例如HTTP協議、FTP協議等等，就會很容易地發現，在這些協議中，“transfer”和“transport”的含義有明顯的區別，根本無法混用。雖然IETF的RFC在格式上比ITU-T的那些規範要自由地多，但是RFC的作者都是非常嚴謹的，在術語的使用上面很少出現因混用導致的歧義。 在IETF的RFC中，“transport”（傳輸）的含義是指：從端到端（例如從ip1:port1到ip2:port2）可靠地搬運位元，也就是TCP/IP協議棧中的第3層傳輸層（transport layer）協議所做的那些事情。將“transport”翻譯為“傳輸”，100%正確！ 而“transfer”的含義是：通過在客戶端-伺服器端之間轉移一些帶有操作語義的操作原語，來執行某種操作。“transfer”是TCP/IP協議棧中的第4層應用層的概念，而不是第3層傳輸層的概念。“transfer”所轉移的是帶有明確操作語義的操作原語，而不是沒有操作語義的位元流。 不僅僅非專業的翻譯者很難理解“transfer”和“transport”的區別，很多經驗豐富的Web開發者也常常混淆兩者的區別。即使在母語為英語的國家，同樣也存在著很多混淆。但是理解兩者之間的區別，是理解HTTP協議本質的關鍵。為了澄清這個問題，HTTP 1.1協議的主要作者Roy Fielding在其2000年發表的博士論文《Architectural Styles and the Design of Network-based Software Architectures》（中文版名為《架構風格與基於網路的軟體架構設計》）的6.5.3小節中專門強調：HTTP並不是一種傳輸協議，其具體內容參見下一個問題。

綜上所述，HTTP協議名稱中的“transfer”可以肯定是與“傳輸”沒什麼關係的。“傳輸”這件事情，傳輸層協議TCP/UDP已經做的很好了，不需要HTTP再來越俎代皰。既然“transfer”與“transport”含義有明顯區別，而“transport”又被正確地翻譯為“傳輸”，那麼將“transfer”也翻譯為“傳輸”，必然會帶來很大的誤導。從實事求是的角度，我們作為專業的Web開發者，不應該任由“超文字傳輸協議”這個名詞以訛傳訛繼續流傳下去，貽害廣大初學者。

那麼將“transfer”翻譯為什麼更好呢？我在翻譯Fielding博士論文時，對於這個問題曾經糾結了很長時間。在中文之中，將“transfer”翻譯為“轉移”或者“傳遞”，都比翻譯為“傳輸”要好。我最後選擇了“轉移”，而沒有選擇“傳遞”，主要原因是“傳遞”與“傳輸”僅有一字之差，仍然會讓不求甚解的開發者產生誤解，誤以為“傳遞”與“傳輸”完全是相同的含義。

於是，我在Fielding博士論文中文版和《REST實戰》中文版中，都將HTTP翻譯為“超文字轉移協議”，將REST翻譯為“表述性狀態轉移”。在大多數地方，都將transfer統一翻譯為“轉移”。當然，如果你真的理解了“transfer”和“transport”之間的區別，將HTTP翻譯為“超文字傳遞協議”，將REST翻譯為“表述性狀態傳遞”都是可以的。

具體到HTTP協議，“transfer”代表的含義是：通過在客戶端-伺服器端之間轉移代表資源當前狀態的資源表述，來對伺服器端的資源執行某種操作。這既是縮寫詞HTTP中“transfer”的含義，也是縮寫詞REST中“transfer”的含義。