バイナリプロトコルとは何かについて、誰かが良い定義を持っていますか？実際にテキストプロトコルとは何ですか？有線で送信されるビットに関して、これらはどのように相互に比較されますか？
ウィキペディアがバイナリプロトコルについて言っていることは次のとおりです。
バイナリプロトコルは、人間ではなくマシンによって読み取られることを意図または期待されているプロトコルです（http://en.wikipedia.org/wiki/Binary_protocol）
さあ！
より明確にするために、jpgファイルがある場合、それはバイナリプロトコルを介してどのように送信され、テキストプロトコルを介してどのように送信されますか？もちろん、ネットワーク上で送信されるビット/バイトの観点から。
結局のところ、文字列を見ると、それ自体がバイトの配列であるため、2つのプロトコルの違いは、実際に送信されているデータに基づいている必要があります。つまり、送信前の初期データ（jpgファイル）のエンコード方法についてです。
回答:
バイナリプロトコルとテキストプロトコルは、実際にはバイナリブロブがどのようにエンコードされるかについてではありません。違いは、プロトコルがデータ構造を対象としているのか、テキスト文字列を対象としているのかということです。例を挙げましょう：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応答構造内のinが、3文字の「2」「0」「0」ではなく値200のintである場合。これがテキストベースのプロトコルです。多くの異なるタイプの構造化データとしてではなく、（通常は人間が読める）テキスト行のフラットストリームとして通信するように設計されたプロトコルです。
これが一種のコップアウト定義です：
あなたがそれを見ればあなたはそれを知るでしょう。
これは、すべてのコーナーケースを網羅する簡潔な定義を見つけるのが非常に難しいケースの1つです。しかし、それはまた、コーナーケースが実際には発生しないため、まったく関係のないケースの1つでもあります。
実際に遭遇するほとんどすべてのプロトコルは、次のようになります。
> fg,m4wr76389b zhjsfg gsidf7t5e89wriuotu nbsdfgizs89567sfghlkf
> b9er t8ß03q+459tw4t3490ß´5´3w459t srt üßodfasdfäasefsadfaüdfzjhzuk78987342
< mvclkdsfu93q45324äö53q4lötüpq34tasä#etr0 awe+s byf eart
[そこに他の印刷不可能ながらくたがたくさんあると想像してみてください。テキストとバイナリの違いを伝える際の課題の1つは、テキストで伝える必要があることです:-)]
またはこのように：
< 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を示していますが、私はしている実際に使用してHTTP経由で、SMTPとPOP3を経由してNNTPと閲覧Webページを介して読み出しUsenetの記事を電子メールを読み書き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.
くそー、私がこれをやったのはかなり久しぶりです。そこにはかなりの数のエラーがあります:-)
ほとんどの人が示唆しているように、ネットワーク上のコンテンツを見るだけでは、プロトコルがバイナリであるかテキストであるかを区別することはできません。
AFIK
バイナリプロトコル-ビットは境界です順序は非常に重要です
例：RTP
最初の2ビットはバージョンです次のビットはMarkUpビットです
テキストプロトコル-プロトコルに固有の区切り文字フィールドの順序は重要ではありません
例：SIP
もう1つは、バイナリプロトコルでは、バイトを分割できます。つまり、1つのビットが特定の個別の意味を持つ場合があります。テキストプロトコルでは、意味のある最小単位はBYTEです。バイトを分割することはできません。
どちらも異なる文字セットを使用し、テキストは縮小文字セットを使用し、バイナリには「文字」と「数字」だけでなく、可能な限りすべてが含まれます（ウィキペディアが「人間」と言っているのはそのためです）
oより明確に言えば、jpgファイルがある場合、それはバイナリプロトコルを介してどのように送信され、テキストプロトコルを介してどのように送信されますか？もちろん、ネットワーク上で送信されるビット/バイトの観点から。
このBase64を読む必要があります
どんなコメントもありがたいです、私はここで物事の本質に到達しようとしています。
文字セットを狭めるための本質は、複雑さを狭め、移植性、互換性に到達することだと思います。ワイド文字セット（またはワイド文字セット）を尊重するように手配し、多くの人に同意するのは困難です。ラテン/ローマ字とアラビア数字は世界的に知られています。（もちろん、コードを減らすための他の考慮事項がありますが、それが主なものです）
バイナリプロトコルでは、パーツ間の「契約」はビットに関するものであり、最初のビットはこれを意味し、2番目はそれを意味します。またはバイト（ただし、移植性を考慮せずに文字セットを自由に使用できます）などです。または（ハードウェア標準の近く）ただし、オープンシステムを設計する場合は、コードがさまざまな状況でどのように表現されるか、たとえば、世界の反対側のマシンでどのように表現されるかを考慮する必要があります。ここに、契約が可能な限り標準となるテキストプロトコルがあります。私は両方を設計しました。それが理由でした。非常にカスタムなソリューションのバイナリと、オープンシステムやポータブルシステムのテキストです。
SOAPで画像ファイルを送信するにはどうすればよいですか：ここをクリック
これは、バイナリデータが[ATTACHMENT]として添付され、その参照がSOAPメッセージに保存されていることを示しています。
したがって、プロトコルはテキストベースであり、data [Image]はエンコーディングが関係しないバイナリ添付ファイルです
したがって、SOAPヘッダーを指定する方法が原因で、SOAPはテキストプロトコルであり、実際にエンコードされたデータではありません。
私はあなたがそれを間違えたと思います。「ワイヤ」上でデータがどのように見えるかを決定するのはプロトコルではありませんが、データを送信するために使用するプロトコルを決定するのはデータ型です。たとえば、tcpソケットを例にとると、jpegファイルはバイナリプロトコルで送受信されます。これは、バイナリデータ（人間が読めない、32〜126のASCII範囲に入るバイト）であるためですが、テキストファイルを送受信できます。両方のプロトコルとあなたは違いに気付かないでしょう。