二进制协议与文本协议
没有人有什么二进制协议是一个很好的定义？ 什么是文本协议呢？ 这些数据如何在电缆上发送的比特相互比较？
这里是维基百科关于二进制协议的说法：
二进制协议是预期或预期由机器而不是人类读取的协议（ http://en.wikipedia.org/wiki/Binary_protocol ）
哦，来吧！
要更清楚，如果我有JPG文件如何通过二进制协议发送，如何通过文本发送？ 就当然发送的位/字节而言。
在一天结束的时候，如果你看一个string，它本身就是一个字节数组，所以这两个协议之间的区别应该取决于在线上发送的实际数据。 换句话说，在发送之前如何对初始数据（jpg文件）进行编码。
任何意见都是有价值的，我正在努力去认识这里的事物的本质。
致敬！
二进制协议与文本协议并不是真正关于如何编码二进制块。 不同的是协议是围绕数据结构还是围绕文本string。 让我举个例子：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是一个值为200而不是三个字符'2''0''0'的int的情况下，根本不必传送字段名称。 这就是基于文本的协议：一种被devise为以平坦的（通常是人类可读的）文本行来传送的，而不是许多不同types的结构化数据。
这里有一个类似于cop-out的定义：
当你看到它时你会知道的。
这是其中很难find涵盖所有angular落案例的简明定义的情况之一。 但这也是angular落案件完全不相关的案例之一，因为它们根本不在现实生活中发生。
几乎所有在现实生活中遇到的协议都将如下所示：
> 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进行debugging的协议
也许我在这里显示我的书呆子，但实际上我已经通过SMTP和POP3编写和阅读电子邮件，通过NNTP阅读usenet文章，并通过使用telnet通过HTTP查看网页，没有任何其他原因，而不是看看它是否会实际工作。
实际上，在写这篇文章的时候，我又有点发烧了：
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.
该死的，自从我这么做以来已经有一段时间了。 那里有很多错误:-)
两个使用不同的字符集，文本之一，使用减less的字符集，二进制包括所有它可以，不仅“字母”和“数字”，（这就是为什么维基百科说“人类”）
o更清楚，如果我有jpg文件，通过二进制协议如何发送？通过文本发送？ 就当然发送的位/字节而言。
你应该阅读这个Base64
任何意见都是有价值的，我正在努力去认识这里的事物的本质。
我认为缩小字符集的本质，是缩小复杂性，达到可移植性，兼容性。 很难安排和同意很多尊重广泛的字符集，（或广泛的）。 拉丁/罗马字母和阿拉伯数字在世界范围内是已知的。 （当然，还有其他一些考虑，以减less代码，但这是主要的）
比方说在二进制协议中，部分之间的“契约”是关于比特的，比特是指这个，第二个等等，甚至是字节（但是在没有考虑可移植性的情况下使用字符集的自由度），例如在私有封闭系统或者（靠近硬件标准），但是如果你devise一个开放的系统，你必须考虑你的代码将如何在很多情况下performance出来，例如它将如何在世界另一端的机器中performance出来？这里来的文本协议的合同将作为标准的posible。 我已经devise了这两个原因，二进制的非常定制的解决scheme和开放或/和便携式系统的文本。
二进制协议的例子： RTP ， TCP ， IP 。
文本协议的例子： SMTP ， HTTP ， SIP 。
这应该允许你推广到二进制文本协议的合理定义。
提示：只需跳到示例部分或图表即可。 他们用来说明泰勒摇摆的答案 。
正如大多数人所build议的，我们无法简单地通过查看networking上的内容来区分协议是二进制还是文本
AFIK
二进制协议 – 位是边界顺序是非常关键的
例如，RTP
前两位是版本，下一位是标记位
文本协议 – 特定于协议的分隔符字段的顺序并不重要
例如，SIP
还有一点是，在二进制协议中，我们可以分割一个字节，也就是说，一位可能有一个特定的个人意义; 而在文本协议中，最小有意义的单位是BYTE。 你不能分割一个字节。
日Thnx
-Bytes
我不小心发现了这个老问题，并决定补充我的意见，至less要检查一下。
大多数答案都解释了文本和二进制协议与机器的不同之处。 从人的angular度来看，文本协议是人类可读/可编辑的（人类可以读写数据包而不是解码器/编码器）。 这意味着至less有两个好处：简化文本协议实现的debugging/维护，以及通过简单通用的工具（如telnet）进行testing的可能性。
还有一个小好处：文本协议被视为更可信，因为（我猜）在协议实现中使用一个漏洞来执行一些恶意代码是不可能的或者很困难的，例如通过利用缓冲区溢出。 这是一个小的好处，因为二进制协议可以通过base64编码实现相同。
文本协议也有一些缺点：
- 由于parsing器的原因，文本协议的实现通常比二进制更难以实现。
- 二进制协议带宽消耗较less
试图从这个编译一些最终的build议：
在以下情况下将协议设置为文本格式：
- 它是一个控制协议，可以被看作是一系列的命令或者请求/回复（交互式的），从实现的angular度来看，它可以作为一个有限状态机来实现，例如考虑多媒体stream：RTSP – 一个控制协议，使用状态机，由请求/回复组成 – 是一个文本协议，因为RTP是一个二进制协议，因为大多数是像多媒体stream一样携带自然的二进制数据。
- 它旨在用于大量使用：由许多人，实现或应用程序; 所以简化的debugging/维护非常重要。
。
我们如何在SOAP中发送图像文件：点击这里
这表明二进制数据附加为[附件]，其引用保存在SOAP消息中。
所以，协议是基于文本的，数据[Image]是二进制附件，其编码是不相关的
因此，SOAP是文本协议，因为我们指定Soap头文件而不是实际编码的数据。
我想你错了。 这不是确定数据如何在“连线”上显示的协议，而是确定使用哪种协议传输的数据types。 以tcp套接字为例，一个jpeg文件将被发送和接收一个二进制协议，因为它是二进制数据（不是人类可读的，字节在32-126 ascii范围内），但你可以发送/ recv文本文件这两个协议，你不会注意到的差异。
文本协议可以自我解释和广泛。 这是不言而喻的，因为消息只包含消息本身中的字段名称。 如果不参考协议规范，则无法理解二进制协议消息中的哪个值。
HTTP的广泛意义在于，HTTP作为一种文本协议只是简单的规则，但是您可以通过自由添加新的头文件或通过改变内容types来传送不同的有效载荷来扩展数据结构。 头是元数据，具有协商和自动适应的能力。
