Új hozzászólás Aktív témák
-
Sipi
addikt
Kernelben, ha nem olyat adsz meg, mint ami a felsorolásban látezik, visszavált egy defaultra. Ez vagy ISO-8859-1 (vagyis a latin1, kvázi angol abc), vagy ehhez hasonló.
Az /etc/locale.gen fájlban hu_HU.UTF-8 UTF-8 a helyes alak, ekkor generál 8 bites Unicode lokált. A lokál definíciója is ez, hu_HU.UTF-8, de adtam má rmeg véletlenül UTF8 alakban is. Elvileg ugyanaz, a ''hivatalos'' neve UTF-8. Még csak nem is kisbetűvel.
Az Xorg alatt vannak kavarok, ott furán értelmezi mind az UTF-8/UTF8/utf8 alakokat, ráadásul alapban magyarhoz nem is mindig ismer Unuicode-ot.
A /usr/share/X11/locale/locale.alias fájlba be kell írni kézzel két sort. Ez a fájl két részből áll, az első részt nem is veszi figyelembe, de menjünk biztosra. Ki kell keresned a hu_HU karakterláncot, és az itteni hu_HU sorok után beírni a következőt: hu_HU.utf8 hu_HU.UTF-8. Ez az első előfordulásnál, majd lesz egy hungarian ... hu_HU, az nem érdekes, és a végén meginegy hasonló sor, de itt hu_HU.utf8: hu_HU.UTF-8 az alak. (Plusz kettősponttal.)
Régebben hu_HU.utf8-at kellett megadni a glibc lokálnak, ezt az X nem ismerte. Most nekem már hu_HU.UTF-8 a glibc lokál (vagyis az LC_ALL értéke), ez lehetne a helyes, ezt az X is ismeri. Tehát elvileg nem kell a fenti locale.alias betoldósdi. Régebben kellett, ártani nem árt, ha esetleg rossz alakban adod meg a lokált. (Ha X alatt egy xkonzolból (konsole, xterm) elindítasz egy X-es programot, az kiírja, ha nem ismert a lokál. Ha nem ad hibát, nem kell beírni a fentieket, vagyis eleve jól adtad meg a glibc-nek, milyen lokál legyen.)
Sipi -
Sipi
addikt
A kerneles kódolás a fájlrendszeren megjelenített fájlnevekért felelős. Ha UTF8-ra teszed, a fájlok neveit Unicode-ban tárolja.
A glibc maga a rendszer. Az itteni kódolás adja meg, a rendszered mit használ, vagyis az összes program. (Bár pontosabban: nem a glibcnek adod meg, a glibc megadja, miket használhatsz. Ezután környezeti változók segítségével megadod, melyik kell, s az elindított programok ezen változókat olvassák, s döntik el, mi a lokál.)
Keverheted, mert semmi közük egymáshoz.
Ráadásul a kerneles csak azt adja meg, hog yha nincs egyéb rákényszerítve, akkor pl. utf8-ban tároljon. De egy távoli (pl. samba) fájlrendszernél úgyis más lesz a kódolás, ekkor csatolásnál valószínűleg megadod, hogyan kezelje. (Mert elég hülyén néznek ki az ISO-8859-1-ben tárolt Windows-os fájlnevek UTF8-ban megjelenítve.)
A glibcnek megadni ilyet-olyat... Ennek így nem sok értelme van. Ha telepíted, megadhatod, sőt, meg is kell adni az /etc/locale.gen fájlban, milyen lokálokat generáljon le. (Ha nem adod meg, mindent generál.) Ezután pl. az LC_ALL változóval mondod meg, mi legyen az összes lokál-beállítás. De ennek egy értéke lehet.
Ahol van Unicode USE flag, az _többnyire_ azt jelenti, hogy alapban nem ismeri, nem működik jól Unicode alatt, ezért ha ezt használsz, be kell kapcsolni, s végez némi varázslatot, hogy működjön. A legtöbb program a gettext, vagy hasonló kijelzési függvénykönyvtárat használja, ezeket nem érdekli, hogy Unicode vagy sem, csak megjelenít. Ha a gettext Unjcode-os, ő is tudni fogja.
Az nls a Native Language Support, arra való, hogy angolon kívül más nyelven is futtatható legyen. Igazság szerint semmi értelme kikapcsolni, ez is a gettext és társai egyik alapszolgáltatása.
A gettext alapvető ki/bemeneti (kijelzési) függvényeket tartalmaz.
Fájlok ékezetbajai MINDIG csatolási kódlap-problémát jelentenek. A kernelben érdemes az adott résznél mindent legalább modulba tenni, hogy ha pl. olyan vinyót kapsz, amin KOI8-as orosz kódolású fájlrendszer van, be tudja tölteni. De ez így még semmit sem jelent, ugyanis sok fájlrendszer SEMMIT sem árul el arról, hogy milyen kódolásban tárolja a fájlneveket. Ezért lehet szükség csatoláskor megadni a kódlapot.
rm kiegészítéskor azért írja ki jól, mert az ls az a kernelben lévő, csatoláskor megadott kódlapot használja, hogy a fájlneveket kiírja, de a kiegészítés már egy szimpla, gettextes program (a bash része), ez teljesen más módon jelenít meg.
Ökölszabályként elfogadható: nagy ívben szard le, ha csak annyi a baj, hogy a fájlnevek rosszul jelennek meg. Semmi köze a rendszerhez, ez csatolási probléma (vagy még inkább annak a *** szarfos fájlrendszernek a hibája). A géped összes kódolási, kijelzési, nyelvi dolgát a glibc által ismert, az LC_* változók által megadott lokál szabja meg.
Egy apró bevezető: [link]
Sipi
Új hozzászólás Aktív témák
- Melyik tápegységet vegyem?
- Formula-1
- Székesfehérvár és környéke adok-veszek-beszélgetek
- Luck Dragon: Asszociációs játék. :)
- sziku69: Fűzzük össze a szavakat :)
- Xbox tulajok OFF topicja
- Apple MacBook
- Mesterséges intelligencia topik
- Tőzsde és gazdaság
- Itt a Galaxy S26 széria: az Ultra fejlődött, a másik kettő alig
- További aktív témák...
- Windows, Office licencek kedvező áron, egyenesen a Microsoft-tól - Automata kézbesítés utalással is!
- Xbox / Microsoft Store feltöltőkártya kód (digitális, HU) több címlet, több db, azonnal, olcsón
- Fallout 4 Pip-Boy Edition eladó
- Windows 10 11 Pro Office 19 21 Pro Plus Retail kulcs 1 PC Mac AKCIÓ! Automatikus 0-24
- Windows 10/11 Home/Pro , Office 2024 kulcsok
- ÁRGARANCIA!Épített KomPhone i7 14700KF 32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- BESZÁMÍTÁS! ASUS B365M i5 9600KF 16GB DDR4 512GB SSD RX 5600XT 6GB Zalman S2 TG GAMDIAS 650W
- Xiaomi 14T 12/256GB - Kártyafüggetlen, Fekete, ÚJSZERŰ - 1 Év garanciával
- Xiaomi Redmi Note 12S 256GB, Kártyafüggetlen, 1 Év Garanciával
- Dell Latitude 7410 Core i5-10310u, 16GB RAM, SSD, jó akku, számla, 6 hó gar
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest