UUencode / decode hex 00s

[GCS]

I have a file of hex data that I need to UUencode
and decode. I was trying to place the data into a
TMemo and work with it from there. However, I
discovered that a $00 delimiters the data in a
TMemo at the place where the first $00 is hit. Any
ideas what I can use to work with data containing
$00? I tried TStringList with the same results.

Thanks.

[M.H. Avegaart]

You could use the following UUEncode/UUDecode functions:

const
CodingTable: array[0..$3f] of Char =
'`!"#$%&''()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_';

function UUEncode(S: String): String;
var
i: Integer;
begin
Result := '';
S := S + #0#0;
for i := 0 to Pred(Length(S) div 3) do
Result := Result +
CodingTable[(Byte(S[i * 3 + 1]) shr 2) and $3f] +
CodingTable[((Byte(S[i * 3 + 1]) shl 4) or (Byte(S[i * 3 + 2]) shr 4))
and $3f] +
CodingTable[((Byte(S[i * 3 + 2]) shl 2) or (Byte(S[i * 3 + 3]) shr 6))
and $3f] +
CodingTable[Byte(S[i * 3 + 3]) and $3f];
end;

function UUDecode(S: String): String;

function GetTableIndex(Ch: Char): Byte;
begin
for Result := 0 to $3f do
if CodingTable[Result] = Ch then
Exit;
Result := 0;
end;

var
i: Integer;
begin
Result := '';
S := S + CodingTable[0] + CodingTable[0] + CodingTable[0];
for i := 0 to Pred(Length(S) div 4) do
Result := Result +
Char(((GetTableIndex(S[i * 4 + 1]) shl 2) or (GetTableIndex(S[i * 4 +
2]) shr 4)) and $ff) +
Char(((GetTableIndex(S[i * 4 + 2]) shl 4) or (GetTableIndex(S[i * 4 +
3]) shr 2)) and $ff) +
Char(((GetTableIndex(S[i * 4 + 3]) shl 6) or (GetTableIndex(S[i * 4 +
4]))) and $ff);
Result := PChar(Result);
end;

ps. For Base64 encoding/decoding you should use:

const
CodingTable: array[0..$3f] of Char =
'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/';

"GCS" <battleRe...@netexecutive.com> wrote in message
news:Xns9117A157F...@207.218.245.68...

[Mike Shkolnik]

This is a problem of TStrings type which work with string until #0 character
is occured.

In own SMImport component for direct data loading I did the next:
1. calculate a real size of string (including #0 characters)
2. in cycle to process any character - no matter which code is occured
Something like that:
while intProcessed < intLength do
instead
while P^ <> #0 do

PS: when I wrote above about string, I meant a PChar, of course.
--
With best regards, Mike Shkolnik
E-Mail: mshk...@scalabium.com
mshk...@yahoo.com
WEB: http://www.scalabium.com

GCS <battleRe...@netexecutive.com> пишет в
сообщении:Xns9117A157F...@207.218.245.68...

[Bjørge Sæther]

"M.H. Avegaart" <aveg...@NOSPAMmccomm.nl> skrev i melding
news:9nhrnu$1arm$1...@scavenger.euro.net...

> You could use the following UUEncode/UUDecode functions:
>
> const
> CodingTable: array[0..$3f] of Char =
> '`!"#$%&''()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_';

Please enlighten me:

Is this a correct escription of this algorithm`?

- The encoded string uses a character set of 64 characters (6 bits)
- 8-bit ASCII Characters are treated in goups of 3 (8*3=24 bits), resulting
in 4 encoded characters (6*4=24 bits)
- This means the encoded string will be 33% larger than the original.

???

--
Bjoerge Saether
Consultant / Developer
http://www.itte.no
Asker, Norway
bjorge@takethisaway_itte.no (remve the obvious)

[Alf Christophersen]

On Mon, 10 Sep 2001 19:43:33 +0200, "Bjørge Sæther"
<REMOVE_bsaether@THIS_online.no> wrote:

>- This means the encoded string will be 33% larger than the original.

UUEncode has never been developed to crunch data but to hinder IBM
EBCDIC computers from harrasing the Email content if an IBM computer
was involved in transferring your email to another place. EBCDIC has a
much smaller set of characters than ASCII and also different placement
of many characters making it necessary to decode ASCII characters into
a subset that EBCDIC supported. Thus the string will grow
significantly in size when UUEncoding a string.

[GCS]

Is EBCDIC still a problem today?

Thanks.

[Alf Christophersen]

On Mon, 10 Sep 2001 19:38:38 -0500, GCS
<battlesEli...@onebox.com> wrote:

> Is EBCDIC still a problem today?

If not needed anymore, it still is an algorithm to code a 256
character set into a smaller one, thus preventing gateways that do not
support 256 character set in harassing binary files. EBCDIC is one of
several problems, more widespreaded are 7-bit gateways which still
make trouble transporting binary files (with whole 256 character set).