【轉】關於HTTP中文翻譯的討論
http://www.ituring.com.cn/article/1817
討論參與者共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 [email protected]
李錕 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 [email protected]_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個郵箱，可以都試一下。我也不清楚他現在是否還常用，不過專家通常不會經常換郵箱的。 [email protected] [email protected] [email protected]
郭義 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 總得有人 提出質疑，，有人解答嘛。
【轉】關於HTTP中文翻譯的討論