نام پرونده (رایانه)

تاریخچه

در حدود سال ۱۹۶۲سیستم اشتراک زمانی سازگارمفهوم پرونده (پروندهٔ بدون کاغذ) را معرفی کرد.
تقریبا در همین زمان نقطه (برای توقف کامل یا کوتاه) به عنوان جداکنندهٔ افزونهٔ نام فایل به وجود آمد و افزونه به سه حرف محدود شد.
در گذشته، تنها نویسه‌ها (کاراکترها) ی حرفی عددی در نام پرونده مجاز بودند اما با گذشت زمان تعداد کاراکترهای مجاز افزایش یافت؛ که این باعث ایجاد مشکلات همسازی در زمان انتقال پرونده‌ها از یک فایل سیستم به دیگری شد.
در حدود سال ۱۹۹۵، یکی از افزونه‌های فایل سیستم FAT به نام جدول تخصیص فایل دروینوز۹۵ و ویندوزNT3.5 معرفی شد. در این افزونه علاوه بر نام‌های کلاسیک "۸٫۳" نام پرونده‌های طولانی یونی کد نیز مجاز بود.
در سال ۱۹۸۵، RFC959 تعریف رسمی زیر را برای نام مسیر(path name) ارائه کرد:رشته‌ای از کاراکترهاکه باید توسط کاربر برای شناسایی فایل وارد فایل سیستم شود.

ارجاعات:مطلق در مقایسه با نسبی

یک ارجاع مطلق تمام سطوح فهرست را شامل می‌شود. در بعضی سیستم‌ها، اگر ارجاع یک نام پرونده شامل مسیر کامل فهرست نباشد به‌طور پیش فرض فهرست جاری در نظر گرفته می‌شود. این یک ارجاع نسبی است. یکی از مزایای استفاده از ارجاع نسبی در فایل‌های پیکربندی برنامه یا اسناد این است که نمونه‌های مختلفی از سند یا برنامه می‌توانند در پرونده‌های مختلف استفاده شوند.
بنابراین یک ارجاع نسبی یا مطلق مرکب از دنباله‌ای از نام پرونده هاست.

تعداد نام‌های هر فایل

فایل سیستم‌های شبیه به Unix به یک فایل اجازه می‌دهند بیش از یک نام داشته باشد؛ نام‌ها در فایل سیستم‌های به سبک Unix قدیمی پیوندهایی سخت به آی‌نود یا معادل فایل هستند. ویندوز از پیوندهای سخت فایل سیستم‌های ان‌تی‌اف‌اس پشتیبانی می‌کند، و برای ساخت آن‌ها فرمان fsutil را در ویندوز XP، و mklink را در نسخه‌های بعدی ارائه می‌دهد. پیوندهای سخت با کلیدهای میانبر ویندوز، یا پیوند نمادین متفاوتند. معرفی LFNها با جدول تخصیص فایل اسم‌های مستعار نام پرونده را مجاز کردند. برای مثال، 
longfi~1. ???
 با حداکثر هشت به علاوهٔ سه کاراکتر یک اسم مستعار برای 
"long file name. ???"
 است. این نام مستعار جهت مطابقت با محدوده‌های ۸٫۳ برای برنامه‌های قدیمی تر است.
این ویژگی توسط الگوریتم فرمان move که ابتدا یک نام پروندهٔ ثانویه ایجاد می‌کند سپس تنها نام پروندهٔ اولیه را حذف می‌کند، استفاده می‌شد.
طراحی سایر فایل سیستم‌ها به گونه ایست که تنها یک نام پرونده را در هر پرونده مقرر می‌کند. این طراحی تضمین می‌کند که تغییرات فایل یک نام پرونده، فایل نام پروندهٔ دیگری را تغییر ندهد.

محدودیت‌های طول

بعضی فایل سیستم‌ها طول نام پرونده را محدود می‌کنند. در بعضی موارد این طول‌ها در نام کامل پرونده اعمال می‌شوند مانند ۴۴ کاراکتر در IBM S/370. در سایر موارد، ممکن است محدودیت‌های طول در بخش‌های خاصی از نام پرونده، از قبیل نام فایل در فهرست یا نام فهرست اعمال شوند. برای مثال: ۹ کاراکتر یا بایت (مانند جدول تخصیص فایل ۸ بیتی در Standalone Disk BASIC)، ۱۱ کاراکتر یا بایت (مانند جدول تخصیص فایل۱۲، جدول تخصیص فایل۱۶، جدول تخصیص فایل۳۲ در DOS)، ۱۴ کاراکتر یا بایت (مانند Unix اولیه)، ۲۱ کاراکتر یا بایت(Human68K)، ۳۱، ۳۰ کاراکتر یا بایت (مانند Apple DOS ورژن ۳٫۳ و۳٫۲)، ۱۵ کاراکتر یا بایت (مانند Apple ProDOS)، ۴۴کاراکتر یا بایت (مانند IBM S/370)، یا۲۵۵ کاراکتر یا بایت (مانند Berkeley Unix اولیه). محدودیت‌های طول عموماً نتیجهٔ تخصیص فضای معینی در فایل سیستم برای ذخیرهٔ مؤلفه‌های نام است، به همین دلیل محدودیت‌های بیشتر همانند اختصاص دادن فضای بیشتر نیازمند یک تغییر ناسازگارند.
یک مسئلهٔ مهم در رابطه با فایل سیستم‌هایی که اطلاعات را در فهرست‌های تودرتو ذخیره می‌کنند این است که شاید امکان ایجاد پرونده‌ای که اسم کامل آن از محدودیت‌های پیاده‌سازی تجاوز کند وجود داشته باشد، زیرا ممکن است بررسی طول به جای نام کامل برای بخش‌های مجزای نام به تنهایی انجام شود. حداکثر محدودهٔ (MAX_PATH) بسیاری از نرم افزارهای کاربردی ویندوز ۲۶۰ است، درحالی که نام پرونده‌های ویندوز به راحتی می‌توانند از این محدوده تجاوز کنند.

افزونه ها(extensions) نام پرونده

بسیاری از فایل سیستم‌ها، مانند سیستم‌های جدول تخصیص فایل، ان تی اف اس و vms به یک افزونهٔ نام پرونده اجازه می‌دهند نام پرونده را به دو بخش تقسیم کند: یک نام اصلی یا ریشه و یک افزونه یا پسوند که بعضی از نرم افزارهای کاربردی برای تشخیص قالب پرونده از آن استفاده می‌کنند. افزونهٔ نام فایل از یک یا چند کاراکتر تشکیل می‌شود که پیروی آخرین بخش نام پرونده می‌آیند. پرونده‌های دارای خروجی چندگانه توسط نرم افزارهای کاربردی که از نام اصلی یکسان و افزونه‌های متفاوت استفاده می‌کنند ایجاد می‌شوند. برای مثال، ممکن است یک کامپایلراز افزونه‌های FOR برای پروندهٔ ورودی منبع (برای کد Fortran), OBJ برای خروجی شیء و LST برای فهرست‌نویسی استفاده کند. با اینکه تعدادی افزونهٔ متداول وجود دارد اما این افزونه‌ها قراردادی هستند و ممکن است یک نرم افزار کاربردی دیگر از REL و RPT استفاده کند. معمولاً پرونده‌ها درفایل سیستم‌هایی که افزونه‌ها را جدا نمی‌کنند، افزونهٔ طولانی تری دارند مانند html.

قابلیت‌های همکاری رمزگذاری

برای نام پرونده‌ها یک رمزگذاری استاندارد عمومی وجود ندارد.
چراکه نام پرونده‌ها باید میان نرم افزارها مبادله شوتد(انتقال فایل شبکه، ذخیرهٔ فایل سیستم، نرم افزار پشتیبانی و هماهنگ سازی پرونده، مدیریت پیکربندی، فشرده سازی و بایگانی داده و…)، این بسیار مهم است که اطلاعات نام پرونده میان دو نرم افزار کاربردی از دست نرود. این مسئله موجب پذیرش گستردهٔ یونی کد به عنوان استانداردی برای رمزگذاری پرونده‌ها شد، گرچه برخی نرم افزارهای قدیمی ممکن است یونی کد را متوجه نشوند.

قابلیت همکاری نشانهٔ رمزگذاری

در گذشته، نام پرونده‌ها درهر کاراکتری را تاجایی که برای فایل سیستم ایمن بود در نام پرونده‌های خود مجاز می‌دانستند. با اینکه این روش استفاده از هرگونه رمزگذاری را مجاز می‌داند، و به همین دلیل امکان نمایش هر متن محلی را در هر سامانهٔ محلی فراهم می‌کند، منجر به بسیاری از قابلیت‌های همکاری می‌شود.
یک نام پرونده داخل یک کشور ممکن است با استفاده از رشته‌های بایتی متفاوتی در سامانه‌های متمایز ذخیره شده باشد، مثلاً یکی با استفاده از رمزگذاری Japanese Shift یا JIS و دیگری از رمزگذاری Japanese EUC. تبدیل ممکن نبوده زیرا بیشتر سامانه‌ها شرحی از رمزگذاری که برای یک نام پرونده استفاده شده را به عنوان قسمتی از اطلاعات فایل توسعه یافته نمایش نمی‌دادند.
یک راه حل پذیرش یونی کد برای رمزگذاری نام پرونده‌ها بود.
اما در Mac OS کلاسیک رمزگذاری نام پرونده‌ها همراه خصوصیات نام پرونده ذخیره می‌شد.

قابلیت همکاری یونی کد

استاندارد یونی کد مسئلهٔ تشخیص رمزگذاری را برطرف کرد.
با این حال، بعضی مسائل قابلیت همکاری محدود از قبیل هنجارسازی یا normalazation (هم ارزی)، یا نسخهٔ در حال استفادهٔ یونی کد باقی ماند. برای نمونه، UDF به یونی کد ۲٫۰ محدود شد؛ Mac OS هنجارسازی ینی کد NFD که به‌طور اختیاری می‌تواند به حروف کوچک و بزرگ حساس باشد (به‌طور پیش فرض حساس نیست) را اعمال می‌کند. حداکثر طول نام پرونده استاندارد نیست و ممکن است به اندازهٔ واحد کد وابسته باشد. اگرچه این یک مسئلهٔ جدی است، در اکثر موارد یک مسئلهٔ محدود است. در لینوکس به این معناست که نام پرونده برای باز کردن آن کافی نیست: علاوه بر آن، نمایش دقیق بایتی نام پرونده روی دستگاه حافظه نیاز است. این با تعدادی فراخوانی‌های هنجار سازی مکارانه در سطح نرم افزار قابل حل است.
این مسئله از هم ارزی یونی کد را «برخورد با نام نرمال» می‌نامند. یک راه حل آگاهی از ترکیب غیر نرمال یونی کد است که در تخریب و سرقت از جوامع فنی استفاده می‌شود. این راه حل مسیرهای داخل حافظه را هنجارسازی نمی‌کند. مسیرها تنها برای مقایسه هنجارسازی می‌شوند. با این حال، بعضی جوامع این راهبرد را انحصاری کردند، به‌طوری‌که استفاده از آن در سایر جوامع ممنوع باشد.

یکتایی

نام پرونده‌ها داخل یک فهرست باید یکتا باشند. از آن جا که ترکیب مربوط به نام پرونده برای فهرست‌ها نیز اعمال می‌شود، امکان ایجاد یک فایل و ورودی‌های فهرست با نام یکسان وجود ندارد. البته فایل‌های متعدد در فهرست‌های مختلف می‌توانند نام یکسانی داشته باشند.
رویکرد یکتایی می‌تواند حساسیت نسبت به حروف کوچک و بزرگ و شکل استانداردسازی یونی کد را تغییر دهد مانند NFC و NFD. یعنی دو پروندهٔ مجزا می‌توانند با متن نام پروندهٔ یکسان و پیاده‌سازی بایتی متفاوت از آن نام پرونده ایجاد شوند.

حفاظت از بزرگی یا کوچکی حروف

بعضی فایل سیستم‌ها، مانند جدول تخصیص فایل، نام پرونده‌ها را بدون توجه به کوچک یا بزرگ بودن حروف آن‌ها با حروف بزرگ ذخیره می‌کنند. برای مثال، اگر پرونده‌ای با نام "MyName.Txt" یا "myname.txt" ایجاد شده باشد با نام پروندهٔ "MYNAME.TXT" ذخیره خواهد شد. هر تغییری در حروف کوچک و بزرگ می‌تواند برای ارجاع به یک پروندهٔ یکسان استفاده شود. این نوع فایل سیستم‌ها غیر حساس به حروف کوچک و بزرگ (case-insensitive) نامیده می‌شوند و محافظ کوچکی و بزرگی حروف(case-preserving) نیستند. بعضی فایل سیستم‌ها اجازه نمی‌دهند در نام پرونده‌ها فقط از حروف کوچک استفاده شود.
بعضی فایل سیستم‌ها نام پرونده‌ها را به همان شکلی که ایجاد شدند ذخیره می‌کنند؛ به این فایل سیستم‌ها نگهدارندهٔ حروف کوچک و بزرگ (case-retentive) یا محافط حروف کوچک و بزرگ(case-preserving) می‌گویند. چنین فایل سیستمی می‌تواند نسبت به حروف کوچک و بزرگ حساس یا غیر حساس باشد. اگر حساس باشد آنگاه "MyName.Txt" و "myname.txt" می‌توانند به دو فایل مختلف در یک فهرست یکسان اشاره کنند، و به هر پرونده باید دقیقا با همان ترکیبی از حروف کوچک و بزرگ که با آن نام‌گذاری شده ارجاع داده شود. از سوی دیگر در یک فایل سیستم غیر حساس به حروف کوچک و بزرگ فقط یکی از نام‌های "MyName.Txt" و "myname.txt" و "Myname.TXT" می‌توانند هم زمان در یک فهرست نام یک پرونده باشند، و به یک پرونده با یکی از این نام‌ها با هر ترکیبی از حروف کوچک و بزرگ می‌توان ارجاع داد.
Unix و سامانه‌های فرعی آن از شروع اصلیش محافظ حروف کوچک و بزرگ بودند. اما، همه انواع فایل سیستم‌های Unix حساس به حروف کوچک و بزرگ نیستند؛ به‌طور پیش فرض، HFS+ در macOS نسبت به حروف کوچک و بزرگ حساس است، و کارگزاران SMB(بلوک پیام سرور)رفتارهای غیر حساس به حروف کوچک و بزرگ ارائه می‌دهند (حتی زمانی که فایل سیستم اصلی به حروف کوچک و بزرگ حساس باشد، مانند سامبا در بیشتر سامانه‌های شبیه به Unix) و فایل سیستم کاربر SMB رفتار غیرحساس نسبت به حروف کوچک و بزرگ ارائه می‌دهد. حساسیت یا عدم حساسیت فایل سیستم به حروف کوچک و بزرگ یک چالش قابل توجه برای نرم افزار است مانند سامبا و واین، که باید به‌طور کارآمد همکاری کند هم با سامانه‌هایی که با پرونده‌های با حروف بزرگ و پرونده‌های با حروف کوچک متفاوت رفتار می‌کنند و هم سامانه‌هایی که با آن‌ها یکسان برخورد می‌کنند.