UTF-8 szívás

Debian GNU/Linux

Mindig is felállt a szőr a hátamon az utf-től, de a mai tapasztalat végkép elkeserített.
Sokan hirdetik, hogy semmi gond, ott van az iconv, az megold mindent. Hát nem!
Íme három probléma:

Probléma 1)
Debian Etch, konzol (LANG=en_US.UTF-8) 


$ echo "árvíztűrő tükörfúrógép" | tr "áéíóúöőüű" "aeiouoouu"
uervuoztuuruu tuukuurfuuruuguop

echo "árvíztűrő tükörfúrógép" | tr "áéíóúöőüűÁÉÍÓÚÖŐÜŰ" "aeiouoouuAEIOUOOUU"
UervUoztUUrUU tUOkUIrfUArUugUop

echo "ÁRVÍZTŰRŐ TÜKÖRFÚRÓGÉP" | tr "áéíóúöőüűÁÉÍÓÚÖŐÜŰ" "aeiouoouuAEIOUOOUU"
UURVUUZTUURUU TUUKUURFUURUUGUUP

echo "árvíztűrő tükörfúrógép" | sed "y/áéíóúöőüűÁÉÍÓÚÖŐÜŰ/aeiouoouuAEIOUOOUU/"
arvizturo tukorfurogep

echo "ÁRVÍZTŰRŐ TÜKÖRFÚRÓGÉP" | sed "y/áéíóúöőüűÁÉÍÓÚÖŐÜŰ/aeiouoouuAEIOUOOUU/"
ARVIZTURO TUKORFUROGEP

Probléma 2)
Adott egy latin2 időkben megírt LaTeX fájlból származó .dvi fájl. Ha, ezt szeretnénk megnézni az xdvi segítségével egy utf8-as környezetben, azt látjuk, hogy nem látjuk a hosszú ékezetes betűket. Kíváncsi vagyok, egy dvi állománnyal mit kezdene az iconv? (apropó: DVI=device independent ...)

Probléma 3)
Magyarul megírt LaTeX file-okban ugyan az iconv szépen kicseréli az ékezetes karaktereket, de a \usepackage[latin2]{inputenc} átírásáról már magunknak kell gondoskodni. No meg persze a HTML-lel is hasonló a történet...

Érdeklődve várom az UTF rajongók/szakértők megoldásait a fenti problémákra, különös tekintettel a tr parancs csodálatos működésére.

  • 1478 megtekintés

( styg v | 2008. 03. 07., p – 10:32 )

Megoldásom nincs, csak egy PC-m, ahol 

styg@marvin:~$ echo "árvíztűrő tükörfúrógép"
árvíztűrő tükörfúrógép

Ubuntu 7.04, Gnome Terminal

Kollégám Debian Etch-e ugyanilyen.

Ne sértődj meg, de bejegyzésed kicsit hasonlít a "régi kartotékos rendszer sokkal jobb volt!" megnyilvánulásokra.

( kikke | 2008. 03. 07., p – 10:35 )

UTF-8-cal nem is lehet szívni. Csak szĂ­vni.

( Replaced | 2008. 03. 07., p – 10:56 )

szar a tr-ed

--
Unix, Perfectly "natural" after five or ten years.

( htamas | 2008. 03. 07., p – 11:08 )

`info tr`:
Currently `tr' fully supports only single-byte characters.

Nem mintha védeni akarnám a tr-t, de ez elég jól megmagyarázza a jelenséget. Egyszerűen bájtonként dolgozik.
Egy analóg példa, ami megmagyarázza, hogy miért azt kapod, amit: 

echo 'PArvPIztRYrRD tPVkPQrfPUrPOgPEp' | tr 'PAPEPIPOPUPQRDPVRY' 'aeiouoouu'
uervuoztuuruu tuukuurfuuruuguop

Mj.: Ilyenkor a gnu tr úgy értelmezi a második sztringet, mintha még 9 db u lenne a végén.

( Csigaa | 2008. 03. 07., p – 11:07 )

Az első "probléma" végülis micsoda?

( MGy v | 2008. 03. 07., p – 11:32 )

Ha karakterkódolást akarsz változtatni arra nem a tr az ideális szerszám. Használd az iconv programot.

( mrev | 2008. 03. 07., p – 11:57 )

1) Nem UTF-8 rajongó vagyok, csak beláttam, hogy nincs más lehetőség (ez a legkisebb rossz).

2) Nem nagyon érted, hogy van ez az UTF-8 dolog.

3) Rendkívül megnehezül az élet, ha felalá konvertálgatni akarsz Latin és UTF-8 között (UTF-8 -> Latin nem is lehetséges). Nem érdemes erőltetni. Ami Latinban van, azt használd Latin környezetben, lassanként pedig átkerülnek az ember vackai UTF-8-ba.

--
CCC3

( Replaced | 2008. 03. 12., sze – 23:18 )

most probaltam ki kivancsisagbol egy suse-s gepen es mukodott. most en probaltam rosszul, vagy sajat verziot hasznalnak?

mellesleg miros-nak van multibyte aware tr-je

--
Segmentation violation -- Core dumped blues

Letöltöttem az opensuse 10.3 bináris csomagot és kipróbáltam az abban lévő tr-t. Ugyanúgy rossz, mint az eredeti postban. Tutkó utf8-ban vagy a locale szerint is és a terminál beállítása szerint is? Ha igen, akkor "type -a tr", utána "rpm -qf /a/kapott/útvonal(ak)", lehet hogy meg fogunk lepődni hogy nem /usr/bin/tr és/vagy nem a coreutils csomagban van, hanem valami más implementáció, vagy alias, vagy bármi hasonló. Ja, "tr --version" valszeg egyszerűbb :)

( egmont | 2008. 03. 13., cs – 00:08 )

1. A GNU Coreutils-ból származó (vagyis gyakorlatilag minden disztrib által szállított) tr nem támogatja a multibyte kódolásokat. Tessék b_szogatni a fejlesztőket, patchet küldeni stb., vagy sed-et, perl-t stb. használni helyette. Mellesleg például az UHU-Linux 2.0-ban ez a dokumentált ismert ékezetkezelési hibák közt szerepel, lásd itt.

2. Még nem találkoztam ezzel a problémával, bár azzal igen, hogy UTF-8 locale esetén nagyon lassan indul el. Ennek megfelelően az UHU-ban a wrapper szkriptbe beraktuk, hogy állítsa vissza a locale-t az xdvi processz számára. Ha ez segít neked, akkor szólj a disztribed készítőinek, hogy ők is tegyék meg. Az xdvi egyébként egy őskövület, rondán kinéző szar. Próbáld ki az advi-től a zdvi-ig mind a 25 többi progit, meg evince, poppler, ilyesmiket, biztos akad ami nemcsak jobb, hanem mellesleg gusztusosabban is néz ki.

3. Igen. Az átírásról magunknak kell gondoskodni. Mi itt a probléma? Ha jól látom, értesz a sed-hez. Mit vártál az iconv-tól, azt hogy komplett LaTex és HTML, .po, mailbox [és még sorolhatnám a különféle fájlformátumokat, melyek valahol önmagukba beépítve tartalmazzák a karakterkódolás megnevezését] parser van benne? Sőt, ha egy html fájlt alakítasz át, akkor megkeresi az azt kiszolgáló Apache konfigját, és azt is átállítja, hogy a http fejléc is stimmeljen, naná! Az iconv egy karakterkészlet-átalakító, nem több. A fájlod karakterkészletét alakítja át, nyilván nem írja át a benne szereplő latin2 szavakat utf8-ra.