ضغط ملف الأوزان: ماذا يعود بعد فك الضغط؟

الخلاصة السريعة

إذا كان الضغط بلا فقد والفك صحيحا، يعود المحتوى الأصلي؛ لا يعني تصغير التخزين أن الأوزان قربت أو أن الحساب بعد التحميل صار منخفض الدقة.

• GZIP موصوف كصيغة بلا فقد؛ وتعرض Python ضغط بيانات بايتية وفكها إلى بيانات غير مضغوطة. ^{[1] [2]} نحصر الكلام في المحتوى والفك الصحيح.
• نعلن نص الحمولة 1.125,2.875 بترميز ASCII؛ في عقد العودة بلا فقد تعود الفاصلة والأرقام نفسها. تقريب محلي مستقل إلى 1.13 و 2.88 يغير القيم، فلا نسميه الفك نفسه.
• قد يتضمن GZIP تاريخا في الرأس، وتتيح Python ضبط mtime. ^[2] لا نساوي اختلاف الأرشيف المخزن باختلاف كل بايت من الحمولة المفكوكة، ولا نثبت التطابق من الامتداد.
• حدد الأصل وصيغة الضغط والحمولة المفكوكة وعقد تحميل النموذج؛ لا يعطي النص حجم أرشيف أو زمن استدلال أو ضمان صحة ملف، ولم نضغط أو نحمل أوزانا.

على أي مادة يعمل الضغط؟

تصف مواصفة GZIP صيغة بيانات مضغوطة بلا فقد، وتعرض Python دالتي compress وdecompress للبايتات المضغوطة وغير المضغوطة. ^{[1] [2]}

نعامل الحمولة هنا تسلسلا من بايتات، ولا ننسب إلى الضاغط تلقائيا معرفة أن بعض الخانات أوزان أو أن وزنًا صغيرا يجوز حذفه. تعريف الأعداد يحتاج إلى تنسيق الملف والقارئ الذي يفسره؛ عمل الأرشفة الذي نناقشه لا يستبدل ذلك التعريف.

لذلك قد يبقى عقد حساب الأوزان بعد الفك كما كان، إذا أعيدت الحمولة الصحيحة ثم حملها القارئ المناسب. أما وجود امتداد مضغوط في الاسم فلا يقدم سجل فك ناجح أو شهادة توافق النموذج.

عودة النص ليست تقريبه

نؤلف نصا حرفيا هو 1.125,2.875، ونعلن ASCII ترميزا لهذه المحارف. هذا ليس تنسيق نموذج ننصح باعتماده؛ هو حمولة تعليمية فيها عددان وفاصلة، ويمكن مراجعة كل محرف فيها.

في عقدنا الأول نفترض ضغطا بلا فقد وفكا صحيحا يعيد النص نفسه حرفيا: 1.125,2.875. وفي عقد مختلف نعلن تقريب كل عدد إلى منزلتين، مع رفع حالة النصف، فيصير النص العددي 1.13,2.88. لم ننفذ أيًا من العقدين بمكتبة.

العدد الأول تغير بمقدار 0.005 والثاني كذلك تحت قاعدة التقريب المعلنة. لا ننسب هذا التغيير إلى GZIP أو نقول إن كل تكميم يقرب بهذه الطريقة. المقارنة تفصل حفظ المحتوى من تحويل عددي آخر له تعريفه.

هل ملفان مضغوطان مختلفان يعنيان وزنَين مختلفين؟

تسمح واجهة Python بإدخال mtime في رأس GZIP، ويكون هذا تاريخا مصاحبا للتخزين. ^[2]

لو اختلفت معلومات الرأس في أرشيفين مفترضين لهما الحمولة نفسها، فلا نستنتج من اختلاف الملفين المخزنين أن العدد 1.125 اختلف داخل الحمولة المفكوكة. نحتاج المقارنة التي يقصدها السؤال: بايتات الأرشيف أم المحتوى الذي أعاده الفك.

وبالعكس، لا يثبت تطابق اسمي ملفين أو امتدادهما أن حمولتيهما متساويتان. وإذا غاب الأصل أو نتيجة الفك، لا نملأ سجل المقارنة بعبارة «مطابق» اعتمادا على اسم مألوف. لم نحسب بصمة أو نفحص أرشيفا هنا.

ما الذي يبقى خارج نتيجة الأرشفة؟

حجم النص الأصلي لا يخبر حجم أرشيف GZIP الذي لم ننشئه، ولا يحدد نسبة ضغط لملف أوزان كبير. تختلف المادة والتنسيق والخيارات؛ لا نستخرج نسبة من عدد الأرقام في مثالنا.

كما لا تحدد عودة البايتات حجم ذاكرة التنسورات بعد التحميل أو زمن الحساب أو دقة التنبؤ. يلزم عقد تحميل وتعريف نوع الأعداد وتجربة ملائمة لهذه الأسئلة، ولا يمنح اسم «مضغوط» جوابها.

احتفظ بالأصل ومرجع الأرشيف والصيغة ونتيجة التحقق من الحمولة عند القيام بذلك فعلا. الرسم يعرض طريق عودة بلا فقد وطريق تقريب مستقل. لم نضغط ملفا أو نغير أوزانا أو نشغل نموذجا؛ الغرض إبقاء التخزين والتحويل العددي منفصلين في تقرير واضح.