HotXLS Delphi Component: workbook metadata and document properties في Delphi

يحمل جدول البيانات طبقتين من الهوية هناك شبكة الخلايا، وهناك البيانات الوصفية للمستند التي ترافقها: العنوان، والمؤلف، والشركة، والكلمات المفتاحية، والطوابع الزمنية لا يُظهر Excel أبدا تلك الطبقة الثانية في الشبكة، ومع ذلك فهي الطبقة التي تفهرسها Windows Search، والطبقة التي يقرأها SharePoint لتسمية مستند، والطبقة التي يصنّف بها نظام إدارة السجلات ملفاته حين يرث مصنف مولَّد خاصية المؤلف والعنوان من القالب الذي بُني منه، يسجّل كل نظام لاحق مصمم القالب كمؤلف لأربعة آلاف كشف حساب عميل البيانات الوصفية صحيحة في لا مكان ومُراجَعة في كل مكان

تُظهر HotXLS هذه الطبقة كخصائص عادية على مستوى المصنف في كلا محركيها: واجهة BIFF لملفات .xls وواجهة OOXML لملفات .xlsx تقرأ حقلا بعد فتح ملف وتكتب حقلا قبل حفظه المكتبة تقرر أي حاوية فعلية تستقر فيها القيمة ما يستحق فهمه قبل كتابة مولّد هو أي الحقول يدعمها فعليا كل صيغة، وأين تعيش تلك الحقول فعليا، والقاعدة البوابية الوحيدة التي تحكم ما إذا كان ملف .xlsx يسجّل أي بيانات وصفية على الإطلاق

صيغتان، ونموذجا تخزين

السبب في أن مكتبة جداول البيانات تحتاج تنفيذين للبيانات الوصفية، والسبب في أن الأدوات نصف المكتملة تختم صيغة واحدة بشكل صحيح وتنسى الأخرى، هو أن .xls و.xlsx يحفظان خصائصهما في أماكن غير مترابطة يكتب مصنف BIFF خصائصه في دفقات ملف OLE المركب، أساسا مجموعة خصائص SummaryInformation التي تسبق Excel نفسه، إلى جانب سجل WRITEACCESS داخل الدفق الذي يسمّي آخر من حفظ الملف يحتفظ مصنف OOXML بخصائصه كأجزاء XML داخل الحزمة المضغوطة، مقسّمة حسب الغرض: docProps/core.xml يحمل حقول Dublin Core (العنوان، والمنشئ، والموضوع، والكلمات المفتاحية، والتواريخ) وdocProps/app.xml يحمل الحقول على مستوى التطبيق مثل الشركة وتطبيق التوليد، وفق ECMA-376 الجزء 1

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

ختم المصنفات المولَّدة من السجل التجاري

في جانب XLSX، تعرض TXLSXWorkbook Title وSubject وAuthor وKeywords وDescription وCategory وLastModifiedBy وCompany وApplication وAppVersion كسلاسل نصية، إضافة إلى Created وModified كقيم TDateTime حيث يعني الصفر أنها غير مضبوطة القاعدة التي تسد ثغرة الوراثة جملة واحدة: عيّن كل حقل في كل تشغيل، مستمدا القيم من السجل التجاري بدل الوثوق بما حمله القالب مصادفة

var
  Book: TXLSXWorkbook;
begin
  Book := TXLSXWorkbook.Create;
  try
    if Book.Open('statement-template.xlsx') <> 1 then
      raise Exception.Create('Template not available');

    // اكتب فوق كل حقل: أي شيء لم يُلمس
    // موروث ممن صمم القالب
    Book.Title := 'Account Statement 2026-06 / ACME Corp';
    Book.Subject := 'Monthly account statement';
    Book.Author := 'Billing Service 4.2';
    Book.LastModifiedBy := 'Billing Service 4.2';
    Book.Company := 'Northwind Financial';
    Book.Category := 'Customer Delivery';
    Book.Keywords := 'statement;billing;2026-06;acct-10024';
    Book.Description := 'Generated document - manual edits are not retained';
    Book.Created := Now;
    Book.Modified := Now;

    Book.SaveAs('statement-10024.xlsx');
  finally
    Book.Free;
  end;
end;

حقل Keywords يستحق تفكيرا أكثر مما يحصل عليه عادة بنية البحث تفهرسه حرفيا، Windows Search وSharePoint ومعظم منتجات إدارة المستندات على حد سواء، لذا اتفاقية مفصولة بفاصلة منقوطة تحمل رقم الحساب والفترة تحوّل كل مصنف مُسلَّم إلى سجل قابل للعثور عليه دون رحلة قاعدة بيانات ذهابا وإيابا نفس هذا المدى هو المشكلة الخصائص تسافر مع كل نسخة من الملف، متجاوزة بكثير ضوابط الوصول للنظام الذي كتبها، لذا لا مكان فيها للبيانات الشخصية

زوج الطابع الزمني يحمل دلالات تستحق أن تُثبَّت في السياسة لا أن تُترَك للعادة Created ينبغي أن يسجّل اللحظة التي ولّد فيها خط أنابيبك المستند ثم يبقى مجمَّدا Modified هو الحقل الذي يحدّثه Excel كلما حفظ مستلم الملف، لذا تباعد بين الاثنين بعد التسليم دليل إيجابي على أن أحدا حرر المصنف لاحقا، وهذا يحسم أكثر من نزاع واحد حول أرقام من فعليا يحملها جدول بيانات مُعاد توجيهه فخ واحد يختبئ في الحالة غير المضبوطة: إنها القيمة الحرفية صفر، لا استثناء ولا قيمة فارغة، لذا يجب على كود التدقيق اختبار الصفر صراحة نسّق TDateTime غير مضبوط دون ذلك الحارس وستمتلئ سجلاتك بتاريخ ديسمبر 1899 خاطئ بثقة

DocPropsTouched: المصنف الذي يُشحَن دون docProps

علم للقراءة فقط، DocPropsTouched، يحكم كاتب خصائص XLSX مصنف لم تُعيَّن فيه أي خاصية أبدا لا ينتج أي أجزاء docProps إطلاقا؛ ترفض HotXLS كتابة هيكل بيانات وصفية فارغ السلوك مرتب، وله نتيجتان تستحقان التصميم من أجلهما

يجب على كود الاستلام في الجانب المستهلك ألا يفترض وجود core.xml في كل حزمة أداة تفرضه إجباريا سترفض ملفات دنيا صحيحة تماما وإذا كان موقفك من الامتثال يفرض أن يحمل كل مستند صادر هوية مولّد على الأقل، فذلك المطلب يصبح كودا لا خاصية للصيغة: عيّن Application وAuthor دون شرط في مسار الحفظ، لأن مصنفا لم يُلمَس شرعي تماما وفق المواصفة بينما ينتهك سياستك بصمت

سطح XLS القديم وفخ Comments

تحمل واجهة BIFF مجموعة الحقول الأقدم والأصغر: Title وSubject وAuthor وKeywords وComments وCompany وManager، إضافة إلى LastSavedBy، وهو اسم مستعار لـUserName، الذي يكتب سجل WRITEACCESS الذي يعرضه Excel حين يكون الملف مقفلا لدى مستخدم آخر

var
  Legacy: IXLSWorkbook;     // واجهة معدودة المراجع: لا Free يدوي
begin
  Legacy := TXLSWorkbook.Create;
  if Legacy.Open('archive-1999.xls') <= 0 then
    raise Exception.Create('Cannot open archive file');

  Legacy.Title := 'FY1999 ledger (migrated copy)';
  Legacy.Author := 'Archive Migration Batch';
  Legacy.Company := 'Northwind Financial';
  Legacy.Comments := 'Migrated 2026-06-11; source retained in cold storage';
  Legacy.LastSavedBy := 'migration-svc';   // سجل WRITEACCESS في BIFF

  Legacy.SaveAs('archive-1999-stamped.xls');
end;

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

قراءة البيانات الوصفية عند الاستلام، وثغرة الفحص

القراءة متماثلة بعد Open، تعود الخصائص نفسها ممتلئة من الملف، ما يحوّل تدقيق البيانات الوصفية للمصنفات الواردة إلى حلقة قصيرة

var
  Book: TXLSXWorkbook;
begin
  Book := TXLSXWorkbook.Create;
  try
    if Book.Open(FileName) = 1 then
    begin
      Writeln(Format('%s | title="%s" author="%s" created=%s',
        [ExtractFileName(FileName), Book.Title, Book.Author,
         FormatDateTime('yyyy-mm-dd', Book.Created)]));
      if Book.Created = 0 then
        Writeln('  no creation date recorded');
    end;
  finally
    Book.Free;
  end;
end;

خطط حول قيد واحد وأنت تفعل ذلك لا يوجد فحص بيانات وصفية وحدها GetSheetNames يستطيع سرد الأوراق دون تحميل مصنف، لكن قراءة Title أو Author تعني Open كاملا، لذا فرز البيانات الوصفية عبر أرشيف كبير يدفع تكلفة التحليل الكاملة على كل ملف في جانب BIFF يمكنك تقليص تلك التكلفة لتدقيقات القراءة فقط بضبط _DisableGraphics إلى صحيح قبل الفتح، ما يتخطى طبقة الرسم كليا يناسب حلقة تقرأ فقط الخصائص وإحصاءات الخلايا، وهو خاطئ تماما في اللحظة التي قد تحفظ فيها النسخة نفسها، لأن محتوى الرسم المتخطى سيُسقط حين يمكن لبنية الأوراق وحدها فلترة المجموعة مسبقا، وتصدير الورقة الواحدة كونه الشيء الواضح لتخطيه، فإن التقنيات الرخيصة في مقالتنا عن سرد الأوراق والفحص الخفيف تقلل عدد الملفات التي تصل إلى التمرير المكلف وفي مهام الختم الجماعي، حيث تُكتَب آلاف المخرجات بدل فحصها، فإن أنماط إنتاجية جانب الكتابة في مقالتنا عن الكتابة المتدفقة لمهام الدفعات تنتقل دون تغيير، لأن تعيين الخاصية لا يضيف شيئا يُقاس إلى وقت الحفظ

عبور الصيغ واحتواء التسرب

الخصائص تنتقل ذهابا وإيابا بنظافة داخل واجهة واحدة: افتح .xlsx، وحرره، واحفظه، وتعود المجموعة سليمة عبور الصيغ هو حيث ينكسر افتراض التكافؤ، لأن مجموعتي حقول BIFF وOOXML لا تتطابق واحدة لواحدة لدى BIFF Manager ولا طوابع زمنية؛ لدى OOXML Category وDescription وزوج Created/Modified محوّل ينسخ بشكل أعمى يفقد كل ما لا تستطيع صيغة الوجهة حمله، لذا خطط الحقول صراحة وضع التخطيط في قائمة تحويلك المرجعية بجانب كل شيء آخر لا ينجو من الرحلة

التسرب الذي تفتحه وراثة القالب يسير في الاتجاه الآخر: معلومات لم تقصد أبدا شحنها أسماء المؤلفين، تسميات مشاريع داخلية ركنت في الكلمات المفتاحية، عنوان مسودة لم يوافق عليه أحد الانضباط بالكتابة فوق كل شيء من المولّد أعلاه هو الدفاع الكامل، ويستحق التحقق منه بالطريقة التي يفعلها شخص خارجي، بفتح مربع حوار الخصائص الذي يمكن لأي عميل الوصول إليه أو بفك ضغط .xlsx وقراءة docProps/core.xml مباشرة من الحزمة ما تراه هناك هو بالضبط ما يراه كل فهرسة لاحقة

تلك الرؤية اللاحقة هي أيضا سبب استحقاق بضعة حقول عناية أكثر من البقية العنوان، والمؤلف، والكلمات المفتاحية (التي تظهر كوسوم)، والتعليقات أو الوصف تحمل معظم ثقل الفهرسة في SharePoint وWindows Search عنوان مميز حقا لكل مستند، يحمل الفترة والحساب، يفعل من أجل قابلية العثور أكثر من أي مخطط تسمية مجلدات مكدَّس فوقه، ويكلّف تعيينا واحدا لكل حفظ

خصائص المستند هي أرخص لمسة احترافية يمكن أن يحملها مصنف مولَّد، والعيب الأكثر شيوعا الذي يُشحَن حين لا يملكها أحد كلا سطحي الخصائص الموصوفين هنا ينتميان إلى HotXLS Delphi Component، الذي يكتبها أصليا لـXLS وXLSX دون أتمتة Excel