關於HTTP中文翻譯的討論

討論參與者共16位：

圖靈謝工 楊博 陳睿傑 賈洪峰 李錕 丁雪豐 郭義 樑濤 吳璽喆 鄧聰 胡金埔 臧秀濤 張伸

圖釘派_007_LL 圖釘派_111_DP 圖釘派-34徐浩然

辯論主題：HTTP中的“transfer”是否應該翻譯為“傳輸”？

主持人：圖靈謝工

正方：賈洪峰、郭義、樑濤 正方觀點：為了照顧讀者的閱讀習慣，還是應該繼續沿用“超文字傳輸協議”這個稱呼。

反方：陳睿傑、李錕、丁雪峰 反方觀點：HTTP既然很清楚並不是一種“傳輸”協議，繼續沿用帶有巨大誤導性的“超文字傳輸協議”這個名稱，顯然是不嚴謹、不妥的。

中立方：其餘所有人

5月21日討論內容：

楊博 16:56:35 已經出現過的術語含義會經常變化？

018圖靈謝工 16:56:58 不好說

009陳睿傑-小狗 16:57:17 HTTP這個術語就是個例子

009陳睿傑-小狗 16:57:38 我很想知道，圖靈的權威指南會怎麼翻譯這個詞呢？嘿嘿

009陳睿傑-小狗 16:58:37 就HTTP

009陳睿傑-小狗 16:58:57 被dlee揪出來罵過很多次的，現在流行的翻譯

018圖靈謝工 17:00:16 超文字傳輸協議（Hypertext Transfer Protocol，HTTP）是在全球資訊網上進行通訊時所使用的協議方案。HTTP有很多應用，但最著名的是用於web瀏覽器和web伺服器之間的雙工通訊。

吳璽喆-George Wing 17:00:23 嗯，傳輸？！

018圖靈謝工 17:00:33 HTTP起初是一個簡單的協議，因此你可能會認為關於這個協議沒有太多好說的。但現在，你手上拿著的是卻一本兩磅重 的書。如果你對我們怎麼會寫出一本650頁 的關於HTTP的書感到奇怪的話，可以去看一下目錄。本書不僅僅是一本HTTP首部的參考手冊；它是一本名副其實的web結構聖經。

009陳睿傑-小狗 17:01:16 有對HTTP這個縮寫做翻譯解說麼？不會又是“超文字傳輸協議吧”

009陳睿傑-小狗 17:01:27 要被dlee罵的

009陳睿傑-小狗 17:01:41 他的書裡面都翻譯成 超文字轉移協議

009陳睿傑-小狗 17:01:50 我覺得可以在譯者注那裡說明下

009陳睿傑-小狗 17:02:20 這是個約定俗成的誤解翻譯，不就得了，兩邊不得罪

吳璽喆-George Wing 17:02:29 轉移？!不習慣

018圖靈謝工 17:02:48 一會我會發個前言的最新版帖子

吳璽喆-George Wing 17:02:51 傳輸？！不知道傳輸了神馬。。。

009陳睿傑-小狗 17:03:00 這個問題，你們要問dlee了

楊博 17:03:10 transfer。。他為什麼這麼翻啊？

009陳睿傑-小狗 17:03:17 建議資訊下他

009陳睿傑-小狗 17:03:21 我覺得挺有道理的

LZSoft·樑濤 17:03:24 難道要翻譯成變形麼？

009陳睿傑-小狗 17:03:36 我找點筆記給你們參考

吳璽喆-George Wing 17:03:56 超文字轉移協議

009陳睿傑-小狗 17:05:08 http://product.china-pub.com/member/bookpinglun/viewpinglun.asp?id=198630&t=2

009陳睿傑-小狗 17:05:15 看這裡有個評論，是相關討論

009陳睿傑-小狗 17:05:21 我個人是比較挺dlee的

009陳睿傑-小狗 17:05:42 這一條，展開了看看

018圖靈謝工 17:05:50 我們這本翻譯的譯者陳涓比較權威

吳璽喆-George Wing 17:06:02 有連結嗎？謝工

009陳睿傑-小狗 17:06:34 還是建議找李琨老師探討下，哪怕是加個譯者注也好啊

009陳睿傑-小狗 17:06:37 我的建議

018圖靈謝工 17:07:11 陳娟是解放軍理工大學的教授，謝希仁學生

吳璽喆-George Wing 17:07:30 實習了嗎？

賈洪峰 17:07:43 HTTP的譯法已經用這麼多年了，我個人覺得不需要改了。

009陳睿傑-小狗 17:08:00 http://product.china-pub.com/57771#yzx 這本書的譯者序就比較婉轉

009陳睿傑-小狗 17:08:08 這樣說明下，就兩邊都不得罪了

009陳睿傑-小狗 17:08:29 以Fielding博士設計的HTTP協議為例，大家都把它當做一種傳輸協議，但HTTP其實是為REST而生的，它能夠表達狀態和狀態轉移，這就是它位於應用層而非傳輸層的原因，所以說HTTP中的Transfer被翻譯成“轉移”更為恰當。

吳璽喆-George Wing 17:08:29 丁雪豐

009陳睿傑-小狗 17:08:35 圖靈的譯者哦

吳璽喆-George Wing 17:08:38 他在群裡呢

009陳睿傑-小狗 17:08:47 對啊，可以找他問問

楊博 17:08:58 嗯，這個挺有意思的

009陳睿傑-小狗 17:09:06 我看李琨老師也線上的嘛

賈洪峰 17:10:30 我也覺得加註更好一些。

楊博 17:10:38 關鍵術語的翻譯對應的是關鍵概念的理解，我覺得還是挺重要的

009陳睿傑-小狗 17:10:50 不過估計來不及了，是不是都印刷了，下一版得了

018圖靈謝工 17:11:21 我看看最新的前言

賈洪峰 17:11:49 可以註明，因為傳統原因，大家一直譯為“傳輸”，實際應為“轉移”，等等。

009陳睿傑-小狗 17:11:56 對

賈洪峰 17:12:18 像微軟的官方文件中都一直用傳輸，突然冒出一個“轉移”來，很難為大家接受。

LZSoft·樑濤 17:12:45 這一點日文比較好，一直挺統一。

賈洪峰 17:12:56 那是因為日文的少。:)

LZSoft·樑濤 17:13:10 跟日文字身有點關係。

LZSoft·樑濤 17:13:20 沒有太多含糊和意義重合的詞。

賈洪峰 17:13:40 這是Ｍｉｃｒｏｓｏｆｔ的文件

018圖靈謝工 17:13:52 目前我看了，這本書叫傳輸

LZSoft·樑濤 17:14:28 session => セッション

LZSoft·樑濤 17:14:35 直接音譯。

LZSoft·樑濤 17:14:43 很少有重合的。

009陳睿傑-小狗 17:14:44 正文不用改，就加個說明就最好

賈洪峰 17:15:21 這是微軟給的定義，如果從deliver的角度來說，叫傳輸也未嘗不可。

LZSoft·樑濤 17:16:40 “遞送”呢？

009陳睿傑-小狗 17:17:46 dlee怎麼不出來討論下

楊博 17:20:57 中文譯名問題

HTTP在中國大陸被翻譯為“超文字傳輸協議”，因為“transfer”在此有“傳輸”的含意。但HTTP定製者之一的Roy Fielding博士在其論文[1]（6.5.3節）中使用“transfer”表達的是“（表述狀態的）轉移”（Representational State Transfer），而不是“傳輸”。這是因為英語單詞“transfer”在不同語境下的多義性，請勿誤解。 另一方面看，不管在大陸還是港臺地區，應用層協議名字中的“transfer”習慣上都被譯為“傳輸”，1991年，Tim Berners-Lee發明設計HTTP的最初目的很單純，就是為了傳輸含有超鏈的文字，最初版本的HTTP只能傳輸純文字頁面，只有一個GET方法，並不適用於構建各種應用系統，這裡HTTP（超文字傳輸協議）與FTP（檔案傳輸協議）、NNTP（網路新聞傳輸協議） 、SMTP（簡單郵件傳輸協議）相比，並無特別之處。HTTP流行之後，Roy Fielding2000年論文提出的Representational State Transfer，是HTTP（也可以是其他傳輸協議）之上構建各種應用系統的一種架構風格，其中的“State Transfer（狀態轉移）”並未改變“Hypertext Transfer（超文字傳輸）”的原始含義，由此看“超文字傳輸協議”的譯法並無不妥。

楊博 17:21:01 wiki上的

賈洪峰 17:23:22 沒有深入研究過這些論文，所以不太好說。

賈洪峰 17:23:41 我是僅從尊重習慣的角度來考慮的，哪怕是錯誤的習慣。

009陳睿傑-小狗 17:23:46 所以才想讓論文的譯者來討論下了，但是貌似他qq沒回復

LZSoft·樑濤 17:23:46 Wiki不是很權威，感覺。

018圖靈謝工 17:23:55 一會我把這本書的前言部分給大家看看放社群文章內

009陳睿傑-小狗 17:24:01 可以不修改翻譯，但是加個註釋說明下，個人建議

LZSoft·樑濤 17:24:08 畢竟Wiki也是大量非專職人士貢獻的。

賈洪峰 17:24:12 大家還記得物理中的磁場強度和磁感應強度吧？！

楊博 17:24:25 嗯，我在看這段是誰加的

楊博 17:24:49 wiki上也有很多專業人士的說

李錕 17:25:43 這個解釋讓Fielding看到後會怎麼說呢，Fielding在2000年的論文中就說的很清楚“HTTP不是一種傳輸協議”。某人非要指鹿為馬說HTTP其實本質上就是一種傳輸協議，是為了證明什麼呢？

009陳睿傑-小狗 17:26:27 歡迎李老師加入討論，我個人是比較認同的

吳璽喆-George Wing 17:27:12 感覺很有料

李錕 17:27:22 Fielding就是HTTP 1.1協議的原創者，尊重一下原創者的觀點，這個要求似乎不過分吧？

吳璽喆-George Wing 17:27:54 有時候 事物的發展遠遠超出了發明家的想象

009陳睿傑-小狗 17:28:13 但是論文裡面明確說明了賽

009陳睿傑-小狗 17:28:33 總不至於和他的意思相悖吧

吳璽喆-George Wing 17:28:36 造物主說自己的造的物是 轉移協議，人們還是在說：傳輸協議

郭義 17:29:05 中文裡面　轉移和傳輸。有什麼差異？

LZSoft·樑濤 17:30:11 類似於擁有權和控制權吧。

009陳睿傑-小狗 17:30:39 傳輸的是實體內容對吧，但是抽象的資源只能是轉移表述

李錕 17:31:09 仔細看一下《REST實戰》等等圖書。把HTTP傳輸協議當作一種傳輸協議來使用，是非常低效的，這個Web開發界早就有共識了。

鄧聰 17:31:37 你前提是REST的場景

009陳睿傑-小狗 17:31:42 所以建議HTTP權威指南能譯者注說明下，不要再以訛傳訛了

鄧聰 17:32:09 就C到S這樣一個HTTP應用協議來說，傳輸沒有什麼不妥

楊博 17:32:42 嗯，09年wiki的版本是這樣的“中文譯名問題

HTTP 在中國大陸被翻譯為“超文字傳輸協議”，因為“transfer”在中文裡有“傳輸”的含意。但依據 HTTP 定製者之一的 Roy Fielding 博士的論文[1]（6.5.3節），作者專門強調“transfer”表示的是“（表述狀態的）轉移”（Representational State Transfer），而不是“傳輸”（transport）。故其中文譯名“超文字傳輸協議”恰恰引種反映了這種誤解。更符合原義的譯名應該為“超文字轉移協議”。”

吳璽喆-George Wing 17:33:37 晚出了十幾年

009陳睿傑-小狗 17:33:39 我還等著看呢，囧

吳璽喆-George Wing 17:33:53 等得花兒都謝了

郭義 17:33:59 超文字轉移協議　貌似也很難理解到　狀態轉移。。。

李錕 17:34:16 2002年的老書，不過HTTP 1.1從1999年到現在一直沒出新版本。

009陳睿傑-小狗 17:34:20 建議大家都看看論文好了，看過了就會有個大概理解了

吳璽喆-George Wing 17:34:28 隨便一本 TCP/IP 相關的書都有http的部分

郭義 17:34:29 不如叫超文字狀態轉移協議。。。多清晰。。

009陳睿傑-小狗 17:34:31 好歹是HTTP制定者的看法

吳璽喆-George Wing 17:34:49 最重要的就是 快取機制了

楊博 17:34:57 哈哈，不小心看到roy fielding的這篇博士論文就是@李錕翻譯的

李錕 17:35:05 Google不是搞了一個自己的HTTP協議嗎，Chrome瀏覽器和Google自己的網站支援。

009陳睿傑-小狗 17:35:07 小吳，你可以去看 REST實戰

009陳睿傑-小狗 17:35:21 裡面把HTTP的優勢都講了

吳璽喆-George Wing 17:35:32 瀏覽器 快取 中間代理 快取 伺服器 快取 三層快取

009陳睿傑-小狗 17:35:37 我看完了，大部分能理解，就是 超文字驅動，這個還有點模糊

009陳睿傑-小狗 17:35:47 不止是快取，還有很多東西

009陳睿傑-小狗 17:36:02 比如分散式、無狀態、容錯

吳璽喆-George Wing 17:36:19 難點 重點 是在 HTTP 快取

吳璽喆-George Wing 17:36:36 協議 我列印了呀

009陳睿傑-小狗 17:36:37 這個沒有多難啊，我倒是覺得

009陳睿傑-小狗 17:36:47 書裡面都講了，強烈推薦

LZSoft·樑濤 17:36:51 怎麼看都像協程的網路版實現。

吳璽喆-George Wing 17:37:33 在中間代理層的快取 你怎麼用長連線 分塊傳呢？

吳璽喆-George Wing 17:37:50 實踐起來 還是有很多坑的

009陳睿傑-小狗 17:37:50 http本來就不是給你做長連線用的

009陳睿傑-小狗 17:37:59 你就是在濫用

009陳睿傑-小狗 17:38:03 無狀態是什麼意思

郭義 17:38:13 1.1 支援長的吧。

009陳睿傑-小狗 17:38:36 要comet，還是老老實實的用web socket好了

吳璽喆-George Wing 17:38:37 IE6是個大坑

009陳睿傑-小狗 17:38:51 看書啦看書啦，你們都不看書

009陳睿傑-小狗 17:39:07 我是菜鳥，只能這麼說了，反正書上這麼講的

LZSoft·樑濤 17:39:10 沒心情看，太多坑要填。

郭義 17:39:12 http 的長連線。很重要的哦。。。

009陳睿傑-小狗 17:39:15 實際中我也會遵循

吳璽喆-George Wing 17:39:26 試試IE6吧

009陳睿傑-小狗 17:39:29 要真長連線，我會考慮socket

009陳睿傑-小狗 17:39:37 IE6可以淘汰了

LZSoft·樑濤 17:39:37 用HTTP長連線不符合它的設計宗旨。

吳璽喆-George Wing 17:39:48 絕對 的巨大的 壎石坑

009陳睿傑-小狗 17:39:54 無狀態這麼重要的要求，你們都不遵循

009陳睿傑-小狗 17:39:58 我也沒什麼好說的了

郭義 17:40:01 太學術了。。。技術是為了解決實際問題為好。。

李錕 17:40:25 無狀態怎麼是太學術了？這樣說簡直就是無知了。

009陳睿傑-小狗 17:40:27 一個session就能搞死你

郭義 17:40:38 我是說。。。長連線。。。

009陳睿傑-小狗 17:40:39 session複製？omg，你慢慢同步去吧

009陳睿傑-小狗 17:40:53 長連線不就是違反了無狀態的一個特例麼

吳璽喆-George Wing 17:41:08 HTTP有無狀態，在實踐國還是得有狀態

009陳睿傑-小狗 17:41:11 專案裡面現在都是輪詢

吳璽喆-George Wing 17:41:15 實踐中

吳璽喆-George Wing 17:41:24 輪詢不好

009陳睿傑-小狗 17:41:38 長連個個毛線，ajax輪詢了，等下個版本，讓客戶用特定的瀏覽器，我用web socket了

郭義 17:41:49 盡信書不如無書。。

009陳睿傑-小狗 17:41:59 後臺配合Node，不是更好的選擇麼

LZSoft·樑濤 17:42:04 工程派跟學院派對上了。

018圖靈謝工 17:42:10 你們在爭什麼，我都看不懂

009陳睿傑-小狗 17:42:23 我就不相信你們在實際專案裡面真的做到非輪詢的長連線了

LZSoft·樑濤 17:42:25 他們爭的是 是否實用。

李錕 17:42:26 別扣帽子，中國人最傻的就是亂扣帽子。

009陳睿傑-小狗 17:42:34 發個永遠下載不完的頁面？

李錕 17:42:37 無狀態對於伺服器的可伸縮性是至關重要的。

楊博 17:42:38 嗯，我也看不懂，不過語氣很犀利啊

009陳睿傑-小狗 17:42:40 不覺得很那啥麼

009陳睿傑-小狗 17:43:21 而且，我想知道，現在有多少產品HTTP伺服器，能夠經受得住你們的長連線

鄧聰 17:43:35 見過的 一般都是輪詢

009陳睿傑-小狗 17:43:39 web qq這麼做的麼？伺服器恐怕早就over了

鄧聰 17:43:58 拉 推相結合

郭義 17:44:09 陳睿傑-小狗　很多http長連線的應用可能你沒注意。。並不只是comit才算長連線應用。

009陳睿傑-小狗 17:44:15 HTML5的web socket真的很好

018圖靈謝工 17:44:22 http://www.ituring.com.cn/article/1806

009陳睿傑-小狗 17:44:31 我指向知道http長連線能經受多大的負載

009陳睿傑-小狗 17:44:36 就這個問題，其他的我不問了

009陳睿傑-小狗 17:44:42 qq會不會這麼做

圖釘派-34徐浩然 17:44:51 qq用了flash

吳璽喆-George Wing 17:44:53 有場景 可以用到呀

018圖靈謝工 17:44:54 我發了有關這書的內容

圖釘派-34徐浩然 17:44:57 某種意義上可以算是長連線

009陳睿傑-小狗 17:45:00 區域網裡面你玩玩無所謂的

郭義 17:45:11 如果沒有１.１的長連線。。。大量請求server　也是很多問題的。

009陳睿傑-小狗 17:45:14 flash可以socket的好不好

018圖靈謝工 17:45:21 一本名副其實的 Web架構“聖經”——關於《HTTP權威指南》

018圖靈謝工 17:45:26 這標題，估計要被拍

009陳睿傑-小狗 17:45:34 http的無狀態，正好能解決你的大量請求的問題

郭義 17:45:44 這麼說吧。有個應用　叫ad　exchange。。你可以瞭解下。。

鄧聰 17:45:47 這本書終於要出了

009陳睿傑-小狗 17:45:53 算了，我也不爭論了，只是希望大家去看看REST相關的書

LZSoft·樑濤 17:46:02 同小狗。

009陳睿傑-小狗 17:46:12 頂樓上

郭義 17:46:35 有個環節叫　RTB。。也就是有大量訪問。。

郭義 17:47:14 qps　大約。每妙。要２萬。。。如果用短連線要很多機器的。。

009陳睿傑-小狗 17:48:08 可以負載均衡喲

009陳睿傑-小狗 17:48:20 因為沒有狀態資訊，1000臺機器都是一樣的喲

吳璽喆-George Wing 17:48:22 要吵 才有收穫呀

鄧聰 17:48:33 10年在推特上 看到yurii 推薦過這本書 看下時間，國外2002出版，感覺一下落後太多了

009陳睿傑-小狗 17:48:47 沒有會話資訊，你不用管到底之前是哪臺伺服器收到了請求，嘿嘿，好了，點到為止，不爭論了

鄧聰 17:49:00 都開始丟名稱了麼，哈哈哈哈

鄧聰 17:49:06 名詞

郭義 17:49:08 qps２萬。上了負載　後面也得不少機器的。

鄧聰 17:49:31 神馬應用啊？

郭義 17:49:50 dsp　進行rtb　競價。。

郭義 17:50:00 也就是個實時競價　架構。。。

郭義 17:50:32 現在google　的adexchange . 淘寶的tanx。。都是這個應用。。

郭義 17:51:18 我這是個實際問題。。說一下沒別的意思。。。就是部想讓大家從一個誤會走如另一個誤會。。

LZSoft·樑濤 17:52:25 但凡是個工程師，都會覺得能解決問題就成。至於學術上愛叫什麼名字都無所謂。只是個名字罷了，能達成共識就行了。 說重一點，委員會為什麼令人討厭？因為他們跟長連線一樣，消耗的資源比解決的問題多。 應用場景不一樣，糾結在一個名字上有什麼意思呢。 回家啃《黑客》去了。各位繼續。

009陳睿傑-小狗 17:53:14 哈哈，鈍刀，你還沒看完黑客麼

LZSoft·樑濤 17:55:54 剛開始啃。

LZSoft·樑濤 17:56:03 挺好看的。

LZSoft·樑濤 17:56:25 裡面有些祕史一類的東西。

018圖靈謝工 17:58:53 一本名副其實的 Web架構“聖經”——關於《HTTP權威指南》http://t.cn/zO3ApYN ，本書是計算機專家多年實踐經驗的總結，介紹了技術人員為了高效使用HTTP所需要知道的一切。本書即將於6月出版，市場上專門介紹HTTP的書幾乎沒有，本書是第一本。歡迎大家到圖靈社群發表高見。

018圖靈謝工 17:59:00 我這麼說，沒問題吧

018圖靈謝工 17:59:58 這句話表述，有問題沒

009陳睿傑-小狗 18:00:50 “全面”介紹的沒有

009陳睿傑-小狗 18:00:56 要說沒有，那太假了

009陳睿傑-小狗 18:01:04 那些REST書都講了不少

王旭泉 18:01:08 市場上專門介紹HTTP的書幾乎沒有，本書是第一本。。。有點羅嗦

018圖靈謝工 18:01:14 市場上專門全面介紹

018圖靈謝工 18:01:54 讓大家拍磚吧

009陳睿傑-小狗 18:03:25 書名都叫權威指南，就說是介紹HTTP相關知識最權威的資料不就得了

018圖靈謝工 18:03:39 本書不僅僅是一本 HTTP首部的參考手冊，它還是一本名副其實的 Web架構“聖經”。

018圖靈謝工 18:03:49 這些話都是這本書原書中所述的

009陳睿傑-小狗 18:04:49 是夠厚的

009陳睿傑-小狗 18:04:59 中文版多少頁

018圖靈謝工 18:06:27 一般原英文書的頁數打個8折左右就是中文的頁數

018圖靈謝工 18:06:57 想想作者寫本書真的不易，還是向作譯者們都致敬吧，太不容易了

賈洪峰 18:09:07 隨著年齡的增長，更能體會別人的不易。

賈洪峰 18:09:31 也就不那麼容易大動肝火了

018圖靈謝工 18:10:15 沒事，都拍我們，我們膽子越來越小，越來越不敢出書了，也不知是好事，還是壞事呢

018圖靈謝工 18:10:32 賈老師，看看這譯文感覺如何

018圖靈謝工 18:11:18 我會及時反饋意見給譯者和編輯，包括今天大家提出的傳輸的說法

賈洪峰 18:11:18 我就願意幹挑刺的活兒。哈哈

018圖靈謝工 18:11:50 賈老師，你這手上翻譯的書，份量也極重啊

賈洪峰 18:11:54 不幹活的總是有理的。:)

018圖靈謝工 18:11:58 是在翻譯《計算機體系結構》吧

賈洪峰 18:12:08 所以我現在提心吊膽的。

賈洪峰 18:14:31 有英文稿嗎？

018圖靈謝工 18:14:45 好象網上應該有

賈洪峰 18:15:30 最後一句不通，少了一個“的”字吧，這個不用看原文。:) 本書的譯者是來自解放軍理工大學通訊工程學院陳涓老師。

018圖靈謝工 18:15:49 這是我剛寫的

018圖靈謝工 18:16:23 本書譯者是來自解放軍理工大學通訊工程學院的陳涓老師。

5月22日討論內容：

018圖靈謝工 10:46:24 丁雪豐，HTTP這個傳輸和移送的翻譯問題，是不是一定要改過來

丁雪豐 10:47:03 移送？什麼移送？

李錕 10:47:49 就是昨天一群牛人整來爭去的那個transfer是否翻譯為傳輸的問題

018圖靈謝工 10:48:06 HTTP 在中國大陸被翻譯為“超文字傳輸協議”，因為“transfer”在中文裡有“傳輸”的含意。但依據 HTTP 定製者之一的 Roy Fielding 博士的論文[1]（6.5.3節），作者專門強調“transfer”表示的是“（表述狀態的）轉移”（Representational State Transfer），而不是“傳輸”（transport）。故其中文譯名“超文字傳輸協議”恰恰引種反映了這種誤解。更符合原義的譯名應該為“超文字轉移協議”。”

李錕 10:48:42 我參與了幾句，後來發現某些人實在太牛了，比HTTP 1.1原創作者Fiedling還要牛數倍。只好不敵而退。

018圖靈謝工 10:48:58 李老師，那個Fielding老師論文的那句話給我們一下，我們轉告譯者

丁雪豐 10:49:36 我是覺得有些約定俗成已經深入人心的翻譯，可以保留原來的翻譯，但加以標註。或者就索性不翻譯了，保留原文，加譯註。但是，這個意思還是要加以正確說明和引導的，不能一直誤解下去。

018圖靈謝工 10:50:05 是的，我們也是要這樣做的

張伸 10:50:13 同意不翻譯加譯註說明和引導。

李錕 10:50:25 http://www.ituring.com.cn/article/937 請仔細看一下我以前寫的blog：為何HTTP被翻譯為“超文字傳輸協議”是一次歷史上的重大翻譯錯誤？

018圖靈謝工 10:51:25 感謝李餛老師，糾正我們

018圖靈謝工 10:52:10 如果能全文通改，我們就儘量改，如果不能通改，我們想辦法加以顯著位置的說明

丁雪豐 10:52:29 所以我在我那本書裡，就是HTTP縮寫不翻譯，Hypertext Transfer Protocl完整表達，我就沒翻譯。但出現處，我加了譯註。加譯註是個關鍵，要告訴讀者，雖然我沒寫中文，但是我告訴你他是什麼意思，應該怎麼理解。

170姚琪琳 10:52:59 李老師，群裡沒人質疑您對HTTP的翻譯

李錕 10:53:26 陳涓老師最好能與我和小丁交流一下，陳老師的主要工作畢竟不是Web開發。

018圖靈謝工 10:54:21 我感覺，也許學校的所有教材或教學都沒改過來

丁雪豐 10:54:32 有些人就喜歡“傳輸”，看到“轉移”覺得有問題，那是他們理解的問題，但我們還是有義務把問題說清楚。一板磚拍死誰對誰錯，估計誰都不買賬。引導為主吧。

丁雪豐 10:55:53 是的，大家都看超文字傳輸協議看慣了，你一改，他就覺得你有問題，所以當時我和李錕商量了好久，我最後決定不翻譯加譯註，最後還把我們的討論寫在了書的序言裡。

李錕 10:56:58 transfer留著不翻譯也行，習慣性地翻譯為“傳輸”肯定是錯誤的。

018圖靈謝工 10:56:59 我剛和QA部的幾位同事說了，他們很重視，這書已經複審完成，就在排版校對了，所以會停下補充說明

胡金埔 10:57:43 什麼書？

018圖靈謝工 10:58:01 HTTP權威指南

楊博 10:58:01 嗯，可以考慮後面附上一篇討論的文章

李錕 10:58:04 Hypertext Transfer Protocol，不要再直接翻譯為“超文字傳輸協議”了。這是我的呼籲。

018圖靈謝工 10:58:34 我們編輯也說，這個錯誤年代太久了，圖靈不應該再犯了

胡金埔 10:59:00 好書。

009陳睿傑-小狗 10:59:19 嗯，這就對了

009陳睿傑-小狗 10:59:35 喜歡圖靈嚴謹的態度，也不枉我昨天提起這事兒

018圖靈謝工 10:59:59 非常感謝，衷心感謝大家，昨天晚上我回家看了一些文件，感覺問題比較嚴重

170姚琪琳 11:00:07 讀者之幸

李錕 11:00:10 HTTP不是一種傳輸協議，Fielding很多年來在很多場合強調過。這是理解HTTP協議本質的入門點。

009陳睿傑-小狗 11:00:35 關鍵的問題是，不能一錯再錯

018圖靈謝工 11:00:57 書好不好另說，出版者的主要職責要對讀者負責任，不能出偽科學的東西

郭義 11:01:05 李錕(44035001) 11:00:10 HTTP不是一種傳輸協議，Fielding很多年來在很多場合強調過。這是理解HTTP協議本質的入門點。 那這麼說。。國外一直理解也不是對的。。這就和翻譯沒什麼關係了。

009陳睿傑-小狗 11:01:28 又要鑽牛角尖了

009陳睿傑-小狗 11:01:36 是要繼續錯下去麼

李錕 11:01:41 HTTP其實是一種應用協議。不過本著人有多大膽地有多大產的革命樂觀冒險主義，非把HTTP當作傳輸協議來用，確實也死不了人。但是這是低效的用法，會付出一些代價。

郭義 11:02:00 哇哈哈。。

018圖靈謝工 11:02:06 其實是翻譯背後隱藏著更深的問題

009陳睿傑-小狗 11:02:28 http老爹其實會很傷心的，自己生了個兒子，別人非要說是女兒

018圖靈謝工 11:02:44 要知道一本書的傳播速度和影響力是很遠的

李錕 11:03:07 昨天有些同學反覆爭論架構設計的某個點能否達到最大化，這是沒有意義的。這些同學不理解其實架構設計就是權衡的藝術，一味追求某方面，就會忽視其他方面。

009陳睿傑-小狗 11:03:33 其實最好的辦法還是丁老師那樣，不做翻譯，然後譯者注澄清一下這個問題

李錕 11:04:20 HTTP協議為何要這樣設計、設計出來是為了做什麼事情，指導思想是REST。REST其實就是中庸之道，沒什麼神祕。

009陳睿傑-小狗 11:06:30 建議大家多看看書，那本 REST實戰 我覺得是目前看過的討論最深入的，推薦

009陳睿傑-小狗 11:06:44 權威指南這本，我也要收藏一本做參考

018圖靈謝工 11:06:56 感謝@dlee_cn @DigitalSonic @琳琳的小狗 等大家的意見，本書對HTTP的譯法“超文字傳輸協議”，和實際的譯法”超文字轉移協議“，會和譯者溝通後，在重要位置做說明。

018圖靈謝工 11:07:03 我這樣寫一下

009陳睿傑-小狗 11:07:22 嗯，反正改不改正文無所謂，但是一定要說清楚

009陳睿傑-小狗 11:07:54 名詞被誤傳了不是問題，只要大家知道真正的含義就行了

009陳睿傑-小狗 11:08:28 如果大家都明白HTTP被發明的初衷，這個詞的叫法其實也無關緊要，但是現在的關鍵是，很多人理解就有問題

賈洪峰 11:17:57 我現在在想，這個是中國人錯誤理解了Transfer，還是英美人也錯誤理解了Transfer

賈洪峰 11:19:13 如果是因為Transfer對應於中文的“傳輸”和“轉移”，而最初的翻譯者錯用了“轉移”，那就絕對是因為錯誤翻譯而導致誤解。

但如果國際上的大多數人也認為Transfer是delivery information，那就和翻譯沒有任何關係了。

009陳睿傑-小狗 11:19:36 現在的事實是，中文名詞翻譯就錯了，你說是誰的錯

009陳睿傑-小狗 11:19:57 好比賣刀的，賣給你，你殺人了，是要怪商販麼

賈洪峰 11:20:46 您沒明白我的意思。

009陳睿傑-小狗 11:20:54 沒有任何跡象表名，國際上“大多數”人也認為ransfer是delivery information

009陳睿傑-小狗 11:21:19 這個論據本來就站不住腳

賈洪峰 11:21:49 我說的是如果！

009陳睿傑-小狗 11:22:10 那你說的沒錯

李錕 11:36:30 首先要明確一下，transfer這個詞語，在HTTP/FTP這些IETF協議中，和transport有明確的區分。本身根本就沒有“傳輸”（transport）的含義，幾乎從來不會與transport混用。

李錕 11:37:17 思而不學則殆，同學們。把HTTP或者FTP協議中找一段出來，大家一起分析一下transfer到底說的是什麼。

圖釘派_111_DP 11:37:28 討論來這裡 http://zh.wikipedia.org/wiki/Http

李錕 11:38:38 寫到維基百科，是個很好的想法

郭義 11:38:42 其實我覺得吧。。

009陳睿傑-小狗 11:40:48 確定不是被kill掉的？哈哈

賈洪峰 11:45:46 1991年，Tim Berners-Lee

Roy Fielding

這兩個人是什麼關係？

賈洪峰 11:45:58 合作者？

LZSoft·樑濤 11:46:49 從高層抽象來看，HTTP不就是個跨機器邊界的執行流（執行狀態）轉移麼。跟僅有兩節點的令牌環有區別麼？找個能描述這種互動模式的中文詞不就成了。翻譯是一碼事，能不能推廣是另一碼事。 假設從今天開始，某人統一用“超文字轉移協議”代替“超文字傳輸協議”來討論技術問題。然後跟每一個人解釋其間的差別，時間開銷乘以解釋次數……好吧，不用幹活了。 竊以為小狗同學的建議是比較中肯也比較合適的。加個譯者注便完了。作者的定義要尊重，譯者的譯法要尊重，那使用者的習慣不需要尊重了？

李錕 11:49:50 Tim Berners-Lee是Web之父，W3C的領導者。Roy Fielding是Web架構的主要設計者之一，HTTP 1.1協議專家組負責人，REST架構風格的發明人，也參與了URI等Web基礎協議的設計工作。他們是合作關係。HTTP 1.1因為是屬於TCP/IP協議棧中的應用層協議，所以交給了IETF來發布。W3C與IETF有非常密切的合作。

賈洪峰 11:50:33 Tim Berners-Lee在最早提出HTTP時，用意和roy

賈洪峰 11:50:40 和Roy相同嗎？

李錕 11:51:42 那是HTTP 1.0協議，HTTP 1.1協議有非常大的發展。

李錕 11:52:25 URI、HTTP、MIME、HTML，這幾個協議是Web的基礎架構協議。

賈洪峰 11:53:11 比如HTTP 1.0協議中，transfer就是傳輸的意思，Roy做1.1時加以擴充套件或引申，用作轉換。有沒有這種可能。

009陳睿傑-小狗 11:54:24 看看HTTP被劃分到的層次就知道了，屬於應用層而非傳輸層

賈洪峰 11:54:38 HTTP 1.0中呢？

賈洪峰 11:54:51 我完全是門外漢，是請教，不是抬槓呢。:)

李錕 11:55:33 其實如果深入理解REST，尤其是理解了超文字驅動這個概念，就不得不和語義網扯上聯絡。所以Fielding和Tim Berners-Lee的架構思想完全是一致的。

009陳睿傑-小狗 11:56:17 1.0也沒有任何跡象表名，transfer是傳輸的意思吧，求證據

郭義 11:56:36 １.２　什麼時候出？

009陳睿傑-小狗 11:56:36 transfer和transport根本就是不一樣的

李錕 11:56:37 HTTP 1.1協議中，transfer早就不是傳輸的意思了。從1999年釋出到現在都多少年了？

賈洪峰 11:56:56 現在能不能確定1.0中是什麼意思？

009陳睿傑-小狗 11:56:56 從來沒有混淆過，不知道你們的論據怎麼來的，臆測麼？做學問不能這樣

賈洪峰 11:57:19 呵呵，我從來也沒有論據，我是想知道最初的人為什麼會犯這個錯誤。

李錕 11:57:29 HTTP 1.1協議設計的太成功了，所以IETF認為這方面的工作已經完成，解散了專家組。

郭義 11:57:49 哦。。

009陳睿傑-小狗 11:58:00 transfer那裡定義為傳輸的，非常想找到根源

郭義 11:58:06 那就按　１.１的版本譯就ok了。

009陳睿傑-小狗 11:58:30 找到了就豁朗了，直至中文翻譯的罪惡根源，呵呵

郭義 11:58:47 這事真不見得事翻譯的問題。。

賈洪峰 11:59:02 對，我也是這個意思，看看這個“傳輸”是徹頭徹尾的誤譯，還是有一些的淵源

郭義 11:59:16 rest　大概０６年　以後開始重提的。。

009陳睿傑-小狗 11:59:38 rails框架的功勞，DHH大神的影響力

李錕 11:59:55 HTTP 1.0中，transfer也不是傳輸的意思。我可以肯定地告訴諸位。

009陳睿傑-小狗 12:00:11 嗯，我也覺得，transport才是，差別很大的嘛

李錕 12:00:14 transfer和transport的差別，我已經研究過很多年。

郭義 12:00:15 那個時候。。在http　之上　　soap協議　大家覺得太笨重了。。。所以http的設計初衷又被重提。。。

李錕 12:01:15 在IETF的RFC中，“transport”（傳輸）的含義是指：從端到端（例如從ip1:port1到ip2:port2）可靠地搬運位元，也就是TCP/IP協議棧中的第3層傳輸層（transport layer）協議所做的那些事情。

李錕 12:01:29 將“transport”翻譯為“傳輸”，100%正確！

郭義 12:01:44 我堅決擁護把翻譯搞的精準。。以免誤人子弟。。

李錕 12:01:46 而“transfer”的含義是：通過在客戶端-伺服器端之間轉移一些帶有操作語義的操作原語，來執行某種操作。“transfer”是TCP/IP協議棧中的第4層應用層的概念，而不是第3層傳輸層的概念。“transfer”所轉移的是帶有明確操作語義的操作原語，而不是沒有操作語義的位元流。

郭義 12:02:52 但是。。http　這事深入的說。。真不是一個簡單的翻譯問題。。

郭義 12:03:58 rest　之前　。。很少有在應用中把http協議做操作語義來使用。。如果那樣譯成轉移，返回增加了讀者理解難度。

李錕 12:04:00 HTTP 1.0和HTTP 1.1最大的區別是什麼，我接下來詳細解釋。

郭義 12:04:33 幾遍現在好像也不多。。

李錕 12:05:04 HTTP 1.0基本上就是一個伺服器端靜態檔案的操作協議，並沒有抽象的資源概念，HTTP 1.0認為Web伺服器上就是一大堆靜態檔案。

郭義 12:06:46 得建立公正的前提下。。

李錕 12:06:50 HTTP 1.0裡面的transfer，就是傳遞、轉移檔案。有人把它理解為傳輸，似乎也可以。但是在協議裡面，傳輸transport其實指的是搬運bit層次的苦力活。

賈洪峰 12:07:19 如果這樣說，那就絕對不是翻譯的問題！

009陳睿傑-小狗 12:07:40 還在扣啊

郭義 12:07:44 哈哈。。

郭義 12:07:47 開胃。啊。。

009陳睿傑-小狗 12:07:49 你繼續守著這個翻譯好了，沒人阻攔你

李錕 12:08:18 如何來很好地支援動態內容，是HTTP 1.1協議要解決的一個主要問題。

賈洪峰 12:08:43 文字交流會有這個問題，看不到對方的表情。

郭義 12:09:02 你的意思　弄個茶話會？

賈洪峰 12:09:21 可以請謝老師考慮，哈哈。

郭義 12:09:25 我覺得弄這個比做培訓有意思。。。

賈洪峰 12:09:25 不過，我肯定是參加不了的。

李錕 12:09:36 因此就發明了一個新的概念叫做資源，注意：資源和麵向物件程式設計裡面的物件類似，是一個抽象的工具。資源不僅僅可以代表伺服器端一個檔案、資料庫中一條記錄這類具體的東西。可以要多抽象有多抽象。

009陳睿傑-小狗 12:09:43 聽李老師講完嘛，你們這幫傢伙

郭義 12:09:44 你可代表一方觀點啊。

賈洪峰 12:10:12 在這件事上，我沒有觀點。我只是想理清前後原因。

李錕 12:10:46 有了資源之後，還需要設計一個統一的介面來操作資源。否則每一個資源操作的方式都不一樣，那樣做會嚴重降低Web應用的可伸縮性。

郭義 12:12:28 不過插一句。。http是協會搞出東東。。所以。。。會考慮的全面，嚴謹些。

李錕 12:12:35 統一介面包括的內容很豐富，可以參考我寫的部落格。

009陳睿傑-小狗 12:13:54 我也插一句，其實，李老師是在普及HTTP知識喲，如果你們看過很早就出版的那本囉嗦至極的《RESTful webservice》，就不會覺得新奇了：）

郭義 12:14:31 很早看的了。。記憶已經模糊了。

郭義 12:16:31 其實作為一個技術小白來說。。。超文字傳輸協議。來源大概是為了考慮讀者理解來說的。

郭義 12:16:53 我的想法是這樣。。。

郭義 12:16:57 tcpip

郭義 12:17:18 tcpiip協議大家說事傳輸協議。。這個沒爭論吧。

李錕 12:18:00 別想的那麼複雜，第一個翻譯HTTP的傢伙，沒準就是喝了點小酒，憑感覺就直接翻譯為“傳輸協議”了。這和第一個翻譯FTP的傢伙類似。

郭義 12:18:37 所以。。當時的譯者　一定是這樣想的。。http協議是其上的應用層，，而且事針對超文字的。。所以叫乘超文字傳輸協議。。讀者理解起來順理成章。。。

李錕 12:18:53 HTTP/FTP/NNTP..... 全是應用層協議。transfer是應用層的概念。

李錕 12:19:16 傳輸這件事情，TCP+UDP已經乾的很好了

郭義 12:20:17 是的。。但是　按我剛才說的這麼想。。譯者當時這麼想也說的過去。

009陳睿傑-小狗 12:20:30 應用層是不用關心傳輸的事兒的

009陳睿傑-小狗 12:21:00 就好比你去郵局寄信，不會去關注郵差的活兒

009陳睿傑-小狗 12:21:18 其實說起來，http還真和郵局很相似

郭義 12:21:45 啊～～

009陳睿傑-小狗 12:21:52 難道你不覺得麼

009陳睿傑-小狗 12:21:57 那些header

郭義 12:22:09 我覺得email　協議更想了。。

009陳睿傑-小狗 12:22:39 囧，你看名字就知道了，mail……

賈洪峰 12:23:22 再請教一下，“轉移”和“傳輸”從中文含義上怎麼區分呢？

009陳睿傑-小狗 12:26:18 你去寄信，信封上的東西，比如地址、郵編，是有語義的，你可以看作是“應用層”的東西，你通過信件“轉移”你的想法給對方；郵局的派送車，只管幫你運輸的，那個是“傳輸層”的東西，幫你“傳輸”這封信件。不知道我能不能這麼理解

009陳睿傑-小狗 12:27:31 對應到HTTP協議的內容，request header、response header，就是信封上的元資訊，body是你的信件內容，就差不多了嘛

009陳睿傑-小狗 12:28:08 http很依賴這些元資訊的，它根本不關注整個東西是怎麼送達到對方手裡的，這有問題麼？沒有吧

009陳睿傑-小狗 12:28:31 傳輸有TCP、IP在做了

009陳睿傑-小狗 12:29:07 其實要真正明白區別，就要明白資源的概念

賈洪峰 12:29:09 這是“高階漢語詞典”中的解釋

009陳睿傑-小狗 12:29:22 資源是抽象的概念，你不可能在網路上真正的交換一個資源實體

009陳睿傑-小狗 12:29:36 你只能操作表述

009陳睿傑-小狗 12:29:44 資源永遠無法直接觸及

009陳睿傑-小狗 12:30:02 沒有仔細看過REST的書，不能理解這其中的差別很正常

009陳睿傑-小狗 12:30:56 在REST架構中，伺服器和客戶端之間都只能通過資源的表述來進行交流，而非資源本身，這就是為什麼要用“轉移”來稱呼這個操作

009陳睿傑-小狗 12:31:03 轉移表述，而非傳輸資源

009陳睿傑-小狗 12:31:40 不知道我這麼說能不能打消你的疑慮，如果不行，只能建議你看看RESTful web service了，那本純入門

LZSoft·樑濤 12:37:28 對此我有一個簡單定義。Transport會有持續存在的副本產生，原本和副本存在於不同的執行環境中。Transfer沒有副本產生，原本會完整移動到接受端執行環境中，傳送端環境不予以留存，降低狀態不一致的可能性。

009陳睿傑-小狗 12:39:22 太抽象了，你這個比資源本身還抽象，囧

009陳睿傑-小狗 12:39:25 無法理解，哈哈

LZSoft·樑濤 12:46:19 所以說做不了學術。解釋不清楚。

LZSoft·樑濤 12:46:41 但是REST要解決的一個問題就是快取。

LZSoft·樑濤 12:46:56 維護一致性的成本有時高得離譜。

LZSoft·樑濤 12:51:41 小狗，還有一個解釋。轉移是Ctrl-X Ctrl-V，傳輸是Ctrl-C Ctrl-V。清楚不？

009陳睿傑-小狗 12:56:35 我覺得不能這樣說誒，比如資源，不能說是剪貼到客戶端了吧，只能說資源的狀態（表述）被傳遞給客戶端了，所以這麼一來，cv更合適

LZSoft·樑濤 12:56:56 只是表達一下概念嘛。

009陳睿傑-小狗 12:57:04 不過如果主語是表述，那也可行

LZSoft·樑濤 12:57:52 這樣解釋的話我想用過Windows的人基本都能理解輪廓了。

009陳睿傑-小狗 12:57:54 HTTP注重了可伸縮性，自然一致性方面就不能兩全了，李老師之前說的，談論一個架構，是要放到特定的上下文環境中的

LZSoft·樑濤 12:57:59 再細講應該會容易點。

009陳睿傑-小狗 12:58:38 要實現一個完美無缺相容百家所長的架構，根本不可能

LZSoft·樑濤 12:58:48 所以嘛。

009陳睿傑-小狗 12:58:59 要伸縮，要容錯，又要一致，哪裡找去哦

LZSoft·樑濤 12:59:05 爭論長短連線是不是普適意義不大的。

LZSoft·樑濤 12:59:44 爭論長短連線何時何地特適才有意義。

009陳睿傑-小狗 13:00:13 所以我才說，那個可以採用更合適的方案，在專案裡面我用node來處理這個了

LZSoft·樑濤 13:01:35 不會有人傻到在嵌入式通訊系統上架個REST的。那不適合，就這麼簡單。

009陳睿傑-小狗 13:09:16 但是對於我這種頁面崽兒，不得不關注啊

009陳睿傑-小狗 13:09:26 別人我管不著，自己可是要天天打交道

018圖靈謝工 13:15:13 剛才吃飯，和鬆峰他們也在爭論這個問題

009陳睿傑-小狗 13:16:17 不知道能不能討論出個結論來

018圖靈謝工 13:19:08 鬆峰說轉移也不太準確

009陳睿傑-小狗 13:22:46 但是，達成的共識是，傳輸 是不靠譜的翻譯，對不對

LZSoft·樑濤 13:23:19 明顯不對。

圖釘派_007_LL 13:31:31 怎麼能叫轉移呢？

圖釘派_007_LL 13:31:59 叫

鄧聰 13:32:20 我感覺吧，討論的點在，http剛出現端到端的場景了與http後來被用做rest style的架構的場景 被賦予的意義就不同了

LZSoft·樑濤 13:32:49 @鄧聰 這是一個分歧點，頂。

賈洪峰 13:32:54 嗯，我與鄧聰的感覺一直，但沒查到原始文件

圖釘派_007_LL 13:33:09 叫漂移

009陳睿傑-小狗 13:33:13 現在的關鍵是，在當下這個環境，一定要明確其真正的含義

009陳睿傑-小狗 13:33:41 要不然，HTTP還是會被人誤用，搞RPC、SOAP那類

009陳睿傑-小狗 13:34:04 理解這個點，是首要先絕條件

鄧聰 13:34:38 看過今天與以往的討論 李老師對rest研究下了很多功夫

009陳睿傑-小狗 13:34:41 從名字上就給人誤導，你還指望他去深入掌握REST麼，搞笑

LZSoft·樑濤 13:34:57 舉個例子，網遊裡的連線維持心跳包機制，屬於“傳輸”還是“轉移”？

009陳睿傑-小狗 13:35:00 dlee是國內REST架構的先驅

018圖靈謝工 13:35:09 移送

鄧聰 13:35:14 得 別當權威了

鄧聰 13:35:38 所以還是先搞清場景 再討論到底什麼翻譯吧

009陳睿傑-小狗 13:35:39 姑且不管權威不權威，人家付出的努力你們怎麼就看不到

018圖靈謝工 13:35:48 反正討論還是有價值的

鄧聰 13:36:05 那篇論文也是2K年出來的 沒準現在不同場景下 又發生了變法

018圖靈謝工 13:36:14 李鬆峰

：怎麼判斷翻譯字面化？我有一個經驗，就是看翻譯在字面上是否可逆。如果中文譯文很容易讓人聯想（或對應）到原文字面，那就是翻譯字面化。當然，對於簡單的或特定的翻譯，字面化不一定是問題。但如果字面化的情況非常普遍，那翻譯肯定有問題。結論是：好譯文應該在字面上不可逆。 009陳睿傑-小狗 13:37:18 上面的上面的上面，REST最近被提起來，恰恰推翻了你的說法

李錕 13:37:36 沒什麼權威不權威的，韓寒同學早就批判過權威了。首先第一步，不要習慣性地把transfer翻譯為“傳輸”肯定是正確的。尤其是在HTTP這個專業術語裡面。雪豐建議不要翻譯為中文，我很贊同。

009陳睿傑-小狗 13:38:00 現在有更多的人回頭思考HTTP的起源，以及他的架構思路

鄧聰 13:38:27 你是看到結果了，然後按照你的結果去推倒起源嗎？

009陳睿傑-小狗 13:38:37 DHH這種頑固分子都這樣了

李錕 13:39:01 transfer我建議翻譯為轉移、傳遞。有些同學感覺不準確，這是因為漢語在這方面的細膩程度不夠。

LZSoft·樑濤 13:39:04 從工程角度去看，一開始有架構定義麼？

009陳睿傑-小狗 13:39:25 論文，要看定義請先仔細看過論文，這是討論的前提！

LZSoft·樑濤 13:40:33 我覺得不從HTTP本身出發，而是從其前身去探究，說不定當時的含義就是在兩個端點間傳點什麼文字罷了。

李錕 13:40:43 transfer和transport的區別，我前面已經詳細解釋過了。主要區別就是一個有操作語義，一個完全沒有操作語義。

鄧聰 13:40:50 HTTP權威指南 貌似不是說 REST http的架構 弄個http1.0到http1.1升級後 當下賦予的意義 弄個故事會 倒不錯 哈哈哈哈哈

LZSoft·樑濤 13:40:56 只是後來發現這樣設計在某些場景下非常適用，於是寫Paper規範化。

李錕 13:41:33 思而不學則殆，同學們。爭論這麼長時間，也不肯自己去讀一下協議原文？

鄧聰 13:41:51 你怎麼知道我們沒去看協議原文？

LZSoft·樑濤 13:42:01 讀過了。

李錕 13:42:11 找來原文再爭論吧，否則老是轉圈圈，其實沒前進，完全是浪費時間。

009陳睿傑-小狗 13:42:22 我倒是感覺，roy當初參與設計http的時候，心裡早就有譜的了，肯定不是後來才發現，咿，我的架構可以幹這個誒

LZSoft·樑濤 13:43:32 跟理想主義做鬥爭的確屬於浪費時間。

李錕 13:43:50 找來原文，證實一下你的想法。

李錕 13:44:52 扣帽子也是國人的習慣之一

圖釘派_007_LL 14:02:48 你們討論後統一了，告訴我答案就好。

009陳睿傑-小狗 14:03:02 打擊伸手黨

圖釘派_007_LL 14:03:43 討論無果的話，你們的能力就太差了。

圖釘派_007_LL 14:03:51 以後就別混。

賈洪峰 14:04:03 嘿嘿

李錕 14:04:59 知識背景不一樣，爭論很難有定論。聞道有先後，術業有專攻而已。

圖釘派_007_LL 14:06:24 聞道有先後，術業有專攻，討論後無果，專攻也白搭。

009陳睿傑-小狗 14:06:25 別爭論了，看看圖靈這本書最終怎麼處理吧，反正我就那個建議，加譯者注說明下

009陳睿傑-小狗 14:06:49 伸手黨別摻和了，你也等這書出來好了

李錕 14:07:07 相互妥協的做法就是保留HTTP不要翻譯

009陳睿傑-小狗 14:07:53 縮寫可以不翻譯，但是如果原文是全稱怎麼處理？

009陳睿傑-小狗 14:08:13 統一都不翻譯麼，只好如此了

李錕 14:09:02 直接問丁雪峰，他為這個問題也糾結過一段時間

圖釘派_007_LL 14:09:18 當HTTP已經成為烙印，任何名稱對它來說都是多餘

009陳睿傑-小狗 14:09:48 想起來了，他的那本書裡面的確是沒有翻譯的

圖釘派_007_LL 14:10:39 呃，忘了加問號：“？”

李錕 14:10:49 不過相對來說，Fielding的意見在這個問題上，權重顯然要大過所有人。

李錕 14:11:10 如果確實有人是權威的話，那就是HTTP 1.1協議的原創者Fielding。

李錕 14:11:20 非要爭論Fielding是不是權威，那就顯得有些無聊了。

郭義 14:11:59 牛xx，，還在繼續。。。。

圖釘派_007_LL 14:15:31 牛xx，，還在繼續。。。。

李錕 14:15:45 對於這個問題，Fielding本人是什麼意見呢？請看這裡： http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm 6.5.3 HTTP is not a Transport Protocol

李錕 14:16:29 不過我還是代勞翻譯一下： HTTP is not a Transport Protocol HTTP並不是一種傳輸協議

郭義 14:17:07 我覺得吧。。。如果拿社會主義來比喻，，，當初馬列的社會主義。。和　我黨的社會主義。。一樣嗎。。

李錕 14:17:43 行了，詭辯我就不參與了。

郭義 14:18:12 哦。。

郭義 14:18:50 老李的觀點就是　field的觀點。。

圖釘派_007_LL 14:18:51 好吧，HTTP是一種網路協議

郭義 14:20:03 現在的核心問題就是要不要統一到field的觀點。。

李錕 14:21:29 你們誰重視過Fielding的觀點啊，都比Fielding牛多了。我昨天就完全承認過。

鄧聰 14:22:47 都為了把這本書能高質量出版而已 別醬紫了

李錕 14:22:58 如果我想了解孔子的觀點，我肯定會自己去直接讀《論語》。當然我承認論語不是孔子本人寫的，但是總比去讀什麼《張批論語》、《王批論語》強吧？

鄧聰 14:23:04 話說這本書夠厚啊

郭義 14:24:34 http　那本書是誰寫的啊。。

018圖靈謝工 14:24:51 我在社群文章下面提到了

郭義 14:25:44 可以問下http作者　和　field的意見。。。

李錕 14:27:08 我把Fielding的郵箱給各位同學，各位同學直接和Fielding聯絡。

郭義 14:27:41 嗯。。http那本書的也給下吧。。

李錕 14:34:26 Fielding有3個郵箱，可以都試一下。我也不清楚他現在是否還常用，不過專家通常不會經常換郵箱的。 fielding@apache.org fielding@w3.org fielding@day.com

郭義 14:35:02 我去試試。。不過我英文不好。。中文不知道是否他認識。

郭義 14:35:22 http那本書的作者也是他嗎。。

李錕 14:35:46 Fielding不認識，不過他的夫人認識。他的夫人是臺灣人。

李錕 14:36:03 HTTP權威指南，作者不是Fielding

郭義 14:36:04 牛xx。。。那就好辦了。。

郭義 14:36:27 HTTP權威指南　也給問下。。畢竟我們們翻譯人家的書，，

賈洪峰 14:36:39 嗯，一定問問他，Http 0.9中的那個transfer到底想表達個什麼意思

李錕 14:38:10 Email: fielding at (choose one of) gbiv.com, adobe.com, apache.org 這幾個郵箱應該可以用

李錕 14:38:44 Fielding現在估計還在Adobe，因為他創辦的公司DaySoft前年被Adobe收購了

丁雪豐 15:09:43 呃，去開了個會回來，發現大家又討論了一堆。《RESTFul WebServices Cookbook中文版》裡，我HTTP和Hypertext Transfer Protocl都沒有做翻譯，在後者出現時加了個譯註，在譯者序裡，對這個詞的翻譯的討論做了點說明。transfer單獨出現時，翻譯為“轉移”。

018圖靈謝工 15:10:36 我轉告李鬆峰了

丁雪豐 15:11:02 恩

009陳睿傑-小狗 15:14:47 丁老師這個做法最討巧了

009陳睿傑-小狗 15:15:19 無懈可擊，贊一個，哈哈哈

丁雪豐 15:15:37 是的，我就是討論了半天，然後不想再折騰了，呵呵。。。

009陳睿傑-小狗 15:15:58 圖靈可以效仿

李錕 15:17:07 目標就是避免讀者把HTTP協議繼續誤以為是一種傳輸協議，這是我們譯者和出版社的共同責任。

鄧聰 15:19:26 這個方法真心好

賈洪峰 15:22:55 HTTP權威指南的正文中明確指出：HTTP是在應用層，下面的事交給TCP/IP去做

李錕 15:24:00 對，這個理解是正確的，也是Fielding等原創作者的觀點。

李錕 15:24:19 但是如果一開始就直接告訴讀者，HTTP是超文字傳輸協議，讀者肯定會被搞暈。

009陳睿傑-小狗 15:25:18 被搞成常規翻譯了，不好改也無所謂，知道真相就行了，然後加個註釋說明，最好學丁老師，統一不去翻譯，哈哈

李錕 15:27:44 SOAP的一個決策失誤，就是它把HTTP當作傳輸協議來用。SOAP其實是把HTTP、SMTP都當作傳輸協議來用，還非常得意。

賈洪峰 15:27:44 我現在想搞清楚的是這個“傳輸”是純粹的誤譯，還是有歷史淵源。

李錕 15:28:30 但是現在在網際網路上，還有誰在繼續沿用SOAP呢？除非一些歷史遺留原因，所有面向網際網路的Web服務/API全部都轉到REST風格了。

009陳睿傑-小狗 15:28:31 這個就不用糾結了吧，除非能找到當初第一個翻譯這個名詞的人

009陳睿傑-小狗 15:29:01 REST是網際網路應用的趨勢，但是我個人現在迷惑的還是那個 超媒體驅動

009陳睿傑-小狗 15:29:17 實在是太沒有概念了，還需要不斷學習研究，囧

賈洪峰 15:29:32 微軟的術語翻譯還是比較嚴謹的，他們都一直用“超文字傳輸協議”這個詞，我覺得值得研究一下。

李錕 15:29:44 先實現資源抽象+統一介面，已經可以帶來很多好處。超文字驅動可以逐漸去實現。

009陳睿傑-小狗 15:29:59 現在專案中實際應用的，只能算的上理查德森所說的第二級，也就是CRUD風格的

李錕 15:30:23 暈，微軟又能怎樣呢？微軟和IBM就是SOAP/WSDL老式Web服務的創造者。

009陳睿傑-小狗 15:30:24 這個也要怪Rails這個框架，搞個這種限制的實現出來誤導大家

李錕 15:31:14 Fielding博士論文第6章，很大程度上就是講給微軟、IBM內部一些傲慢的企業應用整合專家聽的，就是創造出SOAP/WSDL這群人的。

李錕 15:32:06 這幫傢伙曾經搞出了一大堆笨重的網路協議，現在有很多人用嗎？

李錕 15:33:42 其實現在很多傳統Web服務/SOA的大牛都轉向了支援REST風格，因為他們發現REST能夠給SOA帶來非常多的價值。

009陳睿傑-小狗 15:34:00 杯具的是現在國內內多所謂的企業應用，還在搞這個，特別是國企，哎

009陳睿傑-小狗 15:34:37 有本講SOA和REST的書，不知道現在情況怎麼樣了

郭義 15:35:28 網際網路開發　和軟體開發　是不是兩個領域？

LZSoft·樑濤 15:35:36 喲，大頭。

李錕 15:36:10 《SOA with REST》今年9月出版，陳冀康老師已經承諾人民郵電出版社會引進這本書。

009陳睿傑-小狗 15:36:16 這個就是之前討論的，上下文範疇了

009陳睿傑-小狗 15:36:26 哈哈，陳老師威武

009陳睿傑-小狗 15:36:55 兩個風風火火的名詞出現在書裡面，還是很牛逼的

009陳睿傑-小狗 15:37:00 書名

李錕 15:37:04 一向都是Web開發的技術滲透到企業應用開發領域，反例我確實很少見到。

李錕 15:37:53 REST就是為面向網際網路的Web應用量身定製的一種架構風格，不要總是脫離這個執行環境來討論架構的優劣。

郭義 15:39:06 。。IBM　和　微軟　用　soap的優點是什麼呢？

圖釘派-34徐浩然 15:39:38 穩定

圖釘派-34徐浩然 15:39:39 安全

圖釘派-34徐浩然 15:39:42 詳細

圖釘派-34徐浩然 15:39:44 可溯源

圖釘派-34徐浩然 15:39:50 至於效能，反正我們有的是錢，對吧

圖釘派-34徐浩然 15:39:53 我們沒，客戶有

郭義 15:40:02 ok。。那就說。　還是有他們的道理的。

LZSoft·樑濤 15:40:22 那些大公司是靠創造技術概念賺錢的。

李錕 15:40:23 SOAP都是歷史遺留技術了。如果現在還問，Sun選擇EJB有什麼好處，根本就不需要回答。

009陳睿傑-小狗 15:40:32 007，首當其衝，我是第一個引起爭論的人，哈哈哈

鄧聰 15:40:40 一個時段的產物而已，感覺

009陳睿傑-小狗 15:40:42 要不然這事兒估計就不會這樣了

李錕 15:40:45 我們主要做Web開發的人來說，SOAP/EJB都是討厭的東西，我們從來都不會接觸到。

郭義 15:41:08 哦。。

鄧聰 15:41:09 比較討厭，繁瑣

李錕 15:41:24 其實阿里淘寶這樣的大型網站，也幾乎沒聽說哪裡還在用SOAP或者EJB

009陳睿傑-小狗 15:41:57 EJB是過街老鼠現在沒人質疑了吧，我在想，同樣的事情很可能繼續發生哦

李錕 15:41:59 是騾子是馬拉出來溜溜，這麼大的流量，SOAP/EJB很快就死翹翹了。

郭義 15:42:00 soap　和ejb　有必然關係？

009陳睿傑-小狗 15:42:13 囧，你怎麼就不懂得舉一反三呢

郭義 15:42:28 哈哈。。討論嗎。。

郭義 15:42:46 總得有人　提出質疑，，有人解答嘛。