Ei bine, aici. Codul rău latin1 nu este prezent și, într-o mențiune, este posibil să verificăm casa noastră de maternitate)))
Și aceasta este lovitura teribilă a rake-ului, care a durat atât de mult să atragă! Un cititor atent ar fi putut observa că atunci când a fost făcută o încercare de a schimba cu forța codificarea unei coloane conținând date în latin1, atunci pentru fiecare înregistrare care conținea litere ruse, MySQL avea o versiune diferită! A fost un strigăt că serverul nu știe cum să traducă datele de la latin1 la cp1251, bine, mai bine decât înlocuirea caracterelor non-latin1 cu semne de întrebare, nu a găsit :))). Roddom a pierdut iremediabil, deoarece acum în loc de chirilic în baza de date conține întrebări.
Întrebările ar putea fi evitate
De fapt, situația, când codificarea greșită este inițial stabilită, se întâlnește foarte des. Simptomele pot fi identificate după cum urmează:
Aceste variabile sunt responsabile de valorile implicite ale codificărilor.
- character_set_client - codificarea în care datele vor proveni de la client
- character_set_connection - codificarea implicită pentru tot ce nu este codificat în cadrul conexiunii
- character_set_database - codificarea implicită pentru baze de date
- character_set_filesystem - codificare pentru lucrul cu sistemul de fișiere (LOAD DATA INFILE, SELECT.INTO OUTFILE etc.)
- character_set_results - codificarea în care va fi selectat rezultatul
- character_set_server - codificarea în care rulează serverul
- character_set_system - codificarea în care sunt specificate identificatorii MySQL, întotdeauna UTF8
- character_sets_dir - dosar cu codificări
IMPORTANT: Dacă character_sets_dir nu este instalat corect, atunci lucrul cu codificările va fi în pericol. Nu încercați să-i schimbați semnificația dacă nu sunteți sigur de dumneavoastră. Dacă sunteți administrator de sistem, trebuie să vă familiarizați cu manualul înainte de a instala.
Cele mai importante pentru utilizatorii obișnuiți sunt următoarele variabile: character_set_client, result_set_set, character_set_connection. Deoarece sunt responsabili pentru intrarea, preluarea informațiilor și crearea de tabele / baze de date, respectiv. Cum pot fi ei?
Oricare dintre aceste codificări pot fi folosite la gustul dumneavoastră. De obicei, utilizatorii de limbă rusă preferă cp1251 sau utf8, însă, de fapt, nu contează care codificare a datelor este stocată, este important să fie specificată inițial corect și datele să fie introduse corect.
Setarea setului de caractere
Manualul ne oferă trei opțiuni pentru specificarea codificărilor:
ATENȚIE. Primele două opțiuni funcționează numai în conexiunea curentă. Aceasta înseamnă că data viitoare când vă conectați, toate setările vor reveni la starea inițială! Pentru a nu expune codificarea de fiecare dată, trebuie să utilizați a treia opțiune.
Opțiunea 1 - prin numele
Dar este mai bine atunci când codificarea este configurată chiar în conexiune.
Ce trebuie să faceți dacă datele sunt introduse în codificare greșită
Dacă baza de date / tabel / date a fost creată / introdusă într-o codare diferită de cea de care aveți nevoie, trebuie să faceți următoarele:
Această opțiune este potrivită pentru aproape toate cazurile, cu excepția unor situații speciale, de exemplu, când comparația implicită nu este adecvată pentru anumite câmpuri. Un exemplu este câmpul pentru stocarea parolei, este necesar să o comparați cu cazul, în timp ce implicit, comparația este insensibilă la litere mari.
Modul corect de a lucra cu MySQL
Astfel, clientul lucrează în KOI8-R, dar datele sunt stocate în cp1251, MySQL știe despre asta și face conversia în zbor.
Ei bine, pe stick:
Puteți selecta date în orice codificare, așa cum faceți, principalul lucru este să raportați corect acest lucru MySQL.
Articole similare
Trimiteți-le prietenilor: