二进制协议与文本协议

Question

没有人有什么二进制协议是一个很好的定义？实际上什么是文本协议？在线路上发送的比特是如何相互比较的？

这里是维基百科说，关于二进制协议：

二进制协议是其目的或预期要读取由机器而不是人（http://en.wikipedia.org/wiki/Binary_protocol）

拜托的协议！

要更清楚一点，如果我有jpg文件那将如何通过二进制协议发送以及如何通过文本发送？就当然发送的位/字节而言。

如果你看一个字符串，它本身就是一个字节数组，所以这两个协议之间的区别应该取决于在线路上发送什么实际数据。换句话说，在发送之前如何对初始数据（jpg文件）进行编码。

任何评论都是可以理解的，我正试图去探讨事物的本质。

称呼！

Answer 1

二元协议与文本协议并不是真正关于如何编码二进制blob。不同之处在于协议是围绕数据结构还是围绕文本字符串。让我举个例子：HTTP。 HTTP是一种文本协议，即使它发送JPEG图像时，它只是发送原始字节，而不是它们的文本编码。

但真正使HTTP文本协议是在交换得到的JPG看起来是这样的：

请求：

GET /files/image.jpg HTTP/1.0 
Connection: Keep-Alive 
User-Agent: Mozilla/4.01 [en] (Win95; I) 
Host: hal.etc.com.au 
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */* 
Accept-Language: en 
Accept-Charset: iso-8859-1,*,utf-8 

响应：

HTTP/1.1 200 OK 
Date: Mon, 19 Jan 1998 03:52:51 GMT 
Server: Apache/1.2.4 
Last-Modified: Wed, 08 Oct 1997 04:15:24 GMT 
ETag: "61a85-17c3-343b08dc" 
Content-Length: 60830 
Accept-Ranges: bytes 
Keep-Alive: timeout=15, max=100 
Connection: Keep-Alive 
Content-Type: image/jpeg 

<binary data goes here> 

注意，这可以非常容易地被更紧密地包装在看起来像（C）的结构中，像

请求：

struct request { 
    int requestType; 
    int protocolVersion; 
    char path[1024]; 
    char user_agent[1024]; 
    char host[1024]; 
    long int accept_bitmask; 
    long int language_bitmask; 
    long int charset_bitmask; 
}; 

响应：

struct response { 
    int responseType; 
    int protocolVersion; 
    time_t date; 
    char host[1024]; 
    time_t modification_date; 
    char etag[1024]; 
    size_t content_length; 
    int keepalive_timeout; 
    int keepalive_max; 
    int connection_type; 
    char content_type[1024]; 
    char data[]; 
}; 

凡字段名称就不必在所有的传送，并且其中，例如，在响应结构的responseType是一个int值200而不是三个字符'2''0''0'。这就是基于文本的协议：被设计为作为平坦的（通常是人类可读的）文本行流而不是作为许多不同类型的结构化数据进行通信的协议。

Answer 2

我想你错了。 这不是确定数据在“连线”上的外观的协议，而是确定使用哪种协议传输的数据类型。 以tcp socket为例，一个jpeg文件将被发送并用一个二进制协议接收，因为它是二进制数据（不是人类可读的，在32-126 ascii范围内的字节），但是你可以发送/ recv一个文本文件与这两种协议，你不会注意到的差异。

Answer 3

两者使用不同的字符集，文字之一，用减少的字符集，二进制包括一切可能，不仅是“字母”和“数字”，（这就是为什么维基百科说“人”）

o更清楚一点，如果我有jpg文件，那么将如何通过二进制协议发送以及如何通过文本发送？就当然发送的位/字节而言。

要读这Base64

任何评析是apprecited，我试图去事物的本质在这里。

我认为缩小字符集的本质是缩小复杂度，并达到可移植性，兼容性。很难安排并同意很多人尊重广泛的字符集，（或广泛的）。拉丁/罗马字母和阿拉伯数字在世界范围内是已知的。 （当然还有其他的考虑，以减少代码，但这是一个主要的）

让我们说在二进制协议的“合同”之间的部分是关于位，一位意味着这一点，第二，等..或甚至字节（但是在没有考虑可移植性的情况下可以自由使用字符集），例如在私有封闭系统或（靠近硬件标准）时，但是如果你设计一个开放系统，你必须考虑你的代码将如何在广泛例如一组情况，例如它将如何在世界另一端的一台机器上表现出来？所以这里出现的是文本协议，其中合约将是可行的。我设计了这两方面的原因，对于非常自定义的解决方案和开放或/和便携式系统的文本的二进制文件。

Answer 4

二进制协议的示例：RTP，TCP，IP。

文本协议示例：SMTP,HTTP,SIP。

这应该允许您概括二进制与文本协议的合理定义。

提示：只需跳到示例部分或图表即可。他们用来说明Tyler's rocking answer。

Answer 5

这里有一种-的虎头蛇尾定义：

你就会知道它当你看到它。

这是其中很难找到涵盖所有角落案例的简明定义的情况之一。但它也是角落案件完全不相关的案例之一，因为它们根本不在现实生活中发生。

几乎所有的协议，你会在现实生活中遇到的要么是这样的：

> fg,m4wr76389b zhjsfg gsidf7t5e89wriuotu nbsdfgizs89567sfghlkf 
> b9er t8ß03q+459tw4t3490ß´5´3w459t srt üßodfasdfäasefsadfaüdfzjhzuk78987342 
< mvclkdsfu93q45324äö53q4lötüpq34tasä#etr0 awe+s byf eart 

[试想一下，一吨的其他非打印废话那里。一个在传达文本和二进制之间的差异所面临的挑战是，你必须做在文字:-)]输送

或者这样：

< HELLO server.example.com 
> HELLO client.example.com 
< GO 
> GETFILE /foo.jpg 
< Length: 3726 
< Type: image/jpeg 
< READY? 
> GO 
< ... server sends 3726 bytes of binary data ... 
> ACK 
> BYE 

[我只是做这件事当场。]

那里没有那么多含糊不清。

，我有时听到的另一个定义是

文本协议是一个你可以调试使用telnet

也许我在这里展示我的nerdiness，但我有实际写入并通过SMTP和POP3阅读电子邮件，通过NNTP阅读usenet文章并通过HTTP使用telnet查看网页，除了查看它是否真的有效外，没有其他原因。

其实，在写这个，我还挺又抓住了发烧：

bash-4.0$ telnet smtp.googlemail.com 25 
Trying 74.125.77.16... 
Connected to googlemail-smtp.l.google.com. 
Escape character is '^]'. 
< 220 googlemail-smtp.l.google.com ESMTP Thu, 15 Apr 2010 19:19:39 +0200 
> HELO 
< 501 Syntactically invalid HELO argument(s) 
> HELO client.example.com 
< 250 googlemail-smtp.l.google.com Hello client.example.com [666.666.666.666] 
> RCPT TO:Me <Me@Example.Com> 
< 503 sender not yet given 
> SENDER:Me <Me@Example.Com> 
< 500 unrecognized command 
> RCPT FROM:Me <Me@Example.Com> 
< 500 unrecognized command 
> FROM:Me <Me@Example.Com> 
< 500-unrecognized command 
> HELP 
< 214-Commands supported: 
< 214 AUTH HELO EHLO MAIL RCPT DATA NOOP QUIT RSET HELP ETRN 
> MAIL FROM:Me <Me@Example.Com> 
< 250 OK 
> RCPT TO:You <You@SomewhereElse.Example.Com> 
< 250 Accepted 
> DATA 
< 354 Enter message, ending with "." on a line by itself 
> From: Me <Me@Example.Com> 
> To: You <You@SomewhereElse.Example.Com> 
> Subject: Testmail 
> 
> This is a test. 
> . 
< 250 OK id=1O2Sjq-0000c4-Qv 
> QUIT 
< 221 googlemail-smtp.l.google.com closing connection 
Connection closed by foreign host. 

妈的，它已经相当长一段时间，因为我已经做到了这一点。在那里:-)

Answer 6

相当多的错误，你们中的大多数建议我们不能分辨协议是否是二进制或文本单单看在电线上

AFIK

二进制协议内容 - 位是边界 顺序是非常关键的

例如，RTP

前两位是版本 接下来位为标记位

。

文本协议 - 特定于协议 秩序等领域的分隔符并不重要

例如，SIP

一个更多的是，在二进制协议，我们可以拆分字节，即一个比特可能。有特定的个人意义;在文本协议中，最小有意义的单位是BYTE。你不能分割一个字节。

日Thnx

-Bytes

Answer 7

我无意中发现这个老问题，并决定增加我看来，至少要检查它。

大多数答案都解释了文本和二进制协议与机器的不同之处。从人的角度来看，文本协议是人类可读/可编辑的（人类可以读/写没有解码器/编码器的数据包）。这意味着至少有两个好处：简化文本协议实现的调试/维护，以及通过简单通用工具（如telnet）进行测试的可能性。因为（我猜）在协议实现中使用一个洞来执行一些恶意代码是不可能的或者很困难的，例如，通过利用缓冲区溢出。这是一个小好处，因为二进制协议可以通过base64编码实现相同。

有是还的文本协议，一些缺点：

• 文本协议执行是实现 不是二进制平时多difficalt，因为解析器。
• 二进制协议更少的带宽消耗

试图编译从这个最后的一些建议：

德兴的协议作为文本之一时：

• 这是一个控制协议，可以是作为一系列命令或 请求/回复（（交互式））。从实现的角度来看，它可以作为一个有限状态机实现。例如，考虑多媒体流：RTSP - 一种控制协议，使用状态机和由请求/回复组成 - 是一种文本协议，因为RTP是二进制协议，因为它携带的主要是多媒体流等自然二进制数据。
• 它旨在用于大量使用：由许多人，实现或应用程序;所以简化的调试/维护非常重要。

。

Answer 8

How can we send an image file in SOAP: Click here

这表明二进制数据被附加作为此种[ATTACHMENT]及其参考保存在SOAP消息。

所以，该协议是基于文本的和数据[图像]是二进制附件，其编码是不相关的

因此，SOAP是文本协议由于我们指定SOAP标头，并在其中编码不是实际的数据的方式。

Answer 9

文本协议可以自解释和广泛。 这是不言自明的，因为该消息仅包含消息本身中的字段名称。如果不参考协议规范，则无法理解二进制协议消息中的哪个值。

这是广泛的手段HTTP作为文本协议刚刚做简单的规则，但你可以自由地添加新标题或更改内容类型运输不同的有效载荷扩展数据结构。标题是元数据，并具有协商和自动适应的能力。