nyest.hu
Kövessen, kérem!

Nem lát minket a Facebookon?

Kenyérpirítón szeretné?

Legutolsó hozzászólások
A nyelvész majd megmondja
A legnépszerűbb anyagok
Írjon! Nekünk!
nyest.hu
nyest.hu
 
Túl az angol ábécén
Miért drágább a magyar sms, mint az angol?

Azon ismerőseink, akik ékezet nélkül írnak sms-t, nem feltétlenül hanyagok vagy igénytelenek. Lehet, hogy csak spórolnak.

Takács Boglárka | 2010. szeptember 16.
|  

Hogyan kerültek a számítógépre az ékezetek? Az informatika mindig is komoly gondokkal küzdött, amikor az angol ábécében nem szereplő jelek megjelenítéséről volt szó; a helyzet mostanára sokat javult, de még mindig nem minden téren tökéletes a nemzetközi támogatás. Miért alakult ez így, és hogyan fejlődött a karakterkódolás a kezdetektől napjainkig? Sok furcsaságot tartalmazó történeti áttekintésünk a zászlólengetéstől a Unicode SMS-ekig.

Kezdetben vala a morze

Ahhoz, hogy egy modern informatikai rendszer képes legyen tárolni a szöveget, először szükség van egy úgynevezett karakterkódolási szisztémára, ami az írásjeleket számokká alakítja, mert a számítógép csak egyesekkel és nullákkal tud mit kezdeni. De az első karakterkódolási módszerek még nem számokat rendeltek a betűkhöz, hanem egészen más dolgokat. Ezek közül több a maga speciális területén a mai napig fennmaradt: a  morzeábécé hosszú és rövid jeleket használ, a tengerészetben pedig színes jelzőlobogókkal lehet a hajózásban fontos információk mellett magukat a latin betűket is jelölni. Ha két tengerész látótávolságban van, akkor pedig a zászlószemaforral is kommunikálhatnak:

Igazán merész olvasóink a japán szótagírásos zászlójeleket is kipróbálhatják!

Az első olyan rendszer, ami a maiakhoz hasonlóan kettes számrendszerbeli számokkal adta meg a betűket, az 1874-ben Franciaországban feltalált Baudot-kód volt: ez öt számjeggyel – öt biten – tárolta a latin ábécét és egyéb írásjeleket, tehát 25 = 32 féle jelet lehetett vele megkülönböztetni. Ez még úgy sem túl sok, hogy lehetőség nyílt betűk és számok-írásjelek közötti váltásra, tehát kétszer ennyi karakterrel lehetett dolgozni. A hiányzó betűk problémája már itt megjelent, tehát tulajdonképpen egyidős a modern karakterkódolással magával; a Baudot-kód ugyanis nem volt képes a francia ékezetek és mellékjelek helyes kezelésére. Csakúgy, amint a magyarra sem, ennek ellenére mégis ennek a rendszernek módosított változatát használták a magyar telexhálózat távírógépei is, a régi táviratokból ismerős módon átvive az ékezeteket: például ö helyett oe, ő helyett oeoe szerepelt. (Egészen 2002-ig üzemelt Magyarországon nyilvános telexhálózat, habár a rendszerváltás után inkább csak vegetált: fénykorát  évtizedekkel korábban élte, főleg állami szervek, nagyvállalatok használták.)

Feltűnik a színen a kalapos ű

A Baudot-kódra épülő rendszereket az ASCII váltotta fel, ez már a számítástechnikából is ismerős lehet. Az ASCII egy amerikai szabvány, a neve is erre utal: American Standard Code for Information Interchange = Amerikai Szabványos Információcserélési Kód. 1963-ban adták ki első változatát, akkor még szintén a különböző távírógépekre tervezve. Hét biten tárolta a karaktereket, tehát itt már 27 = 128 lehetőség adódott, viszont nem lehetett duplázni – ez teljesen szándékos volt a készítők részéről, mert így egy átvitt jelsorozat értéke nem függött semmi mástól, a változtatás sokkal egyszerűbb műszaki megoldásokat tett lehetővé.

Az eredeti ASCII szabvány számos üres helyet tartalmazott, ide 1967-ben bekerültek a kisbetűk, hogy ne csak nagybetűket lehessen átvinni. Ugyanekkor vezették be azt az eljárást is, miszerint nem egyben tárolják az ékezetes betűket, hanem egy ékezet mindig a betűje után szerepel és külön jelnek számít. Viszont csak hatféle ékezet szerepelt a készletben, és ezek is különböző más írásjelekkel osztoztak a funkción: például az aposztróf egyben a magyar á, é stb. betűkének megfelelő ékezetnek számított.

Az ASCII és a kisebb-nagyobb átalakításaival született szabványok rohamosan elterjedtek az egész világon, annak ellenére, hogy meglehetősen korlátozottak voltak a lehetőségeik. A számítástechnika fejlődésével megjelentek a 8 bitre kiterjesztett kódlapok, amelyekbe a 128 bevált ASCII karakter mellé 128 új is befért... volna, ha nem lett volna szükség a grafikus felületek kialakulásával különböző vonalakra, sarkokra és egyéb elemekre, amiket először szintén ide pakoltak be. Az egyik legjobban elterjedt ilyen próbálkozás az IBM fejlesztette 437-es kódlap volt:

Így néz ki maga a kódkiosztás, a második felében látható krikszkrakszokra érdemes figyelni
Így néz ki maga a kódkiosztás, a második felében látható krikszkrakszokra érdemes figyelni
(Forrás: Wikipedia commons)
Ez pedig egy hasonló elemekből összerakott (modern) felhasználói felület
Ez pedig egy hasonló elemekből összerakott (modern) felhasználói felület
(Forrás: GPL)

Azt is láthatjuk, hogy azért sikerült több ékezetes karaktert belegyömöszölni a táblázatba, viszont sok minden kimaradt, például az ő és ű is. (Innen ered a hullámos õ és a kalapos û, mint szükségmegoldás.) Nem csoda, hiszen ezeket Magyarországon kívül csak egy-két kis helyen használják, például az ő-t a Feröer-szigeteken:

Útjelző tábla a Feröer-szigetekről
Útjelző tábla a Feröer-szigetekről
(Forrás: Wikipedia commons / Mulder1982)

Magyarországon éppen ezért a 437-es helyett a 852-es „közép-európai” kódlapot használták, ebben már benne volt minden magyar ékezetes betű, viszont cserébe hiányzott több sarokelem – aki használt a DOS-korszakban számítógépet, valószínűleg még emlékszik arra, hogy ez kissé elrondította a grafikus felületeket. Csehországban született erre házimegoldás, a Kamenický kódolás, ebből viszont a nyugat-európai karakterek maradtak ki.

Unicode, a megváltás?

A hasonló toldozás-foldozás mellett nehézséget okozott a kódtáblázatok közötti választás is. Jobb esetben tudta a felhasználó – és az általa használt szoftver –, hogy melyik szöveghez melyik kódlapot használja, de nem mindig! Japánban még külön szó is született arra a jelenségre, amikor rossz kódolással jelenik meg valami: ez a mojibake (magyar fonetikával modzsibake).

Mojibake: a Nyest.hu 862-es (héber) kódlappal
Mojibake: a Nyest.hu 862-es (héber) kódlappal

Erre a problémára válaszul született a Unicode (ejtsd: junikód). Tervezői azt tűzték ki célul, hogy minden írás minden karaktere belekerüljön! Itt még nem tartunk, de egyre bővül a választék. Szépen hangzik, de a dolog nem egyszerű: ha minden jelnek van egy száma, akkor nagyon-nagyon hosszú számokra van szükség ahhoz, hogy akár egy egész rövid szöveget is leírjunk. Persze a gyakorlatban nagyon sok jelre nincs szükség, például a föníciai ábécét valószínűleg kevesen használják a mindennapi életben (itt ki lehet próbálni, tudja-e a böngészőnk). Hogyan lehet ezt a dilemmát feloldani?

A trükkös megoldás az, hogy kétszer végezzük el a hozzárendelést. Először az írásjeleket rendeljük a maguk egyedi Unicode azonosítószámához, majd az azonosítószámot valamelyik UTF ( = Unicode Transzformációs Formátum) kódlaphoz. Vannak rövidebb és hosszabb UTF kódlapok, a legelterjedtebb az ASCII-hoz hasonlóan 8 bites számokat használ (ez az UTF-8), de létezik UTF-32 is, amiben minden jelenlegi Unicode karakter benne van egyszerre (32 biten 232 = 4 294 967 296 különböző jel fér el!), viszont cserébe négyszer annyi helyet foglal a vele rögzített szöveg.

Általában nem gond a nagy kódtábla – kivéve, ha nagyon kevés hely áll rendelkezésünkre. Mikor találkozunk ezzel a mindennapi életben? Leginkább akkor, ha SMS-t szeretnénk küldeni mobiltelefonunkról. A telefonokban általánosan használt GSM kódlap nem tartalmaz minden magyar ékezetet, viszont ma már a modernebb készülékeken lehet a Unicode-ot is használni. Igen ám, csak ez több helyet foglal, így az elküldhető üzenet is rövidebb lesz, vagy – szolgáltatótól függően – két részben küldődik. Lehet, hogy a telefon szoftvere a két részre vágást és újra összeillesztést magától elvégzi, nekünk pedig fel sem tűnik, hogy duplán vagy akár triplán fizettünk az SMS-ért. Ha ez gondot okoz, érdemes a beállításokban megkeresni a kódolást és a Unicode helyett valamelyik másik lehetőséget kiválasztani! Sajnos egyre inkább jelennek meg olyan készülékek, amelyeknek vagy a Unicode az alapbeállítása, vagy nem is lehet másra átállítani őket – ilyen esetben talán elvárható lenne a szolgáltatótól, hogy a technológiaváltás miatti árkülönbséget ne hárítsa teljesen a fogyasztóra, de erre egyelőre várhatunk...

Források

Searle, S. J. (1999): A Brief History of Character Codes in North America, Europe, and East Asia. http://tronweb.super-nova.co.jp/characcodehist.html

Jennings, T. (2004): An annotated history of some character codes.

http://wps.com/projects/codes/index.html

Követem a cikkhozzászólásokat (RSS)
Hozzászóláshoz lépjen be vagy regisztráljon.
2 Sigmoid 2012. január 11. 16:51

Uh bocsánat, a második bekezdés utolsó mopndata helyesen: "Az ASCII karakterek 8 bitet (1 bájtot), a gyakoribb nem-ASCII jelek (pl. a magyar ő, ű) 16-ot (2 bájtot), stb."

1 Sigmoid 2012. január 11. 15:13

Az UTF formátumok közti különbségre érdemes kicsit jobban kitérni.

Az UTF-8 nem következetesen 8 bitet foglal, hanem változó karakterhosszúsággal dolgozik. Ez azt jelenti, hogy minél ritkább egy jel, annál nagyobb helyet foglal. Az ASCII karakterek 8 bitet, a gyakoribb nem-ASCII jelek (pl. a magyar ő, ű) kettőt, stb.

Az UTF-16 elődje, az UCS-2 kötött hosszúságú 2 bájtos karakterekkel dolgozott, így kizárólag az úgynevezett BMP (Basic Multilingual Plane, "Alapvető Nyelvi Sík") karaktereket tudta kódolni - ami kb. az összes élő nyelvet jelenti, és pár holtat. Többek közt pl. az egyiptomi hieroglifák nincsenek közte, ahhoz már a Kiterjesztett Nyelvi Sík készlete kell.

Az UTF-16 fejlesztése abban áll, hogy szükség esetén nagyobbra hízlalva az egyes karakterek hosszát, képes azon jeleket is továbbítani, amik nincsenek rajta a BMP-n.

El lehet képzelni, hogy minél ritkább karaktereket használunk, annál inkább megéri magasabb "rendű" UTF formátumot használni.

Pl. tegyük fel, hogy a piréz nyelv karakterei UTF-16-os kódolással még beleférnek a 2 bájtos méretbe, de az UTF-8 esetén csak három bájton lehet kódolni őket.

Így egy 2000 leütésből álló piréz üzenet UTF-16-ban kódolva 4000, UTF-8-ban viszont 6000 bájtot fog elfoglalni!

Mi van viszont az olyan nyelvekkel, mint a magyar? A magyar karakterek kis százaléka ékezetes, a nagy része az ASCII karaktertábla része. Most tekintsetek el attól, hogy nem keresek statisztikát arról, hogy a magyar szöveg hány százaléka ékezetes, tegyük fel hogy mondjuk 5%-ról beszélünk.

Ha UTF-8-ban kódolunk, akkor a nem ékezetes magyar karakterek 1 bájton, az ékezetesek 2-n kerülnek tárolásra. UTF-16-ban viszont az összes magyar karakter 2 bájtot foglal.

Tekintsünk akkor egy 2000 leütéses magyar szöveget. Ha UTF-16-ban kódoljuk, akkor a pirézhez hasonlóan 4000 bájtot foglal. Ha viszont UTF-8-ban, akkor...

2000-nek az 5%-a 100, szóval az üzenet 1900 * 1 + 100 * 2 = 2100 bájtot foglal el! Alig több mint FELE az UTF-16-os kódolásnak!

Na és itt jön elő a gáz a mobiltelefonokkal.

Az iPhone-on amint leütsz egy nem Latin1-es karakterkészletbe tartozó jelet, az SMS-ben elküldhető karakterek száma azonnal lezuhan 160-ról 70-re. Ami itt történik, hogy egy tartalomtípus definíció szúródik be az üzenet elejére, és a gép átvált UTF-16-ra.

Ha UTF-8-at használna, akkor nem 70 karaktert küldhetnénk, hanem sokkal többet.

A régi Nokiámon, ha egy nem Latin1-es karaktert ütöttél be, kettővel csökkent a hátralévő karakterszám az SMS-ben, ebből látni hogy ott UTF-8 volt használatban. Az iPhone ezzel szemben mindent 2 karakteren kódol onnantól.

Az Android telókkal nincs tapasztalatom, és ezzel együtt az iPhone igen jó gép, de ebbe igazán belegondolhattak volna.

Mondjuk lehet hogy megindokolható a döntés, mert így meg Japánban és Kínában hatékonyabb az átvitel. Őszintén fogalmam sincs, hogy egy kandzsi 2 vagy 3 bájtot foglal-e UTF-8-ban, és most nincs kedvem rákeresni. :D Ha 3-on, akkor a magyarnál sokkal nagyobb kelet-ázsiai piacot nézve lehet ráció az UTF-16 használatában.

Információ
X