翻译是一份严谨的工作——关于HTTP中文翻译的讨论

读者点评/专家导读 同时被 2 个专栏收录
73 篇文章 0 订阅
41 篇文章 0 订阅

讨论参与者共16位:

 

图灵谢工

杨博

陈睿杰

贾洪峰

李锟

丁雪丰

郭义

梁涛

吴玺喆

邓聪

胡金埔

臧秀涛

张伸

 

图钉派007LL

图钉派111DP

图钉派-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

这是Microsoft的文档

 

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

如果没有1.1的长连接。。。大量请求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 大约。每妙。要2万。。。如果用短连接要很多机器的。。

 

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

qps2万。上了负载 后面也得不少机器的。

 

邓聪 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到底说的是什么。

 

图钉派111DP 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

1.2 什么时候出?

 

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

那就按 1.1的版本译就ok了。

 

009陈睿杰-小狗 11:58:30

找到了就豁朗了,直至中文翻译的罪恶根源,呵呵

 

郭义 11:58:47

这事真不见得事翻译的问题。。

 

贾洪峰 11:59:02

对,我也是这个意思,看看这个“传输”是彻头彻尾的误译,还是有一些的渊源

 

郭义 11:59:16

rest 大概06年 以后开始重提的。。

 

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

明显不对。

 

图钉派007LL 13:31:31

怎么能叫转移呢?

 

图钉派007LL 13:31:59

 

邓聪 13:32:20

我感觉吧,讨论的点在,http刚出现端到端的场景了与http后来被用做rest style的架构的场景 被赋予的意义就不同了

 

LZSoft·梁涛 13:32:49

@邓聪 这是一个分歧点,顶。

 

贾洪峰 13:32:54

嗯,我与邓聪的感觉一直,但没查到原始文档

 

图钉派007LL 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

扣帽子也是国人的习惯之一

 

图钉派007LL 14:02:48

你们讨论后统一了,告诉我答案就好。

 

009陈睿杰-小狗 14:03:02

打击伸手党

 

图钉派007LL 14:03:43

讨论无果的话,你们的能力就太差了。

 

图钉派007LL 14:03:51

以后就别混。

 

贾洪峰 14:04:03

嘿嘿

 

李锟 14:04:59

知识背景不一样,争论很难有定论。闻道有先后,术业有专攻而已。

 

图钉派007LL 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

直接问丁雪峰,他为这个问题也纠结过一段时间

 

图钉派007LL 14:09:18

当HTTP已经成为烙印,任何名称对它来说都是多余

 

009陈睿杰-小狗 14:09:48

想起来了,他的那本书里面的确是没有翻译的

 

图钉派007LL 14:10:39

呃,忘了加问号:“?”

 

李锟 14:10:49

不过相对来说,Fielding的意见在这个问题上,权重显然要大过所有人。

 

李锟 14:11:10

如果确实有人是权威的话,那就是HTTP 1.1协议的原创者Fielding。

 

李锟 14:11:20

非要争论Fielding是不是权威,那就显得有些无聊了。

 

郭义 14:11:59

牛xx,,还在继续。。。。

 

图钉派007LL 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的观点。。

 

图钉派007LL 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

总得有人 提出质疑,,有人解答嘛。

  • 0
    点赞
  • 0
    评论
  • 0
    收藏
  • 一键三连
    一键三连
  • 扫一扫,分享海报

©️2021 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值