লিনাক্সে আমার ফাইলের নামগুলি কেন 'স্বাভাবিক' দেখায় তবে উইন্ডোজ থেকে দূরবর্তীভাবে নয়?

Question

সহকর্মীর সাথে কাজ করার সময় আমি একটি অদ্ভুত সমস্যা পেয়েছি যা এনকোডিংয়ের সাথে সম্পর্কিত বলে মনে হচ্ছে। আমরা আশা করি আপনি যেমন সহজ যথেষ্ট ফাইলের নাম কিছু চিত্র সাথে কাজ করছি city.gifবা wine.gif, কিন্তু এক আশা করতে পারে কিছু করার সময়ও যেমন বিশেষ অক্ষর ব্যবহার আরো জটিল হতে é, ë, à। আমরা ডাচ ডেটাগুলির সাথেও কাজ করছি যার এই অক্ষরগুলি রয়েছে, যেমন café( পাব )। (ফাইলগুলির উত্সের উপর আমাদের নিয়ন্ত্রণ নেই)) এখানেই সমস্যাগুলি উত্থাপন শুরু হয়। নিম্নলিখিত ফাইলের নামগুলি একটি উদাহরণ। সমস্যাটি ডায়াক্রিটিক্স সহ অন্যান্য চরিত্রগুলির ক্ষেত্রেও ঘটে।

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

প্রথম এবং শেষ আইটেমটিতে একটি উচ্চারণযুক্ত ই থাকা উচিত (অ্যাকসেন্ট আইগু, é)। এটি চলমান অবস্থায় টার্মিনালে লিনাক্সে (সেন্টোস 6 এবং 7) এভাবে দেখানো হয় ls। তবে এখানে উইন্ডোজ আসে! (উইন্ডোজ 10, 64 বিট ব্যবহার করে)) এসএসএল এর মাধ্যমে যখন আমাদের সার্ভারের সাথে উইন্ডোজে সংযুক্ত থাকে এবং তারপরে ফোন করা হয় ls, উপরের তালিকাটি এরকম দেখাচ্ছে:

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

আপনি যেমন আশাবাদী দেখতে পাচ্ছেন, প্রথম লাইনে এখনও উচ্চারণকৃত ই রয়েছে é , তবে তৃতীয়টি নেই। পরিবর্তে, আমি ▒এই চরিত্রটি দেখতে পাচ্ছি - যা medium shadeইউনিকোডে (9618 দশমিক)। এটি নিজের মধ্যেই আজব। যাইহোক, আমি যখন এসটিটিপি-র মাধ্যমে ফাইলজিলার সাথে যুক্ত হয়ে যাই (উইন্ডোজে এখনও) আমি এটি দেখতে পাই:

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

সুতরাং এখন বিষয়গুলি ঘুরে দাঁড়িয়েছে: প্রথমটিতে, éক্রমটি পরিবর্তিত হয়েছে এবং তৃতীয়টিতে সবকিছু ঠিক আছে। আমি এখানে খুঁজে পেয়েছি যে এটি সম্ভবত সঠিক হয়ে থাকলে ল্যাটিন -1 <-> ইউটিএফ -8 রূপান্তরটি ভুল হয়ে গেছে বলেই সম্ভবত এটি ঘটেছে। কিন্তু ঠিক কি তাই হচ্ছে না?

লিনাক্স আমাদের প্রত্যাশা মতো সবকিছু দেখায়, উইন্ডোজ আমাদের ফাইল নাম (এসএসএইচ (পুটি), বা এসএফটিপি (ফাইলজিলা)) দেখার পদ্ধতি অনুসারে আপাতদৃষ্টিতে অস্বস্তিকর আচরণ দেখায়। এই ফাইলগুলির নামগুলিকে 'সাধারনকরণ' করার কোনও উপায় আছে - যেমন এডিট করুন - এবং নিশ্চিত করুন যে প্রতিটি ওএসে সেগুলি একই রকম; বা কমপক্ষে সামঞ্জস্যপূর্ণ, এবং যদি তাই হয়, কিভাবে? UTF-8আমাদের পছন্দসই এনকোডিং।

যদিও এটি নিছক একটি নান্দনিক সমস্যা হতে পারে, তবে তা নয়। আমাদের লিনাক্স সার্ভার থেকে উইন্ডোজ এসএফটিপি এর মাধ্যমে জিনিসগুলি ডাউনলোড করার চেষ্টা করার সময়, আমি উপরে উল্লিখিত সমস্যাযুক্ত ফাইলগুলি ডাউনলোড করতে পারি না। ফাইলজিলা যেমন একটি ত্রুটি নিক্ষেপ করবে Can't download file café-2.png: café-2.png does not exist on the server। আমার কাছে যা দেখে মনে হয় যে ফাইলজিলা ডিরেক্টরি এবং ফাইলের নামটি পড়ে, কোনও এনকোডিংয়ে এটি ব্যাখ্যা করে, এর ব্যাখ্যার সাথে সার্ভারে একটি জিইটি অনুরোধ প্রেরণ করে, তবে সেই ব্যাখ্যাটি লিনাক্স ফাইলের নাম থেকে পৃথক হয় ফলে ফলস্বরূপ ফাইলটি পাওয়া যায় না।

শেষ পর্যন্ত এটির কোনও সমাধান পাওয়া গেলে খুব ভাল লাগবে, যদিও আমি কেন আগ্রহী তা আগ্রহী । ইমেজ ফাইলগুলি সম্ভবত বিভিন্ন অপারেটিং সিস্টেমগুলিতে তৈরি করা হওয়ায় এটি কি ঘটে? লিনাক্স সার্ভার তাদের ভুল ব্যাখ্যা করে বা উইন্ডোজ গণ্ডগোল করছে বলে কি এটি ঘটে? আশা করি এমন একটি সমাধান রয়েছে যেখানে আমরা কেবল আমাদের সিসাদমিনের সাথে যোগাযোগ করতে পারি এবং তাদের সার্ভার কনফিগারেশনে একটি স্যুইচ চালু করতে বলি, তবে আমি ভয় করি যে এটি এতটা সহজ নয়।

Comments

এটি ক্লায়েন্টের (পিটিটিওয়াই ইত্যাদি) এবং তাদের কনফিগারেশন এবং উইন্ডোজের সাথে প্রাসঙ্গিক নয়। পুটিটির জন্য, এটি অনুবাদ বিভাগে করা হয়েছে।

— টমাস ডিকি

দেখে মনে হচ্ছে এটির মতো দেখতে c "ক্যাফে -২.পিএনজি" ইউটিএফ -৮ এনকোডযুক্ত, তবে c "ক্যাফে.পিএনজি" -তে আইএসও -8859-1 এনকোডযুক্ত। আপনি চালাতে পারেন python -c "import sys; print(repr(sys.argv[1]))" café-2.pngএবং python -c "import sys; print(repr(sys.argv[1]))" café.png?

— ওসকার স্কোগ

@ অস্কারস্কোগ আমি সকালে চেষ্টা করব। তবে আমি সবসময়ই ভেবেছিলাম যে ফাইলের নামগুলিতে একটি এনকোডিং নেই, অন্যথায়: এটি ওএস যেমন চায় তেমন। তাহলে এর অর্থ কি বিভিন্ন ওএস এর উপর বিভিন্ন ফাইল তৈরি করা হয়েছিল? (ফাইলগুলির উত্সের উপর আমাদের কোনও নিয়ন্ত্রণ নেই))

— ব্রাম ভ্যানরোয়

অপারেটিং সিস্টেমের মতো ইউনিক্সে, ফাইলের নামটি বাইটের একটি স্ট্রিং। চরিত্রগুলির ধারণাটি উচ্চ স্তরে আসে।

— ওসকার স্কোগ

এমনকি কোনও উত্তর, বা কোনও সমাধানের কাছেও নয়, কেবল অনুসরণের জন্য এভিনিউতে একটি চিন্তাভাবনা। ওপি থেকে মনে হয় যে ফাইলগুলি উত্সটি উত্পন্ন হতে পারে, উত্সটির দ্বারা উত্পাদিত নামের উপর কোনও নিয়ন্ত্রণ নেই এবং ইনকামিং ফাইলের নাম স্নাফাস সংশোধন করতে ফিল্টার প্রয়োগ করতে খুব দেরি হয়েছে। সমাধানটি সম্ভবত সার্ভারে এমন একটি স্ক্রিপ্ট চালানো জড়িত যা ফাইলের নাম ত্রুটিগুলি সনাক্ত করতে এবং সংশোধন করতে পারে, এমনকি নামগুলির জন্য ব্যবহৃত অক্ষর সেট / কোড পৃষ্ঠা মানিক করে তোলাও। তারপরে ওপি ফাইলজিলা বা অন্য ক্লায়েন্টে একই কোড পৃষ্ঠাটি ব্যবহার করতে পারে এবং জিনিসগুলি কাজ করবে। আমার দক্ষতার বাইরে, তবে অনুসরণ করার জন্য নেতৃত্ব, সম্ভবত।

— ব্যবহারকারী 207673

Answer 1

তবে এখানে উইন্ডোজ আসে!

উইন্ডোজ এর সাথে কিছুই করার নেই। আপনি উপযুক্তভাবে নির্বাচিত টার্মিনাল এনকোডিং এবং জন্য উপযুক্তভাবে কনফিগার লোকেল সঙ্গে (বলুন) গনোম টার্মিনাল স্থানীয় নিদর্শনের সঙ্গে এই একই সঠিক আচরণ নকল করা যায়নি, lsছাড়া কোনো উইন্ডোজ ছবিতে হচ্ছে এ সব ।

উইন্ডোজ যা করে তা কেবল এখানে কী চলছে তা স্পষ্টভাবে দেখানো। আপনার উইন্ডোজ এফটিপি প্রোগ্রামটি ফাইলের নামগুলিতে বাইট নিচ্ছে এবং কোড পৃষ্ঠাতে প্রাসঙ্গিক কোড পয়েন্ট হিসাবে এটি প্রদর্শিত হচ্ছে। এটি, 0x1F এর উপরে প্রায় সমস্ত কিছু সহ একটি একক বাইট এনকোডিং যা একটি মুদ্রণযোগ্য গ্লাইফ, আমাদের ফাইলের নামগুলির বাইটগুলি ঠিক কী ।

আপনার দ্বিতীয় ফাইলের নামটি বেশিরভাগ ক্ষেত্রে অপ্রয়োজনীয়, তবে প্রথম এবং তৃতীয়টি বলছে।

• প্রথম ফাইলের নামটি বাইট ক্রম 63 61 66 c3 a9 2d 32 2e 70 6e 67- কোড পৃষ্ঠাতে 1252 এটি café-2.png। এটি ইউটিএফ -8 এনকোডিংও café-2.png।
• তৃতীয় ফাইলের নামটি বাইট ক্রম 63 61 66 e9 2e 70 6e 67- কোড পৃষ্ঠাতে 1252 এটি café.png। এটি অবশ্য বৈধ ইউটিএফ -8 এনকোডিং নয়। e9একটি অসম্পূর্ণ অক্ষর এনকোডিং ক্রম শুরু হয়।

সুতরাং যা হচ্ছে তা হ'ল জিনিসগুলি কোড পৃষ্ঠা 1252 ব্যবহার করছে না তবে এটি ইউটিএফ -8 ব্যবহার করছে যা আপনার এসএসএইচ সেশন এবং আপনার স্থানীয় টার্মিনাল এমুলেটরটি একে অপরের মতো একইভাবে বৈধ ইউটিএফ -8 পরিচালনা করছে তবে পরিচালনা করছে অবৈধ হল UTF-8 দুটি ভিন্ন উপায়ে:

• যেটি ব্লক গ্রাফিক প্রদর্শন করছে তা সম্ভবত অবৈধ ইউটিএফ -8 অনুক্রমের জন্য সাধারণ প্রতিস্থাপন আউটপুট অক্ষর হিসাবে সেই ব্লক গ্রাফিকটি ব্যবহার করছে ।
• চিঠিটি প্রদর্শিত éহচ্ছে এমনটি কোড পৃষ্ঠা 1252 এ ফিরে যাচ্ছে যখন এটি একটি অবৈধ এনকোডিংয়ের মুখোমুখি হয়।

আপনার অন্তর্নিহিত সমস্যাটি এমন একটি সিস্টেম যা কোনওরকমভাবে ইউটিএফ -8 হিসাবে এনকোড করা কিছু ফাইল নাম এবং কোড পৃষ্ঠা 1252 এ এনকোডযুক্ত অন্যান্য ফাইলের নাম তৈরি করছে।

Comments

আমি একমত নই যে এর সাথে উইন্ডোজের কোনও সম্পর্ক নেই। এটি সম্ভবত অন্যান্য লিনাক্সে ঘটবে না। সমস্যাটি ডিফল্ট এনকোডিং এবং আফিক উইন্ডোজ তাদের সিপি ব্যবহার করেছে (বা কমপক্ষে এটি করেছে) ইউটিএফ নয়, ফলে এই সমস্যাটি সারা দেশে একই ওএসে ঘটছে happening আপনি এটি লিনাক্সে পুনরুত্পাদন করতে পারেন, তবে ইউনিকোড বেছে নেওয়ার ক্ষেত্রে লিনাক্স আরও সুসংগত

— ম্যাথিউরক

হাই! বিস্তৃত উত্তরের জন্য ধন্যবাদ। আপনি যা ঘটছে তার দিকে মনোনিবেশ করুন, যা দুর্দান্ত: আমি সবসময় কী ঘটছে তা বুঝতে পছন্দ করি। তবে আপনি সম্ভবত কী কারণে এটি ঘটছে এবং কীভাবে আমরা এই অসঙ্গতি থেকে অনুসরণ করা সমস্যাগুলি মোকাবিলা করতে পারি তার উপর আলোকপাত করতে পারেন? আমি কী বলতে চাইছি তা স্পষ্ট করতে আমি দুটি অনুচ্ছেদ যুক্ত করেছি।

— ব্রাম ভ্যানরোয়

আমি অবাক হয়েছি কেন "ক্যাফে" উভয়কেই যখন তারা না হয় তখন কেন একই রকম দেখানো হয়? GNU এর ls (1) এর একটি হাস্যকর এনকোডিং ত্রুটি পরিচালনা করছে?

— ওসকার স্কোগ

@ ম্যাথেররক এই ক্ষেত্রে আমি মনে করি উইন্ডোজ এর সাথে আসলেই কিছু করার নেই। আমি মি যা করে তার বেশিরভাগ ক্ষেত্রেই সন্তুষ্ট নই এবং স্বেচ্ছায় এর অনেকগুলি কুফল স্বীকার করি, তবুও আমি দোষ দেখতে পাচ্ছি না যেখানে কোনটিই প্রদত্ত নয়। উত্তরটি যেমন স্পষ্ট করে দেয়, সমস্যাটি তাদের নিজের নামের বাইট মানগুলির সাথে। এই উদাহরণে উইন্ডোজ লক্ষণ প্রকাশ করেছে, কিন্তু সমস্যা নয়। আপনার জ্বর 104 show দেখায় তখন থার্মোমিটারের চেয়ে বেশি সমস্যা হয় না ° ওপি অ্যাক্সেস করার চেষ্টা করছে এমন ফাইলগুলি যে সার্ভারে নাম তৈরি করেছে তা থেকেই সমস্যার উদ্ভব হয়।

— ব্যবহারকারী 207673

আপনি আরও তথ্য এবং সম্ভাব্য সমাধান প্রদান করতে পারেন? অন্যথায় আমি আমার অনুগ্রহ কিছুই ব্যয় করেছি।

— ব্রাম ভানরোয়