From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Newsgroups: comp.lang.ada
Subject: Re: A few questions on parsing, sockets, UTF-8 strings
Date: Thu, 11 Aug 2016 19:49:21 +0200
Organization: Aioe.org NNTP Server
Message-ID: <noidr9$atk$1@gioia.aioe.org>
References: <267bd80f-b388-4df6-b712-315ee9bda2b8@googlegroups.com>
 <noi8r3$2p6$1@gioia.aioe.org>
 <90caee48-5fa7-47d7-aad5-761e11225e2c@googlegroups.com>
NNTP-Posting-Host: xelDFTENDI+dlkJFd2Ot2w.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@aioe.org
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.2.0
X-Notice: Filtered by postfilter v. 0.8.2
Xref: news.eternal-september.org comp.lang.ada:31399
Date: 2016-08-11T19:49:21+02:00
List-Id: <comp.lang.ada>

On 2016-08-11 19:40, john@peppermind.com wrote:

> I'm still confused, though. Strings are really kind of a mess in
> Ada,  IMHO. Do I really need your package? Or could I use String instead?

Instead of what?

> Suppose the GPS source code option is set to UTF-8, so a string literal
> in the source code should be UTF-8 data (inside a fixed String type).
> Right?

ASCII string is an UTF-8 string. The reverse if false.

> So if I Base64 encode this directly, do I have to care about UTF-8?

No, if it is strictly ASCII. Yes, if you are going to use other Unicode 
code points.

>> P.S. There is no point using Base64 encoding over TCP/IP unless a
>> specific protocol requires it.
>
> I agree, and it's my own protocol, but in this case I believe Base64
> makes sense despite the inefficiency. The protocol should be as easy as
> possible to implement in basically any language that has strings and TCP
> sockets, and many languages have built-in Base64 encoders and decoders.

Then, what's the problem? Use no Base64 and no line terminators. Pass 
the packet length. Then, the packet contents. No encoding, no recording, 
always known how many bytes to read next.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de