Base64 encoder

[HPW]

It seems that my test with my 10 KB string failed, because

it does not work with 'rn'



This works:



> (setq a(BASE64:encode "TestnTest"))

"VGVzdApUZXN0"

> (BASE64:decode a)

"TestnTest"

> (setq a(BASE64:encode "TestrTest"))

"VGVzdA1UZXN0"

> (BASE64:decode a)

"TestrTest"



But:



> (setq a(BASE64:encode "TestrnTest"))

"dA=="

[pjot]

Hi Lutz,



Well, I mentioned the other languages because I did not experience this problem there... I am sorry if it appeared as a criticism, that really was not my intention... indeed newLISP is functioning more consequent since it will return everything the program has asked for.



HPW: I look into that problem now, just a minute...



P.

[pjot]

Hi HPW,



In my Linux environment this is convertable without any problem. My self-defined function delivers this result with "TestrnTest":



VGVzdA0KVGVzdA==



I will literally cut and paste your program now.

[Lutz]

don't worry, i didn't take it as criticism, i just take all opportunity to explain things about newLISP knowing that many people read this board



Lutz

[pjot]

Hi HPW,



I just found the problem. There is an error in your corrected encoding part. Look at this part in your BASE64:encode:



;; Find BASE64 characters

(if (= (length dat) 1)

(begin

(set 'enc (append(nth base1 base64charset)(nth base2 base64charset)"=="))



This should be:



;; Find BASE64 characters

(if (= (length dat) 1)

(begin

(set 'enc (append enc (nth base1 base64charset)(nth base2 base64charset)"=="))





Then it works.

Btw: nice to see how contexts are working, I did not experiment with them yet!



Regards



Peter.

[HPW]

Oops! Typo.



When changing to Lutz advice I change to



(set 'enc (append (nth base1 base64charset)(nth base2 base64charset)"=="))



instead of



(set 'enc (append enc (nth base1 base64charset)(nth base2 base64charset)"=="))



Sorry for that.

[HPW]

Thanks, you was faster! :-)

[pjot]

;-) ok ok... no problem! Thanks for your input!

[HPW]

A little benchmark test with 50KB string:



> (time(setq a (BASE64:encode bigtxt)))

2391

> (time(setq b(get-string(hpwMimeEncodeString bigtxt))))

0

> (length a)

66696

> (length b)

68450

> (length bigtxt)

50022

>

[pjot]

hmmm... so your mime encode is faster, but also appears to produce a LONGER result? Shouldn't the result of the conversion be of the same length?

[HPW]

Yes, I am also wondering.



The speed difference does not wonder because it

is a compiled delpi-dll with a MIME-encoder from

project jedi.



The size difference might be related to an option

which allows to generate a formated BASE64-stream.

Have to check.

[pjot]

OK I am curious, because this might lead to a bug - either in my code or in the Delphi DLL...



Regards



Peter.

[HPW]

After a look into the source,  my first thought was right.



There is an option for inserting line breaks into the

mime-stream. Maybe I should make an optional

encode command without this option.

[pjot]

Well, it might be nice to check if our BASE64 encoders lead to the same result. If so we must assume the encoders are bug-free... ;-)

[Lutz]

changing (while (> (length dat) 0)  to (while (> (length dat) 3)

and putting all the (if ... length ....) stuff outside the while loop would make things a lot faster.



Also, in the spec at: http://www.securecode.net/Base64Convert+main.html">http://www.securecode.net/Base64Convert+main.html



is says something about inserted linefeeds and max linelength, the rn can just be fitered out as they are not legal BASE64 characters.



Lutz