टर्मिनल पर $ LANG का प्रभाव

Question

मैं यह सीखने की कोशिश कर रहा हूं कि $LANGचर सूक्ति-टर्मिनल (और इसके चरित्र एन्कोडिंग वरीयता विकल्प) के साथ कैसे व्यवहार करता है। मैं अपने मुख्य चरित्र-सेट के रूप में iso8859-1 (latin1) का उपयोग कर रहा हूं और मेरे सभी फ़ाइलनाम जैसे एन्कोड किए गए हैं।

निम्नलिखित परीक्षणों के लिए मैं ls -lउनके फ़ाइलनाम में स्पैनिश उच्चारण पात्रों के साथ एक निर्देशिका करूँगा :

मामला एक:

• ISO-8859-1 के लिए गनोम-टर्मिनल कॉन्फ़िगर किया गया
• LANG "en_US-iso8859-1" पर सेट
• परिणाम: मैं सभी फाइलों को सही ढंग से देखता हूं

केस # 2:

• UTF-8 के लिए गनोम-टर्मिनल कॉन्फ़िगर किया गया
• LANG "en_US-iso8859-1" पर सेट
• परिणाम: मैं सभी स्पेनिश पात्रों के लिए कचरा पात्र देखता हूं। यह अपेक्षित है क्योंकि मैंने टर्मिनल के लिए चरित्र-एन्कोडिंग को बदल दिया था

केस # 3:

• ISO-8859-1 के लिए गनोम-टर्मिनल कॉन्फ़िगर किया गया
• LANG "en_US-UTF-8" पर सेट करें
• परिणाम: मैं सभी स्पेनिश पात्रों के लिए कचरा पात्र देखता हूं।

ऐसा क्यों है कि इस अंतिम मामले में मुझे गढ़े हुए चरित्र दिखाई दे रहे हैं? Ls का आउटपुट फ़ाइल नाम को सीधे गनोम-टर्मिनल पर नहीं भेजना चाहिए क्योंकि वे हैं? और जब से आईएसओ-8859-1 के लिए सूक्ति-टर्मिनल को कॉन्फ़िगर किया गया है, मुझे उम्मीद है कि वे सही दिखेंगे।

एक पल के लिए मुझे लगा कि, शायद, बैश मेरे $LANGचर पर विचार कर रहा है और कुछ रूपांतरण कर रहा है। फिर मैंने अपने टर्मिनल को UTF-8 में बदल दिया, लेकिन मैं अभी भी पात्रों को सही से नहीं देख सकता। मैंने भी xxd को ls के आउटपुट को पाइप किया और मेरे आश्चर्य को मैं अभी भी फ़ाइलों को एन्कोडेड के रूप में देखता हूं जैसे वे हैं: ISO-8859-1।

रैप अप करने के लिए: यदि मेरी लिस्टिंग में ISO-8859-1 अक्षर हैं और मेरे टर्मिनल एमुलेटर को एक ही वर्ण-एन्कोडिंग के लिए कॉन्फ़िगर किया गया है: कौन रूपांतरण कर रहा है जब LANGअन्यथा सेट किया गया हो?

आप जो भी मदद दे सकें मैं उसका आभारी होऊंगा।

Craconia

Answer 1

LANGटर्मिनल के लिए आपकी सेटिंग से मेल खाना चाहिए। अधिक सटीक रूप से, आपके लिए LC_CTYPE(चरित्र एन्कोडिंग) टर्मिनल की एन्कोडिंग से मेल खाना चाहिए, अन्य लोकेल सेटिंग्स को मैच करने की आवश्यकता नहीं है। और टर्मिनल का एन्कोडिंग आमतौर पर टर्मिनल एमुलेटर के एक विकल्प द्वारा निर्दिष्ट किया जाता है और स्थानीय चर द्वारा नहीं। LC_CTYPEजोड़ती दो संकेत: यह क्या टर्मिनल पर उपयोग करने के लिए एन्कोडिंग (दोनों इनपुट और आउटपुट के लिए) अनुप्रयोगों बताता है, और यह क्या फाइलों के साथ उपयोग करने के लिए एन्कोडिंग अनुप्रयोगों बताता है। 2 और 3 के मामलों में, आपने lsआउटपुट को एक एन्कोडिंग में प्रदर्शित करने के लिए कहा है जो टर्मिनल से अलग है, इसलिए आउटपुट में गड़बड़ी है।

यदि आप अलग-अलग समय पर UTF-8 और latin-1 एन्कोडिंग दोनों के साथ काम करते हैं, तो UTF-8 का उपयोग करने के लिए अपने टर्मिनल को कॉन्फ़िगर करें। इसका कारण यह LC_CTYPEUTF-8 को दर्शाने वाले मान पर सेट होना चाहिए ; इस सेटिंग को ओवरराइड न करें। (यदि टर्मिनल एमुलेटर सेट नहीं होता है LC_CTYPE, तो इसे अपने शेल स्टार्टअप फ़ाइल में या अपने पूरे सत्र के लिए ओवरराइड करें।) UTF-8 टर्मिनल में लैटिन -1 डेटा के साथ काम करने के लिए, luit(एक्स यूटिलिटी सूट में शामिल) का उपयोग करें।

LC_CTYPE=en_US.iso88591 luit

(आप एक ही एन्कोडिंग के साथ किसी भी अन्य लोकेल का उपयोग कर सकते हैं, उदाहरण के लिए LC_CTYPE=es_ES.iso88591 luit।)

Comments

उस अद्भुत स्पष्टीकरण के लिए धन्यवाद गाइल्स, विशेष रूप से LC_CTYPE के लिए दो संकेतों की व्याख्या करने के लिए।

— क्रेकोनिया

अपने अंतिम मामले पर वापस जा रहे हैं: मैंने सोचा कि, चूंकि सभी फ़ाइलनामों को लैटिन 1 में एन्कोड किया गया था, इस तथ्य के साथ कि मेरा अंतिम आउटपुट डिवाइस, ग्लिफ़ बनाने वाला मेरा (मेरा टर्मिनल) भी लैटिन 1 के लिए कॉन्फ़िगर किया गया था, मैं फ़ाइलों को सही तरीके से देखने की उम्मीद कर रहा था। (LC_CTYPE की परवाह किए बिना) ...

— क्रेकोनिया

मेरे साथ ऐसा कभी नहीं हुआ जो lsLC_CTYPE (इस मामले में UTF-8 पर सेट) पर विचार करेगा और किसी प्रकार का चरित्र-सेट सत्यापन करेगा: जब भी वह कुछ ऐसा देखता है जो वर्ण सेट के अनुकूल नहीं होता है तो वह एक विशिष्ट वर्ण (उदा।) को थूक देगा? ")। मैंने कहा "सत्यापन" क्योंकि यह "रूपांतरण" नहीं करेगा जैसा कि ल्यूट करता है। क्या यह ऐसा है?

— क्रॉनिकिया

@Craconia तीसरे मामले में, lsद्वारा अनपेक्षित वर्णों को प्रतिस्थापित करता है ?। अधिकांश शब्द लैटिन -1 में एन्कोड किए गए हैं जो वास्तविक शब्दों का प्रतिनिधित्व करते हैं यदि यूटीएफ -8 के रूप में व्याख्या की जाए तो यह अनुचित वर्ण हैं।

— गिल्स एसओ- बुराई को रोकना '

Answer 2

# 2 और # 3 के मामले में आप दो अलग-अलग एन्कोडिंग UTF-8 और लैटिन -1 का मिश्रण कर रहे हैं। # 1 के मामले में आप दोनों के लिए लैटिन -1 का उपयोग कर रहे हैं, इसलिए आपको कोई समस्या नहीं है।

lsआदेश (और अन्य सभी अच्छी तरह से बर्ताव programms) निर्धारित करने के लिए LANG सेटिंग का उपयोग एन्कोडिंग ।

आप दो अलग-अलग भाषाओं का मिश्रण कर सकते हैं, लेकिन आपको दो अलग-अलग एन्कोडिंग का मिश्रण नहीं करना चाहिए ।

सुनिश्चित करें कि LC_ * पर्यावरण चर भी आपके LANG चर के समान एन्कोडिंग का उपयोग करें।

अंगूठे के एक नियम के रूप में, आपको केवल UTF-8 का उपयोग करने के लिए अपने सिस्टम को कॉन्फ़िगर करना चाहिए।

यदि आपको पुराने जमाने की डेटा फ़ाइलों (जैसे जावा गुण) को संपादित करना है, तो आपको या तो एक विशेष संपादक (जैसे जावा आइडेड) का उपयोग करना चाहिए या iconvफिर 'रिकोड' जैसे उपकरणों के साथ एन्कोडिंग सुनिश्चित करना चाहिए ।

Comments

धन्यवाद। हां, मेरी निकट भविष्य में UTF-8 में जाने की योजना है। प्लस कई कई पाठ फ़ाइलों को परिवर्तित करने के लिए फ़ाइल नाम का एक गुच्छा मिला। iconv और बचाव के लिए कायल ...

— क्रेकोनिया

Answer 3

यह आपकी जरूरत के बाहर हो सकता है, लेकिन ...।

यह आरएचईएल 5 में निकलता है, और शायद पहले से, बहुत से पुरुष पृष्ठों में से कुछ के लिए किसी भी तरह से जीडी foresaken कारण, ascii-ized था। यही है, कच्चे आदमी पृष्ठ को उसके मूल चरित्र से 7-बिट एएससीआईआई में बदल दिया गया है। कोई फर्क नहीं पड़ता कि आप एलसी और लैंग के साथ क्या करते हैं, मैन पेज के लिए latin1एक मैन पेज का निर्माण होता है जो प्रभावी रूप से बेकार है। सभी विशेष (8-बिट) अक्षरों को 7-बिट प्लेसहोल्डर्स (आमतौर पर ??) के साथ बदल दिया गया है । मुझे यह प्रफुल्लित करने वाला लगता है।

लेकिन utf8इन मैन पेजों का संस्करण भाषा-विशिष्ट निर्देशिका में मौजूद हो सकता है। चाल उनके सही नाम से उनके लिए पूछना है। उदाहरण के लिए, लैटिन 1 वास्तव में है iso_8859-1। यदि आप इस पर एक मैन पेज करते हैं, और आपकी LANG सेटिंग्स सही हैं, तो आप देखते हैं कि आप क्या उम्मीद करते हैं; मैन पेज भाषा-विशिष्ट उपदिर ( en/man7/iso_8859-1.7) में पाया जाता है । लेकिन अगर आप iso-8859-1किसी कारण से पूछते हैं , तो आपको एएससीआईआई संस्करण मिलता है।