ClarionX

Reading Base64 ...

This is the first article in an Internet Protocol/encoding Series...As developers we will at one time or another need to read base64 encoded data....heres my take...

Base64 is used to encode binary files in a text format suitable to be encapsulated in text documents. One interesting thing about base 64 is that it is one of the only data representation
schemes in modern use that doesn’t encrypt or compress the data. It just represents data
in a different form.

The solution to this problem was to create a data representation protocol that would allow
binary data to be encapsulated within another document. The defacto standard for doing
this is called base 64. In fact, some applications use base 64 as an encryption technique,
albeit a weak one. Basic authentication over the Internet encrypts the username-password
using base 64.

Here is a simple base64 decoder algorithm that has been very useful over the years...

base64decode PROCEDURE(STRING b64)

b64chars STRING('ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/')

oString ANY

CODE

oString = '' !Dont use CLEAR it will cause a GPF on an ANY Variable

! Base64 strings especially those from emails can contain carriage returns and tabs these must be removed before decoding....

b64 = StringReplace(b64,CHR(9),'')
b64 = StringReplace(b64,CHR(10),'')
b64 = StringReplace(b64,CHR(13),'')

! Base64 strings are groups of four characters and need to be stepped through by 4....

LOOP i# = 1 TO LEN(CLIP(b64)) BY 4

!Create a 24 bit Number by bit shifting the four chars values by  6 bit segments...

BigNumber# = BSHIFT(INSTRING(b64[i#],b64chars,1,1)-1,18) + BSHIFT(INSTRING(b64[i#+1],b64chars,1,1)-1,12) + BSHIFT(INSTRING(b64[i#+2],b64chars,1,1)-1,6) + (INSTRING(b64[i#+3],b64chars,1,1)-1)

!Extract the original 3 ascii chars by bit shifting in the other direction by 8 bit segments...

Char1# = BAND(BSHIFT(BigNumber#,-16),11111111b)
Char2# = BAND(BSHIFT(BigNumber#,-8),11111111b)
Char3# = BAND(BigNumber#,11111111b)

!handle trailing padding characters thus...and translate the character values...
IF b64[i#+3] = '=' AND b64[i#+2] ~= '=' THEN
oString = oString & CHR(Char1#)&CHR(Char2#)
ELSIF b64[i#+3] = '=' AND b64[i#+2] = '=' THEN
oString = oString & CHR(Char1#)
ELSE
oString = oString & CHR(Char1#)&CHR(Char2#)&CHR(Char3#)
END
!repeat operation for each group of four base64 chars

END

RETURN CLIP(oString)

The result is the unencoded text or binary data....for more info on base64 like a encoding checkout RFC 3548...

How to lose a Customer in 10 days...

To be a successful software developer, you have to become a skilled communicator.

You think you're a good communicator...You keep your users informed and you listen to their problems. So why is it that no one appears to read your e-mails or seems capable of following your instructions? Are you surprised to learn that the users have been living with computer issues rather than ask you for help? These are all signs of a breakdown in communication -- which we, as software developers, frequently misinterpret as user indifference or even stupidity. Before long, we find ourselves on a downward spiral toward complete communications failure. Even with the best intentions, it's possible to sabotage your own attempts to communicate with the users by inadvertently committing one or more of the following errors of miscommunication.

1. Inappropriate nonverbal communication :: Our words may say "Absolutely, yes, of course I don't mind helping you map the network drive," while our facial expressions, tone, and body language simultaneously scream, "You complete and utter knob, do you honestly think that I spent four years at uni, have an IQ of 167, and earned 53 technical certifications just so I could  map your network drive? Would you like me to wipe your arse as well?" --- quote Techrepublic
2. Showing off :: Using every technical piece of jargon imaginable....all you are doing is making your customer feel stupid...
3. Losing patience
4. Being dismissive
5. Failure to inform
6. Poor documentation
7. Lying :: In short, when presented with a problem you can't resolve, for whatever reason, it's far better to be direct with users and help them find a resolution by some other means rather than mask our ignorance or unwillingness as an insoluble technical issue.
8. Giving too much information :: Honesty may be the best policy, but this does not mean it's appropriate to overburden the users with too much information. They may actually not need you or worse still realise they know more than you...
9. Not providing training
10. Failing to listen
    Communication is a two-way process.

Hopefully these are others errors and not ours...

...

Mac OSX Viruses....

After numerous discussions with my colleagues about the validity of Apple's claim or at least users claim, that they were virus free and safe....I scanned the net and found and interesting article....demonstrating the detection of the first ever virus for Mac OSX....16/02/2006...by Sophos Engineers.

Feeling vindicated...I believe the proliferation of viruses on an operating system is a function of its popularity and share of the market place...In other words in the majority of cases not including script kiddies virus writers are skillful enough to tackle any OS platform...its just that more people use windows...

Sophos Article:

16 February 2006

First ever virus for Mac OS X discovered

OSX/Leap-A worm spreads via iChat instant messaging software

OSX/Leap-A uses an image of a JPEG icon to try and fool users.

Experts at SophosLabs™, Sophos's global network of virus, spyware and spam analysis centers, have announced the discovery of the first virus for the Apple Mac OS X platform. The virus, named OSX/Leap-A (also known as OSX/Oompa-A) spreads via instant messaging systems....[more]

John