هل أدوات PDF داخل المتصفح خاصة فعلاً؟

ما معنى «داخل المتصفح» فعلاً

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

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

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

كيف يتم ذلك في iBuildPDF

تتبع كل أداة في الموقع الخطوات الأربع نفسها.

1. القراءة. يُقرأ الملف الذي اخترته إلى ArrayBuffer — وهو كتلة من البايتات الخام في ذاكرة التبويب.
2. التحليل أو الرسم. يُنجَز العمل البنيوي (الدمج والتقسيم والتدوير وتحرير البيانات الوصفية وختم العلامات المائية وكتابة أرقام الصفحات) بواسطة pdf-lib 1.17.1، التي تحلّل الرسم البياني لكائنات PDF وتكتب مستنداً جديداً. أما كل ما يحتاج إلى رؤية الصفحة كبكسلات (الصور المصغّرة للصفحات، وتصدير الصور، والتحويل إلى نقاط) فيستخدم Mozilla PDF.js 3.11.174 لرسم الصفحة على لوحة.
3. الإنتاج. يُسلسَل المستند النهائي إلى بايتات ويُغلَّف في Blob — وهو ما زال مجرد ذاكرة داخل التبويب.
4. التنزيل. تستدعي الصفحة URL.createObjectURL() على ذلك الـBlob، فيُنشأ عنوان blob: يشير إلى البيانات الموجودة في الذاكرة، ثم يُطلق التنزيل منه. وعنوان blob: لا يمسّ الشبكة إطلاقاً؛ فهو إشارة إلى شيء يحمله التبويب أصلاً.

وتُحمَّل المكتبتان من شبكة توصيل محتوى عامة بتلك الإصدارات المثبّتة. وهذا طلب شبكة سترى أثره — لكنه يحدث عند تحميل الصفحة، ويجلب شيفرة JavaScript، ولا يحمل شيئاً من ملفاتك.

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

كيف تتحقق من ذلك بنفسك

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

الاختبار الأول: راقب الشبكة

افتح أي أداة — أداة ضغط PDF أو دمج PDF تفي بالغرض. اضغط F12 (أو Cmd+Option+I على أجهزة Mac) لفتح أدوات المطوّرين واختر تبويب الشبكة. فعّل خيار الاحتفاظ بالسجل حتى لا يُمسح شيء، ثم أعد تحميل الصفحة.

سترى التحميل الأول: مستند HTML وملفات CSS وشيفرة JavaScript الخاصة بالموقع وطلبات شبكة توصيل المحتوى الخاصة بـ pdf-lib وpdf.js. والآن اضغط زر المسح لتفريغ القائمة، وعندها فقط اختر ملفك وشغّل الأداة.

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

وهناك تحقق بسيط مفيد: لاحظ حجم ملفك، ثم رتّب لوحة الشبكة حسب عمود الحجم. فمن المستحيل إخفاء عملية رفع هناك.

الاختبار الثاني: اقطع الاتصال

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

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

والشيء الوحيد الذي يجب أن تضبطه هو الترتيب: فلا بد أن تكون المكتبات في ذاكرة المتصفح المؤقتة قبل أن تقطع الاتصال، لأنها تُجلب عند تحميل الصفحة. حمّل أولاً، ثم اقطع الاتصال، ثم عالج.

ما الذي لا يحميك منه هذا

المعالجة المحلية خاصية حقيقية لها حدود حقيقية. وأربعة منها تهمّ.

• إنها خاصية للتنفيذ لا للمتصفحات. فلا شيء في منصة الويب يمنع صفحة من رفع ملف قرأته. وعبارة «تعمل داخل المتصفح» ادّعاء بشأن ما تفعله شيفرة JavaScript في موقع بعينه، والسبب الوحيد لتصديقه هو أنك تحققت — ولهذا يوجد القسم أعلاه.
• إحصاءات الاستخدام ليست محتويات ملفات. فقد يسجّل الموقع أن أداةً ما استُخدمت. لكنه لا يسجّل الملف ولا اسمه ولا حجمه ولا أي شيء مستمَد منه، لأن تلك البيانات لا تصل أصلاً إلى طبقة التحليلات في الصفحة.
• جهازك هو حدّ الثقة. فإضافة المتصفح التي لها إذن بقراءة محتوى الصفحة، أو الجهاز المخترَق، تقع داخل ذلك الحد، ولا تستطيع أي صفحة ويب فعل شيء حيال أي منهما. وإن كان المستند حساساً بما يكفي للقلق، فحال الجهاز الذي تفتحه عليه أهم من الموقع الذي تفتحه فيه.
• الذاكرة هي السقف. ولأن كل شيء يجري في تبويب متصفح واحد، فإن المستندات الكبيرة جداً مقيَّدة بالذاكرة المتاحة لا بحد للرفع. ونتناول موضع ذلك الخط فعلاً في دليل ما حجم ملف PDF الذي يستطيع المتصفح التعامل معه.

متى يكون الخادم ضرورياً فعلاً

هناك مهام لا يمكن إنجازها بصدق داخل تبويب. فتحويل ملف PDF إلى ملف Word أو Excel أو PowerPoint قابل للتحرير يعني إعادة بناء نموذج مستند — فقرات وأنماط وجداول — انطلاقاً من صيغة لا تسجّل سوى مواضع العلامات على الصفحة. وهذا يحتاج إلى محركات تحليل تخطيط لا وجود لها كشيفرة JavaScript في المتصفح. والتعرّف الضوئي على الحروف هو القصة نفسها. وiBuildPDF لا يقوم بالتعرّف الضوئي إطلاقاً؛ فلا توجد أداة كهذه في الموقع.

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

ومحوّلات iBuildPDF بين PDF وWord، وبين PDF وExcel، وبين PDF وPowerPoint مدرَجة بوصفها «قريباً» وهي معطَّلة. وهذا متعمَّد: فالمحوّل الذي لا يستطيع العمل محلياً لا يُطلَق بهدوء وخلفه عملية رفع. وحين تُفعَّل تلك الأدوات ستكون معتمدة على خادم، وستقول صفحتها ذلك.

أما كل ما عداها — الأدوات الـ31 المتاحة كلها، بما فيها التنقيح وإزالة البيانات الوصفية واستخراج النص — فتعمل محلياً اليوم. والتفاصيل التقنية الكاملة موجودة في الصفحة المرجعية لخصوصية الملفات.