Kas kada nors bandė tvarkyti MySQL duomenų bazių koduočių problemas, tas žino, kad tai dažnai nėra paprastas reikalas. Savo koduotes turi duomenų bazės, lentelės ir net lentelių stulpeliai, ir šios koduotės gali būti skirtingos vienoje ir toje pačioje duomenų bazėje. O kadangi MySQL dar prieš gerą dešimtmetį duomenis standartiškai įrašydavo `Latin1` koduote, senesnėse žiniatinklio programose pasitaiko visokiausių kuriozų su koduotėmis. Štai ir aš neseniai gavau pataisyti vienos organizacijos naudojamą klientų registravimo duomenų bazę. Svetainėje, naudojančioje duomenų bazę, mačiau gražias lietuviškas raides, bet atsidaręs tą pačią duomenų bazę su PHPMyAdmin programa lietuviškas raides matydavau beviltiškai sugadintas. Tikra bėda, jei reikia kažką paskubom pataisyti tiesiog PHPMyAdmin duomenų bazės programoje... Aukščiau matėte paveikslėlį, kur kairėje – kaip duomenys atrodo svetainėje, dešinėje – PHPMyAdmin programoje. PHPMyAdmin sąsaja buvo nustatyta naudoti universaliąją `UTF8` koduotę. Svetainės programa – taip pat. Pasižiūrėjau į duomenų lentelę – ten irgi parašyta, kad naudojama `UTF8` koduotė!
CREATE TABLE `admins` (
  `id` int(11) NOT NULL,
  `name` varchar(400) NOT NULL,
  ## praleidžiam kitus stulpelius
  `var` int(2) NOT NULL
) ENGINE=MyISAM AUTO_INCREMENT=61 DEFAULT CHARSET=utf8;
Taigi, kame problema? Knisimasis PHPMyAdmin nustatymuose nepadėjo. Nepadėjo ir bandymas eksportuoti duomenų bazę į tekstinį failą ir bandymas jį peržiūrėti pritaikant vis naują koduotę. Taigi, duomenys jau į patį teksto failą pateko sugadinti. Paieškojus informacijos per Google nusprendžiau, kad matyt į duomenų bazės lentelę, kurios numatytoji koduotė yra `UTF8`, yra įterpiami `Latin1` koduotės duomenys. Taigi, jei PHPMyAdmin programoje duomenų bazės ir lentelių koduotė nustatyta į utf8, tačiau
SELECT * FROM `admins`; 
rodo iškraipytas lietuviškas raides, labai gali būti, kad tai – ir Jūsų duomenų bazės problema. Kad tuo įsitikintumėte, PHPMyAdmin įvykdykite tokią komandą:
SET NAMES latin1; SELECT * FROM `admins`;
Jei turinį staiga parodys teisingai, problema tikrai ta. Vienas iš būtų sutvarkyti duomenų bazę – pakeisti koduotę visuose duombazės lentelių stulpeliuose iš pradžių nurodant juose esančio teksto tikrąją koduotę (`Latin1`), tada konvertuojant stulpelius į dvejetainius duomenis, o vėliau iš dvejetainių – į `UTF8` koduotės stulpelius. Tai gan plačiai ir išsamiai aprašyta Wordpress dokumentacijoje, žr. čia. Ten siūloma rankiniu būdu surašyti ilgą sql scenarijų, konvertuojant visų teksto laukų koduotes į dvejetainį kodą tokiu būdu:
    CHAR ⇾ BINARY
    TEXT ⇾ BLOB
    TINYTEXT ⇾ TINYBLOB
    MEDIUMTEXT ⇾ MEDIUMBLOB
    LONGTEXT ⇾ LONGBLOB
    VARCHAR ⇾ VARBINARY
Atskira problema yra įvardinti ENUM tipo laukai. O aš pamėginau padaryti php scenarijų, kuris vienu ypu padarytų visus keitimus visoje duomenų bazėje. Su juo sutvarkiau ir organizacijos klientų registravimo sistemos duomenų bazę, ir taip pat šio tinklaraščio duomenų bazę. Kol kas nepastebėjau, kad kas nors būtų ne taip :) Wordpress tinklaraščio atveju užteko serveryje šį scenarijų įvykdyti ir įrašyti du papildomus parametrus į tinklaraščio konfigūracijos failą:
define( 'DB_CHARSET', 'utf8' );
define( 'DB_COLLATE', 'utf8_lithuanian_ci' );
Žemiau tą scenarijų pateikiu. Tačiau prieš naudojant primygtinai siūlau pasidaryti duomenų bazės kopiją. ir įvertinti, ar jūsų duomenų bazei scenarijus neturėtų būti išplėstas. Mano tvarkytoje duomenų bazėje nebuvo didelių teksto laukų (`LONGTEXT` ir `MEDIUMTEXT` tipo). Ir be to, pamėginau apsieiti be `VARCHAR` tipo laukų keitimo į `BINARY` tipo laukus (visi `TEXT`, `TINYTEXT`, `VARCHAR`, `CHAR` tipo laukai konvertuoti į `BLOB`). Atrodo, viskas praėjo sklandžiai, bet taip gali būti ne visais atvejais. Scenarijų pertvarkiau taip, kad jis teisingai pakeistų visų laukų tipus (*char – į atitinkamą \*binary tipą, \*text – į atitinkamą \*blob tipą. Beje, scenarijų duomenų bazei galima vykdyti TIK VIENĄ KARTĄ; antrą kartą jis sugadins duombazę, nes scenarijuje preziumuojama, kad pirminė stulpelių koduotė - `latin1`. Jei nuspręsite šiuo scenarijumi pasinaudoti, būkite labai atsargūs. Geriausiai jį išmėginkite ant savo tvarkomos duomenų bazės kopijos. Jei dirbsite su pagrindine duomenų baze, būtinai pasidarykite duomenų bazės kopiją ir būkite tikri, kad prireikus galėsite atkurti pirminius duomenis! Kaip minėta, scenarijus nesutvarkys ENUM tipo laukų. Tačiau jei tokių aptiks, juos visus išvardins, tad galėsite rankiniu būdu juos sutvarkyti, kaip tai siūloma Wordpress kodekse. Tikiuosi kam nors tai bus naudinga. Papildomos informacijos, kaip jau minėjau, ieškokite Wordpress kodekse.



  
  Duomenų bazės sutvarkymas
  



Connection failed: Access denied for user 'as_pats'@'localhost' (using password: YES)