ইউনিক্স ফাইলের নাম এনকোডিং বোঝা

Question

ফাইলের নাম এনকোডিং কীভাবে কাজ করে তা বুঝতে আমার খুব কষ্ট হয়েছে। ইউনিক্স.এসই-তে আমি স্ববিরোধী ব্যাখ্যা খুঁজে পাই।

ফাইলের নামগুলি অক্ষর হিসাবে সংরক্ষণ করা হয়

অন্য উত্তরটি উদ্ধৃত করতে: লিনাক্সে ফাইল-সিস্টেমের চরিত্রের এনকোডিং সম্পর্কে বেশ কয়েকটি প্রশ্ন

[…] আপনি আপনার প্রশ্নে যেমন উল্লেখ করেছেন, একটি ইউনিক্স ফাইলের নাম কেবলমাত্র অক্ষরের অনুক্রম; কার্নেল এনকোডিং সম্পর্কে কিছুই জানে না, যা সম্পূর্ণরূপে একটি ব্যবহারকারী-স্থান (যেমন, অ্যাপ্লিকেশন-স্তর) ধারণা।

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

নিম্নলিখিত ধরে: একজন ব্যবহারকারী একটি র্যান্ডম এনকোডিং ব্যবহার এক্স , যা ফাইল অনুবাদ fooবাইট ক্রম মধ্যে α এবং ডিস্কে তা সংরক্ষণ করে। অন্য একজন ব্যবহারকারী এনকোডিং ওয়াই ব্যবহার করেন । এই এনকোডিং α অনুবাদ করার /, যা একটি ফাইল নামের মঞ্জুরিপ্রাপ্ত নয়। তবে, প্রথম ব্যবহারকারীর জন্য ফাইলটি বৈধ।

আমি ধরে নিই যে এই দৃশ্যটি ঘটতে পারে না।

ফাইলের নামগুলি বাইনারি ব্লব হিসাবে সংরক্ষণ করা হয়

অন্য উত্তরটি উদ্ধৃত করতে: লিনাক্সের ফাইল নাম এবং পাথের জন্য কোন চরসেট এনকোডিং ব্যবহৃত হয়?

যেমনটি অন্যদের দ্বারা উল্লিখিত হয়েছে, এর কোনও উত্তর নেই: ফাইলের নাম এবং পাথগুলিতে কোনও এনকোডিং নেই; ওএস কেবল বাইটের ক্রম নিয়ে কাজ করে। পৃথক অ্যাপ্লিকেশনগুলি কোনও উপায়ে এনকোড হওয়া হিসাবে তাদের ব্যাখ্যা করতে বেছে নিতে পারে, তবে এটি পরিবর্তিত হয়।

যদি সিস্টেম অক্ষর সাথে মোকাবিলা নয়, কিভাবে বিশেষ অক্ষর (যেমন পারেন /বা NULL) ফাইলের নাম নিষিদ্ধ হবে? / এনকোডিং ব্যতীত কোনও ধারণা নেই ।

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

আমিও ধরে নিয়েছি যে এটি ভুল।

এনকোডিংটি কোথায় ঘটে এবং নির্দিষ্ট অক্ষরগুলিকে অনুমতি না দেওয়ার ক্ষেত্রে বাধা কোথায়?

Comments

সমস্ত এনকোডিংগুলিতে নাল একই (0)।

— কেভিন

@ কেভিন যথেষ্ট নয়: ইউটিএফ -16, বা ইউসিএস -4 (= ইউটিএফ -32), বা বেশিরভাগ অন্যান্য মাল্টবাইটি এনকোডিংগুলি যা ASCII এর এক্সটেনশন নয় @

— গিলস 'অশুভ হওয়া বন্ধ করুন'

আসলে, রিকার্ডো মুরির উত্তরটিতে বাইটগুলি উল্লেখ করা উচিত ছিল এবং সেখানে চরিত্রগুলি নয় । বেশিরভাগ ফাইল সিস্টেমগুলি বাইটগুলি সঞ্চয় করে।

— গিলস 'অশুভ হওয়া বন্ধ করুন'

@Gilles: এখনও অন্য সময় আমি সত্যিই ঘড়ি কি দেখতে লিখিত ।

— ইনকনিস মিসেসি

Answer 1

সংক্ষিপ্ত উত্তর: ইউনিক্স / লিনাক্স / বিএসডি কার্নেল, ফাংশনটিতে বিধিনিষেধ আরোপ করা হয়েছে namei()। এনকোডিংটি ব্যবহারকারীর স্তরের প্রোগ্রামগুলিতে xterm, firefoxবা হিসাবে ঘটে ls।

আমি মনে করি আপনি ভুল প্রাঙ্গণ থেকে শুরু করছেন। ইউনিক্সের একটি ফাইলের নাম হ'ল স্বেচ্ছাসেবী মান সহ একটি বাইটের স্ট্রিং। কয়েকটি মান, 0x0 (ASCII Nul) এবং 0x2f (ASCII '/') কেবলমাত্র অনুমোদিত নয়, কোনও মাল্টি-বাইট অক্ষর এনকোডিংয়ের অংশ হিসাবে নয়, কিছু হিসাবে নয়। একটি "বাইট" একটি অক্ষরকে প্রতিনিধিত্ব করে এমন একটি সংখ্যা থাকতে পারে (এএসসিআইআই এবং অন্যান্য কিছু এনকোডিংগুলিতে) তবে একটি "চরিত্রের" জন্য 1 বাইটের বেশি প্রয়োজন হতে পারে (উদাহরণস্বরূপ, ইউনিকোডের ইউটিএফ -8 উপস্থাপনায় 0x7f এর উপরে কোড পয়েন্ট)।

এই সীমাবদ্ধতাগুলি ফাইলের নাম মুদ্রণ কনভেনশন এবং ASCII অক্ষর সেট থেকে উদ্ভূত হয়। আংশিক- বা পুরোপুরি দক্ষতার পথে (যেমন '/ usr / bin / cat' তে "usr", "বিন" এবং "বিড়াল" রয়েছে) এর মূল ইউনিক্সগুলি ASCII '/' (সংখ্যাগত 0x2f) মূল্যমান বাইট ব্যবহার করেছে । মূল ইউনিক্সগুলি স্ট্রিং বন্ধ করতে ASCII নুল ব্যবহার করেছিল। এই দুটি মান ব্যতীত, ফাইলের নামের বাইটগুলি অন্য কোনও মান ধরে নিতে পারে। ইউনিকোডের জন্য ইউটিএফ -8 এনকোডিংয়ে আপনি এর প্রতিধ্বনি দেখতে পারেন। '/' সহ মুদ্রণযোগ্য এএসসিআইআই অক্ষরগুলি ইউটিএফ -8 এ কেবল একটি বাইট নেয়। উপরের কোড পয়েন্টগুলির জন্য ইউটিএফ -8 এ নুল নিয়ন্ত্রণ অক্ষর ব্যতীত কোনও জিরো-মূল্যবান বাইট অন্তর্ভুক্ত নয়। ইউটিএফ -8 উদ্ভাবিত হয়েছিল পরিকল্পনা -9 এর জন্য, ইউনিক্সের সিংহাসনের উপস্থাপক।

পুরানো ইউনিক্সস (এবং এটি লিনাক্সের মতো দেখতে) এর একটি namei()ফাংশন ছিল যা কেবল একবারে একটি বাইট পাথ দেখায় এবং শূন্য-মূল্যবান বাইটে থামিয়ে 0x2F মূল্যমান বাইটে পাথগুলি টুকরো টুকরো করে। namei()ইউনিক্স / লিনাক্স / বিএসডি কার্নেলের অংশ, তাই ব্যতিক্রমী বাইট মান প্রয়োগ করা হয়।

লক্ষ্য করুন যে এখন পর্যন্ত, আমি বাইট মান সম্পর্কে কথা বলেছি, চরিত্রগুলি নয়। namei()বাইটগুলিতে কোনও অক্ষর শব্দার্থ প্রয়োগ করে না। এটি ব্যবহারকারী-স্তরের প্রোগ্রামগুলির মতো ls, যেমন বাইট মান বা চরিত্রের মানগুলির উপর ভিত্তি করে ফাইলের নামগুলি বাছাই করতে পারে। xtermঅক্ষরের এনকোডিংয়ের উপর ভিত্তি করে ফাইলের নামগুলির জন্য কী পিক্সেল জ্বলতে হবে তা স্থির করে। আপনি যদি না বলেন যে xtermআপনি ইউটিএফ -8 এনকোডযুক্ত ফাইলের নাম পেয়েছেন, আপনি যখন আবেদন করবেন তখন আপনি প্রচুর জিবির দেখতে পাবেন। যদি vimইউটিএফ -8 (বা যাই হোক না কেন, ইউটিএফ -16, ইউটিএফ -32) এনকোডিংগুলি সনাক্ত করতে সংকলিত না হয়, আপনি যখন ইউটিএফ -8 এনকোডেড অক্ষরযুক্ত একটি "পাঠ্য ফাইল" খুলবেন তখন আপনি প্রচুর জিব্বারিজ দেখতে পাবেন।

Comments

সঠিক, namei()1986 সালের দিকে ত্যাগ করা হয়েছিল New নতুন ইউনিক্স সিস্টেমটি lookuppn()ভিএফএস ভিত্তিক ব্যবহার করে।

— স্কিচলি

Answer 2

জিনিসটি হ'ল, কার্নেলটি কিছুটা বিবেচনা করে না যে অ্যাপ্লিকেশনগুলি ফাইলের নাম হিসাবে দেওয়া ডেটার ব্যাখ্যা করে।

আসুন কল্পনা করুন আমার কাছে একটি সি অ্যাপ্লিকেশন রয়েছে যা একচেটিয়াভাবে ইউটিএফ -16 স্ট্রিং নিয়ে কাজ করে। এবং আমি একটি সঠিকভাবে কনফিগার করা ইনপুট পদ্ধতিটির মাধ্যমে ∯ চিহ্নটি (ইউনিকোড 0x222F) "সংরক্ষণ হিসাবে সংরক্ষণ করুন" প্রম্পট / কথোপকথনে প্রবেশ করি।

যদি অ্যাপ্লিকেশন কোনও রূপান্তর অনুবাদ করে না এবং এটি পাঠায়, সরল পুরানো সি স্ট্রিং ( char*) তে, fopenলিখন মোডে বলতে, কার্নেলটি not দেখতে পাবে না, এমনকি এটি কল্পনা করার চেষ্টাও করবে না। এটি দুটি charএর পরে একের পর এক মান দেখতে পাবে 0x22 0x2F(8 বিট অক্ষর এবং সি লাইব্রেরিতে কোনও মজাদার নয় ) with
এটি, কার্নেলের দৃষ্টিকোণ থেকে, একটি বৈধ চর ( ") এর পরে /(ASCII 0x2F)। fopenফিরে আসবে EISDIR(অর্থাত্ "এটি একটি ডিরেক্টরি মত দেখায় এবং আপনি লিখিত মোডে অনুরোধ করেছেন!")।
যদি আমি ∮ (ইউনিকোড 0x222E) প্রবেশ করতাম , কার্নেলটি দুটি সূক্ষ্ম অক্ষর দেখতে পেত এবং একটি ফাইল তৈরি করেছিল যা ASCII- স্পিকিং অ্যাপ্লিকেশনের মাধ্যমে দেখা যায়, নামকরণ করা হবে ".।

যদি আমি aকোনও ফাইলের নাম হিসাবে অ্যাপ্লিকেশনটিতে প্রবেশ করিয়েছি এবং অ্যাপ্লিকেশনটি এটি ইউটিএফ -16 এর মধ্যে দিয়ে কার্নেলের কাছে দিয়ে গেছে, কার্নেলটি পড়বে 0x00 0x61, এবং আসলে এটি বিবেচনাও করবে না 0x61, কারণ 0x00ইতিমধ্যে স্ট্রিংটি ইতিমধ্যে বন্ধ করে দিচ্ছে সংশ্লিষ্ট। ত্রুটি বার্তাটি খালি ফাইল নাম হিসাবে একই হবে ( ENOENTআমি বিশ্বাস করি)।

সুতরাং কার্নেলটি একটি ব্লব হিসাবে ডেটা গ্রহণ করে। এটি এস এর একটি স্ট্রিম char। আপনার পছন্দ অনুসারে আপনার ব্যবহারকারী-স্পেস এনকোডিংয়ের অবৈধ "অক্ষরগুলি" হ'ল তারা যা তাদের ব্লাবে জেনারেট করে 0x00বা 0x2F("নাল" এবং /) (বাইনারি উপস্থাপনা যা কার্নেলের কাছে পৌঁছে যায়)।

Comments

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

— মার্কো

হ্যাঁ, আপনি যদি এটি দেখতে চান তবে এটি ধারণা। (তবে এটি ভুল হতে পারে A কার্নেলের একটি "নেটিভ এনকোডিং" /থাকতে পারে যেখানে 0x2F নয় - charsবাস্তবে 8-বিট ব্যবহার করা যায় না )) "ট্র্যাডিশনাল" দির বিভাজক /। এটি 8 বিট বাইট ASCII (উদাহরণস্বরূপ EBCDIC নয়) সিস্টেমে 0x27।

— মাদুর

আপনি ইউটিএফ -16 বিই ধরেছেন, যেখানে ইউটিএফ-16 এলই ইউ + 0061 এর ফলাফল (নাল-টার্মিনেটেড) aস্ট্রিংয়ের ফলে আসবে ।

— ইনকনিস মিসেসি

Answer 3

বাইটস বনাম অক্ষরের বিভাজনটি ইউনিক্স ডিজাইনের পরে অনেক পরে এসেছিল। যখন এটি শব্দগুলির ব্যবহারের জন্য তৈরি করা হয়েছিল তখন কীভাবে 8 (বা 6, বা 9) বিট ব্যাখ্যা করা হয়েছিল তবে এনকোডিং শব্দের উল্লেখ করা হয়নি about

ফাইলের নামগুলি বাইটের ক্রম। 0x2f "/" ব্যতীত যে কোনও বাইট অনুমোদিত। স্ট্রিং টার্মিনেটর হিসাবে ব্যবহারের কারণে 0x00যুক্ত একটি বাইট এমনকি কার্নেলটিতে প্রবেশ করতে পারে না। কোনও অ্যাপ্লিকেশন এটি বেছে নেওয়া এনকোডিং অনুসারে বাইটের ক্রম ব্যাখ্যা করতে পারে। যদি তা অগোছালো মনে হয় আমি মনে করি এটি হয়।

Http://www.gtk.org/api/2.6/glib/glib-Character-Set-Cversvers.html এ আরও তথ্য রয়েছে যা আপনি দরকারী হিসাবে দেখতে পারেন।