JavaScript  »  Articoli  »  Ajax 

Terzo errore, invio e ricezione di caratteri

Il numero di script, librerie, interazioni basate sull'utilizzo della funzione escapeè sicuramente eccessivo, soprattutto perchè questa funzione non è assolutamente la più indicata per non avere problemi con caratteri di ogni tipo.

La prima considerazione da fare è sul linguaggio stesso, il JavaScript, il quale è basato su unicode.

Unicode è uno standard che ha lo scopo di assegnare un codice univoco per ogni carattere, con la caratteristica di preservare i caratteri ASCII standard, probabilmente i più usati nei sistemi o applicativi occidentali (per approfondire il discorso unicode e charset, si consiglia la lettura di questo tutorial curato dal W3C).

Tutto questo è strettamente correlato con escape, poiché questa funzione non è in grado di codificare in modo standard o comprensibile tutti i caratteri definiti da unicode. Una delle codifiche più usate, nonché adatta, per inviare, ricevere o leggere caratteri è quella UTF-8. Per essere quindi certi che non ci saranno problemi di comunicazione tra le stringhe JavaScript ed il linguaggio server-side è sempre consigliabile sfruttare questa codifica.

L'unica funzione in grado di fare bene questa conversione da carattere a codifica UTF-8 è la funzione encodeURIComponent.

Ajax si basa sullo scambio di coppie chiavi/valori ed un valore di tipo stringa potrebbe contenere tantissimi caratteri di vario tipo, compresa la e commerciale "&", il segno + e tanto altro ancora. Con encodeURIComponent ci si assicura che tali coppie vengano non solo preservate per l'integrità del dato, ma anche rese compatibili con tutti i linguaggi server-side attuali in grado di supportare o manipolare UTF-8.

La funzione escape invece non converte i caratteri in modo standard e codifica quelli esterni al range 0-255 in modo totalmente inutile per qualunque linguaggio, a meno che questo non preveda la ricezione di tali caratteri e non sia in grado quindi di riconvertire nuovamente gli stessi in un formato più utile. Un esempio è dato dal carattere unicode 256, rappresentato da escape come stringa %u100, fino all'ultimo supportato da escape, il carattere %uFFFF.

Sfruttando invece encodeURIComponent il server riceverà la giusta stringa in formato multibytes e non dovrà fare altro che, eventualmente, convertire tale formato in quello scelto per l'elaborazione dei dati. Nel caso di PHP, ad esempio, sarà sufficiente utilizzare la funzione utf8_decode prima di lavorare sui dati in ingresso, per poi eventualmente utilizzare utf8_encode prima di restituirli nuovamente al client.

Per vedere quali siano effettivamente le differenze tra l'uso di escape e di encodeURIComponentè possibile dare uno sguardo a questa tabella.

Per concludere l'argomento, ecco il consiglio: utilizzare sempre encodeURIComponent per inviare dati tramite Ajax al fine di universalizzare il dato in uscita e di semplificarne la ricezione da parte del linguaggio server. Qualora l'applicazione preveda browser datati che non supportano tale funzione (esempio Internet Explorer <= 5), non utilizzare escape nemmeno come alternativa ma sfruttare una delle funzioni disponibili in rete per la retrocompatibilità.

Conclusioni

Purtroppo ci sono tanti altri errori o problematiche inerenti lo scambio dati asincrono e questi analizzati sono forse i più comuni e quindi importanti. Discussioni sulla sicurezza, sull'uso di buone pratiche, sugli approcci e quant altro sono all'ordine del giorno nei siti internazionali dedicati all'interazione asincrona, il consiglio finale è quindi quello di approfondire sempre la questione a seconda delle esigenze di sviluppo del progetto.

Altri articoli

Altre guide

Altre newsletter