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

Když diskuse,
tak s Lopuchem

Lopuch.cz

Jméno:
Heslo:
Podpora LCD:
 
Klub PHP [ŽP: neomezená] (kategorie Programování) moderuje makovec.
Archiv
Diskuse o vybornem skriptovacim jazyku php. Dulezite odkazy, pred polozenim dotazu zkuste hledat odpoved zde:
  1. www.php.net - domovská stránka PHP
  2. www.kosek.cz - spousta tutorialu pro PHP v češtině
  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: hjpepvn
[ 1845 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  
al3x 18.9.2006 17:39  1570
tvx [1569]: Ano. Stoprocentne s tebou souhlasim. Ani na chvilku jsem netvrdil, ze je to vada mysql. A ano, pokud mohu nastavit server sam, tak mu to nejcastejsi kodovani vrazim do konfiguraku. Kdyz to nejde (nebo chci jine), tak si to hold musim rict na zacatku pripojeni.
tvx tvx Myslet si, že svět je JEN takový, jak - ho v daný čas můžeme pochopit je hloupé. 18.9.2006 13:41  1569
al3xk prvnimu: inu, myslim, ze to je prave duvod, proc je mysql tak casto nasazovany prave v prostredi webhosingu... kazdej uzivatel si zvoli jaky kodovani potrebuje.

k tretimu: a to opet souvisi s webhostingem... ja mam vsude na strojich kde mam server pod svoji kontrolou vse v utf-8 a nemusim posilat nikde nic, neb server predpoklada defaultne na klientovi utf-8 presne tak jak si to predstavujes jako ideal...

tedy, shrnuto, mozna to z predchazejiciho nevyplynulo dost jasne: problem nastava pouze v pripadech ze tomu nekdo nerozumi a neumi si nastavit server (to neni problem mysql) a nebo v pripade, kdy je to hosting a tam naopak muze uzivatel vyuzivat tohoto jako vyhody, pokud se v tom trochu zorientuje - neni to vubec slozity.
al3x 18.9.2006 13:01  1568
fis [1558]: Jak rikam. Krasny teoreticky priklad, ale kolik tvych databazi v praxi pouziva vice aplikaci v ruznych kodovani?


Bredy [1567]: Pokud argumentujes modemy, tak jsi si asi dobre vedom, kolik spatnych a nestadardizovanych protokolu a technologii se v takhle low-endove elekotronicke komunikaci pouziva. Nechapu, proc bychom to meli delat takhle, protoze se to tak dela u modemu.


Abychom si rozumeli, ano najdete priklady, kdy se SET NAMES hodi. O tom nepochybuju. Ale je to potreba jen ve vyjimecnych pripadech. Nikoliv bezne pred kazdym spojenim, pokud db vyuziva skoro vzdy jedna aplikace a jedno kodovani, coz je - myslim - priklad vetsiny z vasich prohramu. Zvlast v klubu PHP.
bredy 18.9.2006 12:13  1567
AL3XSes do toho nějak zamotal. Vem si dobu modemů a přenosu dat po telefonů. Kolik vlastně existovalo různých protokolů? A jak pak si modemy domlouvali konečný protokol? Co je dřív, slepice nebo vejce?

Je jasné, že domluva protokolu musí být v nějakém protokolu. v MySQL to dělají tak, že pokud si nedomluvíš protokol, běží v ASCII. To úplně stačí, aby si klient s MySQL domluvil jiný protokol.

Pokud tedy mám klienta, který pracuje v UTF-16, bude se holt muset po spojení snížit na ASCII a zaslat pár příkazů v ASCII, aby serveru dal najevo, že komunikovat se bude v UTF-16.

Tohle je běžný postup, jak se to řeší. Chci-li od služby něco extra, musím tuto o to službu požádat nějakým standardním postupem, pak to teprv mohu začít využívat.

MySQL je služba poskytující své služby širokému okolí. Musí počítat s různými kombinacemi kódování dat, kódování přenosu a jiné. Pevné nastavení v databázi je tady nevýhodné, neflexibilní.
tvx tvx Myslet si, že svět je JEN takový, jak - ho v daný čas můžeme pochopit je hloupé. 18.9.2006 09:44  1566
pepaktak to teda fakt nelze... jak pisu zmenit v cely db collation ana shodny v ramci vsech tabulek, nejlip, nebo aspon vsechny klice co jsou proti sobe.
pepak pepak - Pepak.net 18.9.2006 09:09  1565
Tvx: Ten dotaz, co jsem uvedl, velmi presne odpovida situaci: Jedina tabulka, jediny WHERE, pouze ASCII-7bit znaky. S kodovanim to temer jiste nijak nesouvisi. S collation ano. Ze si to mam dat dohromady vim taky. Me zajima, jak to udelat co nejjednoduseji, idealne jen prikazem serveru "pro vsechno pouzij tuhle collation" (protoze konfiguraci serveru ovlivnit nemuzu vubec a konfiguraci databaze jen v omezene mire a nejakym rozsahlejsim zmenam struktury bych se rad vyhnul).
tvx tvx Myslet si, že svět je JEN takový, jak - ho v daný čas můžeme pochopit je hloupé. 18.9.2006 08:56  1564
tedy nejen do jednoho kodovani ale i collation
tvx tvx Myslet si, že svět je JEN takový, jak - ho v daný čas můžeme pochopit je hloupé. 18.9.2006 08:56  1563
nio, ja sem ti poradil aby sis dal dohromady db aby se ti vsechno srovnalo do jednoho kodovani, protoze pravdepodobne davas dotazy co spojujou dve tabulky s polozkou ktra ma v kazde tabulce jinou collation.
pepak pepak - Pepak.net 18.9.2006 08:39  1562
Tvx: Moment, tos me myslim nepochopil spravne: Ja nemam problem s tim, ze bych z databaze dostaval texty ve spatnem kodovani. Muj problem spociva v tom, ze dotaz typu SELECT * FROM Tabulka WHERE Jmeno='Pepak' spadne s chybou Illegal mix of collations. Tzn. zmena znakove sady mi IMHO nemuze pomoci, problem je v nejakem konfliktu mezi jazykem DB serveru, jazykem databaze, jazykem sloupecku a jazykem pripojeni. Reseni, jake bych si predstavoval, by byl nejaky prikaz, ktery bych poslal serveru hned po vybrani databaze a kterym bych serveru prikazal, aby ignoroval vsechny collations (resp. aby pouzil nejakou jednu konkretni, bez ohledu na to, o co si rika tabulka nebo jeji sloupecek).
tvx tvx Myslet si, že svět je JEN takový, jak - ho v daný čas můžeme pochopit je hloupé. 18.9.2006 08:28  1561
pepakvyrob si novy tabulky, dej je trteba cely do utf a data do nich nasypej.
tohle vypada tak, zes upgradoval dost zbesile bez nutnych uprav...
tvx tvx Myslet si, že svět je JEN takový, jak - ho v daný čas můžeme pochopit je hloupé. 18.9.2006 08:26  1560
nesmirne jsem to ocenit kdyz do db importuju data z ruznych mist, jenom nahodim 'set names' na spravny kodovani a uz to frci a nemusim se o nic starat, databaze si pritom jede v UTF-8...

Mnou vyzkousene nejlepsi pravidlo na zjisteni chyb v kodovani:
rozchodit phpmyadmina, spravne ho nastavit a pokud v nem je ulozeni a nasledne precteni vporadku, je problem nekde v aplikaci nebo do databaze importovanych datech...

pokud neco importujete do db z prikazovy radky nebo proste jinak nez phpmyadminem, nezapomenete jako prvni radek toho sql dumpu dat, opet 'set names' jinak vam to naladuje v defaultnim kodovani ktery ma mysql nastaveny a je mu burt jak jsou nastaveny v definici tabulky...
je to prave jedna z nejvtipnejsich chyb, kdy blbe ulozeny data se nekomu podari stejne blbe dostabvat z db ven a zbytek mu zlobi a on se pak domniva ze ma vse vporadku a hleda problem tam kde neni :c]
pepak pepak - Pepak.net 18.9.2006 06:53  1559
Kdyz uz tu vyplulo kodovani cestiny v databazi, tak se zeptam: Mam problem s konflikty mezi starou a postupne vznikajici databazi (mysleno databazovym souborem) a relativne aktualnim databazovym serverem. Databaze vznikala jeste v dobe MySQL 3, server se pak postupne aktualizoval a pridavaly se k nemu dalsi tabulky (nicmene stale pod dojmem toho, co bylo v MySQL 3, takze bez jakehokoliv sledovani jazyku, collations apod.). Ted uz se to ale zacina dostavat do stavu, ze to musi bezet na nejake starsi verzi MySQL, protoze na novejsi odmitaji fungovat porovnavani (chyby typu Illegal mix of collations (cp1250_general_ci,IMPLICIT) and (latin1_swedish_ci,COERCIBLE) for operation '='). Nejvic by me zajimalo, jak ten bordel dat nejak pokud mozno bezpracne do poradku, aby ta porovnani fungovala. Alternativne by mi stacilo, kdyby sly pro dane pripojeni k databazi ty ruzne collations vypnout a pouzivat proste binarni porovnani (pripadne case insensitive jen pro US-ASCII a ostatni binarne) - jak pisu, aplikace je historicky psana tak, ze na nejake jazyky v databazi uplne kasle.
fis fis 18.9.2006 03:58  1558
AL3X: Osobne musim souhlasit s huhem, ze to je velice dobra vec. Je sice skoda, ze se k tomu preslo takovym zpetne nekompatibilnim skokem, na druhou stranu je to dobry zpusob, jak lidi donutit skutecne tyto featury zacit vyuzivat a neprasit. Pokud potrebujes jakkoli pracovat s vice kodovanimi, zatim jsem nevidel lepsi zpusob, nez ze si reknes, co ma byt fyzicky v kazdem sloupecku databaze a co mas dostavat ty jako uzivatel a tyto dve veci se mohou zcela lisit. Pri pouziti jednoho add/edit/delete formulare je to asi k nicemu, ale pokud na te databazi bezi vice ruznych aplikaci, ktere ruzna kodovani skutecne vyuzivaji, je to jedina dobra cesta. Ne, opravdu vzdy nejde vsechny aplikace najednou preklopit do jednoho kodovani. Co je podle tebe korektni reseni, kdyz tohle je 'hack'? Ja si nic korektnejsiho moc nedokazu predstavit.
al3x 18.9.2006 02:27  1557
s/utf18/utf16/g
al3x 18.9.2006 02:26  1556
Jen bych jeste podotkl, ze kodovani je urcity druh metainformace, ktera by se mela dohodnout PRED spojenim, nikoliv v nem. Pokud vas klient bude pouzivat utf16 a rozhodne se to oznamit metodou SET NAMES, tak nema sanci, protoze utf18 se s ascii neshoduje ani v dolnich bytech, takze SET NAMES v utf16 precte databaze jako nejaky paskvil.

Tento argument stejne tak plati pro web. Kodovani se ma posilat v HTTP hlavicce PRED dokumentem, ktery v tom kodovani je. Nikoliv v samotnem dokumentu pres http-equiv, coz je jen hack pro autory, kteri nemaji moznost menit konfiguraci webserveru.

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

(c) 2001-2011 Lopuch.cz   
Kontakt