ISO8859-2 vs. UTF-8

Kérdés

ISO8859-2
0% (0 szavazat)
UTF-8
0% (0 szavazat)
Összes szavazat: 0

( Csigaa | 2008. 01. 29., k – 17:05 )

A szavazás kérdését a hozzászólásban kell megtippelni, a sikeres megfejtő egy iconv szoftvercsomagot kap ajándékba, a GNU project támogatásával.

( BaT | 2008. 01. 29., k – 17:11 )

Igen, nagyon nem mindegy, hogy melyiket használod és melyiket preferálod...

( pinyo_villany | 2008. 01. 29., k – 17:20 )

iso8859-1 ... :P én nincs probléma az ékezetekkel, de ... inkább nem is folytatom

linux v2.6.22.15 + madwifi v0.9.3.3-mal itt
debian gnu/linux @ linux-2.6.22.17-rc2-szami2

( DirtY_iCE | 2008. 01. 29., k – 17:33 )

hátőőőpuff.. most ennek így mi értelme van? mert most hogy lehet összehasonlítani az iso-8852-et, ami 1 bájton tárolja a karaktereket és az UTF-8at ami úgy 1-6ig valahol.. tehát úgy szerintem több értelme lenne, hogy single byte vs. multi byte; vagy single bytosak, vagy pl. unicode kodolási formátumok.. mert szerintem a fenti kérdés teljesen attól függ, mit akarsz tenni.. ha az ISO-8859-2 tartlmazza az összes szükséges karaktert akkor az, különben UTF-8..

I hate myself, because I'm not open-source.

most ennek így mi értelme van?

Hogy az uborkás konzervek ;-) / ubuntu+konservation / meg merjenek e füröszteni bennünket iso88592es sötétben bújkáló ellenforradalmárokat szurokban és madártollban... ;-)

amúgy semmi. :-))

----------

Nem a zsömle kicsi, a pofátok nagy...

( kikke | 2008. 01. 29., k – 17:57 )

Javaslat új szavazásra:

Igen ( )
Nem ( )

Igen, szar lehet. De ha odamegyunk hozzad, hogy agyu vagy pisztoly, te melyiket valasztanad? Ugye, hogy attol fugg, elotte vagy mogotte allsz. Nezopont kerdese az egesz. Webes projekthez vagy multiplatformos szoftverhez utf8-at preferalom, de desktopon eddig mindenhol irtottam utf8-at es alltam vissza latin2-re. Egyszeruen tobbminden tamogatja latin2-t, mint utf-et.

( Oscon | 2008. 01. 29., k – 18:03 )

Az UTF8 azoknak a kreálmánya, akik a globalizáció áldásos/átkos hatása miatt kénytelenek többnyelvű kultúrákkal elektronikusan kommunikálni. :-)

És ezek az egyedek döntésüket a világ azon részére is rá próbálják kényszeríteni, akik mentesülnek e "kötelezettség" alól. Ha úgy tetszik saját önös érdekből akarják az egész világot megváltoztatni. :-)

De ez soha sem fog sikerülni. :-)

Nem sikerült anno a windowsnak sem, az internet explorernek sem, és nem sikerül az UTF8nak sem. :-)

100 %ot soha nem fog elérni egyik sem. :-)

Mert a világ nem így működik, hogy mindenkiből borg dolgozót csinálunk azoknak a kárára akiknek ebből nincs hasznuk. :-)

Az "új generáció"-nak relatíve tökmindegy hogy iso, vagy utf. Rajtuk kívül vannak a fent említett globalisták, és vagyunk mi sötétben bújkáló ellenforradalmárok. Nekünk az UTF8 fölösleges pluszmunka. :-)

------

Nem a zsömle kicsi, a pofátok nagy...

Az UTF8 azoknak a kreálmánya, akik a globalizáció áldásos/átkos hatása miatt kénytelenek többnyelvű kultúrákkal elektronikusan kommunikálni. :-)

Mi a helyzet 2 egynelvűvel, akik közül az egyik globalizációs, a másik pedig "maradi"? :)

--
"my mind had skipped town and left me behind to pay the rent"

Nem szeretem az UTF-16 -ot, mert jobban pazarolja a helyet, illetve abból már lehet "little endian" és "big endian", ami által már megint nem teljesen egyértelmű az értelmezés módja.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

Az utf-16 szerintem a legszarabb Unicode-ábrázolási formátum, létjogosultságát egyedül a kezdeti kétbyte-os Unicode-dal való kompatibilitás indokolja. Öszvér megoldás, félig az UCS-4, félig az UTF-8 tulajdonságát keveri, összegyúrja mindkettő kényelmetlen vonásait. Akár az UTF-8, akár az UCS-4 (LE vagy BE) épeszűbb választás szerintem szinte mindenhol.

ejha. :))

jól beestem a csőbe. a szelektív látásom miatt. csak az svn-t és a git-et láttam, nem olvastam el a teljes hsz-t úgy tűnik. :)). de mégis igaz, ezek sem játszanak. A munkavégzésemhez nem használok számítógépet. ún. "fizikai dolgozó" kategóriába tartozom.

a havi "munkaidőbeosztást" néha megkapom mailben xls formátumban. kb. ennyi.

tehát igen. "semmiféle doksit" nem írok.

--------

Nem a zsömle kicsi, a pofátok nagy...

Mindenkinek joga van úgy kódolni és tárolni az adatait, ahogy neki jól esik. A világnak meg joga van, hogy ne kommunikáljon veled. :)
Értsd jól: Annyiban pl. tisztelem a Microsoft -ot, hogy előbb felmérték ennek a jelentőségét, és az NTFS már egyféle karakterkódolást használ a fájlnevekhez, és pont. Nem biztos, hogy a legjobbat, vagy a leghatékonyabbat, de legalább egységes. Nem olyan barmok, mint manapság a Linux, BSD, és társai, ahol azt mondják, hogy tekintsük a fájlnevet nyers adathalmaznak, és mindenki úgy értelmezi, ahogy akarja. Mert ebből származik az, hogy még mindig nem igazán lehet ékezetes fájlneveket használni, mert semmi sem garantálja, hogy a másik gépen azt értelmezni is tudják. Vagy ha ennyire fáj az UTF-8, akkor legalább tárolják el a fájlnévben a kódolás azonosítóját, amellyel értelmezni lehet.
És mindig ajánlom elolvasásra ezt

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

és az NTFS már egyféle karakterkódolást használ a fájlnevekhez, és pont

És éljenek boldogan mindazon windows tulajok kik olyan külső adathordozót használnak, melyen fat/fat32 fájlrendszer virul büszkén és dacosan különféle okok miatt, és nem angol nyelvterületen élnek...;-)

És éljenek még boldogabban, mikor ezt a külső adathordozót más nem feltétlen windows használókhoz cipelik különféle okok miatt. ;-)

------------------

Nem a zsömle kicsi, a pofátok nagy...

Aki jelenleg FAT -ot használ produktív környezetben, sikeres ember nem lehet.
Amúgy pedig elég baj, hogy a FAT -nál még nem figyeltek a különféle karakterkódolások problémájára a fájlnevekben, mint ahogy Linux alatt még most sem figyelnek erre kellőképpen.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

/off
nemtudom, lehet hogy csak nekem, de NTFS nekem, windows alól már kétszer is megadta magát (először nem nyitott meg egy fájlt, majd 4-5-t, majd egész mappákat, végül már a fél fájlrendszert.. ebben a legbulisabb csak az volt hogy linuxról szó nélkül meg tudtam nyitni.. egy formázás után észheztért, most jelenleg nem igazán tapasztalok ilyen jelenséget, főként mert csak ext3at használok.. ha meg mindenféleképpen windows, akkor maradok a jó öreg fat32nél, akárki akármit is mond rá..
/on

I hate myself, because I'm not open-source.

Az én tapasztalatom az hogy egyrészt nem.

Másrészt vannak rajtuk kívül még a dualbootosok. azoknál eddig mindig láttam fat32-t ;-)

Harmadrészt a jó kis pendrive-on császkáló xszázdarabos gyűjtemények. Otthon csávónak ctrl-c ctrl-v aztán hogy a 400valahány fájlnévből hány ékezetes, szerinted átnézi bármelyik is ? na ugye. ;-)

Negyedrészt nekem is jobb így. mexoktam, bevallom nekem is vannak évekkel ezelöttről ékezetes fájlneveim. mert kiafasz gondolta, hogy valakinek az sem tetszik majd pár év múlva hogy valami működik ;-)

------------

Nem a zsömle kicsi, a pofátok nagy...

hogy ezek mennyire stabil, gyors gyakorlatban használhatóak az egy más kérdés ;-). tény hogy vannak. Egy tömörített NTFS partíciót pl. mivel kezelsz írható-olvasható módon? mert az NTFS-t sok mindenért lehet szidni, de a tömörítése rendkívül nagyszerű majd 30%ot ad, igen kevés teljesítményveszteség mellett. ntfs3g tömörítetten mikor utoljára láttam nem ment. captive jó volt 2 gigabájtos partícióig, aztán 20asnál segmentation fault kb. és minél nagyobb volt a partíció annál lassabb volt.

ext-s wines megoldást láttam néhány éve. hasonlóan ment mint a captive.

kernelben levő ntfs read+write kb. arra jó hogy a SAM fájlokat lehessen írni vele. aztán ntfsfix parancs, és windows rendbeteszi a minor inkonzisztenciákat.

--------

Nem a zsömle kicsi, a pofátok nagy...

1. erre nincs szükségem. :-)
2. ezért cserébe az archívumom egy része alapjáraton kb. olvashatatlan átkódolásra szorul =munka.
3. időnként hoznak ide mindenféle "anyagot", ami szintén olvashatatlan lenne. :-)

Ezért 3:0 arányban az isora szavaztam. :-)

----------

Nem a zsömle kicsi, a pofátok nagy...

Ezek alapján az ISO ellen sokkal több minden szól, mint az UTF ellen. S az UTF mellett is több minden szól, mint az ISO mellett. Tehát nem győztél meg. Szvsz mindannyian a hülye ASCII áldozatai vagyunk. Okos (angol nyelvű) tervezői nem gondoltak a világ többi országára, de cserébe megspóróltak karakterenként egy bitet :)

Nem én akarok meggyőzni bárkit is. tőlem mindenki azt használ amit akar. :-)

Egyszerűen leírtam, nekem miért nem jó az UTF8. kb. ez volt az eredeti kérdés. :)

Én ugyanis nem akarom a világ összes karakterét leírni, mert mi a francnak nekem ez , viszont amit nem akarok az archívum, meg az idelátogató fat32es szarok átkódolgatása. ;-)

------

Nem a zsömle kicsi, a pofátok nagy...

> meg az idelátogató fat32es szarok átkódolgatása.

Látszik, értesz a témához :-) A fat32 ugyanis a hosszú fájlneveket mindenképp UTF-16 kódolásban tárolja, körülbelül a Win95 második kiadása óta. Tehát kábé tizenkét éve ezen a téren semmi sem változott. Ha Windows alól nézed, jók az ékezetek. Ha Linux alól, a mount-nak kell megadni okosan a paramétert. Vagyis részedről semmiféle átkódolgatásra nincs szükség, a Linux kernelnek viszont bármilyen karakterkészlet választása esetén kell alakítgatnia, de ezt szíves-örömest megteszi neked.

Persze van még az az eset, ha rossz opciót meg adsz meg a kernelnek, és te magad alakítgatsz. Ez esetben viszont a hiba a felhasználóban keresendő.

Ahogy mondod, linux alól a mount-nak kell megadni okosan a paramétereket. pl.:

codepage=852,iocharset=iso8859-2

ugyanígy van az ntfs-nél is pl. (Xp félék jártak erre még, vista-s gönc még nem volt) nls=iso8859-2

mi van akkor ha mindenki imádott utf-8 kódolást próbáljuk kierőszakolni pl. egy vfaton ?

Jan 30 04:32:17 osconsfortress kernel: FAT: utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive!

Úgyhogy ezúton is Csókoltatom az utf8 imádókat !!! :-))

De azért minden karaktert le tudnak írni vele. OK. ;-)

Magyarország, Kelet-Közép Európa iso8859-2 rulez! ;-)

---------

Nem a zsömle kicsi, a pofátok nagy...

Nem készülök nyelvészprofesszornak hogy zavarjon a nagykötőjelek hiánya. Az viszont idegesítene, ha egy fájlnévben kérdőjeleket látnék, vagy egy txt fájl tartalmából úgy kellene kitotózni hogy az a kurva kérdőjel, az most ő,
, ű vagy mifene. Hogy úgy mondjam a "szövegértés"re a nagykötőjel hiánya kevésbé van hatással, mint hogy mindenfele pl. ?-eket látok. ;-)

A világ számomra "csak" Magyarországból áll, ill. angol nyelvű szövegekből (manual). Ilyen speciális helyzetben vagyok.

sem a pa ruszkit, sem a türkische manuszt, sem a görög karalábébetűket nem értem. akko' meg minek bámuljam ?

ennyi erővel írhatnak 50 ?-et egymás után, abból se értek se többet se kevesebbet.

--------

Nem a zsömle kicsi, a pofátok nagy...

"Az viszont idegesítene, ha egy fájlnévben kérdőjeleket látnék, vagy egy txt fájl tartalmából úgy kellene kitotózni hogy az a kurva kérdőjel, az most ő,, ű vagy mifene."

Ezert is hasznalok utf8-at.

"sem a pa ruszkit, sem a türkische manuszt, sem a görög karalábébetűket nem értem. akko' meg minek bámuljam ?
ennyi erővel írhatnak 50 ?-et egymás után, abból se értek se többet se kevesebbet."

Nem mintha En olyan tul sokat ertenek belole, de megis szivesebben bamulom mint a ?-ket vagy hibas kodolasbol adodo ertelmezhetetlen krix-kraxokat.
Ezenkivul pl matematikaban gyakran hasznalnak gorog betuket.

> mi van akkor ha mindenki imádott utf-8 kódolást próbáljuk kierőszakolni pl. egy vfaton ?

Én nem kierőszakolni szoktam, hanem beállítani. Semmiféle eröltetés nincs egy opció megadásában.

> Jan 30 04:32:17 osconsfortress kernel: FAT: utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive!

Ja, semmi sem lehet tökéletes.

A case insensitive fájlrendszer az egyik legnagyobb baromság, amit csak el lehet képzelni. Csak szívás van vele, Windows alatt is. Többek közt azért is, mert a betű kis- vagy nagybetűs párja függ az adott _nyelvtől_. Nemcsak kódlaptól, nyelvtől is. Képzeld el, hogy valaki mondjuk az ISO-8859-9 kódlapot használja, mert történetesen nem magyarnak, hanem töröknek született (képzeld, ilyen emberek is vannak). Ebben a kódlapban benne van a szokásos i és I, valamint a török pont nélküli kis ı és pontos nagy İ. (Ha a HUP iso-8859-2-t használna UTF-8 helyett, jó eséllyel ezt most nem tudtam volna demonstrálni neked.) Melyiknek melyik a párja? Ez még ezen a kódlapon belül is attól függ, hogy az adott szó, amit leírsz, angolul vagy törökül van-e. Ezt nemhogy a Linux kernel, de még a Windows fájlrendszerkezelő kódja sem tudhatja. Íme egy példa arra, hogy a case insensitive rendszer miért baromság.

> Úgyhogy ezúton is Csókoltatom az utf8 imádókat !!! :-))

Ezúton csókoltatom a case insensitive fájlrendszer megálmodóit! :-)

mert történetesen nem magyarnak, hanem töröknek született (képzeld, ilyen emberek is vannak)

Mint mondtam én nem vagyok ilyen ember, én nem melózok infos vonalon, nem beszélek sem görögül, sem törökül, sem klingonul, így nem szorulok rá az utf világmegváltására, tehát nekem hiába jötöök ilyen példákkal, az életben nem fogok találkozni vele. Ami viszont nekem probléma, hogy az utf8 és az iso8859-2 nem kompatibilis egymással az ékezetek eltérő kezelése miatt.

És akkor ott vannak a saját cuccaim, amiben szintén vannak ékezetes fájlnevek könyvtárak. Ugyanis ha teszem azt hoznak valami cuccost, akkor az általában egy könyvtárban van. abban vannak alkönytráak, azokban a fájlok. Namost azt ugye nem gondoljátok komolyan, hogy én akár szkript révén, akár egyesével átnyálázva azzal töltöm az időmet, hogy átnevezgessem...

A fat32-t meg sok mindenért lehet szidni, én is szoktam jó buli meg minden, viszont kvázi default pendrive filerendszer, dualbootosok is mind használják (mert nincs más). és bizony ott is vannak ékezetes fájlnevek stb.

Ez még semmi, de ezt mobilrackekben időnként idehorgyák különféle okok miatt.

Namost én itt UTF8al kb. kitörölhetem a seggem. ;-)

Törökök, meg görögök, meg japánok nem hoznak ide ilyen cuccost, és erre esély kb. nincs is. Így nálam nem téma az áttérés. Akinek probléma oldja meg. De mástól pl. tőlem ne várja el hogy fölöslegesen szopassam magam UTF8al.

De nagyjából összegyűjtöttem az itt fellelt ötletek közül hogy az UTF8 imádók szerint nekem mit is kéne tennem:

- UTF8 rulez, ez a jövő, ez a fejlődés
- ne használj ékezetes fájlneveket
- kódold át a teljes archívumodat, csak egyszer kell szopni vele, meg a használt fájlrendszeredet, stb. (pl. különféle isos magyar txt fájlok tartalma ? )
- ne használj fat32-t / = dobd ki a pendriveodat, dobd ki az mp3 lejátszódat, dobj ki mindenkit aki mobilrackel jön, vagy dualbootot használ /
- bármilyen nyelven akár klingonul, görögül és törökül is írogathasz ezáltal kódtábla vátlás nélklül / jó tudom hogy nem beszélsz egyiken sem, meg izé, de megteheted, biztos fontos lesz 200 évvel korábban /

Az esetleges írónia/cinizmus felfedezése fenti sorokban nem a véletlen műve. ;-)

--------

Nem a zsömle kicsi, a pofátok nagy...

- UTF8 rulez, ez a jövő, ez a fejlődés
Igaz, bár nem biztos, hogy ez a legjobb. De még mindig jobb, mint az iso-xyz

- ne használj ékezetes fájlneveket
Használj, csak ez néha hátrányokkal jár.

- kódold át a teljes archívumodat, csak egyszer kell szopni vele, meg a használt fájlrendszeredet, stb. (pl. különféle isos magyar txt fájlok tartalma ? )
magyar txt-s fájlok tartalma: normális szövegszerkesztők támogatnak minden elterjedtebb kódolást, ami meg nem, az számomra nem normális

- ne használj fat32-t / = dobd ki a pendriveodat, dobd ki az mp3 lejátszódat, dobj ki mindenkit aki mobilrackel jön, vagy dualbootot használ /
De, én is használok. Mount opciókban megadod a kódolást, akkor _elvileg_ nem lesz probléma vele.

- bármilyen nyelven akár klingonul, görögül és törökül is írogathasz ezáltal kódtábla váltás nélkül / jó tudom hogy nem beszélsz egyiken sem, meg izé, de megteheted, biztos fontos lesz 200 évvel korábban /
Lehet, de nem leszel inkompatibilis azokkal, akik már átálltak, mert pl. kapcsolatban állnak görögökkel.

"Namost azt ugye nem gondoljátok komolyan, hogy én akár szkript révén, akár egyesével átnyálázva azzal töltöm az időmet, hogy átnevezgessem..."

man convmv.
kb egy egész perc, mire észreveszed a példát és kimásolod parancssorba, aztán már eldolgozik magában.
Huszadannyi időbe és energiába nem kerülne, mint amennyit a napokban itt összetrollkodtál.

Huszadannyi időbe és energiába nem kerülne, mint amennyit a napokban itt összetrollkodtál.

Csak hiszed, pl. csak a tavalyi archívumot is elő kell bányászni,és mindet szépen átkonvertálni. Kb. ha belegondolok mi mindent kéne előbányászni, átkonvertálni, hogy 100%ban utf8as legyek, ez x*hússzor annyi időbe kerül mint itt "trollkodni" a te szavaiddal élve.

és akkor ha utf8at használok alapértelmezésként, konzolon, helyesírásellenőrzőn, miegymáson, akkor baromi jó hogy minden ideérkező cuccot codepage=852, iocharset=iso8859-2vel fogok becsatolni, akkor az tényleg kurva sok értelme volt úgymond szopni.

És ha netalántán valami mittommilyen prghiba akármi miatt félresikerül az átkódolásnál, akkor még jól be is szoptam, határozott vonzerőm van sajnos a bugokhoz atchitektúrától és operenciás rendszertől függetlenül. ;-)

Bár én a "trollkodás" helyett úgy fogalmaznék hogy egy "másik" nézőpontot testesítek meg itten. :-). végül is a fórumok részben erre is valók. :-). nem lehetünk tökegyformák, mások az igényeink, elvárásaink, stb.

Én tiszteletben tartom hogy tik utf8at használtok, biztos tudtok héberűl, görögül, törökül, klingonul, ezért rendkívül fontos, hogy minden létező nyelven egy kódolással képesek legyetek kommunikálni. lelketek rajta. Használjátok egészséggel.

-------

Nem a zsömle kicsi, a pofátok nagy...

Pontosan miben áll a hozzá nem értés azt mond meg?

Tessék most bevágtam az egyik mobilrackot a kaszniba.
ntfs van rajta.

A konsole-t (KDE) áttettem utf8 kódolásra, becsatoltam nls=utf8-opcióval és ezt látom: 

-rw------- 2 root root 2455 2007-09-13 12:35 �\232j\ Office\ dokumentum.lnk

ugyanez fat32vel.

konsole (KDE) vissza iso02-re, ntfs nls=iso8859-2 vel és ezt látom: 

-rw------- 2 root root 2455 2007-09-13 12:35 Új\ Office\ dokumentum.lnk

pontosan ennyit az UTF8ról.

-----

Nem a zsömle kicsi, a pofátok nagy...

Te akarsz meggyőzni minket, hogy CSAKAZÉRTIS jobb a magyar nyelvet SEM megfelelően támogató latin2, mint a nemzetközi UTF-8

Nem én akarok meggyőzni bárkit is. tőlem mindenki azt használ amit akar (Oscon | 2008. január 29., kedd - 20:31 )

Én nem vettem észre hogy olyan marha nagy probléma lenne a magyar nyelv támogatásával iso02ben. A nagy gondolatjel hiányát, ha 10évig bámulom se veszem észre, amit asszem egmont hozott fel. Ékezet legyen, bötűk meglegyenek.

Tehát ha van Árvíztűrő Tükörfúrógép, nekem az már faszomántos, nem tervezem a nyelvészprofesszori kurzus látogatását, még az se zavarna ha a ő betűnek hulláma lenne, az ű nek meg kalaptya (asszem iso01ben? van így). És mivel évekkel ezelött a latin2-t használtuk, és ott ez mögvolt, és még a kb. egyetlen igazán univerzális fájlrendszer (vfat), sem rinyál tőle NEKEM önző csekély értelmű és beszűkült látásmódú egységsugarú usernek megfelel. :-)

Végül is évekig ezt haszná'tuk. Tegye fel a kezét aki UTF8-elött mást használt, és abszurdisztán boldog lakója. ;-)

-------------------

Nem a zsömle kicsi, a pofátok nagy...

nem én az a fajta csávó vagyok, aki nem szereti ha fölöslegesen akarnak rákényszeríteni olyasmit, ami csak kárára van, és fölösleges szopással jár. Ami haszna lenne, azt pedig helyzetéből fakadóan nem tudja ki- felhasználni.

--------

Nem a zsömle kicsi, a pofátok nagy...

> ... rákényszeríteni ...

Légyszi fejtsd ki részletesebben, miért beszélsz „rákényszerítés”-ről. Egyszerűen nem értem, miért használod folyton-folyvást ezt a szót. Kíváncsi vagyok, tényleg, pláne mivel ugye a szavazás eléggé nyitvahagyta a kérdést, hogy tulajdonképpen mire is válaszolunk, miről beszélgetünk. Én nem látom, hogy bárhol bárki rád akarna bármit is kényszeríteni. Vagy legalábbis nem nagyobb mértékben, mint amilyen mértékben évekkel ezelőtt az iso-8859-2-t „kényszerítették” rád. (Vagy az egy tudatos döntés volt részedről, sok-sok lehetőség megvizsgálása után, hogy „ez kell nekem”?) Tényleg kíváncsi vagyok, milyen típusú felhasználó vagy, milyen progikat használsz, milyen rendszert üzemeltetsz vagy fejlesztesz stb.

Elképzelhetőnek tartok olyan szituációt, amikor egyáltalán nem éri meg átállni, és az utf-8 tényleg inkább csak nehézségeket okoz. Például ha van egy általad fejlesztett, jól bejáratott, sok helyen használt szoftver, több évnyi adatbázissal, biztonsági mentésekkel, ami szoftvert funkciójánál fogva soha senki nem fog magyartól különböző karakterek tárolására használni, soha senki nem fog valahol külföldön is beüzemelni, és amelyik szoftver nem tart kapcsolatot másik szoftverekkel, akkor ott valóban fölösleges átállni... Ebben az esetben viszont a napnál is világosabb, hogy senki sem akar téged semmire sem kényszeríteni.

A másik lehetőség, amire gondolni tudok, hogy általában a Linux rendszerekre, azok alapértelmezett beállításaira, és az itt tapasztalható általános tendenciára (ti. UTF-8-ra átállás) érted a rákényszerítést. Azonban itt sem kényszerítésről van szó. Két fontos észrevételt kell tenni. Az egyik az, hogy az iso-8859-2 és hasonló karakterkészletet valószínűleg még ükunokáink korában is támogatni fogják a számítógépek, meg fognak tudni jeleníteni ilyen kódolású fájlokat és el fognak tudni menteni, csak épp nem ez lesz az alapértelmezett (mint ahogy a legtöbb Linuxban már ma sem ez az alapértelmezett). A másik fontos dolog azt észrevenni, hogy miért történik ez a nagy átállás. Ezt hadd fejtsem ki részletesen.

Az átállásnak kizárólag technikai okai vannak. A felhasználók számottevő részének veled ellentétben szüksége van több nyelv írásjeleire is egyszerre (vagy egyszerűen csak annyira, hogy a saját cuccai mások számítógépén is jól jelenjenek meg), és a régi kódlapokkal sorozatosan olyan problémákba ütköztek, amelyek nem voltak megoldhatók. Az ISO-8859-2 és társai nem képesek megoldani egy olyan igényt, amelyre neked ugyan nem, de nagyon sokaknak másoknak szükségük van. Az UTF-8 ki tudja elégíteni ezeket az igényeket.

Az UTF-8 valóban nem kompatibilis az ISO-8859-2-vel, de azt is vegyük észre, hogy az ISO-8859-* kódlapok léteztek előbb, és ezeket a karakterkészleteket úgy alkották meg, hogy nincs lehetőség a felülről kompatibilis bővítésükre. Ha lett volna lehetőség, minden bizonnyal éltek volna vele az újabb kódolások megalkotói. Tehát a kompatibilitás hiánya is az ISO-8859-* kódlapok bűne, nem az UTF-8-é.

Miközben hangoztatod, hogy nem érdekelnek téged a magyaron kívüli nyelvek, ne feledd, hogy azokat a rendszereket, amelyeket te használsz (a hardvertől kezdve a gépeden telepített szoftvereken keresztül egészen az interneten használt szolgáltatásokig) többnyire nem magyar, és nagyon sokszor nem is angol ajkú emberek fejlesztették, hanem mindenfélék szerte a világon. Nem csak Neked fejlesztették ki. Nem is csak azoknak a magyaroknak, akik csak magyarokkal akarnak kommunikálni. De még csak nem is összes magyarnak. És nem is egy adott nemzet tagjainak. A szoftverek túlnyomó részét a fejlesztők a világon mindenkinek fejlesztik. Amíg az ISO kódlapok használatával próbálták meg nemzetköziesíteni a szoftvereket (alkalmassá tenni például többnyelvű dokumentumok továbbítására, melyre, ismétlem, sokaknak szükségük van), addig csak megoldhatatlan problémákba ütköztek. A felmerülő igények jelentős részét csak az UTF-8 karakterkészletre átállással lehetett épeszűen, vagy egyáltalán bárhogyan megoldani.

És most jön a csattanó. Már csak egyetlen nagyon egyszerű dolgot kell észrevenni. Ha már egyszer egy adott feladatra van egy általános, sok igényt kielégítő, jól működő, világszerte mindenki által jól használható megoldás, akkor egyáltalán semmi értelme nincs tovább fáradozni azon, hogy egy másmilyen, ezzel nem kompatibilis megoldást is nyújtson bárki, amelyik megoldás csak egy szűkebb igénylistát elégít ki, ezáltal csak jóval kevesebb ember számára megfelelő.

Az előző gondolatot elég kacifántosan sikerült csak megfogalmaznom, elsőre talán nem tiszta. Megpróbálom egy példával érzékeltetni. Vegyük például a Gnome 2 rendszert, amelyik mindenütt UTF-8-at használ, azért, mert csak így tudták kielégíteni nemzetközileg nagyon sok felhasználó igényeit. Erre egyébként bizonyíték a Gnome 1-es változata, amelyik még akkor is tartalmazott egy-két csúnya ékezethibát (nem elírást, hanem elví síkú, az adott rendszerben nem javítható hibát), ha magyarra beállított rendszeren csak magyarul akartad használni. A Gnome 2-es sokkal több nyelven, sokkal több karaktert tud akár egyszerre is hibátlanul megjeleníteni. A világon nagyon sokak számára ez egy hatalmas előrelépés, míg kétségtelenül vannak, akik számára közömbös. De remélhetőleg objektív mércén mérve érthető számodra, hogy miért volt szükséges az átállás. Namármost van tehát a Gnome 2, amelyik az elejétől a végéig UTF-8-at használ. Ilyen módon a magyar ékezeteket is mindenütt tökéletesen jeleníti meg, és nem haragszik meg senkire sem pusztán azért, mert csak magyarul használja a rendszert, másmilyen karaktereket nem használ.

Nade ha egyszer van egy ilyen szoftver, akkor ugyan kiknek és miért érné meg kifejlesztenie egy másik Gnome-ot, amelyik ISO-8859-2 alapon csak a közép-európai karaktereket lenne képes kezelni? Ha már van egy általános megoldás, a hülyeség netovábbja volna irdatlan mennyiségű fejlesztői erőforrást ölni egy ezzel nem kompatibilis, és csak szűkebb igényeket kielégítő másik megoldás kifejlesztésére.

Végezetül hadd hívjam fel a figyelmed még egy körülményre. A fentiek miatt ha tetszik, ha nem, tény, hogy terjed az UTF-8 az ISO karakterkészletek rovására, ez a folyamat visszafordíthatatlan. Soha nem fog eljutni 100%-ig a térhódítás, de kilencvensokig biztos. Már most is majdnem mindegyik Linux disztribúció majdnem mindegyik alaklmazása UTF-8-at feltételez alapból a fájlok kódolásának, és ez a tendencia csak folytatódni fog, ez ellen egyikünk sem tud tenni semmit (maximum érte tud tenni, mint ahogy azt én is igyekeztem anno egy-két relative apró lépéssel).

Néhány évvel ezelőtt, amíg még ISO-8859-2-t használtam, de a programok jelentős része (például Gnome) már UTF-8-at, rendszeresek voltak az ékezetgondok, sokszor kellett átkapcsolnom (például egy Gnome konfigurációs fájl szerkesztésekor), és az egész kezdett roppant unalmas és fárasztó lenni. Ráadásul én még csak-csak tudtam, hogy mi a teendő, de az átlag felhasználó nem is értett volna az egészből semmit, csak azt látta, hogy nem működnek a dolgok úgy, ahogy elvárná.

Amikor átálltam UTF-8-ra, valóban volt némi teendőm az átállással. Szövegfájljaimat átkonvertáltam, Linux partíción lévő ékezetes fájljaimat átneveztem, és mindezt egyszerre az összes gépen, amit használok. Igen, volt talán egy-két hét átmeneti, nagyon-nagyon felemás időszak. Ha jól emlékszem, ez közel két és fél éve volt.

Azóta is rendszeresen használok ékezeteket, és gyakorlatilag soha semmi problémám nincs velük. Nem is gondolok a karakterkészletekre, nem alakítgatok, nem konfigurágatok, nem konvertálgatok. Csak leütöm a billentyűzeten a megfelelő betűt, és az mindig is ugyanaz marad, akár a Gnome egyik konfigurációs fájljában a sok-sok idegen nyelvű sor között az egy magyar sort írom át (és „mellékesen” a többi idegen nyelvű szöveg is helyesen jelenik meg), akár csak úgy terminálban irogatok egy szövegfájlt, akár bármi mást csinálok. Egyszerűen észre sem veszem, hogy UTF-8, észre sem veszem, hogy bármi gond lenne az ékezetes betűkkel. Épp olyan természetesen használom őket úton-útfélen, mint az ékezet nélkülieket. Nemes egyszerűséggel „Csak Működik”. Ennyi. Ezt tudja nyújtani az UTF-8 kódolás az ezt támogató szoftverekkel együtt.

Ha kinyitod a szemed és körülnézel, észreveszed hogy az árral szemben haladsz, akár tetszik neked ez az irány, akár nem. Ráadásul ahogy sorra átáll mindenki, az ár is egyre erősebb lesz, egyre nehezebb lesz kapaszkodnod, értsd, egyre több kellemetlenséged fog adódni a két kódolás keveredéséből. Akár tetszik neked, akár nem, az UTF-8 objektív okok miatt igenis terjed, mivel jobb kódolás, mint az ISO-8859-2. Az idő múlásával egyre gyakrabban fogsz ilyen kódolásban kapni anyagokat, egyre gyakrabban fog az panaszkodni, akinek ISO-8859-2-ben küldesz valamit, hogy nem tudja elolvasni. Még akkor is, ha pusztán magyar ékezetes betűket használsz. Most még talán nem hiszed, de elkerülhetetlen, hogy előbb-utóbb átállj, ha nem akarsz napi rendszerességgel szívni. Ha rám hallgatsz, minél hamarabb állsz át, annál több fölösleges kellemetlenségtől kíméled meg magad.

Igen, az érem másik oldala az, hogy ha szoftvert fejlesztek, akkor valóban picit nehezebb dolgom van, mint ha ISO-8859-2 rendszerem volna. Valamit valamiért. Végülis a fejlesztő van a felhasználóért, nem fordítva, nemde?

Szerk.: most látom csak, milyen rohadt hosszúra sikerült... elnézést :-)

(Vagy az egy tudatos döntés volt részedről, sok-sok lehetőség megvizsgálása után, hogy „ez kell nekem”?)

Relatíve nem volt más. A magyar kommunikációban akartam ékezeteket használni, és ez tűnt a jó megoldásnak. Az említett érkező mobilrackes, stb. cuccok is codepage=852;iocharset=iso8859-2 -t "kértek" csúnya aszóval, hogy ne a ?-el fájlneveket bámuljam. utf8ra igazából nem volt igény. kvázi akkorban sehol sem használták. az utóbbi pár évben indult meg az utf8 konverzió..

A másik lehetőség, amire gondolni tudok, hogy általában a Linux rendszerekre, azok alapértelmezett beállításaira, és az itt tapasztalható általános tendenciára (ti. UTF-8-ra átállás) érted a rákényszerítést.

Talált. szerecséncsémre a debianban levő dpkg-reconfigure locales (még) felkínálja az iso8859-2t.

Az UTF-8 valóban nem kompatibilis az ISO-8859-2-vel, de azt is vegyük észre, hogy az ISO-8859-* kódlapok léteztek előbb

És itt a pont. Egyetlen program/kódlap/akármi fejlesztőtől sem várható el, hogy megjósolja a 15-20(mittomomén mikori? :-))) évvel későbbi tendenciákat, és eszerint fejlesszen.

A rossebb gondolta hogy ennyire globális lesz a helyzet. ;-)

A fejlesztéseket úgy szokták csinálni hogy legalább a közvetlenül megelőző "rendszerrel" kompatibliis legyen. Itt ez nem áll fent. ha az ékezetek ua. jelennének meg uf8al, mint isoval akkor én sem haboznék, mert kb. mindegy lenne. (az ilyenek hogy mennyire kalapos, nem kalapos, stb. meg milyen a karimája akármije a betűnek azt lexarom röviden és velősen.) de ékezetek terén az eltérés a két kódlap között már a szövegértést sem biztosítja.

Amikor átálltam UTF-8-ra, valóban volt némi teendőm az átállással. Szövegfájljaimat átkonvertáltam, Linux partíción lévő ékezetes fájljaimat átneveztem, és mindezt egyszerre az összes gépen, amit használok. Igen, volt talán egy-két hét átmeneti, nagyon-nagyon felemás időszak.

Na látod ez az aminek én feleslegesen nem fogok nekiállni. Utálom a felesleges, és értelmetlen munkát.

Én relatíve nem nyerek semmit az UTF8-al. Nem vitatom, hogy a "globalista" - több_Ékezetets_nyelvű használók számára fontos, és hasznos. Én viszont nem tartozok ebbe a körbe, és nem is valószínű hogy ide bekerülök. Németül még elvagyok, angolul már annyira azért nem :), de ezen még igyekszünk alapfokig / közép reménytelennek tűnik /, aztán itt meg is állok. (ä, és ß pedig van isoban is)

de a programok jelentős része (például Gnome) már UTF-8-at, rendszeresek voltak az ékezetgondok, sokszor kellett átkapcsolnom (például egy Gnome konfigurációs fájl szerkesztésekor), és az egész kezdett roppant unalmas és fárasztó lenni.

Ez a rákényszerítés tipikus esete - a jelenleg használt rendszer használatának megnehezítése, használhatatlanná tétele. És még észre sem vetted.

Egyszerűen észre sem veszem, hogy UTF-8, észre sem veszem, hogy bármi gond lenne az ékezetes betűkkel.

vicc: erről az jut eszembe mikor trey elindította a hup.hu-s irc csánelt :-), és megjöttek oda az uborkás konzervek (ubuntu+konservation), és utf8 as cuccokkal nem látták az én és hasonszűrő maradiak ékezeteit. Mi viszont láttuk az övükét. (irssi a titok nyitja). tehát amit írtál a "kompatibilitás" hiányáról az nem feltétlenül igaz. Irssi a bizonyíték arra, hogy ha van szándék-akarat, akkor meg lehet oldani a helyzetet, hogy a káposzta is jóllakjon és a kecske is megmaradjon.

Ezt tudja nyújtani az UTF-8 kódolás az ezt támogató szoftverekkel együtt.

Amit viszont nem tud nyújtani az "X-1es verzióval" való kompatibilitás. Hogy miért az tjképpen lényegtelen. Nem tudja és kész.

Most még talán nem hiszed, de elkerülhetetlen, hogy előbb-utóbb átállj, ha nem akarsz napi rendszerességgel szívni. Ha rám hallgatsz, minél hamarabb állsz át, annál több fölösleges kellemetlenségtől kíméled meg magad.

Ezt az idő fogja eldönteni. Jelenleg semmiféle kellemetlenségem nincsen abból hogy a rendszeremet, fájlrendszeremet, konzolomat, konqueroromat, helyesírásellenőrzőmet, stb. iso8859-2es alapértelmezett rendszerrel használom, ezáltal évekkel ezelötti, és jelenlegi önmagammal is kompatiblis vagyok. A neten vannak utf8as cuccok, de a böngészők az irssi-hez hasonlóan megoldják a helyzetet. egészen egyszerűen egy content_type sort kell a weboldalkészítőnek bepötyögni kb.

vagy egyszerűen csak annyira, hogy a saját cuccai mások számítógépén is jól jelenjenek meg

Igen ez az igény itt is megvan, csak mivel a "mások" esetemben általában windows felhasználók, a vfat codepage=852;iocharset=iso8859-2-es vfat-os megoldást választom/juk, mindenféle hátrányával együtt. Ugyanis nincs más stabilan használható megoldás. Az igazi az lenne ha az NTFS végre stabilan is írható lenne tömörítéssel is, de sajnos ez évek óta és szerintem mindannyiunk számára nyílvánvaló ok (MS) miatt gyakorlatilag járhatatlan.

Ha elszaporodnak a vista-k (ezekben már kizárólag utf8van?, hiába no nem ismerem ezeket a jószágokat már), lehet a helyzet változik. ezt majd az idő eldönti.

Kérdésedre válaszolva, (már) nem üzemeltetek semmit, "kiszálltam" pár éve az infóbol, nem fejlesztek, egyszeri egységsugarú, de azért ultraparnoid user vagyok.debian woody óta kde-t használok grafikus felületként.

Végülis a fejlesztő van a felhasználóért, nem fordítva, nemde?

Most lehet hogy nagyon sok embert magamra haragítok, de én ezt egyre kevésbé érzem főleg linux alatt... és most el is térek a tárgytól attól tartok. :-)

Itt most leginkább a kernelre gondolok. Itt inkább azt érzem hogy a kernel a fejlesztőért van, és nem a felhasználóért. Az egyik legutóbbi húzás (i386&amd64) "összegyúrása" tipikusan ezt az irányt testesíti meg. Ez tipikusan a kernel-fejlesztőkért volt.

------------

Nem a zsömle kicsi, a pofátok nagy...

"A fejlesztéseket úgy szokták csinálni hogy legalább a közvetlenül megelőző "rendszerrel" kompatibliis legyen. Itt ez nem áll fent. ha az ékezetek ua. jelennének meg uf8al, mint isoval akkor én sem haboznék, mert kb. mindegy lenne. (az ilyenek hogy mennyire kalapos, nem kalapos, stb. meg milyen a karimája akármije a betűnek azt lexarom röviden és velősen.) de ékezetek terén az eltérés a két kódlap között már a szövegértést sem biztosítja."

Parancsolj.

"vicc: erről az jut eszembe mikor trey elindította a hup.hu-s irc csánelt :-), és megjöttek oda az uborkás konzervek (ubuntu+konservation), és utf8 as cuccokkal nem látták az én és hasonszűrő maradiak ékezeteit. Mi viszont láttuk az övükét. (irssi a titok nyitja). tehát amit írtál a "kompatibilitás" hiányáról az nem feltétlenül igaz. Irssi a bizonyíték arra, hogy ha van szándék-akarat, akkor meg lehet oldani a helyzetet, hogy a káposzta is jóllakjon és a kecske is megmaradjon."

Ez visszafele is ugyan ugy igaz, azzal a kulonbseggel hogy ISO-8859-2-n kivul eso karaktereket nem fogod latni, attol fuggetlenul hogy akarod-e vagy sem.

Tudom, ez a topic már lerágott csont, de ha egyszer úgy szeretek reagálni...

A fejlesztéseket úgy szokták csinálni hogy legalább a közvetlenül megelőző "rendszerrel" kompatibliis legyen.

Melyik előző rendszerre gondolsz itt? Csak mert isobol van vagy 15, cp-ből is jópár. Amivel lehetséges kompatibilisnek lenni (ASCII) azzal meg az is. Mondd, hogy igazunk van!
Lécci-lécci-lécci-lécci-lécci-lécci! :)

> A fejlesztéseket úgy szokták csinálni hogy legalább a közvetlenül megelőző "rendszerrel" kompatibliis legyen. Itt ez nem áll fent.

A fejlesztéseket úgy szokták csinálni, hogy azok eredményei tovább bővíthetők legyenek felülről kompatibilis módon. Az ISO kódlapok nem ilyenek. Ezek a kódlapok tehát két tekintetben is hibásak, egyrészt az alap filozófiájuk hibás, mivel nem képesek megoldást nyújtani a nemzetköziesítés problémaira, másrészt azért is hibásak, mert nem bővíthetők. (Mellesleg az előbbi implikálja az utóbbit: mivel a különböző ISO kódlapok nem kompatibilisek egymással, ezért sem lehetséges olyat alkotni, amelyik mindegyikkel kompatibilis felülről.) Nagy-nagy kár, de ebből a szituációból más kiút egyszerűen nem volt. Vagy te tudsz valami okos megoldást javasolni, amivel mindenki jól járna?

> Ez a rákényszerítés tipikus esete - a jelenleg használt rendszer használatának megnehezítése, használhatatlanná tétele. És még észre sem vetted.

Ja, hogy te rákényszerítésnek hívod azt, hogy egy régi rendszert technikai okok miatt felvált az új? Kényszerítés az, hogy ma már nem igazán kapni magnó- és videókazettákat, hanem a CD és a DVD a menő? Kényszerítés az, hogy a nagyfloppyt kiszorította a kicsi, azt meg a CD és a pendrive? Ezek sem visszamenőleg kompatibilisek. Ám legyen.
De ugyan miért is tenné ez nehezebbé vagy lehetetlenné a jelenlegi rendszerek használatát? Ezt egyáltalán nem értem. Azt sem, hogy mit értesz „jelenleg használt rendszer” alatt.

Az alkalmazások túlnyomó többségének nemzetköziesítése nem oldható meg az ISO-8859-2, vagy bármely más ISO-8859-* karakterkészlet segítségével. De nemcsak a nemzetköziesítés nem oldható meg: még az sem oldható meg, hogy ha egy magyar dokumentumot átviszel a szomszéd gépére, akinek más nyelvű az oprendszere, akkor azon megnézve vagy kinyomtatva magától kapásból jó legyen. Egyszerűen nem volt más út, mint másmilyen karakterkészletet választani. Összesen két út van: a régivel kompatibilis, ami minden kétséget kizáróan járhatatlan, és egy új, ami járható. Te szemlátomást a járhatatlan mellett kardoskodsz, érvként a kompatibilitást emlegetve. Igen, a kompatibilitás nagyon-nagyon fontos, de ha egyszer egy adott szituációban nem lehet megoldani, akkor nem lehet és kész, kell venni egy nagy levegőt és valamikor átállni.

> Az egyik legutóbbi húzás (i386&amd64) "összegyúrása" tipikusan ezt az irányt testesíti meg. Ez tipikusan a kernel-fejlesztőkért volt.

Nem követem a kernel fejlesztését, de kíváncsivá tettél. Ez a változás milyen szempontból éri hátrányosan a felhasználókat?

Vagy te tudsz valami okos megoldást javasolni, amivel mindenki jól járna?

Komolyra fordítva a szót nagyjából igen.

Az online "kommunikációs" részére irssi féle megoldást. Nem néztem meg hogy csinálják, de teljesen mindegy hogy iso8859-2es vagy utf-8asnak írkálok, vagy kit olvasok. mindegyik ékezetet jól látom. Nyílván azok a karakterek melyek nincsenek benne az isoban azok nem jelennek meg, de mivel megállapítuttok hogy beszűkült vagyok, és úgysem érteném, ez kb. tökmindegy. De azok amelyek mindkettőben bent vannak, legalább azok között megoldja a "kompatiblitás" kérdését. Tehát egyfajta "hybrid" kliensprogram használata.

A fájlrendszeres, doksis nézegetős témára meg nagyjából igen. Nem kell az egész rendszert átkonvertálni muszájból, ha a "helyileg uralkodó" kódolás HELYBEN nagyon domináns. Akkor az "újonc" fájlok miatt nem érdemes egy működő rendszert teljesen kiborítani,átpiszkálni. Ebben az esetben a régi fájlok vannak többségben, az újak vannak kevesebben. :-)

Nekem pl. 2005ös a /home fájlrendszerem, a / és a többi, meg még régebbi. Sajnos amikor ezek készültek, vagy ext2-ről konvertálódtak (=nem emléxem), akkor az extX-nek valszeg még nem volt "filesystem created attributum" támogatása, mert a dumpe2fs nem mondja meg ezekről hogy mikor készültek. Talán érthető, talán nem, hogy nem szívesen cseszegetem a fájlrendszert, vagy a fájlneveket, stb. úgy mindenestül. működő rendszeren általában nem érdemes változtatni...:-)

Naszóval a "nagyjából igen" ötlet, Debian alatt pl. fonty-rg console-tools csomagok segítségével az egyik konzolt pl. tty5 kell csak átbillenteni a "kompatibilitás" jegyében, tehát "hybrid-rendszer" kiépítése.

Azért többen írták, hogy jelenleg még többmindennek van ISO támogatása, mint utf.És ha már valami támogatja az ISOt, ezt már csaknem fogják kiszedni belőle.

Hogy kinek melyik irányba billen el a rendszere, az már sz'tem teljesen egyedi. A globalistáknak nyílván UTF, a magamfajta beszűkülteknek ISO.

Nyílván nincs kizárva, hogy kapok én is utf8as cuccot. vagy mobilracken egy utf8as csávó extX rendszere érkezik valamilyen karbanszarásra ;-).

Volt már erre példa, én a fenti megoldást használtam, az egyik konzolt az "action" idejére átbillentettem utf8ra.

Egy darabig / pár hónapig /ezt meghagytam, aztán nem jött több, és visszatettem a tty5öt is ISOra.

Nem követem a kernel fejlesztését, de kíváncsivá tettél. Ez a változás milyen szempontból éri hátrányosan a felhasználókat?

User számára feleslegesen termeli a potenciális inkomptabiilitási, instabilitási problémákat. Azok a külső zárt kerneldriverek, melyek i386-ra, illetve x86_64re függtek, azokat is mind át kell írni, tesztelni, anyámkínja.

Jónéhány belső kernel drivert i386ra írtak meg xmillió évvel ezelött, mert x86_64en már nincs élő ember aki használná. Pl. ki látott már ISA sínes hangkártyát x86_64es rendszeren? de most őszintén...

És akkor most van egy x86os ömlesztett kódtömeg. Amiben meg kell oldani a "normál" x86, az x86_64, és gondolom az x86_32 (a x86_64en belül levő 32bites megfejtés) együttes támogatását.

Ettől a kernel semmilyen értelemben nem lesz jobb szerintem,sem kisebb / mert az x86_64es "fájlok" x86on értelemszerűen "nem fordultak le"/, sem semmi, a fejlesztők számára lett kényelmesebb. Bizonyos függvényeket, melyeket mindkét architektúra használ nem kell 2 fájlba beleírni.

Akkor ha volt egy arch/*-on belüli biztonsági probléma, az volt hogy csak egyik architektúrát érintette /voltak i386 és x86_64 specifikus problémák, hadd ne keressem most elő az archívumból /, most lehet hogy mindekettőt fogja.

Meglesz még ennek a böjtje szerintem, bár én örülnék a legjobban ha később kiderül, hogy tévedtem. Előbb utóbb stabilizálódik, de addig sz'tem még sok víz lefolyik a giten.

Meg aztán most egészen őszintén. Nem volt enélkül is épp elég baj a kernellel. (hol is volt a regressziós listás cikk?)

A floppyra visszatérve már nem is tudom hány évvel ezelött elkezdték temetni, de azért még ma is lehet hogy adott esetben van létjogosultsága. Pl. BIOS frissítés. / tudom, freedos boot-cd, de azért az még mindég tovább tart egy boot cd elkészítése, mint rámásolni floppyra, reboot, és ASUS EZ Flash pl/. :-) /

Én pl. nem dobtam ki a floppyt. Ma is itt van. elfér a kaszniban.

bocs, hosszú lettem és csontos. :))

-----------------

Nem a zsömle kicsi, a pofátok nagy...

Az iso-8859-* kontra utf-8 automatikus detektálása egyes alkalmazásokban viszonylag jól működően megoldható, nem meglepő, ha az irssi megoldotta. A sors fintora, hogy ha konkrétan csak a magyar nyelv ékezeteit használod, akkor 100% biztonsággal megoldható a detektálás, de ha más nyelveket nézünk (hiszen nemcsak magyarok, nemcsak magyarul használják a progit), akkor megvan az esély a tévedésre.

A két karakterkészlet keverése azonban általánosan, az egész operációs rendszer minden területén egyszerűen nem tud működni. Például én elvárom, hogy ha van két ékezetes sima .txt fájlom, és mondjuk a legegyszerűbb cat paranccsal összefűzöm őket, akkor az eredményben is jók legyenek az ékezetek. Ha az egyik fájl ilyen, a másik meg olyan kódolású, akkor lehet hogy a szövegszerkesztőm okosan megtippeli a kódolást, és külön-külön mindkettőt jól jeleníti meg, de az összefűzött felemás verziót már semmiképp. Ilyen és számtalan ehhez hasonló buktató miatt a két karakterkészlet együttélése csak akkor oldható meg, ha a felhasználó kegyetlenül ért a részletekhez és tud mit kezdeni velük. De ebben az esetben is kényelmetlen és értelmetlen ez a megoldás, ha másik lehetőségként ott van az, hogy hozzáértés, állítgatás nélkül minden gördülékenyen működjön.

Érdekes azt látni, hogy hibrid rendszert javasolsz, ahol kapcsolgatod a konzolt. Tényleg ezt akarod csinálni? Eleinte az ISO-8859-2 mellett érveltél, most meg már a felemás rendszer mellett, ami nem biztos, hogy bármivel is jobb, sőt... A mai modern, UTF-8 alapú disztribúciókkal is technikailag valamelyest ezt kapod, hiszen bármikor át tudsz állni ideiglenesen ISO-8859-2-re, csak éppen nem az a default, és alapvetően nincsen szükség az átállásra. Miért jó az, hogy egyfolytában át kell állni? Nem lenne sokkal jobb egy olyan rendszert használnod, ami átállítgatás nélkül működik? Én olyat használok, és semmi gondom nincs az ékezetekkel.

Nekem is vannak még floppyjaim. Meg tudom nézni szükség esetén a rajtuk lévő adatokat. Egyre ritkábban van erre szükségem. Többek között azért, mert az új cuccokat nem floppyra mentem. A párhuzam magától értetődő a két sztori közt.

A kerneles részre rátérve:

> User számára feleslegesen termeli a potenciális inkomptabiilitási, instabilitási problémákat.

Ezt az állításodat egyáltalán nem látom megindokolva. Az instabilitást egyáltalán nem, az inkompatibilitást meg maximum annyira, hogy a felhasználónak meg kell várnia, amíg egyes modulkészítők átírják a modult, de ez architektúraváltás nélkül is nagyon sokszor így volt.

> Azok a külső zárt kerneldriverek, melyek i386-ra, illetve x86_64re függtek, azokat is mind át kell írni, tesztelni, anyámkínja.

Ez a fejlesztők dolga, nem a felhasználóké. Azokat meg hadd ne sajnáljuk már, akik zárt kerneldrivereket írnak.

> Ettől a kernel semmilyen értelemben nem lesz jobb szerintem,sem kisebb / mert az x86_64es "fájlok" x86on értelemszerűen "nem fordultak le"/, sem semmi, a fejlesztők számára lett kényelmesebb.

Ha csak annyit értünk el, hogy a fejlesztő számára kényelmesebb lett, akkor már megérte, és áttételesen a felhasználó számára is jobb lesz. Miért? Azért, mert a fejlesztőknek több idejük lesz értelmes dologgal foglalkozni, felhasználókat is érintő hibákat javítani, és szívesebben is fognak dolgozni, ha nem kell értelmetlenül dupla munkát végezniük. És hogy az ISA rendszer is közös i386/x86_64 kódbázis fogja kezelni? Felhasználóként ugyan mit érdekel engem? Az érdekel, hogy működik-e. A fejlesztőkre bízom, hogy megtalálják annak a módját, hogyan tudnak hatékonyan dolgozni. Ha azt állítják, hogy egy ilyen átállás segít nekik, akkor további információ híján megbízom bennük, elhiszem nekik, és örülök mert ezáltal közvetve nekem, felhasználónak is jobb lesz.

Nekem is vannak még floppyjaim. Meg tudom nézni szükség esetén a rajtuk lévő adatokat.

Tehát hybrid rendszert használsz te is. :-)

ha más nyelveket nézünk (hiszen nemcsak magyarok, nemcsak magyarul használják a progit), akkor megvan az esély a tévedésre.

Igen, és itt jön képbe az én jó kis beszűkült látásmódom. :-)))

hogy hozzáértés, állítgatás nélkül minden gördülékenyen működjön.

Ha kapsz egy extX-es fájlrendszert, doksit, stb. iso8859-2ben, neked is át kell át kell állítani egy konzolt.

bármikor át tudsz állni ideiglenesen ISO-8859-2-re
Én is bármikor át tudok állni ideiglenesen UTF8ra, mint már volt rá példa. csak én nem az unicode_stop hanem az unicode_start aprancssal. :-)
de ha állandó UTF8ra állítok egy konzolt, akkor ennyi sem kell. egyszerűen egy ctrl-alt-f5öt kell nyomni. És mindezt anélkül hogy a rendszer többi részéhez hozzá kelljen nyúlni.

Volt már ilyen, csak azért állítottam vissza, mert helyileg NEKEM AZÓTA nem volt igény UTF8ra, mint mondtam pár hónapig meghagytam a "rendhagyó konzol"-t, hogy mi lesz hogy lesz, aztán nem jött semmi ami miatt kellett vóna, úgyhogy vissza a helyi status quo-hoz. nyílván a helyzetem nem általánósítható, merülnek fel másoknál olyan igények, ami miatt ez másnál nem járható.

Én olyat használok, és semmi gondom nincs az ékezetekkel.
Nekem sincs. Csak én iso8859-2t használok, te meg UTF8at. neked az jön be, nekem meg ez. :-)

Miért? Azért, mert a fejlesztőknek több idejük lesz értelmes dologgal foglalkozni, felhasználókat is érintő hibákat javítani, és szívesebben is fognak dolgozni, ha nem kell értelmetlenül dupla munkát végezniük.

Meglátjuk, ezt szerintem az idő fogja eldönteni. Vagy több idejük lesz értelmesebb dolgokkal foglalkozni, vagy pedig az architektúrális összevonásból eredő bugok javításával megy el a nyert plusz idő valahányszorosa. Ezt az idő majd eldönti. Ha fejemre olvasod/olvassátok 1 év múlva 2.6.30 vagy mittom mi lesz, és nem okozott gondot, nem szégyellem beismerni azt, hogy tévedtem. :-)

ha viszont jönnek a jó kis bugok, amik 2.6.24 alatt csak egyik architektúrát , 24 felett meg érintik mindkettőt akkor meg fordítva. :-) 

Megjegyzés:

Sajnos :-) a kernelfejlesztők is emberek, ők is hibáznak, legyen az akár kódtisztítás, stb... Mikor a grsec-MSI-stb. backportot csináltam magamnak, akkor szembesültem ezzel a helyzettel. Voltak olyan forrásfájlok, melyek x86_64 alatt lefordultak, x86 alatt meg nem, és akkor az volt a megoldásuk, hogy x86 alatt nem fordították le a kérdéses fájlt. :-), és volt több hasonló is. Akkor volt egy két félresikerült kódtisztítás. Az egyik pl. ennek az "összevonásnak" az előfutára. Volt egy cuccos, ami élt i386ban is és x86_64ben is. Ennek a deklar.-át áttették az "univerzális" helyről az x86_64be. Aztán úgy döntöttek, hogy az egész nem ér semmit, és az egész cuccot kipucolták, a def-et meg bentfelejtették az x86_64/proto.h-ban. :-)

Itt van ni include/x86/proto.h. Még ma is benne van. A kutya nem vette észre hogy tökfölösleges 2.6.19rc akárhány óta. Persze nyílván kételkedsz az állításomban, jól teszed, keress rá a gsi_irq_sharing kifejezésre a forráskód könyvtárban. gépsebességtől függ, de mire lefőzöl egy kávét biztos végez, hogy hol találni még ilyesmit. / persze ha 2.6.22+ben visszarakták, akkor most öngolt lőttem, de nem hiszem, úgyhogy ezt a pofáraesést vállalom. :-) /

Nyílván működés szempontjából ez speciel sem nem oszt se nem szoroz, de jelzi, hogy bizony az összevonósdi azért hozzátesz az "elnéztem" faktorhoz a "kényelmesebb fejlesztés mellett".

Annyit még hozzátennék, hogy backportos házi barkácsolásom során a forráskód kevesebb mint 1%val "foglalkoztam". Vajon mi lehet a maradék 99%ban ? 

Megjegyzés vége

----------

Nem a zsömle kicsi, a pofátok nagy...

[floppy] > Tehát hybrid rendszert használsz te is. :-)

Tippeld meg, mikor használtam utoljára floppyt. Én nem emlékszem, de kábé 5 évvel ezelőttre tippelnék. Ha akarom, még mindig tudok floppyt használni, de nincs rá szükségem, mert átálltam másmilyen adathordozókra.

Nade vissza az igazi témánkhoz:

> Ha kapsz egy extX-es fájlrendszert, doksit, stb. iso8859-2ben, neked is át kell át kell állítani egy konzolt.

Speciel nem konzolt állítok át (nem is igazán használom a Linux konzolt), hanem indítok mondjuk egy luit-ot, vagy az alkalmazást állítom át latin2 karakterkészletre, vagy méginkább parancssorban átalakítom a fájlnevet és tartalmat a saját diszkemre átmásoláskor. Te a unicode_start parancsot használod, de más hozzászólásaidból kiderült, nem vagy tisztában azzal, hogy ennél több teendő van (pl. környezeti változók átállítása) ahhoz, hogy tisztességesen átállítsd UTF-8-ra a rendszert. A unicode_start csak egy lépés a sokból, ami önmagában egy következetlen, rossz rendszert eredményez, ahol jó eséllyel egyetlen ékezet sem látszik jól. De ezek mind technikai részletkérdések. A lényeg: igazad van, ilyenkor valamit nekem is át/be kell állítanom.

> Nekem sincs. Csak én iso8859-2t használok, te meg UTF8at. neked az jön be, nekem meg ez. :-)

Oké, értem, rendben van. Az előző hozzászólásaimban többek között az alábbiakat próbáltam meg sok más hozzászólóval együtt objektív érvekkel megindokolni, abban reménykedve, hogy legalább picit elgondolkodtatlak:

- Az Alt+F5 megoldás arra jó, hogy mondjuk egy pendrive fájljait ideiglenesen jól jelenítsd meg, de ha ezeket a fájlokat átmásolod magadnak, akkor vagy következetlen, össze-vissza kódolású rendszert kapsz (és ugyanmár micsoda dolog az, hogy az egyik fájlodat csak az egyik konzolban tudod jól megnézni, a másik fájlodat meg csak a többiben? én mindegyik fájlomat mindenhol jól látom), vagy pedig át kell alakítani a fájlok nevét és tartalmát.

- Általános tendencia az iso-8859-2-ről vagy bármi egyébről utf-8-ra átállás. Ennek következtében az idő múlásával nekem egyre ritkábban, neked viszont egyre gyakrabban kell majd vagy ideiglenesen átállnod, vagy átalakítanod a fájlt.

- Ha én kapok egy iso-8859-2 kódolású fájlt, garantált, hogy az átalakítás után is tökéletesen látom a tartalmát. Ha te kapsz egy utf-8 kódolású fájlt, az átalakítás során adatot veszthetsz, például ha történetesen van benne igazi magyar „idézőjel”, vagy euró jel (ami a magyar billentyűzetkiosztáson is szerepel, tehát mágia nélkül bárki, aki utf-8-as rendszert használ, a karakterkészletek ismere nélkül is simán begépelheti), akkor ezeket nem látod.

- Ha én átküldöm a fájlomat a szomszédnak, akinek lehet hogy angolra, oroszra, japánra, héberre van beállítva a rendszere (ezt én nem tudom) és megkérem hogy olvassa el vagy nyomtassa ki, akkor (feltételezve, hogy kellően új rendszere van, ami ma már elég valószínű, és az idő múlásával méginkább az lesz), bármiféle mágia nélkül jól el tudja olvasni és jól ki tudja nyomtatni. Még akkor is, ha az én fájlomban nemcsak magyar, hanem bármilyen egyéb karakterek vannak. Ha te megkéred ugyanezt a szomszédot, hogy a fájlodat nézze meg vagy nyomtassa ki, nagy valószínűséggel kalapos-hullámos ékezeteket vagy teljesen hibás olvashatatlan hieroglifákat fog látni a képernyőn és kinyomtatni számodra, még akkor is, ha csak magyar ékezeteket használtál.

Ilyen és ehhez hasonló objektív érvek szólnak az utf-8 mellett, és ezek miatt áll át szép sorban mindenki... Jelen írásommal nem az a célom, hogy téged is „megtérítselek”, csak az, hogy megértsd, miért is terjed az utf-8. A többi idővel úgyis jön magától, még ha most nem is hiszed :-)

hogy tisztességesen átállítsd UTF-8-ra a rendszert.

Na akkor ezt kifejtem bővebben. 1. lépésként a tty5 átállítása a LatChr(akarmi)-16 / fejből nem vágom /, vagy a chavo karakterkészletre a console-tools segítségével. Utána a fonty-rg-ben levő utf8 parancs indítja az unicode_start ot többek között, illetve az iso 2 az unicode_stop -ot.

Az (LC_*) környezeti változókat így nem kell átállítani. A rendszerüzenetek ékezet nélkül jelennek meg (éppen ezért), viszont utf8 fájlrendszer nézegetésére, utf8 doksik olvasására alkalmas módszer. meg az mc-is kicsit betörötten néz ki. De nézegetésre, karbantartásra megfelelő.

- de ha ezeket a fájlokat átmásolod magadnak, akkor vagy következetlen, össze-vissza kódolású rendszert kapsz (és ugyanmár micsoda dolog az, hogy az egyik fájlodat csak az egyik konzolban tudod jól megnézni, a másik fájlodat meg csak a többiben? én mindegyik fájlomat mindenhol jól látom), vagy pedig át kell alakítani a fájlok nevét és tartalmát.

Ezért írtam a megoldásra, hogy "nagyjából igen".nyílván ami kell azt majd konvertálom, de egyszerűbb a kevés újat a sok régihez, mint a sok régit a kevés újhoz konvertálni... :-)

akinek lehet hogy angolra, oroszra, japánra, héberre van beállítva a rendszere (ezt én nem tudom) és megkérem hogy olvassa el vagy nyomtassa ki, akkor (feltételezve, hogy kellően új rendszere van, ami ma már elég valószínű, és az idő múlásával méginkább az lesz), bármiféle mágia nélkül jól el tudja olvasni és jól ki tudja nyomtatni.

Ezt egyszerűen kivédtem. Nincsenek ilyen szomszédaim. :))

például ha történetesen van benne igazi magyar „idézőjel”, vagy euró jel (ami a magyar billentyűzetkiosztáson is szerepel, tehát mágia nélkül bárki, aki utf-8-as rendszert használ, a karakterkészletek ismere nélkül is simán begépelheti), akkor ezeket nem látod.

Jó, ez OK, de ettől még megértem amit ír.én beszűkült igénytelen vagyok, nekem elég az árvíztűrő tükörfúrógép. :-)

A többi idővel úgyis jön magától, még ha most nem is hiszed :-)

Meglátjuk. :)). csak aztán nehogy 3 év múlva valami utf16on találjuk magunkat. :)))

-----------

Nem a zsömle kicsi, a pofátok nagy...

> Az (LC_*) környezeti változókat így nem kell átállítani.

Már meg ne haragudj, de te aztán tényleg nagyon értesz hozzá. Ugyan miért is kellene átállítani ezeket a változókat?

Talán azért, mert az alkalmazások túlnyomó többsége (például az mc is) ezekből (egész pontosan LC_ALL, LC_CTYPE és LANG) derítik ki, hogy a terminálnak mi a karakterkészlete?

A fent leírt módon egy olyan terminált kapsz, ami utf-8 módban viselkedik, miközben az alkalmazásokat továbbra is úgy tájékoztatod, hogy a terminál latin-2 karakterkészletet használ. Aztán csodálkozol, ha az mc kicsit betörötten néz ki, máskor meg a fájlnévben kérdőjelek vannak az ékezetek helyett. Ez amit itt összeraksz, ez egy abszolút hibásan összerakott rendszer. Ez se nem latin-2, se nem utf-8 rendszer, hanem valami nemlétező totálkáros egyveleg.

Érdekes, határozottan úgy emlékszem, hogy erre a hibára néhány napja másvalaki már felhívta a figyelmedet ebben a topicban. Kár, hogy nem vetted észre, vagy nem hallgattál rá.

Egyre biztosabb vagyok benne, hogy úgy alkotsz véleményt a latin2 kontra utf8 kérdésről, hogy helyesen összerakott utf8-as rendszert még nem láttál működni, továbbá úgy látom, hogy nem is igazán szívesen tanulsz másoktól. Ebben az esetben viszont semmi értelme folytatni ezt a beszélgetést.

> csak aztán nehogy 3 év múlva valami utf16on találjuk magunkat.

Ha kicsit tájékozottabb lennél a karakterkészletek terén, akkor látnád, hogy ez az állítás több szempontból is egy bődületesen nagy baromság. Bocsi, nem pazarlom az időmet ennek a kifejtésére, mert úgy tapasztaltam, hogy csak belekötni próbálnál abba amit írok, nem pedig megérteni. Ha rosszul látom, és érdekel hogy miért baromság, akkor elnézést kérek, szólj és leírom.

Ez se nem latin-2, se nem utf-8 rendszer, hanem valami nemlétező totálkáros egyveleg.

Igazad van. Be kell lássam.

Úgyhogy módosítottam a hybrid rendszeres elképzeléseken. Találtam egy UTF8as example tesztet, ehhez "igazítom" a dolgokat a tty5ön.

Ezt mind nem fogom végigcsinálni, mert ez a teljes rendszert átborítja. Nekem meg valami hybrid megoldás köllene csak tty5re.

A locale körny. változók átállítása nélkül sehogy sem úszom meg, úgyhogy tty5ös bejelentkezés után ezt meg köll csinálni.

Lépésről lépésre leírom mit csináltam, és hogy meddig jutottam. Mert most eljutottam oda, hogy tanácstalan vagyok.

Nos tehát etc/console-tools/config.d/fonty-ban a screen_font_vc5=LatCyrGr-16-ra állítottam app_charset_map_vc5=user, console-tools restart, majd bejelentkeztem tty5ön, a locale változók (LC_ALL, LANG) kaptak egy .UTF8at, majd kiadtam az utf8 parancsot, hogy az unicode_start meg a többi lefusson.

majd zcat UTF example...

És az a bajom, hogy a helyzet felemás, ill. 3/4ed más. Euro jel, meg ilyesmi van, a Greek (in polytonics) test, meg a Russian,meg az Euro test jó, de némelyik testben vannak inverz ?-ek.

Pl. a georgian és a Thai az nem jó.

valami nem jó, de fogalmam sincs hogy mi.

SZERK: talán másik fontot kellene választani ? de melyiket? sem a chavoval, sem LatCírHebbel, sem ezzel nem ad a teszt 100%ot.

Ha rosszul látom, és érdekel hogy miért baromság, akkor elnézést kérek, szólj és leírom.

utf16 vicc volt, szmájli ott van a végén, mindjárt három is. :-)

--------------

Nem a zsömle kicsi, a pofátok nagy...

> A locale körny. változók átállítása nélkül sehogy sem úszom meg

Hmmm, az előbb mintha még nem ezt mondtad volna...

> És az a bajom, hogy a helyzet felemás, ill. 3/4ed más. Euro jel, meg ilyesmi van, a Greek (in polytonics) test, meg a Russian,meg az Euro test jó, de némelyik testben vannak inverz ?-ek.

A Linux kernel UTF-8 támogatása igencsak korlátozott. Egyszerre csak az előre betöltött fontkészlet legfeljebb 256 vagy 512 karakterét tudja megjeleníteni (512 esetén a fényesség attribútum rovására), illetve mintha tudna olyat is, hogy egy nagyobb karakterkészletből választ dinamikusan a megjelenítendő tartalom alapján, de ez se jó, ha egyszerre túl sokféle karaktert akarsz megjeleníteni. VGA konzol esetén ez magának a hardvernek a korlátozottsága, framebuffer esetén elvileg meg lehetne csinálni, de nagyon nagy átalakítást igényelne, hiszen a framebuffer is a karakteres VGA mód kódjából használ részleteket, amit annak idején nem terveztek Unicode támogatásra, és senkinek sincs kedve, ideje átírni. Továbbá a kernel fejlesztői azon a véleményen vannak, hogy a kernel konzolja egy vésztartalék, szükség esetén viszonylag jól működő megoldás, de igazán tisztességesen működő terminált tessék felhasználói programként csinálni.

Mindemellett ha bárki előáll egy tisztességesen megcsinált rendes Unicode támogatással, valószínűleg viszonylag könnyen letolható a torkukon, hogy berakják. Én nem értek ennyire a kernel programozáshoz hogy újraírjam a konzolkezelést (persze idővel mindent meg lehet oldani, csak ennyi időm nincs és nekem nem éri meg, mert grafikus terminált használok), bár apróbb UTF-8 kezelési patcheim vannak már benne. Ha gondolod, hajrá! :-)

Hmmm, az előbb mintha még nem ezt mondtad volna...

Te bűnöd. :))) meggyőztél.

ill. az utf-es test és te győztetek meg.

Egyszerre csak az előre betöltött fontkészlet legfeljebb 256 vagy 512 karakterét tudja megjeleníteni (512 esetén a fényesség attribútum rovására), illetve mintha tudna olyat is, hogy egy nagyobb karakterkészletből választ dinamikusan a megjelenítendő tartalom alapján, de ez se jó, ha egyszerre túl sokféle karaktert akarsz megjeleníteni.

Na, akkor nem is erőlködök tovább, pedig már veszettül lestem a debecsben levő elérhető konzolfontos csomagokat / nem röhögnek :)) /, hogy mi az francot lehetné még kitalálni...De akkor ez a max. jelenlegi állás szerint.

U.I.:

Deb etch release notesben találtam:

The package utf8-migration-tool contains a tool that may help the migration, however that package is only available in unstable[/b] as it was not ready in time for etch. Making a backup of your data and configuration before using the tool is strongly recommended.

Azért rendesek. végül is ne szarjak be annyira, ha majd egyszer valamikor átállok utf8ra, de azért a migrációs segédeszköz csak kb. fejlesztői verzióba van, meg mentsek le mindent amim van, mielött majd lefuttatom... :))

De azért belerakták defaultnak az utf8at... /ejj de morcos vagyok az ilyesmire /

SZERK: már a lennyben is megvan...addig biztos kihúzom, aztán meglátjuk :-)

-------

Nem a zsömle kicsi, a pofátok nagy...

3. időnként hoznak ide mindenféle "anyagot", ami szintén olvashatatlan lenne. :-)

Ne haragudj meg, de eleg hosszu ideje utf-8-as alaprendszert hasznalok, es soha nem talalkoztam olvashatatlan fajllal. Pendrive, felcsatolt lemezek, CD/DVD mind csont nelkul megy. Az mar mas kerdes, hogy szorultam arra, hogy WinSCP-vel windozra huzzak at ekezetes fajlokat, na az tudott vicces karaktereket produkalni a fajl neveben a celgepen, ezt elismerem. Ez viszont meg mindig elenyeszo problema, igy nem nagyon hiszem, hogy ez egy komoly erv.

Egyebkent no offense, es azt hasznalsz, amit akarsz, eszem agaban sincs meggyozni, csak ezt le kellett irnom. ;-)
--
Bárki aki aritmetikai módszerekkel akar előállítani egy véletlen számot, az a bűn állapotában leledzik.

Hátha én nem codepage=852,iocharset=iso8859-2vel csatolok be egy idelátogató fat32-t, annak mindig az a vége, hogy előkerülnek a jó kis kérdőjeles/nem megfelelő/hieroglifikus fájlnevek. ugyanezt tapasztaltam ntfs-nél is az idelátogató xp-s rackes vinyóknál ha nem nls=iso8859-2 (vagy mifene fejből most nem vágom 14 órás meló után) volt a mountopcsön.

Az iocharset utf8 "opció", pedig hivatalosan sem ajánlott, lásd lentebb.

Egyebkent no offense, es azt hasznalsz, amit akarsz, eszem agaban sincs meggyozni, csak ezt le kellett irnom. ;-)

Vettem. ;-)

-------------

Nem a zsömle kicsi, a pofátok nagy...

Naná, hogy ha elkezdesz a mount opciókon variálni, akkor nem lesznek jók az ékezetek. Nem úgy működik ez, hogy megadok bármit, hadd szóljon!

A mount opcióban azt a karakterkészletet kell megadnod, amit az operációs rendszered alkalmazásai mind egy szálig használnak, és amire ezáltal a fájlnevekben is számítanak. Ha az iocharset-et átírod utf8-ra, annak csak úgy van értelme, ha ezzel együtt a rendszered egyéb beállításait is utf8-ra alakítod. Ez grafikus környezetre talán nem olyan bonyolult, a Linux konzol esetén viszont igencsak összetett, több lépéses művelet. Viszont ha ezt megteszed, vagy olyan disztribúciót használsz, amelyik megteszi helyetted, és ezzel egyidőben állsz át az iocharset=utf8 opcióra, akkor hidd el, tökéletesek lesznek a fájlnevek, semmi kérdőjel, semmi hieroglifa.

nyílván azért kell variálni mert az alappal ((cp437,iocharset iso8859-1) ;-) / forrás man mount / nem jók az ékezetek .

Ha az iocharset-et átírod utf8-ra, annak csak úgy van értelme, ha ezzel együtt a rendszered egyéb beállításait is utf8-ra alakítod.

Igen és ezzel mindjárt saját magammal baszok ki mert konvertálni kell.

és ezzel egyidőben állsz át az iocharset=utf8 opcióra, akkor hidd el, tökéletesek lesznek a fájlnevek, semmi kérdőjel, semmi hieroglifa.

1. Akkor is ha a fájlokat iso8859-2es winekkel hozták létre ? ugye a mobilracken érkező fat32es partíciókkal ellátott történet...
2. utf8 is not reccommended on fat...lásd fent/lent. különösen idegen vinyókon azért nem szívesen.
3. archívum. múlt héten is kellett keresni a 2005ösben.

---------

Nem a zsömle kicsi, a pofátok nagy...

( padawan | 2008. 01. 29., k – 18:12 )

Ez kicsit olyan mint ennek a szovege.
Mindenki tudja, hogy utf8 a jobb es a "jovo" megis odzkodnak tole.

"Megszületett az ISO-8859-2 (Latin-2), amely az összes magyar ékezetet tartalmazza, tehát lényegesen jobb, de a magyar tipográfiának megfelelő nagykötőjel és idézőjelek, valamint sok egyéb fontos szimbólum ebből is hiányzik."

- innentől akkor talán nincs is értelme tovább vitatkozni... :O

( snowflake v | 2008. 01. 29., k – 19:52 )

utf-8 rulez, gyk. egyszer kell megejteni a fájdalmas átállást az érintett rendszereken, azután el is lehet felejteni a karakterkódolás fogalmát.
Persze ez csak papíron igaz, mert mindig lesz olyan rendszer ami iso-t használ, és olyankor lehet örömködni... :(

( tade v | 2008. 01. 29., k – 20:54 )

Szavaztam amint eszrevettem, aztan elgondolkoztam, semmi ertlme nincs ennek a szavazasnak... :(

( egmont | 2008. 01. 29., k – 22:12 )

Hol marad a CWI-2 és a CP852? :-)

Egyébként az ISO-8859-16 a legjobb! Nagyokosok rájöttek, hogy elég gáz, hogy az euró jel (€) nincs benne a hagyományos 8-bites karakterkészletekben, ezért az iso-8859-1-en picit módosítva létrehozták az iso-8859-15-öt. Aztán arra is rájöttek, hogy talán előbb-utóbb Közép-Európában is euró lesz, ezért kell ám egyszerre ő és ű betű, na meg € is, nosza, csináljunk egy iso-8859-16-ot. Örö és bódottá. Ugye mindenki ezt használja? Ja, hogy az ű betű kódja más, mint az ISO-8859-2-ben? Ugyanmár, kit izgat?!? ;-)

( sumo | 2008. 01. 29., k – 23:43 )

önös érdekből egyértelműen utf-8 - nekem.
évekig izraelben éltem, sok barátot szedtem össze, különböző országokból. marha jól jön, hogy egyszerre tudok chatelni héberül, angolul és/vagy magyarul.
::sumo.conf::

( gsimon | 2008. 01. 30., sze – 08:44 )

Igazából a jó öreg 4-byte-per-karakter UCS4 lenne az igazi.
Az egy byte-os kódolások a kódlap-mizéria miatt felhasználói szempontból szörnyűek, az UTF-8 meg a változó karakterhossz miatt programozói nézőpontból ocsmány.
Miért nem lehet végre elfelejteni a byte-ot, (ahogy az oktális számolás is szépen muzeálissá vált,) és szépen, korrektül áttérni a 32-bites karakterábrázolásra?
(Igen, több memóriát eszik, de most mondja valaki, hogy ez bárhol is szempont, a programok memóriaigényének az alakulását elnézve...)

(Igen, több memóriát eszik, de most mondja valaki, hogy ez bárhol is szempont, a programok memóriaigényének az alakulását elnézve...)

Egy regi-vagasu asm-guru keresztre feszitene egy ilyen mondatert! :-D
--
Bárki aki aritmetikai módszerekkel akar előállítani egy véletlen számot, az a bűn állapotában leledzik.

Hát, réginek régi vagyok, a basic után az asm volt a második nyelvem, és már azt sem értettem, hogy mire fel képes egy rojtos shell két megabyte-ot felzabálni, amikor ugye 64k-ban csodákat lehetett művelni :).
Viszont amikor azt látom, hogy bármi épeszű funkcionalitáshoz vagy fél giga ram kell a gépbe, vagy kávéfőző a várakozások áthidalásához, akkor hajlok arra, hogy vigye ürdöng, kelljen bele 768M, de akkor végre felejtsük el a változó hosszúságú kódokat.
Határozottan frusztráló érzés egy utf8-as szövegben pl. az n. karakterre lépést leprogramozni: csak lineárisan végiglépkedve lehetséges. Aztán a 'vissza 42-vel'-nél ugyanez egy hatos vissza-tekintő automatával... Szóval Romhányi szavaival élve: "önmagánál rútabb, olyannyira ronda".
Anno egyszer kellett írni egy (részleges) regex illesztőt, ami nem ragadt le a 8bites asciinél - hát utf8-ban elkezdtem, aztán az oda-vissza lépkedés kapcsán azt mondtam, hogy fenét, tessék beolvasáskor ucs4-re alakítani, és onnantól fog működni :).

Más.
Mivel vannak itt hozzáértők is, megkérdezném, hogy a karakterábrázolás mellett a rendezéssel most hogy áll a tudomány? Tehát pl. van-e mód arra, hogy a "csokoládé" a "cukor" utánra kerüljön ("c" < "cs")? Bár mondjuk az "sz" és "zs" tokenizálása még mindig megoldatlan marad ("egészséges liszteszsák": "sz+s", "s+zs"), úgyhogy erre megoldást talán csak az összetett betűink egy-egy kóddal való jelölése adhatna. Hmm.

Szerk.: Az utf8 helyett mit szólnátok egy ucs4+gzip kombinációhoz :)? Tömör is, meg könnyen elemezhető is :).

Előrebocsátom, hogy nem értek a programozáshoz, de nincsenek UTF-8-hoz libek, amik megcsinálják a lépkedéseket helyetted, és nem kell mindekinek újraprogramoznia? Ez lenne a jóhackeremberi hozzáállás.

Az UCS-4+gzip nekem is eszembe jutott, úgyhogy szerintem jó ötlet :)

php esetében mbstring http://hu.php.net/mbstring
(a sebesség meg mindegy, 768MB RAM mellé úgyis dukál egy 2GHz körüli processzor)

u.i.:mi a lócsöcsnek kompresszálni szöveges tartalmat? Ha gyors a kapcsolat a doboz két vége között, minek? Ha lassú, akkor meg azért minek?

Au, ez fájt!
Mármint nem a tömörítés elvetése, az viccnek szántam, de "a sebesség mindegy"... Jaj. A proci sebessége a konstans szorzó erejével gyorsít, az egyesével léptetés helyett a belecímzés pedig az n lépés helyett csak 1-et igényel. Függetlenül a proci sebességétől.
Mondhatni egy százezer négybyte-os karakterből álló szövegnek a 58716. karakterét hamarabb ássa elő egy 386dx40, mint amennyi idő alatt egy százezer utf8-as karakterből álló szöveg 58716. karakterét egy 25 GHz-es core5trio, mert az előbbi 1 db memóriaolvasás (pl. mov eax, szoveg[4 * ebx]), az utóbbinak pedig végig kell olvasnia a keresett előtt lévő összes karakter összes byte-ját.

Nem teljesen értek veled egyet, bár a különbség tényleg csak a teljesítmény szempontjából számít, ott viszont igencsak, ugyanis _minden_ stringen végzett művelet lépésigényét O(n)-nel szorozza, ha a belső ábrázolás utf8-as, ami mondjuk egy webes alkalmazásnál sem mindegy.

Bár alapvetően inkább perl-párti vagyok, ahogy elsőre utánanéztem, a php-nél is gondoltak erre, és állíthatóvá tették a belső ábrázolást a php.ini 'mbstring.internal_encoding' sorával.
Ha ez tényleg azt csinálja, amit gondolok, akkor az általad javasolt 'mb_.*' tényleg helyes, és még gyors is tud lenni :).

Viszont most, hogy felvetődött, megnéztem a perl viselkedését (mert szégyenszemre a belső ábrázolását eddig nem figyeltem), és ahogy látom, biza utf8! Működik éppen rá minden szépen: 


fules@chaos:/tmp$ echo "árvíztűrő tükörfúrógép" | hexcat
00000000 - c3 a1 72 76  c3 ad 7a 74  c5 b1 72 c5  91 20 74 c3  ..rv..zt..r.. t.
00000010 - bc 6b c3 b6  72 66 c3 ba  72 c3 b3 67  c3 a9 70 0a  .k..rf..r..g..p.
fules@chaos:/tmp$ echo "árvíztűrő tükörfúrógép" | perl -ni -e 'use encoding "utf8"; print substr($_, 5, 10)."\n";'
tűrő tükör

De belül utf8-at használ az ebadta :(. (Lehet, hogy valahogy rá lehet beszélni értelmesebbre, de ennek utána kell néznem.) 


fules@chaos:/tmp$ perl -e 'print "nesze: árvíztűrő tükörfúrógép\n"; kill 6,$$;'
nesze: árvíztűrő tükörfúrógép
Aborted (core dumped)
fules@chaos:/tmp$ hexcat core | grep nesze
00000500 - 70 72 69 6e  74 20 22 6e  65 73 7a 65  3a 20 c3 a1  print "nesze: ..
000240d0 - 6e 65 73 7a  65 3a 20 c3  a1 72 76 c3  ad 7a 74 c5  nesze: ..rv..zt.
00024470 - 6e 65 73 7a  65 3a 20 c3  a1 72 76 c3  ad 7a 74 c5  nesze: ..rv..zt.

Szerk.: UTF8, pont. Na most vagy kerítek egy ideológiát az utf köré, vagy elismerem, hogy itt a perl lesz a lassabb. Tényekkel ne vitatkozzunk, maradok az utóbbinál :).

Egyrészt "Nem teljesen, mert..."-tel kezdtem, másrészt azért, mert csak később olvastam utána a php beállításainak, és aztán elfelejtettem javítani.

A "nem teljesen"-t amúgy a "mellékes a végfelhasználó szempontjából ha működik"-ra gondoltam, ugyanis volt már szerencsém olyan esethez, amikor a felhasználók által összerakott és ftp-vel (igen, tudom...) a szerverre feltolt szöveges adatfile-okat kellett odafenn megrágni és adatbányába átlapátolni, és bizony a nagyobbjánál le-letelt a feldolgozási időkorlát, és így bizony nem volt mindegy, hogy tudtunk-e 'seek'-elni a bejövő szövegben karakterpozíció szerint.

Leteszteltem, a kódot lásd lentebb. A php.ini-ben két változás volt:
- 'memory_limit = 256M', hogy elférjen a szép nagy unistring :)
- 'mbstring.internal_encoding = UTF-8' ill. '= UCS-4' a teszteléshez

Az eredmények magukért beszélnek:
- utf8: 


substr($x, 33554432, 1): 0.210611104965 sec -> avg=318.638772685 pos/usec
substr($x, 33554432, 1): 0.211586952209 sec -> avg=317.169198286 pos/usec
substr($x, 33554432, 1): 0.211588859558 sec -> avg=317.166339193 pos/usec
substr($x, 33554432, 1): 0.210678815842 sec -> avg=318.536364142 pos/usec
substr($x, 33554432, 1): 0.210830926895 sec -> avg=318.306545384 pos/usec
substr($x, 33554432, 1): 0.211280107498 sec -> avg=317.629827032 pos/usec

- ucs-4: 


substr($x, 33554432, 1): 3.09944152832E-06 sec -> avg=21651921.2854 pos/usec
substr($x, 33554432, 1): 2.14576721191E-06 sec -> avg=31274997.4123 pos/usec
substr($x, 33554432, 1): 2.86102294922E-06 sec -> avg=23456248.0592 pos/usec
substr($x, 33554432, 1): 2.86102294922E-06 sec -> avg=23456248.0592 pos/usec
substr($x, 33554432, 1): 2.14576721191E-06 sec -> avg=31274997.4123 pos/usec
substr($x, 33554432, 1): 2.14576721191E-06 sec -> avg=31274997.4123 pos/usec
substr($x, 33554432, 1): 1.90734863281E-06 sec -> avg=35184372.0888 pos/usec
substr($x, 33554432, 1): 2.86102294922E-06 sec -> avg=23456248.0592 pos/usec
substr($x, 33554432, 1): 1.90734863281E-06 sec -> avg=35184372.0888 pos/usec

A tesztprogi: 


#!/usr/bin/php
<?php
$x = 'új fűszárítógépünkön kávészínű lódöghúst főzünk';
# strlen($x) = 47

for ($i = 0; $i < 20; $i++)
  $x .= $x;
# strlen($x) = 47 * (1 << 20) = 47 Mchar

$delta = 0;
for ($i = 1; ($i < (47 * (1 << 20))) && ($delta < 1); $i <<= 1)
{
  $t_start = gettimeofday(true);
  $y = mb_substr($x, $i, 1);
  $t_end = gettimeofday(true);

  $delta = $t_end - $t_start;
}

if ($i >= (47 * (1 << 20)))
  $i >>= 1;

echo "substr(\$x, $i, 1): $delta sec -> avg=".($i / $delta / 1e6)." pos/usec\n";
?>

Konklúzió:
- UCS4-nél a felhasznált idő a 32M-s pozícionálásnál is a mérési pontosság körül van
- UTF8-nál határozottan mérhető, és határozottan lassabb
- A sejtést innentől igazolódni látom :).
- Akinek van memória a gépében és számít a sebesség, az tegye át az mbstring.internal_encoding-ot UCS4-re.

Igaz, nézzük.
- mb_strpos: 


#!/usr/bin/php
<?php
$x = mb_convert_encoding('új fűszárítógépünkön kávészínű lódöghúst főzünk', mb_internal_encoding(), 'UTF-8');
$vesz = mb_convert_encoding('vész', mb_internal_encoding(), 'UTF-8');
$vasz = mb_convert_encoding('vász', mb_internal_encoding(), 'UTF-8');

for ($i = 0; $i < 20; $i++)
  $x .= $x;
# strlen($x) = 47 * (1 << 20) = 47 Mchar

$t_start = gettimeofday(true);
$y = mb_strpos($x, $vesz);
$t_end = gettimeofday(true);
echo "chk #0: pos=$y time=".($t_end - $t_start)." sec\n";

$t_start = gettimeofday(true);
$y = mb_strpos($x, $vasz);
$t_end = gettimeofday(true);
echo "chk #1: pos=$y time=".($t_end - $t_start)." sec\n";
?>

UTF-8: 


chk #0: pos=23 time=4.2200088501E-05 sec
chk #1: pos= time=1.96387290955 sec

chk #0: pos=23 time=4.19616699219E-05 sec
chk #1: pos= time=1.96743321419 sec

UCS-4: 


fules@chaos:~/src/php_unicode_test$ ./test.php 
chk #0: pos=23 time=5.10215759277E-05 sec
chk #1: pos= time=4.12724995613 sec

chk #0: pos=23 time=5.10215759277E-05 sec
chk #1: pos= time=4.12672686577 sec

Konklúzió: a sikeres keresés ideje egyik esetben sem számottevő, a sikertelené az UCS-4-es esetben kb. 2.1-szer több. A tényleges átnézendő memóriaterület az UCS4 esetében kb. (188/64=)2.94-szer több, ez okozhatja a lassabb eredményt.

- mb_ereg 


#!/usr/bin/php
<?php
$x = mb_convert_encoding('új fűszárítógépünkön kávészínű lódöghúst főzünk', mb_internal_encoding(), 'UTF-8');
$vesz = mb_convert_encoding('vész', mb_internal_encoding(), 'UTF-8');
$vasz = mb_convert_encoding('vász', mb_internal_encoding(), 'UTF-8');

for ($i = 0; $i < 20; $i++)
  $x .= $x;

$t_start = gettimeofday(true);
$y = mb_ereg($vesz, $x);
$t_end = gettimeofday(true);
echo "chk #0: match=".($y ? "yes" : "no")." time=".($t_end - $t_start)." sec\n";

$t_start = gettimeofday(true);
$y = mb_ereg($vasz, $x);
$t_end = gettimeofday(true);
echo "chk #1: match=".($y ? "yes" : "no")." time=".($t_end - $t_start)." sec\n";
?>

UTF-8: 


chk #0: match=yes time=0.000118970870972 sec
chk #1: match=no time=0.223363876343 sec

chk #0: match=yes time=0.000121116638184 sec
chk #1: match=no time=0.224899053574 sec

UCS-4: 


chk #0: match=yes time=0.00011682510376 sec
chk #1: match=no time=0.807845830917 sec

chk #0: match=yes time=0.000118017196655 sec
chk #1: match=no time=0.813722848892 sec

Konklúzió: UCS-4-ben több, mint 3.5-szer lassabb. Erre a nagyobb tárigény sem magyarázat. (Mármint feltéve, hogy a regex elemzés nem O(n^1.19) futásigényű.)

- Még meg kéne nézni backref-es kifejezésekkel is (pl. '(vész.*)\1'), mert ott már jöhet szóba belecímzés is, de ott nálam valamiért a fenti példa sem illeszkedik, pedig annak kéne.

Lehetne, de az átnézendő terület nem négyszer akkora, ui. az ékezetes betűket az utf8 is két byte-on tárolja, a mintaszövegben pedig elég szép számmal volt ilyen.
Ahogy számoltam (persze lehet, hogy tévedek), a fenti 47 karakteres blokkot utf8-ban 64 byte-on lehet ábrázolni, ucs4-ben pedig 4*47=188 byte-on, így a tárfoglalás aránya csak 188/64, azaz kevesebb, mint 3-szoros.

Azert kicsit necces hogy egy alap progihoz is minimum lib kell, vagy meghivom a gzip -et (ami ugye akkor dependency, nameg temp). Szerintem a mai világban elfér aza 4byte/karakter a winyón... aztán majd gzippelem adatátvitelhez, vagy ha véletlenül egy floppyra kéne rágyúrni a Harry Potter összeset :P

amugy ha csak ez a kettő van akkor UTF8

__________
"It's nice to be important, but it's more important to be nice"

> hát utf8-ban elkezdtem, aztán az oda-vissza lépkedés kapcsán azt mondtam, hogy fenét, tessék beolvasáskor ucs4-re alakítani, és onnantól fog működni :).

Ez nem spanyolviasz, ezt közismert hogy így kell csinálni. Az UTF-8 elsősorban programok közti kommunikációra, fájlban tárolásra stb. alkalmas. Ha memóriában akarsz dolgozni, akkor a feladat típusától függően könnyen lehet, hogy az UCS-4 sokkal jobb.

> Tehát pl. van-e mód arra, hogy a "csokoládé" a "cukor" utánra kerüljön ("c" < "cs")?

Igen. Locale-t kell beállítani (LC_COLLATE=hu_HU vagy hu_HU.UTF-8) és utána sort parancs, strcoll() vagy ínyenceknek strcoll_l() függvény. Egyes glibc verziókban szarul van implementálva, keress rá a bugtrackerben, szükség esetén a megfelelő patchet megtalálod ott.

( asch v | 2008. 01. 30., sze – 11:08 )

Programozó szemszöge:

Ha írsz egy programot, ami ISO8859-2-t használ, egyből jönnek az arcok, hogy: az meg mi? Én újzélandi vagyok. Az a vége, hogy tehetsz bele kódolásválasztót, ami akár bonyolultabb is lehet, mint az eredeti tool...

Ha megírod UTF-8-cal mindenki örül és bódottá van. Ezért minden ami új, az legyen UTF-8 és punktum.

( turul16 v | 2008. 01. 30., sze – 21:44 )

Azt hiszem átállok C -ről C.UTF-8 ra :)

Aki nemzeti karakterlapot használ, az ellene van annak, hogy a nemzete karakterei normálisan jelenjenek meg. Mivel így csak az első 128 chban bízhat meg az ember és nem is használja a többit ,ha jót akar.

Miért nem az utf-16 vagy ucs-4 et választottam ?
Mert akkor 2* 4* akkora lenne az ahol leggyakrabban használok mezei text -et. Vagyis forráskódok.
Ami egy kernelnél vagy egy openofficnál jelntős plusz.
utf-16 távolkeleti szövegeknél jol jönne, de ahol humán nyelvet használ az ember ott a más "díszítő" elemek sokkal többet foglalnak a dokumentumban, mint a human számára készült szöveg.

Belső használatra használnék, ucs-4 -et , ha tényleg elkerülhetetlen, de gyakoribb, hogy mintát keres az ember, vagy pointerrel mutat a megfelelő helyre mintsem karakter poziciót adna meg, valószínüleg jó neki byte -ban is megadni az offsetet.

u* sulyos hátránya, vagy inkább VGA kártyák text modjainak, hogy maximum 8bit áll rendelkezésre karakter reprezentázióra.

( airwave | 2008. 01. 31., cs – 11:43 )

Azért jobb az UTF-8, mert azt konyebb megjegyezni, mint hogy "ISO8859-2". :D

cp1250 rulz :D - a felhasználók 90%-a ezt használja errefelé. :D

( enpassant v | 2008. 02. 01., p – 08:29 )

"Ez SOK". Ezt ugye viccnek írtad? Egy keresés ideje olyan kicsi, hogy annak már a mértékegységét sem tudom megadni.:-) 0,0025 ns

Szerk. Valamiért elcsúszott a válasz. Ide szántam: http://hup.hu/node/50144#comment-497608

Újraszámlálva:

250 ns az én bc -szerint.
0.5 ns egy órajel mondjuk.

Valóban Javanál az nem sok erre a feladatra, sőt a vártnál jóval kevesebb, de valóban utf-8 -ban és az n -edik bötű pozicióját határorozd meg?

(Első-nek csak azt néztem, hogy jóval nagyobb -e mint amit C -nél várnék, mezi 8 bites karaktereknél)

Egy átlagosan 60k hosszú sztringet byteonként végig nyálazni tovább tart, leglábbis us től nagyobra számítanék.

( Kayapo | 2008. 02. 03., v – 17:08 )

Ez a szavazás akár az sg.hu -n is megállná a helyét...

De itt van még egy:

Mi a különbség a veréb?
[ ] általában a bal!
[ ] néha a jobb!

vagy:

Diessel, vagy benzines?
AMD, vagy Intel?
Risk, vagy bináris?

( Lightgod | 2008. 02. 14., cs – 14:51 )

Addig amig a BitchX-be bele nem operalom vagy valaki bele nem operalja az UTF-et addig ISO...

--
by lightgod