الخلاصة

  • عند الجمع بين STRU R وMODE S كان بايت الواحدات علامة هروب: تتبعه 1 فتعني EOR، أو 2 فتعني EOF، أو 3 فتعني النهايتين في الموضع نفسه.
  • إذا كانت العلامة نفسها بيانات حقيقية وجب تكرارها. لذلك احتاج المستقبل إلى سياق التفاوض وحالة تحليل تبقى عبر حدود قراءات البرنامج.
  • نقل نمطا BLOCK وCOMPRESSED الحدود نفسها داخل حقول وصف. فالسجل والسطر ومقطع TCP ودفعة القراءة وحدات مختلفة، ولا يجوز لإحداها أن تنتحل معنى الأخرى.

المعنى مؤجل حتى البايت التالي

لا تمثل علامتان متطابقتان من الواحدات أمرين. بعد فك الترميز تتركان بايت بيانات واحداً. حفظت RFC 765 ثم RFC 959 هذه القاعدة لنمط STREAM: تحجز الأولى للهروب وتعيد الثانية القيمة نفسها إلى الملف.

أما إذا كانت القيمة التالية 1 أغلقت الثنائية السجل؛ وإذا كانت 2 أغلقت الملف؛ وإذا كانت 3 تزامنت نهاية السجل الأخير مع نهاية الملف. العلامة الأولى وحدها ليست تحكماً مكتملاً. يحدد معناها الجار التالي واختيار STRU R السابق.

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

التدفق مرتب لكنه لا يعرف السجلات

فصل FTP بين البنية والنمط. قال STRU F إن الملف سلسلة مستمرة من البايتات، وقال STRU R إنه سجلات متتابعة. وحدد MODE S طريقة مرور التمثيل في اتصال البيانات.

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

لم يكن حقل عد خاص بنظام سجلات على حاسوب مركزي لغة مشتركة تلقائياً. حمل FTP قرار «ينتهي السجل هنا» بدلاً من نسخ ترتيب القرص الخاص بمضيف واحد.

أربع نهايات لحالة انتظار واحدة

يمرر المحلل البايت العادي مباشرة. وعندما يرى العلامة يدخل حالة انتظار. يحسم البايت التالي واحداً من أربعة نواتج: إخراج علامة حرفية، أو EOR، أو EOF، أو الحدثين معاً.

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

من يقسم السجل فور رؤية العلامة يمحو البيانات الحرفية. ومن يحتفظ بنسختي العلامة كبيانين يضيف بايتاً لم يطلبه المصدر. يجب فصل عد بايتات النقل عن بايتات الملف وأحداث البنية.

قد يقع شق القراءة في منتصف الزوج

تعرف RFC 9293 TCP كتدفق بايتات موثوق ومرتب، لا كخدمة سجلات FTP. لا تَعِد بأن استدعاء استقبال واحد يساوي وحدة تطبيق.

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

حتى الإغلاق النظامي لا يكمل علامة معلقة. تبقى صيغة السجل ناقصة لأنها لم تحصل على البايت الذي يحدد تفسيرها.

تحت STRU F تصبح القيمة كلها بيانات

مع STRU F + MODE S تكون جميع البايتات بيانات، ويشير إغلاق اتصال البيانات إلى EOF. لا يفتح بايت الواحدات لغة هروب ولا يحتاج إلى تكرار.

لهذا لا تكفي لقطة الأوكتتات من دون التسلسل الزمني لـSTRU وMODE. قد تفسر القيم نفسها كبيانين عاديين أو كبيان حرفي واحد أو كحد بنيوي، تبعاً للعقد المختار.

ويختلف دليل النهاية أيضاً. يكفي إغلاق الاتصال عادة لإظهار EOF في بنية الملف. أما بنية السجلات فتحتاج EOR الأخير صراحة. عبارة «انتهى الاتصال بنجاح» لا تثبت أن خريطة السجلات اكتملت.

وضعت الأنماط الأخرى الحدود في أوصاف

في BLOCK سبق كل كتلة عدد طول وبايت وصف. يشير بت إلى EOR وآخر إلى EOF ويمكن جمعهما. وخصصت بتات أخرى للبيانات المشكوك فيها وعلامة الاستئناف.

استخدم COMPRESSED أيضاً أوصاف EOR وEOF إلى جانب تمثيل البيانات المكررة والحشو. ظل معنى الحد ثابتاً بينما تغير شكله على السلك حسب MODE.

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

نهاية السطر ليست اسماً آخر لنهاية السجل

ميز FTP بين end-of-line وend-of-record. يمكن لنص ASCII غير المسجل استخدام CRLF، ولنص EBCDIC استخدام NL. أما STRU R فيحمل EOR مستقلاً.

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

طلبت RFC 959 قبول بنية السجلات للنصين ASCII وEBCDIC، وسعت إلى تحويل مفيد وقابل للعكس بين المضيفات الملفية والمسجلة. كون النص مقروءاً لا يثبت بقاء تقسيم المصدر.

ضيق الحد الأدنى لاحقاً من دون إخفاء النتيجة

قصرت RFC 1123 وجوب بنية السجلات على المضيفات التي تدعمها أنظمة ملفاتها. ويمكن لمضيف آخر أن يقبل STRU R ويحفظ تدفق البايتات حرفياً.

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

تحفظ RFC 5797 وسجل IANA لأوامر FTP كلمتي STRU وMODE ضمن المفردات الأساسية. السجل لا يختبر قبول R ولا حالة المحلل بين القراءات ولا الاستعادة بعد التخزين.

ينبغي أن يشمل الإثبات المفسر

يحفظ السجل الموثوق TYPE وSTRU وMODE، وبصمة التدفق الخام وبصمة البيانات، والطولين، وكل مواضع EOR/EOF، وحالة الإغلاق، ونهاية المحلل، ونتيجة إعادة البناء.

تختبر العينات زوجاً مقسوماً بين قراءتين، وعلامة حرفية مضاعفة بجوار كل تحكم، والخريطة نفسها في STREAM وBLOCK. الهروب المعلق والمميز غير الممكن وEOR الأخير المفقود والحالة الباقية بعد تغيير MODE كلها إخفاق معنى.

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

المصادر