Allora baldi giovini, vi spiego come sta la cosa con Ajax e encodeURIComponent. Può darsi che non accontenterà, come spiegazione, i palati raffinatissimi: ma quel che importa è che accontenti i palati di chi può essere indotto in errore dagli errori dei palati raffinatissimi :-) - come il nostro povero utente del forum che riscontrò dei problemi non più tardi di ieri.
A chi si rivolge il post: programmatori diligenti, capaci di creare applicazioni anche di complessità elevatissima, che in realtà sono in grado di competere con chiunque (magari perdono, ma si battono bene: come diceva il mio Mister :"me sei piaiciuto: c'hai avuto er core"), e che sono incorsi nella seguente problematica: due anni fa (diciamo a febbraio o marzo del 2005? Ma sì, diciamo) si sono avvicinati ad Ajax.
Ovviamente interessati al tema, si sono anche con una certa diligenza studiati alcuni tutorial su questa nuova tecnologia.
Epperò sono incorsi in una terribile disdetta: se ne sono letti 3 o 4, magari anche lunghi, ma in un tempo in cui una problematica relativa ad Ajax non era da tutti i tutorial evidenziata: alcuni caratteri, e particolarmente & + %, quando inviati ad Ajax tramite un campo form, possono essere letti da Ajax (se volete "fraintesi") come entità di codifica (%), come spazi bianchi (+) o come elementi di query (&).
Può darsi che alcuni tutorial dell' epoca evidenziassero il problema, ma voi siete stati sfortunati, e vi siete letti proprio quei 3 o 4 tra i circa... 400 che allora accusavano lo stesso problema, cioè dove la tematica non era affrontata nella maniera corretta - anzi, o non era affatto segnalata, o era proprio affrontata nella maniera sbagliata. Ve ne erano di simili che giravano anche su HTML. it e non è colpa di nessuno: era solo una cosa che allora accadeva un po' dovunque.
A quel punto avevate acquisito Ajax, ma con un errore.
Certo, avreste potuto leggervi altri 5 tutorial al mese nei mesi successivi, e magari allora sareste arrivati alla fase in cui il problema era più generalmente riconosciuto.
Però non lo avete fatto. Birichini! Maleducati! Magari avevate da leggervi anche JP Sartre, o Jane Austen, o Immanuel Kant, e avete incautamente presunto che 3 o 4 tutorial bastavano. Male! Dovete passare tutto il santo giorno a leggervi tutorial su tutto! Sempre! Ogni giorno ne porta una nuova... di correzione. Mi raccomando :-)
In seguito siete incorsi nel problema suddetto. Quando? Diciamo un anno fa o meno. Magari siete gente che come diceva Hemingway "la mia carne io me la vado a cacciare da solo" - e, riscontratolo, ci avete lavorato su da soli. Male! Non si lavora da soli, si deve sempre andare a chiedere aiuto alla mamma!
Magari venite fuori dai tempi di Netscape 4, tempi duri, che vi hanno abituato che i browser fanno i capricci come una regola, non come una eccezione, e che dovevate cavarvela da soli perchè Nestcape 4.01 non era affatto differente da Netscape 4.89). E voi lo avete fatto. Avete trovato una qualche patch o soluzione non proprio ottimale, ma insomma non siete gli unici: il motivo per cui aggiornate i vostri Firefox ed Explorer è che purtroppo accade anche ai programmatori multimilionari della Microsoft e della Netscape di presentare soluzioni non ottimali.
Bhe, i tutorial sono cambiati negli ultimi 18 mesi: molti degli stessi autori che vi dicevano allora una cosa, oggi ve ne dicono una altra.
Lasciate che io vi rassicuri subito: il problema che vi trovate ad affrontare non vi causerà alcun inconveniente serio, e non c'è da promettervi alcuno sfracello: è una fesseria, nè più nè meno. Una vera totale autentica sciocchezza, che non dovrebbe esservi presentata con alcuna urgenza particolare e senza maledizioni, ma con banale serenità.
Vi riaprite la vostra classe Ajax preferita e cambiate due righe - di numero.
Poi vi riaprite un po' di PHP, diciamo anche meno di 10 files se siete stati bravi a fare i vostri templates in maniera razionale, e effettuate la seguente operazione: in tutti i file dove un campo di testo editato dagli utenti è inviato ad Ajax, il value di quel campo lo circondate con encodeURIComponent.
Finito. Tutto qui. Nessuna maledizione, nessun vernacoliere :-)
Siccome voi siete programmatori diligenti, a differenza di altri, il vostro database sarà già in UTF-8, e quindi non dovrete fare niente altro.
Se non lo fosse invece, allora avete un problema di una certa serietà, perchè i tutorial vi stanno comminando ancora una volta un errore - che voi fra 2 anni scoprirete che è tale, e che coloro che proprio oggi ve lo propinano, vi rimprovereranno di avere seguito LOL.
Per cui seguitemi con attenzione.
Se il vostro DB non è in UTF-8 i tutorial correnti vi dicono che per ovviare a quel problema di Ajax potete anche richiedere a PHP di gestire i dati ritornati da encodeURIComponent attraverso un gioco di switching con le funzioni PHP:
utf8_decode
utf8_encode
Sbagliato. Molto.
Se il vostro Db non è in UTF-8 la soluzione non è quella di caricare il vostro server con due (due!) conversioni aggiuntive. Immaginatevi cosa vi accadrebbe se seguiste questo consiglio che alcuni tutorial correnti di oggi (errati, il che non è una colpa, se non fossero così conditi di urgenza e talora anche una certa supponenza - come la mia ahah. E magari voi, ci risiamo: vi siete letti proprio quelli!): mettiamo infatti che voi abbiate la sfortuna di avere un sito di successo (ma come vi permettete!), con diciamo 800,000 utenti, tipo che so un hi5.com.
Mettiamo che avete un aggiornamento del blog o dei gruppi di discussione fatto via Ajax - fico no?
Bhe, seguendo quel consiglio vi ritrovate con 800,000 blog con campi magari di tipo text che potrebbe contenere fino a quasi (quasi) 66mila caratteri e la bellezza, se ogni giorno vi aggiornano diciamo 50000 blog, di oltre tre miliardi di caratteri encode/decode/encode, cioè che il vostro server deve codificare e decodificare. Tutti i giorni.
No. Non fatelo.
La soluzione è, se questo è il vostro problema: convertite tutti i vostri DB a utf8_general_ci.
Il processo può essere assai complesso invero (ho letto di gente che ha incontrato inconvenienti da incubo), ma in linea di massima potrebbe anche andarvi bene e risultare banale. I vostri DB devono essere in UTF-8 sempre e comunque, e i vostri files salvati in utf-8, e le vostre connessioni devono settarne sempre il character set a utf-8.
Una buona regola dice: non fidatevi _troppo_ dei tutorial di oggi, se sono fatti da chi ha sbagliato quelli di ieri ahahah :-)
Buon editing, in 20 minuti avete fatto tutto. E se non lo fate, siccome non dovete farlo affatto per obbligo (le cavallette del Signore non pioveranno su di voi per niente), se un giorno vi capiterà un russo che immette dati nel vostro DB utf 8 essi saranno visualizzati correttamente. Se fa un editing via Ajax non lo sarebbero. Allora voi vi aprite la vostra classe Ajax e cambiate le due righe, e i vostri 8 templates php e ci mettete in una riga ciascuno o massimo due encodeURIComponent. Fatto.
E mi raccomando, non fate nessuna conversione con
utf8_decode
utf8_encode
Per siti ad elevato traffico significa imporre al server un burden non solo inaccettabile, ma peraltro del tutto evitabile - che se si vuole essere bravi programmatori dediti alla ottimizzazione come spesso si pretende di essere, allora dovrebbe interessarci alquanto come problema, e motivarci NON a suggerirvi, magari financo con insistenza, di convertire 3 miliardi di caratteri 3 volte al giorno, ma di convertirli una volta sola, con Ajax, cambiando tutto il vostro DB in utf8_general_ci.
Fine del tutorial. Assai impreciso e con una penna alla Jonathan Swift cioè leggermente caustica, va da sè. E pieno di imprecisioni e di difetti. Ma quanto vero! Voi intanto cambiate encodeURIComponent, e guardatevi dall' usare utf8_decode utf8_encode come se fosse la peste. Si cambia il DB, non si incarica il server di fondere :-)
