[erlang-questions] strings vs binaries

zxq9 zxq9@REDACTED
Wed Aug 19 16:17:47 CEST 2015


On 2015年8月19日 水曜日 09:48:44 you wrote:
> On 08/19, zxq9 wrote:
> >The protocols involved in this case are often textual and its somewhat 
> >rare to find a textual protocol that isn't 100% ASCII.
> 
> This is less and less true and I wouldn't count on it for long. Hell for 
> the sake of the argument, I'd say almost no protocol is 100% ASCII 
> anymore.

Speaking strictly from my own experience in Asia, which is by no means representative of what may be going on elsewhere...

This is universally true if you include the payloads as part of the protocol, but generally speaking, while the encoding is nearly always unicode, the control tokens of text-based protocols are nearly always ASCII. The payloads, at least in most of the cases I've dealt with, tend to get routed through in a mannger based on the ASCII/binary (sometimes a mix) protocol tags that preceed it. Or ASN.1, which is particularly easy to deal with anywhere an ASN1 compiler is available (which is still most environments, it seems).

Even in Japan and Korea I've yet to see a custom protocol that did not adhere to this. So you may see the basic equivalent of

<<"FETCH", " ", "some.obj.type", " ", PayloadSize:8, Payload:PayloadSize, Blah/binary>>

The command token, the spaces, and the object type identifier will rarely be anything but ASCII, though this is occasionally not true for the object type id (which is more often an integer than some random utf8 named string).

But in any case, you're right. The future is now, and it is whatever we make of it. Many are making an arbitrary linguistic stew of it. And we have to keep in mind that there is actually nothing wrong with that.

-Craig



More information about the erlang-questions mailing list