$ LANG'ın terminal üzerindeki etkisi

Değişkenin gnome terminali (ve karakter kodlama tercih seçeneği) ile nasıl davrandığını öğrenmeye çalışıyorum $LANG. Ana karakter setim olarak iso8859-1 (latin1) kullanıyorum ve tüm dosya adlarım bu şekilde kodlandı.

Aşağıdaki testler ls -liçin dosya adlarında İspanyolca aksanlı karakterler içeren bir dizini yapacağım :

Dava 1:

• gnome terminali ISO-8859-1 için yapılandırılmıştır
• LANG "en_US-iso8859-1" olarak ayarla
• Sonuç: Tüm dosyaları doğru görüyorum

Dava # 2:

• UTF-8 için yapılandırılmış gnome terminali
• LANG "en_US-iso8859-1" olarak ayarla
• Sonuç: Tüm İspanyolca karakterler için çöp karakterler görüyorum. Terminalin karakter kodlamasını değiştirdiğim için bu bekleniyor

Vaka # 3:

• gnome terminali ISO-8859-1 için yapılandırılmıştır
• LANG "en_US-UTF-8" olarak ayarlandı
• Sonuç: Tüm İspanyolca karakterler için çöp karakterler görüyorum.

Bu son durumda neden bozuk karakterler görüyorum? Ls çıktısı dosya adlarını oldukları gibi doğrudan gnome terminaline göndermemeli midir? GNOME terminali ISO-8859-1 için yapılandırıldığından, onların doğru görünmelerini beklerdim.

Bir an için, belki de bash'ın $LANGdeğişkenimi düşünüp bir dönüşüm gerçekleştirdiğini düşündüm . Sonra terminalimi UTF-8 olarak değiştirdim ancak karakterleri hala doğru göremiyorum. Hatta xsd ls çıkışını piped ve sürpriz için hala oldukları gibi kodlanmış dosyaları görüyorum: ISO-8859-1.

Özetlemek için: Listem ISO-8859-1 karakterleri içeriyorsa ve terminal öykünücüm aynı karakter kodlaması için yapılandırılmışsa: LANGAksi ayarlandığında dönüştürme işlemini kim yapıyor ?

Verebileceğiniz herhangi bir yardım için teşekkürler.

Craconia

İçin yaptığınız ayar LANGterminallerle eşleşmelidir. Daha kesin olarak, LC_CTYPE(karakter kodlaması) ayarınızın terminalin kodlamasıyla eşleşmesi gerekir, diğer yerel ayarların eşleşmesi gerekmez. Terminalin kodlaması, yerel ayar değişkeni tarafından değil, genellikle terminal öykünücüsünün bir seçeneğiyle belirtilir. LC_CTYPEBirleştirir iki endikasyonları: o (hem giriş ve çıkış için) Terminal kullanılmak üzere kodlama neyi uygulamaları anlatır ve dosyalarla kullanmak kodlama neyi uygulamaları anlatır. Durum 2 ve 3'te, lsçıkışı terminalden farklı bir kodlamada görüntülemenizi söylediniz , bu nedenle çıkış bozuktur.

Hem UTF-8 hem de latin-1 kodlamaları ile farklı zamanlarda çalışıyorsanız, terminalinizi UTF-8 kullanacak şekilde yapılandırın. Bu LC_CTYPEUTF-8'i gösteren bir değere ayarlanmasına neden olmalıdır ; bu ayarı geçersiz kılma. (Terminal öykünücüsü ayarlanmazsa LC_CTYPE, kabuk başlangıç ​​dosyanızda veya tüm oturumunuz için geçersiz kılın.) UTF-8 terminalinde latin-1 verileriyle çalışmak için luit(X yardımcı program paketinde bulunur) öğesini kullanın.

LC_CTYPE=en_US.iso88591 luit

(Aynı kodlamaya sahip başka herhangi bir yerel ayarı kullanabilirsiniz, örn LC_CTYPE=es_ES.iso88591 luit.)

# 2 ve # 3 durumunda, iki farklı kodlama UTF-8 ve Latin-1'i karıştırıyorsunuz. # 1 durumunda, her ikisi için de Latin-1 kullanıyorsanız, sorun yaşamazsınız.

lsKomut (ve tüm diğer iyi davranıyor programı kullanılacaktır) belirlemek için LANG ayarını kullanın kodlamayı .

İki farklı dili karıştırabilirsiniz, ancak iki farklı kodlamayı karıştırmamalısınız .

LC_ * ortam değişkenlerinin de LANG değişkeninizle aynı kodlamayı kullandığından emin olun.

Genel bir kural olarak, sisteminizi bugünlerde yalnızca UTF-8 kullanacak şekilde yapılandırmalısınız.

Eski moda veri dosyalarını (örneğin java özellikleri) düzenlemeniz gerekiyorsa, özel bir düzenleyici (örn. Java ide) kullanmalı veya kodlama iconvveya `recode gibi araçlarla kodlamayı sağlamalısınız .

Bu ihtiyaç dışında olabilir, ama ....

RHEL5'te ortaya çıkıyor ve muhtemelen daha önce, man sayfalarının birçoğunun bir şekilde öngörülen bir sebepten dolayı saldırıya uğramıştı. Yani, ham adam sayfası yerel karakter kümesinden 7 bit ASCII'ye dönüştürüldü. LC ve LANG ile ne yaparsanız yapın, man sayfası latin1etkili bir şekilde işe yaramayan bir man sayfası üretir. İçindeki tüm özel (8 bit) karakterler 7 bit yer tutucularla (genellikle ??) değiştirildi. Bunu komik buluyorum.

Ancak utf8bu kılavuz sayfaların sürümü dile özgü dizinde bulunabilir. İşin püf noktası, onları doğru adlarıyla sormak. Örneğin, latin1 aslında iso_8859-1. Üzerinde bir man sayfası yaparsanız ve LANG ayarlarınız doğruysa, ne beklediğinizi görürsünüz; kılavuz sayfası dile özgü alt dizinde ( en/man7/iso_8859-1.7) bulunur. Ancak iso-8859-1, herhangi bir nedenle ASCII sürümünü alırsanız.