Ir giga problēma :) Tika uzlikts MySQL 4.1, pirms tam kātīgi izlemjot, ka vecās tabulas ar jaunajām netiks džoinotas. Bet tagad izrādās, ka tas ir nepieciešams. Un rodas dziļš dibuā tipa caurums.
Ir divas tabulas:
CREATE TABLE `a` {
`id` int(11) auto_increment primary key,
`a` varchar(254)
} DEFAULT CHARACTER SET=latin1
CREATE TABLE `b` {
`id` int(11) auto_increment primary key,
`a_id` int(11), –– Relācija uz tabulas `a` ierakstu
`b` varchar(254)
} DEFAULT CHARACTER SET=utf8
Pie kam, tabulā a lauks a, neskatoties uz to, ka tam ir norādīts čaraktersets latin1 satur tekstu iekš cp1257. Tā ir vecā tabula.
Tabulā b viss ir bumbās — saturs tieši, kā norādīts, ir utf8.
Un tagad man nekādi neizdodas izveikt sekojošu operāciju:
SELECT
`a`, `b`
FROM
`a`, `b`
WHERE
`a.id` = `b.a_id`
Nēnu, selekts izdodas, protams. Man pilnībā pietiktu, ja viss smuki rādītos utf8 kodējumā. Taču, tā kā viens lauks ir utf8, bet otrs MySQL'prāt ir latin1, tad nu nekādi neizdodas korekti iestāstīt MySQL'am, ka tas nebūt nav latin1, bet gan cp1257.
Itin vai īzī risinājums — varētu nomainīt tabulas character set. Bet nevar. Jo veco tabulu izmanto vecās aplikācijas. Attiecīgi, mainot čaraktersetu, jamās palidos pa pieskari. Viena pēc otras. Pie kam, alter'ējot tabulu MySQL's daiļi sajās saturu :)
Ko darīt? Duplicēt tabulu ar korektu čārsetu — tas nav risinājums.
1 Atoms @ 14:39 (2004. gada 23. novembris)
a tev parastaa mysql vai mysqli ekstensija ?
ja mysqli tad tur vareeja smuki noraadiit kaadaa charsetaa veelaties datu charsetu outputaa… ja es pareizi saprotu ko vaiga….
2 laacz @ 14:42 (2004. gada 23. novembris)
Atoms: arī ar mysql parasto ekstensiju to var izdarīt. Bet nejau tur ir problēma :) Problēma ir iekš tā, ka es nezinu, kā piespiest MySQL saprast, ka tas, kas viņaprāt ir latin1, patiesībā ir cp1257 :)
3 bubu @ 15:09 (2004. gada 23. novembris)
Tiešām šis nelīdz: ALTER TABLE a MODIFY a varchar(254) cHARACTER SET utf8;
Un šis:
SELECT CONVERT(`a` USING cp1257), `b`
FROM `a`, `b`
WHERE `a.id` = `b.a_id`
4 laacz @ 15:16 (2004. gada 23. novembris)
bubu: 1. nelīdz, jo rada problēmas jau minētajās pārējās aplikācijās, kurās VISUR jālabo būs selekti :)
2. arī, jo no MySQL uzskata, ka `a` ir iekš `latin1` un attiecīgi arī konvertē no `latin` uz `cp1257`.
5 Shiazo @ 15:19 (2004. gada 23. novembris)
paurbinaaju degunu. laacz, programmatuuras arhitektuuras izstraades posms ir pirms realizeeshanas & implementeeshanas posma (resp. kodeeshanas) :D
da neko — gribeeju pavazat aiz deguna.
6 laacz @ 15:21 (2004. gada 23. novembris)
Shiazo: Pateikt godīgi? Es par šiem posmiem dzirdējis esmu. Un pieturos pie jamajiem dikti minimāli. Tā nu tas ir. :)
7 Neonz @ 15:34 (2004. gada 23. novembris)
A vaig tieši lai mysql ņemas ar tiem encodingiem? Nevar izmantot PHP iconv() pēc selekta?
8 laacz @ 15:37 (2004. gada 23. novembris)
Neonz, padomā, kas ir ātrāk? :) Native MySQL iebūvētās konversijas, vai iconv(). Plus, kā tad man būs operēt ar laukiem, meklēt tajos, u.t.t.?
9 anonīmi @ 16:00 (2004. gada 23. novembris)
Palīdzēt nemācēšu. Bet man ir jautājums. Vai tev php_mysqli extensions māk ņemties ar tabulām, kur ir UTF–8? Viņš man atgriež ķeburus. tāpēc joprojām esmu spiests lietot latin–8 un glabāt UTF–8!
10 Arturs @ 16:17 (2004. gada 23. novembris)
Ar MySQL nestrādāju, bet tas netraucē man piedāvāt risinājumus :). Uztaisam, tajā a tabulā vēl vienu kolonu — a2. Pēc tam uzlaižam pa virsu kaut vai PHP skriptu, kas sadzen vērtības no lauka a laukāa a2 nomainot encodingu. Pēc tam taisam selectus atsaucoties uz tabulas a lauku a2
11 Mr.Venom @ 16:33 (2004. gada 23. novembris)
vāja cerība uz pārkonvertēšanu "lidojumā":
WHERE `a.id` = _utf8`b.a_id`
12 Mr.Venom @ 16:34 (2004. gada 23. novembris)
vāja cerība uz pārkonvertēšanu "lidojumā":
WHERE _utf8`a.id` = `b.a_id`
13 Djuke @ 16:51 (2004. gada 23. novembris)
moš var kaukādā veidā izveidot "pareizu" tabulu ('aa') "pareizajā" kodējumā, pārdzīt uz to no tabulas 'a' datus un tad uztaisīt skatu 'a' kas pēc būtības ir identisks tabulai 'a', bet veidojas no 'aa', kuras nu tad jau vairs nebūs….
par mysql gan neko nezinu… līdz ar to varbūt smagi kļūdos
14 ZeaLot @ 17:03 (2004. gada 23. novembris)
A nevar to b.a_id konvertēt uz latin1/cp1257 un tādējādi salīdzināt…?
15 RuncZ @ 19:39 (2004. gada 23. novembris)
nu un kā ar konekcijas čarseta un collation izvēli ??
tjipa laikam bij sekojoši:
set names 'your_favourite_encoding_here';
set character set 'your_favourite_encoding_here';
nu protams tur jāzin, kā mysql atpazīst kodējumus ar domu, ka utf–8 ir 'utf8', windows–1257 ir cp1257.. nu karoč konvertē uz nebēdu
tad pēc idejas pat konsolē viss izvadās kā prasīts.. at least man uz 4.1.3 tā iet
P.S. šitais online translita konvertors nerullē, jo līdzko teksts ir vairāk, kā ielien šinī textarea laukā un parādās scrolleris, tā jams spītīgi uz katras pogas piespiedienu stāv uzrullēts maksimāli uz augšu.. un rezultātā jāraksta ir pa tumšo :/ (Firefox/1.0 & w2k+SP4, ja tas kauko ietekmē)
16 RuncZ @ 19:44 (2004. gada 23. novembris)
ar domu izvēlēties tajas vecajās aplikācijās to collation un charsetu un tomēr nokonvertēt tās tabulas .. (sorre par doublepostu, pauris liecas)
17 Roze @ 22:03 (2004. gada 23. novembris)
If you have a column in one character set (like latin1) but the stored values actually use some other, incompatible character set (like utf8). In this case, you have to do the following for each such column: ALTER TABLE t1 CHANGE c1 c1 BLOB;
ALTER TABLE t1 CHANGE c1 c1 TEXT CHARACTER SET utf8;
The reason this works is that there is no conversion when you convert to or from BLOB columns.
18 juris @ 22:07 (2004. gada 23. novembris)
kāpēc jauno tabulu nevarēji taisiit vienā kodējumā ar veco un izmatot latin1 un glabāt tur savus cp1257 datus? Es saprotu ka utf–8 skaitas stilīgi, taču esošā sistēma jācenšas strādāt vecās sistēmas stilā nevis dzejot uber konvertāciju.
Tašu reāli tavam risinājumam 15 koments varētu noderet un translita konvertētājs ir īpaši neērts
19 Roze @ 22:33 (2004. gada 23. novembris)
Aiz kam mysql pēc dokumentācijas piedāvā arī šādu variantu (itkā ar ne nelatin čaracteri līdz ar to '?' nevaidzētu būt)
SELECT CONVERT(_latin1'Müller' USING utf8);
Tākā moš vari rakstīt..
.. WHERE CONVERT(_latin1`a.id` USING utf8) = `b.a_id`
20 karlis @ 10:34 (2004. gada 24. novembris)
bija līdzīga problēma:
vecā tabula (utf–8) vairs negribēja ielikt īsto charsetu. Kā saprotu problēma bija iekš tā apstākļa, ka mysql pieņēma, ka ienākošie dati ir tipa latin un ņēmās šos konvertēt uz utf–8, līdz ar ko galarezultātā sanāca kaut kādas kakas, jo konvertēt neko vairs nevajadzēja.
atrisināju sākumā izveidojot tabulu struktūru bez datiem un visiem laukiem, kuri saturēja tekstus norādot kodejumu binary. pēc tam savukārt tikai importēju datus (bez create table).
21 jozhix @ 06:13 (2004. gada 25. novembris)
karlis, tikai laacz gadijumaa buutu jaataisa vjuuvs(i)
22 Didulis @ 18:32 (2004. gada 25. novembris)
Pirmkārt jau laacz nav problēmu ar selektēšanu, ko te lielākā daļa cenšas izskaidrot.
Otrkārt pie pašas problēmas. Vai neder exports uz XML? Exportējam visus datus uz XML, manuāli nomainam kodējumu un iebarojam datus jaunā tabulā ar pareizu kodējumu. It kā stabilāks variants par vienkāršu Alter table.