Protocol Buffers是Google提出的新的資料交換格式. 關於它的英文定義是: a language-neutral, platform-neutral, extensible way of serializing structured data for use in communications protocols, data storage, and more. 關於Protocol Buffer開發文檔的說明:
This documentation is aimed at Java, C++, or Python developers who want to use protocol buffers in their applications.
This overview introduces protocol buffers and tells you what you need to do to get started
– you can then go on to follow the tutorials or delve deeper into protocol buffer encoding.
API reference documentation is also provided for all three languages, as well as language and style guides for writing .proto files.
What are protocol buffers?
Protocol buffers are a flexible, efficient, automated mechanism for serializing structured data –
think XML, but smaller, faster, and simpler. You define how you want your data to be structured once,
then you can use special generated source code to easily write and read your structured data to and from a variety of data streams
and using a variety of languages. You can even update your data structure without breaking deployed programs that are compiled against the "old" format.
How do they work?
You specify how you want the information you're serializing to be structured by defining protocol buffer message types in .proto files.
Each protocol buffer message is a small logical record of information, containing a series of name-value pairs.
Here's a very basic example of a .proto file that defines a message containing information about a person:
message Person { required string name = 1;
required int32 id = 2;
optional string email = 3;
enum PhoneType {
MOBILE = 0;
HOME = 1;
WORK = 2;
}
message PhoneNumber {
required string number = 1;
optional PhoneType type = 2 [default = HOME];
}
repeated PhoneNumber phone = 4;
}
As you can see, the message format is simple – each message type has one or more uniquely numbered fields,
and each field has a name and a value type, where value types can be numbers (integer or floating-point), booleans, strings, raw bytes,
or even (as in the example above) other protocol buffer message types, allowing you to structure your data hierarchically.
You can specify optional fields, required fields, and repeated fields.
You can find more information about writing .proto files in the Protocol Buffer Language Guide.
象你看到的一樣，訊息格式很簡單：每個訊息類型有一個或者多個資料項目，每個資料項目有一個名字和一個資料類型。資料類型可以是數值(整形或者浮點型)，
布爾型，字串，位元組流或者自訂的buffer類型，允許你子架構造資料體系。
你可以指定可選的資料項目，必選資料項目和重複資料項目。關於如何寫.proto檔案，可以從protocol buffer language指南中得到更多資訊。
Once you've defined your messages, you run the protocol buffer compiler for your application's language on your .proto file to generate data access classes.
These provide simple accessors for each field (like query() and set_query()) as well as methods to serialize/parse the whole structure to/from raw bytes –
so, for instance, if your chosen language is C++, running the compiler on the above example will generate a class called Person.
You can then use this class in your application to populate, serialize, and retrieve Person protocol buffer messages.
You might then write some code like this:
定義了訊息後，就可以protocol buffer編譯器編譯，從.proto檔案產生資料訪問類。（與corba idl類似）
這些類提供了簡單的訪問資料項目的方法，類似query(),set_query()
你可以在你的應用中使用這些類來構造、序列化和取回Person這個protocol buffer訊息。你可以寫如下代碼：
Person person;
person.set_name("John Doe");
person.set_id(1234);
person.set_email("jdoe@example.com");
fstream output("myfile", ios::out | ios::binary);
person.SerializeToOstream(&output);
then, later on, you could read your message back in:
然後，從檔案中讀回資訊
fstream input("myfile", ios::in | ios::binary);
Person person;
person.ParseFromIstream(&input);
cout << "Name: " << person.name() << endl;
cout << "E-mail: " << person.email() << endl;
You can add new fields to your message formats without breaking backwards-compatibility;
old binaries simply ignore the new field when parsing. So if you have a communications protocol that uses protocol buffers as its data format,
you can extend your protocol without having to worry about breaking existing code.
你可以增加資料項目，不用考慮前向相容；舊的代碼僅僅是簡單的忽略新增的項。
如果你使用protocol buffer作為你的通訊協議，你能夠擴充你的協議，不用擔心影響已經存在的代碼。
You'll find a complete reference for using generated protocol buffer code in the API Reference section,
and you can find out more about how protocol buffer messages are encoded in Protocol Buffer Encoding.
你可在API文檔中找到完整的參考資料，並能夠瞭解協議是如何編解碼的。
Why not just use XML?
Protocol buffers have many advantages over XML for serializing structured data. Protocol buffers:
* are simpler
* are 3 to 10 times smaller
* are 20 to 100 times faster
* are less ambiguous
* generate data access classes that are easier to use programmatically
For example, let's say you want to model a person with a name and an email. In XML, you need to do:
為什麼不使用XML?
protocol buffer有很多XML不具備的優點：
1.簡單；
2.小巧：3-10倍
3.效率高：20-100倍
4.無二義性
5.有自動工具產生訪問類；(其實ASN.1, CORBA都有類似工具)
例如，Person模型使用xml表示
<person>
<name>John Doe</name>
<email>jdoe@example.com</email>
</person>
while the corresponding protocol buffer message (in protocol buffer text format) is:
對應的protocol文字格式設定
# Textual representation of a protocol buffer.
# This is *not* the binary format used on the wire.
person {
name: "John Doe"
email: "jdoe@example.com"
}
When this message is encoded to the protocol buffer binary format (the text format above is just a convenient
human-readable representation for debugging and editing), it would probably be 28 bytes long and take around 100-200 nanoseconds to parse.
The XML version is at least 69 bytes if you remove whitespace, and would take around 5,000-10,000 nanoseconds to parse.
當訊息編碼成二進位格式（上面的說明只是為了編譯閱讀的表示方式），protocol buffer將差不多28個子節長，用100-200ns時間解析。
而XML檔案有69位元組長，還要去掉空白符，使用5000-10000ns來解析
Also, manipulating a protocol buffer is much easier:
維護以很容易：
cout << "Name: " << person.name() << endl;
cout << "E-mail: " << person.email() << endl;
Whereas with XML you would have to do something like:
而XML要做如下的事情：
cout << "Name: "
<< person.getElementsByTagName("name")->item(0)->innerText()
<< endl;
cout << "E-mail: "
<< person.getElementsByTagName("email")->item(0)->innerText()
<< endl;
However, protocol buffers are not always a better solution than XML –
for instance, protocol buffers would not be a good way to model a text-based document with markup (e.g. HTML),
since you cannot easily interleave structure with text. In addition, XML is human-readable and human-editable; protocol buffers,
at least in their native format, are not. XML is also – to some extent –
self-describing. A protocol buffer is only meaningful if you have the message definition (the .proto file).
可是，protocol buffers並不是一直都比XML好-例如，protocol buffers不適合描述符號文本，如HTML，因為你不能很好的組織文本。
另外，XML更易於閱讀和編輯。protocols buffers也不是自描述的（不知什麼意思。）
並且，protocol buffers在google內部已經廣泛使用。
