Windows es az utf8

 ( Anonymous | 2006. november 20., hétfő - 9:59 )

Kihasznalom ha mar win forum. :)

Kerdesem: windows miota tamogatja az utf8-at bongeszo es mail kliens szerint?
(at szeretnek terni ra, de fingom nincs milyen problemakat okozhatok egy windows-os embernek.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

bongeszo tekinteteben nem tudom mire gondolsz. Weblapot gyartasz? Ha igen akkor nyugodtam mehet az utf8.
Mailnel picit cinkes, mert a default beallitas outlookban (es expressben) az LATIN1 (lehet hogy a magyar nyelvu windowsban LATIN2) es az emberek nem allitjak at. Ha mas mail klienst hasznalnak, akkor altalaban rendben vagy mert a legtobb az Automata felismeresen van.

win98,2000,NT,ME,XP-re is igaz ez az allitas?
outlook es az utf8 haverok?

webes mail rendszer es ERP miatt kerdezem.
amugy kesz az atallas (lefuttattam azt a scriptet amit egy hetig irtam es tezsteltem).
remelem a wines kollegaknak (otthon sokan wint hasznalnak) nem lesz gondjuk. mondjuk eddig meg senki sem sikitott :)

Ha arra gondolsz, hogy pl. a Firefox képes-e megjeleníteni Win98-n UTF-8-s kódolású oldalakat, a válasz igen. Elmúlt (tan)évben még sokat használtam suliban W98-n Firefoxot. Ment mindenhol. Mint lentebb írták, igazából böngésző/mailprogram függő.

Egyébként W98/NT már nem valami elterjedt.

erre gondolok. ie-vel miujsag?

IE6 simán megjeleníti tök jól az utf8-as oldalakat, valszeg régebbi IE-k is. Ne feledjük, hogy az UTF-8 immár több mint 14 éves, a Unicode nyilván ennél is öregebb, és a Windows már a 95 környékén intenzíven kezdett Unicode-ozni (jó, az UTF-16, de akkor is...). Nem az a meglepő és különös, ha valami támogatja, hanem az a szégyen, ha valami nem (és az is, hogy a Linuxok ilyen későn kezdtek el rákapni).

A levelező progikról nincs semmi tapasztalatom, de itt végülis a kliensedet valszeg be tudod állítani, hogy ha latin2-be belefér a levél, akkor abba konvertálva küldje el. Ezzel elősegíted a kompatibilitást a régebbi levelezőkkel. Én kb. 1 éve így használom a rendszert: minden mindenhol UTF-8, kivéve a küldött levelek, mert azok latin2-k amikor csak lehet (szívás is grepelni a sent-mail mappában). Persze ha nem intelligens progival küldesz levelet, hanem pl. egyszerű szkripttel, akkor ezt nem olyan egyszerű megoldani (bár ott sem reménytelenül nehéz, inkább csak nincs kedve az embernek).

Én nem annyira a Windowstól félnék, sokkal inkább a webes levelezőktől. Gmail oké, yahoo.com-ról ismerősömtől olyan leveleket kapok, amikben totálkárosak az ékezetek, így csak sejtem hogy ő az UTF8-at nem tudná szerintem elolvasni, és van egy csomó egyéb (hotmail, freemail, citrom, vip stb.) amikről semmi információm nincs. Ha vkinek van kedve ezekre zsinórban regisztrálni, kipróbálni és megírni tapasztalatait, azt örömmel venném :-)) Kíváncsi vagyok, hogy helyesen kódolja-e a küldött levelekben az ő, ű, illetve egyéb extrémebb (latin1-en és latin2-n kívüli) karaktereket, valamint helyesen jeleníti-e meg a fogadott latin2 ill. utf8 kódolású leveleket (helyesen alatt azt is értem, hogy az ű-ből nem lesz-e kalapos û), mindez külön a levéltörzsre és a tárgyra is...

a levelkuldest mar megirtam utf8-ra es muxik (elobb postoltam a halado listara is tezst levelet), kliensek amivel neztem: kmail, weben es a macosx beepitett levelezojevel (ezek allnak rendelkezesemre)

a php fugveny amivel a leveleket legyartom (hatha masnak is jol jon) berakom ide:

function send_mail ( $_receiver, $_subject, $_message, $_sender = "", $_sender_mail = ""  )
        {
    $header .= "Return-Path: <".$_sender_mail.">\r\n";
        $header .= "Content-Type: text/plain; charset=\"utf-8\"\r\n";
        $header .= "Content-Transfer-Encoding: 8bit\r\n";
        $header .= "From: =?utf-8?B?".base64_encode($_sender)."?= <".$_sender_mail.">\r\n";
        $header .= "X-Sender: <".$_sender_mail.">\r\n";
        $header .= "X-Mailer: mailer\r\n";
        $header .= "X-Priority: 1\r\n";
        $_subject = ("=?utf-8?B?".base64_encode($_subject)."?=");
        mail( $_receiver, $_subject, $_message, $header );
        }

a scriptben nem szerepel a fogado neve csak az emil cime, de aszem ezt jatszava bele lehet rakni, csak szvsz felesleges, mert fene se tudja, hogy a suernek mi van beallitva sajat maganak.

Rakj bele egy "MIME-Version: 1.0" sort is a fejlécbe, ennek hiányában például a Mutt magasról szarik a C-T és C-T-E sorokra, hiszen ezeket a MIME definiálja; vagyis például muttban nem jelenik meg jól a levél. Lehet hogy máshol is szívást okoz a hiánya.

koszi! ezt nem tudtam, meg is csinaltam.

HA nincs hardened-php patch-ed, akkor figyelj, hogy ne tudjanak "\r\n"-t rakni az emailcimbe, illetve barmilyen headerbe.

mert? ebben a scriptben is van. ez gaz?

Nem.
En arra gondoltam, hogyha ez egy formmail vagy ilyesmi, akkor figyelj oda, hogy a userek ne tudjanak newline-t irni az emailcimbe, subjectbe, stb. (keress ra mail header injection-re vagy hasonlora, illetve itt egy angol oldal rola)

jahhh ertem mire gondolsz. erre nincs lehetoseg. ez egy kuldo script es nem levizsgalo. az egyesevel az alkalmazasok csinaljak. mivel mindenhol mast kell nezni vagy mas a visszajelzes az elkuldes/rontas eseten

ok.
Ajanlom figyelmedbe a "mb_encode_mimeheader" functiont a te megoldasod helyet...
$_subject = ("=?utf-8?B?".base64_encode($_subject)."?=");

ha hosszu a subject akkor ez nem lesz igy jo.

varchar(255)
ez gondolom nem olyan hosszu.

De.
Ha jol emlekszem akkor a transport hosszusag 1000 byte, de altalaban 76 karakteres sorhosszt szoktak hasznalni headernel. Ott tornek sort. Nem vagyok nagyon otthon az SMPT RFC-ben.
Szoval feltetelezve hogy a varchar(255) az utf8 az max 2x255 byte ha csak egy reszt szamolunk (amiben magyar karakterek is vannak). Ez base64-ben atlagosan 1/3-dal hosszabb.
Lehet, hogy talalsz jo par olyan MTA-t vagy mail klienst ami nem fog orulni neki, hogy olyan hosszu 1 sor.

PHP Mailer osztályt ismered? Nekem nagyon bejött. http://phpmailer.sourceforge.net

ugy fogalmaznek, hogy hallottam mar rola :)
nem hasznalom, jo a sajat kod, mert abban tudom mi-miert van.

egmont írta:
Kíváncsi vagyok, hogy helyesen kódolja-e a küldött levelekben az ő, ű, illetve egyéb extrémebb (latin1-en és latin2-n kívüli) karaktereket, ...

a legtobb Magyarorszagi webmail szolgalatas nem foglalkozik a headerekben a nem us-ascii karakterek escape-elesevel.

A valasz nem igazan os-fuggo", szerintem. mivel egy _nyers_, mindenfele metaadatok nelkuli filerol nem eldontheto", hogy az utf8 vagy latinx, ezert csak abban az esetben lehet megkulonboztetni o"ket (hogy rendesen kulturaltan mukodjenek) ha van valami metaadat. Viszont mind emaileknel mind http/html-nel adott ilyen adat (email: Content-Type: text/plain; charset=UTF-8; format=flowed, egy ilyen header, html: <meta http-equiv="content-type" content="text/html; charset=UTF-8">, http: szinten ilyen content-type-os header), ezert ha a kiszolgalo (email feladoja, a webszerver uzemelteto"je es a html-szoveg alkotoja) jol beallitja ezeket _es_ a kliens is kepes az effele adatok elfogadasara, akkor barmilyen kodolas barmilyen izevel nezheto" (es ezutobbi is elvarhato, pl. egy sima xterm+pine eseten is minden megy, meg ma'r a mozilla 1.7-es is tudja).

A nagy szopa's akkor van, mikor nincs ilyen metaadat. Pl. kuld neked valaki egy file-t, csak ugy. vagy a rendszered degradalodott latinX-rol utf8-ra, akkor az osszes text/* fileodnak reszeltek. De nagyon.

ezzl nalam nincs gond :)

header + html-ben is van meta adat, az emil meg utf-8-ban megy ki mert megcsinaltam azt is.

Akkor mi a problema? ugyertem, ha a kliens (email es web egyarant) tudja kezelni ezeket, akkor jo. ha a kiszolgalo nem adja ezekat az adatokat, akkor vagy ra' kell szolni ("lecci tedd bele az emailedbe hogy milyen kodolast hasznalsz"), vagy be kell allitani valami alapertelmezettet. Email-nel gondolom az alapertelmezett a latinx/ascii, mivel mar jopar evtizede letezik... Aki meg azt hiszi, hogy az utf8 az alapertelmezett, az megszivja.

Ha "atallas"-rol beszelsz azaz hogy ma'r van egy rakat fileod (sima mezei file, vagy aka'r email folder) ami latinx-be kodolt es azt szeretned, hogy egy program (barmi, tehat kliens vagy aka'r egy mezei editor) alapertelmezesben utf8-at hasznaljon, akkor a szivas: mindegyiket at kell konvertalni. Egyese'vel.

felre ertesz. szerver szinten hibatlanul atalltam, csak a cegnel (es mashol sincs) windows-om. igy fingom sincs ott milyen lett a hatas.

ami erdekelt: IE& Outlook ugyanis ezeket nem hasznalom.

magarol az atallasrol ugyerzemmar mindent tudok (hiszen megvalositottam) mult hetem arra ment ra, hogy az elokeszuleteket (scriptek) megcsinaljam, igy ma 5 perc volt a leallas es az atallas osszesen.

Csak egy tipp: nem lenne a legegyszerűbb, és egyben a legmegnyugtatóbb, ha küldenél egy tesztlevelet Gizikének, a babaarcú titkárnőnek, amiben leírnád, hogy mondjuk "Az árvíztűrő tükörfúrógép nagybetűkkel is csak ÁRVÍZTŰRŐ TÜKÖRFÚRÓGÉP.", majd felhívnád telefonon, és megkérnéd, hogy olvassa fel neked? :)

ha lenne windowsos ismerosom, akkor igen, nameg lenne az alabbi ket tomb matrixara ismerosom:

array(w98,w2000,wNT,wME,wXP);
array(fasztudja hanyfele win mail kliens es verzio);

Azt szeretném kérdezni, hogy a w$ vi$ta, támogatja-e az utf fájlneveket? Ha igen, hogyan?

A Windows mindenképpen UTF-16 fájlnevet használ. De igazából ott ez a kérdés fel sem merül, mivel az API eltakarja a fájlrendszer kódolását a felhasználó elől. Tulképp a Unix filozófia szerint a fájlnév byte-ok sorozata, a Windows filozófia szerint viszont karakterek (betűk, számok, írásjelek...) sorozata. Ha programozol és fogsz egy fájlkezelő függvényt, akkor annak dokumentációja mondja meg, hogy a fájlnévnek milyen kódolásban kell állnia. Az pedig innen kezdve a Windows magánügye, számodra nem látható, hogy a fájlrendszeren ténylegesen mi szerepel. Ha meg felhasználó vagy, akkor legyen elég annyi, hogy az ékezetek egyszerűen működnek, anélkül hogy bármit is tudnod kellene a kódolásokról.

Igen, a window$ tudja már - ha jól tudom - a vinfóó$$ kettőnullanullanulla óta telje$en nóóóórmáli$an, amióta entéefe$ 5 fájlrend$zer wan.

Legalábbis többször látok fura ékezeteket linukkszo$ terminálon fájlnevekben, mint win-n fájlnévben...

valószínűleg hülye vagyok, de nem értem a válaszaitokat.

Eddig az volt, hogy ha egy magyar w$-ban ékezetes nevű fájlokat mentettem, és felcsatoltam egy utf8-as linuxos rendszeren, akkor leginkább latin2-nek láttam a fájlneveket, tehát vagy latin2-nek kellett felcsatolnom az adott partíciót vagy convmv . Hülyeség a kérdésem, hogy megúszom-e ezután a convmv -t?

w$ helyett mondjuk mi lenne, ha leírnád, hogy melyik win és milyen fájlrendszerről volt szó?

CIFS-et hasznalj, ne SMBFS -t. Mert smbfs regebbi verzioju, (kvazi minta win95 vagy akar dosos lanmanager lenne). CIFS -sel mountolva, es az iocharset=utf8 opcioval, nalam utf8as rendszeren tokeletesek az ekezetek.

---
Apple iMac 20" CTO / Core Duo 2GHz

A Windows elég régóta (talán 95sp2?) mindenképp UTF-16-ot használ a hosszú fájlnevekben, pont. Vita nincs. :-) (A 8.3-as DOS-kompatibilis fájlnév az más tészta, de ez manapság senkit sem érdekel.)
Mivel ez nem kompatibilis az ASCII-val, vfat és hasonló fájlrendszerek csatolásakor a Linux kernel a fájlneveket _mindenképp_ átalakítja, ezen átalakítás egyik végpontja nyilván mindenképpen az UTF-16, a másik pedig az iocharset=... mount-opcióval megadható, illetve a defaultja kernelfordítási paraméter. Ha latin2-nek látod a fájlneveket, akkor utf8 rendszeren iocharset=iso8859-2 opcióval csatoltál, vagyis a kernel UTF-16 és Latin-2 között konvertál, aminek -- valljuk be -- abszolút semmi értelme nincs. UTF8-as rendszeren az iocharset=utf8 opcióra van szükséged (vagy csak simán utf8 opció is jó általában, iocharset nélkül. A különbség az, hogy az iocharset a külső nls modult tölti be és használja, míg az utf8 opció belső hard-coded konvertálót használ.)