Convertitore escape Unicode

Chi esegue il debug di payload JSON, bundle di risorse Java o letterali di stringa JavaScript incontra di continuo la forma barra-u: quattro cifre esadecimali dopo \u che rappresentano un'unità di codice UTF-16. Lo strumento gratuito del browser e l'API a pagamento condividono un unico nucleo deterministico, così le dimostrazioni in aula, i controlli di CI e i webhook live concordano sempre sulla stessa mappatura al prezzo pubblicato di $0.002 per elemento riuscito.

Come gli escape \uXXXX mappano le unità UTF-16

Java, JavaScript e la grammatica delle stringhe JSON descrivono il testo Unicode con lo stesso escape classico: una barra rovesciata, la lettera u ed esattamente quattro cifre esadecimali. Quel disegno coincide con ciò che si vede nell'output di JSON.stringify, in molti file Properties Java e nel JavaScript più datato precedente all'escape di code point \u{…}.

Cosa si invia e cosa si riceve indietro

Invi un campo stringa obbligatorio chiamato text e un campo opzionale mode impostato su encode o decode. Encode trasforma ogni carattere in unità contigue \uXXXX: Hi diventa \u0048\u0069, e una stringa che mescola ASCII con café e un emoji produce un risultato più lungo ma completamente escapato. Decode inverte il processo: sostituisce ogni \uXXXX ben formato con l'unità di codice corrispondente, ricombina le coppie surrogato in un unico carattere quando sono presenti entrambe le metà e conserva i caratteri letterali mai escapati, così gli incolla misti funzionano ancora. I fallimenti di validazione non consumano il saldo prepagato. Quando mode è omesso, encode è il valore predefinito, così un solo payload resta utile. In decode sono accettati i compagni JSON comuni come \n, \t, \r, \\ e \", così un frammento copiato da un letterale di stringa non fallisce al primo escape di nuova riga. Le risposte di successo riportano mode e il text originale, restituiscono result come stringa di output principale e includono length, code_units (unità UTF-16 elaborate), escape_count (quante forme \uXXXX sono state prodotte o consumate), un'etichetta format \uXXXX e una breve nota standard che nomina Java, JavaScript e JSON. Text assente, valori di mode non supportati, stringhe più lunghe del massimo documentato, hex troncato dopo \u, cifre non esadecimali dentro un escape e sequenze a barra sconosciute falliscono con invalid_input e un messaggio in inglese che nomina l'indice o il campo. Il prezzo delle chiamate API riuscite è la base pubblicata di $0.002 per elemento.

Dove compare la conversione di escape Unicode nel lavoro reale

Client mobili e desktop che parlano con backend Java a volte registrano bundle in stile Properties pieni di sequenze \u per ogni etichetta accentata; i team di supporto incollano quelle righe su una landing dedicata al convertitore anziché cercare impostazioni dell'IDE. I corsi di programmazione insegnano che la lunghezza di una stringa JavaScript conta le unità UTF-16, non i caratteri percepiti dall'utente, e un codificatore live che mostra due escape per un emoji rende concreta quella lezione. Se servono elenchi di scalari U+ senza barre, dump hex grezzi UTF-16, codifica percent per URL o entità HTML nominate, li tratti come intenzioni di ricerca e landing separate anziché sovraccaricare questa pagina di sequenze di escape Unicode: quegli strumenti rispondono a query diverse anche quando il codice sottostante è breve. Gli autori di API e webhook ricevono spesso JSON in cui nomi di prodotto non ASCII o didascalie generate dagli utenti appaiono completamente escapati; decodificarli in testo leggibile accelera il triage senza avviare un runtime applicativo completo. Poiché questa capacità è un motore di parse puro, il prezzo API resta alla base pubblicata di $0.002 per elemento riuscito e la validazione fallita non consuma saldo.