Ho un problema nel passaggio di variabili tramite l'utilizzo dell'oggetto xmlhttprequest.
In pratica in un campo form inserisco un carattere tipo il '+' quando vado a salvarlo nel DB il + non viene caricato insieme agli altri caratteri presenti nella stringa.
Hosting, VPS, SSL e Domini: https://www.blooweb.it
Eh sì...
Problemino non solo serio, ma che può farsi catastrofico se anzichè un + inserisci un & o un %.
Ti diranno che devi risolverlo sul lato del server facendo l'escaping, facendo htmlspecialchars, facendo nu' sacco di cose...
La verità è che Ajax con i caratteri &+% può darti problemi assai seri, che non è facile ovviare poichè potrebbero ripresentarsi in altre maniere subdole.
Il + viene frainteso come un carattere rappresentativo dello spazio bianco nelle url (stai inviando una richiesta HTTP, ricordi?).
L' & come ad esempio (Jonny & soci) viene frainteso come un separatore di un nuovo elemento della query.
Il % viene frainteso come l'inizio di una entità "encoded".
Nel tuo codice ajax, supponendo che l'input sia affidato ad una variabile di nome "send":
send=send.replace(/\&/g, '#38#');
send=send.replace(/%/g, '#37#');
send=send.replace(/\+/g, '#43#');
send=unescape(send);
Poi, sul lato del server dovrai incaricarti di ritrasformare
#38# in &
#37# in %
#43# in +
prima di immettere nel DB.
Quei numeri non è che sono scelti proprio a caso, ma i due caratteri # che li circondano sì: è un tentativo, ineremente problematico, di cercare delle stringhe che assai probabilmente non saranno state immesse dall' utente nei suoi testi - se lo fossero, avverrebbe una traduzione errata.
Penso che non lo siano, ma ovvio che se vuoi essere del tutto certo ti toccherebbe fare un loop che verifica la presenza (indexOf) della stringa nell' input, e se c'è vi aggiunge che so un altro # e poi riverifica e se c'è vi appende un altro # e cosi via finchè non individua un indexOf<0, e a quel punto puoi usarlo come un replacement in maniera sicura, solo che poi come lo comunichi al server? Ti toccherebbe fare un altro ajax che setta una variabile di sessione... e poi al response lancia l'altro ajax.
Ti ringrazio per l'analisi completa che hai fatto, in questo caso mi serve solo quel carattere in particolare, anche altri, tipo il '-' ma pare che questo funzioni, proprio perchè non rientra nel discorso dei caratteri speciali appesi agli url.
Grazie ancora
Alessio
Hosting, VPS, SSL e Domini: https://www.blooweb.it
Si il - non dà problemi. Http request è un HTTP a tutti gli effetti. Ti conviene prendere in considerazione anche gli altri due casi della & e del %, a meno che gli input anzichè dagli utenti non arrivino da te e siano quindi sotto il tuo completo controllo.
Ci sarà magari anche qualche altra soluzione che quella suggerita da me, ma tutte quelle che mi hanno suggerito finora, riportavano in un modo o l'altro alla riproposizione del problema. Magari sbaglio io.
Buon lavoro!
Non sono sicuro che faccia al caso tuo, comunque prova a legge questo articolo.Originariamente inviato da powerflash2
Ho un problema nel passaggio di variabili tramite l'utilizzo dell'oggetto xmlhttprequest.
In pratica in un campo form inserisco un carattere tipo il '+' quando vado a salvarlo nel DB il + non viene caricato insieme agli altri caratteri presenti nella stringa.
Cavicchi Andrea
Problemi con javascript, jquery, ajax clicca qui
Sì è un buon riferimento, il fatto comunque è che resta un qualche livello di problematicità, come peraltro anche quell' articolo stesso riconosce in conclusione. cito:
=====
Purtroppo ci sono tanti altri errori o problematiche inerenti lo scambio dati asincrono
=====
Utilizzare encodeURIComponent forse è una soluzione, io stesso potrei provarla anche se non si capisce perchè così tanti altri autorevoli autori insistono per usare unescape.
Ma il fatto che l' articolo poi menzioni la necessità di ricorrere (nel caso sul server ci sia PHP) a quanto cito:
=====
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.
=====
questo mi fa storcere un po' il naso.
Significa che il tuo DB deve essere in UTF-8 (ed io stesso suggerisco vivamente di far sì che lo sia, sempre), ma quelle conversioni utf8_encode e utf8_decode le ho vedute spesso fare cose bizzarre e inattese. Si dirà: scarsa comprensione dell' argomento. Può essere: epperò io mica sono tanto stupido, e se allora sto faticando a comprenderlo, vuol dire che qualche confusione di troppo in giro e non solo nella mia testa c'è.
Gli UTF codificano milioni di caratteri: cosa accadrà tra utf8_encode e utf8_dencode e il tuo Ajax che manda come una URL dei dati immessi dall' utente non si sa con quale keyboard, trattati con encodeURIComponent, per essere inviati ad un database utf8 case insensitive su script php che non si sa se setta NAMES e CHARACTER_SET, e anche se li setta mica è tanto sicuro come risponderanno i varii browsers... Che accadrà? ANdrà tutto liscio se usiamo encodeURIComponent? Forse.
Insomma, io mi sono affidato ad un search e replace (che dopo tutto non sembra più impegnativo che tutto il lavoro di cui sopra) e a rischio di effettuare una inversione sbagliata di un paio di caratteri dentro un post magari futile e peraltro solo in circostanze assai sfortunate, forse mi sono risparmiato un po' di mal di testa appresso a cose che dovrebbero funzionare e che troppo spesso, in 11 anni di programmazione, ho veduto non funzionare affatto come previsto dalla manualistica :-)
Core JavaScript 1.5 Reference penso che come reference possa essere sufficenteUtilizzare encodeURIComponent forse è una soluzione, io stesso potrei provarla anche se non si capisce perchè così tanti altri autorevoli autori insistono per usare unescape.
Sarà ma mi fido molto di + delle funzioni native di phpInsomma, io mi sono affidato ad un search e replace (che dopo tutto non sembra più impegnativo che tutto il lavoro di cui sopra) e a rischio di effettuare una inversione sbagliata di un paio di caratteri dentro un post magari futile e peraltro solo in circostanze assai sfortunate, forse mi sono risparmiato un po' di mal di testa appresso a cose che dovrebbero funzionare e che troppo spesso, in 11 anni di programmazione, ho veduto non funzionare affatto come previsto dalla manualistica :-)
a mettere le mani nella codifica se non sai veramente
quello che stai facendo rischi veramente di fare dei
macelli .............
Without faith, nothing is possible. With it, nothing is impossible
http://ilwebdifabio.it
i nomi, grazie ...Originariamente inviato da TrueLies
Utilizzare encodeURIComponent forse è una soluzione, io stesso potrei provarla anche se non si capisce perchè così tanti altri autorevoli autori insistono per usare unescape.
attenzione ... devi usare utf8_decode proprio se non stai usando dati in database codificati con utf8 ... siccome PHP è un linguaggio semplice e lo usano anche persone poco interessate che snobbano di solito e totalmente i problemi relativi alla codifica da sempre presenti in PHP (non a caso la 6 utilizzerà una codifica non proprio utf-8 ma almeno che si avvicina un pò, utf16 o 32, non ricordo), non potevo scrivere che la gente che non si preoccupa della codifica è destinata a fare sempre e solo siti che non prevedono caratteri stranieri ... quindi quello è un consiglio per chi non usa codifica UTF8, mentre considera che i nuovi linguaggi o quelli un pò più accorti usano da sempre Unicode o UTF8 per inviare e ricevere dati.Originariamente inviato da TrueLies
Ma il fatto che l' articolo poi menzioni la necessità di ricorrere (nel caso sul server ci sia PHP) a quanto cito:
=====
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.
=====
questo mi fa storcere un po' il naso.
Significa che il tuo DB deve essere in UTF-8 (ed io stesso suggerisco vivamente di far sì che lo sia, sempre), ma quelle conversioni utf8_encode e utf8_decode le ho vedute spesso fare cose bizzarre e inattese. Si dirà: scarsa comprensione dell' argomento. Può essere: epperò io mica sono tanto stupido, e se allora sto faticando a comprenderlo, vuol dire che qualche confusione di troppo in giro e non solo nella mia testa c'è.
Non c'è naso da storcere, casomai un pò di tempo da perdere per capire meglio qual'è la problematica, anche perchè escape è una funzione JavaScript e solo JavaScript ( ... e c'è pure una tabella comparativa per dimostrare che escape è incompatibile con tutti se non con unescape ... o in determinati casi, per compatibilità proprio col JavaScript, JSON ... ma è tutt'altro discorso .. ), nel senso che tutti gli altri ECMAScript compatibili fanno codifica come encodeURIComponent a partire dal buon vechio ActionScript 1.0 (... e siamo alla 3 ...) seppur la funzione si chiami escape ed unescape la codifica usata è quella corretta, la corrispettiva di encodeURIComponent.
In soldoni, usare escape per inviare dati di ogni tipo in Ajax è semplicemente un errore, tutti gli autori veramente autorevoli che puoi trovare in rete utlizzano encodeURIComponent
ecco perchè ho scritto di utf8_decode ed utf8_encode con PHP, capace di manipolare correttamente questo tipo di codifica grazie alle apposite funzioniAjax 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.
Ma sai non è questione di nomi, non è che uno manda a memoria i nomi dei programmatori che incontra. Ad ogni modo non credo affatto che ti sarebbe difficile navigare la rete e trovare a cascata esempi di ajax che usano unescape. Ti fai una ricerca su google riguardo ad Ajax e li trovi. Non è questione di chiedere i nomi quasi che uno abbia piacere ad inventarsi le cose. Qui nessuno si inventa le affermazioni per amor di tesi.
I codici che usano escape ce ne sono eccome, e i tutorial anche: faccio una rapida ricerca per te e trovo in pochi minuti:
http://www.xul.fr/en-xml-ajax.html non usa nè l'uno ne l'altro
http://publicliterature.org/ajax/
http://www.modernmethod.com/sajax/
http://developer.mozilla.org/it/docs/AJAX:Iniziare pare manco citi il problema
Certo, toccherà mettersi d'accordo su cosa si intende con autorevole: se per te autorevole è quello che usa encodeURIComponent, non si qualificano; se invece per autorevole si intende abbastanza letto e noto, bhe quelli lo sono.
Non sto perorando la causa di escape contro quella di encodeURIComponent: mi sto solo chiedendo se merita, anche a livello di benchmark, applicare un encodeURIComponent che poi richiede sul lato server l'utilizzo di funzioni orientate all' utf-8, o piuttosto un semplice search e replace che mette delle entities, o pseudo entities (che dopo tutto sono proprio quello che una url manipola) per poi lasciare che il server, anzichè usare funzioni utf-8 andata e ritorno, utilizzi a sola andata un banalissimo str_replace che ti rimpiazza i caratteri della enciclopedia britannica in un secondo.
Insomma, mi sto chiedendo se davvero coloro che usano escape sbagliano. ECMAScript non entra mai nelle mie considerazioni - e guarda che io sono uno che codifica XHTML Strict e che _valida_ e lo faccio perchè ho _motivo_ di farlo non perchè ci "credo". Ma non mi interessa la compliance con un paradigma astratto che non trova riscontro visto che noi è Javascript che usiamo. Io encodeURIComponent sono prontissimo ad usarlo, se _serve_, non se è accademicamente corretto - ti prego, considerami un barbaro :-)
Ti faccio una domanda precisa, sperando che tu saprai essere più diligente di me: in termini di performance hai mai misurato (ipotizzamo un input di 65000 bytes) il rapporto tra:
replace
escape
Server: str_replace
e
encodeURIComponent
Server: utf8_encode
Server: utf8_dencode
Sai dirmi nulla in merito? Nel senso che sono capacissimo di testarmelo da me, ma se tu già hai dei dati magari mi risparmio la laboriosità del test.
Infine, o forse solo in altre parole: quale è il motivo per cui, per ovviare all' inconveniente datoci da 3 caratteri (& + %) dobbiamo codificarne a dozzine inclusi parentesi e quant' altro che problemi ad Ajax non ne darebbero, e chiedere al server di effettuare due conversioni manipolando evidentemente, in 65000 caratteri, magari anche alcune migliaia di dati (immagina un Ajax che invia codici a un forum)?
E' che i manuali ci dicono che non è ECMA compliant usare unescape, e che non fa molto fine inventarsi tre entities per accomodare quei tre casi?
Oh lo chiedo senza polemica, sia chiaro: è che vorrei davvero capirla questa cosa; desidero _davvero_ capire se ci imbarchiamo in una conversione così massiccia degli input solo perchè è inelegante o remotamente rischioso (quanto a fedeltà dei dati convertiti, non quanto ad altro) occuparci dei 3 caratteri problematici di "persona" anzichè affidarci alle cure onnnicomprensive di una metodologia built in.
Grazie, ciao
Permessi di invio
Rispondi quotando