فرمت فایل

از ویکیپدیا، دانشنامه آزاد
پرش به ناوبری پرش به جستجو
فایل wav: 2.1 مگابایت
فایل ogg: 154 کیلوبایت.

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

برخی از فرمت‌های فایل برای انواع بسیار خاصی از داده‌ها طراحی شده‌اند: فایل‌های PNG ، برای مثال، تصاویر بیت‌مپ‌شده را با استفاده از فشرده‌سازی داده‌های بدون تلفات ذخیره می‌کنند. با این حال، فرمت‌های فایل دیگر برای ذخیره‌سازی چندین نوع مختلف داده طراحی شده‌اند: فرمت Ogg می‌تواند به عنوان محفظه‌ای برای انواع مختلف چندرسانه‌ای از جمله هر ترکیبی از صدا و تصویر ، با یا بدون متن (مانند زیرنویس )، و ابرداده عمل کند. . یک فایل متنی می تواند شامل هر جریانی از کاراکترها، از جمله کاراکترهای کنترلی احتمالی باشد، و در یکی از طرح های رمزگذاری کاراکترهای مختلف کدگذاری شده است . برخی از فرمت‌های فایل، مانند HTML ، گرافیک‌های برداری مقیاس‌پذیر ، و کد منبع نرم‌افزارهای رایانه‌ای ، فایل‌های متنی با نحو تعریف‌شده هستند که به آن‌ها امکان استفاده برای اهداف خاص را می‌دهند.

مشخصات

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

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

اختراعات

قانون ثبت اختراع ، به جای کپی رایت ، بیشتر برای محافظت از فرمت فایل استفاده می شود. اگرچه ثبت اختراع برای فرمت های فایل به طور مستقیم تحت قوانین ایالات متحده مجاز نیست، برخی از فرمت ها داده ها را با استفاده از الگوریتم های ثبت شده رمزگذاری می کنند . به عنوان مثال، استفاده از فشرده سازی با فرمت فایل GIF به استفاده از یک الگوریتم ثبت شده نیاز دارد، و اگرچه مالک پتنت در ابتدا حق اختراع خود را اجرا نکرد، اما بعداً شروع به جمع آوری هزینه های حق امتیاز کرد. این منجر به کاهش قابل توجهی در استفاده از GIF شده است و تا حدی مسئول توسعه قالب جایگزین PNG است. با این حال، پتنت GIF در اواسط سال 2003 در ایالات متحده و در اواسط سال 2004 در سراسر جهان منقضی شد.

شناسایی نوع فایل

سیستم عامل های مختلف به طور سنتی رویکردهای متفاوتی را برای تعیین فرمت یک فایل خاص اتخاذ کرده اند که هر رویکرد مزایا و معایب خاص خود را دارد. اکثر سیستم‌عامل‌های مدرن و برنامه‌های کاربردی فردی نیاز به استفاده از تمام روش‌های زیر برای خواندن فرمت‌های فایل «خارجی» دارند، اگر به طور کامل با آنها کار نمی‌کنند.

پسوند نام فایل

یکی از روش‌های رایج مورد استفاده در بسیاری از سیستم‌عامل‌ها، از جمله Windows ، macOS ، CP/M ، DOS ، VMS ، و VM/CMS ، تعیین فرمت یک فایل بر اساس انتهای نام آن، به‌ویژه حروف بعد از پایان نام است. عادت زنانه. این بخش از نام فایل به عنوان پسوند نام فایل شناخته می شود . برای مثال، اسناد HTML با نام هایی که به .html (یا .htm ) ختم می شوند و تصاویر GIF با .gif شناسایی می شوند. در سیستم فایل اصلی FAT ، نام فایل ها محدود به یک شناسه هشت نویسه و یک پسوند سه نویسه است که به نام فایل 8.3 معروف است. تعداد محدودی پسوند سه حرفی وجود دارد که می تواند باعث شود یک پسوند معین توسط بیش از یک برنامه استفاده شود. بسیاری از فرمت‌ها هنوز از پسوندهای سه کاراکتری استفاده می‌کنند، حتی اگر سیستم‌عامل‌های مدرن و برنامه‌های کاربردی دیگر این محدودیت را ندارند. از آنجایی که لیست استانداردی از برنامه‌های افزودنی وجود ندارد، بیش از یک فرمت می‌توانند از یک پسوند استفاده کنند که می‌تواند سیستم عامل و کاربران را سردرگم کند.

یکی از مصنوعات این رویکرد این است که سیستم را می توان به راحتی فریب داد تا یک فایل را به عنوان یک فرمت متفاوت به سادگی با تغییر نام آن در نظر بگیرد - برای مثال، یک فایل HTML می تواند به راحتی با تغییر نام از filename.html به filename به عنوان یک متن ساده در نظر گرفته شود . txt _ اگرچه این استراتژی برای کاربران متخصصی که به راحتی می‌توانستند این اطلاعات را بفهمند و دستکاری کنند مفید بود، اما اغلب برای کاربران کمتر فنی گیج‌کننده بود، زیرا می‌توانستند با تغییر نام نادرست فایلی را به‌طور تصادفی غیرقابل استفاده کنند (یا «از دست بدهند»).

این باعث شد که اکثر نسخه‌های Windows و Mac OS پسوند را هنگام فهرست کردن فایل‌ها پنهان کنند. این امر از تغییر تصادفی نوع فایل توسط کاربر جلوگیری می کند و به کاربران متخصص اجازه می دهد تا این ویژگی را خاموش کرده و پسوندها را نمایش دهند.

با این حال، پنهان کردن پسوند می تواند ظاهر دو یا چند نام فایل یکسان را در یک پوشه ایجاد کند. برای مثال، ممکن است لوگوی شرکت هم در قالب .eps (برای انتشار) و هم با فرمت png . (برای وب سایت ها) مورد نیاز باشد. با نمایان شدن پسوندها، اینها به عنوان نام فایل های منحصر به فرد ظاهر می شوند: " CompanyLogo.eps " و " CompanyLogo.png ". از سوی دیگر، مخفی کردن برنامه‌های افزودنی باعث می‌شود هر دو به عنوان " CompanyLogo " ظاهر شوند که می‌تواند منجر به سردرگمی شود.

پنهان کردن برنامه های افزودنی نیز می تواند خطر امنیتی ایجاد کند. [1] به عنوان مثال، یک کاربر مخرب می تواند یک برنامه اجرایی با نامی بی گناه مانند " Hiday photo.jpg.exe " ایجاد کند. " .exe " پنهان می شود و کاربر ناآگاه " Hiday photo.jpg " را می بیند که به نظر می رسد یک تصویر JPEG است و معمولاً نمی تواند به دستگاه آسیب برساند. با این حال، سیستم عامل همچنان " .exe " را می بیندبرنامه را گسترش داده و اجرا کنید، که پس از آن می‌تواند به رایانه آسیب برساند. همین امر در مورد فایل‌های تنها با یک پسوند صدق می‌کند: از آنجایی که به کاربر نشان داده نمی‌شود، بدون بررسی صریح نمی‌توان هیچ اطلاعاتی در مورد فایل دریافت کرد. برای فریب بیشتر کاربران، می توان یک نماد را در داخل برنامه ذخیره کرد، در این صورت تخصیص نماد برخی از سیستم عامل ها برای فایل اجرایی ( exe .) با نمادی که معمولاً برای نمایش تصاویر JPEG استفاده می شود، لغو می شود. برنامه شبیه به یک تصویر است.افزونه ها را نیز می توان جعل کرد: برخی از ویروس های ماکرو Microsoft Word یک فایل Word در قالب قالب ایجاد می کنند و آن را با یک .doc ذخیره می کنند.افزونه. از آنجایی که Word عموماً پسوندها را نادیده می گیرد و به فرمت فایل نگاه می کند، این فایل ها به عنوان الگو باز می شوند، اجرا می شوند و ویروس را پخش می کنند. [ نیازمند منبع ] این یک مشکل عملی برای سیستم‌های ویندوزی است که در آن پنهان کردن افزونه به طور پیش‌فرض روشن است.

فراداده داخلی

راه دوم برای شناسایی فرمت فایل استفاده از اطلاعات مربوط به فرمت ذخیره شده در خود فایل است، یا اطلاعاتی که برای این منظور هستند یا رشته های باینری که همیشه در مکان های خاصی در فایل های برخی از فرمت ها هستند. از آنجایی که ساده‌ترین مکان برای یافتن آنها در ابتدا است، معمولاً چنین ناحیه‌ای را هدر فایل زمانی که بیشتر از چند بایت باشد، یا اگر فقط چند بایت باشد یک عدد جادویی نامیده می‌شود.

سربرگ فایل

ابرداده های موجود در هدر فایل معمولاً در ابتدای فایل ذخیره می شوند، اما ممکن است در قسمت های دیگر نیز وجود داشته باشند، اغلب از جمله انتهای آن، بسته به فرمت فایل یا نوع داده های موجود. فایل‌های مبتنی بر کاراکتر (متن) معمولاً دارای هدرهای مبتنی بر کاراکتر هستند، در حالی که فرمت‌های باینری معمولاً دارای هدرهای باینری هستند، اگرچه این یک قانون نیست. هدرهای فایل مبتنی بر متن معمولاً فضای بیشتری را اشغال می کنند، اما از آنجایی که برای انسان قابل خواندن هستند، می توان آنها را به راحتی با استفاده از نرم افزارهای ساده مانند ویرایشگر متن یا ویرایشگر هگزادسیمال بررسی کرد.

علاوه بر شناسایی فرمت فایل، هدرهای فایل ممکن است حاوی ابرداده در مورد فایل و محتوای آن باشد. به عنوان مثال، اکثر فایل‌های تصویری اطلاعاتی در مورد فرمت تصویر، اندازه، وضوح و فضای رنگ ، و به‌صورت اختیاری اطلاعاتی را ذخیره می‌کنند، مانند اینکه چه کسی تصویر را ساخته است، چه زمانی و کجا ساخته شده است، از چه مدل دوربین و تنظیمات عکاسی استفاده شده است ( Exif )، و به زودی. چنین ابرداده ای ممکن است با خواندن یا تفسیر فایل توسط نرم افزار در طول فرآیند بارگذاری و پس از آن مورد استفاده قرار گیرد.

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

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

مثال پیچیده‌تری از هدرهای فایل، آنهایی هستند که برای فرمت‌های فایل Wrapper (یا Container) استفاده می‌شوند.

عدد جادویی

یکی از راه‌های ترکیب متادیتای نوع فایل، که اغلب با یونیکس و مشتقات آن مرتبط است، ذخیره کردن یک عدد جادویی در داخل خود فایل است. در ابتدا، این اصطلاح برای مجموعه خاصی از شناسه های 2 بایتی در ابتدای فایل ها استفاده می شد، اما از آنجایی که هر دنباله باینری را می توان به عنوان یک عدد در نظر گرفت، هر ویژگی فرمت فایل که به طور منحصر به فرد آن را متمایز می کند، می تواند برای شناسایی استفاده شود. به عنوان مثال، تصاویر GIF بسته به استانداردی که به آن پایبند هستند ، همیشه با نمایش ASCII از GIF87a یا GIF89a شروع می شوند. تشخیص بسیاری از انواع فایل ها، به خصوص فایل های متنی ساده، با این روش دشوارتر است. برای مثال، فایل های HTML ممکن است با رشته <html> شروع شوند(که به حروف کوچک و بزرگ حساس نیست)، یا یک تعریف نوع سند مناسب که با <!DOCTYPE HTML> شروع می شود ، یا، برای XHTML ، شناسه XML ، که با <?xml شروع می شود . فایل ها همچنین می توانند با نظرات HTML، متن تصادفی یا چندین خط خالی شروع شوند، اما همچنان HTML قابل استفاده باشند.

رویکرد عدد جادویی تضمین های بهتری را ارائه می دهد که قالب به درستی شناسایی می شود و اغلب می تواند اطلاعات دقیق تری را در مورد فایل تعیین کند. از آنجایی که تست‌های «اعداد جادویی» قابل اعتماد می‌توانند نسبتاً پیچیده باشند، و هر فایل باید به طور مؤثر در برابر هر احتمالی در پایگاه داده جادویی آزمایش شود، این رویکرد نسبتاً ناکارآمد است، به‌ویژه برای نمایش فهرست‌های بزرگ از فایل‌ها (در مقابل، نام فایل و ابرداده- روش های مبتنی بر نیاز به بررسی تنها یک قطعه داده، و تطبیق آن با یک شاخص مرتب شده). همچنین، داده‌ها باید از خود فایل خوانده شوند، در مقایسه با ابرداده‌های ذخیره‌شده در فهرست، تأخیر افزایش می‌یابد. در مواردی که انواع فایل‌ها به این شکل امکان شناسایی را ندارند، سیستم باید به ابرداده برگردد. با این حال این است که بهترین راه برای برنامه برای بررسی اینکه آیا فرمت فایلی که به او گفته شده است پردازش کند یا نه: در حالی که نام فایل یا ابرداده ممکن است مستقل از محتوای آن تغییر کند، رد شدن در تست عدد جادویی که به خوبی طراحی شده باشد نشانه کاملاً مطمئنی است. که فایل یا خراب است یا از نوع اشتباه است. از طرف دیگر، یک عدد جادویی معتبر تضمین نمی کند که فایل خراب نیست یا از نوع صحیح آن است.

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

سیستم عامل دیگری که از اعداد جادویی استفاده می کند، AmigaOS است ، که در آن اعداد جادویی "کوکی های جادویی" نامیده می شدند و به عنوان یک سیستم استاندارد برای شناسایی فایل های اجرایی در قالب فایل اجرایی Hunk و همچنین اجازه می دهد تا برنامه ها، ابزارها و ابزارهای منفرد به طور خودکار با فایل های داده ذخیره شده خود کار کنند، به کار گرفته شدند. ، یا هر نوع فایل دیگری هنگام ذخیره و بارگیری داده ها. سپس این سیستم با سیستم تشخیص نوع داده استاندارد آمیگا تقویت شد. روش دیگر روش FourCC بود که از OSType در مکینتاش سرچشمه گرفت و بعداً توسط Interchange File Format (IFF) و مشتقات اقتباس شد.

فراداده خارجی

آخرین راه برای ذخیره فرمت یک فایل، ذخیره صریح اطلاعات مربوط به فرمت در سیستم فایل است، نه در خود فایل.

این رویکرد، ابرداده را از داده‌های اصلی و نام جدا نگه می‌دارد، اما نسبت به پسوندهای نام فایل یا "اعداد جادویی" کمتر قابل حمل است، زیرا فرمت باید از سیستم فایل به سیستم فایل تبدیل شود. در حالی که این امر تا حدی در مورد پسوندهای نام فایل صادق است - به عنوان مثال، برای سازگاری با محدودیت سه کاراکتری MS-DOS - اکثر اشکال ذخیره سازی تعریف تقریباً معادلی از داده ها و نام یک فایل دارند، اما ممکن است نمایش متفاوت یا بدون نمایش داشته باشند. از فراداده های بیشتر

توجه داشته باشید که فایل های فشرده یا فایل های آرشیو مشکل مدیریت ابرداده را حل می کند. یک برنامه کاربردی چندین فایل را همراه با ابرداده در مورد هر فایل و پوشه ها/دایرکتوری هایی که از آنها آمده اند در یک فایل جدید جمع آوری می کند (به عنوان مثال یک فایل فشرده با پسوند .zip ). فایل جدید همچنین فشرده و احتمالاً رمزگذاری شده است، اما اکنون به صورت یک فایل در سراسر سیستم عامل ها توسط انتقال FTP قابل انتقال است یا از طریق ایمیل به عنوان پیوست ارسال می شود. در مقصد، تنها فایل دریافتی باید توسط یک ابزار سازگار از حالت فشرده خارج شود تا مفید باشد. مشکلات مدیریت ابرداده به این روش با استفاده از فایل های فشرده یا فایل های آرشیو حل می شود.

کدهای نوع سیستم عامل مک

سیستم فایل سلسله مراتبی Mac OS کدهایی را برای ایجاد کننده و نوع به عنوان بخشی از ورودی فهرست برای هر فایل ذخیره می کند. به این کدها OSType می گویند. این کدها می توانند هر دنباله 4 بایتی باشند، اما اغلب به گونه ای انتخاب می شدند که نمایش ASCII دنباله ای از کاراکترهای معنی دار، مانند مخفف نام برنامه یا حروف اول توسعه دهنده را تشکیل می داد. به عنوان مثال، یک فایل "پشته" HyperCard یک سازنده WILD ( از نام قبلی Hypercard، "WildCard") و یک نوع STAK دارد . ویرایشگر متن BBEdit یک کد سازنده داردR*chبا اشاره به برنامه نویس اصلی آن، Rich Siegel . کد نوع فرمت فایل را مشخص می‌کند، در حالی که کد سازنده برنامه پیش‌فرض را مشخص می‌کند که با دوبار کلیک کردن توسط کاربر، آن را باز کند. به عنوان مثال، کاربر می تواند چندین فایل متنی داشته باشد که همگی با نوع کد TEXT هستند، اما به دلیل داشتن کدهای سازنده متفاوت، هر کدام در یک برنامه متفاوت باز می شوند. این ویژگی به این منظور در نظر گرفته شده بود که، برای مثال، فایل‌های متن ساده قابل خواندن توسط انسان می‌توانند در یک ویرایشگر متن عمومی باز شوند، در حالی که فایل‌های برنامه‌نویسی یا کد HTML در یک ویرایشگر تخصصی یا IDE باز می‌شوند . با این حال، این ویژگی اغلب منبع سردرگمی کاربران بود، زیرا برنامه‌ای که با دوبار کلیک کردن روی فایل‌ها راه‌اندازی می‌شد اغلب غیرقابل پیش‌بینی بود. سیستم عامل RISCاز یک سیستم مشابه، متشکل از یک عدد 12 بیتی استفاده می‌کند که می‌توان آن را در جدولی از توضیحات جستجو کرد - به عنوان مثال، عدد هگزادسیمال به PoScriptFF5 "نام مستعار" داده می‌شود ، که یک فایل PostScript را نشان می‌دهد.

شناسه‌های نوع یکنواخت Mac OS X (UTIs)

شناسه نوع یکنواخت (UTI) روشی است که در macOS برای شناسایی منحصربه‌فرد کلاس‌های «تایپ‌شده» موجودیت، مانند فرمت‌های فایل استفاده می‌شود. این توسط اپل به عنوان جایگزینی برای OSType (کدهای نوع و سازنده) توسعه داده شد.

UTI یک رشته پایه اصلی است که از یک رشته DNS معکوس استفاده می کند. برخی از انواع معمول و استاندارد از دامنه ای به نام public استفاده می کنند (مثلا public.png برای یک تصویر گرافیکی شبکه قابل حمل )، در حالی که دامنه های دیگر را می توان برای انواع شخص ثالث استفاده کرد (مثلا com.adobe.pdf برای قالب سند قابل حمل ). UTI ها را می توان در یک ساختار سلسله مراتبی تعریف کرد که به عنوان سلسله مراتب انطباق شناخته می شود. بنابراین public.png با supertype public.image مطابقت دارد که خود با supertype public.data مطابقت دارد. UTI می تواند در چند سلسله مراتب وجود داشته باشد که انعطاف پذیری زیادی را فراهم می کند.

علاوه بر فرمت‌های فایل، UTI می‌تواند برای موجودیت‌های دیگری که می‌توانند در macOS وجود داشته باشند، از جمله:

  • داده های مقوا
  • پوشه ها (دایرکتوری ها)
  • انواع قابل ترجمه (که توسط مدیر ترجمه مدیریت می شود)
  • بسته
  • چارچوب ها
  • جریان داده ها
  • نام مستعار و پیوندهای نمادین

ویژگی های توسعه یافته OS/2

سیستم های فایل HPFS ، FAT12 و FAT16 (اما نه FAT32) امکان ذخیره "ویژگی های توسعه یافته" را با فایل ها فراهم می کنند. این شامل مجموعه دلخواه از سه قلوها با یک نام، یک نوع کدگذاری شده برای مقدار و یک مقدار است که در آن نام ها منحصر به فرد هستند و مقادیر می توانند تا 64 کیلوبایت طول داشته باشند. معانی استاندارد شده ای برای انواع و نام های خاص (تحت OS/2 ) وجود دارد. یکی از این موارد این است که ویژگی ".TYPE" توسعه یافته برای تعیین نوع فایل استفاده می شود. مقدار آن شامل فهرستی از یک یا چند نوع فایل مرتبط با فایل است که هر کدام یک رشته هستند، مانند «متن ساده» یا «سند HTML». بنابراین یک فایل ممکن است انواع مختلفی داشته باشد.

سیستم فایل NTFS همچنین امکان ذخیره ویژگی های توسعه یافته OS/2 را به عنوان یکی از فورک های فایل فراهم می کند ، اما این ویژگی صرفاً برای پشتیبانی از زیرسیستم OS/2 (در XP وجود ندارد) وجود دارد، بنابراین زیرسیستم Win32 با این اطلاعات به عنوان یک اطلاعات غیر شفاف برخورد می کند. بلوک داده و از آن استفاده نمی کند. درعوض، برای ذخیره اطلاعات متا در فرمت های خاص Win32 به دیگر فورک های فایل متکی است. ویژگی های توسعه یافته OS/2 هنوز می توانند توسط برنامه های Win32 خوانده و نوشته شوند، اما داده ها باید به طور کامل توسط برنامه ها تجزیه شوند.

ویژگی های توسعه یافته POSIX

در سیستم‌های یونیکس و شبه یونیکس، سیستم‌های فایل ext2 ، ext3 ، ext4 ، ReiserFS نسخه 3، XFS ، JFS ، FFS و HFS+ امکان ذخیره ویژگی‌های توسعه‌یافته با فایل‌ها را فراهم می‌کنند. اینها شامل یک لیست دلخواه از رشته‌های "name=value" است که در آن نام‌ها منحصربه‌فرد هستند و می‌توان به یک مقدار از طریق نام مرتبط آن دسترسی پیدا کرد.

شناسه‌های منحصربه‌فرد PRONOM (PUID)

شناسه منحصر به فرد دائمی PRONOM (PUID) یک طرح توسعه پذیر از شناسه های ثابت، منحصر به فرد و بدون ابهام برای فرمت های فایل است که توسط آرشیو ملی بریتانیا به عنوان بخشی از سرویس ثبت فنی PRONOM آن توسعه یافته است. PUID ها را می توان با استفاده از فضای نام info:pronom/ به عنوان شناسه منبع یکنواخت بیان کرد . اگرچه هنوز به طور گسترده در خارج از دولت بریتانیا و برخی از برنامه های حفظ دیجیتال استفاده نشده است، طرح PUID نسبت به اکثر طرح های جایگزین، جزئیات بیشتری را ارائه می دهد.

انواع MIME

انواع MIME به طور گسترده در بسیاری از برنامه های مرتبط با اینترنت و به طور فزاینده ای در جاهای دیگر استفاده می شود، اگرچه استفاده از آنها برای اطلاعات نوع روی دیسک نادر است. اینها شامل یک سیستم استاندارد از شناسه‌ها (که توسط IANA مدیریت می‌شود ) متشکل از یک نوع و یک نوع فرعی است که با یک اسلش از هم جدا شده‌اند - به عنوان مثال، متن/html یا تصویر/گیف . اینها در ابتدا به عنوان راهی برای شناسایی نوع فایل پیوست شده به یک ایمیل ، مستقل از سیستم عامل منبع و هدف در نظر گرفته شده بودند. انواع MIME فایل‌ها را در BeOS ، AmigaOS 4.0 و MorphOS شناسایی می‌کنند، و همچنین امضاهای منحصر به فرد برنامه را برای راه اندازی برنامه ذخیره کنید. در AmigaOS و MorphOS سیستم نوع Mime به موازات سیستم Datatype خاص Amiga کار می کند.

مشکلاتی در مورد انواع MIME وجود دارد. چندین سازمان و افراد انواع MIME خود را بدون ثبت مناسب در IANA ایجاد کرده اند که در برخی موارد استفاده از این استاندارد را ناخوشایند می کند.

شناسه‌های قالب فایل (FFID)

شناسه فرمت فایل روش دیگری است که به طور گسترده مورد استفاده قرار نمی گیرد برای شناسایی فرمت های فایل بر اساس مبدا و دسته بندی فایل آنها. برای مجموعه نرم افزار Description Explorer ایجاد شده است. از چندین رقم فرم تشکیل شده NNNNNNNNN-XX-YYYYYYYاست. قسمت اول مبدأ/نگهدار سازمان را نشان می دهد (این عدد نشان دهنده مقداری در پایگاه داده شرکت/سازمان استاندارد است)، 2 رقم زیر نوع فایل را به صورت هگزادسیمال دسته بندی می کند. قسمت آخر از پسوند نام فایل معمولی فایل یا شماره استاندارد بین المللی فایل تشکیل شده است که با صفر در سمت چپ قرار داده شده است. به عنوان مثال، مشخصات فایل PNG دارای FFID 000000001-31-0015948جایی 31است که یک فایل تصویری را نشان می دهد، 0015948عدد استاندارد است و 000000001نشان دهندهسازمان بین المللی استاندارد (ISO).

شناسایی فرمت مبتنی بر محتوای فایل

روش دیگر اما کمتر محبوب برای شناسایی فرمت فایل، بررسی محتویات فایل برای الگوهای قابل تشخیص در بین انواع فایل است. محتویات یک فایل دنباله ای از بایت است و یک بایت دارای 256 جایگشت منحصر به فرد (0-255) است. بنابراین، شمارش وقوع الگوهای بایت که اغلب به عنوان توزیع فرکانس بایت نامیده می شود، الگوهای قابل تشخیصی را برای شناسایی انواع فایل ارائه می دهد. بسیاری از طرح‌های شناسایی نوع فایل مبتنی بر محتوا وجود دارد که از توزیع فرکانس بایت برای ساخت مدل‌های نماینده برای نوع فایل استفاده می‌کنند و از هر تکنیک آماری و داده کاوی برای شناسایی انواع فایل استفاده می‌کنند [2]

ساختار فایل

چندین روش برای ساختار دادن به داده ها در یک فایل وجود دارد. معمول ترین آنها در زیر توضیح داده شده است.

فرمت های بدون ساختار (حافظه خام)

فرمت‌های فایل قبلی از فرمت‌های داده خام استفاده می‌کردند که شامل ریختن مستقیم تصاویر حافظه یک یا چند ساختار در فایل بود.

این چند اشکال دارد. مگر اینکه تصاویر حافظه دارای فضاهای ذخیره شده برای پسوندهای بعدی باشند، گسترش و بهبود این نوع فایل ساختاریافته بسیار دشوار است. همچنین فایل هایی را ایجاد می کند که ممکن است مختص یک پلتفرم یا زبان برنامه نویسی باشد (به عنوان مثال ساختاری که دارای رشته پاسکال است در C به عنوان آن شناخته نمی شود ). از سوی دیگر، توسعه ابزار برای خواندن و نوشتن این نوع فایل ها بسیار ساده است.

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

قالب‌های مبتنی بر تکه

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

در طول دهه 1970، بسیاری از برنامه ها از فرمت هایی از این نوع عمومی استفاده می کردند. به عنوان مثال، پردازشگرهای کلمه مانند troff ، Script و Scribe و فایل های صادراتی پایگاه داده مانند CSV . Electronic Arts and Commodore - آمیگا نیز در سال 1985 از این نوع فرمت فایل با فرمت فایل IFF (فرمت فایل تبادلی) خود استفاده کرد.

یک ظرف گاهی اوقات "تکه" نامیده می شود ، اگرچه "تکه" ممکن است به این معنی باشد که هر قطعه کوچک است، و/یا اینکه تکه ها حاوی تکه های دیگر نیستند. بسیاری از قالب ها آن الزامات را تحمیل نمی کنند.

اطلاعاتی که یک "تکه" خاص را مشخص می کند ممکن است چیزهای مختلفی نامیده شود، اغلب اصطلاحاتی از جمله "نام فیلد"، "شناسه"، "برچسب" یا "برچسب". شناسه ها اغلب برای انسان قابل خواندن هستند و بخش هایی از داده ها را طبقه بندی می کنند: به عنوان مثال، به عنوان "نام خانوادگی"، "آدرس"، "مستطیل"، "نام قلم"، و غیره. یک کلید پایگاه داده یا شماره سریال (اگرچه یک شناسه ممکن است داده های مرتبط خود را به عنوان یک کلید شناسایی کند).

با این نوع ساختار فایل، ابزارهایی که شناسه های تکه خاصی را نمی شناسند، به سادگی از مواردی که نمی فهمند می گذرند. بسته به معنای واقعی داده های نادیده گرفته شده، این ممکن است مفید باشد یا نباشد ( CSS به صراحت چنین رفتاری را تعریف می کند).

این مفهوم بارها و بارها توسط RIFF (معادل IFF مایکروسافت-IBM)، ذخیره‌سازی PNG، JPEG، جریان‌ها و فایل‌های رمزگذاری‌شده DER ( قوانین رمزگذاری متمایز ) استفاده شده است (که در ابتدا در CCITT X.409:1984 شرح داده شده‌اند و بنابراین به قبل از IFF هستند. و فرمت تبادل داده های ساختاریافته (SDXF) .

در واقع، هر قالب داده ای باید به نحوی اهمیت اجزای سازنده خود را شناسایی کند، و نشانگرهای مرزی تعبیه شده راهی واضح برای انجام این کار هستند:

  • هدرهای MIME این کار را با یک برچسب جدا شده از دو نقطه در ابتدای هر خط منطقی انجام می دهند. سرصفحه‌های MIME نمی‌توانند حاوی سرصفحه‌های MIME دیگری باشند، اگرچه محتوای داده‌های برخی از سرصفحه‌ها دارای بخش‌های فرعی است که می‌توانند توسط قراردادهای دیگر استخراج شوند.
  • CSV و فایل‌های مشابه اغلب این کار را با استفاده از رکوردهای هدر با نام فیلدها و با کاما برای علامت‌گذاری مرزهای فیلد انجام می‌دهند. مانند MIME، CSV هیچ پیش بینی ای برای ساختارهایی با بیش از یک سطح ندارد.
  • XML و خویشاوندان آن را می‌توان نوعی قالب مبتنی بر تکه در نظر گرفت، زیرا عناصر داده با نشانه‌گذاری مشابه شناسه‌های تکه شناسایی می‌شوند. با این حال، دارای مزایای رسمی مانند طرحواره ها و اعتبار سنجی ، و همچنین توانایی نمایش ساختارهای پیچیده تر مانند درختان ، DAG ها و نمودارها است. اگر XML یک فرمت "تکه ای" در نظر گرفته شود، SGML و سلف آن IBM GML از اولین نمونه های این فرمت ها هستند.
  • JSON بدون طرحواره ها، ارجاعات متقابل یا تعریفی برای معنای نام های مکرر فیلد شبیه XML است و اغلب برای برنامه نویسان مناسب است.
  • YAML شبیه JSON است، اما از تورفتگی برای جدا کردن تکه‌های داده استفاده می‌کند و هدف آن این است که بیشتر از JSON یا XML برای انسان قابل خواندن باشد.
  • بافرهای پروتکل به نوبه خود شبیه JSON هستند، به ویژه نشانگرهای مرزی را در داده ها با شماره های فیلد جایگزین می کنند، که با مکانیزم خارجی به نام ها/از نام ها نگاشت می شوند.

فرمت های مبتنی بر فهرست

این یک فرمت قابل توسعه دیگر است که بسیار شبیه یک سیستم فایل است ( اسناد OLE سیستم های فایل واقعی هستند)، که در آن فایل از "ورودی های دایرکتوری" تشکیل شده است که حاوی مکان داده ها در خود فایل و همچنین امضاهای آن است (و در موارد خاص موارد نوع آن). نمونه های خوبی از این نوع ساختارهای فایل عبارتند از: تصاویر دیسک ، اسناد OLE TIFF ، کتابخانه ها . ODT و DOCX که مبتنی بر PKZIP هستند تکه تکه می‌شوند و همچنین یک دایرکتوری دارند.

همچنین ببینید

منابع

  1. PC World (23 دسامبر 2003). "نکات ویندوز: برای دلایل امنیتی، دانستن پسوندهای فایل شما مفید است" . بایگانی شده از نسخه اصلی در 23 آوریل 2008 . بازیابی شده در 20 ژوئن 2008 .
  2. «شناسایی فرمت فایل» . بایگانی شده از نسخه اصلی در 2009-08-14 . بازیابی شده در 2009-07-21 .

پیوندهای خارجی