Codificatore e decodificatore Base16 RFC 4648

Un input malformato — un numero dispari di cifre hex, un carattere fuori dall'alfabeto o byte che non sono UTF-8 valido — restituisce un errore invalid_input chiaro invece di una corruzione silenziosa. Il percorso è aritmetica di byte pura e deterministica — niente rete, niente semi casuali, niente orologio — quindi l'esecutore gratuito nel browser e l'API prepagata restituiscono sempre lo stesso JSON.

Come chiamare l'API e cosa contiene la risposta

La modalità predefinita è encode: i byte UTF-8 di text diventano una stringa Base16 maiuscola secondo l'alfabeto della RFC 4648. Invii un corpo JSON con un campo stringa obbligatorio text (alias input, value e data) e un mode opzionale che è encode oppure decode. La modalità decode tratta text come un payload Base16 — opzionalmente con spazi o separatori di due punti e case misto — e restituisce la stringa UTF-8 recuperata dopo la normalizzazione. La lunghezza dell'input è limitata a centomila caratteri affinché una singola richiesta non possa esaurire la memoria del Worker con dump patologici. In caso di successo con encode, la risposta include mode, input, result oltre a base16 e hex con la stessa stringa codificata, alphabet con la costante di sedici caratteri 0123456789ABCDEF, alphabet_name con il valore rfc4648_base16, standard con RFC 4648 Base16, input_bytes come conteggio dei byte UTF-8, output_length come conteggio dei caratteri codificati e un breve messaggio in inglese. In caso di successo con decode, la risposta include mode, input, result e text con la stringa UTF-8 decodificata, base16_normalized con la forma continua maiuscola, gli stessi campi alphabet e standard, input_length, output_bytes e un messaggio corrispondente. Una convalida fallita — text mancante, text non stringa, input oltre il limite, un mode sconosciuto, una lunghezza hex dispari, un carattere Base16 non valido o byte decodificati che non sono UTF-8 valido — restituisce invalid_input e non viene mai addebitata. Il prezzo è una tariffa fissa di $0.002 per richiesta riuscita con unità item e prezzo marginale unitario zero.

Consigli pratici, limiti e differenze rispetto ad altre codifiche

I controlli di andata e ritorno sono lo smoke test più rapido: codifichi una parola nota come Hello, confermi il classico risultato maiuscolo 48656C6C6F, poi decodifichi quella stringa e confermi di recuperare la frase originale byte per byte. Non è nemmeno Base58, che elimina i glifi ambigui per la trascrizione umana. E non è un convertitore di basi per interi o float: per convertire un singolo numero hex in decimale o binario, usi le capacità dedicate ai formati numerici invece di trattare le cifre come una stringa opaca di byte. Preferisca Base16 quando le serve un dump 1:1 leggibile per nibble conforme alla RFC 4648 e all'hex dei manuali; preferisca Base64 quando la densità conta più della leggibilità. Per insegnare, mostri la stessa frase codificata in Base16 e Base64 una accanto all'altra così gli studenti vedono perché l'hex è più lungo, sempre di lunghezza pari, e perché A–F maiuscole è la forma standardizzata della Tabella 5 della RFC 4648. Preferisca encode quando parte da testo leggibile o da brevi payload UTF-8 che vuole come dump hex canonico maiuscolo per specifiche, ticket o test unitari. Invii di proposito una stringa hex di lunghezza dispari o un glifo non hex come G o Z in una richiesta decode per verificare che il suo client gestisca invalid_input e il messaggio di errore che cita la regola. Mantenga i payload sotto il limite di caratteri pubblicato; i dump di svariati megabyte appartengono al lavoro offline o a strumenti binari dedicati. Questo strumento non è Base64 né Base64URL: quegli alfabeti usano sessantaquattro simboli con riempimento e un impacchettamento più denso. Le attività fallite che restituiscono invalid_input non consumano saldo prepagato, il che mantiene economici gli script esplorativi quando prova hex malformato.