为何HTTP被翻译为“超文本传输协议”是一次历史上的重大翻译错误??!!

原贴地址：http://www.ituring.com.cn/article/937?1364996918

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”的含义。