ASCII

ASCII (American Standard Code for Information Interchange, pronunciato “aschi”) è una codifica di caratteri che mappa 128 simboli agli interi 0–127. Definita nel 1963 e standardizzata internazionalmente come ISO/IEC 646 nel 1972.

Copertura:

• 0–31: caratteri di controllo (NUL, newline, carriage return, tab, escape, bell)
• 32–47: punteggiatura e simboli (spazio, !, ", #, $, %, ecc.)
• 48–57: cifre 0–9
• 58–64: altra punteggiatura (:, ;, <, =, >, ?, @)
• 65–90: maiuscole A–Z
• 97–122: minuscole a–z
• 127: DEL

ASCII rientra in 7 bit, motivo per cui i vecchi protocolli seriali e i sistemi telegrafici utilizzavano la trasmissione a 7 bit. L’8° bit diventava il bit di parità. I sistemi moderni usano 8 bit per carattere; i 128 valori superiori (128–255) vengono interpretati diversamente a seconda della codifica scelta (Latin-1, Windows-1252, ecc.).

UTF-8 è retrocompatibile con ASCII — qualsiasi testo ASCII è un file UTF-8 valido con byte identici. Questa compatibilità è uno dei principali motivi per cui UTF-8 ha vinto le guerre delle codifiche Unicode.

Esempio pratico

La stringa “Hi!” codificata in ASCII è composta da tre byte: H = 72 (0x48), i = 105 (0x69), ! = 33 (0x21). Scritta in binario: 01001000 01101001 00100001. Si noti che il bit più alto di ogni byte è zero — questa è la garanzia dei 7 bit. Confrontando con la stessa stringa in UTF-16: 0048 0069 0021 — sei byte per lo stesso contenuto, con l’ordinamento dei byte little-endian che aggiunge un BOM all’inizio. Confrontando di nuovo con UTF-8: identico ad ASCII perché ogni carattere è nell’intervallo 0–127. Ora si provi “café”: ASCII non riesce a codificare la é (Unicode U+00E9); il codificatore dà errore o sostituisce un punto interrogativo. UTF-8 codifica é come due byte 0xC3 0xA9; Latin-1 lo codifica come il singolo byte 0xE9. Lo stesso carattere visibile, tre diverse sequenze di byte a seconda della scelta di codifica.

Il complemento di ASCII per il testo non inglese è Unicode, che assegna a ogni carattere un punto di codice e usa codifiche (UTF-8, UTF-16, UTF-32) per serializzarli come byte. UTF-8 è stato progettato appositamente da Ken Thompson e Rob Pike nel 1992 per essere compatibile con ASCII: qualsiasi file contenente solo caratteri ASCII è identico in ASCII e UTF-8, motivo per cui quasi ogni protocollo wire in lingua inglese e formato di configurazione era aggiornabile a Unicode senza modifiche incompatibili.

Quando e perché è importante

ASCII è importante quando si debuggano bug di codifica, si progettano protocolli wire o si lavora con qualsiasi sistema che elabora il testo byte per byte. Il bug che spedisce una é come “cé” o “cé” o “c?” è sempre un disallineamento ASCII/UTF-8/Latin-1 — da qualche parte nella pipeline, i byte sono stati decodificati con il presupposto sbagliato. Gli algoritmi di ordinamento che trattano le stringhe come byte metteranno le maiuscole prima delle minuscole a causa dell’ordinamento di ASCII — “Zebra” viene prima di “mela” se si ordinano i byte grezzi, sorprendente per gli utenti che si aspettano un ordine lessicografico senza distinzione tra maiuscole e minuscole. Le regole per gli identificatori nei linguaggi di programmazione (nomi di variabili, chiavi JSON) sono solitamente limitate ad ASCII per portabilità tra sistemi la cui codifica predefinita non può essere assunta. Chiunque progetti un formato CSV, un formato di file log o un protocollo wire basato su testo trae beneficio dal sapere cosa sopravvive invariato alla pipeline ASCII rispetto a cosa viene alterato. Riferimento: RFC 20 — ASCII format for Network Interchange.

Perché l’ordine dell’alfabeto è importante: ASCII ha intenzionalmente posto le lettere maiuscole (65–90) prima delle minuscole (97–122) con un offset fisso di 32 tra di esse. Impostare o cancellare il bit 5 di qualsiasi byte di lettera (il bit 0x20) ne inverte il caso — da maiuscolo a minuscolo e viceversa. Questo trucco con i bit è il motivo per cui ogni vecchia libreria di stringhe in C poteva fare tolower() con una singola operazione aritmetica, ed è incorporato in innumerevoli protocolli (nomi di intestazione HTTP, etichette DNS) che sono nominalmente case-insensitive ma si basano su questa esatta equivalenza bit-flip. Il trucco fallisce nel momento in cui arriva Unicode — la I con punto e senza punto del turco è il contro-esempio canonico.

Il retaggio dei caratteri di controllo che nessuno può eliminare: l’intervallo 0–31 porta residui dell’hardware teletype che nessun sistema moderno usa ma ogni parser deve riconoscere. NUL (0) termina le stringhe C; LF (10) e CR (13) dividono le righe (Unix usa LF, Windows usa CRLF, il vecchio Mac OS usava CR da solo); HT (9) è il tab; ESC (27) avvia le sequenze di escape ANSI per i terminali. Il carattere bell (7) un tempo faceva suonare un campanello fisico sui terminali Teletype Model 33; oggi attiva l’API di beep di sistema sulla maggior parte dei sistemi operativi. Nessuno di questi è progettabile oggi — sopravvivono perché mezzo secolo di formati di file e protocolli wire li richiedono. Riferimento: ISO/IEC 646 — Information technology — ISO 7-bit coded character set.