نگهداری فایل تحقیق · تمرین قابل تکرار

این همان فایل اصلی است؟ بررسی تغییر فایل با هش SHA-256

یک فایل را برای همکارتان می‌فرستید و چند روز بعد نسخه‌ای با نام مرتب‌تر پس می‌گیرید. ظاهرش همان است، اما قبل از استناد به آن می‌خواهید بدانید: فقط اسم عوض شده یا خود فایل هم تغییر کرده؟ برای پاسخ به همین سؤال، هش فایل به کار می‌آید.

SHA-256 از بایت‌های فایل یک مقدار محاسبه می‌کند که به آن هش می‌گوییم. اگر مقدار اولیه را درست نگه داشته باشید، می‌توانید نتیجه محاسبه بعدی را با آن مقایسه کنید. این بررسی درباره ثابت ماندن بایت‌هاست؛ درست بودن حرف‌های داخل سند را ثابت نمی‌کند.

یک سند نگهداری‌شده و دو نسخه کاری با الگوهای مقایسه یکسان و متفاوت
الگوهای تصویر فقط نمایش مفهومی مقایسه‌اند؛ هش واقعی یا گواهی اصالت سند نیستند.

پیش از تبدیل یا ویرایش، نسخه اصلی را کنار بگذارید

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

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

نام‌های متفاوت به شما کمک می‌کنند نقش فایل‌ها را گم نکنید. برای نمونه، notice-original.pdf نسخه اولیه است، notice-ocr.txt متن استخراج‌شده و notice-redacted.pdf نسخه‌ای است که بخشی از اطلاعاتش حذف شده. طبیعی است که این سه فایل هش متفاوت داشته باشند.

دستور ساده برای محاسبه روی رایانه خودتان

در PowerShell می‌توانید از دستور رسمی Get-FileHash استفاده کنید. در نمونه زیر، الگوریتم را صریح تعیین کرده‌ایم و LiteralPath باعث می‌شود مسیر، بدون تفسیر نویسه‌های wildcard خوانده شود:

Get-FileHash -LiteralPath 'C:\Research\notice-original.pdf' -Algorithm SHA256

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

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

آزمایش چهار فایل؛ نتیجه‌ای که می‌توانید تکرار کنید

در ۱۲ اکتبر ۲۰۲۶ چهار فایل کوچک UTF-8 بدون نشان BOM ساختیم. هش هرکدام را هم با پایتون و هم با PowerShell محاسبه کردیم؛ دو روش برای هر فایل به نتیجه یکسان رسیدند. این فایل‌ها عمداً برای آموزش ساخته شده‌اند و نه مدرک بازیابی‌شده‌اند، نه آزمون عملکرد محصول اوسینت جت.

نسخه اولیه دو خط دارد: Harbour note و status=pending. در انتهای هر خط، نویسه پایان خط LF قرار دارد. یک کپی دقیق با اسم دیگر ساختیم؛ در نسخه سوم پایان خط‌ها را به CRLF تغییر دادیم و در چهارمی، با حفظ LF، واژه pending را به confirmed تبدیل کردیم.

نام فایلاندازه به بایتنتیجه نسبت به اصل
original.txt۲۸نسخه مبنا
renamed-copy.txt۲۸هش کامل یکسان بود.
windows-lines.txt۳۰هش عوض شد؛ فقط پایان خط‌ها متفاوت بود.
changed-status.txt۳۰هش عوض شد؛ متن وضعیت تغییر کرده بود.

هش کامل نسخه اصلی این بود:

541cf99519c85610355bdb7863b0192f688fefeab16afc645a4da3ec90a64004

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

from pathlib import Path
original = b"Harbour note\nstatus=pending\n"
files = {
    "original.txt": original,
    "renamed-copy.txt": original,
    "windows-lines.txt": b"Harbour note\r\nstatus=pending\r\n",
    "changed-status.txt": b"Harbour note\nstatus=confirmed\n",
}
for name, data in files.items():
    Path(name).write_bytes(data)

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

در مقابل، تغییر «در انتظار» به «تأییدشده» معنای متن را عوض کرده است. هش در هر دو حالت فقط اختلاف را نشان می‌دهد؛ از خود عدد نمی‌فهمید با تغییر ساده قالب روبه‌رو هستید یا ویرایش مهم محتوا. برای فهم علت باید نسخه‌ها را مقایسه کنید.

به‌جای یک عدد تنها، سابقه قابل بررسی نگه دارید

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

نمونه یادداشت: «هش نسخه تغییرنام‌یافته با هش نسخه اصلی نگهداری‌شده برابر بود. متن حاصل از OCR یک فایل مشتق‌شده است و هش خودش را دارد. این تطبیق، نویسنده سند یا صحت ادعاهای داخل آن را تأیید نمی‌کند.»

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

اگر هش‌ها فرق داشتند، از اینجا شروع کنید

  1. مطمئن شوید فایل و الگوریتم درست را انتخاب کرده‌اید.
  2. هر دو نسخه را حفظ کنید و مبنای قبلی را بازنویسی نکنید.
  3. سابقه تبدیل فرمت، حذف اطلاعات، ویرایش فراداده، تغییر کدگذاری یا پایان خط را بررسی کنید.
  4. محتوا را مقایسه کنید و فقط علتی را ثبت کنید که برایش شاهد دارید.

دانلود دوباره از همان URL هم لزوماً همان بایت‌ها را نمی‌دهد؛ ممکن است فایل به‌روز یا دوباره تولید شده باشد. اختلاف هش به‌تنهایی نشانه دست‌کاری بدخواهانه نیست. اگر نسخه اولیه یا هش معتبر آن را نگه نداشته‌اید، محاسبه امروز نمی‌تواند گذشته گم‌شده را بازسازی کند.

SHA-256 برای مقایسه عملی بایت‌ها طراحی شده و احتمال برخوردِ دو محتوای متفاوت در کاربرد معمول بسیار ناچیز است. بااین‌حال، تطبیق هش امضای دیجیتال، زمان‌سنج معتبر یا اثبات واقعیت بیرونی نیست. اعتبار منبع را باید جدا ارزیابی کنید.

این سابقه را به گزارش وصل کنید

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

منابع

رفتار دستور با مستندات Get-FileHash مایکروسافت تطبیق داده شد. آرشیو ملی آمریکا نیز در روش نگهداری فایل‌های ویدئویی از بررسی checksum پس از انتقال و در طول نگهداری استفاده می‌کند؛ اشاره به آن، به معنی انطباق این تمرین کوچک با استاندارد سازمانی یا حقوقی نیست.

انتشار: ۱۲ اکتبر ۲۰۲۶ · تحریریه اوسینت جت

پیشنهاد اصلاح · English version