ISO8859-2 - UTF8 migrálás - jó ez nekünk?

Debian GNU/Linux

Nem húzhatom már sokáig, muszáj megújítanom a házi szerveremet - nagyobb teljesítmény, nagyobb kapacitás (a diszkjeim is végét járják), kisebb fogyasztás és stb. Itt lenne ideje áttérni Squeeze -re. Amit jelenleg a szerver szolgáltat: 


- samba tükrözött tárfelület
- samba+cups nyomtató szerver
- levelező "kliens" exim4+courier imap+fetchmail és ache2+php5+squirrelmail
- FAX fogadás email -ben exim4+mgetty
- felhasználói honlapok + dokuwiki és homokozó
- leginkább fejlesztésekhez PostgreSQL
- rtorrent/bittorrent/torrenttornado, plowdown és persze screen

A kliensek, XP és Linux.
Már az Etch óta tiltom az UTF8 -at és a HU_hu azaz iso8859-2 kódlapot használom, mint rendszer alapértelmezés. Viszont ez számos problémát vet fel. Például:
- biztonsági frissítéskor, fejre állt a samba+cups (cups csak UTF8)
- a Squirrelmail -ben, ha válaszolni akarok egy UTF8 -as levélre zagyvaságokat ír ki.
Az utóbbi időben, új fejlesztésekben (cél feladatok - cél gépek) US English UTF8 -as local -t használok alapba - egész szimpatikus (pl. a naplók angolul vannak, ha valami van könnyebb infót találni róla a neten mint a magyarból visszafordított "pikk szalámi"), de a szerverben használt dolgokat itt nem használom (samba, cups, SQL). Mi lenne ha itt is ezt alkalmaznám, és ahol kell ott elvileg, külön megadhatom, hogy az adott alkalmazás UTF8 Magyar, esetleg ISO8859-2 Magyar legyen (szerintem ez még a sambára is érvényes, az adatbázisoknál, úgy emlékszem akár táblánként meglehet adni a karakter kódolást stb. - persze rengeteg többlet munka és sz'vás).
Hogy ne szaporítsam a bevezetőt, amire számítok:
- könyvtárak és fájl nevek iso -> utf
- levelezés, archivum
- adatbázisok/táblák
De mi jöhet még? Egy-egy konkrét szolgáltatás/applikáció esetében mi a leghatékonyabb megoldás. Most még működik a régi szerver, lehet kísérletezni. Még tervet sem csináltam, pl. mi legyen a szerverke alapértelmezett kódlapja - Magyar vagy US English?
Kérlek osszátok meg a tapasztalatokat és javaslataitokat, az is jó ha egy jó linket kapok.

UI: tudom, rengeteg topic és cikk született a migrációval kapcsolatban. Azonban ez mind szétszórva, és rendezetlenül. Most sok mindent ki tudok próbálni, talán nem csak nekem lesz érték.

  • 4564 megtekintés

( zslaszlo v | 2011. 05. 11., sze – 10:52 )

Egy friss tapasztalatom:
Egy kisebb bemutatkozó honlapot írtam egy ismerősömnek. (kb 4 statikus html lap).
A karakterkódolás utf-8 volt. Azonban éles szerverre feltöltve, egyes gépeken helyesen, míg más gépeken rosszul jelenítette meg az ékezetes betűket. Az egyik ingyenes szolgáltató honlapja például alapból nem is teszi lehetővé, hogy utf-8-as html dokumentumok helyesen jelenjenek meg.
Én személy szerint szívtam vele... És aztán ott van még, az utf bom-mal vagy anélkül kérdés is, hisz sok böngésző nem támogatja még ezt a kódolást.
És akkor még csak a html oldalakról beszéltünk. Hol vannak még az sql táblák...

> Az egyik ingyenes szolgáltató honlapja például alapból nem is teszi lehetővé

Szar szolgáltatók mindig is voltak és lesznek is. Mint ahogyan színvonalasak is. A választás a tiéd.

Szerk.: azt azért ugye beleírtad a html-be, hogy márpedig ő utf8-ban van?

> hisz sok böngésző nem támogatja még ezt a kódolást

Konkrétan?

Az Apache alapbeállítása hajlamos a Content-Type mezőbe betenni egy defaultot. Ekkor lényegtelen, milyen

AddDefaultCharset utf-8
AddCharset utf-8 html

Ennek hatására az Apache az alábbi sort fogja generálni a HTML-dokumentumok HTTP válaszfejlécébe:

Content-Type: text/html; charset=utf-8

Csak egy kis adalék: gyors guglizás különféle statisztikákat hozott fel, 40-60% köztre becslik a weben az utf8 karakterkészlet használatát az összes többivel szemben, és az érték folyamatosan nő. Tényleg az emberek fele olyan honlapot csinálna, amit nem mindegyik értelmes böngésző jelenít meg jól???

(bocs, zslaszlo-nak szántam válaszul)

Szerencsére én nem vagyok szolgáltató :)
Eddig bárhol alkalmaztam UTF-8 kódolást, az nem a szerver, sokkal inkább a böngésző, a tartalom (kimarad az UTF8 deklaráció), de leginkább a felhasználók, aki csak értetlenkednek, és nem tudnak kódlapot váltani a böngészőn. (még a busybox httpd is kezeli az UTF-8 -at, illetve nem kezeli egyszerűen elküldi, nem korlátoz, nem piszkál bele).
Alapvetően, a jelenlegi állapotok szerint az UTF lesz a győztes, de meglep hogy az első válasz, azt támasztja alá, hogy a magorok nem kérnek a globalizációból.

* Én egy indián vagyok. Minden indián hazudik.

Miért kellene a felhasználónak kódlapot váltania a böngészőben???

Az átlag felhasználó által nézegetett oldalak kábé fele utf8-ban van. hup, index, gugli, fácse, tvitter, hotméjl, jahúú, tecső, viki, gyakorlatilag az összes blog ... folytassam?

Hol látsz te felhasználót, akinek gondja lenne ezen oldalak bármelyikével, és kattintgatnia kellene misztikus menükben hogy rendberakja az ékezeteket?

Én személy szerint a böngészők fejlesztőire haragszom, amiért ez a rég elavult opció még megtalálható, nem csapták ki páros lábbal évekkel ezelőtt. :)

Az ékezetek helyes megjelenésének garantálása kizárólag az oldal fejlesztőjének feladata, nem a felhasználóé. Webfejlesztésben jártas fejlesztő számára körülbelül fél perc megoldani, nem több. Aki erre képtelen, annak az oldala nem érdemli meg hogy a felhasználók időt szánjanak rá.

Én személy szerint a böngészők fejlesztőire haragszom, amiért ez a rég elavult opció még megtalálható, nem csapták ki páros lábbal évekkel ezelőtt. :)

Aki erre képtelen, annak az oldala nem érdemli meg hogy a felhasználók időt szánjanak rá.

Én évente többször futok bele olyan oldalakba, amik más kódolást állítanak magukról, mint amilyen karaktereket küldenek. Tipikusan utf8 jön le, de nem ezt mondja magáról az oldal.

> Én évente többször futok bele olyan oldalakba...

Én is. Egy ideig baszakodtam a karakterkészletekkel. Aztán rájöttem, hogy fölösleges, egyik ilyen oldal sem volt érdemes arra hogy elolvassam. Te már találkoztál olyannal, amelyiket megérte olvashatóvá varázsolni, annyira jó volt? Rohadt nagy a web, ha ennek 1%-át kidobom, ráadásul nyilvánvalóan az alja táján lévő 1%-ot, hiszen milyen lehet már az az oldal ahol az ékezetek sem stimmelnek, akkor asszem nem vesztettem semmit.

Te már találkoztál olyannal, amelyiket megérte olvashatóvá varázsolni, annyira jó volt?

Találkoztam, rendszeresen találkozok is. Sőt, időnként általam visszatérően látogatott oldalak időre-időre el-elbaszódnak, és nincs kedvem kivárni, amíg megcsinálják. Ez nem jóság kérdése, sokszor szoktam olyan dolgok után keresgélni a neten, amiről csak nagyon kevés, vagy csak régi infók vannak fent, és minden egyes gugli által kidobott oldalt meg kell néznem, néha már csak a cached verziót tudom - na az is egy külön mise...

> Én személy szerint a böngészők fejlesztőire haragszom, amiért ez a rég elavult opció még megtalálható, nem csapták ki páros lábbal évekkel ezelőtt. :)
Van rengeteg olyan oldal ami meg akkor keszult amikor nem volt elterjedve a utf8. Ezen oldalakat mar nem tartjak karban de hasznos informaciot kozolnek.

> Az ékezetek helyes megjelenésének garantálása kizárólag az oldal fejlesztőjének feladata, ...
Ezzel nem lehet vitatkozni, de a server uzemeltetoje elegge meg tudja neheziteni a fejleszto munkajat.

( egmont | 2011. 05. 11., sze – 11:46 )

Két ellentmondó választ fogsz kapni tőlem. :)

Első válasz:
8 bites karakterkészlet = folytonos szívás a hibás tervezés miatt
utf-8 = egyszeri átállási költség, ami után minden egyszerűen "csak" működik.

Második válasz:
Ha szerverről van szó, akkor nagyjából tök mindegy.

Amit szerintem még nem értesz: az oprendszer alap karakterkészete az egy dolog, aztán amit az alkalmazások művelnek, az meg egy másik. Példa: említed, hogy a squirrelmail hülyeségeket csinál utf8 levelek esetén, meg hogy az levelezés archívumait át kéne alakítani. Nem. Minden egyes e-mail saját maga tartalmazza az ő karakterkészletét, majd a levél törzsét azzal a karakterkészlettel. Kutya kötelessége ezt minden levelezőnek jól kezelni az oprendszer karakterkészletétől függetlenül. Ha a squirrel szar, akkor szar, valszeg szar marad utf8-as alapokkal is. Az archívumhoz meg nem kell, nem szabad hozzányúlni.

Adatbázisok ditto: Minden alkalmazásnak tudnia kell, hogy ő maga az adatbázisokba milyen karakterkészlet szerint pakol, és ezt az oprendszer karakterkészletétől függetlenül kell tennie. Tehát elvileg, jól megírt alkalmazás esetén az alap karakterkészlet átállítása nem szabad hogy meglátszódjon. Persze tudjuk, nem minden alkalmazás van jól megírva. Ha meg saját cuccokról van szó, akkor érdemes lehet itt is átállni idővel utf8-ra, a hosszútávú szívások csökkentése érdekében.

Felhasználói honlapok szintén: minden honlap saját maga kell hogy megnevezze a saját karakterkészletét, ha nem teszi, akkor hibás, az apache viselkedése aligha függ a rendszer karakterkészletétől. (Már csak azért sem, mert szerver programok gyakran C locale-lal futnak és nem a desktop számára beállított defaulttal.) Dokuwiki: fogadjunk hogy már most is utf8-at használ, fel se tűnt neked, mert jól csinálja.

Fájlnevek: valóban illik átalakítani, de ha például mondjuk csak sambán éred el a fájlokat, akkor ott már nem fog meglátszani ez, mivel egy smb.conf-beli változtatás ezt kompenzálja. NFS-en, vagy ssh-val belépve persze lehet hogy másképp fognak látszani a dolgok.

> 8 bites karakterkészlet = folytonos szívás a hibás tervezés miatt
> utf-8 = egyszeri átállási költség, ami után minden egyszerűen "csak" működik.

megcáfolnám. egészen a legutóbbi évekig minden szoftver és programozó számára evidens volt, hogy 1 karakter = 1 bájt, és innentől kezdve bármi, ami nem felel meg ennek a tézisnek, folytonons szívással jár még jópár évig. gondolj bele, hány helyen lett mondjuk úgy memória allokálva stringeknek, hogy szükséges memória = karakterek száma...

alapjaiban véve oda jó az UTF8, ahol minden részlet UTF8 ready. ez azonban egy apró töredéke a világnak (még, ha növekszik is a részesedése)

Sajnos ez az 1 karakter = 1 bájt régesrégóta gond és nem is igaz. A soros vonalakon mindmáig fennmaradt a 7 bites kommunikáció. A "legújabbkori" GSM/SMS PDU is megér egy misét - még mindig hibázik az áltatlam írt "kodek" :( (ég is pofám miatta, de nem volt elég időm kibogarászni azt a szutykot, csak az vigasztal, hogy sok ipari GSM modul sem tudja).

Az UTF8 viszonylag nemrég kezdett terjedni. De állandóan beleütközök, hogy a dolgaim iso ez meg csak utf8 -at fogad el (lásd cups). De rendszeresen húzogatok csak feliratos filmeket, és szinkronozgatok (mert kicsit más az időzítés) ott meg a Panasonic DVD lejátszó szépségei jönnek elő, úgy tűnik iso8859-1 et eszi "helyesen"). Bárhova nyúlok ez még mindig probléma, jó lenne végre megegyeznének valamiben.

* Én egy indián vagyok. Minden indián hazudik.

> egészen a legutóbbi évekig

Ez egy elég lazán definiált valami... egyesek még ma is tévhitben élnek, mások viszont már ~15 éve tudják hogy mi a frankó.

> szükséges memória = karakterek száma

Tény ami tény, ha egy program nem támogatja az utf-8-at, akkor nem támogatja. Ezen nincs mit vitatkozni. A kérdés az, hogy az általad használt rendszeren, a rendszer által szállított progikat és az általad, Pistike által stb. írtakat is összeszámolva hány ilyen progi van, ezek mennyire kritikusak, tényleg kezelsz-e velük nyolcbites ékezetes karaktereket, mennyire van esély átírni a progikat utf-8 támogatásra, avagy mennyire tudsz helyettük valami mást találni... és ha még mindig van akadály, akkor nem célszerűbb-e ezen programok elé-mögé rakni karakterkonvertálást, mintsem az egész rendszer fejlődését fogni vissza emiatt.

utf-8 = egyszeri átállási költség, ami után minden egyszerűen "csak" működik.

Most haloványan beugrott néhány évvel ezelőttről, mikor ez téma volt, az UTF-8 akkor is kb. ugyanígy állt. Akkor is kb. úgy volt ha jól emlékszem, hogy "majdnem minden" faszán támogatja. Mint most.

Úgyhogy én leszek a kivétel aki erősíti a szabályt, maradok a saját rendszeren a latin2-esnél. Nem hiszem, hogy sok vizet zavarok. De nekem így jó még mindig.

OFF:
Minden faszán megy, amit használok, néha jön csak olyan tömörített zip es cucc, amit ha kicsomagolok, a fájlnevek krix-kraxok lesznek. Eredetileg cp852-vel kódoltan. Érkezés, kicsomagolás után convmv -f cp852 -t latin2 --notest és kész. ;-)

Meg néha előfordult, ahogy említettétek néhány weblap nem akar magáról helyes karakterkódolást árulkodni, és ilyenkor kézi/utf8. De ez szvsz meglenne ha a rendszert utf8ra tenném, csak a másik irányban. ;-)

--------

Nem vezetek...Jobb így. Nekem is
meg mindenki másnak is.

( zslaszlo v | 2011. 05. 11., sze – 11:54 )

Mindenkitől elnézést kérek, ha félreérthető voltam.
Nem a weblap karakterkódolásáról beszéltem, hanem a szöveges állomány kódlásáról.

meta http-equiv="Content-Type" content="text/html; charset=utf-8" Ez a sor természetes. És jól is van. Tudom, hogy ezt támogatják a böngészők.
Én a html,mint szöveges fájl kódolásáról beszéltem.
Mégegyszer bocsi, ha félreérthető voltam.

Sajnos, és szerintem ez egy óriási tervezési hiba, a http fejlécben szereplő karakterkészlet erősebb a meta tag-nél, ennek fordítva kéne lennie. Ezért lehetséges, hogy bizonyos tárhelyszolgáltatók erőltetik a latin2-t a fejlécben, garantáltan elrontva ezzel az utf8 lapokat. Az ilyen tárhelyszolgáltatókat meg lehet kérni, el lehet nekik magyarázni hogy miért rossz amit csinálnak, vagy lehet másikat választani helyettük. Sajnos nemcsak tárhelyszolgáltatók, hanem mondjuk linux disztribbel szállított webszerverek is van hogy defaultból valamilyen karakterkészletre vannak beállítva, és ezeket felülbírálni legalábbis picit macerás, de lehet hogy felhasználóként nem is lehetséges a rendszergazda beállításai szerint. Ez szívás sajnos, de a latin2-utf8 kérdésben ez a körülmény nem billenti semerre sem a mérleget, hiszen szimmetrikus a helyzet: a bedrótozott utf8 is ugyanúgy okozhatja a latin2 honlap hibás megjelenését.

( radix | 2011. 05. 11., sze – 12:02 )

2006 óta mindent UTF-8-ra konvertálok / használok, nem mondom, hogy teljesen zökkenőmentes,
de mivel 3 platformon dolgozom, valószínűleg így szívok a legkevesebbet.

+1

2005 végén álltunk át az UHU disztrib fejlesztői ágában, hirtelen sokkal egyszerűbbé vált sokminden. Ahol előtte csomót szívtunk az ékezetekkel (mert ugye a GTK2-nek akkor már UTF-8-at kellett adni, a rendszer többi komponense meg még Latin2-t használt), ott egy csapásra szinte minden probléma eltűnt. A stabil kiadás után is azt hiszem hogy drasztikusan csökkent a levlistákon az ékezetes betűkkel kapcsolatos panaszok száma.

Persze vannak buktatók, például meg kellett tanulnom hogy "tr" helyett "sed y", mert előbbi mind a mai napig nem komálja az UTF-8-at, de hát ilyen az élet. Ezen problémák száma még mindig jóval kisebb, mint az átállás előtt volt, és folyamatosan csökken.

( tovis v | 2011. 05. 11., sze – 12:54 )

Huh! Atz sem tudom kinek válaszoljak előbb :)
A HTML látom sokakat érzékenyen érint. Sajnos mi sem fogunk tudni ebben rendet teremteni - még petíciót sem tudnánk kinek küldeni (sóhivatal?).
Egyikőtök, azt mondja a meta infó kisebb prioritásű mint a head, a másikotok azt mondja rosszul van összerakva a cucc és a böngészúben nem is szabadna ilyen kódlap váltónak lennie, és a felhasználónak erről a dologról nem is szabad tudnia. Egyezzünk meg abban, hogy a felhasználónak mindent szabad/lehet - ha Ő az iso8859-1 -et mint KOI8 -as orosz kódlapként szeretné megnézni, tegye, mi meg legyünk azon, hogy világos és helyes honlapokat készítsünk.
Másikotok azt mondja át kell állni utf8 -ra minden kis piszlicsáré programban - valóban nincs más kiút, ez most a belátható jövő. A 8 bites kódolás egy történelmileg kialakult forma, amit a 8 (még régebben 7) bites kommunikációs átviteli csatornák alapoztak meg - így volt természetes. De ez roppant sok idő és pénz illetve sz'vás, ráadásul, mi a helyzet a különféle vezérlő jellegű programokkal? Olyan lakonikus és egyszerű szövegeket kommunikál min pl. "Állj" akkor ezt most valamelyik oldalon össze-vissza kell konvertálgatni. Ami eddig sima kis C string volt most, wide verzióra kell cserélni - valahol :) Ráadásul, pl. az NT4.0 vagy a W98nem biztos hogy jól kezeli az UTF8 -at.
Adatbázisok. Hát-hát, elég sokat kell velük szkanderezni, és mi a helyzet a kollíziós táblákkal? Ugye nem azt akarod mondani, hogy lapátoljuk be binarás blob -ként az adatokat, aztán majd a kliens leválogatja, rendezi? A tábláknak szerintem ismernie kell a kódlapot.
Az apache viselkedése nem függ a kódtáblától - és ha fájl listát tesz ki?
A samba felhasználók számára mindegy a gép kódlap,no igen, de mint rendszergazda azért nekem is itt-ott bele kell túrnom a fájlokba, és roppant bosszantó ha nem tudom használni a Midnight Commandert. így is gond, hiszen az UTF8 US Enlish vagy Magyar teljesen másként jelenik meg az mc egy iso8859-2 -n. Mi a helyzet a szokásos ssh mentésekkel és másolatokkal (a minap valószínűleg ezt sz'vtam meg, egy eredetileg mc -vel iso8859-2 alatt szerkesztett shell script hibákat okozott egy UTF8 -as gépen, több óra töprengés és értetlenség).
Azt mondja a levelezési archívumokat nem kell bántani, jó lesz ahogy van - ezt könnyű lesz kipróbálni, hiszem ha látom.
Szóval nem arról kellene beszélni, hogy minek kéne lennie, hanem hogyna lehet megvalósítani, működőképessé tenni a dolgokat. Látom hogy az utf8 migrálás megkerülhetetlen, szeretnék a felmerülő problémákra a lehető legjobban rákészülni.
Kezd a topic szétzuhanni - bennem van a hiba, túl globális kérdést vetettem fel :(
* Én egy indián vagyok. Minden indián hazudik.

> A tábláknak szerintem ismernie kell a kódlapot.

Igen, vagy legalábbis ez a szerencsésebb eset.

> Az apache viselkedése nem függ a kódtáblától - és ha fájl listát tesz ki?

Nem tudom pontosan a választ, de szerintem inkább a saját konfig fájljából, illetve htaccess-ből veszi az értékeket, mintsem a rendszer default locale-jéből. A default locale inkább desktopra vonatkozik; rég nem néztem már initszkripteket, de szerintem a disztribek egy része a démonokat, szerver programokat (mint pl. apache) nem a rendszer default locale-jével, hanem mondjuk C-vel indítja. Nem tudom, nézz utána :) Egyébként használsz ékezetes fájlneveket és apache által listáztatást egyszerre? Egész biztos hogy megoldható; a konkrétumokat nem tudom fejből.

> Mi a helyzet a szokásos ssh mentésekkel és másolatokkal (a minap valószínűleg ezt sz'vtam meg, egy eredetileg mc -vel iso8859-2 alatt szerkesztett shell script hibákat okozott egy UTF8 -as gépen, több óra töprengés és értetlenség).

Korábban írtam két egymásnak ellentmondó választ :) Ha mc-zel, akkor már nem 100%-ban szerverként használod a gépet, hanem mondjuk 99% szerver és 1% kliens, és az az 1% miatt szerintem érdemes UTF-8-ra váltani. Hogy az mc ne legyen szívás.

Azt javaslom, kísérletezz bátran, és teljes gőzzel előre UTF-8 terén! Nem te vagy az első aki ezt csinálja, konkrét apróságokba biztos bele fogsz ütközni amikre gugli kapásból megmondja a választ, ezt előre úgysem lehet látni.

Az az igazság, hogy én azt hittem ezen már a gazdák túlnyomó része átesett, és én az utolsó "mucsikán" vagyok aki még ilyen beállításokkal él. Olyannyira ezt hittem, hogy mindig ha valami ilyesmihez hozzá szóltam szégyenkezve írtam le, hogy én még iso8859-2.
Mindenképpen szeretném ezt az akadályt megugrani és lehetőleg minden legyen szinkronban - mc -ből ugyanazt lássam amit samba alól.
Mindig hangsúlyozom, hogy ez egy házi szerver, számos funkciót lát el, de a legfontosabb a megbízható tárhely és most már a levelezés (egy nanószkópikus BT vagyok és a levelezésem létfontosságú évekre visszamenőleg). Egy ilyen gép üzemeltetése csak úgy indokolható, ha ki is van használva, pl. a letöltéseket is ezen csinálom - éjjel/nappal megy. Mint új szolgáltatás, szeretném majd bevezetni a torrent flux -ot, amivel a torrentes letöltéseket, WEB felületen kezelhetem, de olyan terv is van hogy a még meglévő analóg TV -t is ide beépíteni (felvenni műsort, etherneten műsort szórni ... hobby -nak menne de ki tudja mire esz jó). Szóval kipaszírozom az összes mips -et és bitet, ha tudom.

* Én egy indián vagyok. Minden indián hazudik.

Szerintem tulmisztifikalod.

Dobj fel egy friss sqeeze-t, aptitude install-old a szukseges csomagokat. Ha vannak sajat scriptjeid, azokat iconv-val konvertald UTF8-ba, a regi mailekhez, html fileokhoz ne nyulj.

latin2-es adatbazisokrol el kell gondolkodni, ha latin2-es weblapokon at megy az input-output, celszeru az adatbazist is ugy hagyni (DBMS beallitas backup visszatoltes elott).

Esetleg regi ekezetes file nevekkel lehet gondod, de ez valoszinuleg eddig is fennallt.

Egy kétszemélyes cég? Az igazi WEB lapot egyébként egy másik cég csinálja - amennyit ezért el kér az szerintem megéri és nekem is megfizethető.
A "házi szerver" egyébként is dyndns -en csücsül, inkább fejlesztési és kisegítő feladatokat lát el. Nem ezen fut a honlapunk.
Több olyan szoftverem is üzemel ami windows-linux kombó, mindkét oldalon akkor át kellene néznem a string/üzenet kezeléseket - senki ezért nem fizet egy buznyákot sem, így ez hobby project lenne.

* Én egy indián vagyok. Minden indián hazudik.

Én úgy láttam, hogy a torrentflux valójában a bittorrent, torrenttornado vagy az rtorrent (parancssori, non GUI) számára nyújt WEB -es admin felületet. Az utorrent GUI felületes, leginkább munkaállomásokon futtatott cucc - legalábbis én így tudom. Az rtorrent -hez éppen még faragnak valami WEB felületet. A lényeg, hogy ne kelljen még egy gépet folyamatosan (többé-kevésbé) üzemeltetni azért, hogy ezt -azt lehúzzak.

* Én egy indián vagyok. Minden indián hazudik.

( tovis v | 2011. 05. 15., v – 13:29 )

Töltsük ezt újra.
KÉRDÉSEK:

1. Áttértetek-e a gép/rendszer már az UTF8 alapértelmezett lokálra?

2. Nekem az alapértelmezett US English UTF8 nagyon szimpatikus, mivel az összes adminisztratív felület és a különféle hiba üzenetek angolul jelennek meg (pl. nem kell őket visszafordítani ha google -ban keresek). Ti Magyar UTF8 -at telepítettetek?

3. Milyen nehézségekbe ütköztetek? Hangsúlyosan, az olyan szerver applikációkkal mint, samba, cups, apache2, exim4, IMAP szerver, SQL szerverek stb.

4. Milyen nehézségekbe ütköztetek? Az egyéb segítő, adminisztratív és felhasználói felületet biztosító programok (pl. squirrelmail, dokuwiki stb.) esetében.

Kicsit elmentek a dolgok, a php/html fejlesztés, WEB üzemeltetés irányába. Valaki említette, hogy 3 éve áttért az UTF8 -ra, de nem nekem úgy tűnik, hogy ez megint a WWEB -es fejlesztésekkel kapcsolatban írta.

HÁTTÉR:
Debian -t használok, szerverről beszélünk, tehát stable. Már az Etch kopra óta első dolgom volt a telepítés után, kikapcsolni a kernelben az utf8 támogatást, aztán minden iso8859-2 (HU_hu). Számos kisebb nagyobb sz'vás lett ebből. pl. az egyik frissítés során a cups megszünt kommunikálni és kijelentette, hogy csak UTF8 -ban hajlandó szóba állni a samba -val. Máskor, arra lettem figyelmes, hogy a squirrelmail -ben, ha válaszolni akarok egy UTF8 -ban írott email -ra, nem képes helyesen megjeleníteni azt, a böngészőben átállítani nem tudom. Az így megírt válasz levél is elég érdekes lehet, hiszen amit válaszolok az iso8859-2 viszont az eredeti az utf8. PostgreSQL -ben nem lehet tökéletes sorrendet állítani az ékezetes karaktereket tartalmazó tábláknál - pl. névsorok. Kipróbáltam, az UTF8 lokálon a saját programjaimat - baj van az üzenetek nyelvével, az ilyen gépről küldött hasonló szövegek a windows kliensen is rosszul néznek ki. Mi a helyzet a samba-windows kombóval? - pl. ékezetes felhasználó nevek. Valahogy be lehet állítani a windows XP -n az UTF8 lokált, de ezt a beállítást még nem láttam sehol.
Ezekről a dolgokról szeretném ha megosztanátok a tapasztalatokat.

* Én egy indián vagyok. Minden indián hazudik.

Bocsi de ez most kicsit úgy hangzik, mintha az eddigi válaszokat el sem olvasnád, mivel nem 100%-ig pontosan egy az egybe a te kérdéseidre válaszolnak.

Ha át akarsz állni, ne habozz, vágj neki! Lesznek buktatók, netes segítséggel meg fogod tudni oldani őket, de ne hidd hogy a fórumon előre meg fogják neked mondani az emberek hogy mik lesznek ezek - senki sem tudja. Egy adott pontig természetesen tartsd meg a lehetőséget a visszalépésre, hátha valami tök nem működne.

Kéréseidre az én részemről a válaszok: 1. igen. 2. hol ez, hol az - nem tök mindegy? :) 3. gyakorlatilag semmi - ezen alkalmazások általában leszarják hogy mi a rendszer alapértelmezett lokálja. 4. dettó.

Squirrelmail-ről már írtam: Egy ilyen proginal a rendszer latin2-es vagy bármilyen alap lokálja esetén helyesen kell kezelnie bármilyen karakterkészletű e-mailt, utf8-at is, akkor is ha nem ilyen az alap lokál. Te azt állítod, hogy ez nincs így. Ebből a következtetés egyértelmű: a squirrelmail szar. Namármost ha szar, akkor valszeg utf8-as alap lokállal is szar lesz - lehet hogy ugyanúgy szar, lehet hogy másképp szar, nem tudom.

Samba: tudnod kell hogy a Windows minden körülmények között egy konkrét bizonyos karakterkészletet használ (tök mindegy hogy mit), tehát a samba most is alakít neked oda-vissza a windowsos és a latin2 között, ezentúl a windowsos és utf8 között fog. Az "xp-n utf8 lokál" tehát elvi síkon hülyeség. A sambán csatlakozó gép nem fogja látni, hogy a szerveren karakterkészletet váltottál, mivel eddig sem ment, és ezentúl sem fog menni egyetlen bit sem a hálózaton a szerver karakterkészlete szerint, az átállás a kliensek számára transzparens kell hogy legyen.

postgres: ismételten: a táblák, illetve az adatkapcsolat karakterkészlete számít (bár részleteket nem ismerek), aligha az oprendszer alapértelmezett lokálja.

Ne várj arra hogy itt majd a fórumban megmondják neked hogy milyen szopásoknak nézel elébe, senki sem látja. Ess neki!

"Kéréseidre az én részemről a válaszok: 1. igen. 2. hol ez, hol az - nem tök mindegy? :) " - nem, nem mindegy, pl. nincs hosszú "Ű" és hosszú "Ő".
"3. gyakorlatilag semmi - ezen alkalmazások általában leszarják hogy mi a rendszer alapértelmezett lokálja." - hát erre én nem így emlékszem, pl. a postgresql (régebbi) telepítője avval kínzott, hogy mondjam meg mi az alapértelmezett lokál a számára, ha nem adok meg semmit akkor a rendszer alapértelmezett lokálját fogja használni.
Számomra az is fontosnak tűnik, hogy ha a szerveren, direktben kotorászok a samba megosztásokban, akkor ugyan azt lássam (fájl nevek), mint windows alól. Ha egy iso8859-2 lokalos gépről csatlakozom ssh -n egy UTF8 -as gépre nagyon kellemetlenül néz ki, alig használható - több olyan hostot felügyelek távolról ami ilyen (pl. Sarge 3.1 a php4 miatt).
Szóval már most látok egy kupac bajt és vacilálok. Jó lett volna, ha többet is láttam volna, de úgy látom, neked lesz igazad, csak a konkrét esetekkel lehet (talán) mit kezdeni. Pedig "nromáliséknál" az ilyet meg kellene tervezni.

* Én egy indián vagyok. Minden indián hazudik.

> nem, nem mindegy, pl. nincs hosszú "Ű" és hosszú "Ő".

Hol nincs?

> hogy mondjam meg mi az alapértelmezett lokál a számára

Tehát ha akarod, akkor meg tudod mondani neki egy utf8-as rendszeren is, hogy a postgres az bizony latin2 - ha gondod akadna az utf8-cal. Ez csak jó, nem? Nem muszáj egyből átállnod, csinálhatod azt is hogy a postgres marad a régiben.

> Ha egy iso8859-2 lokalos gépről csatlakozom ssh -n egy UTF8 -as gépre nagyon kellemetlenül néz ki, alig használható

Ez egy létező probléma, létező megoldással. screen, luit, terminál utf8-ba billentése az ssh idejére stb...

Ha egy iso8859-2 lokalos gépről csatlakozom ssh -n egy UTF8 -as gépre nagyon kellemetlenül néz ki, alig használható - több olyan hostot felügyelek távolról ami ilyen (pl. Sarge 3.1 a php4 miatt).

"Mindent, vagy semmit" az elv lényege.
Vagy az _összes_ gépedet átállítod mindenben utf8-ra, vagy Szopni Fogsz (TM).

A HU_hu-ról pláne nem beszélve... (_magyar_ hibaüzenetek? jó az valakinek?)

Hát pedig ez nem fog menni - mindent nem fogok tudni átállítani. Bizonyos helyeken a Linux inkább firmware mint OS.
A windows ssh putty kliensnél, hostonként betudom állítani a kódtáblát, Linux alatt ilyet nem lehet? Esetleg ha más felhasználói profilt használok?

* Én egy indián vagyok. Minden indián hazudik.

> windows ssh putty kliensnél, hostonként betudom állítani a kódtáblát, Linux alatt ilyet nem lehet

???
minden ssh session-t így indítasz:

$ env LANG=hu_HU-UTF8 ssh gépnév
$ env LANG=en_EN-UTF8 ssh gépnév

stb, és máris minden session külön kódtáblát használ. LANG helyett lehet valamelyik LC_xxx változót, vagy akár az LC_ALL-t is használni. (Ezt az env-es indítási formát azért szeretem, mert mindenféle shell-ben működik, mindegy, hogy sh- vagy csh-szintaxisú. És így akár külön indítóikonja is lehet, mert ez már mehet az execCommand-ba.)

$ env LANG=hu_HU-UTF8 ssh gépnév

Ebben biztos vagy? Mérget vennék rá, hogy _így_ nem működik. Máshogy persze igen.

Az ssh programot ugyanis csöppet sem érdekli a saját LANG-ja. Sőt, a karakterkészlet úgy egyáltalán. Az ssh csak byte-okat pakol változatlan formában balról jobbra és jobbról balra.

Ha helyi latin2-es gép előtt ülsz, és távoli utf8-asra jelentkezel be, akkor valakinek valahol el kell végeznie az oda-vissza konvertálást, és az nem az ssh lesz, mert tudtommal az nem tud ilyet.

A konvertálást végezheti például a luit, vagy a screen, mindkettő tud alakítgatni, mindkettőt lehet elvileg a helyi és a távoli gépen is indítani, bár a helyin szerintem egyszerűbb. Vagy még jobb: a helyileg futó terminál program viselkedését át lehet állítani. Ehhez termináltól függően _lehet_ hogy elég a _terminált_ (és nem az ssh-t) módosított LANG-gal indítani, avagy escape szekvenciát kiírni rá ami átkapcsol (*), avagy kézzel menüben átállítani, stb.

(*) UHU-ban megcsináltuk, hogy ha szerveren fut UTF-8-as UHU, és akármilyen kliensről belépsz ssh-val, akkor kiírja azt az escape szekvenciát, amelyik UTF-8-ba billenti a terminált. A dolog hátránya csak annyi, hogy kilépéskor nem tudjuk megbízhatóan visszabillenteni.

Ezt mondom én is. A távoli gépen a LANG és társai beállítódnak, de egyetlen kukk sincs arról, hogy bárki is konvertálná a nyers byte-okat. Márpedig ha a helyi terminálod latin2, a távoli rendszeren meg minden fájlban és fájlnévben utf8 van, akkor valakinek ezt is meg kell tennie, különben hatalmas zagyvaság jelenik meg a képernyőn.

Linux alatt ilyet nem lehet? Esetleg ha más felhasználói profilt használok?

Nem lenne Linux, ha ne lehetne, vagy ha más felhasználóra kellene váltani.

A putty tulajdonképpen két dolgot csinál egyszerre. Az egyik a hálózati titkosított kommunikációért felelős rész, a másik pedig az adatok grafikus megjelenítése, billentyűlenyomások értelmezése stb, tehát az "ablak". Linuxban ez élesen két külön progi (kivéve ha valami perverz ötlettől kifolyólag putty-ot használnál Linuxon): előbbi az ssh, utóbbi a terminál. A karakterkészletek a terminálra tartoznak, nem az ssh-ra. Minden említésre méltó terminál programban ablakonként, tabonként lehet állítani a karakterkészletet.

Ki fogom próbálni amit itt írtatok. Rengeteget használom az ssh -t, nagyon szeretem! Imádom, hogy parancssorból (legalább is Linuxon) még whinchestert is cserélhetek - már ha előtte be volt dugva :)
(Kár hogy a windows parancssori kezelése nem eléggé nehézkes és hiányos, az ssh szerverek pedig vagy nem működnek, vagy fizetősek)

* Én egy indián vagyok. Minden indián hazudik.

Jogos, ezt elírtam. Viszont van benne ráció :) Ha megnézed a Unix/Linux parancssori programjait, a többségüknek elképesztően sok különféle kis kapcsolója van és ha a kombinációikról beszélünk akkor rájövünk, hogy a rugalmassága ezeknek a bonyolult, nehezen memorizálható programoknak köszönheti. Igen, az ms tovább bonyolíthatná a parancssori programjainak lehetőségét (talán, jó példa erre a "net" parancskészlete).

* Én egy indián vagyok. Minden indián hazudik.

( nevergone v | 2011. 06. 27., h – 10:27 )

Semmilyen problémám nem volt még abból, hogy UTF-8-at használok.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)

( tovis v | 2011. 07. 24., v – 17:55 )

A levelező kombót felraktam, utf8 vs. iso8859-2 - nem érzek különbséget. Talán a Squirrelmail default nyelvet kellene beállítani, mert mielőtt bejelentkezik az ember addig angolul írogat, de végül is ez nem igazán számít.
Viszont, hogy is kellene a samba megosztásokról az adatot migrálni? Ami adja magát, az a mount.cifs - eddig csak az "ÚŐ" betűkkel nem nem tudott mit kezdeni (no meg a szerveren lévő linkek nem működnak). Ha, viszont, mondjuk rsync -el dolgozok akkor számos ékezetes fájl nevet kellene konvertálnom :(

* Én egy indián vagyok. Minden indián hazudik.