hírek, közleményekdomaintárhelyakcióinkwebfejlesztésweblap-optimalizáláspartnerprogrampartnereinkszoftverekpályázatok
0 Ügyfeleink mondták:

"-"

FTP elérés élesítése:

FTP kapcsolódás engedélyezéshez adja meg az "FTP felhasználónév"-et:

Nyelv módosítása:

Slovenčina Slovenčina

Belépés, ügyfélkapu:

Elfelejtette a jelszavát?

Rendelés menete:

1. A kiválasztott szolgáltatásnál kattintson a "megrendelés"-re

2. Töltse ki a néhány lépésből álló megrendelőlapot

3. Kövesse a visszaigazoló e-mailben leírtakat

Letöltés:

TotalCommander (FTP kliens, a tárhelyre való fájlfeltöltéshez)

 

2009.07.02. 11:11 - Gyógyír karakterkódolási problémákra

hirek
Karakterkódolással, Unicode-dal és UTF-8-cal kapcsolatos tudnivalók..

Részelt Koblinger Egmont, "Unicode, UTF-8" c. írásából:

4. Dokumentumformátumok

[..]

4.2. E-mail

Egy e-mail fejlécébe ha belekukkantunk, ilyesmi sorokkal kell találkoznunk:

MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-2

Ezek határozzák meg a levél tartalmának típusát. A MIME-Version sor kötelező, azért mert csak. (Ennek hiányában sok levelező kliens figyelmen kívül hagyja a Content-Type értéket.) A Content-Type pedig jelenlegi példánkban azt mondja, hogy a levél tartalma egy Latin-2 kódolású sima szöveg. Hasonló szintaxissal az egyes csatolmányok típusa is megadható.

A fejléc sorok megadása különösen abban az esetben kritikus, amikor valaki nem levelezőprogramból, hanem például szkript segítségével küld leveleket. Nem elég, ha a küldő tudja, hogy ő milyen kódolással készítette el a fájlt, ezt az információt el kell juttatnia a címzetthez is, hiszen a címzett levelezőkliense nem gondolatolvasó.

Ettől teljesen függetlenül létezhet egy Content-Transfer-Encoding, ami egy feljebbi rétegként a bytesorozatot átalakítja valahogyan, annak érdekében, hogy hálózaton jobban továbbítható legyen ősrégi (például 7 bites) levelező szervereken át is. Ennek semmi köze nincs ahhoz, hogy a levél tartalma egyszerű szöveg-e, és ha igen, akkor milyen karakterkészletű. Talán jobb lett volna, ha nem is említem meg.

A fejléc soraiban, például tárgy és feladó, szintén megadhatók ékezetek, szintén a karakterkészlet megnevezésével együtt, bonyolult szintaxisban.

Sajnálatos módon a levelezők terén a legnagyobb a káosz, nagyon kevés levelezőprogram van, pláne a régebbiek és a terminálban futók közül, amelyek helyesen kezelik a karakterkészlet-információt. Mindennaposak az olyan levelezők, amelyek a bytesorozatot tartják meg változatlanul mondjuk a válaszolás során a beidézett részben, elfelejtve annak karakterkészletét, és a végén hozzábiggyesztik a konfigurációs fájlunkban megadott karakterkészletet. Az eredmény nyilván katasztrofális. Meg egyébként is, tegyük fel, hogy kapok egy levelet, Latin-1 kódolással, olasz balra dőlő ékezetes betűkkel, szeretnék rá válaszolni magyarul, de az én rendszerem meg Latin-2-vel dolgozik, mi legyen? Nyilván csak az UTF-8 jöhet szóba a kimenő levél karakterkészleteként. Csak sajnos kevés levelezőprogram van, amelyik ezt ilyen jól tudja.

Az e-mailekben a fejlécben megnevezett karakterkészleten kívül eső karakterek megadására nincsen lehetőség.

4.3. HTML

Na ez se kispálya.

A karakterkészlet információt kétféleképpen is meg lehet adni.

Az egyik lehetőség a HTTP fejlécben az e-mail esettel azonos módon a Content-Type használata. Sajnos ez az adat a kommunikáció során viszonylag el van rejtve a felhasználó elől, elég nehéz kideríteni, ezt még az előtt egyezteti a kliens és a szerver, hogy a honlap tényleges tartalmát (tipikusan a html fájlt) elkezdené küldeni. Lássunk egy példát, szeretném kideríteni a képzeletbeli http://www.foo.bar/bigyo.html oldal karakterkészletét. Kiadom a

telnet www.foo.bar 80

parancsot (a 80-as az alapértelmezett http port, telnet helyett pedig lehetne netcat parancs is), majd begépelem ezt:

GET /bigyo.html HTTP/1.1
Host: www.foo.bar

Itt megadhatnék egyéb adatokat is, de nem teszem, és egy újabb Enterrel (vagyis üres sor bevitelével) tudatom, hogy készen vagyok. Erre a szerver valami ilyesmit válaszol (kivonat):

HTTP/1.1 200 OK
Content-Type: text/html

majd ő is egy üres sort követően közli a tényleges oldal tartalmát. De az is lehet, hogy ilyesmit válaszolt:

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8

Hát íme. Vagy mondott karakterkészletet, vagy nem.

Ha mi készítjük a honlapot, és nem tetszik az adott érték, akkor, amennyiben Apache web szerver fut Unix rendszeren, a honlap mellett helyezzünk el egy .htaccess nevű fájlt ilyesmi tartalommal:

AddDefaultCharset UTF-8

vagy

AddCharset UTF-8 .html .txt

és próbáljuk újra. Vagy bejött, vagy nem. A fenti példa azt mondja, hogy minden fájl, vagy csak a html és txt fájlok karakterkészleteként UTF-8-at küldjön ki a szerver. De sajnos elképzelhető, hogy a rendszergazda nem engedélyezi, hogy felülbíráljuk a rendszer alapértelmezett értékét. Ez esetben sajnos nincsen lehetőségünk arra, hogy honlapunk mellé korrektül megmondjuk, milyen karakterkészlettel értelmezendő, tehát rugdossuk a rendszergazdát.

Ha kézzel írunk cgi szkriptet, akkor ott nekünk kell a fejléc sorokat is kiíratnunk, így annak helyes beállítása nem jelenthet gondot.

PHP szkriptünket kezdjük valahogy így:

header("Content-Type: text/html; charset=UTF-8");
?>

A karakterkészlet HTTP fejlécben történő megnevezésének előnye, hogy nemcsak html, hanem sima szöveg esetén is használható. Hátránya, hogy a honlap készítője részéről nehézkes a beállítása, és ha valaki tükrözi vagy diszkre letölti az oldalt és onnan nézi meg, akkor elvész ez az információ.

A karakterkészlet megnevezésére a másik lehetséges hely már a html fájlon belül van, így azt látjuk, amikor készítjük a fájlt. A szekción belül elhelyezhetünk egy ilyen sort is:



Ez azt jelenti, hogy vedd úgy, mintha a HTTP fejlécben ezt a Content-Type sort kaptad volna.

Ennek a megközelítésnek hátránya, hogy csak html esetén használható, előnye, hogy a honlap tükrözése, letöltése során is megmarad.

Na és akkor ehhez képest most jön a hatalmas idétlenség. Egyrészt a legtöbb webszerver alapból megnevezi a Latin-1 karakterkészletet (ugyan miért ezt?), esetleg ha jobb formában van, akkor az UTF-8-at, de megnevez valamit, ritka, amelyik nem. Másrészt ha mindkét lehetséges helyen szerepel karakterkészlet-információ, akkor a HTTP fejlécben lévő számít, a html oldal elemét hagyják figyelmen kívül a böngészők. Ez szerintem egy hatalmas tervezési hiba.

Az opera böngésző, amennyiben az oldal kis fülecskéje fölé visszük az egeret, buboréksúgóban megjeleníti az oldal értelmezéséhez használt karakterkészletet.

Szerencsére html fájlban megvan a lehetőség arra, hogy a használt karakterkészletbe nem illeszkedő karaktert is megnevezzünk. Sok karakternek létezik &valami; típusú neve, de Unicode értéket is írhatunk, &#dec; vagy hex; alakban, például ű = ű. Így elvileg akár az összes ékezetes betűt is ábrázolhatjuk. Előny, hogy ekkor nem számít, mit kavarunk a karakterkészlettel, hátrány viszont a komoly méretnövekedés, valamint hogy webböngészőn kívül gyakorlatilag olvashatatlan a fájl, a TeX ilyen id'etlen 'ekezetei p'eld'aul igaz'an kisp'aly'asak ehhez az őrültséghez képest.

--

A teljes dokumentum a következő linken olvasható: http://www.cs.bme.hu/~egmont/utf8/

Fontos információ:

A mbyte.hu tárhelyszolgáltatások (mysql, apache) alapértelemett karakterkódolása Latin 2, tehát a html <header></header> részben az alábbi sornak kell lennie:

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-2" />

MySQL esetén, az egyik lehetőség a hibásan megjelenő és mentésre kerülő karakterek elkerülésére, az ha adatbáziskapcsolódás után közvetlenül beszúrjuk a mysql_query("SET NAMES latin2"); lekérdezést.

Koblinger Egmont

domain- és tárhelyszolgáltatások

Oldalunk megfelel a XHTML 1.0 szabványnak. Firefox.hu
Compute Magyarország Kft. PHoliPortal engine
SpamPoison Support GoPHP5.org