मेरे फ़ाइल नाम लिनक्स में 'सामान्य' क्यों दिखते हैं लेकिन विंडोज पर दूरस्थ रूप से नहीं?

Question

एक सहयोगी के साथ काम करते हुए मुझे एक अजीब मुद्दा मिला जो एन्कोडिंग से संबंधित लगता है। हम है कि इस तरह के रूप में सरल पर्याप्त फ़ाइल नाम कुछ छवियों के साथ काम कर रहे हैं city.gifया wine.gif, लेकिन जैसा कि एक उम्मीद कर सकते हैं बातें अधिक जब विशेष वर्ण जैसे का उपयोग कर आप जटिल é, ë, à। हम डच डेटा के साथ भी काम कर रहे हैं, जिसमें ये पात्र हैं, जैसे café( पब )। (फाइलों की उत्पत्ति पर हमारा नियंत्रण नहीं है।) यहां उन मुद्दों पर चर्चा शुरू होती है। निम्न फ़ाइल नाम केवल एक उदाहरण हैं। मुद्दा विकृति विज्ञान के साथ अन्य पात्रों के लिए भी होता है।

café-2.png
cafetaria.png
café.png

पहले और अंतिम आइटम में एक उच्चारण ई होना चाहिए (उच्चारण aigu, é)। जब यह टर्मिनल में लिनक्स (CentOS 6 & 7) में दिखाया जाता है, तो यह कैसे चलता है ls। लेकिन यहाँ विंडोज आता है! (विंडोज 10, 64 बिट का उपयोग करते हुए।) जब हमारे सर्वर के साथ एसएसएल के माध्यम से विंडोज पर कनेक्ट किया जाता है और फिर कॉलिंग होती है ls, तो ऊपर दी गई सूची इस तरह दिखती है:

café-2.png
cafetaria.png
caf▒.png

जैसा कि आप उम्मीद कर सकते हैं, पहली पंक्ति में अभी भी उच्चारण ई है é , लेकिन तीसरा नहीं है। इसके बजाय, मैं ▒इस चरित्र को देखता हूं - जो medium shadeयूनिकोड (9618 दशमलव) में है। यह अपने आप में अजीब है। हालाँकि, जब मैं फ़ाइल के साथ SFTP के माध्यम से कनेक्ट करता हूँ Filezilla (अभी भी विंडोज पर) मुझे यह देखने को मिलता है:

café-2.png
cafetaria.png
café.png

इसलिए अब चीजें बदल गई हैं: पहले एक éमें, क्रम में बदल गई है और तीसरे में सब कुछ ठीक है। मैंने यहां पाया कि लैटिन -1 <-> यूटीएफ -8 रूपांतरण के कारण यह सबसे अधिक संभावना है, अगर मैं सही हो गया तो गलत हो गया। लेकिन यह सब ठीक नहीं चल रहा है?

जैसा कि हम फ़ाइल नाम (SSH (पोटीन), या SFTP (filezilla)) को देखते हैं, लिनक्स उम्मीद के मुताबिक सबकुछ दिखाता है, विंडोज प्रतीत होता है कि असंगत व्यवहार है। क्या इन फ़ाइलनामों को 'सामान्य' करने का एक तरीका है - यानी उन्हें संपादित करें - और यह सुनिश्चित करें कि वे हर ओएस पर समान हैं; या कम से कम लगातार, और यदि हां, तो कैसे? UTF-8हमारी पसंद की एन्कोडिंग है।

हालांकि यह केवल एक सौंदर्य मुद्दा हो सकता है, यह नहीं है। जब हमारे लिनक्स सर्वर से विंडोज में एसएफटीपी के माध्यम से चीजों को डाउनलोड करने की कोशिश की जाती है, तो मैं उन फाइलों को डाउनलोड नहीं कर सकता जिनके पास ऊपर बताई गई समस्या है। Filezilla जैसे एक त्रुटि फेंक देंगे Can't download file café-2.png: café-2.png does not exist on the server। जो मुझे लगता है कि फाइलज़िला निर्देशिका और फ़ाइल नाम पढ़ता है, इसे कुछ एन्कोडिंग में व्याख्या करता है, सर्वर को इसकी व्याख्या के साथ एक जीईटी अनुरोध भेजता है, लेकिन यह व्याख्या लिनक्स फ़ाइल नाम से भिन्न होती है, इसलिए परिणामस्वरूप फ़ाइल नहीं मिली है।

अंततः यह अच्छा होगा यदि कोई समाधान उपलब्ध है, भले ही मुझे भी दिलचस्पी है कि ऐसा क्यों होता है। क्या ऐसा होता है क्योंकि छवि फ़ाइलों को संभवतः अलग-अलग ऑपरेटिंग सिस्टम पर बनाया गया था? क्या यह होता है क्योंकि लिनक्स सर्वर उन्हें गलत व्याख्या करता है, या विंडोज गड़बड़ कर रहा है? उम्मीद है कि एक ऐसा समाधान है जहाँ हम बस अपने sysadmin से संपर्क कर सकते हैं और उन्हें सर्वर कॉन्फिगर में स्विच चालू करने के लिए कह सकते हैं, लेकिन मुझे डर है कि यह उतना आसान नहीं है।

Comments

यह क्लाइंट (PuTTY, आदि), और उनके कॉन्फ़िगरेशन की बात है, और विंडोज के लिए प्रासंगिक नहीं है। PuTTY के लिए, यह अनुवाद अनुभाग में किया गया है ।

— थॉमस डिकी

यह इस तरह की तरह दिखता है कि "कैफ़े -२.पेंग" में é यूटीएफ-of इनकोडिंग है, लेकिन "कैफ़े.पिंग" में é आईएसओ-99५ ९ -१ एन्कोडेड है। क्या आप दौड़ सकते हैं python -c "import sys; print(repr(sys.argv[1]))" café-2.pngऔर python -c "import sys; print(repr(sys.argv[1]))" café.png?

— अक्टूबर को Oskar Skog

@OskarSkog मैं कोशिश करूंगा कि सुबह हो जाए। लेकिन मुझे हमेशा लगता था कि फ़ाइल नाम में एन्कोडिंग नहीं है, दूसरे शब्दों में: यह वैसा ही है जैसा कि ओएस चाहता है। तो क्या इसका मतलब यह होगा कि अलग-अलग ओएस पर अलग-अलग फाइलें बनाई गई थीं? (फाइलों की उत्पत्ति पर हमारा कोई नियंत्रण नहीं है।)

— ब्रैम वनरॉय

ऑपरेटिंग सिस्टम की तरह यूनिक्स पर, फ़ाइल नाम बस बाइट्स का एक स्ट्रिंग है। पात्रों की अवधारणा उच्च स्तर पर आती है।

— Oskar Skog

जवाब के करीब भी नहीं, या समाधान के लिए, आगे बढ़ने के लिए केवल एक विचार है। ओपी से ऐसा लगता है कि फ़ाइलों में मूल उत्पत्ति हो सकती है, स्रोत द्वारा उत्पन्न नाम पर कोई नियंत्रण नहीं है, और आने वाले फ़ाइल नाम स्नैफ़स को सही करने के लिए फ़िल्टर लागू करने के लिए बहुत देर हो चुकी है। समाधान में सर्वर पर एक स्क्रिप्ट चलाने की संभावना होती है जो फ़ाइल नाम त्रुटियों का पता लगा सकती है और सही कर सकती है, संभवतः नाम के लिए उपयोग किए गए वर्ण सेट / कोड पृष्ठ को भी मानकीकृत कर सकती है। तब ओपी फाइलज़िला, या अन्य क्लाइंट में एक ही कोड पेज का उपयोग कर सकता है, और चीजें काम करेंगी। मेरे कौशल से परे, लेकिन पालन करने के लिए एक नेतृत्व, हो सकता है।

— user207673

Answer 1

लेकिन यहाँ विंडोज आता है!

विंडोज का इससे कोई लेना-देना नहीं है। आप उचित रूप से चयनित टर्मिनल एन्कोडिंग और के लिए उचित रूप से कॉन्फ़िगर किया गया स्थान के साथ (माना) सूक्ति टर्मिनल की एक स्थानीय उदाहरण के साथ इस एक ही सटीक व्यवहार को पुनः सकता है, ls, बिना किसी भी Windows चित्र में किया जा रहा है सब पर ।

केवल एक चीज जो विंडोज करती है वह स्पष्ट रूप से दिखाती है कि यहां क्या चल रहा है। आपका विंडोज एफ़टीपी प्रोग्राम फ़ाइलनामों में बाइट्स ले रहा है और उन्हें कोड पेज 1252 में प्रासंगिक कोड बिंदुओं के रूप में प्रदर्शित कर रहा है। यह, एक सिंगल-बाइट 0x1F के ऊपर लगभग सब कुछ के साथ एन्कोडिंग एक मुद्रण योग्य ग्लिफ़ है, हमें बताता है कि आपके फ़ाइलनाम में बाइट्स वास्तव में क्या हैं। ।

आपका दूसरा फ़ाइलनाम काफी हद तक एकरूप है, लेकिन पहला और तीसरा बता रहे हैं।

• पहला फ़ाइल नाम बाइट अनुक्रम है 63 61 66 c3 a9 2d 32 2e 70 6e 67- कोड पृष्ठ 1252 में यह है café-2.png। यह UTF-8 की एन्कोडिंग भी है café-2.png।
• तीसरा फ़ाइल नाम बाइट अनुक्रम है 63 61 66 e9 2e 70 6e 67- कोड पृष्ठ 1252 में यह है café.png। हालाँकि, यह एक मान्य UTF-8 एन्कोडिंग नहीं है। e9एक अधूरा चरित्र एन्कोडिंग अनुक्रम शुरू करता है।

तो क्या हो रहा है कि चीजें कोड पृष्ठ 1252 का उपयोग नहीं कर रही हैं, लेकिन वह यूटीएफ -8 का उपयोग कर रही हैं, अर्थात् आपके एसएसएच सत्र और आपके स्थानीय टर्मिनल एमुलेटर, वैध यूटीएफ -8 को उसी तरह से संभाल रहे हैं जैसे एक दूसरे को संभाल रहे हैं लेकिन संभाल रहे हैं दो अलग-अलग तरीकों से अमान्य UTF-8:

• वह जो ब्लॉक ग्राफिक प्रदर्शित कर रहा है वह संभवतः उस ब्लॉक ग्राफिक का उपयोग कर रहा है जो कि अवैध UTF-8 दृश्यों के लिए सामान्य प्रतिस्थापन आउटपुट चरित्र के रूप में है ।
• जो अक्षर प्रदर्शित कर रहा है, éवह कोड पेज 1252 पर वापस आ रहा है, जब यह एक अवैध एन्कोडिंग का सामना करता है।

आपकी अंतर्निहित समस्या एक ऐसी प्रणाली है जो किसी तरह यूटीएफ -8 के रूप में एन्कोडेड कुछ फ़ाइलनाम उत्पन्न कर रही है और अन्य फाइलनेम कोड 1252 में एन्कोड किए गए हैं।

Comments

मैं इस बात से सहमत नहीं हूं कि विंडोज का इससे कोई लेना-देना नहीं है। यह संभवतः अन्य लिनक्स पर नहीं होगा। समस्या डिफ़ॉल्ट एन्कोडिंग है, और afaik Windows ने (या कम से कम पड़ा है) ने अपने CP का उपयोग किया है और UTF का नहीं, जिसके परिणामस्वरूप यह समस्या पूरे देशों में समान OS पर भी हो रही है। आप इसे लिनक्स पर पुन: पेश कर सकते हैं, लेकिन लिनक्स का यूनिकोड चुनने में अधिक सुसंगत है

— मैथोरॉक

नमस्ते! विस्तृत जवाब के लिए धन्यवाद। आप इस बात पर ध्यान केंद्रित करते हैं कि क्या हो रहा है, जो अच्छा है: मैं हमेशा यह समझना पसंद करता हूं कि क्या हो रहा है। लेकिन क्या आप शायद इस बात पर प्रकाश डाल सकते हैं कि ऐसा क्यों हो रहा है, और हम इस असंगति से आने वाले मुद्दों का मुकाबला कैसे कर सकते हैं? मैंने स्पष्ट करने के लिए दो पैराग्राफ जोड़े हैं।

— ब्रैम वनरॉय

मुझे आश्चर्य है कि जब वे नहीं होते हैं तो दोनों "कैफ़े" को समान क्यों दिखाया जाता है। क्या GNU के ls (1) में हास्यास्पद एन्कोडिंग त्रुटि है?

— Oskar Skog

@MatthewRock इस मामले में मुझे लगता है कि विंडोज का वास्तव में इससे कोई लेना-देना नहीं है। मैं एम $ क्या करता है के अधिकांश के साथ खुश नहीं हूं, और स्वेच्छा से अपनी कई बुराइयों को स्वीकार करता हूं, फिर भी मुझे दिए गए दोष को नहीं देख सकता है जहां कोई भी कारण नहीं है। जैसा कि उत्तर स्पष्ट करता है, समस्या स्वयं नामों के बाइट मूल्यों के साथ है। इस उदाहरण में विंडोज ने लक्षण को उजागर किया, लेकिन समस्या नहीं है। थर्मामीटर से अधिक कोई समस्या नहीं है जब यह दिखाता है कि आपका बुखार 104 ° है। समस्या उन प्रक्रियाओं के साथ उत्पन्न होती है, जो कुछ भी सर्वर उस सर्वर पर नाम बनाते हैं जिनके पास ओपी तक पहुंचने की कोशिश कर रही फाइलें हैं।

— user207673

क्या आप अधिक जानकारी और संभावित समाधान प्रदान कर सकते हैं? वरना मैंने अपना इनाम बिना कुछ लिए खर्च कर दिया।

— ब्रैम वनरॉय