معظم مستخرجي ملفات PDF يستخدمون واجهة برمجة التطبيقات (API) الخاطئة
معظم أدوات PDF تستخدم مصدر بيانات خاطئ.
عندما يتحدث المطورون عن استخراج بيانات PDF، فإنهم يقصدون عادةً getTextContent(). توفر هذه الطريقة عناصر النص ومواقعها، وهي الخيار الافتراضي لكل أداة تعمل في جانب المتصفح تقريبًا.
لكن getTextContent() هي عرض مُعالَج؛ فهي نسخة مبسطة مما هو متاح بالفعل.
هناك ثلاثة مستويات من البيانات في PDF.js:
• getStructTree(): يخبرك هذا بما يعنيه المستند، حيث يحتوي على الجداول والعناوين والمعادلات.
• getOperatorList(): يخبرك هذا بما يرسمه المستند، ويشمل الخطوط والمسارات والأشكال.
• getTextContent(): هذا عرض مُصفّى لما يرسمه المستند.
تستخدم معظم الأدوات الخيار الثالث. يعمل هذا مع 80% من المستندات مثل التقارير البسيطة، ومع ذلك، فإنه يفشل مع الأوراق الأكاديمية والمنشورات المعقدة.
يؤدي استخدام getTextContent() فقط إلى أربع مشكلات رئيسية:
- تفقد هياكل الجداول؛ حيث تضطر إلى تخمين أماكن الخلايا بناءً على مواقع النص.
- تتعطل المعادلات الرياضية؛ فغالبًا ما تظهر معادلات LaTeX ككتل نصية ضخمة ووحيدة.
- تفقد خطوط الأعمدة؛ حيث تستخدم العديد من التنسيقات خطوطًا فعلية للفصل بين الأعمدة، وهذه الخطوط لا توجد في المحتوى النصي.
- تحصل على ترتيب قراءة خاطئ؛ فغالبًا ما يظهر النص بالترتيب الذي رُسم به، وليس بالطريقة التي يقرأه بها البشر.
الطريقة الصحيحة لبناء معالج PDF هي نظام مكون من ثلاثة مستويات:
- تحقق من
getStructTree()أولاً. إذا كان للمستند هيكل منطقي، فاستخدمه للعثور على الجداول والعناوين على الفور. - تحقق من
getOperatorList()بعد ذلك. استخدم الخطوط والمسارات الصريحة للعثور على حدود الأعمدة. - استخدم
getTextContent()كخيار احتياطي. استخدم الرياضيات الهندسية فقط عندما لا يوفر المستويان الأولان أي بيانات.
هذا النهج لا يتطلب جهداً إضافياً، حيث يعمل المستويان 1 و2 كمخارج سريعة. إذا كان المستند منظمًا جيدًا، فستتخطى العمليات الرياضية الصعبة، ولن تلجأ إلى الاستنتاج المعقد إلا عندما يكون المستند غير مُوسم.
تتعامل هذه البنية مع كل من ملفات الشركات البسيطة والأوراق العلمية المعقدة.
المصدر: https://dev.to/bonzai2carn/most-pdf-extractors-use-the-wrong-api-heres-what-we-built-instead-5dgh