Deci, totul a început cu faptul că ați instalat MySQL, crea un tabel, le-au umplut cu date, și apoi a constatat că cererile în tabelele în care există o căutare sau sortează după câmpuri de tip CHAR, VARCHAR, TEXT da rezultate imprevizibile. Dacă se întâmplă acest lucru, este posibil să specificați incorect codificarea pentru date. Încerc să explice ce problema este. Sper că înțelegi ce tip de codificare. Dacă nu, întrebarea progugilite și să obțină cel puțin cunoștințe primare.
Deci Să vedem cum sa dovedit că aveți o problemă cu codificarea. MySQL cu codificarea implicită pentru baza de date indică Latin1. Cei mai mulți clienți, atunci când este conectat, setat la Latin1 codificare. Sunteți folosind clienți pentru a introduce date, vizualizarea rezultatelor etc. În acest caz, folosind codarea Latin1 peste tot. Această codificare vă permite să afișați corect alfabetul chirilic. La această corectitudine în relațiile cu chirilice care codifică capetele Latin1. Simbolul vedeți dreapta, dar codurile din tabelul de simboluri în codificarea nu corespunde cu caractere chirilice reale. Și se pare că de căutare și sortare a da rezultate imprevizibile, deoarece lucrarea nu are loc cu caracterele pe care le vedeți, și coduri. Poate confuz explicat apoi pus în fața faptului: a Latin1 codificare - este incorect de codificare pentru a finaliza lucrările cu krillitsey. Pentru a funcționa corect, trebuie să selectați codificările chirilice care acceptă chirilic. Pentru a cunoaște lista completă a acestor codificări RTFM pentru MySQL. Mă voi concentra pe două cele comune: utf-8 și cp1251. Voi începe cu cp1251. deoarece este codificarea nativ pentru sistemul de operare Windows.
Deci, provocarea noastră: pentru a converti datele din inițial afirmat în mod eronat în codificarea corectă de codificare Latin1 cp1251. Mergem la documentația pentru limba:
Dacă doriți să modificați setul de caractere implicit de masă și toate coloanele de caractere (CHAR, VARCHAR, TEXT) la un nou set de caractere, utilizați o declarație de genul:
ALTER TABLEtbl_nameCONVERT LA SETcharset_name CARACTER; (1)
Nu în grabă pentru a efectua soluția propusă, și citește mai departe:
Avertizare. Operația precedentă convertește valorile coloanelor între seturile de caractere. Acest lucru nu este ceea ce doriți, dacă aveți o coloană într-un singur set de caractere (cum ar fi Latin1), dar valorile stocate folosesc de fapt, un anumit set de alt, caracter incompatibil (cum ar fi cp1251). În acest caz, trebuie să faceți următoarele pentru fiecare astfel de coloană:
ALTER TABLEt1CHANGEc1 c1BLOB; (2)
SETcp1251 CHARACTER ALTER TABLEt1CHANGEc1 c1TEXT; (3)
Motivul acestei lucrări este că nu există nici o conversie atunci când convertiți la sau de la coloanele BLOB.
conversie simplă a datelor (1) nu ne convine, pentru că avem coduri incorecte pentru caractere, precum și are loc conversia conform tabelului de cod, atunci vom obține un rezultat incorect. Ieșirea din această situație - este de a scăpa de legare caracter codificării. Acest lucru se face prin conversia datelor de caractere, și tipul de date binare (2). Imaginați-vă că codificarea - este o mască, care este suprapus peste datele binare. Ie endianness în sine nu se schimba, ci doar modifică masca, care sunt selectate de coduri pentru formarea de simboluri vizuale. Astfel, cererea (2) te scapa de masca, și cererea (3) ați aplicat o nouă mască. Repet încă o dată (aproximativ vorbind): punct de vedere fizic, nu am schimbat un singur octet de date, vom schimba regulile de formare a caracterului! Ca rezultat, veți obține următoarele: datele reale în care acestea erau valabile pentru codificarea cp1251, astfel încât acestea au rămas, dar acum avem dreptul de a specifica cp1251 de codificare.
După aceste manipulări viața bazelor de date și probe ar trebui să fie ajustate, pentru că acum totul se potrivește împreună și toate în locurile lor. Acum, dacă doriți să modificați tabelele de codificare și câmpurile, puteți utiliza în siguranță cererea (1). Apropo, mă gândesc să se mute de la cp1251 la utf-8, dar acum nu mai pot în mod clar de voce, de ce am nevoie: unele au premise, ci o înțelegere clară a nu a fost încă.
- Dacă conversia de date a afirmat în mod eronat inițial în codificarea corectă de codificare Latin1 cp1251. Nu se poate schimba doar setul de caractere pentru coloana, și anume, nu îndeplini cererea (2), și imediat a efectua o cerere (3). Deoarece face cererea dreapta (3) nu vom reconstrui fizic masca, ci pur și simplu schimba valoarea curentă a măștii. Dacă nu aveți probleme cu inconsistența codificări, și ai nevoie doar pentru a schimba codificarea mesei, atunci trebuie doar să îndeplinească cererea (1).
- Dacă conversia de date a afirmat în mod eronat inițial în codificarea corectă de codificare Latin1 cp1251. În același timp, schimbați codificarea câmpului, care are un indice, apoi reconstrui indexul (eliminați și re-crea).
- Dacă decideți să mutați la codificare UTF-8 - Asigurați-vă că clienții vizuale sprijină unicode. De exemplu, așa cum mi-a plăcut foarte mult SQLyog 5.2 fumul de bambus la afișarea conținutului tabelelor care stochează datele în utf-8.
- MySQL a început sprijinirea unicode numai versiunea 4.1.x, și anume Unicode nu a fost până în acest sprijin. Acest lucru înseamnă că, dacă doriți un tabel cu o unicode.Versiunile perensti la versiunea 4.1.x mai tineri, atunci nu va reuși. Două ieșiri: sau de a converti datele din Unicode în ceva mai puțin exemplu multibyte, cp1251; sau pentru a actualiza baza de date la versiunea în conformitate cu 4.1.x. Actualizarea bazei de date, deoarece predpochitetlney MySQL a 3KA în opinia mea nu este acceptată și 4ka prea, va înceta în curând să fie menținute, cu a 5-SA este activ în curs de dezvoltare în două ramuri. Și toată lumea este în Unicode activă într-o fabrică de rețea.