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=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,bffcdbd805329ff8 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-08-29 12:00:36 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!cyclone.bc.net!cyclone-sjo1.usenetserver.com!usenetserver.com!border1.nntp.aus1.giganews.com!nntp.giganews.com!news-east.rr.com!news-west.rr.com!lsnws01.we.mediaone.net!typhoon.san.rr.com.POSTED!not-for-mail Message-ID: <3B8D3BC2.B3D9DBF6@san.rr.com> From: Darren New Organization: Boxes! X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Ada and Internet stuff References: <3B8D181E.8C9523D@san.rr.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 29 Aug 2001 19:00:19 GMT NNTP-Posting-Host: 24.165.20.229 X-Complaints-To: abuse@rr.com X-Trace: typhoon.san.rr.com 999111619 24.165.20.229 (Wed, 29 Aug 2001 12:00:19 PDT) NNTP-Posting-Date: Wed, 29 Aug 2001 12:00:19 PDT Xref: archiver1.google.com comp.lang.ada:12575 Date: 2001-08-29T19:00:19+00:00 List-Id: > > Also, what's the mechanism for dealing with things like UTF-8? > Base64 is specifically designed to work across various character > encodings. Thus an 'A' means 6 bits of zeroes, regardless of how > that 'A' is represented. Actually, I think it's that ASCII 64 means 6 bits of zeros, but I'd have to double-check the RFC specifically. :-) But I understand what you're saying, that the text-io routines are responsible for mapping 'A' in the source to 'A' in your input file. > You *should* be able to replace String > with Wide_String and Character with Wide_Character appropriately > and have it work. Of course your 24 bits of input would then be > 64, rather than 32 bits, encoded, for an expansion factor of 2.66, > which would rather argue against it. Sorry. That second question was kind of a non-sequitar. Not asking about its relation to base64 as such, but in general about character encoding problems. Like, if I were to deal with XML, how could I expect to handle wide characters in the input stream? > > -- Target'length must be at least: > > -- Output_Quad_Count: constant := (Source'length + 2) / 3; > > -- Output_Byte_Count: constant := 4 * Output_Quad_Count; > > -- Target'length = Output_Byte_Count + 2 * (Output_Byte_Count / 76) > > > > This should be a function. :-) Probably, it would be best to have a > > function that takes an input length and returns the output length in > > both directions, so you can allocate your buffers properly before > > calling the functions. > Extra whitespace and missing line breaks are both allowed in encoded > data, so you can't tell without looking at it, ie running the decoding, > just what it will decode into. True. But that might be useful anyway, even if inefficient. > No such problem on encoding. Yes. > You could make > function Encode(X : Stream_Element_Array) return String; > function Decode(S : String) return Stream_Element_Array; > and let them generate and return the correct size results. That's > not terribly hard but is surely less speedy, which may matter. I was fiddling around with variable length strings, and I thought I understood but I apparently don't. What would I *do* with such a returned result? There isn't a variable I could assign it to, is there? The only thing I could do is to pass it to some other routine that takes unconstrained strings as an in parameter, yes? I thought I could do declare s : String; begin s := Encode(yadda); end; but that doesn't work. Bummer. (Yes, as you can tell, I'm all the way up to "Hello World". :-) -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand.