Izgubljen u encodingu...

[ 5h0ck @ 10.03.2010. 03:24 ] @

Sve je radilo super, a onda su mi ovi iz hostinga blokirali bazu dok nešto ne popravim, kada sam popravio i kada su pokusali da vrate bazu - nije je bilo, pa su je pokusali vratiti iz bekapa, ali onda su neki karakteri poludeli, pitaj q šta se tu desilo, a ja ne znam kako da vratim, kako da konvertujem, u šta da konvertujem...

Ovo sve zvuči malo konfuzno, ja sam konfuzan i umoran, pa ajde da probam da iznesem barem neke činjenice:
- strane su mi utf-8
- collation baze je utf8_unicode_ci
- ovako mi je izgledao upis u bazi pre: Uno&scaron;enje foto-aparata, kamera i sl. je takoÄ‘e ZABRANJENO i isti Ä‡e biti oduzimani na ulazu!
- nakon vraćanja baze iz njihovog bekapa: Uno&scaron;enje foto-aparata, kamera i sl. je takoÃ„â€˜e ZABRANJENO i isti Ã„â€¡e biti oduzimani na ulazu!
- nakon vraćanja baze iz mog bekapa: Uno&scaron;enje foto-aparata, kamera i sl. je takoÄ‘e ZABRANJENO i isti Ä‡e biti oduzimani na ulazu!

Ne znam šta da radim... Pomažite molim vas...

[ bogdan.kecman @ 10.03.2010. 04:45 ] @

vec sam jednom nogom u krevetu ali .. evo na brzaka jedan primer

takoÄ‘e

ovo "dj" koje ti ovde fali je dvobajtni utf8 karakter (0xC4 0x91)

ako ti ovo posaljes "kako treba" u mysql (klijent koristi utf8 enkoding) mysql ce taj jedan karakter da zapise kao 3 bajta (0x00 0xC4 0x91).
ako ti uradis "vrlo cestu glupost" i klijent ti koristi latin1 enkoding a misli da je utf (kao na primer php sa kojim nisi odradio set names posle konekcije) ti ces mysql-u da posaljes 2 latin1 karaktera od kojih ce svaki da bude zapisan kao 3 bajtni utf, te ce 0xC4 latin1 karakter (to veliko slovo A sa tackicama) biti zapisano kao neka tri bajta i onaj 0x91 kao jos tri i to je 6 bajtova koje ti vidis u takoÃ„â€˜e

da bi to sve radilo kako treba (vratio bekap, imao "korisne podatke" u bazi, imao ok prikaz na webu ..) mora da se potrefi

1. da je sve u bazi kako treba .. dakle da je to slovo "dj" u bazi jedan karakter (3 bajta) a ne 2 karaktera po tri bajta
2. da je sve u aplikaciji kako treba (dakle da se pravilno setuje enkoding konekcije izmedju klijenta i servera)

to ce da "deluje ok" u slucaju da je u bazi smece a da ga php takvog ocekuje .. tako da ce on onih 6 bajtova koje dobije da pljune browseru kao 2 latin1 karaktera a browser ce da to isparsira kao jedan utf karakter posto mu to pise u hederu.

u zavisnosti od toga sta imas u sql fajlu iz koga radis restore relativno je lako (nema mnogo nasih karaktera) da napises kratak skript koji ce da ti uradi search & replace i da upises umesto tih 6 bajtova za "dj" koje verovatno imas u sql- fajlu 2 bajta tj jedan utf karakter ... onda obavezno na pocetku sql fajla setujes pravilno enkoding (set names ..) i onda restorujes to nazad ...

ima i "nekad brza" varijanta da restorujes u latin1 / prebacis u bin / vratis u utf8 ali to se isplati samo ako imas mnogo karaktera .. sa nasih 5-6 karaktera, brzi ti je search & replace

onda moras da sredis app .... tamo gde pravis konekciju - setuj koji je enkoding iste (set names ..)

sorry sto ne mogu detaljnije ali 0543 .. budan sam vec vise od 48h moram da zabodem malo ... nadam se da ti je ovo dovoljno jasno

p.s. vrlo verovatno mozes da "zakrpis" problem (ako je frka za downtime) tako sto ces da samo tamo gde setujes konekciju da kazes "set names 'latin1'" (da latin1 umesto utf8) i probas dal ce to da proradi ... moguce da je hosting provider promenio default klijentski enkoding... ali obrati paznju da to i ako proradi - i dalje ti je u bazi "smece" - tj u bazi ti je i bilo smece samo to nisi znao

[ 5h0ck @ 10.03.2010. 09:50 ] @

Bogdane, hvala ti puno na opširnom odgovoru u sitne sate. Imam još par pitanja na osnovu tvog odgovora...

"dakle da je to slovo "dj" u bazi jedan karakter" - Jel to znači, da u bazi treba umesto takoÃ„â€˜e pisati baš takođe ili...?

I ako bi mi samo još malo pomogao oko skripte za konvertovanje i toga šta on tačno treba da konvertuje... I mislim da tu imam problem sa ćirilicom, ima je dosta. Tačnije, cela baza je podosta velika (35mb), 3 godine pisanje raznih vesti, blogova, komentara...

Što se set names-a tiče i to sam probao i promenio nekoliko charset-a, ali je rezultata bio da jedne kerefeke zameni drugima...

Hvala još jednom na pojašnjenom odgovoru, sada mi je sa te neke strane jasnije, ali mi i dalje nije jasno zašto se bilo šta promenilo prilikom bekapovanja, i da li, ako je već nešto promenilo taj karakter u drugi, zašto ne postoji podjednako lak način da uradi obrnuto... :/

Kako ću znati da nemam smeće u bazi?

[ bogdan.kecman @ 10.03.2010. 19:26 ] @

nema na cemu ... glava mi puca ceo dan tako da cu opet ukratko ... (ono sto me cudi je da niko nije priskocio u pomoc a sigurno ima bar 10 ljudi koji prate forum i znaju kako da rese taj problem ... i svi cute ko zaliveni :( )

ne vredi ti da pravis skript za konvertovanje sql-a ako imas tu i cirilicu ..

35M je "malecna baza" ... aj to spakuj i uploaduj negde i posalji mi (na pp ili na mail) odakle da skinem ... ako nemas gde da uploadujes reci pa da vidimo neki drugi nacin da mi posaljes fajl .. pa cu ja to da ti sredim ..

takodje je bitno
- koja je verzija mysql-a sa kog je napravljen taj bekap
- koja je verzija mysql-a na koju ide restore

(ubi me glava nemam snage sad da pisem proceduru ... tako da .. baci mi taj bekap, ja cu popravim, pa cu kad se oporavim da se smorim da napravim eventualno post kod mene na blogu "kako da se izvuce iz tog sra*a")

[ Tyler Durden @ 12.03.2010. 09:56 ] @

I mene muči enkoding, tj. prebacivanje sa MySQL servera verzije 3.23 na 5.0.51.
Baza na 3.x je u latin1 formatu, i kad je dampujem sa mojim klijentom iz shella sa

Code:
mysqldump --add-drop-table --default-character-set=latin1 --insert-ignore --skip-set-charset .... > baza.sql

dobijem fajl u kome se nalazi

Code (sql):

-- Server version       3.23.56-log

/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;

/*!40103 SET TIME_ZONE='+00:00' */;

/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;

/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;

/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;

/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;

--

-- Table structure for table `grejanje`

--

DROP TABLE IF EXISTS `grejanje`;

/*!40101 SET @saved_cs_client     = @@character_set_client */;

/*!40101 SET character_set_client = utf8 */;

CREATE TABLE `grejanje` (

  `id` INT(11) NOT NULL AUTO_INCREMENT,

  `naziv` VARCHAR(40) DEFAULT NULL,

  `knaziv` VARCHAR(40) DEFAULT NULL,

  PRIMARY KEY  (`id`)

) ENGINE=MyISAM;

/*!40101 SET character_set_client = @saved_cs_client */;

--

-- Dumping data for table `grejanje`

--

LOCK TABLES `grejanje` WRITE;

/*!40000 ALTER TABLE `grejanje` DISABLE KEYS */;

INSERT  IGNORE INTO `grejanje` VALUES (1,'Centralno grejanje','CG'),(2,'TA peÄG','TA'),(3,'EtaÅ¾no na struju'.....

i kad to pokušam sa istim klijentom da učitam na 5.0.x naravno, ne radi.
I ja sam nešto pogubljen sa tim enkodingom jer sam prije na ovaj način uspješno prebacivao iz latin1 u utf8. Doduše, ne između ovih verzija.

Probao sam i po ovom uputstvu ali ništa nije pomoglo.

[ bogdan.kecman @ 12.03.2010. 18:32 ] @

3.x ne zna sta je to karakter set !!!

ja sam krenuo da pisem neki skriptic za to al ukratko ...

1. uzmi taj tvoj dump file, takav u originalu, i napravi kopiju istog
2. onda promeni create table tako da svi text, char, varchar i ostali "txt" podaci budu BLOB !!
3. importuj sada taj dump u mysql 5.x
4. uradi sada za svako to polje koje si prebacio iz text u blob ili iz char(40) u blob ili ....
alter table t1 modify f1 char(40) character set utf8;
5. voila - sad sve radi

ono sto je bitno je da ubodes character set koji je "stvarno" u tabeli ... na primer mladi kolega 5h0ck je imao pola podataka u windows-cp1250 a pola u utf8 tako da je popravljanje negovog dump-a zahtevalo malo vise cimanja .. (fala bogu za awk i sed) + je imao kolone koje se zovu "order", "group", "date", "time", "timestamp" i slicno a naravno nisu bile backtikovane tako da sql naravno nije mogao da se izvrsi (opet - hvala bogu za sed)

dakle za tvoj slucaj ...

Code:

-- izbacis sva ova "sra*na na pocetku"

--
-- Table structure for table `grejanje`
--

DROP TABLE IF EXISTS `grejanje`;

-- izbacis obavezno ovaj ovde smor sa charsetom posto nije ispravan !!
CREATE TABLE `grejanje` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `naziv` BLOB,
  `knaziv` BLOB,
  PRIMARY KEY  (`id`)
) ENGINE=MyISAM;

--
-- Dumping data for table `grejanje`
--

LOCK TABLES `grejanje` WRITE;
/*!40000 ALTER TABLE `grejanje` DISABLE KEYS */;
INSERT  IGNORE INTO `grejanje` VALUES (1,'Centralno grejanje','CG'),(2,'TA peÄG','TA'),(3,'EtaÅ¾no na struju'.....
...

spucas to u bazu ... i onda odradis

Code:

alter table `grejanje` modify `naziv` varchar(40) character set utf8;
alter table `grejanje` modify `knaziv` varchar(40) character set utf8;

i sada proveris podatke u bazi - trebalo bi da su ok (za ovaj tvoj primer sa ovim podacima ce sigurno biti ok)

[ Shinhan @ 23.03.2010. 08:57 ] @

Niiice :)

Nisam znao za ovaj trik sa prebacivanjem u blob, mi kada smo migrirali na unicode sa latin1 smo ručno find-and-replace loše karaktere. (na sreću smo koristili samo latinicu)

[ Tyler Durden @ 19.07.2010. 10:44 ] @

@bogdan,
a sta da radim kad je ta kolona postavljena i kao neki KEY? I onda dobijam gresku

Code:
ERROR 1170 (42000) at line 20:
BLOB/TEXT column 'kolonaaaa' used in key specification without a key length

Vidim na netu da predlazu da se ukloni taj KEY, ali ja to ne mogu da uradim. Postoji li neki drugi nacin?

[ bogdan.kecman @ 19.07.2010. 10:52 ] @

ti dok radis "Sredjivanje podataka u bazi" pristup toj bazi svejedno mora da se ukine tako da uklanjanje tog key-a ne treba da predstavlja problem. Ukines taj key, prebacis tamo vamo i kad podaci tu budu ok vratis key :D ... izgubices malo vremena za generisanje tog kljuca i to je sve

[ Tyler Durden @ 19.07.2010. 11:27 ] @

Problem je sto se tu ne radi o jednoj bazi vec o par stotina :)
Pa mu ga to onda dodje kao mali skripterski pakao.

Nekako sam uspio da odradim citav find/replace svih char varchar text polja i onda ponovo ucitavanje, ali ovo me sad vratilo opet u kameno doba. + nove zajebancije se pojavljuju, kao npr. ta blob polja ne mogu da imaju default vrednosti pa i to mora da se budzi..
Ubicu se.

[ bogdan.kecman @ 19.07.2010. 11:37 ] @

default vrednost ti ne znaci nista posto polje svejedno vec ima neku vrednost a kao sto rekoh, dok radis tu promenu nema nikakvih inserta tako da te bas briga za default vrednost ..

ali da - pakao jeste - problem je kada se od starta lose radi i kada se smece u bazi nagomila, srediti to ume da bude "day in hell"

[ Tyler Durden @ 10.08.2010. 16:05 ] @

Odradio sam monstrum skriptu koja je veliku vecinu posla uradila kako treba, ali mi je ipak ostalo par (ne moze da ne ostane) koje ne mogu da provalim sta ih muci i vozaju me vec dva dana.

Jednostavno, ne prikazuje mi nista iza č,ć... iz npr. te celije. Kao da ga tu nesto presijece.
A ne prijavljuje nikakvu gresku i "ostatak" podataka se i dalje nalazi u toj celiji.

[ bogdan.kecman @ 10.08.2010. 16:27 ] @

lose je formatiran string unutar polja .. najlakse ti je sledece ... prebacis ga u bin, napravis web skriptu koja ce taj bin da procita i pukne na html stranu bez ikakvog enkodinga i onda u browseru menjas enkoding (imas par desetina komada) dok ne nadjes tacno koji ce da ti prikaze txt kako treba ... onda prebacis u txt sa tim enkodingom, pa u utf8 ..

[ Tyler Durden @ 11.08.2010. 09:11 ] @

Skapirao sam dio oko pronalazenja koji encoding je u pitanju i nasao sam ga (windows1250), ali zaista mi je mozak overloadovan i ne znam vise kako da to prebacim u utf8.

Dakle, kad na "novoj" bazi prebacim spornu kolonu u blob i povucem nesto sa jednostavnom skriptom skontam da je to win1250, ali sta sad dalje da uradim kako bi to prebacio u utf8? Jer kad vratim u text tu kolonu, ono opet ode sve kvragu.
Opet dump pa neke izmjene, pa ucitavanje opet.. ili moze nekako direktno u bazi??

[ bogdan.kecman @ 11.08.2010. 09:29 ] @

prebacis je u BLOB - ako sada na webu ovo vidis kao cp1250 ides dalje

pa iz BLOB prebacis u VARCHAR (ili char) sa CHARACTER SET cp1250
pa onda promenis character set u utf8 ..

dakle

Code:

alter table smece change djubre djubre blob;
alter table smece change djubre djubre varchar(100) character set cp1250;
alter table smece modify djubre djubre varchar(100) character set utf8;

[ Tyler Durden @ 11.08.2010. 09:51 ] @

Hm, probao sam tako, ali vrate se samo ž i š slova a čćđ se i dalje pojavljuju kao ?.
Inace, ovdje je konkretno u pitanju bila text kolona, ali mislim da to nema veze.

bogdane, kad ovo zavrsim castim te gajbom piva....

[ Tyler Durden @ 11.08.2010. 09:55 ] @

A stani, prekrizi ovo gore, javljam se za par minuta... :)

Ne ovo za pivo, to ostaje nego ovo za ćč... :D

[ bogdan.kecman @ 11.08.2010. 11:05 ] @

ma pivo cemo lako nego ako ti ne uspe, odradi dump te tabele pa mi baci na bogdan.kecman [na] mysql.rs (pre toga bzipni)

[ Tyler Durden @ 15.09.2010. 09:17 ] @

Jos uvijek ovo razvlacim, ali polako i privodim kraju.

Imam opet cudnu situaciju. Kad prebacim na novi server/bazu polje je u blob formatu i u browseru se sve vidi ok kad je utf8 koristi u browseru. Kad prebacim to polje nazad u varchar bilo da mu navedem
alter table vesti change naslov naslov varchar(150) character set utf8 default NULL
ili
alter table vesti change naslov naslov varchar(150) default NULL
sve pobrljavi, odnosno pojave se upitnici?

[ bogdan.kecman @ 15.09.2010. 15:22 ] @

daj select HEX(blobpolje) from t1; pa onda iskonvertuj to u varchar sa utf8 pa opet uradi select HEX() pa da vidimo sta je uradio

[ Tyler Durden @ 16.09.2010. 08:19 ] @

Jesi ovako mislio?
Nista se nije promjenilo.

[ bogdan.kecman @ 16.09.2010. 08:36 ] @

da tako, nesto nije u redu ...

ako je HEX() bloba

D0A0D095D097D0A3D09BD0A2D090D0A2D09820D09AD09ED09DD09AD0A3D0A0D0A1D09020323030332E20D093D09ED094D098D09DD095202D2022D09FD09BD090D09DD098D09DD09020D09820D097D094D0A0D090D092D089D09522

i kada ga prebacis u UTF8 ostane:

D0A0D095D097D0A3D09BD0A2D090D0A2D09820D09AD09ED09DD09AD0A3D0A0D0A1D09020323030332E20D093D09ED094D098D09DD095202D2022D09FD09BD090D09DD098D09DD09020D09820D097D094D0A0D090D092D089D09522

to znaci da je "validan" ... tj, ako se ja dobro secam, da nije mysql bi trebalo da kuka ... mada to je uvek "pitanje" ...

kada iz PHP-a uradis "SET NAMES 'UTF8'; SELECT naslov FROM vesti;" i spucas to direkt browseru kome je enkoding utf8 sta ti prikaze browser u jednom a sta u drugom slucaju?

koji bese mysql tu kod tebe moram da proverim nesto, ne secam se vise kako se ponasa ova konverzija sa "pogresnim" enkodingom

[ bogdan.kecman @ 16.09.2010. 08:51 ] @

nesto ti tu nije ok .. pazi ovako, kada taj hex ubacis u fajl:

Code:

<?php
$x = 'D0A0D095D097D0A3D09BD0A2D090D0A2D09820D09AD09ED09DD09AD0A3D0A0D0A1D09020323030332E20D093D09ED094D098D09DD095202D2022D09FD09BD090D09DD098D09DD09020D09820D097D094D0A0D090D092D089D09522';

$t = '';

$f = fopen("kita.txt", "w") or die("greska");

for ($i=0;$i<strlen($x);$i+=2){
  $p = hexdec( substr($x,$i,2));
  fwrite($f,  chr($p));
  $t .= chr($p);
}
fclose($f);

if (is_validUTF8($t)){
  echo 'validan utf8 string:' . $t . "\n";
} else {
  echo "nije validan string\n";
}

function is_validUTF8($str) //http://php.net/manual/en/function.utf8-encode.php
{
    // values of -1 represent disalloweded values for the first bytes in current UTF-8
    static $trailing_bytes = array (
        0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
        0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
        0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
        0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
        -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1, -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,
        -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1, -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,
        -1,-1,1,1,1,1,1,1,1,1,1,1,1,1,1,1, 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
        2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2, 3,3,3,3,3,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1
    );

    $ups = unpack('C*', $str);
    if (!($aCnt = count($ups))) return true; // Empty string *is* valid UTF-8
    for ($i = 1; $i <= $aCnt;)
    {
        if (!($tbytes = $trailing_bytes[($b1 = $ups[$i++])])) continue;
        if ($tbytes == -1) return false;

        $first = true;
        while ($tbytes > 0 && $i <= $aCnt)
        {
            $cbyte = $ups[$i++];
            if (($cbyte & 0xC0) != 0x80) return false;

            if ($first)
            {
                switch ($b1)
                {
                    case 0xE0:
                        if ($cbyte < 0xA0) return false;
                        break;
                    case 0xED:
                        if ($cbyte > 0x9F) return false;
                        break;
                    case 0xF0:
                        if ($cbyte < 0x90) return false;
                        break;
                    case 0xF4:
                        if ($cbyte > 0x8F) return false;
                        break;
                    default:
                        break;
                }
                $first = false;
            }
            $tbytes--;
        }
        if ($tbytes) return false; // incomplete sequence at EOS
    }
    return true;
}

?>

fajl bude validan utf8 cirilica (REZULTATI KONKURSA 2003. GODINE - "PLANINA I ZDRAVLjE") i ova funkcija koja proverava validnost potvrdi da je string validan .... tako da bice da imas negde gresku kod sebe

[ Tyler Durden @ 16.09.2010. 10:16 ] @

Radi sa set names utf8....
Provjericu kasnije, mislim da to ima veze sa verzijom php-a i mysql klijenta sa kojim je kompajliran isti, jer na novijim serverima imam iste slucajeve ali nije potrebno eksplicitno set names utf8.
Ovdje je u pitanju php 4.4.7 i mysql 4.1.22.

Imacu jos jedno pitanje kasnije i mislim da je to to :)

[ bogdan.kecman @ 16.09.2010. 10:19 ] @

pazi, 4.1 nije najsrecnije resenje sa enkodingom, tu je prvi put dodata podrska ...

UVEK iz PHP-a radi set names inace php prica sa bazom kao latin1, samo slucajno mozes da naletis na php konektor koji prica utf8, dakle kad ne stavis set names generises smece

[ Tyler Durden @ 16.09.2010. 13:24 ] @

Evo, imam sad situaciju gdje hex nije isti nakon konverzije

Ovo je prije konverzije

Code:

613A343A7B733A353A227374796C65223B733A313A2231223B733A31343A22646973706C617977616974696E67223B733A313A2231223B733A31343A22646973706C61796D6F64756C6573223B693A303B733A373A22636F6E74656E74223B733A313039353A22696E6465782E7068707C506FE86574616B7C506F76726174616B206E61206F736E6F766E7520737472616E6963752E2E2E4C494E4553504C4954757365722E7068707C4D6F6A206E616C6F677C41646D696E697374726163696A61206C69E86E6F67206E616C6F67612E2E2E4C494E4553504C49545B4D657373616765735D7C5072697661746E6520706F72756B657C5072697661746E6520706F72756B652064727567696D20E86C616E6F76696D61206F766F672073616A74612E2E2E4C494E4553504C495461646D696E2E7068707C41646D696E697374726163696A617C41646D696E697374726163696A612073616A74612E2E2E4C494E4553504C4954757365722E7068703F6D6F64756C653D55736572266F703D6C6F676F75747C4F646A6176617C4F646A6176612E2E2E4C494E4553504C49547C7C4C494E4553504C49547372735F666F72756D7C466F72756D7C466F72756D20536176657A612E2E2E4C494E4553504C49545B546F706963735D7C54656D657C53706973616B206E6F766968206E61736C6F7661206E61206F766F6D2073616A74752E2E2E4C494E4553504C49545B53656374696F6E735D7C53656B63696A657C4F7374616C6920736164729E616A69206F766F672073616A74612E2E2E4C494E4553504C49545B4E6577735D7C56657374697C506F736C65646E6A65207665737469206E612073616A74752E2E2E4C494E4553504C49545B5375626D69745F4E6577735D7C506F9A616C6A6920E86C616E616B7C506F9A616C6A6920E86C616E616B20696C6920766573742E2E2E4C494E4553504C49545B4641515D7C506974616E6A617CC86573746F20706F737461766C6A616E6120706974616E6A612E2E2E4C494E4553504C49545B5365617263685D7C5472619E697C5072657472619E6976616E6A65206F766F672073616A74612E2E2E4C494E4553504C49545B446F776E6C6F6164735D7C446F776E6C6F6164737C46616A6C6F7669207A6120707265757A696D616E6A652E2E2E4C494E4553504C49545B5765625F4C696E6B735D7C576562206C696E6B6F76697C4C696E6B6F7669206B612064727567696D2073616A746F76696D612E2E2E4C494E4553504C49545B53746174735D7C53746174697374696B617C53746174697374696B61206F2073616A74754C494E4553504C49545B4D656D626572735F4C6973745D7C4C6973746120E86C616E6F76617C4C6973746120726567697374726F76616E696820E86C616E6F76612073616A74612E2E2E4C494E4553504C49545B5265636F6D6D656E645F55735D7C507265706F7275E8697465206E61737C507265706F7275E8697465206F76616A2073616A742064727567696D612E2E2E4C494E4553504C4954696E6465782E7068703F6E616D653D53656374696F6E73267265713D7669657761727469636C652661727469643D32347C3C623E4B6F6E74616B743C2F623E7C535253202D206B6F6E74616B7420696E666F726D6163696A65223B7D

Onda uradim
alter table t1 change content content text character set utf8 NOT NULL default '';

i nakon toga hex je

Sta se tu desi?

Da li bih imao nekih problema ako bi ostavio sva ova polja u blob formatu?

[ bogdan.kecman @ 16.09.2010. 17:41 ] @

desi se to da u blobu nije validan utf8 string i kada naidje na prvi nevalidan karakter mysql izignorise ostatak ...

ako pustis taj string kroz onaj php primer koji proverava validnost videces da ce da vrati da string nije validan.

sto se tice toga da ih ostavis kao blob, nemas pretragu po tim poljima onda, nemas ideju "sta je unutra"

[ Tyler Durden @ 17.09.2010. 10:32 ] @

A mogu li to kako da popravim, taj string?
Sta da radim onda sa ovim.. mora da ostane na staroj bazi?? ufff

[ bogdan.kecman @ 17.09.2010. 16:48 ] @

paaaaaaa .. ako ga vidis na web-u kako treba, copy sa web-a utf string pa paste ce odraditi posao ... rucno da ga popravljas - imas taj source u php-u koji testira string pa mozes da vidis uz pomoc njega tacno gde ti je problem..

sta da radis - proveris koliko imas takvih entrija koji su "razliciti" ... i ako nema previse, ispravis ih "na misice" ...

ima isto fora koja je meni uspela nekoliko puta

uradis mysqldump u fajl (obavezno NE stavis --hex-dump) ... on to spuca u txt ... onda taj txt otvoris u nekom "iskusnom" editory koji zna sta je to enkoding, kazes mu da je fajl utf8, promenis definicije polja u utf8 (samo create menjas, ostavis podatke takvi kakvi su), snimis fajl (u ovom trenutku ce veci broj editora "popraviti" sitne byte greske koje postoje (mislim da sam zadnji put to popravljao sa KATE) i onda to importujes nazad u mysql ... ovde ti je najveci cim da li ce text editor umeti da odradi "popravku" (meni je kate odradio posao par puta gde su bile sitne greske na mnogo mesta - dok je glupi gedit bio potpuno nesposoban) ... takodje ako je fajl "velik" imas problem posto svi ovi pokusavaju to da usisaju u ram tako da - veliki swap + mnogo strpljenja, zadnji put kada sam to radio ucitavao je fajl oko 2h a snimao isti oko 4h!!! tu je zgodno da posebno exportujes data a posebno definicije, posto samo definicije menjas, za data je bitno da ucitas fajl, dodas jedan razmak i snimis ga, bitno je samo da editor zna da je utf8 enkoding u pitanju

[ ColdKeyboard @ 12.10.2010. 15:35 ] @

Probao sam sve moguce varijante koje su gore navedene.

Uspio sam sa pretvaranjem polja u blob pa iz blob-a u varchar sa UTF-8.
Time sam dobio sve naslove u tabeli bez kvakica.

Ali problem je kada trebam da izmjenim TEXT polje. Sve radi ok dok ne pocne vracanje nazad u UTF-8, tada MYSQL 'zezne' tabelu tako sto
nakon pretvaranja dobijem polje koje umjesto cijele vrijednosti imam samo vrijednost do prvog slova sa kvakicom, poslije toga nema nista :S

Da li ima neki nacin da uradim backup pa da u nekom text editoru uradim replace tih znakova sa kvakicama?

[ bogdan.kecman @ 12.10.2010. 15:46 ] @

naravno . mysqldump ..

elem, ono sto ti je najverovatnije problem je da ti je sadrzaj u text polju u pogresnom enkodingu daj jedan slog koji ne valja iz originalne tabele

select polje, hex(polje) from tabela where id=nesto into outfile '/tmp/uploadujnaforum';