Registrace nového uživatele     Návod     Kluby     Archív  Lopuchu     Lopuch.cz  

Zelený je lopuch,
fotbal to je hra...

Lopuch.cz

Jméno:
Heslo:
Podpora LCD:
 
Klub Database (mysql,...) [ŽP: neomezená] (kategorie Programování) moderuje melkor_unlimited.
Archiv
  Nastavení klubu     Nastavení práv     Homepage     Anketa     Přítomní     Oblíbené     Lopuch     Kategorie  
autor: 
text: 
vyplnit a 
Help
 Titulek, text příspěvku  
Opište pozpátku následující text bez prostředního znaku: swkyngz
[ 1008 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  
puschpull puschpull být nad věcí, pohoda a klid ... - AV-Com (Homepage) 17.3.2009 15:21  871
jukněte ještě semWebsite Baker Help Project - Moving from Server A to B
jesli nedělám nějaký kopanec já ...
pepak pepak - Pepak.net 17.3.2009 15:20  870
Knedle: Taky mám podobný, ale udělaný primárně pro případ "dobrá data, blbá metadata". Ale na případ "dobrá data, dobrá metadata" by šel použít taky, to je jen speciální případ téhož :-)
pepak pepak - Pepak.net 17.3.2009 15:20  869
Puschpull: Není to tak strašné. Ty teď musíš udělat tři věci, které na sobě v podstatě nezávisí:

1) Opravit ten bordel v databázi (asi nejspíš tím postupem, co jsem nastínil). To ti mimo jiné vyřeší problém s tím, že web nejde přesunout na jiný hosting (a podotýkám, až to uděláš, tak bys to měl mít vyřešené "navždy"). Při tom search-and-replace kroku mimochodem můžeš rovnou zkonvertovat i tu češtinu uloženou v entitách.

2) Upravit WSB, aby nepoužíval HtmlEntities ale jen HtmlSpecialChars(). Tím vyřešíš vkládání entit místo českých znaků.

3) Vzít si čistý WSB a odtrasovat si, co ten blbec dělá se stringem "příliš žluťoučký kůň úpěl ďábelské ódy" předtím, než ho zapíše do databáze - prostě si na každý druhý řádek dát echo $promenna;. Jsem si dost jistý, že tam někde volá funkci, která ÚTF8 vstup zakóduje (po nějaké drobné konverzi) ještě jednou do UTF8. Tak tu nadbytečnou konverzi budeš chtít vyhodit.
knedle knedle online - Krabice živých 17.3.2009 15:13  868
pepak [866]: zkazil si mi radost - nicmene ja si to udelal "pro jistotu"
puschpull puschpull být nad věcí, pohoda a klid ... - AV-Com (Homepage) 17.3.2009 15:10  867
pepak: díky za informacekoukám, že je toho práce jak na kostele

samozřejmě bych byl nejraději, kdyby RS fungoval třeba tak, aby uměl tytvoři vájejazyčné stránky kde by byla třeba verze ENG/CZ/RUS/JAP
a celé na utf-8 kodování
(naivně jsem si myslel, že to lze) ale když tam do toho z nějakého důvody RS WebsiteBaker pořád cpe nějaké entity, tak to je asi na nic

Vytvoři by to tedy asi šlo, ale nešlo by vytvořený web přenést na jiný server (nebo resp. šlo, ale bylo by s tím víc práce a starost než twornou webů)
hmmm

ještě to nevzdávám, WSB má pro mě tolik kladů, že mu ještě chci dát šanci
pepak pepak - Pepak.net 17.3.2009 15:01  866
Knedle: To ale bude fungovat za jednoho zásadního předpokladu: Že v databázi odpovídají data metadatům. Ovšem pokud je tento předpoklad splněn, tak obvykle žádnou konverzi do UTF8 dělat nepotřebuješ, protože ti ji klidně udělá sama databáze (potřeba je to jen v případě, že by skutečně přicházelo v úvahu víceabecední prostředí, tj. že by mi třeba do fóra přispívali rusové).
pepak pepak - Pepak.net 17.3.2009 14:59  865
No, takže základní problém, proč to puschpullovi nejde, je vidět na tomto obrázku - ten obrázek je mimochodem důvod, proč jsem pořád tak tvrdohlavě trval na tom, abych dostal data "přímo z dumpu":
http://puschpull.org/root/a/Win_Hex_05.png

Když se podíváte na "zaměstnanci" (od offsetu 48E557), zjistíte, že data jsou sice uložena v UTF-8, ALE jsou dvojnásobně zakódovaná: ta sekvence bajtů C3 84 E2 80 BA jsou dva UTF-8 znaky, které kdyby se převedly do Windows-1250 (znak -> znak), tak by se velmi podobaly tomu, jak vypadá UTF-8 znak zobrazený editorem, který UTF-8 neumí (neodpovídá to přímo "ě", ale to může docela dobře být tím, že evidentně proběhla konverze převeď_na_UTF8(ber_string_jako_nějaké_ANSI_kódování(UTF8vstup)). Pravděpodobně tam ještě navíc někde bylo vnořeno volání htmlentities(), aby to z některých znaků udělalo entity.

Každopádně tohle se jen na databázové úrovni opravit nedá. Jako nejschůdnejší postup bych viděl (za předpokladu, že v tom jsou jenom české texty a ne i nějaká čínština):
1) Udělat dump databáze.
2) Zkonvertovat dump (jako text) do nějakého jednobajtového českého kódování (Win1250, Latin2, whatever).
3) Provést search-and-replace pro všechny české znaky.
4) Výsledek znovu zkonvertovat do UTF8.
5) Na začátek dumpu dopsat řádek SET NAMES utf8; - velmi důležité a dost dobře nechápu, proč to tam PhpMyAdmin nedává sám.
6) Naimportovat do nového serveru.
7) Po ověření, že se to zobrazuje dobře, si udělat zálohu starých špatných dat (pokud možno opět v binární podobě) a naimportovat to i do nich, aby to bylo dobře všude.
knedle knedle online - Krabice živých 17.3.2009 14:53  864
prave jsem dokopal skript pro prekopani kodovani uvnitr db na nejake
je to lehce upravenej script od Vrany, ale pouzivam dibi

// prekonvertovani kompletne vseho na UTF
// 1. db
// 2. tabulky
// 3. sloupce tabulek 

$character_set = "utf8";
$collate = "utf8_czech_ci";

// nejdrive databazi
dibi::query('ALTER DATABASE `'.$db['database'].'` DEFAULT CHARACTER SET '.$character_set.' COLLATE '.$collate);

// pak vsechny tabulky
$result = dibi::query('SHOW tables');
foreach ($result as $n => $row) {
    echo $tab = $row['Tables_in_'.$db['database']];
    
    exit;
    // zmenim kodovani tabulce
    dibi::query('ALTER TABLE `'.$tab.'` DEFAULT CHARACTER SET '.$character_set.' COLLATE '.$collate);
	// zjistim sloupce tabulky
    $result2 = dibi::query("SHOW COLUMNS FROM ".$tab);
    // a uvnitr tabulek pak i sloupce
    foreach ($result2 as $row1) {
        if (preg_match('~char|text|enum|set~', $row1["Type"])) {
            dibi::query("ALTER TABLE `".$tab."` CHANGE `".$row1[Field]."` `".$row1[Field]."` ".$row1["Type"]." CHARACTER SET ".$character_set." COLLATE ".$collate." NULL DEFAULT NULL");
            //ALTER TABLE `newsletter` CHANGE `captions` `captions` TEXT CHARACTER SET utf8 COLLATE utf8_czech_ci NULL DEFAULT NULL
        }    	
    }
    
    echo "tab ".$tab." hotova".BR;
    flush(); flush();

}
puschpull puschpull být nad věcí, pohoda a klid ... - AV-Com (Homepage) 17.3.2009 14:53  863
znáte tenhle RSjdu vyzkoušet i něco jiného než WSB (ale štve mě to)

Redakčný systém Etomite, zdarma - O Etomite
puschpull puschpull být nad věcí, pohoda a klid ... - AV-Com (Homepage) 17.3.2009 14:08  862
no jo no, pořád niczměnil jsem si kodování DB na serveru
ALTER DATABASE `xxxxxx` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci

nainstaloval znovy prázdný RS

vyexportval obsah tabulek týkajících se obsahu a názvů stránek vytvořených na localhostu

importival pomocí SQL dotazu v phpMyAdmin na serveru

výsledek je pořád stejně blbý

Web AIMON - Reference
knedle knedle online - Krabice živých 17.3.2009 13:27  861
abys vedel, ze v trablech s db nejsi sam, tak ted resim to, ze se mi pri pouziti UTF8 naimportuje pulka z tabulek spravne a pulka poskozena

ze stejneho dumpu pri pouziti latin2 se mi naimportuje takze pulka spatne a pulka dobre - ale jen v opacnem gardu

jak tohle dokazali vytvorit netusim
puschpull puschpull být nad věcí, pohoda a klid ... - AV-Com (Homepage) 17.3.2009 12:10  860
kdo rozumí dobře anglicky ?@Lior, here are a couple of hints - off the top of my head, so forgive me if they are not 100% accurate:

1) when you create a new database in MySQL, it automatically defaults to the 'swedish latin' collation. So, right after you create your database, go into phpMyAdmin (or whatever other DB admin tool you are using), and change the default collation for the entire database to the 'generic utf-8' option.

You need to do this, because when you create tables, fields, and import data *without* specifically setting an alternative collation, the default collation is used. Now, I can't remember whether the backup that WB does of your database includes the collation information for every table, but I suspect it doesn't, and that the problem you are experiencing may just be because you did not set the default collation for the new database to UTF-8 before you did the import.

Nevertheless, if the WB backup DOES contain collation information, it is easy enough for you to change it:

2) the backup script is a plain text file, so you should be able to change all references from one charset to another (like "latin_swedish" to "unicode_general_utf8") by doing a simple find-and-replace. Make sure you use the correct collation names (which I cannot remember right now off the top of my head).

3) if the backup script contains references to the wrong charset, it is very likely that the characters it exported from your database are also garbled. So, while you might wish to do a find-and-replace on all the garbled characters, substituting them with the correct ones.

Once your done all your replacing, and your backup file looks correct - ie., with all characters showing as they should, and the collation references correctly set to utf-8 - then you can load the backup up into your new database.

I hope this helps!
puschpull puschpull být nad věcí, pohoda a klid ... - AV-Com (Homepage) 17.3.2009 12:02  859
tady to je zajímavé (patrně i o mém problému)Moving WB to an new server - Problem!
pepak pepak - Pepak.net 17.3.2009 10:49  858
Tvx [834]: Měl. Jenže protože předpokládám, že ta data v souladu s metadaty nemá (ačkoliv teď ukázal případ, kdy to zrovna shodou okolností sedí), tak chci vidět skutečná reálná data, abych si udělal obrázek, JAK to má blbě.
puschpull puschpull být nad věcí, pohoda a klid ... - AV-Com (Homepage) 17.3.2009 10:25  857
Website Baker (forum) vyhledána slova (export import problem character)Take a look. Am I missing something?

[ 1008 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  

(c) 2001-2011 Lopuch.cz   
Kontakt