"LC_ALL = C" क्या करता है?


324

क्या करता है Cके लिए मूल्य LC_ALLयूनिक्स सिस्टम में करते हैं?

मुझे पता है कि यह सभी पहलुओं के लिए एक ही स्थान को मजबूर करता Cहै लेकिन क्या करता है?


यदि आप xclockचेतावनी ( Missing charsets in String to FontSet conversion) के साथ एक समस्या को हल करना चाहते हैं , तो बेहतर होगा कि आप LC_ALL=C.UTF-8सिरिलिक के साथ समस्याओं से बचने के लिए उपयोग करेंगे । इस परिवेश चर को सेट करने के लिए आपको ~/.bashrcफ़ाइल के अंत में निम्नलिखित पंक्ति को जोड़ना होगा -export LC_ALL=C.UTF-8
फेड्सोल्डियर

@fedotsoldier आपको शायद सवाल पूछना चाहिए और खुद को जवाब देना चाहिए, मुझे नहीं लगता कि यह सवाल से संबंधित है। यह आपको होने वाली विभिन्न समस्या का जवाब है।
ज्यूबिक

हाँ, आप सही हैं, ठीक है
फेड्सोल्डियर

जवाबों:


209

यह अनुप्रयोगों को आउटपुट के लिए डिफ़ॉल्ट भाषा का उपयोग करने के लिए मजबूर करता है:

$ LC_ALL=es_ES man
¿Qué página de manual desea?

$ LC_ALL=C man
What manual page do you want?

और बलों को बाइट-वार करने के लिए छांटना:

$ LC_ALL=en_US sort <<< $'a\nb\nA\nB'
a
A
b
B

$ LC_ALL=C sort <<< $'a\nb\nA\nB'
A
B
a
b

20
अच्छा छूट के लिए +1, लेकिन स्टीफन के जवाब में महत्वपूर्ण जानकारी का अभाव है ...
ओलिवियर दुलैक

4
डिफ़ॉल्ट भाषा से आपका क्या अभिप्राय है ?
स्टीफन चेजलस

2
हां, मैं समझता हूं कि लेखक जो कुछ भी पसंद करता है उसे वह कर सकता है जिसमें वह नहीं है जो वह टिन पर कहता है। बात है। US अंग्रेजी एकमात्र भाषा है जिसे LC_ALL = C में चारसेट के साथ सही ढंग से दर्शाया जा सकता है, एकमात्र भाषा जहां LC_ALL = C (LC_COLLATE) में क्रमबद्ध क्रम समझ में आता है, LC_ALL = C (LC_TIME) में अंग्रेजी महीना और दिन के नाम हैं। मैंने ऐसे ऐप्स कभी नहीं देखे हैं जहां LC_ALL = C ने एक अलग भाषा में LC_ALL = en LANGUAGE = en से संदेश लौटाया है। तो क्या मैं एक कार्यक्रम के खिलाफ बग की रिपोर्ट करने का हकदार हूं अगर यह मामला नहीं है? (यहां अंग्रेजी में अनुवादित नहीं होने वाले ऐप्स के बारे में बात कर रहे हैं)।
स्टीफन चेज़लस

2
समस्या यह है कि "यूएस इंग्लिश एकमात्र भाषा है जिसे LC_ALL = C" में चारसेट के साथ सही ढंग से दर्शाया जा सकता है। यह आमतौर पर केवल सी / सी ++ कार्यक्रमों में सही होता है जब संकीर्ण वर्णों का उपयोग किया जाता है, लेकिन फिर भी अपवाद हैं (चूंकि कई भाषाएं हैं जो केवल ASCII में पाए जाने वाले वर्ण और प्रतीकों का उपयोग करती हैं)। एक बग की रिपोर्ट करना जब डिफ़ॉल्ट भाषा अंग्रेजी नहीं है, तो आपको लगता है ... बिगॉटेड।
इग्नासियो वाज़केज़-अब्राम्स

3
ध्यान दें कि अंग्रेजी में (जिसका अर्थ है LANG = en_US.utf8) संदेश (और चाहिए) स्ट्रिंग के उद्धरण के लिए "" जैसे यूनिकोड वर्णों का उपयोग कर सकते हैं। जबकि LANG = C में, इसमें केवल ASCII वाले (डबल कोट्स, बैकक्वाट्स और एपोस्ट्रोफिस) हैं।
Ángel

332

LC_ALLपर्यावरण चर है जो अन्य सभी स्थानीयकरण सेटिंग्स ( कुछ परिस्थितियों को छोड़कर$LANGUAGE ) को ओवरराइड करता है ।

स्थानीयकरणों के विभिन्न पहलुओं (जैसे हजार विभाजक या दशमलव बिंदु चरित्र, वर्ण सेट, क्रमबद्धता क्रम, महीना, दिन के नाम, भाषा या त्रुटि संदेश, मुद्रा प्रतीक जैसे एप्लिकेशन संदेश) को कुछ पर्यावरण चर का उपयोग करके सेट किया जा सकता है।

आप आम तौर पर $LANGअपने क्षेत्र को पहचानने वाले मान के साथ अपनी प्राथमिकता पर सेट होते हैं (जैसे fr_CH.UTF-8कि यदि आप फ्रेंच बोलने वाले स्विट्जरलैंड में हैं, तो यूटीएफ -8 का उपयोग करके)। अलग-अलग LC_xxxचर एक निश्चित पहलू को ओवरराइड करते हैं। LC_ALLउन सभी को ओवरराइड करता है। localeआदेश, जब तर्क के बिना कहा जाता है वर्तमान सेटिंग्स की एक सारांश देता है।

उदाहरण के लिए, एक ग्नू प्रणाली पर, मुझे मिलता है:

$ locale
LANG=en_GB.UTF-8
LANGUAGE=
LC_CTYPE="en_GB.UTF-8"
LC_NUMERIC="en_GB.UTF-8"
LC_TIME="en_GB.UTF-8"
LC_COLLATE="en_GB.UTF-8"
LC_MONETARY="en_GB.UTF-8"
LC_MESSAGES="en_GB.UTF-8"
LC_PAPER="en_GB.UTF-8"
LC_NAME="en_GB.UTF-8"
LC_ADDRESS="en_GB.UTF-8"
LC_TELEPHONE="en_GB.UTF-8"
LC_MEASUREMENT="en_GB.UTF-8"
LC_IDENTIFICATION="en_GB.UTF-8"
LC_ALL=

मैं उदाहरण के लिए एक व्यक्तिगत सेटिंग को ओवरराइड कर सकता हूं:

$ LC_TIME=fr_FR.UTF-8 date
jeudi 22 août 2013, 10:41:30 (UTC+0100)

या:

$ LC_MONETARY=fr_FR.UTF-8 locale currency_symbol
€

या LC_ALL के साथ सब कुछ ओवरराइड करें।

$ LC_ALL=C LANG=fr_FR.UTF-8 LC_MESSAGES=fr_FR.UTF-8 cat /
cat: /: Is a directory

एक स्क्रिप्ट में, यदि आप किसी विशिष्ट सेटिंग को बाध्य करना चाहते हैं, जैसा कि आप नहीं जानते हैं कि उपयोगकर्ता ने कौन सी सेटिंग्स को मजबूर किया है (संभवतः LC_ALL साथ ही), तो आपका सबसे अच्छा, सबसे सुरक्षित और आम तौर पर केवल विकल्प LC_ALL को मजबूर करना है।

Cलोकेल एक विशेष स्थान है कि सबसे सरल वातावरण करने के लिए है है। आप यह भी कह सकते हैं कि जबकि अन्य स्थान मनुष्यों के लिए हैं, सी लोकेल कंप्यूटरों के लिए है। सी लोकेल में, पात्र सिंगल बाइट्स होते हैं, चारसेट ASCII है (ठीक है, की आवश्यकता नहीं है, लेकिन व्यवहार में सिस्टम में होगा हममें से अधिकांश को कभी-कभी उपयोग करने के लिए मिलेगा), सॉर्टिंग ऑर्डर बाइट मानों पर आधारित है भाषा आमतौर पर यूएस इंग्लिश होती है (हालांकि एप्लिकेशन मैसेज के लिए (जैसा कि सिस्टम लाइब्रेरी के लिए महीने या दिन के नाम या संदेश जैसी चीजों के विपरीत), यह एप्लिकेशन लेखक के विवेक पर है) और मुद्रा प्रतीकों जैसी चीजों को परिभाषित नहीं किया जाता है।

कुछ प्रणालियों पर, POSIX लोकेल के साथ अंतर होता है, उदाहरण के लिए, गैर-ASCII वर्णों के लिए क्रम क्रम परिभाषित नहीं होता है।

आप आमतौर पर अपनी स्क्रिप्ट के साथ हस्तक्षेप करने के लिए उपयोगकर्ता की सेटिंग से बचने के लिए LC_ALL = C के साथ एक कमांड चलाते हैं। उदाहरण के लिए, अगर आप चाहते हैं [a-z]से 26 ASCII वर्ण से मेल करने aके लिए z, आप सेट करना होगा LC_ALL=C

GNU सिस्टम पर, LC_ALL=Cऔर LC_ALL=POSIX(या LC_MESSAGES=C|POSIX) ओवरराइड $LANGUAGE, जबकि LC_ALL=anything-elseनहीं होगा।

कुछ मामले जहां आपको आमतौर पर सेट करने की आवश्यकता होती है LC_ALL=C:

  • sort -uया sort ... | uniq...। सी के अलावा कई स्थानों पर, कुछ प्रणालियों पर (विशेष रूप से GNU वाले), कुछ वर्णों में समान क्रमबद्धता होती हैsort -uअद्वितीय पंक्तियों की रिपोर्ट नहीं करता है, लेकिन पंक्तियों के प्रत्येक समूह में से एक जिसमें समान क्रमबद्ध क्रम होता है। इसलिए यदि आप अद्वितीय रेखाएँ चाहते हैं, तो आपको एक स्थान की आवश्यकता होती है जहाँ वर्ण बाइट होते हैं और सभी वर्णों में अलग-अलग क्रमबद्ध क्रम होता है (जिसे Cस्थानीय निवासी गारंटी देते हैं)।
  • यही बात =POSIX कंप्लेंट के संचालक exprया POSIX के संचालक के संचालक पर लागू होती है ( और इस संबंध में POSIX नहीं हैं), कि दो तार समान हैं या नहीं, लेकिन वे समान हैं या नहीं इसकी जाँच करें।==awkmawkgawk
  • चरित्र श्रेणियों में जैसे grep। यदि आप उपयोगकर्ता की भाषा में एक पत्र से मेल खाते हैं, तो उपयोग करें grep '[[:alpha:]]'और संशोधित न करें LC_ALL। लेकिन अगर आप a-zA-ZASCII वर्णों का मिलान करना चाहते हैं , तो आपको LC_ALL=C grep '[[:alpha:]]'या तो match की आवश्यकता है LC_ALL=C grep '[a-zA-Z]'[a-z]उन पात्रों से मेल खाता है जो aपहले और बाद में सॉर्ट करता है z(हालांकि कई एपीआई के साथ यह उससे अधिक जटिल है)। अन्य स्थानों में, आप आमतौर पर नहीं जानते कि वे क्या हैं। उदाहरण के लिए, कुछ स्थान पैटर्न की [a-z]तरह कुछ एपीआई में सॉर्ट करने के लिए मामले को अनदेखा bashकर सकते हैं, शामिल [B-Z]कर सकते हैं या [A-Y]। बहुत से UTF-8 स्थानों में ( en_US.UTF-8अधिकांश प्रणालियों पर), [a-z]इसमें लातीक अक्षरों से aलेकर yनृतत्वशास्त्र तक शामिल होंगे , लेकिन उनमें से नहीं z(तब से)zउनसे पहले की तरह) जिसकी मैं कल्पना नहीं कर सकता कि आप क्या चाहते हैं (आप क्यों शामिल करना चाहते हैं éऔर नहीं ź?)।
  • चल बिन्दु अंकगणित में ksh93ksh93में decimal_pointसेटिंग का सम्मान करता है LC_NUMERIC। यदि आप एक स्क्रिप्ट लिखते हैं a=$((1.2/7)), तो यह काम करना बंद कर देगा जब एक उपयोगकर्ता जिसके लोकेल में दशमलव विभाजक के रूप में अल्पविराम है:

    $ ksh93 -c 'echo $((1.1/2))'
    0.55
    $ LANG=fr_FR.UTF-8  ksh93 -c 'echo $((1.1/2))'
    ksh93: 1.1/2: arithmetic syntax error
    

    फिर आपको चीजों की आवश्यकता है:

    #! /bin/ksh93 -
    float input="$1" # get it as input from the user in his locale
    float output
    arith() { typeset LC_ALL=C; (($@)); }
    arith output=input/1.2 # use the dot here as it will be interpreted
                           # under LC_ALL=C
    echo "$output" # output in the user's locale
    

    एक साइड नोट के रूप में: ,दशमलव विभाजक ,अंकगणितीय ऑपरेटर के साथ संघर्ष करता है जो और भी भ्रम पैदा कर सकता है।

  • जब आपको बाइट्स के लिए पात्रों की आवश्यकता होती है। आजकल, अधिकांश स्थान UTF-8 आधारित हैं, जिसका अर्थ है कि वर्ण 1 से 6 बाइट्स तक ले सकते हैं। पाठ उपयोगिताओं के साथ बाइट्स होने वाले डेटा से निपटने के दौरान, आप LC_ALL = C सेट करना चाहेंगे। यह प्रदर्शन को भी बेहतर करेगा क्योंकि UTF-8 डेटा पार्स करने में एक लागत है।
  • पिछले बिंदु की एक कोरोलरी: जब प्रसंस्करण पाठ जहां आपको पता नहीं है कि इनपुट किस वर्ण में लिखा गया है, लेकिन मान सकते हैं कि यह ASCII के साथ संगत है (जैसा कि सभी वर्ण हैं)। उदाहरण के लिए , यदि कोई UTF-8 लोकेल grep '<.*>'में है <, तो >जोड़ी कोई काम नहीं करेगी और इनपुट iso8859-15 जैसे एकल-बाइट 8-बिट वर्ण में एन्कोडेड है। ऐसा इसलिए है क्योंकि .केवल iso8859-15 में वर्णों और गैर-ASCII वर्णों से मेल खाता है, संभवत: UTF-8 में एक वैध चरित्र नहीं बनता है। दूसरी ओर, LC_ALL=C grep '<.*>'काम करेगा क्योंकि कोई भी बाइट मान Cलोकेल में एक वैध चरित्र बनाता है ।
  • किसी भी समय जहां आप इनपुट डेटा या आउटपुट डेटा संसाधित करते हैं जो मानव के लिए / से इरादा नहीं है। यदि आप किसी उपयोगकर्ता से बात कर रहे हैं, तो आप उनके कन्वेंशन और भाषा का उपयोग करना चाह सकते हैं, लेकिन उदाहरण के लिए, यदि आप कुछ अन्य एप्लिकेशन को फीड करने के लिए कुछ संख्याएँ उत्पन्न करते हैं जो अंग्रेज़ी शैली के दशमलव बिंदुओं या अंग्रेज़ी महीने के नामों की अपेक्षा करते हैं, तो आप चाहते हैं। LC_ALL = C सेट करें:

    $ printf '%g\n' 1e-2
    0,01
    $ LC_ALL=C printf '%g\n' 1e-2
    0.01
    $ date +%b
    août
    $ LC_ALL=C date +%b
    Aug
    

    यह मामला असंवेदनशील तुलना (जैसे grep -i) और केस रूपांतरण ( awk's toupper(), dd conv=ucase...) जैसी चीजों पर भी लागू होता है । उदाहरण के लिए:

    grep -i i
    

    Iउपयोगकर्ता के स्थान पर मेल करने की गारंटी नहीं है । उदाहरण के लिए कुछ तुर्की स्थानों में, यह ऊपरी स्थिति के रूप में नहीं iहै İ(ध्यान दें डॉट) और निचला-मामला Iहै ı(गायब डॉट पर ध्यान दें)।


Encoding पाठ के एन्कोडिंग पर निर्भर करता है, यह जरूरी नहीं कि सही बात है। यह UTF-8 या एकल-बाइट वर्ण सेट (जैसे iso-8859-1) के लिए मान्य है, लेकिन आवश्यक रूप से गैर-UTF-8 मल्टीबाइट वर्ण सेट नहीं है।

उदाहरण के लिए, यदि आप एक zh_HK.big5hkscsलोकेल (हांगकांग, BIG5 चीनी चरित्र एन्कोडिंग के हांगकांग संस्करण का उपयोग कर रहे हैं ), और आप उस वर्णमाला में एन्कोडेड फ़ाइल में अंग्रेज़ी अक्षर देखना चाहते हैं, तो या तो:

LC_ALL=C grep '[[:alpha:]]'

या

LC_ALL=C grep '[a-zA-Z]'

गलत होगा, क्योंकि उस चारसेट में (और कई अन्य, लेकिन शायद ही यूटीएफ -8 बाहर आने के बाद से उपयोग किया जाता है), बहुत सारे पात्रों में बाइट्स होते हैं जो ए-जे-जेड पात्रों के एएससीआईआई एन्कोडिंग के अनुरूप होते हैं । उदाहरण के लिए, सभी A䨝䰲丕乙乜你再劀劈呸哻唥唧噀噦嚳坽(और कई और) में एन्कोडिंग शामिल है A0x96 0x41 है, और AASCII की तरह 0x41 है। तो हमारा LC_ALL=C grep '[a-zA-Z]'उन रेखाओं पर मेल होता है, जिनमें वे वर्ण होते हैं क्योंकि यह बाइट्स के अनुक्रमों का गलत अर्थ लगाती है।

LC_COLLATE=C grep '[A-Za-z]'

काम करेगा, लेकिन केवल अगर LC_ALLअन्यथा सेट नहीं किया जाता है (जो ओवरराइड करेगा LC_COLLATE)। तो आप ऐसा करने के लिए समाप्त हो सकते हैं:

grep '[ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz]'

यदि आप लोकेल के एन्कोडिंग में एन्कोडेड फ़ाइल में अंग्रेजी अक्षर देखना चाहते हैं।


12
+1, यह सबसे अच्छा उत्तर है (ओवरराइडिंग आदि को इंगित करने के लिए)। लेकिन इग्नासियो के उत्तर के (अच्छे) उदाहरणों का अभाव है ^ ^
ओलिवियर दुलक

1
एक मामूली नाइटपिक: Cलोकेल को केवल "पोर्टेबल कैरेक्टर सेट" (ASCII 0-127) का समर्थन करने की आवश्यकता होती है, और वर्ण> 127 के लिए व्यवहार तकनीकी रूप से अनिर्दिष्ट है । व्यवहार में, अधिकांश कार्यक्रम उन्हें अपारदर्शी डेटा के रूप में मानेंगे और आपके द्वारा वर्णित के माध्यम से उन्हें पारित करेंगे। लेकिन सभी नहीं: विशेष रूप से, रूबी Cलोकेल में चलने पर बाइट> 127 के साथ चार डेटा पर चोक कर सकते हैं । मैं ईमानदारी से नहीं जानता कि क्या यह तकनीकी रूप से "अनुरूप" है, लेकिन हमने इसे जंगली में देखा है
एंड्रयू जंके

2
@AndrewJanke, हाँ। ध्यान दें कि पोर्टेबल वर्ण सेट ASCII और न ही 0-127 की घटना नहीं करता है। ऑस्टिन समूह की मेलिंग सूची में इस बात पर बहुत चर्चा हुई है कि "सी" लोकेल कैरेक्टर सेट के गुण क्या होंगे और आम सहमति (और अगले अनुमान में स्पष्ट की जाएगी) यह है कि चारसेट सिंगल होगा- बाइट, और पूर्ण 8 बिट रेंज (यहां वर्णित गुणों के साथ) शामिल हैं। इस बीच में, हाँ कुछ विचलन हो सकता है (जैसे बग या क्योंकि कल्पना स्पष्ट रूप से पर्याप्त नहीं है)। किसी भी सीमेण्ट में LC_ALL = C सबसे नज़दीकी है जिससे आप एक समझदार व्यवहार प्राप्त कर सकते हैं।
स्टीफन चेज़लस

1
UTF-8 में एक यूनिकोड कोडपॉइंट में अधिकतम 4 ऑक्टेट (या बाइट्स) हो सकते हैं, लेकिन कुछ कैरेक्टर को एक से अधिक कोडपॉइंट की जरूरत होती है, जिससे 6 ऑक्टेट से अधिक सीक्वेंस हो सकते हैं।
12431234123412341234123

1
@ 12431234123412341234123, मूल UTF-8 एन्कोडिंग में U + 7FFFFFFF (6 बाइट्स) शामिल हैं, और 13 बाइट्स जैसे perl's' तक जाने के लिए कुछ एक्सटेंशन हैं \x{7FFFFFFFFFFFFFFF}और जबकि यूनिकोड कोड पॉइंट्स की सीमा को मनमाने ढंग से U + 10FFFFFF तक सीमित कर दिया गया है (UTF-16 डिज़ाइन सीमा के कारण), कुछ उपकरण अभी भी 6 बाइट वर्णों को पहचानते / उत्पन्न करते हैं। यही कारण है कि मैं 6 बाइट पात्रों से मतलब था। यूनिक्स शब्दार्थ में, एक वर्ण एक कोडपॉइंट है। आपके एक से अधिक कोडपॉइंट "वर्ण" अधिक सामान्यतः वर्णों के खंडन करने के लिए अंगूर के समूहों के रूप में संदर्भित होते हैं।
स्टीफन चेजलस

7

Cडिफ़ॉल्ट लोकेल है, "POSIX" "C" का उपनाम है। मुझे लगता है कि "C" ANSI-C से लिया गया है। शायद एएनएसआई-सी "पोसिक्स" लोकेल को परिभाषित करता है।


C और UNIX दोनों अब तक ANSI C. की भविष्यवाणी करते हैं
एक CVn

@ माइकलकॉर्जलिंग: तो? मैंने प्री-एएनएसआई प्रलेखन देखा है, और इसमें स्थान नहीं हैं। आंतरिक रूप से एटी एंड टी बेल लैब्स में, हर कोई अंग्रेजी बोलता था।
MSAALERS

@MSalters तथ्य यह है कि सी भाषा के लिए पूर्व-एएनएसआई प्रलेखन में उन स्थानों का उल्लेख नहीं है (जो पूर्व-एएनएसआई, सी का पता नहीं लगा सकते हैं या नहीं कर सकते हैं; सब के बाद, मुझे पूरा यकीन है कि भाषा अभी भी नहीं है; , लेकिन इस बिंदु के बगल में) का अर्थ यह नहीं है कि Cस्थानीय नाम "ANSI C" से निकला है।
बजे एक CVn

2
@ MichaelKjörling: आप इस बिंदु को याद कर रहे हैं। जब लोकेशन की शुरुआत की गई, तो "C" का मतलब पहले से ही "ANSI C" था। इसका मतलब है कि K & R C अतीत में अप्रासंगिक है।
MSalters

3

जहां तक ​​मैं बता सकता हूं, OS X UTF-8 स्थानों में कोड पॉइंट कोलाजेशन ऑर्डर का उपयोग करता है, इसलिए यह स्टीफन चेज़लस द्वारा उत्तर में उल्लिखित कुछ बिंदुओं का अपवाद है।

यह ओएस एक्स में 26 प्रिंट करता है और उबंटू में 310:

export LC_ALL=en_US.UTF-8
printf %b $(printf '\\U%08x\\n' $(seq $((0x11)) $((0x10ffff))))|grep -a '[a-z]'|wc -l

नीचे दिए गए कोड OS X में कुछ भी प्रिंट नहीं करते हैं, यह दर्शाता है कि इनपुट सॉर्ट किया गया है। हटाए गए छह सरोगेट वर्ण एक अवैध बाइट अनुक्रम त्रुटि का कारण बनते हैं।

export LC_ALL=en_US.UTF-8
for ((i=1;i<=0x1fffff;i++));do
  x=$(printf %04x $i)
  [[ $x = @(000a|d800|db7f|db80|dbff|dc00|dfff) ]]&&continue
  printf %b \\U$x\\n
done|sort -c

नीचे दिए गए कोड OS X में कुछ भी नहीं दिखाते हैं, यह दर्शाता है कि लगातार दो कोड बिंदु नहीं हैं (कम से कम U + 000B और U + D7FF के बीच) जिसमें समान टकराव क्रम है।

export LC_ALL=en_US.UTF-8
for ((i=0xb;i<=0xd7fe;i++));do
  printf %b $(printf '\\U%08x\\n' $((i+1)) $i)|sort -c 2>/dev/null&&echo $i
done

(उपरोक्त उदाहरण %bक्योंकि printf \\U25zsh में त्रुटि के कारण उपयोग किया जाता है।)

ग्नू प्रणालियों में समान कोलाजेशन वाले वर्णों के कुछ वर्णों और अनुक्रमों का OS X में समान समतलीकरण क्रम नहीं होता है। यह प्रिंट पहले OS X (OS OS sortया GNU का उपयोग करके sort) करता है, लेकिन उबंटू में पहले of

export LC_ALL=en_US.UTF-8;printf %s\\n ② ①|sort

यह ओएस एक्स में तीन लाइनें प्रिंट करता है (ओएस एक्स sortया जीएनयू का उपयोग करके sort) लेकिन उबंटू में एक लाइन:

export LC_ALL=en_US.UTF-8;printf %b\\n \\u0d4c \\u0d57 \\u0d46\\u0d57|sort -u

क्या किसी को पता है कि यह अंतर क्यों है?
1.61803

3

ऐसा प्रतीत होता है कि LC_COLLATEls द्वारा उपयोग किए गए "वर्णमाला क्रम" को भी नियंत्रित करता है। अमेरिकी स्थान इस प्रकार होगा:

a.C
aFilename.C
aFilename.H
a.H

मूल रूप से पीरियड्स को नजरअंदाज करना। आप पसंद कर सकते हैं:

a.C
a.H
aFilename.C
aFilename.H

मैं निश्चित रूप से कर दूंगा। LC_COLLATEइसे Cपूरा करने के लिए सेटिंग । ध्यान दें कि यह सभी राजधानियों के बाद निचले मामले को भी हल करेगा:

A.C
A.H
AFilename.C
a.C
a.H
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.