الخلاصة

  • فصل نمط COMPRESSED بين البيانات الحرفية وتكرار أي بايت والحشو الخاص بالتمثيل؛ والحشو وحده لم يحمل القيمة المتكررة.
  • أكمل TYPE القيمة الغائبة: مسافة في ASCII أو EBCDIC، وبايت صفري في Image أو Local byte.
  • قد تحفظ اللقطة كل بتات MODE C وتبقى عاجزة عن إعادة الملف إذا فقدت تسلسل معلمات الجلسة.

العدد وحده كان صيغة صحيحة

يبدأ واصف الحشو بالبتين 11، وتحمل البتات الستة الأخرى العدد. ينتهي العنصر هنا، ولا يأتي بعده بايت عينة. يثبت RFC 765 ثم RFC 959 هذه الصيغة نفسها.

أما تكرار قيمة عشوائية فله الصنف 10: عدد من ستة بتات ثم بايت صريح d يكرره المستقبل. لذلك لا يعني غياب العينة شيئاً واحداً. بعد 10 هو بتر؛ وبعد 11 يكون انتظار العينة خطأ يلتهم بداية العنصر التالي.

للبيانات العادية تعهد ثالث: بت أعلى قيمته صفر، وعدد موجب من سبعة بتات حتى 127، ثم n من البايتات الحرفية. لا يقرر العدد وحده طول البنية اللاحقة؛ الصنف هو الذي يقرر.

قدّم TYPE ما حذفه MODE

الحشو في ASCII هو المسافة ذات الرمز 32، وفي EBCDIC المسافة ذات الرمز 64. وفي Image أو Local byte هو بايت صفري. وهكذا يمكن للواصف نفسه أن ينتج مسافات أو أصفاراً من دون أن تتغير بتاته.

يقول RFC 959 إن التمثيل ونمط النقل مستقلان في الأساس، ثم يحدد الاستثناء بدقة: طبيعة بايت الحشو في Compressed تعتمد على نوع التمثيل. ليست هذه ملاحظة هامشية، بل المدخل الذي يسمح للصيغة الأقصر بحذف القيمة.

إذا احتفظ جهاز الالتقاط باتصال البيانات وحده بقي لديه العدد وضاعت المادة. يثبت تجزؤه الرقمي ما وصل من ترميز، لكنه لا يثبت وحده أي صورة للملف كوّنها المستقبل آنذاك.

التكرار ليس مرادفاً للحشو

يستطيع 10 تكرار أي قيمة لأنه يرسل العينة. أما 11 فلا يكرر إلا القيمة التي منحها التمثيل منزلة الحشو. سلسلة من الأصفار في ASCII لا تصبح حشواً لمجرد أنها متطابقة، لأن الحشو هناك مسافة. وفي Image يمكن إنشاء الأصفار بلا عينة.

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

سلكت معلومات التحكم طريقاً رابعاً: بايت هروب صفري ثم واصف يحمل رموز BLOCK ويطبقها على السلسلة التالية. وكان على آلة الحالة أن تميز الحرفي والتكرار الصريح والحشو الضمني والتحكم قبل تسليم الناتج للتخزين.

كانت فراغات الطباعة تستهلك السعة

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

لهذا كان منح المسافة النصية صيغة من بايت واحد قراراً عملياً، مثل منح الصفر الدور المقابل في التمثيل الثنائي. لم يكن بروتوكولاً عاماً لكل ضغط حديث، بل مواءمة ضيقة مع معنى التمثيل وعبء تاريخي محدد.

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

القبول هو الذي يفتح حقبة فك جديدة

ضُبطت TYPE وSTRU وMODE عبر أوامر وردود. لذلك يجب تسجيل الحالة التي وافق عليها الطرف البعيد، لا نية العميل فقط. الأمر المرفوض لا يغير التمثيل الفعال.

يرتبط كل نقل بمعلماته عند البدء، ويفتح كل تغيير مقبول حقبة تفسير جديدة. تشمل الأدلة حدود النقل وحالة المحلل أولاً وآخراً وبصمة الدفق والناتج. أما حدود مقاطع TCP وعمليات القراءة المحلية فلا معنى نحوياً لها.

كون MODE أساسياً لا يثبت شمول C

عيّن RFC 959 القيم S وB وC، وجعل Stream الافتراضي. ثم قصر RFC 1123 الحد الأدنى المطلوب على Stream. وجود MODE C في المعيار لا يعني أن كل تنفيذ تاريخي أو حالي دعمه.

يبقي RFC 5797 وسجل IANA لأوامر FTP وامتداداته الأمر MODE ضمن مفردات الأساس. يثبت السجل الاسم والمرجع، ولا يختبر الوسيط C أو المحلل أو دورة التخزين والاسترجاع.

بصمتان بدل افتراض واحد

يحتفظ السجل القابل للدفاع بالدفق الخام وطوله وبصمته، وتسلسل TYPE/STRU/MODE المقبول، وصنف كل عنصر وعدده وما ينتظره، وأحداث التحكم والحالة النهائية وبصمة الناتج القانوني. ولا يدمج الحشو بالتكرار الصريح حتى إن أنتجا البايتات نفسها مصادفة.

تشغّل الاختبارات واصف 11 نفسه تحت ASCII وEBCDIC وImage وLocal byte، وتقارنه بـ10 مع عينة مكافئة، وتقسم العناصر متعددة البايتات بين القراءات، وتنهي الدفق بعد تكرار بلا عينة. النحو والسياق هما الحكم، لا حجم الحزمة.

لم يرسل المرسِل البايت لأن الجلسة كانت قد سمته. استعان FTP بالسياق ليوفر السعة؛ ومن يريد أن تبقى البتات دليلاً عليه أن يحفظ السياق الذي منحها معناها.

المصادر