Calcolatore Adler-32

Ingegneri che verificano payload compressi, studenti della RFC 1950 e team di supporto che confrontano trailer da log di dispositivo spesso necessitano dello stesso risultato da manuale per una stringa breve: A iniziale pari a uno, B iniziale pari a zero, entrambe ridotte modulo sessantacinquemilacinquecentoventuno, poi B spostata di sedici bit a sinistra e combinata con A. Questo strumento di checksum Adler-32 accetta testo non vuoto, lo codifica come UTF-8, esegue quel ciclo deterministico e restituisce il valore completo a trentadue bit come otto cifre esadecimali minuscole insieme all’intero decimale, ai parziali A e B e a un breve riepilogo. L’input vuoto viene rifiutato con invalid_input affinché chi chiama non confonda mai un campo mancante con il checksum noto del messaggio vuoto, che vale uno.

Contratto di input, errori di stringa vuota e forma JSON della risposta

L’input vuoto viene rifiutato di proposito invece di restituire il valore teorico del messaggio vuoto zero zero zero zero zero zero zero uno, così UX di prodotto e autovalutatori distinguono risposte mancanti da un checksum reale. Fissi sia un percorso di successo sia l’errore di input vuoto nell’integrazione continua affinché modifiche accidentali di modulo o di inizializzazione non vadano in produzione. I campi null opzionali vengono omessi anziché emessi come null, in linea con il contratto del renderer dichiarativo per form web puliti. Invii un corpo JSON con un unico campo stringa obbligatorio denominato text: qualsiasi sequenza non vuota di caratteri di cui calcolare il checksum. Gli alias input, value, s, data, message e payload sono accettati per lo stesso campo, così stub SDK e invii da form restano flessibili. La stringa viene codificata come UTF-8 prima del ciclo Adler, quindi i caratteri multi-byte contribuiscono con ogni unità di codice esattamente come farebbe un compressore che riceve lo stesso flusso UTF-8. text mancante, valore non stringa o stringa vuota falliscono con invalid_input e un messaggio chiaro che richiede una stringa non vuota; tali fallimenti non vengono addebitati sull’API prepagata. In caso di successo il corpo include result, adler32 e hex tutti impostati sullo stesso checksum esadecimale a otto cifre minuscole; decimal sull’intero senza segno a trentadue bit; a e b sui parziali finali a sedici bit basso e alto; algorithm fisso su Adler-32; input_bytes pari alla lunghezza UTF-8; text che ripete l’input; e message che riassume il conteggio byte e il risultato hex.

Dove un’API di checksum Adler-32 conviene e come funziona il prezzo

Usi lo strumento gratuito nel browser per controlli occasionali; chiami l’API KIT prepagata da backend, funzioni serverless e SDK quando le serve un contratto stabile a saldo di $0.002 per elemento riuscito. Mantenga payload di dimensioni di testo ordinarie adatte a una chiamata item in un Worker isolate; questo strumento è per stringhe brevi e frammenti di protocollo, non per blob binari multi-megabyte.