UKC

i need to convert some hex numbers to decimal and put them into a program, but it says to 'reverse the byte order' before converting. Theres a few numbers i need to convert and the seem to be 4 digits, with a small space (well looks like they are spaced!!) between the first and last two like this:

1b 01
2d 46

although the space is smaller on my list so not sure if it is an actual space or not!! The input box in the program only takes 4 digits, but if i convert 2d46 to decimal i get 11590 which wont fit! I'm assuming the space is important but when i stick 2d 46 into a hex converter i get 45 which is the same as just entreing 2d

What am i doing wrong? And how do i reverse the byte order whatever this means. Is it just typing the number in reverse?

Thnaks

In reply to ed34: Reversing the byte order gives you

01 1b
46 2d

462d in decimal is 17965, so you won't fit that into 4 digits.

In reply to ed34:

if you reverse the byte orderwould it be

01 1b
46 2d

?

do they give a better converson?

In reply to Anonymous:

so the space splits the number into bytes?

and i just reverse the 'blocks' ?

it wont take 011b or 462d still

In reply to ed34:
Not entirely sure what you are trying to do, but here's some background

Some O/Ss are "big-endian", other's are "little-endian", referring to the order in which bytes are stored in a number. A "short" integer has two bytes, a "long" integer has 4 bytes. Hex characters are usually denoted by "0x".

Therefore decimal 283, if stored as a short, is 0x011b on a "little endian" system and 0x1b01 on a "big endian" system.

In C++ there are intrinsic functions you can use - ntohl, ntohs, htonl, htons - but I just wrote my own

In reply to ed34:

Have a read up on "little endian" and "big endian" it's all to do with byte order as stored in memory (or files) in different systems. The reason you *do* have a space between each 2 digits of hex is that each 2 digits amounts to the equivilent of one byte i.e. 8 bits in base 2. It's the most convenient way to represent this kind of data. So simply swap your low and high order bytes and you've reversed the byte order. This gives you:

01 1B
46 2D

In reply to Chris the Tall:

Beat me to it.

In reply to ed34:

ah think i sussed it

I have to convert the blocks seperately

so 1b 01 reversed is 01 1b as said above, then if i convert 01 i get 1, and converting 1b i get 27 so i entered 127 in the program and it seemed happy!

46 2d gives 70,45 so i entered 7045 and it worked

still dont understand it, i tried googling but all the answers were way over my head. I just have to enter the hex numbers in to a program to generate some 30 digit key codes. Anyway the codes seem to be working so far so my trial and error method seems to have worked. I might get stuck when i get to the next set though which are much longer numbers

In reply to ed34:

i guess thats what Chris and Matt have just said then!!

In reply to ed34:

For a bit of background (apologies if you know this):

Each hex digit represents a number 0..15. Four binary bits also represent that number range. A byte is 8 binary bits so you can represent one byte using 2 hex digits. So "1b" is a byte and so is "01".

In reply to ed34:

Yes - but the space does not mean anything. Hex is a convienient notation for binary.

For example, 0xf is the same as 4 bits, the binary of which is 1111

If you had the binary number (and I use spaces to make it easier to read

1111 1111 1111 1111, the hex equivilent is 0xffff and so on.

Since a byte is 8 bits long, it can represent numbers from 0x00 to 0xff or binary 0 to 11111111.

Byte swapping is done as shown by other posters.