PHP - diskusní klub na Lopuchu

Registrace nového uživatele

Návod

Kluby

Archív Lopuchu

Lopuch.cz

Nudou jsi opuch?
Navštiv Lopuch!

Lopuch.cz

	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: www.php.net - domovská stránka PHP www.kosek.cz - spousta tutorialu pro PHP v češtině

Nastavení klubu

Nastavení práv

Homepage

Anketa

[ 1845 ]

<Novější <<<Nejnovější Nejstarší>>> Starší>


	pepak - Pepak.net 18.9.2006 07: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 Myslet si, že svět je JEN takový, jak - ho v daný čas můžeme pochopit je hloupé. 18.9.2006 07: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 Myslet si, že svět je JEN takový, jak - ho v daný čas můžeme pochopit je hloupé. 18.9.2006 07: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.net 18.9.2006 05: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 18.9.2006 02: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.


	18.9.2006 01:27	1557
	s/utf18/utf16/g


	18.9.2006 01: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.


	18.9.2006 01:19	1555
	Tomas Kyte: "Pristupovat k databazi jako k cerne skrince, psat dotazy co nejobecneji, aby prosly na co nejvetsim druhu SRBD, to je nejvetsi chyba, ktere se muzeme u prace s databazi dopustit. Temer vzdy je predem jasne, na jake databazi, na jake implemetaci a dokonce na jake jeji verzi a konfiguraci aplikace pobezi. Psanim specializovaneho kodu pro tuto ziskame rychlejsi, prehlednejsi, lehci a efektivnejsi aplikace, nez kdyz budeme psat obecny kod pro pripad, ze bychom se nekdy rozhodli databazi vymenit za jinou, ke kteremu stejne v drtive vetsine pripadu nedojde." Vase argumenty jsou sice po teoreticke rovine korektni, ale zkuste si udelat statistiku, kolik _ruznych_ kodovani pozaduji pripojeni, ktere se k vasemu serveru hlasi? Tipl bych, ze krom zlomku testovacich a ladicich dotazu, bude naprosta vetsina nastavovat vzdy jedno. Stejny argument (jako ten vas) by se dal pouzit i mnohem obecneji. To pripojeni vlastne vubec nemusi vedet, ze na druhe strane bezi zrovna MySQL. Nebylo by korektni pouzivat jen kostrukty SQL92? Bylo by to tak prece mnohem flexibilnejsi... Uvaha hezka, ale z pohledu sw vyvoje je to temer vzdy blbost.


	huh 18.9.2006 00:44	1554
	AL3X [1550]: Nevim, podle me je mnohem lepsi rict na zacatku komunikace databazi jake chci kodovani. Je to mnohem flexibilnejsi, mohu menit kodovani v db aniz bych se musel byt jen dotknout aplikace. Stejne tak pokud provozuji ruzne aplikace, ktere treba pouzivaji ruzna kodovani. Cili ja to nevidim jako hack, ale naopak jako naprosto idealni reseni, ke kteremu se po letech dospelo. Nevidim u nej jedinou nevyhodu.


	mpts Je to jinak, ba přesně naopak! 18.9.2006 00:38	1553
	AL3X: Já nevím, mně přijde celkem normální si na začátku spojení nastavit takové věci jako znakovou sadu apod., zkrátka domluvit se se serverem na tom, jak si budeme povídat. On přece vůbec nemusí tušit, z jakého prostředí se k němu hlásím atp.


	knedle online - Krabice živých 18.9.2006 00:24	1552
	huh [1549]: jak rikam - tohle nemohlo vypadnou z me hlavy - asi to byl manual ci jina chytra knizka/stranka to ze je set names ekvivalent sem netusil ->> a zase su chytrejsi


	Straka82 17.9.2006 23:33	1551
	pro tvxOno mi to dela doma, nikde to zatim nemam. No budu doufat, ze az to nekam dam, tak ze to bude fungovat normalne :-)


	17.9.2006 23:13	1550
	huh [1548]: Ja netvrdim, ze to tak v MySQL neni. Jen rikam, ze je dobre zduraznit, ze toto je spis "hack", ktery pomaha obejit spatne nastaveni serveru, nikoliv idealni reseni.


	huh 17.9.2006 23:04	1549
	knedle [1546]: SET NAMES je ekvivalent presne pro tuto trojici prikazu. Ale kdyz nekdo touzi posilat misto jednoho prikazu tri...


	huh 17.9.2006 23:02	1548
	AL3X [1544]: Ale presne takhle to v MySQL je.

[ 1845 ]

<Novější <<<Nejnovější Nejstarší>>> Starší>


(c) 2001-2011 Lopuch.cz Kontakt