Hozzászólások
Sziasztok!
Nem akartam ezért új topickot nyitni, részben idevág, szóval íme a problémám:
breezy -ről dapper -re való dist-upgrade után gond van az adatbázisban tárolt (utf8 -as) ékezetekkel. my.cnf -ben [client] és [myqsld] esetén is a default charset utf8 -ra volt/van állítva, minden így lett létrehozva és feltöltve.
A jelenség most az, hogy konzolból (utf8 -as megjelenítéssel) teljesen jól látom és tudom kezelni az infókat, viszont a php által megjelenített oldalakon minden ékezet problémás.
apache2 + php4 + mysql4.1 a kombináció. content type, charset a html -ben és az apache kiküldött headerében is teljesen korrekt, a böngésző is beáll utf8 -ra, csak az ékezetek helyett vannak hülyeségek (sarkára állított négyszögben kérdőjel :) )
van valakinek valami ötlete, hogy mi lehet a gond?
ja, az adatbázist nem bántottam a korábbi változat óta de ledumpoltattam és ellenőriztem, rendben van, szóval nem az tolódott el az upgrade során...
előre is thx.
- A hozzászóláshoz be kell jelentkezni
$result = mysql_query("SET CHARACTER SET utf8");
Rogton connect utan php-ba.
- A hozzászóláshoz be kell jelentkezni
bakker... ok, így megy, köszi! elég triviális, de tulajdonképpen korábban miért nem volt rá szükség?
- A hozzászóláshoz be kell jelentkezni
Jo kerdes, ezt en is vegigszoptam, aztan mikor kiirattam a connection charakter setjet akkor lattam hogy az iso-8859-1 hiba van mindenhol minden utf8 ra allitva. Valoszinu a php mint kliens igy kuldi el alapban es ha jol vettem ki a mysql kliensenkent kulon kezeli.
- A hozzászóláshoz be kell jelentkezni
A PHP per pillanat nem nézi meg a konfig fájlt, hogy mi van beállítva, ezért a fordításkori beállítások érvényesülnek. Ez disztrib függő.
Erre akkor kellett rájöjjek, amikor a Gentoo-ban megváltoztatták a fordításkori alapértelmezettet latin1-ről utf8-ra. Tettem pár hamvába holt javaslatot, hogy maradjon a régi, de ők inkább csináltak egy patch-et a php-hoz, amivel az figyelembe veszi a mysql konfig beállításokat.
Ez a legutóbbi gentoo ebuild-ekben már benne van, de nem tudom mikor fog bekerülni upstream.
(továbbra is hagyományos latin1-gyel fordítom a mysql - csakazértis)
Üdv,
Dw.
"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."
- A hozzászóláshoz be kell jelentkezni
hát ez jópofa... végülis akkor sok értelme van a config file-nak. "a júzer had állítgassa, attól még úgy működök ahogy akarok" :))
na a lényeg az, hogy azért csak ki lehet kényszeríteni...
- A hozzászóláshoz be kell jelentkezni
Meg aztán hogy a jó büdös rohadt életbe nem támogatja a html_entity_decode az iso-8859-2-t? Mindenféle nyamvadt kiosztásokat támogat, de a latin2-t nem? Aszittem, hogy majd a PHP5-ben már benne lesz, de egy nagy szart.
Franc egye meg a PHP-t! Csak az a baj, hogy egy nagyon hatékony nyelv...
Üdv,
Dw.
"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."
- A hozzászóláshoz be kell jelentkezni
Rossz hir: meg a php6 cvs-ben sincs latin2... En mar komolyan nekialltam megnezni mibol allna portolni bele egy latin2-es tablat, de sajnos lofitty vagyok C-hez, s nem jutottam semmire.
- A hozzászóláshoz be kell jelentkezni
Gentoo ebuildeknel van egy latin1 use flag, ami ha meg van adva akkor default latin1(_swedish_ci)-t hasznal, ha viszont nincs akkor utf8(_general_ci)-t. Viszont ahhoz, hogy utf8_hungarian_ci-t tudj hasznalni, meg mindig szukseg van egy collation allitasra connect utan. Ugyan alaposan nem neztem meg a patcheket, de tenyleg van olyan, amivel figyelembe veszi a globalis my.cnf [client] szekciojat?!
///szerk:
Kozben megtalaltam: php5.1.4-mysql-readmycnf.patch nagyon komoly! Mar megerte megneznem ezt a topicot. :-)
- A hozzászóláshoz be kell jelentkezni
Én is hasonló problémával küzdök. Nekem nem muszáj konvertálni semmit, egyszerűen az lenne a kérdésem, hogy hogyan kell egy mysql szervert feltelepíteni és futtatni úgy, hogy minden magyar karaktert képes legyen kezelni?
Az UTF-8 is megoldás lenne, de hol kell ezt beállítani?
Paramétert kell adni a szervernek amikor elindul és úgy kell létrehozni az adatbázist vagy hogyan?
Köszi,
D.
- A hozzászóláshoz be kell jelentkezni
Boogie írt egy nagyon jó cikket erről kb. 1 hónapja, itt a hup-on a hírek közt megtaláljátok. Szerintem (remélem) az megválaszolja kérdéseiteket.
- A hozzászóláshoz be kell jelentkezni
Bingo!
http://weblabor.hu/cikkek/mysql50karakterkodolasok
- A hozzászóláshoz be kell jelentkezni
Udv!
A kovetkezo lenne a problemam. Egesz pontosan nem is problema csak engem zavar. Szoval, eddig nem igazan erdekel a mysql-ben levo adatok charsetje. Mostanban viszont eluralkodott rajtam a minden hasznalt dolog charsetjenek utf8 ra allitasa. Mondvan hogy utf8ba minden jol benne van ha minden azthasznalja nallam nem lesz gond. A kovetkezo lenne a kerdesem. Mivel viszonylag nagyobb adatbazisrendszerem van mar, ezt at tudom e "konvertalni" utf8ra, es a mysql-t hol es hogy tudom beallitani hogy utf8at hasznaljon mindenhol ezentul.
PhpMyAdminba ezt az infokat kaptam:
character set client utf8 latin1
character set connection latin2 latin1
character set database latin1 latin1
character set results utf8 latin1
character set server latin1 latin1
character set system utf8 utf8
character sets dir /usr/share/mysql/charsets/ /usr/share/mysql/charsets/
collation connection latin2_hungarian_ci latin1_swedish_ci
collation database latin1_swedish_ci latin1_swedish_ci
collation server latin1_swedish_ci latin1_swedish_ci
Szoval egyaltalan jo az ha en a mysql adatait ut8ba akarom tarolni? nincs vmi hatulutoje? Masodsorban a mar meglevo adatok nem fognak serulni, azaz pl weboldalak tartalma nem fog behanyni ettol a konverzitol? Harmadreszben pedig hogy hogy tudom ezeket a charset dolgokat atallitani, es mi kell a mar meglevo adatok atalakitasahoz. Koszonom elorre is a tanacsokat.
- A hozzászóláshoz be kell jelentkezni