|
برای نام پرونده‌ها یک رمزگذاری استاندارد عمومی وجود ندارد.
چرا که نام پرونده‌ها باید میان نرم افزارهانرم‌افزارها مبادله شوند (انتقال فایل شبکه، ذخیرهٔ فایل سیستم، نرم افزارنرم‌افزار پشتیبانی و هماهنگ سازیهماهنگ‌سازی پرونده، مدیریت پیکربندی، فشرده سازیفشرده‌سازی و بایگانی داده و…)، این بسیار مهم است که اطلاعات نام پرونده میان دو نرم افزارنرم‌افزار کاربردی از دست نرود. این مسئله موجب پذیرش گستردهٔ یونی‌کد به عنوانبه‌عنوان استانداردی برای رمزگذاری پرونده‌ها شد، گرچه برخی نرم افزارهاینرم‌افزارهای قدیمی ممکن است یونی‌کد را متوجه نشوند.
=== قابلیت همکاری نشانهٔ رمزگذاری ===
در گذشته، نام پرونده‌ها در هر کاراکتری را تا جایی که برای فایل سیستم ایمن بود در نام پرونده‌های خود مجاز می‌دانستند. با اینکه این روش استفاده از هرگونه رمزگذاری را مجاز می‌داند، و به همین دلیلدلیل، امکان نمایش هر متن محلی را در هر سامانهٔ محلی فراهم می‌کند، منجر به بسیاری از قابلیت‌های همکاری می‌شود.
یک نام پرونده داخل یک کشور ممکن است با استفاده از رشته‌های بایتی متفاوتی در سامانه‌های متمایز ذخیره شده باشد، مثلاً یکی با استفاده از رمزگذاری Japanese Shift یا JIS و دیگری از رمزگذاری Japanese EUC. تبدیل ممکن نبودهنبوده؛ زیرا بیشتر سامانه‌ها شرحی از رمزگذاری که برای یک نام پرونده استفاده شده را به عنوان قسمتی از اطلاعات فایل توسعه یافتهتوسعه‌یافته نمایش نمی‌دادند.
یک راه حلحل، پذیرش یونی‌کد برای رمزگذاری نام پرونده‌ها بود.
اما در MacMacOS OS کلاسیککلاسیک، رمزگذاری نام پرونده‌ها همراه خصوصیات نام پرونده ذخیره می‌شد.
=== قابلیت همکاری یونی کدیونی‌کد ===
استاندارد یونی کدیونی‌کد مسئلهٔ تشخیص رمزگذاری را برطرف کرد.
با این حال، بعضی مسائل قابلیت همکاری محدود از قبیل هنجارسازی یا normalization (هم‌ارزی)، یا نسخهٔ در حال استفادهٔ یونی کدیونی‌کد باقی ماند. برای نمونه، UDF به یونی کدیونی‌کد ۲٫۰ محدود شد؛ Mac OSMacOS هنجارسازی یونی‌کد NFD که به‌طور اختیاری می‌تواند به حروف کوچک و بزرگ حساس باشد (به‌طور پیش فرضپیش‌فرض حساس نیست) را اعمال می‌کند. حداکثر طول نام پرونده استاندارد نیست و ممکن است به اندازهٔ واحد کد وابسته باشد. اگرچه این یک مسئلهٔ جدی است، در اکثر موارد یک مسئلهٔ محدود است. در لینوکس به این معناست که نام پرونده برای باز کردن آن کافی نیست: علاوه برعلاوه‌بر آن، نمایش دقیق بایتی نام پرونده روی دستگاه حافظه نیاز است. این با تعدادی فراخوانی‌های هنجار سازیهنجارسازی مکارانه در سطح نرم افزارنرم‌افزار قابل حل است.<ref>{{cite web|url=http://nedbatchelder.com/blog/201106/filenames_with_accents.html |title=Filenames with accents |publisher=Ned Batchelder |date= |accessdate=September 17, 2013}}</ref>
این مسئله از هم ارزیهم‌ارزی یونی‌کد را «برخورد با نام نرمال» می‌نامند. یک راه حل ''آگاهی از ترکیب غیرغیرنرمال نرمال یونی کدیونی‌کد'' است که در تخریب و سرقت از جوامع فنی استفاده می‌شود.<ref>{{cite web|url=http://wiki.apache.org/subversion/NonNormalizingUnicodeCompositionAwareness |title=NonNormalizingUnicodeCompositionAwareness - Subversion Wiki |publisher=Wiki.apache.org |date=January 21, 2013 |accessdate=September 17, 2013}}</ref> این راه حل مسیرهای داخل حافظه را هنجارسازی نمی‌کند. مسیرها تنها برای مقایسه هنجارسازی می‌شوند. با این حال، بعضی جوامع این راهبرد را انحصاری کردند، به‌طوری‌که استفاده از آن در سایر جوامع ممنوع باشد.
=== چشم اندازهاچشم‌اندازها ===
برای محدود کردنمحدودکردن مسائل قابلیت همکاری بعضی اندیشه‌ها که توسط Sun شرح داده شده عبارتند از:
* استفاده از یک رمزگذاری یونی‌کد (مانند [[جدول تخصیص فایل]]_۸)
* انجام تبدیلات شفاف کد روی نام پرونده‌ها
* ذخیرهٔ نام پرونده‌های هنجارسازی نشدههنجارسازی‌نشده
* بررسی برای هم ارزیهم‌ارزی استاندارد میان نام پرونده‌ها، برای جلوگیری از دو نام پروندهٔ هم ارزهم‌ارز استاندارد در یک فهرست یکسان
این توجهات یک محدودیت را ایجاد می‌کند که اجازهٔ تغییر به یک رمز گذاریرمزگذاری متفاوت با [[جدول تخصیص فایل]]_۸ در آینده را نمی‌دهد. ▼Those considerations create a limitation not allowing a switch to a future encoding different from UTF-8
▲این توجهات یک محدودیت را ایجاد می‌کند که اجازهٔ تغییر به یک رمز گذاری متفاوت با [[جدول تخصیص فایل]]_۸ در آینده را نمی‌دهد.
== یکتایی ==
| 