Qual è la migliore raccolta da utilizzare per MySQL con PHP? [chiuso]

Mi chiedo se esiste una scelta "migliore" per le regole di confronto in MySQL per un sito Web generale in cui non si è sicuri al 100% di ciò che verrà inserito? Capisco che tutte le codifiche dovrebbero essere uguali, come MySQL, Apache, HTML e qualsiasi cosa all'interno di PHP.

In passato ho impostato PHP per l'output in "UTF-8", ma quale confronto corrisponde in MySQL? Sto pensando che è uno dei caratteri UTF-8 quelli, ma ho usato utf8_unicode_ci, utf8_general_cie utf8_binprima.

La differenza principale è l'accuratezza dell'ordinamento (quando si confrontano i caratteri nella lingua) e le prestazioni. L'unico speciale è utf8_bin che serve per confrontare i caratteri in formato binario.

utf8_general_ciè leggermente più veloce di utf8_unicode_ci, ma meno preciso (per l'ordinamento). La codifica della lingua specifica utf8 (come utf8_swedish_ci) contiene regole di lingua aggiuntive che le rendono le più precise da ordinare per quelle lingue. Il più delle volte lo uso utf8_unicode_ci(preferisco la precisione ai piccoli miglioramenti delle prestazioni), a meno che non abbia una buona ragione per preferire una lingua specifica.

Puoi leggere ulteriori informazioni su set di caratteri Unicode specifici nel manuale di MySQL - http://dev.mysql.com/doc/refman/5.0/en/charset-unicode-sets.html

In realtà, probabilmente vuoi usare utf8_unicode_cio utf8_general_ci.

• utf8_general_ci ordina eliminando tutti gli accenti e ordinandoli come se fossero ASCII
• utf8_unicode_ci utilizza l'ordinamento Unicode, quindi ordina correttamente in più lingue

Tuttavia, se lo stai usando solo per memorizzare il testo inglese, questi non dovrebbero differire.

Sii molto, molto consapevole di questo problema che può verificarsi durante l'utilizzo utf8_general_ci.

MySQL non distinguerà tra alcuni caratteri nelle istruzioni selezionate, se utf8_general_civiene utilizzata la raccolta. Ciò può portare a bug molto sgradevoli, specialmente ad esempio in cui sono coinvolti nomi utente. A seconda dell'implementazione che utilizza le tabelle del database, questo problema potrebbe consentire agli utenti malintenzionati di creare un nome utente corrispondente a un account amministratore.

Questo problema si espone almeno nelle prime versioni 5.x: non sono sicuro che questo comportamento sia cambiato in seguito.

Non sono un DBA, ma per evitare questo problema, vado sempre con utf8-bininvece di maiuscole e minuscole.

Lo script seguente descrive il problema con l'esempio.

-- first, create a sandbox to play in
CREATE DATABASE `sandbox`;
use `sandbox`;

-- next, make sure that your client connection is of the same 
-- character/collate type as the one we're going to test next:
charset utf8 collate utf8_general_ci

-- now, create the table and fill it with values
CREATE TABLE `test` (`key` VARCHAR(16), `value` VARCHAR(16) )
    CHARACTER SET utf8 COLLATE utf8_general_ci;

INSERT INTO `test` VALUES ('Key ONE', 'value'), ('Key TWO', 'valúe');

-- (verify)
SELECT * FROM `test`;

-- now, expose the problem/bug:
SELECT * FROM test WHERE `value` = 'value';

--
-- Note that we get BOTH keys here! MySQLs UTF8 collates that are 
-- case insensitive (ending with _ci) do not distinguish between 
-- both values!
--
-- collate 'utf8_bin' doesn't have this problem, as I'll show next:
--

-- first, reset the client connection charset/collate type
charset utf8 collate utf8_bin

-- next, convert the values that we've previously inserted in the table
ALTER TABLE `test` CONVERT TO CHARACTER SET utf8 COLLATE utf8_bin;

-- now, re-check for the bug
SELECT * FROM test WHERE `value` = 'value';

--
-- Note that we get just one key now, as you'd expect.
--
-- This problem appears to be specific to utf8. Next, I'll try to 
-- do the same with the 'latin1' charset:
--

-- first, reset the client connection charset/collate type
charset latin1 collate latin1_general_ci

-- next, convert the values that we've previously inserted
-- in the table
ALTER TABLE `test` CONVERT TO CHARACTER SET latin1 COLLATE latin1_general_ci;

-- now, re-check for the bug
SELECT * FROM test WHERE `value` = 'value';

--
-- Again, only one key is returned (expected). This shows 
-- that the problem with utf8/utf8_generic_ci isn't present 
-- in latin1/latin1_general_ci
--
-- To complete the example, I'll check with the binary collate
-- of latin1 as well:

-- first, reset the client connection charset/collate type
charset latin1 collate latin1_bin

-- next, convert the values that we've previously inserted in the table
ALTER TABLE `test` CONVERT TO CHARACTER SET latin1 COLLATE latin1_bin;

-- now, re-check for the bug
SELECT * FROM test WHERE `value` = 'value';

--
-- Again, only one key is returned (expected).
--
-- Finally, I'll re-introduce the problem in the exact same 
-- way (for any sceptics out there):

-- first, reset the client connection charset/collate type
charset utf8 collate utf8_generic_ci

-- next, convert the values that we've previously inserted in the table
ALTER TABLE `test` CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;

-- now, re-check for the problem/bug
SELECT * FROM test WHERE `value` = 'value';

--
-- Two keys.
--

DROP DATABASE sandbox;

È meglio usare il set di caratteri utf8mb4con le regole di confronto utf8mb4_unicode_ci.

Il set di caratteri utf8supporta solo una piccola quantità di punti di codice UTF-8, circa il 6% dei possibili caratteri. utf8supporta solo il piano multilingue di base (BMP). Ci sono altri 16 aerei. Ogni piano contiene 65.536 caratteri. utf8mb4supporta tutti e 17 gli aerei.

MySQL tronca i caratteri UTF-8 a 4 byte con conseguente danneggiamento dei dati.

Il utf8mb4set di caratteri è stato introdotto in MySQL 5.5.3 il 24-03-2010.

Alcune delle modifiche necessarie per utilizzare il nuovo set di caratteri non sono banali:

• Potrebbe essere necessario apportare modifiche nell'adattatore del database dell'applicazione.
• Sarà necessario apportare modifiche a my.cnf, tra cui l'impostazione del set di caratteri, le regole di confronto e il passaggio innodb_file_format su Barracuda
• Le istruzioni SQL CREATE potrebbero dover includere: ROW_FORMAT=DYNAMIC
  • DYNAMIC è richiesto per gli indici su VARCHAR (192) e superiori.

NOTA: il passaggio a Barracudada Antelope, potrebbe richiedere il riavvio del servizio MySQL più di una volta. innodb_file_format_maxnon cambia fino a dopo il servizio MySQL è stato riavviato a: innodb_file_format = barracuda.

MySQL utilizza il vecchio Antelopeformato di file InnoDB. Barracudasupporta formati di riga dinamici, che saranno necessari se non si desidera colpire gli errori SQL per la creazione di indici e chiavi dopo il passaggio al set di caratteri:utf8mb4

• # 1709 - Dimensione della colonna dell'indice troppo grande. La dimensione massima della colonna è 767 byte.
• # 1071 - La chiave specificata era troppo lunga; la lunghezza massima della chiave è 767 byte

Il seguente scenario è stato testato su MySQL 5.6.17: Per impostazione predefinita, MySQL è configurato in questo modo:

SHOW VARIABLES;

innodb_large_prefix = OFF
innodb_file_format = Antelope

Arresta il tuo servizio MySQL e aggiungi le opzioni al tuo my.cnf esistente:

[client]
default-character-set= utf8mb4

[mysqld]
explicit_defaults_for_timestamp = true
innodb_large_prefix = true
innodb_file_format = barracuda
innodb_file_format_max = barracuda
innodb_file_per_table = true

# Character collation
character_set_server=utf8mb4
collation_server=utf8mb4_unicode_ci

Esempio di istruzione SQL CREATE:

CREATE TABLE Contacts (
 id INT AUTO_INCREMENT NOT NULL,
 ownerId INT DEFAULT NULL,
 created timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
 modified timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
 contact VARCHAR(640) NOT NULL,
 prefix VARCHAR(128) NOT NULL,
 first VARCHAR(128) NOT NULL,
 middle VARCHAR(128) NOT NULL,
 last VARCHAR(128) NOT NULL,
 suffix VARCHAR(128) NOT NULL,
 notes MEDIUMTEXT NOT NULL,
 INDEX IDX_CA367725E05EFD25 (ownerId),
 INDEX created (created),
 INDEX modified_idx (modified),
 INDEX contact_idx (contact),
 PRIMARY KEY(id)
) DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci ENGINE = InnoDB ROW_FORMAT=DYNAMIC;

• È possibile visualizzare l'errore # 1709 generato per INDEX contact_idx (contact)se ROW_FORMAT=DYNAMICviene rimosso dall'istruzione CREATE.

NOTA: la modifica dell'indice per limitare i primi 128 caratteri su contactelimina la necessità di utilizzare Barracuda conROW_FORMAT=DYNAMIC

INDEX contact_idx (contact(128)),

Nota anche: quando dice che la dimensione del campo è VARCHAR(128), non è di 128 byte. È possibile utilizzare 128 caratteri a 4 byte o 128 caratteri a 1 byte.

Questa INSERTaffermazione dovrebbe contenere il carattere 'cacca' a 4 byte nella riga 2:

INSERT INTO `Contacts` (`id`, `ownerId`, `created`, `modified`, `contact`, `prefix`, `first`, `middle`, `last`, `suffix`, `notes`) VALUES
(1, NULL, '0000-00-00 00:00:00', '2014-08-25 03:00:36', '1234567890', '12345678901234567890', '1234567890123456789012345678901234567890', '1234567890123456789012345678901234567890', '12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678', '', ''),
(2, NULL, '0000-00-00 00:00:00', '2014-08-25 03:05:57', 'poo', '12345678901234567890', '💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩', '💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩', '💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩', '', ''),
(3, NULL, '0000-00-00 00:00:00', '2014-08-25 03:05:57', 'poo', '12345678901234567890', '💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩', '💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩', '123💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩', '', '');

Puoi vedere la quantità di spazio utilizzata dalla lastcolonna:

mysql> SELECT BIT_LENGTH(`last`), CHAR_LENGTH(`last`) FROM `Contacts`;
+--------------------+---------------------+
| BIT_LENGTH(`last`) | CHAR_LENGTH(`last`) |
+--------------------+---------------------+
|               1024 |                 128 | -- All characters are ASCII
|               4096 |                 128 | -- All characters are 4 bytes
|               4024 |                 128 | -- 3 characters are ASCII, 125 are 4 bytes
+--------------------+---------------------+

Nell'adattatore del database, potresti voler impostare il set di caratteri e le regole di confronto per la tua connessione:

SET NAMES 'utf8mb4' COLLATE 'utf8mb4_unicode_ci'

In PHP, questo sarebbe impostato per: \PDO::MYSQL_ATTR_INIT_COMMAND

Riferimenti:

• Mysql 5.6 Manuale di riferimento: limiti sulle tabelle InnoDB
• Come supportare Unicode completo nei database MySQL

Le regole di confronto influiscono sul modo in cui i dati vengono ordinati e su come le stringhe vengono confrontate tra loro. Ciò significa che dovresti utilizzare le regole di confronto che la maggior parte dei tuoi utenti si aspetta.

Esempio dalla documentazione per Unicode charset :

utf8_general_ciinoltre è soddisfacente sia per il tedesco che per il francese, tranne per il fatto che "ß" è uguale a "s" e non a "ss". Se questo è accettabile per la tua applicazione, dovresti usarlo utf8_general_ciperché è più veloce. Altrimenti, usa utf8_unicode_ciperché è più preciso.

Quindi - dipende dalla base di utenti prevista e da quanto è necessario l' ordinamento corretto . Per una base di utenti inglese, utf8_general_cidovrebbe essere sufficiente, per altre lingue, come lo svedese, sono state create regole di confronto speciali.

In sostanza, dipende da come pensi a una stringa.

Uso sempre utf8_bin a causa del problema evidenziato da Guus. A mio avviso, per quanto riguarda il database, una stringa è ancora solo una stringa. Una stringa è un numero di caratteri UTF-8. Un personaggio ha una rappresentazione binaria, quindi perché deve conoscere la lingua che stai usando? Di solito, le persone costruiranno database per sistemi con lo scopo di siti multilingue. Questo è il punto centrale dell'uso di UTF-8 come set di caratteri. Sono un po 'purista, ma penso che il rischio risulti pesantemente superiore al leggero vantaggio che potresti ottenere sull'indicizzazione. Qualsiasi regola relativa alla lingua dovrebbe essere eseguita a un livello molto più elevato rispetto al DBMS.

Nei miei libri il "valore" non dovrebbe mai essere uguale a "valúe" in un milione di anni.

Se voglio memorizzare un campo di testo e fare una ricerca senza distinzione tra maiuscole e minuscole, userò le funzioni di stringa MYSQL con funzioni PHP come LOWER () e la funzione php strtolower ().

Per informazioni testuali UTF-8, dovresti usare utf8_general_ciperché ...

• utf8_bin: confronta le stringhe in base al valore binario di ciascun carattere nella stringa

• utf8_general_ci: confronta le stringhe usando le regole del linguaggio generale e usando confronti senza distinzione tra maiuscole e minuscole

aka dovrebbe rendere la ricerca e l'indicizzazione dei dati più veloce / più efficiente / più utile.

La risposta accettata suggerisce in modo abbastanza definitivo l'uso di utf8_unicode_ci, e mentre per i nuovi progetti è grandioso, volevo mettere in relazione la mia recente esperienza contraria nel caso in cui qualcuno risparmiasse del tempo.

Poiché utf8_general_ci è il confronto predefinito per Unicode in MySQL, se si desidera utilizzare utf8_unicode_ci, si finisce per doverlo specificare in molti punti.

Ad esempio, tutte le connessioni client non hanno solo un set di caratteri predefinito (per me ha senso), ma anche un confronto predefinito (ovvero il confronto verrà sempre impostato come predefinito su utf8_general_ci per Unicode).

Probabilmente, se usi utf8_unicode_ci per i tuoi campi, i tuoi script che si collegano al database dovranno essere aggiornati per menzionare esplicitamente le regole di confronto desiderate, altrimenti le query che utilizzano stringhe di testo potrebbero non riuscire quando la tua connessione utilizza le regole di confronto predefinite.

Il risultato è che quando si converte un sistema esistente di qualsiasi dimensione in Unicode / utf8, si potrebbe finire per essere costretti a usare utf8_general_ci a causa del modo in cui MySQL gestisce le impostazioni predefinite.

Per il caso evidenziato da Guus, suggerirei vivamente di utilizzare utf8_unicode_cs (distinzione tra maiuscole e minuscole, corrispondenza rigorosa, ordinamento corretto per la maggior parte) invece di utf8_bin (corrispondenza rigorosa, ordinamento errato).

Se si desidera che il campo venga cercato, anziché corrispondere a un utente, utilizzare utf8_general_ci o utf8_unicode_ci. Entrambi non fanno distinzione tra maiuscole e minuscole, una corrisponderà in modo errato ("ß" è uguale a "s" e non a "ss"). Esistono anche versioni specifiche della lingua, come utf8_german_ci, in cui la corrispondenza persa è più adatta alla lingua specificata.

[Modifica - circa 6 anni dopo]

Non consiglio più il set di caratteri "utf8" su MySQL e invece il set di caratteri "utf8mb4". Corrispondono quasi interamente, ma consentono un po '(molti) più caratteri unicode.

Realisticamente, MySQL avrebbe dovuto aggiornare il set di caratteri "utf8" e le rispettive regole di confronto in modo che corrispondessero alla specifica "utf8", ma invece, un set di caratteri separato e rispettive regole di confronto per non influire sulla designazione di archiviazione per coloro che già utilizzano il set di caratteri "utf8" incompleto .

Ho trovato utili queste tabelle di confronto. http://collation-charts.org/mysql60/ . Non sono sicuro di quale sia l'utf8_general_ci usato però.

Ad esempio, ecco il grafico per utf8_swedish_ci. Mostra quali caratteri interpreta come gli stessi. http://collation-charts.org/mysql60/mysql604.utf8_swedish_ci.html

Nel file di caricamento del database, aggiungi la seguente riga prima di qualsiasi riga:

SET NAMES utf8;

E il tuo problema dovrebbe essere risolto.