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

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

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

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.

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

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

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

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

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!

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

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

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

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

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

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

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)

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.

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

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

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

karlis, tikai laacz gadijumaa buutu jaataisa vjuuvs(i)

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.

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