Codificatore xxencode

Quel disegno alfanumerico nacque perché i gateway di posta e i sistemi EBCDIC non corrompessero i payload come spesso accadeva con i flussi uuencode. Questa capacità svolge quel lavoro quotidiano: scelga la modalità encode o decode, invii il campo text, opzionalmente indichi il nome file della riga begin e riceva un blocco classico begin-and-end o il testo in chiaro recuperato—oppure un errore invalid_input chiaro se il payload da decodificare contiene un carattere fuori dall'alfabeto xx.

Codificare testo UTF-8 in xxencode classico

Invii un corpo JSON con il campo stringa obbligatorio text uguale al messaggio in chiaro che desidera rappresentare in xxencode, e lasci mode al valore predefinito encode oppure imposti mode su encode in modo esplicito. Un campo filename opzionale (alias name e file) scrive un nome semplice sulla riga begin, ad esempio message.txt; se omesso il nome predefinito è data. Gli alias opzionali input, value e s sono accettati per il campo text quando genera client da nomi di form più antichi. La risposta include sempre result con il blocco xxencode completo, mode uguale a encode, encoding uguale a xxencode, bytes uguale alla lunghezza UTF-8 prima della codifica e filename che ripete il nome della riga begin, così può verificare nelle prove sia la dimensione del payload sia i metadati di intestazione.

Decodificare xxencode in testo e gestire input non valido

Le righe begin opzionali nella forma begin mode filename vengono analizzate per il filename segnalato, e una riga end finale è accettata quando presente; i payload senza involucro sono ugualmente validi purché ogni riga del corpo inizi con un carattere di lunghezza dell'alfabeto. Qualsiasi altro carattere—compresi spazi da un collage uuencode, punteggiatura URL o rumore binario—causa un fallimento immediato invalid_input con un messaggio che nomina la condizione di carattere xxencode non valido, così i client possono correggere il collage invece di ricevere Unicode corrotto. Dopo la validazione di alfabeto e struttura, i byte recuperati vengono decodificati come UTF-8 con un decodificatore fatale: se il payload non è testo Unicode valido, ottiene invalid_input invece di caratteri di sostituzione che corromperebbero le visualizzazioni a valle. I fallimenti di validazione non vengono addebitati sull'API prepagata, quindi sondare un frammento d'archivio sospetto è economico per gli operatori e sicuro per gli utenti finali.

Uso dell'API, prezzi, flussi e limiti pratici

Chiami il codificatore xxencode gratuito nel browser per dimostrazioni in aula, playbook di supporto, controlli di recupero archivi e conversioni una tantum senza installare pacchetti Unix storici o port specifici di linguaggio. Usi l'API prepagata KIT quando un backend, una funzione serverless o un SDK necessita dello stesso passo di codifica o decodifica a saldo a $0.002 per elemento riuscito; la validazione fallita non consuma mai saldo dopo il rifiuto del motore. Un flusso tipico codifica un breve valore di configurazione o un payload di esempio per l'archiviazione in un ticket solo testo, lo spedisce via e-mail o chat che può attraversare hop consapevoli di EBCDIC, poi lo decodifica sul servizio ricevente con mode decode affermando che bytes coincide con la lunghezza originale e che filename coincide con la riga begin. Abbini questo endpoint a uno strumento Base64 quando un partner moderno parla solo Base64, ma mantenga i passi su landing separate affinché ogni pagina corrisponda a un solo intento di ricerca—eredità xxencode e sicurezza EBCDIC contro l'ubiquità di Base64. Gli autori che distribuiscono SDK possono mappare il campo result direttamente su un pulsante di copia, mentre le etichette mode e encoding rendono autoesplicativi gli esempi OpenAPI per i lettori che conoscono solo l'involucro classico begin e end e l'alfabeto alfanumerico.