mysql maiuscole / minuscole in utf8_general_ci

Ho un database mysql in cui io uso utf8_general_ci (che è tra maiuscole e minuscole), e nella mia tabella ho alcune colonne come ID con dati sensibili (per esempio: ‘iSZ6fX’ o ‘AscSc2’)

Distinte lettere maiuscole da minuscole è meglio impostare su queste colonne, solo il utf8_bin, come questo:

CREATE TABLE  `test` (
`id` VARCHAR( 32 ) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL ,
`value1` VARCHAR( 255 ) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL
) ENGINE = MYISAM CHARACTER SET utf8 COLLATE utf8_general_ci

O utilizzare utf8_general_ci su tutte le colonne e l’uso ‘BINARIO’ in php query, per esempio:

mysqli_query( $link, "SELECT * FROM table WHERE BINARY id = 'iSZ6fX'" );
  • È il caso di dati sensibili o quella singola query case sensitive? Per esempio, fai di solito tra maiuscole e minuscole query fatta eccezione per quello? Che dovrebbero guidare vostra risposta!
InformationsquelleAutor ipel | 2013-09-11



3 Replies
  1. 15

    È meglio usare il utf8_bin di confronto, perché anche se non è possibile in UTF-8, nel caso generale è teoricamente possibile (come accade con la codifica UTF-16) per la stesso stringa di essere rappresentati da diversi codifiche, che un confronto binario non capire, ma un confronto binario sarebbe. Come documentato in I Set Di Caratteri Unicode:

    C’è una differenza tra “ordine dal carattere del codice di valore” e di “ordinare il carattere della rappresentazione binaria,” una differenza che appare solo con utf16_bin, a causa di surrogati.

    Supponiamo che utf16_bin (al confronto binario per utf16) è stato un confronto binario “byte”, piuttosto che “di carattere per carattere.” Se fosse così, l’ordine dei caratteri in utf16_bin sarebbero diversi dall’ordine di utf8_bin. Per esempio, il grafico seguente mostra due caratteri rari. Il primo carattere è nel range E000-FFFF, quindi è maggiore di un surrogato, ma meno di un supplementare. Il secondo personaggio è un complementare.

    Codice punto di Caratteri utf8 utf16 
    ---------- --------- ---- ----- 
    0FF9D HALFWIDTH KATAKANA LETTERA N EF ESSERE 9D 9D FF 
    10384 UGARITICO LETTERA DELTA F0 90 8E 84 D8 00 DF 84 
    

    I due personaggi nel grafico sono, nell’ordine, il codice del punto di valore, perché 0xff9d < 0x10384. E sono, nell’ordine, utf8 valore perché 0xef < 0xf0. Ma essi non sono in ordine da utf16 valore, se usiamo byte-per-byte confronto, perché 0xff > 0xd8.

    Così MySQL utf16_bin confronto non è “un byte alla volta.” È “dal punto di codice.” Quando MySQL vede un complementare-codifica dei caratteri in utf16, converte il carattere di codice del punto di valore, e poi confronta. Pertanto, utf8_bin e utf16_bin sono lo stesso ordinamento. Questo è coerente con l’SQL:2008 requisito standard per un ordinamento UCS_BASIC: “UCS_BASIC è un confronto in cui l’ordine è interamente determinato dal scalare Unicode valori dei caratteri nelle stringhe ordinate. È applicabile per l’UCS repertorio di caratteri. Dal momento che ogni personaggio repertorio è un sottoinsieme dell’UCS repertorio, l’ordinamento UCS_BASIC è potenzialmente applicabile a tutti i set di caratteri. NOTA 11: Unicode valore scalare di un personaggio è il suo punto di codice trattata come un intero senza segno.”

    Quindi, se confronti con queste colonne sempre essere case-sensitive, si dovrebbe impostare la colonna di confronto per utf8_bin (in modo che rimangano maiuscole e minuscole anche se si dimentica di specificare altrimenti nella query); o se solo query particolare sono case-sensitive, si potrebbe specificare che il utf8_bin confronto deve essere utilizzato con il COLLATE parole chiave:

    SELECT * FROM table WHERE id = 'iSZ6fX' COLLATE utf8_bin
    • quindi se ho sempre bisogno di caso di dati sensibili è meglio impostare utf8_bin solo in questa colonna, e lasciare utf8_general_ci in tutte le altre colonne, e nella tabella di database e utf8_general_ci. Altrimenti se solo un paio di query sono case-sensitive semplicemente aggiungere COLLATE utf8_bin nella query, anche se il confronto di colonna è utf8_general_ci. è corretto?
    • Sì, è corretto.
  2. 1

    È meglio utilizzare le colonne con ‘utf8_bin’, piuttosto che specificare la condizione nella query, perché riduce la probabilità di errori.

    • Può fare un esempio di un errore che potrebbe verificarsi?
  3. 0

    L’effetto di BINARIO come un attributo della colonna differisce dal suo effetto prima di MySQL 4.1. Precedentemente, BINARI ha provocato una colonna che è stata trattata come una stringa binaria. Una stringa binaria è una stringa di byte che non ha il set di caratteri o di confronto, che differisce da un non binari stringa di caratteri che è un confronto binario.

    Ma Ora

    L’operatore BINARIO getta la stringa che segue è una stringa binaria. Questo è un modo semplice per forzare un confronto fatto un byte alla volta, piuttosto che di carattere per carattere. BINARIO causa anche gli spazi per essere significativo.
    BINARIO str è una scorciatoia per il CAST(str BINARIO).

    BINARIO attributo di carattere definizioni di colonna ha un effetto diverso. Una colonna di caratteri definito con il BINARIO attributo viene assegnato al confronto binario della colonna del set di caratteri. Ogni set di caratteri è un confronto binario. Per esempio, il confronto binario per il character set latin1 è latin1_bin, quindi se la tabella di default character set latin1, queste due colonne definizioni sono equivalenti:

    CHAR(10) BINARY
    
    CHAR(10) CHARACTER SET latin1 COLLATE latin1_bin

Lascia un commento