Plain Text
Plain Text
The plain text data format consists of lines and words. It is not really a data format, per se, but is just the simplest way to create a document. The concept was quickly repurposed for communication between a client and a server. By definition, the plain text format is
a text format, not a binary format. To separate lines, the ASCII 13 character, also known as the carriage return or CR
character, is used. It is URL-encoded as %0d. To separate words, the ASCII 32 character, the “space” character ( ), is used. A space ( ) is URL-encoded as %20.
Plain Text | 221
The following example data is in the plain text format:
The first name is John. The last name is Smith. The zip code is 80001.
This example data could be URL-encoded and sent to the server using an HTTP GET or an HTTP POST:
customer=The%20first%20name%20is%20John.%0dThe%20last%20name%20is%20Smith. %0dThe%20zip%20code%20is%2080001.
The example data could be returned from the server in the HTTP response body just as it is:
The first name is John. The last name is Smith. The zip code is 80001.
The HTTP response header could even specify the “text/plain” value for the Content- type HTTP response header, just to be clear.
The benefit of the plain text format is that it is very readable. It is plain English. The drawback is that it is too flexible. To separate the important data, such as the John,
Smith, and 80001 values, from the surrounding text is a nuisance to the code that is receiving the data. The plain text format is more convenient for a single document than it is for multiple small pieces of data that need to be used by client-side JavaScript, PHP, or Node.js code.
To use the plain text format, inevitably, some smaller ad hoc formats need to be agreed upon. For example, the strings “the last name is Smith” and “the last name is set to Smith” might mean approximately the same thing, but for easy communication using the plain text format, the client and the server would agree that both would always use “is” and never use “is set to.”
Even more inconvenient, differentiating between arrays, objects, strings, and numbers in the plain text format is a common requirement and the only way to handle the specifics of each of those is with more ad hoc formats.
For example, a client may wish to tell the server to create an object with certain attributes, such as the first name, last name, and zip code, or the server may wish to return an object that the client requested. If the client and server are communicating using the plain text format, they would need to communicate the following object properties in each com‐ munication:
the 'first name' property has the string, 'John' the 'last name' property has the string, 'Smith' the 'zip code' property has the string, '80001'
222 | Chapter 11: Plain Text, JSON, and XML
Of course, an ad hoc format could be invented to convey this specific object inside the plain text format. But instead, it is a better idea to select one of the other formats, such as the JSON data format or the XML data format, that is specifically designed to work in this style.
Many web applications still communicate using the plain text as their data format. If PHP code is using this data format, it uses the PHP dot operator (.) to create the data.
To convert this PHP code to Node.js, the PHP dot operator (.) is converted to the Node.js plus (+) operator as shown in Chapter 6 .
If PHP code needs to parse data and extract it from the plain text format, it usually uses the PHP string position API functions, such as the PHP strpos() API function, and PHP substring API functions, such as the PHP substr() API function, to separate the values from the surrounding text. To convert this PHP code to Node.js, the PHP API functions can be implemented in Node.js using the information from the next chapter.
As a replacement for the plain text format and the complication of the ad hoc formats that it leads to, the JSON format has been gaining popularity in recent years.