اصول نام‌گذاری فایل‌ها؛ الگوی شناسه، تاریخ، نسخه و وضعیت سند

نام فایل باید بدون بازکردن آن، حداقل هویت، موضوع، تاریخ یا دوره و نسخه را روشن کند؛ اما نباید به یک جمله طولانی تبدیل شود. قرارداد خوب در جست‌وجو، مرتب‌سازی و انتقال بین سیستم‌ها پایدار است و «final-final2» را از فرایند حذف می‌کند.

در این راهنما یک الگوی قابل اجرا، قواعد تاریخ و نسخه، روش تغییر نام دسته‌ای و کنترل کیفیت ارائه می‌شود. پیش از اجرای انبوه، روی کپی آزمایش کنید و نگاشت نام قدیم به جدید را نگه دارید.

اصول نام‌گذاری فایل‌ها؛ اجزا همیشه در جای ثابت

برای اسناد کاری این قرارداد نقطه شروع خوبی است:

[شناسه]_[موضوع]_[تاریخ-یا-دوره]_[وضعیت]_[نسخه].[پسوند]

نمونه‌ها:

PRJ042_contract_2026-10-30_draft_v01.docx
PRJ042_contract_2026-11-02_approved_v02.pdf
FIN1405_payroll_1405-07_approved_v03.xlsx
MKT017_campaign-report_2026-Q4_approved_v01.pdf

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

هر جزء چه قاعده‌ای دارد؟

شناسه

شناسه به پروژه، مشتری یا پرونده وصل می‌شود و برخلاف نام مشتری با تغییر برند عوض نمی‌شود. از شناسه یکتا و کوتاه مانند PRJ042 استفاده کنید. اطلاعات حساس مثل کد ملی را داخل نام فایل نگذارید؛ نام فایل ممکن است در Log، لینک یا ایمیل دیده شود.

موضوع

دو تا چهار واژه ثابت و قابل فهم بنویسید: meeting-minutes، invoice یا security-policy. فرهنگ واژگان کوچک تیم بسازید تا یک مفهوم با contract، agreement و deal پراکنده نشود.

تاریخ یا دوره

برای مرتب‌شدن زمانی، قالب سال-ماه-روز را از بزرگ به کوچک بنویسید: YYYY-MM-DD. برای گزارش ماهانه YYYY-MM و برای فصل YYYY-Qn کافی است. مشخص کنید تاریخ مربوط به رویداد، ایجاد یا تأیید است؛ این سه را مخلوط نکنید.

اگر سازمان تقویم شمسی دارد، پیشوند یا سیاست سیستم را روشن کنید. ترکیب 1405-07-08 و 2026-09-30 بدون نشانه تقویم ابهام می‌سازد. در Metadata می‌توانید تاریخ میلادی ماشین‌خوان و تاریخ شمسی نمایش را هم‌زمان نگه دارید.

وضعیت

فهرست محدود داشته باشید:

وضعیت واقعی باید در سیستم کنترل سند نیز ثبت شود؛ تغییر دستی نام فایل نباید به فرد اختیار تأیید بدهد.

نسخه

از صفر ابتدایی استفاده کنید تا مرتب‌سازی رشته‌ای درست بماند: v01، v02، … v10. نام‌هایی مانند final، last و new نسبی‌اند و با تغییر بعدی معنا از دست می‌دهند. برای چرخه کامل Draft تا Approved، Workflow کنترل نسخه اسناد را اجرا کنید.

فاصله، خط تیره، زیرخط و حروف فارسی

راهنمای NARA برای پایداری بین سیستم‌ها استفاده از حروف و اعداد و خط تیره/زیرخط به‌جای Space و Symbolهای مشکل‌ساز را توصیه می‌کند. برای بیشترین سازگاری با URL، Script و سیستم قدیمی، نام لاتین lowercase با خط تیره داخل عبارت و زیرخط بین اجزا انتخاب محافظه‌کارانه‌ای است:

PRJ042_user-research_2026-10-30_approved_v02.pdf

نام فارسی در سیستم‌های مدرن معمولاً قابل استفاده است، ولی پیش از اجبار سازمانی، Sync، ZIP، ایمیل، Backup و سامانه مقصد را آزمایش کنید. اگر فارسی انتخاب می‌کنید، نرمال‌سازی حروف «ی/ک»، نیم‌فاصله و اعداد را یکسان کنید.

از این نویسه‌ها دوری کنید، چون در سیستم‌عامل، URL یا Script معنای خاص دارند:

\ / : * ? " < > | # % & { } $ ! @ + ` =

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

قبل:

قرارداد جدید.docx
قرارداد جدید اصلاح شد.docx
قرارداد نهایی.pdf
قرارداد نهایی واقعی.pdf

بعد:

CLI083_service-contract_2026-10-20_draft_v01.docx
CLI083_service-contract_2026-10-23_review_v02.docx
CLI083_service-contract_2026-10-30_approved_v03.pdf

تفاوت فقط زیبایی نیست. اکنون می‌دانیم همه فایل‌ها به CLI083 مربوط‌اند، تاریخ هر Snapshot چیست، کدام فایل تأیید شده و ترتیب نسخه چیست.

طراحی قرارداد در شش گام

1. نمونه واقعی جمع کنید: ۳۰ تا ۵۰ نام فعلی و خطاهای جست‌وجو را ببینید.
2. حداقل اجزا را انتخاب کنید: هر جزء باید یک تصمیم واقعی را آسان کند.
3. واژه‌نامه بسازید: کد واحد، نوع سند و وضعیت مجاز.
4. ۱۰ سناریو را آزمایش کنید: فایل تکراری، نسخه دهم، نام بلند، ZIP و انتقال بین Windows/Linux.
5. قواعد را با مثال منتشر کنید: الگوی درست/غلط و مالک پرسش مشخص باشد.
6. Pilot و اصلاح کنید: ابتدا یک پوشه، سپس Migration دسته‌ای.

قرارداد نام باید با SOP فرایند فایل و Metadata سیستم هماهنگ باشد. اگر نام باید ۱۲ جزء حمل کند، احتمالاً بخشی از داده جای مناسبی در Tag یا فیلد اختصاصی دارد. در گنجینه نوتوا نیز عنوان خوانا را کنار پوشه و اطلاعات فایل نگه دارید؛ نام فیزیکی را حامل تمام Metadata نکنید.

تغییر نام دسته‌ای بدون شکستن مسیرها

پیش از Rename انبوه:

• Backup یا Snapshot معتبر بگیرید؛
• لینک، Shortcut، Embed و نرم‌افزارهای وابسته را فهرست کنید؛
• CSV نگاشت old_path,new_path بسازید؛
• Collision و طول کامل Path را بررسی کنید؛
• روی یک کپی کوچک Dry run بگیرید؛
• نتیجه را با شمارش، Hash یا حداقل نمونه‌برداری کنترل کنید؛
• مسیر Rollback را قبل از Apply آماده کنید.

نمونه نگاشت:

old_path,new_path
قرارداد نهایی واقعی.pdf,CLI083_service-contract_2026-10-30_approved_v03.pdf
گزارش مهر.xlsx,FIN1405_monthly-report_1405-07_approved_v01.xlsx

روی فضای مشترک فعال، Rename بدون هماهنگی می‌تواند لینک‌ها یا Sync کاربران را بشکند. زمان تغییر، مالک و پنجره توقف ویرایش تعیین کنید.

نام فایل چه چیزی را نباید حمل کند؟

• رمز، Token یا کلید دسترسی؛
• کد ملی، شماره موبایل یا داده پزشکی؛
• نظر شخصی درباره مشتری یا کارمند؛
• نام کامل همه بازبین‌ها؛
• وضعیت‌هایی که سیستم باید با Permission کنترل کند؛
• اطلاعاتی که مرتب تغییر می‌کنند و باعث Rename دائمی می‌شوند.

Metadata، کنترل دسترسی و Audit جایگزین نام نیستند. نام فایل فقط لایه شناسایی و مرتب‌سازی است.

خطاهای رایج

• چسباندن تاریخ به شکل 08111405 و ایجاد ابهام؛
• استفاده هم‌زمان از _، Space و - بدون قاعده؛
• نسخه‌های v1، v2، v10 و مرتب‌شدن نادرست؛
• نگه‌داشتن «final» در کنار وضعیت و نسخه؛
• تغییر قرارداد بدون Migration یا تاریخ اجرا؛
• نام طولانی که همراه پوشه‌ها از حد Path عبور می‌کند؛
• اعتماد به نام برای اثبات تأیید سند.

چک‌لیست قرارداد نهایی

• ترتیب اجزا ثابت و مستند است.
• شناسه یکتا و بدون داده حساس است.
• تاریخ قالب و معنای مشخص دارد.
• واژه‌های موضوع و وضعیت محدودند.
• نسخه با Zero padding مرتب می‌شود.
• نویسه‌ها در سیستم‌های مقصد آزموده شده‌اند.
• طول کل Path کنترل شده است.
• نگاشت Migration و Rollback وجود دارد.
• Owner قرارداد و تاریخ بازبینی تعیین شده است.

جمع‌بندی

قرارداد نام‌گذاری خوب کوتاه، ثابت و قابل آزمایش است: شناسه، موضوع، تاریخ یا دوره، وضعیت و نسخه در جای مشخص. این قرارداد جست‌وجو و انتقال را بهتر می‌کند، اما جای Workflow تأیید یا Version history را نمی‌گیرد. ابتدا روی نمونه‌های واقعی طراحی کنید، با داده کپی Pilot بگیرید و سپس با نگاشت قابل بازگشت، نام‌های موجود را مهاجرت دهید.