الخلاصة

  • يتكوّن ملف gzip في RFC 1952 من أعضاء متجاورين، لكل منهم ترويسة وكتل مضغوطة وتذييل CRC32/ISIZE مستقل.
  • يطيل إلحاق عضو صحيح الناتج المفكوك من دون لمس السابق، لكنه لا ينشئ فهرساً أو وصولاً عشوائياً أو ضغطاً أمثل بين الأعضاء.
  • الحقول الاختيارية أوصاف غير موثقة، وCRC32 لكشف التلف، وISIZE طول العضو بترديد 2^32؛ لا يثبت أي منها هوية الملحِق.

نهاية صالحة لا تمنع بداية جديدة

يُغلق برنامج سجل الأمس المضغوط. في اليوم التالي يكتب برنامج آخر تدفق gzip كاملاً عند نهاية الملف. تبقى بصمة المقدمة كما هي، ومع ذلك ينتج القارئ من البداية بيانات اليومين.

هذه بنية صريحة في RFC 1952: الملف سلسلة من الأعضاء تأتي تباعاً بلا غلاف عام بين الوحدات. يبدأ كل عضو بترويسة معروفة وينتهي بتذييله. تعني النهاية أن هذا العضو اكتمل، لا أن الاسم الخارجي لا يمكن أن يحمل عضواً تالياً.

تسجل صفحة RFC Editor أن وثيقة P. Deutsch نشرت في مايو 1996 بصفتها Informational. ليست معياراً في Standards Track ولا مسحاً لسلوك كل تطبيق. كانت أهدافها قابلية النقل، والمعالجة المتدفقة بذاكرة وسيطة محدودة، وحرية التنفيذ، والتوافق مع gzip. أما الوصول العشوائي فليس من أهدافها.

الترويسة تجمع قواعد وادعاءات

يعرّف بايتان ثابتان صيغة gzip، وتدل CM=8 على DEFLATE. تعلن FLG الحقول الاختيارية، ويجب أن تكون البتات المحجوزة صفراً. هذه قواعد يحتاج إليها كل قارئ ليجد الحدود نفسها.

أما MTIME وFNAME وFCOMMENT وFEXTRA وFTEXT فتحمل وقتاً أو اسماً أو تعليقاً أو امتداداً أو إشارة نصية محتملة. يجب أن يستطيع القارئ تجاوزها حتى إن لم يستخدمها. الصفر في MTIME يعني غياب الوقت، ويمكن تجاهل رمز نظام التشغيل.

الاسم المضمّن ليس إثبات منشأ، والتعليق ليس توقيع عهدة، والوقت لا يثبت لحظة الإلحاق الحالية. إنها ادعاءات داخل الكائن تحتاج إلى ثقة خارجية.

إذا حضرت FHCRC فهي أقل 16 بتاً من CRC32 للترويسة السابقة. أما CRC32 في التذييل فيغطي البيانات بعد الفك، وISIZE يسجل طول الدخل بترديد 2^32. تتجاور القيم ولا تتساوى حدودها.

التحقق المحلي لا ينشئ مصدراً موثوقاً

يكشف CRC32 كثيراً من التلف العرضي، لكن من يستطيع صنع عضو يستطيع حساب CRC صحيح له. النجاح يعني اتساق البايتات مع القيمة، لا معرفة الكاتب أو صلاحية الإضافة.

كما أن ISIZE يلتف كل 2^32، ويصف دخل عضو واحد. في ملف متعدد الأعضاء لا يوجد رقم كلي مطلق في تذييل الأخير؛ يحسب القارئ المجموع بمعالجة السلسلة.

تبقى طبقة الضغط منفصلة. يعرّف RFC 1951 DEFLATE، بينما يضعه RFC 1950 في غلاف zlib ذي ترويسة وAdler-32 مختلفين. وسجّل RFC 6713 لاحقاً application/gzip وapplication/zlib، مميزاً بين غلاف gzip الملائم للملفات وتدفق zlib.

التنفيذ يكشف اختلاف مجال الأدوات

يوثق دليل GNU gzip أن ربط الملفات المضغوطة يجعل gunzip يفك كل الأعضاء. وينبه إلى أن ضغط المدخلات معاً غالباً أفضل، وأن --list يعرض حجم وCRC العضو الأخير فقط في الملف المتعدد.

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

يحيل RFC 9110 ترميز محتوى HTTP المسمى gzip إلى RFC 1952. يثبت ذلك معنى الاسم، لا تطابق كل عميل ووسيط وماسح في معالجة تعدد الأعضاء.

الاتفاق الأدنى يقع عند الحد

يفصل Running-Code Primacy بين النص والتنفيذ والاستخدام. يثبت RFC الشكل المنشور، ويثبت الدليل سلوك تنفيذ محدد، ولا يثبتان انتشاراً شاملاً.

يوضح Minimum Initial Specification أن الاتفاق الصغير يمكن أن يكون صارماً: التعريف والطريقة والأطوال والبتات والتذييل مشتركة؛ عرض التعليق واستخدام الوقت قراران محليان.

ويميز Reality Layers اسم «ملف واحد» عن الواقع التنفيذي ذي بدايات ونهايات وفحوص متعددة. الرمز واحد، أما البنية التي ينفذها القارئ فسلسلة.