Codificări în limba rusă
În mod tradițional, în Rusia au fost folosite patru codificări pentru a reprezenta personaje rusești:
Aceste patru codificări au atât caracteristici comune, cât și diferențe. În primul rând, toți folosesc un octet de informații pentru a stoca un caracter. În al doilea rând, acestea sunt compatibile cu codificarea latin1, adică au aceleași 128 octeți din tabela de codificare. Valorile simbolurilor cu setul superior de biți (adică cu valorile 128-255) diferă.
Chiar și patru coduri de caractere pentru o limbă sunt foarte multe. Inițial, oamenii nu au acordat nici o importanță acestui lucru, dar în ultimii ani nu a devenit așa. Au existat diverse probleme legate de programele de portabilitate, iar oamenii au decis să creeze codificări generale care conțin simbolurile tuturor limbilor lumii (inclusiv, desigur, rusă).
Deci, codificarea Unicode (UCS-2) a fost creată. Desigur, este imposibil să plasați un număr foarte mare de caractere în 8 biți, astfel încât această codificare utilizează 2 octeți (adică 16 biți) pentru fiecare caracter. Liniile din această codare, desigur, ocupă mai mult spațiu decât vechile codificări, dar aplicațiile care folosesc astfel de șiruri sunt foarte ușor transferate în alte limbi.
În ciuda introducerii UCS-2, rămân unele probleme. În primul rând, aceasta este creșterea specificată a lungimii șirului. Persoanele care folosesc numai caractere latine nu au putut înțelege de la sine motivele pentru care ar trebui să folosească 16 biți pentru a desemna caracterele care se potrivesc în 7 biți. În al doilea rând, 65.536 de caractere nu sunt încă suficiente pentru a indica toate simbolurile folosite pe planetă.
Pentru a depăși aceste dificultăți, a fost creată o codificare cu lungime variabilă a caracterului UTF-8. În această codificare, se utilizează 1 octet pentru a marca primele 128 de caractere (adică caracterele incluse în latin1). Dacă bitul superior al primului octet este setat, se folosește al doilea octet (adică literele ruse din această codare ocupă 2 octeți). Dacă bitul superior al celui de-al doilea byte este setat, se folosește al treilea octet (și include o varietate de hieroglife și alte simboluri orientale) și așa mai departe.
Această codare, în primul rând, poate găzdui un număr arbitrar de caractere (deoarece vă permite să creșteți dinamic numărul de octeți). În al doilea rând, în cazul limbii engleze, se utilizează un octet și acest lucru este foarte frumos pentru țările vorbitoare de limba engleză. Țările est-europene nu-i plac foarte mult această codificare, pentru că ei trebuie să folosească 3 octeți pentru a indica propriile caractere (în UCS-2 folosesc doar două).
Mapări de caractere
Unele aplicații (inclusiv MySQL, care vor fi discutate mai jos) utilizează nu numai codificarea caracterelor, ci și caracterele de caractere. Faptul este că unele simboluri consideră că anumite simboluri sunt aceleași (și uneori simbolul sau o serie de simboluri se presupune a fi aceleași). De exemplu, "ü" în limba germană poate fi scrisă ca "ue". Pe de altă parte, în limba suedeză, același simbol poate fi scris ca "uy".
În limba rusă, de exemplu, puteți lua în considerare aceleași litere "e" și "e" (așa cum se întâmplă adesea în documentele oficiale). De asemenea, este adesea util să nu se facă distincția între literele mari și cele mici (care au cod diferit în orice codare).
Cartografia afectează exact modul în care aplicația funcționează cu o colecție de caractere, afectează ordinea de sortare și compararea simbolurilor. Desigur, maparea depinde de codificarea caracterelor.
Codificarea caracterelor în MySQL
În serverul MySQL, fiecare linie are propria codificare și potrivire. Când creați o masă, puteți specifica codificarea și maparea în care vor fi salvate rândurile din tabel. Puteți specifica chiar acești parametri pentru fiecare câmp din tabel. De exemplu:
CREATE TABLE enctest (
str1 CHAR (10) CHARSET koi8r,
str2 CHAR (15) COLLATE utf8_general_ci
);
În acest exemplu, se creează un tabel cu două câmpuri, dintre care unul va fi stocat în codarea KOI8-R (și cu maparea implicită). Cel de-al doilea câmp va avea o utf8_general_ci și o codificare UTF-8 (codificarea este determinată de potrivire, deoarece cartografiere depinde de aceasta).
Lista de codare și comparații disponibile poate fi obținută, respectiv, de comenzi
ARĂTAȚI CHARACTER SET;
SHOW COLLATION;
Codificarea implicită și modificarea codării șirului în MySQL
Dacă nu doriți să specificați în mod explicit codificarea caracterelor rândurilor din tabel, puteți specifica codificarea implicită a caracterelor pentru acest tabel:
CREATE TABLE enctest2 (
str1 CHAR (10),
str2 CHAR (15)
) CARACTERISTICI DEFALCATE cp1251;
În acest caz, ambele linii vor fi create în codificarea CP1251. Puteți specifica codificarea liniilor individuale și dacă specificați codificarea implicită.
De asemenea, puteți modifica codificarea caracterelor pentru un câmp de tabel specific:
ALTER TABLE enctest2 Modificați str1 CHAR (10) CHARSET utf8;
În acest caz, în câmpul str1, modificările de codificare și toate liniile sunt recodificate. Rețineți că, dacă modificați codificarea implicită pentru o tabelă, atunci rândurile din ea nu sunt recodificate, doar afectează crearea altor câmpuri din acest tabel.
Mapări în MySQL
În MySQL, pentru fiecare codificare, există cel puțin o mapare (și de obicei mai multe). Pentru a înțelege ceea ce sunt diferite, toate au nume foarte detaliate.
Numele fiecărei cartografiere începe cu numele codificării corespunzătoare (de exemplu, utf8_). Următoarea este o comparație a caietului de sarcini (de multe ori, o comparație simplă este, general, nu litere de identificare) și o indicație a sensibilității (cs - caz sensibile - sensibil, CI - caz insensibil - nu sensibil la majuscule).
Separat este necesar să se noteze comparații binare (binare). Dacă rândurile sunt potrivite într-un mod binar, nu se fac nicio mapări sau conversii între ele. Astfel de șiruri nu vor fi convertite prin comanda SET NAMES (vezi mai jos). comparație binară este utilă în special atunci când se trece de la MySQL 3.23, care nu este acceptată de codificare și care indică faptul că toate tabelele sunt codificate latin1 (în ciuda faptului că tabelul poate cuprinde date, de exemplu, în KOI8-R).
Codificarea clientului MySQL
Serverul MySQL schimbă automat codarea șirului la introducerea datelor într-un tabel și la preluarea datelor dintr-un tabel. În acest scop, utilizează date din variabile de sistem, cum ar fi character_set_client. O listă a tuturor variabilelor care afectează codificările poate fi obținută prin rularea comenzii
EVIDENȚI VARIABILE SIMILARE "char%";
Puteți specifica variabilele singure sau le puteți modifica imediat cu un set mare (după cum este necesar în majoritatea cazurilor):
SET NAMES koi8r;
După ce serverul primește o astfel de comandă, se va aștepta să îi transferați toate liniile din codarea KOI8-R și va traduce automat liniile de ieșire la această codificare.
Acest lucru este convenabil atunci când serverul nu funcționează implicit în codificarea pe care o așteptați (de exemplu, în KOI8-R și doriți să afișați informații pe site-ul CP1251).
Stocarea de informații în MySQL
MySQL stochează informații în funcție de ce codificare ați specificat. Deoarece serverul alocă 1 octet pentru fiecare caracter pentru seturi de caractere pe un singur octet (CHAR (10) întotdeauna ia 10 octeți, un VARCHAR (10) durează de la 1 la 11 octeți în funcție de lungimea șirului, 1 octet suplimentar este cheltuit pentru stocarea lungimii șir).
Pentru codarea UCS-2, serverul alocă 2 octeți pentru fiecare caracter. Pentru codificarea UTF-8, serverul alocă un număr diferit de octeți pentru diferitele simboluri (în conformitate cu codificarea) în cazul VARCHAR și 3 octeți pentru fiecare simbol în cazul CHAR. Astfel, în UTF 8-string CHAR (10) ocupă întotdeauna 30 octeți și VARCHAR (10) - la 1 la 31 bayta.Pri aceasta, în orice caz, atunci când se utilizează UTF-8, serverul nu poate stoca lungimea codului de 4 octeți ( totuși, acest lucru nu impune restricții speciale).