Hirdetés
Új hozzászólás Aktív témák
-
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
- Vírusirtó, Antivirus, VPN kulcsok GARANCIÁVAL!
- Windows 10 11 Pro Office 19 21 Pro Plus Retail kulcs 1 PC Mac AKCIÓ! Automatikus 0-24
- Antivírus szoftverek, VPN
- MEGA AKCIÓ! - Jogtiszta Windows - Office & Autodesk & CorelDRAW - Azonnal - Számlával - Garanciával
- Játékkulcsok ! : PC Steam, EA App, Ubisoft, Windows és egyéb játékok
- Dell ALienware AW3225QF 32" 4K QD-OLED Gaming Monitor 27% áfás - 3 ÓRA ÜZEMIDŐ!!
- Új! AKRacing Premium Master gamer szék
- iPhone 17 Pro Max Kozmosz - Bontatlan !! www.stylebolt.hu - Apple eszközök - Számlás
- LG 65C5 - 55" OLED evo - 4K 144Hz - 0.1ms - NVIDIA G-Sync - FreeSync - HDMI 2.1 - A9 Gen8 CPU
- Honor 200 256GB,Újszerű,Dobozaval,12 hónap garanciával
Állásajánlatok
Cég: Central PC számítógép és laptop szerviz - Pécs
Város: Pécs
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest



