Convertitore decimale-esadecimale-binario-ottale

Se lavori con networking, Linux, Windows, microcontrollori, SDR o debug a basso livello, ti capita continuamente di incontrare numeri scritti in basi diverse: decimale nei log, esadecimale nei memory dump, binario nelle bitmask e ottale nei permessi Unix classici. Questo convertitore rapido ti permette di incollare un valore in quasi qualsiasi formato comune (inclusi 0x, 0b e 0o) e vedere subito le rappresentazioni equivalenti, i bit/byte raggruppati e, opzionalmente, l’interpretazione signed (complemento a due). È uno strumento pratico per sviluppatori, sysadmin e appassionati di elettronica che vogliono risultati veloci e pronti da copiare quando decodificano registri, flag, campi di pacchetto o quando devono capire valori “strani” in firmware e output di sistema.

Capire le basi numeriche nel lavoro tecnico reale

Quando costruisci, fai debug o ottimizzi qualcosa di tecnico — software, firmware, apparati di rete, ricevitori SDR, server Linux o perfino interfacce audio — prima o poi incontri lo stesso punto critico: i numeri non compaiono sempre nella base “in cui ragioni” naturalmente. I log tendono al decimale, i dump di memoria amano l’esadecimale, le bitmask sono intrinsecamente binarie e i permessi Unix restano spesso in ottale. Un convertitore di basi trasforma questa traduzione mentale continua in un’operazione da un secondo, ed è per questo che questi tool vengono usati ogni giorno.

Questa guida spiega cosa rappresentano davvero decimale, esadecimale, binario e ottale, come riconoscerli “sul campo” e come evitare gli errori più comuni — soprattutto su valori signed, complemento a due, larghezza in bit e endianness.

Decimale vs binario vs esadecimale vs ottale

Decimale

Il decimale (base 10) è il sistema di tutti i giorni. Le cifre vanno da 0 a 9 e ogni posizione rappresenta una potenza di 10.

Esempio:

255 significa: 2×10² + 5×10¹ + 5×10⁰

Nel lavoro tecnico il decimale è comune in UI, metriche, valori di timing, limiti di configurazione e numeri “umani” come “1000 Mbps” o “5 ms”.

Binario

Il binario (base 2) usa solo 0 e 1 e ogni posizione rappresenta una potenza di 2.

Esempio:

11111111₂ = 1×2⁷ + 1×2⁶ + … + 1×2⁰ = 255

Il binario è il linguaggio nativo di:

• flag e bitmask

• mappe registri e periferiche MCU

• permessi, feature toggle, status word

• rappresentazioni DSP/SDR (bit depth, formati campione)

È molto esplicito, ma diventa lungo in fretta.

Esadecimale

L’esadecimale (base 16) usa 0–9 e A–F (o a–f) per 10–15. Ogni posizione è una potenza di 16.

Esempio:

FF₁₆ = 15×16¹ + 15×16⁰ = 240 + 15 = 255

L’hex è popolare perché mappa perfettamente sul binario:

• 1 cifra hex = 4 bit (nibble)

• 2 cifre hex = 1 byte (8 bit)

Ecco perché dump di memoria, indirizzi MAC, hextet IPv6, CRC, hash e valori di registro compaiono spesso in esadecimale.

Ottale

L’ottale (base 8) usa 0–7. È meno comune oggi, ma resta molto rilevante nei sistemi Unix-like.

Uso classico:

• permessi file come 755, 644, 600

Ogni cifra ottale corrisponde a 3 bit (dato che 8 = 2³), quindi è una rappresentazione naturale per i permessi.

Come riconoscere i formati velocemente

Nei sistemi pratici, i prefissi aiutano:

• 0xFF → esadecimale

• 0b1010 → binario

• 0o377 → ottale (Python e tool moderni)

• 077 → ottale in convenzioni legacy (notoriamente stile C “vecchio”)

Non tutto ha prefissi. Alcuni dump mostrano hex “nudo” tipo:

DEADBEEF
FFEE12

Per questo può essere utile riconoscere binario “nudo” (10101100 senza 0b), ma è ambiguo: 10101100 può anche essere decimale. Meglio che sia un’opzione, non il default.

Perché raggruppare bit e byte

Le stringhe binarie lunghe sono difficili da leggere. Il raggruppamento migliora tantissimo la leggibilità:

• raggruppamento per nibble (4 bit):
  10101100 → 1010 1100

• raggruppamento per byte in hex (2 cifre):
  DEADBEEF → DE AD BE EF

È fondamentale quando fai debug di:

• header di protocollo (campi allineati a byte/nibble)

• registri MCU (bit field)

• strutture “packed” e formati binari

Un buon convertitore dovrebbe mostrarlo automaticamente, perché riduce gli errori quando scansionI visivamente un valore.

Larghezza in bit: il pezzo mancante nelle conversioni

Uno degli errori più comuni: pensare agli interi come se fossero “lunghi quanto vuoi”. In realtà hanno una larghezza fissa: 8, 16, 32, 64 bit…

Esempio con 0xFF:

• unsigned 8 bit: 0xFF = 255

• signed 8 bit: 0xFF = -1 (complemento a due)

• unsigned 16 bit: 0x00FF = 255

• signed 16 bit: ancora 255 (bit di segno = 0)

Scegliere la larghezza corretta è essenziale per valori provenienti da:

• registri hardware (spesso 8/16/32 bit)

• pacchetti di rete (campi a dimensione fissa)

• letture signed da sensori

• struct firmware e messaggi “packed”

Con una larghezza N, il comportamento reale è “wrap modulo 2^N”, come fanno gli interi macchina. È lo stesso motivo per cui in C gli overflow unsigned “girano” (wrap-around).

Signed vs unsigned e complemento a due

Idea di base

Un pattern di bit è solo un pattern. Signed/unsigned dipende dall’interpretazione.

• unsigned: 0 a 2^N − 1

• signed (complemento a due): −2^(N−1) a 2^(N−1) − 1

Il complemento a due è praticamente ovunque perché rende l’aritmetica semplice ed efficiente.

Regola mentale rapida

Per un signed su N bit:

• MSB = 0 → valore positivo

• MSB = 1 → valore negativo

Esempio (8 bit):

• 0b01111111 = 127

• 0b10000000 = -128

• 0b11111111 = -1

Interpretazione a mano

Per leggere un valore N bit come signed:

• se MSB = 0: uguale a unsigned

• se MSB = 1: sottrai 2^N al valore unsigned

Esempio:

0xFF (8 bit) = 255 unsigned
signed: 255 − 256 = −1

Ecco perché un toggle “signed interpretation” nel convertitore è così utile.

Esempi pratici reali

Esempio 1: bit flag in un registro di stato

Registro = 0x2D e datasheet:

• Bit 0: READY

• Bit 2: ERROR

• Bit 3: TX_ACTIVE

• Bit 5: LOW_BAT

0x2D → binario 0010 1101

Leggi:

• bit 0 = 1 (READY)

• bit 2 = 1 (ERROR)

• bit 3 = 1 (TX_ACTIVE)

• bit 5 = 1 (LOW_BAT)

Esempio 2: permessi Unix in ottale

755 significa:

• owner: 7 → rwx

• group: 5 → r-x

• others: 5 → r-x

Ogni cifra ottale è 3 bit:

• 7 → 111

• 5 → 101

• 4 → 100

Per questo 644 è “tipico” per i file:

• 6 = 110 → rw-

• 4 = 100 → r–

• 4 = 100 → r–

Esempio 3: numeri negativi dai sensori

Un sensore potrebbe dare un valore signed 16-bit:

0xFF9C

unsigned: 65436 (assurdo come temperatura)
signed: 65436 − 65536 = −100

Se l’unità fosse 0,01 °C, allora −100 significa −1,00 °C. Un convertitore con vista “16-bit signed” evita errori.

Perché NOT, shift e AND/OR/XOR sono utili nel convertitore

Le operazioni bitwise sono ovunque:

AND

Per testare o azzerare bit:

• value & mask
  Esempio: leggere gli 8 bit meno significativi: x & 0xFF

OR

Per impostare bit:

• value | mask

XOR

Per toggle o confronto pattern:

• value ^ mask

NOT

NOT inverte i bit in una larghezza definita.

Su 8 bit:

• NOT 0x00 → 0xFF

• NOT 0x0F → 0xF0

Dettaglio importante: NOT ha senso solo se scegli una larghezza (8/16/32/64 bit). Senza, diventa ambiguo.

Shift

Usati per:

• scalare per potenze di due

• pack/unpack di campi

• costruire maschere

Estrazione campo tipica:

• (value >> 12) & 0xF

Endianness: perché l’ordine dei byte conta

Endianness = ordine dei byte per valori multi-byte.

• big-endian: byte più significativo per primo

• little-endian: byte meno significativo per primo

Per 0x12345678:

• big-endian: 12 34 56 78

• little-endian: 78 56 34 12

Conta perché:

• molte CPU usano little-endian (x86)

• molti protocolli usano big-endian (network byte order)

Un convertitore che mostra le viste byte e permette lo swap di endianness è utilissimo con capture, dump, file binari e bug di serializzazione.

Errori comuni e come evitarli

• pensare che “hex = unsigned”: hex è solo una rappresentazione

• dimenticare la larghezza con NOT o shift: il comportamento dipende dai bit

• confondere ASCII, byte e numeri: ASCII è un encoding, non una regola universale

• credere che i numeri con zero iniziale siano sempre ottali: vale solo in alcuni contesti legacy

• assumere che “101010” sia per forza binario: può anche essere decimale

Dove la conversione di base serve davvero

Se fai anche solo una di queste cose, la userai spesso:

• leggere log kernel o eventi Windows con flag in hex

• decodificare campi pacchetto (Wireshark / raw)

• lavorare con registri MCU (GPIO, UART, SPI)

• reverse engineering di firmware o formati binari

• costruire subnet mask, bitmask, feature flag

• tuning SDR/DSP (bit depth, formati sample)

• interpretare byte MIDI o status word audio

• verificare CRC, hash e checksum

Consigli per sfruttare al massimo il convertitore

• usa prefissi (0x/0b/0o) per eliminare ambiguità

• seleziona una larghezza (8/16/32/64) per hardware e protocolli

• usa il raggruppamento (nibble/byte) per leggere più in fretta e con meno errori

• prova AND/shift/XOR per validare maschere ed estrazioni

• se c’è sincronizzazione via URL, condividi un link per un debug riproducibile