Delphi'den ISO 29500 Strict XLSX Dosyaları Yazma

HotXLS, kaydetmeden önce tek bir özelliği — StrictOOXML — ayarlayarak Delphi ve C++Builder'dan ISO/IEC 29500 Strict Open XML çalışma kitapları yazar. Paketteki her parça — xl/workbook.xml'den ilişki dosyalarına ve içerik türlerine kadar — geçişli (transitional) schemas.openxmlformats.org kelime dağarcıkları yerine katı (strict) purl.oclc.org kelime dağarcıklarıyla yazılır ve Strict'in izin vermediği özellikler, yine de yazılmak yerine açık bir istisnayla reddedilir

Çoğu geliştirici bu gereksinimle bir satın alma belgesi üzerinden karşılaşır. Birkaç yargı bölgesindeki kamu sektörü ihaleleri, Office'in varsayılan olarak yazdığı geçişli biçimi değil, Open XML'in ISO standardına uygun biçimini ister ve ISO 29500 Strict'i zorunlu kılan bir arşiv, Excel onu kusursuzca açsa bile sıradan bir .xlsx dosyasını reddeder. Geçişli ad alanları, eski ikili davranışı barındırmak için vardır; katı olanlar ise standardın ta kendisidir

Strict ile Transitional arasında gerçekte ne fark var?

Görünür fark kelime dağarcığıdır. Katı bir çalışma kitabı parçası, kök ad alanı olarak http://purl.oclc.org/ooxml/spreadsheetml/main'i ve ilişki referansları için http://purl.oclc.org/ooxml/officeDocument/relationships'i bildirir ve paketin hiçbir yerinde hiçbir geçişli ad alanı hayatta kalamaz. İlişki türleri de bununla birlikte değişir, bu yüzden kök ilişkiler parçası, tanıdık openxmlformats karşılığı yerine .../ooxml/officeDocument/relationships/officeDocument adını taşır ve genişletilmiş özellikler türü extendedProperties olarak camelCase yazılır

Görünmez fark kapsamdır. Strict, yalnızca eski ikili dosyaları gidiş-dönüşle (round-trip) korumak için var olan geçişli şema parçalarını ve Office'in daha sonra eklediği satıcı uzantılarını bilinçli olarak dışarıda bırakır. Dönüşümün dizeler üzerinde bir ara-ve-değiştir işlemi olmamasının nedeni budur: bazı özelliklerin katı bir yazımı basitçe yoktur ve hiç yazılmamalıdır

Etkinleştirmek

Sıradan yazma kodu değişmez. Çalışma kitabını her zamanki gibi oluşturun, bayrağı ayarlayın ve kaydedin:

var
  Wb: TXLSXWorkbook;
  Sh: TXLSXWorksheet;
begin
  Wb := TXLSXWorkbook.Create;
  try
    Sh := Wb.Sheets.Add('Data');
    Sh.Cells[1, 1].Value := 'Product';
    Sh.Cells[1, 2].Value := 'Amount';
    Sh.Cells[2, 1].Value := 'Widget';
    Sh.Cells[2, 2].Value := 17;
    Sh.Cells[3, 2].Formula := '=SUM(B2:B2)';

    Wb.StrictOOXML := True;          // ISO/IEC 29500 Strict çıktı
    if Wb.SaveAs('archive-copy.xlsx') <> 1 then
      raise Exception.Create('strict save failed');
  finally
    Wb.Free;
  end;
end;

Bayrak, her kaydetme işleminin başında sıfırlanır ve çalışma kitabı özelliğinden yeniden atanır, bu yüzden bir kaydetme sırasındaki bir istisna, katı modu bir sonrakine sızdıramaz. Bu ayrıntı, tek bir çalışma kitabı nesnesinin birden çok dışa aktarma isteğine hizmet ettiği sunucu süreçlerinde önemlidir

Katı bir kaydetme işlemi neden çalışmayı reddedebilir?

Dört özellik ailesi, ISO 29500 Strict karşılığı olmayan Microsoft uzantılarıdır ve HotXLS, katı uygunluk iddia eden ama öyle olmayan bir paket üretmek yerine kaydetme sırasında bir istisna fırlatır:

// Strict çıktı bir VBA projesini gömemez
//   -> makro etkin çalışma kitaplarını geçişli .xlsm olarak kaydedin
// Strict çıktı form denetimleri taşıyamaz
//   -> düğmeler, onay kutuları, açılır kutular ve ctrlProps'ları
// Strict çıktı iş parçacıklı (threaded) yorumları taşıyamaz
//   -> klasik notlar değil, modern persons/threads modeli
// Strict çıktı dinamik dizi meta verisini taşıyamaz
//   -> meta veri parçası üzerinden kaydedilen taşma (spill) aralıkları

Burada doğru tercih yüksek sesle başarısız olmaktır. Sessizce düşürülen bir VBA projesi, çalışan bir çalışma kitabını hâlâ açılan ama bozuk bir kitaba dönüştürür ve hatanın bildirimi haftalar sonra bir kullanıcıdan gelir. Bir istisna, çağıran kod hâlâ neyi dışa aktardığını bilirken özelliği ve değiştirilecek özelliği adlandırır. Geçişli yoldaki makro ve dış bağlantı korunumu, VBA projelerini ve dış bağlantıları koruma yazısında ele alınmıştır

İki uzantı ailesi farklı ele alınır ve nedenini bilmeye değer. Veri çubukları, kıvılcım grafikler (sparkline) ve benzer özellikler x14 ve xm kelime dağarcıklarında yaşar, resimlerin SVG varyantları ise c15'te yaşar. Bunlar, ad alanları kendini açıklayan uzantı listesi içeriğidir, genel elektronik tablo ayrıştırıcıları bunlara tolerans gösterir ve onları çevirebilecek bir ISO karşılığı yoktur. HotXLS, kullanıcı içeriğini yere düşürmek yerine bunları korur. İşlem hattınızdaki bir doğrulayıcı ad alanları kadar uzantılar konusunda da katıysa, dışa aktarmadan önce bu özellikleri kaynak çalışma kitabından kaldırın

Çeviri, normalde kimsenin yeniden yazmadığı parçalara da ulaşmalı

Katı çıktıdaki ilginç mühendislik sorunu, çalışma sayfası XML'i değildir. Hızlı bir yazıcının olduğu gibi kopyalamayı tercih edeceği parçalardır. HotXLS; temaları, bağlantıları, dış bağlantıları, grafikleri ve pivot blob'ları, orijinal sıkıştırılmış baytlarını doğrudan kopyalayarak korur; bu, sadakat için tam olarak doğru şeydir ve katı çıktı için tam olarak yanlış şeydir, çünkü kopyalanan baytlar geçişli ad alanları taşır

StrictOOXML altında bu beş korunan yol, bayt kopyalama hızlı yolunu atlayarak yeniden oluşturmaya veya çeviri yaparak yeniden oynatmaya geçer. Tüm XML, bir hücre içindeki URI benzeri bir dizenin yanlışlıkla asla yeniden yazılamaması için çift tırnaklı öznitelik değerlerine dayanan tek bir çeviri yordamından geçer. Aynı URI'yi içeren hücre metni, XML'de bir varlık (entity) olarak kaçışlanır, bu yüzden bu dayanaklı değiştirme onu göremez. Akış yazıcısı önce iskeletini çevirir, ardından sheetData'da böler, çünkü satır blokları hiç kelime dağarcığı URI'si içermez. Korunum yoluna ilişkin ilgili mekanik, temaların, uzantı listelerinin ve calcChain'in kayıpsız gidiş-dönüşleri yazısında ele alınmıştır

Excel'in katı olarak kaydettiği dosyaları okumak

Çıktı hikayenin yalnızca yarısıdır. Excel, bir kaydetme seçeneği olarak "Katı Open XML Elektronik Tablosu"nu sunar ve bu şekilde üretilen dosyaların doğru açılması gerekir. HotXLS, paketteki her ilişki ayrıştırma noktasında — kök, dış bağlantılar, çalışma sayfaları, çizimler ve pivot tablolar — ilişki türlerini normalleştirir, böylece katı bir ilişki türü, geçişli karşılığıyla aynı dahili sabite eşleşir

Okuyucu tarafındaki karşılığı, keyfi önekler ile her iki kelime dağarcığının tek bir kurallı ad tablosuna çözümlenmesine izin veren ad alanı öneki normalleştirmesidir. Bu çalışma, sıradan dosyalara olduğu kadar katı dosyalara da fayda sağlar, çünkü üçüncü taraf üreteçler önekleri serbestçe bağlar ve bu, XLSX paketlerinde OPC ilişki çözümlemesi yazısında anlatılan aynı mekanizmadır

Katı çıktıyı göndermeden önce kısa bir kontrol listesi

Excel ile değil, paketle doğrulayın. Excel her iki biçimi de sorunsuzca açar, bu yüzden başarılı bir açılış uygunluk (conformance) hakkında hiçbir şey kanıtlamaz. Sonucu zip'ten çıkarın ve xl/workbook.xml'in purl ad alanını bildirdiğini, hiçbir parçanın schemas.openxmlformats.org/spreadsheetml içermediğini ve _rels/.rels ile xl/_rels/workbook.xml.rels'teki ilişki türlerinin katı biçimleri kullandığını doğrulayın

Ardından dosyayı HotXLS üzerinden yeniden açın ve değerleri, formülleri, biçimleri ve köprüleri kaynakla karşılaştırın. Geri okuma testi, çevirinin içeriğe zarar vermediğini kanıtlamanın tek ucuz yoludur ve aynı zamanda okuyucu tarafı normalleştirmeyi de çalıştırır. Çalışma kitaplarınız grafik taşıyorsa onları da kontrol edin, çünkü grafik parçası, katı modda yeniden oluşturulan bir yola geçen korunan parçalardan biridir

Katı çıktı, toleranslı okuma ve kayıpsız korunum, Delphi ve C++Builder için aynı OOXML motorunun tamamının parçasıdır; eksiksiz özellik listesi HotXLS Delphi elektronik tablo bileşeni sayfasındadır