ebcdic ascii hex dec oct chr Binary Unicode

Recently, I am very interest in understanding more about these different formats:

ebcdic
ascii
hex
dec
oct
chr
Binary
Unicode

-Are there more?
-The ones that I have listed, what use do they have and when would you use it? I know some of them already.
-Why would you convert from one format to another?

I found this but really want to understand the correlations:
http://www.lookuptables.com/ebcdic_scancodes.php

I learned EBCDIC about 10 years ago but can't remember the purpose it serves for today.

Thank You

check this out

http://en.wikipedia.org/wiki/Character_encoding


As I see are all these are some standards to let us (humans) understand the Computer Language (Binary).
Like a translater. Even VB is a Higher Level Translator which helps us to pass Instructions to the Computer in order to do/get something.
In other words , the Computer is like a slave, a dumb slave, who does what we want. :p

:wave:

ASCII and EBCDIC having nothing to do with the other items in your list.

ASCII and EBCDIC are simply two different protocols for determining how what a user sees (a letter or number or symbol) is stored internally. ASCII - for example - stores the letter A as the number 65. EBCDIC stores the letter A as 193. Lowercase "a" is ASCII is 97 - in EBCDIC it's 129.

Notice that 97 is greater then 65 - so uppercase letters sort before lowercase letters in ASCII.

In EBCDIC 129 is less then 193 - so lowercase A sorts before uppercase.

It's a collation sequence difference that is very, very meaningful to the two platforms by which they have come from (EBCDIC being the mainframe/cobol/IBM world).

When we used to receive transmissions on magnetic tape from banks they would typically be in EBCDIC and we would have to translate them to ASCII in order to read the data. It's looked totally meaningless in a NOTEPAD type application - since each "decimal value" was being displayed with ASCII rules but the data was recorded in EBCDIC.

As for hex, decimal and octal - they are simply different "base" systems to look at values. They become meaningful when you layout a grid of the ASCII values using one of these different system. Notice that 97-65 (lowecase a and uppercase A) equals 32. That is a bit - a single bit - that indicates the lowercase-ness of the letter. All lowercase letters in the ASCII chart have this 32'd bit set. Notice that 65 is simply 1 more then 64 - which divides nicely by both 8 and 16. So with all that said - look at this chart.

http://www.asciitable.com/

This chart has 4 columns - it should help you appreciate that 32/64/96 are in a way related. As is 33/65/97 - look along the rows and see how they arranged the collation of ASCII. It makes sense in so many ways.

Now this chart http://ostermiller.org/calc/ascii.html will help you see the OCTAL'ness meaning behind the ASCII collation. It's got 8 columns.

This chart http://www.ascii.cl/ with 16 column "blocks" will help you see how hex means something in this collation sequence. The 33/65/97 that was meaningful in the decimal world is so much more meaningful in hex - where it's 21/41/61.

When you type a CTRL/A it's an ASCII value of 1

0000 0001 in binary is Ctrl/A

The letter A is an ASCII value of 65

0100 0001 in binary is A

The letter "a" in ASCII is value of 97

0110 0001 in binary is "a"

This chart might be the best at helping you see relationships

http://datahunter.com/ascii_chart.pdf

It's got 16 rows (which is very hex - right?) and 8 columns (also hex - but ignoring the high order bit).

Hex basically is taking half a binary value (like I showed above for "a" - 0110 0001 - which in hex is 6 (0110) and 1 (0001). These are nibbles - half a byte.

The reason for 8 columns is that to have "another 8 columns" would require that each nibble had the high order bit set. And of course transmission protocols from decades ago did not allow for 8-bit but instead wanted 7-bit values. Reasons for this are many - one was that some transmission protocols used that 8th bit for parity setting to insure clean transmission.

Thank you szlamany for spending the time to write this post. I am going to digest it tonight.

You are very welcome.