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


731

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.


35
Nota a margine: "utf8" di MySQL non è corretto UTF-8 (nessun supporto per i caratteri Unicode a 4+ byte come 𝌆), tuttavia lo è "utf8mb4". Con utf8, un campo verrà troncato su insert a partire dal primo carattere Unicode non supportato. mathiasbynens.be/notes/mysql-utf8mb4
basic6

6
Mi chiedo se avremo mai bisogno di 5 byte per tutti quegli emoji ... sigh
Álvaro González

1
Domanda correlata: stackoverflow.com/questions/38228335/… "Quale confronto MySQL corrisponde esattamente al confronto delle stringhe di PHP?"
William Entriken,

Per una panoramica delle opzioni sane: monolune.com/mysql-utf8-charsets-and-collations-explained
Flux

Risposte:


618

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


4
piccoli miglioramenti delle prestazioni? Sei sicuro di questo ? publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp?topic=/… Le regole di confronto scelte possono influire in modo significativo sulle prestazioni delle query nel database.
Adam Ramadhan,

62
Questo è per DB2 non MySQL. Inoltre, non ci sono numeri o benchmark concreti, quindi lo stai basando sull'opinione dello scrittore.
Eran Galperin,

3
Si noti che se si desidera utilizzare le funzioni, esiste un bug in MySQL (la maggior parte delle versioni attualmente distribuite) in cui le funzioni restituiscono sempre la stringa utilizzando utf8_general_ci, causando problemi se si utilizza un'altra raccolta per le stringhe - vedere bugs.mysql.com/ bug.php? id = 24690
El Yobo

1
Dalla mia esperienza con diversi locali avrei sempre usatoutf8_unicode_*
Shiplu Mokaddim il

11
Aggiornamento: per le versioni più recenti, raccomandare utf8mb4e utf8mb4_unicode_520_ci. Questi ti danno il resto del cinese, oltre a una migliore raccolta.
Rick James

129

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.


1
Mi piace la tua spiegazione! Buona Ma ho bisogno di una migliore comprensione del perché l'ordinamento unicode è il modo migliore per ordinare correttamente che togliere gli accenti.
weia design,

14
@Adam Dipende molto dal tuo pubblico di destinazione. L'ordinamento è un problema difficile da localizzare correttamente. Ad esempio in norvegese le lettere Æ Ø Å sono le ultime 3 dell'alfabeto. Con utf8_general_ci, Ø e Å vengono convertiti in O e A, il che li mette nella posizione completamente sbagliata quando vengono ordinati (non sono sicuro di come Æ viene gestito, in quanto si tratta di una legatura, non di un carattere accentato). Questo ordinamento è diverso in quasi tutte le lingue, ad esempio norvegese e svedese hanno ordini diversi (e lettere leggermente diverse che sono considerate uguali): Æ Ø Å è ordinato Å Æ Ø (le lettere effettive sono Å Ä Ö). Unicode risolve questo problema.
Vegard Larsen,

Quindi quello che sto sostanzialmente dicendo è che dovresti probabilmente usare un ordinamento specifico per la lingua, se puoi, ma nella maggior parte dei casi è impossibile, quindi scegli l'ordinamento generale Unicode. Sarà ancora strano in qualche lingua, ma più corretto di ASCII.
Vegard Larsen,

3
@Manatax - con una qualsiasi delle regole di confronto utf8_, i dati vengono archiviati come utf8. Le regole di confronto riguardano solo quali personaggi sono considerati uguali e come vengono ordinati.
frymaster,

2
@frymaster - non è vero, come da: mathiasbynens.be/notes/mysql-utf8mb4 "utf8 di MySQL consente solo di memorizzare 5,88% di tutti i possibili punti di codice Unicode"
dati

120

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;

36
-1: questo è sicuramente risolto applicando una chiave univoca alla colonna pertinente. Vedresti lo stesso comportamento se i due valori fossero 'value'e 'valUe'. Il punto centrale di una collazione è che fornisce regole (tra le altre cose) quando due stringhe sono considerate uguali tra loro.
Hammerite,

13
Questo è esattamente il problema che sto cercando di illustrare: la collazione rende uguali due cose mentre in realtà non sono affatto pensate per essere uguali (e quindi, un vincolo unico è esattamente l'opposto di ciò che vorresti raggiungere)
Guus,

18
Ma lo descrivi come un "problema" e porta a "bug" quando il comportamento è esattamente quello che una collazione intende raggiungere. La descrizione è corretta, ma solo nella misura in cui è un errore da parte del DBA selezionare una raccolta inappropriata.
Hammerite,

32
Il fatto è che, quando inserisci due nomi utente che sono considerati uguali dalla collazione, non sarà consentito se imposti il ​​nome utente della colonna su unico, cosa che dovresti ovviamente fare!
Student of Hogwarts,

12
Ho votato sia questa risposta che il commento di @ Hammerite, perché entrambi mi hanno aiutato a raggiungere una comprensione delle regole di confronto.
Nacht - Ripristina Monica il

86

È 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:




6
utf8mb4_unicode_ci dovrebbe assolutamente essere la raccolta consigliata per i nuovi progetti nel 2015.
Trevor Gehman

7
Aggiorna ... utf8mb4_unicode_520_ciè meglio. In futuro, ci sarà utf8mb4_unicode_800_ci(o qualcosa del genere), poiché MySQL raggiungerà gli standard Unicode.
Rick James,

46

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.


1
stavo usando utf8_general_ci e ci sono voluti un paio di secondi mentre l'ordinamento e armscii_general_ci lo hanno fatto estremamente velocemente. Perché è successo? Ancora una domanda, cosa ne pensi quale fascicolazione viene utilizzata dai siti di social network

22

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 ().


9
Se il confronto binario di stringhe è il confronto desiderato, allora ovviamente dovresti usare il confronto binario; ma liquidare le regole di confronto alternative come "rischio di bug" o essere semplicemente per comodità dell'indicizzazione suggerisce che non si comprende appieno il punto di una raccolta.
Hammerite,

13

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.


12

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.


8

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 .


5
Cordiali saluti: utf8_unicode_csnon esiste. L'unica utf8 sensibile al maiuscolo / minuscolo è utf8_bin. Il problema è che l' utf8_binordinamento non è corretto. Vedi: stackoverflow.com/questions/15218077/…
Costa

1
Grazie per l'aggiornamento!
Prometeo


2

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

SET NAMES utf8;

E il tuo problema dovrebbe essere risolto.


2
Leggi una domanda: in passato ho impostato PHP per l'output in "UTF-8", ma quale confronto corrisponde in MySQL? Sto pensando che sia uno di quelli UTF-8, ma prima ho usato utf8_unicode_ci, utf8_general_ci e utf8_bin.
Jitesh Sojitra,

5
Questa risposta non ha nulla a che fare con la domanda. Inoltre, l'emissione SET NAMESdiretta di una query non consente al client di conoscere la codifica e può interrompere alcune funzioni come istruzioni preparate in modo molto sottile.
Álvaro González,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.