← Uz sākumu

MySQL 4.1 help needed

2004. gada 23. novembrī, 23 komentāri

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.

Tu atbildi augstāk redzamajam komentāram. Atcelt

Gravatar Atoms

2004. gada 23. novembrī, plkst. 14:39

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....

Gravatar laacz

2004. gada 23. novembrī, plkst. 14:42

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 :)

Gravatar bubu

2004. gada 23. novembrī, plkst. 15:09

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

Gravatar laacz

2004. gada 23. novembrī, plkst. 15:16

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.

Gravatar Shiazo

2004. gada 23. novembrī, plkst. 15:19

paurbinaaju degunu. laacz, programmatuuras arhitektuuras izstraades posms ir pirms realizeeshanas & implementeeshanas posma (resp. kodeeshanas) :D da neko - gribeeju pavazat aiz deguna.

Gravatar laacz

2004. gada 23. novembrī, plkst. 15:21

Shiazo: Pateikt godīgi? Es par šiem posmiem dzirdējis esmu. Un pieturos pie jamajiem dikti minimāli. Tā nu tas ir. :)

Gravatar Neonz

2004. gada 23. novembrī, plkst. 15:34

A vaig tieši lai mysql ņemas ar tiem encodingiem? Nevar izmantot PHP iconv() pēc selekta?

Gravatar laacz

2004. gada 23. novembrī, plkst. 15:37

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.?

Gravatar anonīmi

2004. gada 23. novembrī, plkst. 16:00

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!

Gravatar Arturs

2004. gada 23. novembrī, plkst. 16:17

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//

Gravatar Mr.Venom

2004. gada 23. novembrī, plkst. 16:33

vāja cerība uz pārkonvertēšanu "lidojumā": WHERE a.id = _utf8b.a_id

Gravatar Mr.Venom

2004. gada 23. novembrī, plkst. 16:34

vāja cerība uz pārkonvertēšanu "lidojumā": WHERE _utf8a.id = b.a_id

Gravatar Djuke

2004. gada 23. novembrī, plkst. 16:51

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

Gravatar ZeaLot

2004. gada 23. novembrī, plkst. 17:03

A nevar to b.a_id konvertēt uz latin1/cp1257 un tādējādi salīdzināt...?

Gravatar RuncZ

2004. gada 23. novembrī, plkst. 19:39

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ē)

Gravatar RuncZ

2004. gada 23. novembrī, plkst. 19:44

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)

Gravatar Roze

2004. gada 23. novembrī, plkst. 22:03

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.

Gravatar juris

2004. gada 23. novembrī, plkst. 22:07

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

Gravatar Roze

2004. gada 23. novembrī, plkst. 22:33

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(_latin1a.id USING utf8) = b.a_id

Gravatar karlis

2004. gada 24. novembrī, plkst. 10:34

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).

Gravatar jozhix

2004. gada 25. novembrī, plkst. 06:13

karlis, tikai laacz gadijumaa buutu jaataisa vjuuvs(i)

Gravatar Didulis

2004. gada 25. novembrī, plkst. 18:32

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.

Gravatar error

2008. gada 12. septembrī, plkst. 14:23

kads,nevar pateikt ka pec man nevaru uztasīt mysol tabulu freehostia.com neņem pretī garumu/vertību piem: 12"/"a") ?