ugrás a tartalomhoz

Cache fájlok létrehozása UTF-8 esetén

Thom · 2008. Júl. 29. (K), 10.28
Sziasztok,
A teljes rendszerem UTF-8 kódolásra lett átállítva, így az összes működő fájlt ilyen módon létrehozott fájlokkal cseréltem le.
Problémám van a PHP-ből létrehozott cache fájlok kódolásának beállításával. Ezek (gondolom) a szerver által meghatározott ISO-8859-1 kódolással jönnek létre.
Konkrétan többféle RSS tartalmat tárolok, amik vegyesen ISO és UTF betűkészlettel érkeznek. Hogy milyen RSS-eket, az admin felületről adható meg, utána a cache fájl automatikusan jön létre. Az oldalon a kiolvasott tartalmak egyes esetekben hibás betűkkel jelennek meg.
Ha beíráskor minden tartalmat módosítok az mb_convert_encoding() -al UTF-8 ra, akkor kiolvasáskor hibásan jelenik meg (mert maga a cache fájl nem UTF-re lett létrehozva). Ha csak kiolvasáskor módosítok, akkor jónak tűnik, de biztos van jobb megoldás - eleve a létrehozott fájl karakterkódolását megadni. Abba aztán mindent UTF-8 -al lehetne belementeni.

Arra viszont nem ismerek lehetőséget, amivel a touch() után a létrehozott fájl kar.kódolását be tudnám állítani. Van ilyen lehetőség, vagy hogyan szokás ezt megoldani? Esetleg buherálni kell, nincs más megoldás?

Köszi előre is.
 
1

Bináris

janoszen · 2008. Júl. 29. (K), 15.00
Én a helyedben a cacheket is UTF-8-ban tárolnám, mert ISO-ből UTF-8-ba lehet veszteségmentesen tömöríteni, fordítva pedig nem. Én pl a mindenféle visszafeleékezetes ő betűkkel szívtam sokat, amíg áttértem globálisan UTF-8-ra. Persze, nem tudom, mennyire megvalósítható ez.
2

touch() és charset

Thom · 2008. Júl. 29. (K), 15.28
Igen, valóban ez a cél.
A kérdés, hogy ha a PHP touch() fv-el hozok létre egy fájlt, hol tudom megadni, hogy az utf8 formában tárolja a tartalmát?
Az editoromban is be lehet állítani, hogy kogyan mentse el az új fájlokat, ez most utf8 -ra van állítva (amíg az átálláskor minden létező fájlt nem cseréltem ki újra, addig egy csomó krix-krax volt az oldalon). Tehát a szöveges fájlok létrehozásukkor megjegyzik, hogy milyen kódolási beállítással jöttek létre. Nyilván a szerveren PHP-val létrehozott fájlok is megjegyeznek ilyen beállítást - és gondolom, ez a nyilván a defaultnak tekintett ISO-8859-1. Na ezt akarom én létrehozáskor futásidőben módosítani.
Hozzáteszem, hogy a fájlkezelésnek ez a része nem egészen tiszta bennem - azért is kérdezek.

Amit eddig tapasztaltam, hogy ha előre kézzel létrehozom a cache fájlt és beleírom az utf8 kódolású szöveget, akkor más lesz az eredmény, mint ha a PHP hozza azt létre. Nekem pedig PHP-val kellene megoldani a fájl létrehozást is.
3

Sehol

janoszen · 2008. Júl. 29. (K), 16.26
Sehol nem tudod állítani. A fájlok működése bináris, tehát amit bele írsz és amit kiolvasol, az bináris adat, az editortól függ, hogyan értelmezi. Egyébként arra figyelj, hogy ne legyenek benne BOM adatok.

Egyébiránt kicsit kifejthetnéd, mennyiben más a probléma és hogy hol akadtál el a probléma megoldásában (ami egyébként nem is egészen tiszta számomra).
4

mb_string win/linux-nál másképp működik

Thom · 2008. Júl. 29. (K), 18.06
Közben kialakult a dolog. Ez volt az elv:
- lekérem a távoli fájlt (rss vagy html), beolvasom egy változóba
- mb_convert_encoding() -al átalakítom utf8-ra a bejövő tartalmat,
- mintát illesztek rá és tömbbe szedem a szükséges dolgokat: blokk címe, szövege, tovább-link,
- a tömböt tetszés szerint beírom a cache fájlba.
Később kiolvasásnál már utf8-as tartalmat kell találnom a cache fájlban.

A problémát valószínű az okozta, hogy az itthoni win* gépen hoztam össze és próbálgattam a PHP dolgot, a karakterkódolás átalakítók viszont (mb_string, iconv) nem ugyanúgy működnek win és linux OS alatt. Amikor feltettem a tárhelyre, egyből megjavult :-)

Közben jutott eszembe, hogy a sortörést valóban másképp kezeli a win és unix OS (\r\n ill. \n), valószínű ezt lehet az editorban állítani. Vagy ki tudja oo)
5

Editor...

janoszen · 2008. Júl. 29. (K), 21.46
Lehet hülye kérdés, de egyáltalán miért kényszerülsz editort használni automatikusan generáljt fájlokon? Egyébként a Winen szeretnél UTF8 fájlokat nézegetni, akkor szvsz a Notepad++ a legalkalmasabb rá, mert az tud BOM nélküli UTF-8 fájlokat írni/olvasni.
6

Editplus

Thom · 2008. Júl. 29. (K), 23.37
A cache fájlokat üzemszerűen természetesen PHP-ból hozom létre, nem előzetesen editorral. Csak a megoldás keresése során tettem egy próbát. A korábban is használt RSS parser-omat igazítottam az UTF8 kezeléséhez + akarok egy jópár html híroldalból infókat kiszedni mintaillesztéssel (a céloldalak gazdái valószínű még nem hallottak az RSS-ről ;-) Közben futottam ebbe a látszólagos problémába.

Editplus -t használok régóta, részemről meg vagyok elégedve vele. UTF8-at ez is tud. (egyébként nekem új fogalom: a BOM mi fán terem?)
7

Google?

janoszen · 2008. Júl. 30. (Sze), 00.19
google://bom harmadik entry. :) Egyébként nekem utóbbi időben egyáltalán nem voltak karakterkódolási gondjaim, mindenhol UTF-8-at használok. Igaz, talán a sorrendezés meg egyéb problémák kissé árnyalják a képet, de mindent átkódolva UTF-8-cá, talán minimalizálhatóak a problémák. Én ilyen célra egyébként a recode nevü utilityt szoktam használni command lineból és ha jól emlékszem, az iconv tett nagyon jó szolgálatot PHP alatt... érdemes (szerintem) a tesztkörnyezetedet az éles pontos másaként berendezni, pont az ilyen problémák elkerülésére.