Summary

  • نشر W3C أول مسودة عمل عامة لواجهة File API في 17 نوفمبر 2009. وصفت المسودة الملفات التي يختارها المستخدم، وقائمة FileList، وقراءة المحتوى عبر FileReader مع أحداث تبيّن سير العملية.
  • فصلت مسودتا 2013 و2015 أدوار Blob والقراءة غير المتزامنة وروابط blob. معاينة الملف داخل الصفحة وإرساله إلى خادم قراران متتابعان، لا حركة واحدة.

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

انطلقت أول مسودة عامة لـ File API، في 17 نوفمبر 2009، من الملفات المختارة واحداً واحداً. يمكن لحقل <input type="file"> فتح نافذة الاختيار، ثم تمثل FileList النتيجة. يحمل كائن File معلومات مثل الاسم والنوع، ويمثل Blob البايتات الخام وأجزاء منها. يقرأ FileReader المحتوى لصالح نص الصفحة البرمجي، ويرسل أحداثاً عن القراءة. حصلت الصفحة على كائن واضح الحدود بدلاً من مفتاح للخزانة.

قبل ذلك كان نموذج الرفع يستطيع إرسال ملف إلى الخادم. لكن المستخدم قد يكتشف هناك أنه اختار الصورة الخطأ. عندما صارت البايتات متاحة للصفحة بعد الاختيار، أمكن عرض الصورة قبل الإرسال أو قراءة النص والتحقق منه. أوردت مسودة 2009 وسائل readAsBinaryString وreadAsText وreadAsDataURL للقراءة غير المتزامنة. ليست الأسماء مادة للنكات في متجر التصوير، لكنها جعلت من «اختيار ملف» بداية عمل داخل المتصفح، لا مجرد طابع بريد على طرد متجه إلى الخادم.

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

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

في مسودة المرحلة الأخيرة للتعليقات المؤرخة 12 سبتمبر 2013، اتضحت وظيفة كل قطعة أكثر. تضم FileList العناصر المختارة. يحفظ Blob بيانات خاماً غير قابلة للتعديل المباشر ويسمح بأخذ شريحة منها. يضيف File الاسم ومعلومات عن التعديل. ويقرأ FileReader بطريقة غير متزامنة مع أحداث للتقدم والنجاح والخطأ. يعرض مثال المسودة قراءة ملف كنص وتحديث شريط تقدم. إذا تأخر قرص موصول أو كبر الملف، تستطيع الصفحة أن تقول للقارئ إنها ما زالت تعمل، بدلاً من الوقوف صامتة خلف الستار.

أرادت صفحات الويب أيضاً أن تعرض الصورة كما تعرض أي صورة أخرى: عبر عنوان URL. لكن الملف المختار كائن محلي. جاءت روابط blob لتصل بين الشكلين. تقدم مسودة 21 أبريل 2015 مثالاً ينشئ مرجعاً باستخدام URL.createObjectURL()، ثم يسحبه بـURL.revokeObjectURL() بعد انتهاء المعاينة. تحذر المسودة من بقاء المراجع المنسية. بطاقة الاستلام على طاولة المتجر نافعة ما دامت الصورة هناك؛ إبقاؤها معلقة إلى الأبد ليس طريقة جيدة لترتيب المكان.

وتكشف قاعدة صغيرة من 2015 دقة هذا التسليم: يعرض File.name اسم الملف من دون مسار المجلدات التي تقود إليه. تستطيع الصفحة كتابة اسم الصورة إلى جانب معاينتها، ولا تحتاج خريطة أدراج جهاز صاحبها. كما وصفت المسودة روابط blob مرتبطة بأصلها وتفشل الطلبات القادمة من أصل آخر. كانت المنفعة في قدرة الصفحة على استخدام الكائن المحدد، لا في معرفتها كيف رتّب الشخص بقية ملفاته.

تسجل صفحة تاريخ النشر لدى W3C المسودة العامة الأولى في 2009، ومسودة Last Call في 2013، ومسودة عمل أخرى في 2015. امتد صقل الواجهة أعواماً، ولم يكن نص 2015 توصية نهائية. القيمة الدائمة في هذا المسار هي تحويل اختيار بشري صغير إلى تمثيل مشترك: المتصفح يعرف أي ملف سُلّم، والصفحة تملك أدوات عملية للتعامل معه.

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

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