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

بدون خلاصۀ ویرایش
(اصلاح نویسه، اصلاح فاصلهٔ مجازی، اصلاح ارقام)
بدون خلاصۀ ویرایش
یک مسئلهٔ مهم در رابطه با فایل سیستم‌هایی که اطلاعات را در فهرست‌های تودرتو ذخیره می‌کنند این است که شاید امکان ایجاد پرونده‌ای که اسم کامل آن از محدودیت‌های پیاده سازی تجاوز کند وجود داشته باشد، زیرا ممکن است بررسی طول به جای نام کامل برای بخش‌های مجزای نام به تنهایی انجام شود.حداکثر محدودهٔ (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 کلاسیک رمزگذاری نام پرونده ها همراه خصوصیات نام پرونده ذخیره می شد.
===قابلیت همکاری یونی کد===
استاندارد یونی کد مسئله ی تشخیص رمزگذاری را برطرف کرد.
 
با این حال، بعضی مسائل قابلیت همکاری محدود از قبیل هنجارسازی یا 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> این راه حل مسیرهای داخل حافظه را هنجارسازی نمی کند. مسیرها تنها برای مقایسه هنجارسازی می شوند. با این حال، بعضی جوامع این راهبرد را انحصاری کردند، به طوری که استفاده از آن در سایر جوامع ممنوع باشد.
== جستارهای وابسته ==
* [[سیستم پرونده]]
۲۱

ویرایش