فایل ZIP بعد از آپلود با FTP خراب می‌شود؛ حالت Binary را درست تنظیم کنید

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

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

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

از فایل اصلی یک اثر انگشت SHA-256 بگیرید. در PowerShell ویندوز، مسیر نمونه را با مسیر واقعی جایگزین کنید:

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

روی macOS معمولاً shasum -a 256 sample.zip در دسترس است. یکسان بودن هش نسخه اصلی و نسخه بازگشتی نشانه بسیار قوی یکسان بودن محتوای آن‌هاست. متفاوت بودن هش فقط می‌گوید محتوا فرق دارد و به‌تنهایی علت را مشخص نمی‌کند.

در برنامه انتقال فایل، تنظیم سایت ذخیره‌شده را باز کنید. FTP ساده رمز و داده را بدون حفاظت کافی می‌فرستد؛ اگر سرویس شما پشتیبانی می‌کند، از SFTP یا FTPS با بررسی گواهی استفاده کنید. این دو یکسان نیستند: SFTP بر پایه SSH است و FTPS از FTP همراه TLS استفاده می‌کند. شماره پورت، نام میزبان و نوع اتصال را از اطلاعات سرویس خود بردارید و درستی اثر انگشت یا گواهی را از کانال مورد اعتماد تأیید کنید.

در FTP و FTPS، حالت Binary برای فایل‌های ZIP و سایر فایل‌های غیرمتنی مناسب است. SFTP به‌طور معمول داده فایل را به‌صورت بایت منتقل می‌کند و تنظیمات تبدیل متن هر برنامه ممکن است متفاوت باشد؛ نام گزینه‌ها را در همان نرم‌افزار بررسی کنید. اگر سرویس شما فقط یکی از این پروتکل‌ها را ارائه می‌دهد، با همان تنظیمات پشتیبانی‌شده ادامه دهید و برای عبور از خطا، اعتبارسنجی هویت سرور را خاموش نکنید.

اگر برای انتقال FTP یا FTPS از FileZilla استفاده می‌کنید، از منوی Transfer → Transfer type → Binary گزینه Binary را انتخاب کنید. در نسخه‌های مختلف ممکن است جای نام گزینه کمی فرق داشته باشد. حالت Auto طبق تنظیمات و فهرست پسوندهای برنامه تصمیم می‌گیرد؛ برای آزمایش این مشکل انتخاب صریح Binary ساده‌تر است.

به حساب صحیح وصل شوید و از پنل DirectAdmin مسیر پوشه‌ای را که فایل آزمایشی باید داخل آن قرار گیرد پیدا کنید. فایل را با نامی تازه، مثلاً sample-binary-test.zip، در پوشه آزمایشی آپلود کنید. از روی صف انتقال مطمئن شوید عملیات واقعاً کامل و بدون خطاست؛ بستن پنجره یا شروع آپلود به معنی رسیدن کامل فایل نیست. برای پیشگیری از دسترسی اتفاقی، فایل آزمایشی نباید اطلاعات محرمانه داشته باشد.

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

بعد از پایان آپلود، فایل را از همان مسیر سرور با نام دیگری در رایانه دانلود کنید؛ نام اصلی رایانه را بازنویسی نکنید. مثلاً sample-returned.zip را دریافت کنید. سپس هش نسخه بازگشتی را در همان سیستم حساب کنید:

اگر دو هش یکسان‌اند، رفت‌وبرگشت در این آزمایش بایت‌های فایل را حفظ کرده است. حال لینک عمومی یا مسیر واقعی تحویل فایل را جداگانه امتحان کنید. اگر فایل برگشتی از پنل یا SFTP سالم است ولی فایل دریافتی از لینک عمومی تفاوت دارد، مشکل بعد از آپلود است؛ ممکن است URL به صفحه خطا، کش یا نسخه دیگری اشاره کند. آموزش تشخیص HTML به‌جای ZIP برای همین حالت نوشته شده است.

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

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

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

برای انتخاب سرویس مناسب فایل‌های حجیم، صفحه هاست دانلود نت‌آرام را ببینید. تفاوت حالت متنی و رفتار ابزار خط فرمان در مستندات رسمی curl نیز توضیح داده شده است.