نام پرونده (رایانه): تفاوت میان نسخه‌ها

اصلاح فاصلهٔ مجازی، اصلاح نویسه، اصلاح ارقام، اصلاح سجاوندی، اصلاح نویسه‌های عربی
بدون خلاصۀ ویرایش
(اصلاح فاصلهٔ مجازی، اصلاح نویسه، اصلاح ارقام، اصلاح سجاوندی، اصلاح نویسه‌های عربی)
 
یک نام پرونده، به طور معمول از اجزای زیر تشکیل می‌گردد:
* '''میزبان'''(یا '''گره''' یا '''کارگزار (سرور)''')-دستگاه شبکه‌ای که پرونده‌ها را در بر می‌گیرد.
* '''دستگاه'''(یا '''درایو''')-دستگاه یا درایو سخت افزاری
* شاخه (Directory) یا مسیر (Patch)- (مانند: \TEMP, [USR.LIB.SRC], etc.)
* نام پرونده
* [[پسوند نام فایل]] (مانند: txt, exe, com)
* نسخه (Version)-شمارهٔ تولید یا چاپ اصلاح شده
ترکیب و قالب یک فایل معتبر مانند مولفه‌های لازم برای شناسایی فایل، در سیستم عامل‌های مختلف متفاوتند.
 
مباحث پیرامون نام پرونده به دلیل فقدان استانداردسازی این واژه پیچیده هستند. نام پرونده گاهی برای نام کامل مانند نام ویندوز مثل c:\directory\myfile.txt به کار می‌رود. گاهی برای اشاره به اجزا استفاده می‌شود؛ در این مثال myfile.txt. بعضا ارجاعیست که یک افزونه را مشخص می‌کند، بنابر این در این حالت نام پروندهmyfile خواهد بود. چنین ابهاماتی متداول است و این مقاله تلاش نمی‌کند هیچ یک از معانی را تعریف کند،وکند، و فعلا ممکن است هریک از آن‌ها را استفاده کنیم. بعضی سامانه‌ها ممکن است نام گذاری استاندارد خود را پذیرفته باشند مانند "«نام مسیر"»(path name)، ولی همین اسامی نیز در سراسر سیستم استاندارد نیستند.
==تاریخچه==
در حدود سال ۱۹۶۲[[سیستم اشتراک زمانی سازگار]]مفهوم پرونده(پروندهٔ بدون کاغذ) را معرفی کرد.
 
== تاریخچه ==
تقریبا در همین زمان [[نقطه (نگارش)|نقطه]](برای توقف کامل یا کوتاه)به عنوان جداکنندهٔ افزونهٔ نام فایل به وجود آمد و افزونه به سه حرف محدود شد.<ref>{{cite web|author=Howard, Randall |url=http://randalljhoward.com/2008/12/31/who-invented-filenames-dot/ |title=General, History |publisher=Randalljhoward.com |date=December 31, 2008 |accessdate=September 17, 2013}}</ref>
در حدود سال ۱۹۶۲[[سیستم اشتراک زمانی سازگار]]مفهوم پرونده (پروندهٔ بدون کاغذ) را معرفی کرد.
 
تقریبا در همین زمان [[نقطه (نگارش)|نقطه]] (برای توقف کامل یا کوتاه) به عنوان جداکنندهٔ افزونهٔ نام فایل به وجود آمد و افزونه به سه حرف محدود شد.<ref>{{cite web|author=Howard, Randall |url=http://randalljhoward.com/2008/12/31/who-invented-filenames-dot/ |title=General, History |publisher=Randalljhoward.com |date=December 31, 2008 |accessdate=September 17, 2013}}</ref>
در گذشته، تنها نویسه ها(کاراکترها)ی [[حرفی عددی]] در نام پرونده مجاز بودند اما با گذشت زمان تعداد کاراکترهای مجاز افزایش یافت. که این باعث ایجاد مشکلات همسازی در زمان انتقال پرونده‌ها از یک فایل سیستم به دیگری شد.<ref name="solaris presentations IUC29-FileSystems">{{cite web|author=David Robinso|author2=Ienup Sung|author3=Nicolas Williams |date=March 2006 |url=http://developers.sun.com/global/products_platforms/solaris/reference/presentations/IUC29-FileSystems.pdf |title=Solaris presentations: File Systems, Unicode, and Normalization |location=San Francisco |publisher=Sun.com |deadurl=no |archiveurl=https://web.archive.org/web/20120704003732/http://developers.sun.com/global/products_platforms/solaris/reference/presentations/IUC29-FileSystems.pdf |archivedate=July 4, 2012 }}</ref>
 
در گذشته، تنها نویسه ها (کاراکترها) ی [[حرفی عددی]] در نام پرونده مجاز بودند اما با گذشت زمان تعداد کاراکترهای مجاز افزایش یافت.یافت؛ که این باعث ایجاد مشکلات همسازی در زمان انتقال پرونده‌ها از یک فایل سیستم به دیگری شد.<ref name="solaris presentations IUC29-FileSystems">{{cite web|author=David Robinso|author2=Ienup Sung|author3=Nicolas Williams |date=March 2006 |url=http://developers.sun.com/global/products_platforms/solaris/reference/presentations/IUC29-FileSystems.pdf |title=Solaris presentations: File Systems, Unicode, and Normalization |location=San Francisco |publisher=Sun.com |deadurl=no |archiveurl=https://web.archive.org/web/20120704003732/http://developers.sun.com/global/products_platforms/solaris/reference/presentations/IUC29-FileSystems.pdf |archivedate=July 4, 2012 }}</ref>
 
در حدود سال ۱۹۹۵، یکی از افزونه‌های فایل سیستم FAT به نام [[جدول تخصیص فایل]] دروینوز۹۵ و ویندوزNT3.5 معرفی شد. در این افزونه علاوه بر نام‌های کلاسیک "۸٫۳" نام پرونده‌های طولانی [[یونی کد]] نیز مجاز بود.
 
در سال ۱۹۸۵، RFC959 تعریف رسمی زیر را برای نام مسیر(path name) ارائه کرد:رشته‌ای از کاراکترهاکه باید توسط کاربر برای شناسایی فایل وارد فایل سیستم شود.<ref>{{IETF RFC|959}}
[http://www.ietf.org/rfc/rfc959.txt IETF.org] {{IETF RFC|959}}, File Transfer Protocol (FTP)</ref>
 
</ref>
=== مهاجرت به یونی کد ===
یک مسئله تغییر شیوهٔ نام گذاری به یونی کد بود. به این منطور شرکت‌ها ی نرم افزاری بسیاری، نرم افزارهایی برای مهاجرت نام پرونده‌ها به رمزگذاری یونی کد جدید فراهم کردند.
* Microsoft برای تمامی کاربران تکنولوژی vfat، نرم افزار migration transparent را ارئه داد
* Apple نرم افزارFile Name Encoding Repair Utility v1.0 را ارائه کرد<ref>{{cite web|url=http://support.apple.com/downloads/File_Name_Encoding_Repair_Utility |title=File Name Encoding Repair Utility v1.0 |publisher=Support.apple.com |date=June 1, 2006 |accessdate=September 17, 2013}}</ref>
* Linux community نرم افزار convmv را ارائه داد<ref>{{cite web|url=http://www.j3e.de/linux/convmv/man/ |title=convmv - converts filenames from one encoding to another |publisher=J3e.de |date= |accessdate=September 17, 2013}}</ref>
[[Mac OS X 10.3]] marked Apple's adoption of Unicode 3.2 character decomposition, superseding the Unicode 2.1 decomposition used previously. This change caused problems for developers writing software for Mac OS X.<ref>{{cite web|url=http://kerneltrap.org/mailarchive/git/2008/1/23/593749/thread |title=Re: git on MacOSX and files with decomposed utf-8 file names |publisher=KernelTrap |date=May 7, 2010 |accessdate=July 5, 2010 |deadurl=yes |archiveurl=https://web.archive.org/web/20110315014244/http://kerneltrap.org/mailarchive/git/2008/1/23/593749/thread |archivedate=March 15, 2011 }}</ref>
 
== ارجاعات:مطلق در مقایسه با نسبی ==
یک ارجاع مطلق تمام سطوح فهرست را شامل می‌شود. در بعضی سیستم‌ها ،سیستم‌ها، اگر ارجاع یک نام پرونده شامل مسیر کامل فهرست نباشد به طور پیش فرض فهرست جاری در نظر گرفته می‌شود. این یک ارجاع نسبی است. یکی از مزایای استفاده از ارجاع نسبی در فایل‌های پیکربندی برنامه یا اسناد این است که نمونه‌های مختلفی از سند یا برنامه می‌توانند در پرونده‌های مختلف استفاده شوند.
 
بنابراین یک ارجاع نسبی یا مطلق مرکب از دنباله‌ای از نام پرونده هاست.
 
== تعداد نام‌های هر فایل ==
فایل سیستم‌های شبیه به Unix به یک فایل اجازه می‌دهند بیش از یک نام داشته باشد؛ نام‌ها در فایل سیستم‌های به سبک Unix قدیمی پیوندهایی سخت به [[آی‌نود]] یا معادل فایل هستند. ویندوز از پیوندهای سخت فایل سیستم‌های [[ان‌تی‌اف‌اس]] پشتیبانی می‌کند، و برای ساخت آنها فرمان <code>fsutil</code> را در ویندوز XP، و <code>mklink</code> را در نسخه‌های بعدی ارائه می‌دهد..<ref>{{cite web|title=Fsutil command description page|publisher=Microsoft.com|accessdate=September 15, 2013|url=http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/fsutil.mspx?mfr=true}}</ref><ref>{{cite web|title=NTFS Hard Links, Directory Junctions, and Windows Shortcuts|url=http://www.flexhex.com/docs/articles/hard-links.phtml|work=Flex hex|publisher=Inv Softworks|accessdate=March 12, 2011}}</ref> پیوندهای سخت با کلیدهای میانبر ویندوز، یا [[پیوند نمادین]] متفاوتند. معرفی LFNها با [[جدول تخصیص فایل]] اسم‌های مستعار نام پرونده را مجاز کردند. برای مثال، {{چپ‌چین}}<tt>longfi~1. ???</tt>{{پایان چپ‌چین}} با حداکثر هشت به علاوهٔ سه کاراکتر یک اسم مستعار برای {{چپ‌چین}}"<tt>long file name. ???</tt>"{{پایان چپ‌چین}} است. این نام مستعار جهت مطابقت با محدوده‌های ۸٫۳ برای برنامه‌های قدیمی تر است.
 
این ویژگی توسط الگوریتم فرمان move که ابتدا یک نام پروندهٔ ثانویه ایجاد می‌کند سپس تنها نام پروندهٔ اولیه را حذف می‌کند، استفاده می‌شد.
 
طراحی سایر فایل سیستم‌ها به گونه ایست که تنها یک نام پرونده را در هر پرونده مقرر می‌کند. این طراحی تضمین می‌کند که تغییرات فایل یک نام پرونده، فایل نام پروندهٔ دیگری را تغییر ندهد.
==محدودیت‌های طول==
بعضی فایل سیستم‌ها طول نام پرونده را محدود می‌کنند. در بعضی موارد این طول‌ها در نام کامل پرونده اعمال می‌شوند مانند ۴۴ کاراکتر در IBM S/370.<ref name="44_char">{{cite web|title=ddname support with FTP, z/OS V1R11.0 Communications Server IP User's Guide and Commands z/OS V1R10.0-V1R11.0 SC31-8780-09 |publisher=IBM.com |url=http://publib.boulder.ibm.com/infocenter/zos/v1r11/index.jsp?topic=/com.ibm.zos.r11.halu001/dd_name_support.htm }}</ref>در سایر موارد، ممکن است محدودیت‌های طول در بخش‌های خاصی از نام پرونده، از قبیل نام فایل در فهرست یا نام فهرست اعمال شوند. برای مثال: ۹ کاراکتر یا بایت(مانند [[جدول تخصیص فایل]] ۸ بیتی در Standalone Disk BASIC)، ۱۱ کاراکتر یا بایت(مانند [[جدول تخصیص فایل]]۱۲، [[جدول تخصیص فایل]]۱۶، [[جدول تخصیص فایل]]۳۲ در DOS)، ۱۴ کاراکتر یا بایت(مانند Unix اولیه)،۲۱ کاراکتر یا بایت(Human68K)، ۳۱، ۳۰ کاراکتر یا بایت(مانند Apple DOS ورژن ۳٫۳ و۳٫۲)، ۱۵ کاراکتر یا بایت(مانند Apple ProDOS)، ۴۴کاراکتر یا بایت(مانند IBM S/370)، یا۲۵۵ کاراکتر یا بایت(مانند Berkeley Unix اولیه). محدودیت‌های طول عموما نتیجهٔ تخصیص فضای معینی در فایل سیستم برای ذخیرهٔ مولفه‌های نام است، به همین دلیل محدودیت‌های بیشتر همانند اختصاص دادن فضای بیشتر نیازمند یک تغییر ناسازگارند.
 
== محدودیت‌های طول ==
یک مسئلهٔ مهم در رابطه با فایل سیستم‌هایی که اطلاعات را در فهرست‌های تودرتو ذخیره می‌کنند این است که شاید امکان ایجاد پرونده‌ای که اسم کامل آن از محدودیت‌های پیاده سازی تجاوز کند وجود داشته باشد، زیرا ممکن است بررسی طول به جای نام کامل برای بخش‌های مجزای نام به تنهایی انجام شود.حداکثر محدودهٔ (MAX_PATH) بسیاری از نرم افزارهای کاربردی ویندوز ۲۶۰ است، درحالی که نام پرونده‌های ویندوز به راحتی می‌توانند از این محدوده تجاوز کنند.
بعضی فایل سیستم‌ها طول نام پرونده را محدود می‌کنند. در بعضی موارد این طول‌ها در نام کامل پرونده اعمال می‌شوند مانند ۴۴ کاراکتر در IBM S/370.<ref name="44_char">{{cite web|title=ddname support with FTP, z/OS V1R11.0 Communications Server IP User's Guide and Commands z/OS V1R10.0-V1R11.0 SC31-8780-09 |publisher=IBM.com |url=http://publib.boulder.ibm.com/infocenter/zos/v1r11/index.jsp?topic=/com.ibm.zos.r11.halu001/dd_name_support.htm }}</ref>در سایر موارد، ممکن است محدودیت‌های طول در بخش‌های خاصی از نام پرونده، از قبیل نام فایل در فهرست یا نام فهرست اعمال شوند. برای مثال: ۹ کاراکتر یا بایت (مانند [[جدول تخصیص فایل]] ۸ بیتی در Standalone Disk BASIC)، ۱۱ کاراکتر یا بایت (مانند [[جدول تخصیص فایل]]۱۲، [[جدول تخصیص فایل]]۱۶، [[جدول تخصیص فایل]]۳۲ در DOS)، ۱۴ کاراکتر یا بایت (مانند Unix اولیه)،۲۱، ۲۱ کاراکتر یا بایت(Human68K)، ۳۱، ۳۰ کاراکتر یا بایت (مانند Apple DOS ورژن ۳٫۳ و۳٫۲)، ۱۵ کاراکتر یا بایت (مانند Apple ProDOS)، ۴۴کاراکتر یا بایت (مانند IBM S/370)، یا۲۵۵ کاراکتر یا بایت (مانند Berkeley Unix اولیه). محدودیت‌های طول عموما نتیجهٔ تخصیص فضای معینی در فایل سیستم برای ذخیرهٔ مولفه‌های نام است، به همین دلیل محدودیت‌های بیشتر همانند اختصاص دادن فضای بیشتر نیازمند یک تغییر ناسازگارند.
==افزونه ها(extensions) نام پرونده==
 
بسیاری از فایل سیستم ها، مانند سیستم های [[جدول تخصیص فایل]]، [[ان تی اف اس]] و [[OpenVMS|vms]] به یک [[پسوند نام پرونده|افزونه ی نام پرونده]] اجازه می دهند نام پرونده را به دو بخش تقسیم کند: یک ''نام اصلی'' یا ''ریشه'' و یک ''افزونه'' یا ''پسوند'' که بعضی از نرم افزارهای کاربردی برای تشخیص [[قالب پرونده]] از آن استفاده می کنند. افزونه ی نام فایل از یک یا چند کاراکتر تشکیل می شود که پیروی آخرین بخش نام پرونده می آیند. پرونده های دارای خروجی چندگانه توسط نرم افزارهای کاربردی که از نام اصلی یکسان و افزونه های متفاوت استفاده می کنند ایجاد می شوند. برای مثال، ممکن است یک کامپایلراز افزونه های <code>FOR</code> برای پرونده ی ورودی منبع(برای کد Fortran)، <code>OBJ</code> برای خروجی شیء و <code>LST</code> برای فهرست نویسی استفاده کند. با اینکه تعدادی افزونه ی متداول وجود دارد اما این افزونه ها قراردادی هستند و ممکن است یک نرم افزار کاربردی دیگر از <code>REL</code> و <code>RPT</code> استفاده کند. معمولا پرونده ها درفایل سیستم هایی که افزونه ها را جدا نمی کنند، افزونه ی طولانی تری دارند مانند <code>html</code>.
یک مسئلهٔ مهم در رابطه با فایل سیستم‌هایی که اطلاعات را در فهرست‌های تودرتو ذخیره می‌کنند این است که شاید امکان ایجاد پرونده‌ای که اسم کامل آن از محدودیت‌های پیاده سازی تجاوز کند وجود داشته باشد، زیرا ممکن است بررسی طول به جای نام کامل برای بخش‌های مجزای نام به تنهایی انجام شود. حداکثر محدودهٔ (MAX_PATH) بسیاری از نرم افزارهای کاربردی ویندوز ۲۶۰ است، درحالی که نام پرونده‌های ویندوز به راحتی می‌توانند از این محدوده تجاوز کنند.
==قابلیت های همکاری رمزگذاری==
 
برای نام پرونده ها یک رمزگذاری استاندارد عمومی وجود ندارد.
== افزونه ها(extensions) نام پرونده ==
بسیاری از فایل سیستم ها،سیستم‌ها، مانند سیستم هایسیستم‌های [[جدول تخصیص فایل]]، [[ان تی اف اس]] و [[OpenVMS|vms]] به یک [[پسوند نام پرونده|افزونه یافزونهٔ نام پرونده]] اجازه می دهندمی‌دهند نام پرونده را به دو بخش تقسیم کند: یک ''نام اصلی'' یا ''ریشه'' و یک ''افزونه'' یا ''پسوند'' که بعضی از نرم افزارهای کاربردی برای تشخیص [[قالب پرونده]] از آن استفاده می کنندمی‌کنند. افزونه یافزونهٔ نام فایل از یک یا چند کاراکتر تشکیل می شودمی‌شود که پیروی آخرین بخش نام پرونده می آیندمی‌آیند. پرونده هایپرونده‌های دارای خروجی چندگانه توسط نرم افزارهای کاربردی که از نام اصلی یکسان و افزونه هایافزونه‌های متفاوت استفاده می کنندمی‌کنند ایجاد می شوندمی‌شوند. برای مثال، ممکن است یک کامپایلراز افزونه هایافزونه‌های <code>FOR</code> برای پرونده یپروندهٔ ورودی منبع (برای کد Fortran)،, <code>OBJ</code> برای خروجی شیء و <code>LST</code> برای فهرست نویسی استفاده کند. با اینکه تعدادی افزونه یافزونهٔ متداول وجود دارد اما این افزونه هاافزونه‌ها قراردادی هستند و ممکن است یک نرم افزار کاربردی دیگر از <code>REL</code> و <code>RPT</code> استفاده کند. معمولا پرونده هاپرونده‌ها درفایل سیستم هاییسیستم‌هایی که افزونه هاافزونه‌ها را جدا نمی کنند، افزونهنمی‌کنند، یافزونهٔ طولانی تری دارند مانند <code>html</code>.
 
== قابلیت‌های همکاری رمزگذاری ==
برای نام پرونده هاپرونده‌ها یک رمزگذاری استاندارد عمومی وجود ندارد.
 
چراکه نام پرونده هاپرونده‌ها باید میان نرم افزارها مبادله شوتد(انتقال فایل شبکه، ذخیره یذخیرهٔ فایل سیستم، نرم افزار پشتیبانی و هماهنگ سازی پرونده، مدیریت پیکربندی، فشرده سازی و بایگانی داده و...و…)، این بسیار مهم است که اطلاعات نام پرونده میان دو نرم افزار کاربردی از دست نرود. این مسئله موجب پذیرش گسترده یگستردهٔ یونی کد به عنوان استانداردی برای رمزگذاری ام پرونده هاپرونده‌ها شد، گرچه برخی نرم افزارهای قدیمی ممکن است یونی کد را متوجه نشوند.،نشوند؛ و به همین دلیل امکان نمایش هر متن محلی را در هر سامانه یسامانهٔ محلی فراهم می کندمی‌کند
 
=== قابلیت های همکاری نشانهٔ رمزگذاری ===
در گذشته، نام پرونده هاپرونده‌ها درهر کارکتری را تاجایی که برای فایل سیستم ایمن بود در نام پرونده هایپرونده‌های خود مجاز می دانستندمی‌دانستند. با اینکه این روش استفاده از هرگونه رمزگذاری را مجاز می داند،می‌داند، و به همین دلیل امکان نمایش هر متن محلی را در هر سامانه یسامانهٔ محلی فراهم می کند،می‌کند، منجر به بسیاری از قابلیت هایقابلیت‌های همکاری می شودمی‌شود.
 
یک نام پرونده داخل یک کشور ممکن است با استفاده از رشته هایرشته‌های بایتی متفاوتی در سامانه هایسامانه‌های متمایز ذخیره شده باشد،مثلاباشد، مثلا یکی با استفاده از رمزگذاری Japanese Shift یا JIS و دیگری از رمزگذاری Japanese EUC. تبدیل ممکن نبوده زیرا بیشتر سامانه هاسامانه‌ها شرحی از رمزگذاری که برای یک نام پرونده استفاده شده را به عنوان قسنتی از اطلاعات فایل توسعه یافته نمایش نمی دادندنمی‌دادند.
 
یک راه حل پذیرش یونی کد برای رمزگذاری نام پرونده هاپرونده‌ها بود.
 
اما در Mac OS کلاسیک رمزگذاری نام پرونده هاپرونده‌ها همراه خصوصیات نام پرونده ذخیره می شدمی‌شد.
چراکه نام پرونده ها باید میان نرم افزارها مبادله شوتد(انتقال فایل شبکه، ذخیره ی فایل سیستم، نرم افزار پشتیبانی و هماهنگ سازی پرونده، مدیریت پیکربندی، فشرده سازی و بایگانی داده و...)، این بسیار مهم است که اطلاعات نام پرونده میان دو نرم افزار کاربردی از دست نرود. این مسئله موجب پذیرش گسترده ی یونی کد به عنوان استانداردی برای رمزگذاری ام پرونده ها شد، گرچه برخی نرم افزارهای قدیمی ممکن است یونی کد را متوجه نشوند.، و به همین دلیل امکان نمایش هر متن محلی را در هر سامانه ی محلی فراهم می کند
===قابلیت همکاری نشانه ی رمزگذاری===
در گذشته، نام پرونده ها درهر کارکتری را تاجایی که برای فایل سیستم ایمن بود در نام پرونده های خود مجاز می دانستند. با اینکه این روش استفاده از هرگونه رمزگذاری را مجاز می داند، و به همین دلیل امکان نمایش هر متن محلی را در هر سامانه ی محلی فراهم می کند، منجر به بسیاری از قابلیت های همکاری می شود.
 
=== قابلیت همکاری نشانهیونی یکد رمزگذاری===
یک نام پرونده داخل یک کشور ممکن است با استفاده از رشته های بایتی متفاوتی در سامانه های متمایز ذخیره شده باشد،مثلا یکی با استفاده از رمزگذاری Japanese Shift یا JIS و دیگری از رمزگذاری Japanese EUC. تبدیل ممکن نبوده زیرا بیشتر سامانه ها شرحی از رمزگذاری که برای یک نام پرونده استفاده شده را به عنوان قسنتی از اطلاعات فایل توسعه یافته نمایش نمی دادند.
استاندارد یونی کد مسئله یمسئلهٔ تشخیص رمزگذاری را برطرف کرد.
 
با این حال، بعضی مسائل قابلیت همکاری محدود از قبیل هنجارسازی یا normalazation (هم ارزی)، یا نسخه ینسخهٔ درحال استفاده یاستفادهٔ یونی کد باقی ماند. برای نمونه، UDF به یونی کد 2.0۲٫۰ محدود شد؛ Mac OS هنجارسازی ینی کد 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> این راه حل مسیرهای داخل حافظه را هنجارسازی نمی کندنمی‌کند. مسیرها تنها برای مقایسه هنجارسازی می شوندمی‌شوند. با این حال، بعضی جوامع این راهبرد را انحصاری کردند، به طوری که استفاده از آن در سایر جوامع ممنوع باشد.
اما در Mac OS کلاسیک رمزگذاری نام پرونده ها همراه خصوصیات نام پرونده ذخیره می شد.
===قابلیت همکاری یونی کد===
استاندارد یونی کد مسئله ی تشخیص رمزگذاری را برطرف کرد.
 
=== چشم اندازها ===
با این حال، بعضی مسائل قابلیت همکاری محدود از قبیل هنجارسازی یا normalazation (هم ارزی)، یا نسخه ی درحال استفاده ی یونی کد باقی ماند. برای نمونه، UDF به یونی کد 2.0 محدود شد؛ Mac OS هنجارسازی ینی کد 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>
برای محدود کردن مسائل قابلیت همکاری بعضی اندیشه‌ها که توسط Sun شرح داده شده عبارتند از:
* استفاده از یک رمزگذاری یونی کد (مانند[[جدول تخصیص فایل]]_۸)
* انجام تبدیلات شفاف کد روی نام پرونده‌ها
* ذخیرهٔ نام پرونده‌های هنجارسازی نشده
* بررسی برای هم ارزی استاندارد میان نام پرونده‌ها، برای جلوگیری از دو نام پروندهٔ هم ارز استاندارد در یک فهرست یکسان
Those considerations create a limitation not allowing a switch to a future encoding different from UTF-8
این توجهات یک محدودیت را ایجاد می‌کند که اجازهٔ تغییر به یک رمز گذاری متفاوت با [[جدول تخصیص فایل]]_۸ در آینده را نمی‌دهد.
 
این مسئله از هم ارزی یونی کد را "برخورد با نام نرمال" می نامند. یک راه حل ''آگاهی از ترکیب غیر نرمال یونی کد'' است که در تخریب و سرقت از جوامع فنی استفاده می شود.<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> این راه حل مسیرهای داخل حافظه را هنجارسازی نمی کند. مسیرها تنها برای مقایسه هنجارسازی می شوند. با این حال، بعضی جوامع این راهبرد را انحصاری کردند، به طوری که استفاده از آن در سایر جوامع ممنوع باشد.
== جستارهای وابسته ==
* [[سیستم پرونده]]
۲۱

ویرایش