fr3akX

Maaren, kādu storage engine izmanto tabulām, 'show table status' to paraadīs zem Type? Cik lielas tev ir tabulas, ja downtime nav kritisks, tad var alterot tabulas uz InnoDB un lietot transakcijas. Ja neizpildās visi no query'jiem, tad transakcija rollback'ojas. Tavā gadījumā transakcijas ir vissaprātīgākais variants :) BEGIN insert into userlist(user,password,mail,sex,level,name,surname) values('$username','$dbpass','$mail','$sex','1','$firstname','$surname') delete * from inactive_user WHERE id='$inactiveid COMMIT

Gala risinājums ir līdzīgs sākotnēji izteiktajiem variantam par konvertācijas tabulām. 1. Katram charsetam tika izveidots paterns heksā, kur ietilps visi simboli, kas nav ASCII. (http://www.mikezilla.com/exp0012.html) 2. Katrs ieraksts tika matchots pret katru paternu un, ja tas mačojās, tad iegūstam ieraksta kodējumu, ja nē, tad tas ir ASCII. 3. Kad ieguvām kodējumu konvertējam ierakstu ar iconv no iegūtā kodējuma uz UTF-8. 4. Kad ieraksts tika pārkonvertēts uz UTF-8, pēdējais solis bija pārkonvertēt entītes ar html_entity_decode. Pēc kā tika iegūts UTF-8 kontents :)

interesants variants, būs jāizmēģina. paldies!

zinu tikai kāda valoda tika norādīta reģistrējoties, bet pēdējais valodas uzstādījums tiek glabāts tikai pārlūka cookie. Var jau balstoties uz to kāda valoda tika norādīta reģistrējoties, bet būs datu zudumi. Izskatās, ka tas ir vienkāršākais risinājums. Ja ņemties ar konvertācijas tabulām, tad arī iespējams būtu datu zudumi, ja simboliem dažādos kodējumos izrādās vienāds hex's. Droši vien būs jāveic konvertācija, kas balstās uz valodu, kas norādīta registrējoties. Paldies, par ātrām atbildēm un padomiem!

Tā arī ir, ka lietotājam, kurš vadījis RU interfeisā, atverot LV ir ķeburi. mb_detect_encoding esmu skatījies, diez cik labi tas nestrādā, detektee tikai ASCII un UTF-8, vismaz tā ir manā gadījumā.

Šī sistēma ir per/user. Satur sevī informāciju par lietotājiem un to kontaktiem. Dažādi lietotāji lieti dažādus interfeisus, tādēļ nav nepieciešamības redzēt informāciju, kas ir vadīta no citas valodas. EDIT: Par to pēdējo, tad domāju, ka tam nav atšķirības, tā kā tur nav diakritisko simbolu.

Aplikācijā ir iespēja pārslēgties starp valodām. Sadalīt 3 sql failos nesanāks, jo visas valodas ir vienā kaudzē. Piem. ja izvēlies RUS interfeisu un raksti LV, tad tas arī tā saglabāsies. Tabulās nav nekāda dalījuma starp valodām. Ja raksta RUS interfeisaa LV purtiem, un otrādi, tad simboli saglabājas entītēs, ko pārkonvertēt problēmu nebūs. Domāju jābūt iespējai nodetektēt čārsetu, piem. skanē vārdu, ja atrod kādu simbolu, kas nav en, tad skatās konvertāciajs tabulās, jā tādu atrod, tad visu vārdu konvertē no detektētā čārseta. Problēma tikai atrast šādas tabulas.

Sveiki! Šobrīd cīnos ar sekojošu problēmu. Ir datubāze kuras tabulu kodējums ir latin1 un satura kodējums ir ISO-8859-13,ISO-8859-1, 1257 t.i LV, RU, EN. Saturs man ir jāpārkonvertē uz UTF-8, tad arī pašas tabulas jāpārkonvertē uz UTF-8. Tākā saturs ir vairākos kodējumos, tad šis variants neder (http://www.mysqlperformanceblog.com/2007/12/18/fixing-column-encoding-mess-in-mysql/). Nav iespējams arī pārkonvertēt ar iconv, tākā ir jānorāda ieejas kodējums, un tie ir vairāki. Man ir pāris varianti kā šo konvertējumu varētu paveikt: Detektēt katra simbola kodējumu un konvertēt ar iconv (problēma - kā detektēt) Izveidot charsetu tabulu, pēc kuras izparsēt visu datubāzi aizmainot vienu pret otru, arī simbola bāzēts risinājums, bet šajā gadījumā pastāv iespēja, ka dažādos gadījumos simboli var sakrist varbūt kāds ir saskāries ar šādu problēmu un varētu ieteikt risinājumu. Jau iepriekš paldies!