Uso MySQL per archiviare i dati e le mie pagine Web sono tutte codificate come UTF-8. Ho un sacco di caratteri portoghesi come ç e õ e mi chiedo se dovrei scappare in HTML prima della memorizzazione.Dovremmo codificare in HTML caratteri speciali prima di memorizzarli nel database?
Dovremmo memorizzare & come &, ad esempio? E perchè no)? Quali sono i vantaggi e gli svantaggi/le migliori pratiche?
Non codificare in HTML i caratteri prima della memorizzazione. Dovresti conservare il più puro dei tuoi dati possibile. La codifica HTML è necessaria perché stai per visualizzare i dati su una pagina HTML, quindi esegui la codifica durante l'elaborazione dei dati per creare la pagina. Ad esempio, supponiamo che tu decida che invierai i dati in e-mail di solo testo. Se hai codificato in HTML i dati, ora la codifica HTML è una barriera che devi annullare.
Scegli un modulo canonico per i tuoi dati e memorizzalo. UTF-8 è meraviglioso e il tuo database lo supporta (assumendo che tu abbia creato tutte le tue tabelle correttamente). Basta memorizzare UTF-8.
Sono d'accordo. Questo è l'equivalente HTML della funzione \ "magic quotes \" di PHP. Non è una buona idea, perché non tutti i dati devono sfuggire a & è fastidioso vedere i dati sfuggiti dove non dovrebbe essere. – dan04
Non è lo stesso, viceversa? Quel codice HTML non codificato è una barriera quando è necessario codificarlo? I.m.o. è più probabile che tu debba generare un codice HTML codificato. Nei pochi casi in cui desideri decodificarlo, puoi decodificarlo. È anche più sicuro quando uno sviluppatore si dimentica di decodificare piuttosto che codificare correttamente? Ci possono essere molte posizioni in cui vengono utilizzati i dati, quindi il rischio per uno sviluppatore di dimenticare la codifica è reale. – feskr
Hai mai bisogno di cercarli? Non sono un esperto di MySQL ma potresti dover saltare attraverso i cerchi per fare ricerche.
Sei preoccupato per l'HTML-ness dei dati o la codifica dei caratteri?
Direi di non eseguire alcuna codifica speciale di caratteri nel DB se è possibile evitarlo. Ricerca, dover ricordare elaborazione speciale in entrata/uscita, ecc.
ottimo punto. Non avevo pensato fino a quel momento perché non ho ancora implementato la ricerca. Il mio software è ancora in fase di sviluppo. Ma la risposta è sì, avrò bisogno di cercarli. La loro codifica causa problemi in quel caso?Leggendo il tuo commento, presumo che avrei dovuto codificare i caratteri nella stringa di ricerca prima di inviare la query! – Mohamad
Lo penserei, e anche in questo caso avresti problemi con le "partite ravvicinate". Sono più familiare con SQL Server che ha la corrispondenza con caratteri jolly ('LIKE' - SQL Standard?) Che potrebbe essere problematico con la codifica. – n8wrl
Non lo codificherei nel database a meno che non ci sia un chiaro e preciso valore per farlo. Tu (e chiunque altro lavorerà mai con i dati) dovrai ricordarti di scappare quando usi quei dati o di sfuggire a qualsiasi dato che inserisci, aggiorni o confronti con quel campo. Non sono sicuro di quale sia il vantaggio di evaderlo, ma probabilmente non ne vale la pena.
Se si stanno facendo 100 o 1000 di presentazioni di pagina per ogni scrittura, la codifica in entrata sarà più efficiente. Ma nella maggior parte dei casi, credo che la differenza sarebbe trascurabile.
Ma gli altri motivi (per non codificare) sono buoni, non ci sono dubbi, e comunque è inutile codificare i caratteri che piacciono a UTF-8.
In base allo scopo del Database, non è consigliabile codificare HTML e archiviare i dati. Ciò renderà i dati desiderabili solo per il rendering su pagine HTML (l'unico scopo) e per tutte le altre operazioni (molte) che è necessario decodificare nuovamente. Ciò degrada la coerenza dei dati (poiché validità, accuratezza, usabilità sono ostacolate) proprietà del Database.
Direi che la codifica sulla strada verso il database è in realtà un rischio per la sicurezza, perché significa che presumibilmente non verrà codificata tra database e browser (in quanto ciò porterebbe a una doppia codifica). Ciò significa che se c'è un percorso, ora o in futuro, per i dati non codificati da inserire nel tuo database, questo verrà inviato al browser non codificato. Meglio codificare tra database e browser e quindi memorizzare IMHO non codificato.
ç e õ sono caratteri UTF-8. Se DB li supporta e le tue pagine sono già codificate in UTF-8, allora perché convertire? – bakoyaro
È perché sono abituato a leggere di sfuggire a questa roba che ho pensato fosse prassi normale, apparentemente non lo è! – Mohamad