نام پرونده (رایانه): تفاوت میان نسخهها
محتوای حذفشده محتوای افزودهشده
Sillverfox (بحث | مشارکتها) خنثیسازی ویرایش 27709553 از 5.236.161.246 (بحث) برچسب: خنثیسازی |
بدون خلاصۀ ویرایش |
||
خط ۱۶:
یک نام پرونده، بهطور معمول از اجزای زیر تشکیل میگردد:
* '''میزبان''' (یا '''گره''' یا '''کارگزار (سرور)''') - دستگاه شبکهای که پروندهها را در بر میگیرد.
* '''دستگاه''' (یا '''درایو''') - دستگاه یا درایو
* شاخه (Directory) یا مسیر (Patch) - (مانند: \TEMP, [USR.LIB.SRC], etc.)
* نام پرونده
* [[پسوند نام فایل]] (مانند: txt
* نسخه (Version)
ترکیب و قالب یک فایل معتبر مانند مؤلفههای لازم برای شناسایی فایل، در سیستم عاملهای مختلف متفاوتند.
مباحث پیرامون نام پرونده به دلیل فقدان استانداردسازی این واژه پیچیده هستند. نام پرونده گاهی برای نام کامل مانند نام ویندوز مثل c:\directory\myfile.txt به کار میرود. گاهی برای اشاره به اجزا استفاده میشود؛ در این مثال myfile.txt. بعضاً
== تاریخچه ==
خط ۳۳:
در گذشته، تنها نویسهها (کاراکترها) ی [[حرفی عددی]] در نام پرونده مجاز بودند اما با گذشت زمان تعداد کاراکترهای مجاز افزایش یافت؛ که این باعث ایجاد مشکلات همسازی در زمان انتقال پروندهها از یک فایل سیستم به دیگری شد.<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 به نام [[جدول تخصیص فایل]] دروینوز۹۵ و
در سال ۱۹۸۵، RFC959 تعریف رسمی زیر را برای نام مسیر(path name) ارائه کرد:رشتهای از
[http://www.ietf.org/rfc/rfc959.txt IETF.org] {{IETF RFC|959}}, File Transfer Protocol (FTP)</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>
خط ۵۹:
بعضی فایل سیستمها طول نام پرونده را محدود میکنند. در بعضی موارد این طولها در نام کامل پرونده اعمال میشوند مانند ۴۴ کاراکتر در 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) بسیاری از نرم افزارهای کاربردی ویندوز ۲۶۰ است،
== افزونه ها(extensions) نام پرونده ==
بسیاری از فایل سیستمها، مانند سیستمهای [[جدول تخصیص فایل]]، [[ان تی اف اس]] و [[OpenVMS|vms]] به یک [[پسوند نام پرونده|افزونهٔ نام پرونده]] اجازه میدهند نام پرونده را به دو بخش تقسیم کند: یک ''نام اصلی'' یا ''ریشه'' و یک ''افزونه'' یا ''پسوند'' که بعضی از نرم افزارهای کاربردی برای تشخیص [[قالب پرونده]] از آن استفاده میکنند. افزونهٔ نام فایل از یک یا چند کاراکتر تشکیل میشود که پیروی آخرین بخش نام پرونده میآیند. پروندههای دارای خروجی چندگانه توسط نرم افزارهای کاربردی که از نام اصلی یکسان و افزونههای متفاوت استفاده میکنند ایجاد میشوند. برای مثال، ممکن است یک
== قابلیتهای همکاری رمزگذاری ==
برای نام پروندهها یک رمزگذاری استاندارد عمومی وجود ندارد.
=== قابلیت همکاری نشانهٔ رمزگذاری ===
در گذشته، نام پروندهها
یک نام پرونده داخل یک کشور ممکن است با استفاده از رشتههای بایتی متفاوتی در سامانههای متمایز ذخیره شده باشد، مثلاً یکی با استفاده از رمزگذاری Japanese Shift یا JIS و دیگری از رمزگذاری Japanese EUC. تبدیل ممکن نبوده زیرا بیشتر سامانهها شرحی از رمزگذاری که برای یک نام پرونده استفاده شده را به عنوان قسمتی از اطلاعات فایل توسعه یافته نمایش نمیدادند.
یک راه حل پذیرش
اما در Mac OS کلاسیک رمزگذاری نام پروندهها همراه خصوصیات نام پرونده ذخیره میشد.
خط ۸۱:
استاندارد یونی کد مسئلهٔ تشخیص رمزگذاری را برطرف کرد.
با این حال، بعضی مسائل قابلیت همکاری محدود از قبیل هنجارسازی یا
این مسئله از هم ارزی
=== چشم اندازها ===
برای محدود کردن مسائل قابلیت همکاری بعضی اندیشهها که توسط Sun شرح داده شده عبارتند از:
* استفاده از یک رمزگذاری
* انجام تبدیلات شفاف کد روی نام پروندهها
* ذخیرهٔ نام پروندههای هنجارسازی نشده
خط ۹۷:
نام پروندهها داخل یک فهرست باید یکتا باشند. از آن جا که ترکیب مربوط به نام پرونده برای فهرستها نیز اعمال میشود، امکان ایجاد یک فایل و ورودیهای فهرست با نام یکسان وجود ندارد. البته فایلهای متعدد در فهرستهای مختلف میتوانند نام یکسانی داشته باشند.
رویکرد یکتایی میتواند حساسیت نسبت به حروف کوچک و بزرگ و شکل استانداردسازی
== حفاظت از بزرگی یا کوچکی حروف ==
بعضی فایل سیستمها، مانند [[جدول تخصیص فایل]]، نام پروندهها را بدون توجه به کوچک یا بزرگ بودن حروف آنها با حروف بزرگ ذخیره میکنند. برای مثال، اگر پروندهای با نام
بعضی فایل سیستمها نام پروندهها را به همان شکلی که ایجاد شدند ذخیره میکنند؛ به این فایل سیستمها '''نگهدارندهٔ حروف کوچک و بزرگ (case-retentive)''' یا '''
Unix و سامانههای فرعی آن از شروع اصلیش محافظ حروف کوچک و بزرگ بودند. اما، همه انواع فایل سیستمهای Unix حساس به حروف کوچک و بزرگ نیستند؛ بهطور پیش فرض، HFS+ در macOS نسبت به حروف کوچک و بزرگ حساس است، و کارگزاران SMB([[بلوک پیام سرور]])رفتارهای غیر حساس به حروف کوچک و بزرگ ارائه میدهند (حتی زمانی که فایل سیستم اصلی به حروف کوچک و بزرگ حساس باشد، مانند [[سامبا (نرمافزار)|سامبا]] در بیشتر سامانههای شبیه به Unix) و فایل سیستم کاربر SMB رفتار غیرحساس نسبت به حروف کوچک و بزرگ ارائه میدهد. حساسیت یا عدم حساسیت فایل سیستم به حروف کوچک و بزرگ یک چالش قابل توجه برای نرم افزار است مانند سامبا و [[واین (لایه سازگاری)|واین]]، که باید بهطور کارآمد همکاری کند هم با سامانههایی که با پروندههای با حروف بزرگ و پروندههای با حروف کوچک متفاوت رفتار میکنند و هم سامانههایی که با آنها یکسان برخورد میکنند.<ref>{{cite web |url=http://wiki.winehq.org/CaseInsensitiveFilenames |title=CaseInsensitiveFilenames - The Official Wine Wiki |publisher=Wiki.winehq.org |date=November 8, 2009 |accessdate=August 20, 2010 |archiveurl=https://web.archive.org/web/20100818055054/http://wiki.winehq.org/CaseInsensitiveFilenames |archivedate=۱۸ اوت ۲۰۱۰ |dead-url=yes }}</ref>
|