ugrás a tartalomhoz

néha utf-8 néha nem..

batabub · 2007. Aug. 26. (V), 04.15
üdv, olyan problémám lenne, hogy az oldalamon be van állítva a charset utf-8-ra, minden tartalma utf-8-ba van elmentve. Szépen meg is jelennek, viszont egyszercsak gondol egyet és valamelyik aloldal ékezetei helyett az opera kérdőjelet, az ie pedig a furcsa karaktereit írja.. Ha nyomok egy frissítést minden jó újra pár kattintás után megin eljátsza ezt egy másik aloldallal. Az oldal google maps apit, mootools-t, illetve phorum5-öt használ, aminek a magyar fordítása is utf-8-ban van.
Ezt az egészet csak az internetes tárhelyén játsza el, saját gépről, apacheról semmi gond.. Tárhelyen változtatni nem tudok, és muszáj azt használnom.
Végső esetben átrakom a kódolást iso-8859-2-re, de nincs sok kedvem minden egyes fájlt átszerkeszteni miatta.. egyéb ötlet?
‹ prototype AJAX request timeout Egész oldal villog IE alatt link hover eseményre ›
 ■
1

néha utf-8 néha nem..

lacó · 2007. Aug. 26. (V), 10.46
Nem világos, hol van beállítva a charset-ed?
Ha eddig html-ben volt, és php-t is használsz, tedd be a html elé a php elejére:
header("Content-Type: text/html; charset=UTF-8");
2

ehh..

batabub · 2007. Aug. 27. (H), 07.27
hihetlen, hogy csak ennyi kellett.. működik is.. meta contentbe volt csak beállítva eddig.
kössz szépen! :)
3

mégsem

batabub · 2007. Szep. 7. (P), 03.46
ugyan ritkább lett a jelenség, de néha még ígyis előjön :(
4

példa?

TeeCee · 2007. Szep. 7. (P), 10.27
A latin2-re való visszalépést nem javaslom, több problémád lenne vele, mint ezt megoldani.
A header()-kiadása segíteni szokott a problémán, az a legutolsó, ami kimegy, tehát ha csak a PHP-ban, vagy apache-konfigban nincs előtte ilyesmi, akkor jónak kellene lennie. (moz fx alatt le tudod ellenőrizni a webdeveloper toolbarral pl: Information/View Response headers)
Az nem lehet, hogy nem utf8-as karakterkészlettel pakoltál bele valamit és azt utf8 alatt nem jól néz ki? Ez is szokásos hiba. Adatbázisban táblák milyen tulajdonságal rendelkeznek? Az adatbázissal való kapcsolat során milyen kódolást használsz, nem konvertálsz-e bevitelkor, stbstb...

Üdv: TeeCee :o)
5

hát..

batabub · 2007. Szep. 9. (V), 04.13
Webdeveloper-el megnéztem Content-Type: text/html; charset=UTF-8-at ír miközben az oldal hibásan jön be, meg akkor is ha jól. Az adatbázisban a táblák utf8_hungarian_ci kódolásban vannak. Igazából én még nem is használok semmit adatbázisból csak a phorum5, hogy az mit csinál adatokkal azt nem tudom. A nyelvi fájla is utf8-as kódolásban van..
6

hmm...

TeeCee · 2007. Szep. 9. (V), 07.33
Ami hibásan jön adat, az mind adatbázisból jön? Mert ez lehetne támpont...
Ha igen:
- Az űrlapoknak nincs külön, más karaktertkódolása, amivel az adat bemegy? (accept-charset)
- Az adatbáiznak nincs más alapértelmezett kódolása? (default emlékeim szerint a latin1, ezt lehet a SET NAMES-sel módosítani/beállítani minden kapcsolat-létrehozás után)
- A tábláknál utf8_hungarian_ci, az jó, de a mezőknek külön meg lehet adni mást is, esetleg még abba kukk bele. Jó adatb van a táblában? mert ha eleve rosz megy bele, vagy rosszul, akkor ne is várj jó kimenetet...
7

hmhmhm

batabub · 2007. Szep. 9. (V), 20.46
amióta beraktam a header("Content-Type: text/html; charset=UTF-8"); -at azóta úgy veszem észre csak a fórumból jövő tartalom jelenik meg rosszul, viszont olyan része is rosszul jelenik meg mikor nem olvas semmit ki az adatbázisból mint pl egy ürlap, amit csak simán a magyar fordítás fájljából. Amúgy az adatbázis mezői is mind utf8_hungarian_ci-ben vannak, az alapértelmezett kódolást pedig most átraktam utf8_hungarian_ci-re. Űrlapoknál meg nincsen megadva külön karakterkódolás :(
8

példa?

TeeCee · 2007. Szep. 9. (V), 22.30
Jól jönne mostmár egy példa. Elmentett hibás oldal, ha az oldal nem elérhető...
Nem lehet, hogy a magyar fordítás fájlja véletlen latin1, vagy latin2-es, míg a teljes oldal pedig utf8as?
Esetleg pont fordítva: az oldal végig latin2-es, csak a böngészőbe való kiküldés előtt kerül rá egy utf8-konverzió?

az alapértelmezett kódolást pedig most átraktam utf8_hungarian_ci

Ez mit takar? Úgy tudom, hogy MySQL-szinten az alapértelmezést csak újrafordításnál lehet megadni (vagy bubu vagyok, és nem vettem észre, hogy hol ---> akkor PLZ mondd meg). Ha eddig a mező latin2-esen volt, akkor meg hiába állítottad MOST át utf8-ra, mert bekerüléskor máshogy kezelte...
10

hiba pl.

batabub · 2007. Szep. 10. (H), 01.14
itt a hiba:
http://mosonszolnok.hu/hiba.htm

normálisan meg itt lenne
http://mosonszolnok.hu/index2.php?oldal=legifotok#mosonszolnokrol

phpmyadminban a tevékenységek/egybevetést raktam csak át utf8-ra az mit csinál ?? a mezők utf8_hungarian_ci-n voltak eredetileg is.
11

ez bizony iso-8859-2

zila · 2007. Szep. 10. (H), 08.42
A belinkelt oldal kódolása nem utf-8. Nem elég a html-ben jelezni a kódolást (<meta http-equiv="content-type" content="text/html; charset=utf-8">), a lapot is ezzel a kódolással kell kiküldeni: header("Content-type: text/html; charset=utf-8"); minden egyéb kimenet _előtt_ és természetesen a php file-nak és a template-nek is utf-8 kódolású file-nak _kell_ lennie.

szerk: a http://mosonszolnok.hu/hiba.htm oldal rosszul jön, de a http://mosonszolnok.hu/index2.php?oldal=legifotok#mosonszolnokrol már jól. Az apache nem küld véletlenül default charset-et? Ha igen, akkor erről le kéne beszélni...
12

hát..

batabub · 2007. Szep. 10. (H), 16.32
Az index2.php legelső sora az hogy: header("Content-Type: text/html; charset=UTF-8");
A Response Headers azt írja, hogy: Content-Type: text/html; charset=UTF-8-at ír ha hibás ha nem.
Azt hol kell megnéznem hogy küld-e deafault charsetet? Response Headers-be nem.
Minden utf-8 kódolású elvileg.
13

fura

zila · 2007. Szep. 10. (H), 17.15
A következő történik: kinyitom az oldalot firefox-ban: rosszak az ékezetek. Megnyitom a live http headers-t, újratöltöm az oldalt és minden ékezet jól jelenik meg :(

A default charset az a httpd.conf-ban van elvileg, ha darabolt a config file akkor lehet, hogy máshol van, az biztos, hogy valahol az apache config file-ban szokott lenni egy AddDefaultCharset sor, ha be van állítva ez a dolog, de nem ez lesz a baj mégsem.

Ötletelek:
Nem használsz valami template rendszert, smarty-t pl? Annak a szerveroldali lefordított template-jei szoktak néha viccelődni, a templates_c könyvtár tartalmát szoktam olyankor törölni.
Esetleg az apache van proxy-zásra állítva (másik webszerver szolgálja ki az oldalt, a külső apache csak átpasszolja a lekéréseket)?

Az a fura, hogy egy sima refresh megoldja a gondot (Orvos, Fórum és légifotók oldalakon találkoztam az ékezets gonddal)...
14

poén az egész

batabub · 2007. Szep. 10. (H), 19.32
Sajnos az apache confighoz nem férek hozzá, csak ftp-n a kis tárhelyhez. Saját szerveren működik rendesen, semmi gond vele.. Nem használok smarty-t meg semmi template rendszert.
9

tévedtem

batabub · 2007. Szep. 10. (H), 01.05
mégse csak fórumot jeleníti meg rosszul, olyan aloldalt is ahol csak pár kép van egymás alatt és hozzá se ér adatbázishoz, php-hez is csak annyit hogy include-olja az aloldalt.. olyankor meg csak a mootools.js-t tölti be a menühöz ..
15

érdekes

batabub · 2007. Szep. 11. (K), 17.20
Csináltam most egy olyat, hogy: http://www.mosonszolnok.hu/ekezetek.php amin csak eza pár sor ékezet van minden javascript nélkül, php is csak annyi, hogy a headert beállítja, és még ígyis rosszul adja be néha.. :(( szerver beállítási hiba ez, vagy mi lehet ??
16

Proxy, cache?

Heilig Szabolcs · 2007. Szep. 11. (K), 17.30
Helló!
Az nem lehet, hogy a probléma valójában megoldódott a php header() hívással, csak közben a hibás oldalak jól bették magukat a böngésződ gyorstárába? Esetleg ugyanez a proxynál, ha amögül webezel?
17

cache ürítés stb

gex · 2007. Szep. 11. (K), 17.44
én felváltva frissítek és ürítek cache-t (egy mai blogmarkban talált Extended Cookie Manager kiterjesztéssel), és hol jó hol nem. ez az utolsó link kb 50 frissítésig jó volt, nem is értettem hol a probléma, aztán hirtelen tényleg rossz volt a kódolás.
18

Hol hasal el?

janoszen · 2007. Szep. 11. (K), 19.09
Mi lenne, ha debugolnád a dolgot? Mármint hogy mi megy ki kimenetre echo-zás helyett írd fájlba és akkor azonnal tudod, mi a dörgés. Ha meg programhiba, akkor izzíts be egy debuggert és nézz a körmére a PHP-nak.
22

php nélkül is rossz

batabub · 2007. Szep. 12. (Sze), 06.03
php használata nélkül is eljátsza ezt .. :(
23

itt az idő,

zila · 2007. Szep. 12. (Sze), 08.52
hogy felvedd a kapcsolatot a szerver rendszergazdájával...
21

sajnos nem

batabub · 2007. Szep. 12. (Sze), 06.00
header javítás után, teljesen máshol lévő embereknek is rosszul jön néha :(
19

Halkan megjegyzem...

thomasrc · 2007. Szep. 11. (K), 20.27
...hogy nálam jól jelennek meg az ékezetek az említett oldalon ( akárhányszor frissítek, nálam mindig jó ). Hogy tanusítsam az állításom ITT egy kép róla.
20

nálam nem...

TeeCee · 2007. Szep. 11. (K), 20.35
...és én nem néztem ezt az oldalt fejlesztés közben, tehát nem lehet, hogy véletlen még a fejlesztés idejéről maradt volna valami rossz kódolás...
Előjött nálam is a hiba, nem frissítgettem orrba-szájba, hanem kattogtam és olvastam

Lehet, hogy ez egy szándékosan randomizált hiba, mint új marketingfogás? :D

Úgy emléxem, egy oldal frissítgetésével nekem se jött elő, csak ha tényleg 'használtam az oldalt', nem tudom, ez infó-e...
Az UTF8-as header végig megvolt a firefox szerint...
24

hehe

batabub · 2007. Szep. 13. (Cs), 04.43
igaz, oldalletöltés megnőtt :))
sajnos hiba megmaradt.. na írtam rendszergazdának, majd csak lesz valami..

Mindenesetre köszönöm mindenkinek a segítséget!
25

hmhmhm

batabub · 2007. Szep. 16. (V), 17.24
Hát a rendszergazda aztmondja nálam van a hiba.. hogy valszeg nem jó kódolással mentem az oldalakat. Notepad++ -t használtam eddig (formátum / utf-8 kódolás). Mivel érdemes akkor próbálkozni ?
26

utf-8 bom nélkül

cSuwwi · 2007. Szep. 16. (V), 20.15
Én is notepad++-al kódolok, gondom eddig nem volt, jól ment a program.
Nekem ANSI + UTF-8 kódolás BOM nélkül formátumban ment, sima UTF-8-al hibát jelez a php. Próbáld meg, hátha...
27

vicces

gex · 2007. Szep. 16. (V), 21.29
ott az ekezetek.php, ellenőrizze le azon a rendszergazdád.
28

végre

batabub · 2007. Okt. 1. (H), 21.36
Na végülis találtam egy megoldást.. megfigyeltem, hogy a notepad++ meg a többi program is minden utf-8-ba mentett fájl elejére berak 3 láthatatlan karaktert, legalábbis windowsba én nem láttam, csak mikor véletlenül linuxba megnéztem az egyik php fájlt. Ha kitörlöm ezt a 3 karaktert megszünik a jelenség, hogy néha rosszul jön be oldal és minden tökéletes.
Szóval most mi aza 3 karakter gondolom nem poénból van ott.. az jelzi az utf-8-at?? De akkor meg, hogy működik ha kitörlöm onnét?
29

BOM

Charybdis · 2007. Okt. 1. (H), 22.04
Ohhh igen a jó öreg BOM.

Valahogy állítsd be a szövegszerkesztőbe, hogy ne használja a BOM-ot. A létező fájlokból pedig szedd ki mindet.

Ezzel én is szívtam egyszer. Volt egy ennyi PHP-m:
<?php
header("Location: htétép://valami.hu");
?>
És nem működött az istenért sem! Azt mondta, hogy a header már el lett küldve, ezért nem használható a header függvény.

A megoldás az volt, hogy BOM-mal kezdődött a php fájl, azt kiszedtem és megjavult, noha a forráskódban semmit sem változatttam.
30

notepad++

gex · 2007. Okt. 1. (H), 23.14
megoldás notepad++-ban: formátum > utf-8 kódolás (bom nélkül)
(ha nem tudod kiválasztani, akkor valószínűleg utf-8-ra van állítva, úgyhogy előbb vissza ansira majd utf-8 bom nélkülre)
31

ahh

batabub · 2007. Okt. 3. (Sze), 15.54
na igen, pont úgy jártam hogy a bom nélküli utf-8 szürke volt.. ahh pedig cSuwwi már 2hete megírta a jó megoldást..
szóval kössz mindenkinek mégegyszer a segítséget..