È necessario utilizzare Latin-1 su UTF-8 per la configurazione del database?

Unicode è certamente difficile, e la codifica UTF-8 ha un paio di proprietà scomode. Tuttavia, UTF-8 è diventato la codifica standard di fatto sul web, superando ASCII, Latin-1, UCS-2 e UTF-16. Solo usa UTF-8 ovunque .

Il motivo più importante per cui dovresti supportare Unicode è che non dovresti fare supposizioni non necessarie sull'input dell'utente. Non ho idea di cosa sia il tuo dominio, ma cose come i nomi utente ebraici, un post sul blog in Cina, un commento con Emoji, o semplicemente un testo in stile - come "questo" - dovrebbero essere possibili ... Oh, quelle erano virgolette tipograficamente corrette ( “” anziché "" ), trattini a larghezza intera e un'ellissi, che sono caratteri comuni nel testo inglese, ma non supportati da ASCII o Latin-1. Quindi non supportare altri script non è solo un grosso problema per altre culture, ma attenersi a Latin-1 non ti permette nemmeno di scrivere un inglese corretto.

L'idea che Unicode consenta solo "caratteri errati" è errata. Sì, il testo è davvero complicato e Unicode non lo nasconde a te. Il tuo capo potrebbe pensare a caratteri composti, in cui un codepoint di base come a viene modificato da successivi codepoint che ad es. rappresenta i segni diacritici per formare un carattere visivo come á . Questo non ti disturba davvero quando cerchi di fare ricerche se fai qualche tipo di normalizzazione. Ad esempio, è possibile memorizzare tutto il testo nel modulo NFC che comprime tali composizioni nel loro modulo precomposto, se disponibile. Quando esegui una ricerca, puoi anche rimuovere tutti i caratteri di composizione dal testo, ma questo potrebbe cambiare sostanzialmente il loro significato in alcune lingue.

Unicode aggiunge anche molti caratteri non stampabili, ma anche ASCII ne contiene molti. Gestirai un NUL nel mezzo di una stringa? Che ne dici di 0x1C, un "separatore di file"? Non ho mai visto metà di quelli . Latin-1 aggiunge un trattino morbido che indica opportunità di interruzione di parole, ma è altrimenti invisibile. Rompe anche la ricerca full-text? In altre parole, anche ASCII e Latin-1 ti consentono di interrompere completamente il tuo input se ritieni che sia tutto solo testo stampabile!

Penso che al di là della domanda tecnica, il tuo capo potrebbe non avere il tempo di tenersi aggiornato sugli standard attuali.

Dal momento che la sua posizione non è completamente fuori a pranzo, solo obsoleto, rispettare la sua posizione quando si discute di questo argomento (e bisogna ricordare a discutere , non discutere), e provare a lavorare attraverso preoccupazioni che ha nei confronti di UTF-8. Sospetto che il problema di fondo non sia un problema tecnico e potrebbe richiedere un certo livello di negoziazione di competenze soft.

Which of us is right?

C'era una volta, il tuo capo era. Ma col passare del tempo, le cose cambiano. Al giorno d'oggi, sei (ma prima di correre dal tuo capo, assicurati di leggere anche la risposta di Nelson ).

Le vecchie versioni di MySQL e le vecchie versioni di principalmente tutto , si sono rivelate molto migliori con il precedente Latin1 / ISO-8859-1 (5) rispetto a UTF8.

C'è una ragione per cui UTF8 è stato creato, evoluto e spinto per lo più ovunque: se implementato correttamente, funziona molto meglio . Esistono alcuni problemi di prestazioni e archiviazione derivanti dal fatto che un carattere Latin1 è 8 bit, mentre un carattere UTF8 può essere lungo da 8 a 32 bit. Pertanto, quando si pianifica VARCHAR è necessario tenerne conto. E le tue routine di ricerca saranno un po 'più lente. Saranno in grado di fare più cose (es. Ricerche con sensibilità all'accento o senza . fai quelli in Latin1 senza molto lavoro), ma loro prenderanno un po 'più di tempo.

D'altro canto, la memoria è economica , il sovraccarico realistico per le dimensioni dei file è inferiore al 2-3%, la potenza di calcolo è anche economica e sta diventando più economica buon accordo con la legge di Moore; mentre il tuo tempo e le aspettative dei tuoi clienti sicuramente non sono .

Potresti doverti preoccupare degli strumenti di ricerca, ecc. se tu eri quello che sviluppa tali strumenti. Ma probabilmente non lo sei. usi quegli strumenti; anche quelli che non erano completamente conformi a UTF8 ieri (come non lo erano i precedenti MySQL), sono oggi, o presto lo saranno (per esempio MySQL con supporto utf8mb4).

Quindi, pianificando attentamente e implementando UTF8 nel modo giusto ( not schiaffo su Latin1 come ripensamento) puoi avere un codice che è a prova di futuro molto ragionevolmente, che , se hai intenzione di fare affari con qualsiasi paese asiatico, è una cosa molto buona. E se non hai piani del genere, le altre persone avranno e quelle persone potrebbero essere i tuoi clienti, fornitori o partner.

Quindi quando iniziano a inviarti dati UTF8, dovrai impostare un complicato thingamajig per convertire da e verso Latin1 e affrontare casi irrisolvibili.

Quando calcoli nel budget il costo di diverse schermaglie contro i ninja mojibake malvagi , e considera che non hanno intenzione di andare via - come hai già scoperto - allora ti renderai conto che andare in UTF8 non è solo più semplice, sarà più economico .

Alcune situazioni in cui la limitazione del set di caratteri solo a ASCII può avere senso è per campi di scelta limitati, ad es. campi di stato, perché si controllano rigorosamente i valori che possono esserci, e la chiave / i riferimenti esterni al sistema esterno, perché raramente vi sono motivi per cui hanno solo caratteri alfanumerici e alcuni simboli.

Per qualsiasi altro testo, usa UTF-8.

Per iniziare con la risposta, non importa, come è configurato il server . La codifica dei caratteri in MySQL può essere configurata per colonna (significa che la stessa tabella potrebbe contenere caratteri in più codifiche, facile). Cioè il mio server (e una serie di database legacy in esso contenuti) è configurato per cp1251 per impostazione predefinita per i vecchi client che non sono in grado di impostare le regole di confronto corrette (diversi client hardware), ma i database principali in produzione utilizzano UTF-8.

Parlando di "spazio sprecato" - non si può realisticamente chiamare dati importanti come rifiuti, vero? L'aumento dello spazio di archiviazione, tuttavia, sarà diverso a seconda della lingua in cui si trovano i dati. Da un aumento insignificante (meno dell'1%) se il sito è principalmente in inglese e fino al 100%, se è mailny utilizzando caratteri esterni all'intervallo ASCII . E ancora di più, se ti sposti verso est. Le specifiche successive di UTF-8 (le cosiddette UTF8mb4) consentono fino a 4 byte per punto di codice.

E a "chi ha ragione" ... La verità è che questa è una domanda sociale più che tecnica. Potrebbero esserci motivi validi per specifiche configurazioni del server, ma è necessario conoscere le implicazioni. Ma se me lo chiedi, non c'è motivo di non usare UTF-8. È l'unico tipo che regola tutti i testi del mondo.

Spiegagli che UTF-8 è l'impostazione predefinita per il traffico web. E ogni utente può inserire qualsiasi carattere Unicode valido nel proprio browser.

È molto più facile avere utf-8 / unicode dall'inizio alla fine del back end piuttosto che affrontare i numerosi e vari problemi che risultano da utf-8- > latin-1- > utf-8.