Cita:
Iniciado por programeitor
asi "10" en hexadecimal es "a" y "17" es "f1".
17 en base 10 corresponde a 11 en hexadecimal, no a f1(0 1 2 3 4 5 6 7 8 9 a b c d e f
10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
20 21 ...
Pasar un byte de binario a hexadecimal: 0000 -> 0
0001 -> 1
0010 -> 2
0011 -> 3
0100 -> 4
0101 -> 5
0110 -> 6
0111 -> 7
1000 -> 8
1001 -> 9
1010 -> a
1011 -> b
1100 -> c
1101 -> d
1110 -> e
1111 -> f
Dada esta tablita, si tenemos un byte lo que hacemos es dividirlo en dos 'trozos' y sustituir las dos sub-palabras por su equivalente hexadecimal
Por ejemplo:
10000111 --- 1000=>8 ; 0111=>7 ->
87h
11011010 --- 1101=>d ; 1010=>a ->
dah
Por otra parte
para convertir de binario a decimal hay que tener muy en cuenta las posiciones de los bits porque de ellas depende su 'peso'. Veamos con un ejemplo:
10010011001,10011
Vemos que tenemos un número con coma binario, con lo cual procedemos asi:
La parte no fraccionaria consta de 11 dígitos, con lo cual para la parte derecha lo que hacemos es multiplicar cada valor por (2^posición). Las posiciones van de 0(a la derecha de la coma hasta el número de dígitos menos 1-> en este caso 10)
Parte entera:10010011001
1x(2^10) + 0x(2^9)+ 0x(2^8)+ 1x(2^7)+ 0x(2^6)+ 0x(2^5)+ 1x(2^4)+ 1x(2^3)+ 0x(2^2)+ 0x(2^1)+ 1x(2^0) = 1x(2^10) + 1x(2^7)+ 1x(2^4)+ 1x(2^3)+ 1x(2^0) = 1024 + 128 + 16 + 8 = 1176
Se denomia pesos de cada bit a la potencia a la que se ha de elevar 2, es una forma de referenciar su posición.
Y bueno para la parte fraccionaria será parecido lo único que los pesos empiezan en -1 (a la derecha de la coma) y crecen hacia la derecha
Parte fraccionaria:10011
1x(2^(-1)) + 0x(2^(-2)) + 0x(2^(-3)) + 1x(2^(-4)) + 1x(2^(-5)) = 0,5 + 0,625 + 0,03125
Lo que sucede es que en Sistemas digitales no se puede mandar una 'coma'(para indicar el comienzo de una parte fraccionaria) o por ejemplo un menos(para indicar que el número es negativo). Esos signos los podemos utilizar nosotros, pero digitalmente sólo se pueden usar ceros y unos.
Y dado ése problema es cuando surgen distintos tipos de soluciones, y encima no son iguales.
Por ejemplo para codificar digitalmente un número que contenga información de signo, es decir indicar mediante una secuencia de 0 y 1 el signo pero sin usar el signo menos, hay varias formas de hacerlo,
signo-magnitud,
complemento a 1 ó
complemento a 2.
Siguiendo esos métodos, se puede dar signo a un número binario.
Pero que pasa si queremos expresar una coma, es decir si queremos representar mediante 0 y 1 un número decimal como por ejemplo 10465,4585. Bueno lo que se hace en ése caso es usar el formato definido por el estándar 754-1985 ANSI/IEE, y la conversión desde, ó a éste formato ya se hace un pelín más complicada.
En definitiva, lo que quería decir con esto, es que el binario es una secuencia de 1s y 0s, pero que dependiendo del tipo de dato que se esté manejando existen multitud de formatos que se pueden aplicar y más adecuados para ése tipo de dato.
Por ejemplo si queremos pasar a binario una dirección IP utilizamos dos bytes y resolvemos a razón de paquetes de 4 bits, pero si queremos pasar un numero decimal con coma es necesario el uso de un formato que use coma flotante como el estándar 754-1985 ANSI/IEE.
La cosa está en lo siguiente, hemos de usar un medio de transmisión de datos que es el digital, por su rapidez(la luz eléctrica jajajaja), pero hemos de adaptar lo que enviamos y lo que recibimos mediante formatos para que la codificación y la traducción de esa secuencia de 1s y 0s nos cueste lo menos posible. En muchos casos la complejidad de los algoritmos de dichos formatos se ve incrementada pero para manejar la menor cantidad de información posible, para evitar redundancias, para reducir posibilidades de errores, etc...(o sea para bien
)
En fin que 'leer binario' puede ser pasar un numero octal, decimal o hexadecimal a binario o biceversa, cosa que en el fondo no es tan complicada, pero cuando te metes en formatos representaciones y tál ya la cosa cambia :S
Salu2 amigos ;)