Skrive ISO 29500 Strict XLSX-filer fra Delphi

HotXLS skriver ISO/IEC 29500 Strict Open XML-arbeidsbøker fra Delphi og C++Builder ved å sette én enkelt egenskap, StrictOOXML, før lagring. Hver del i pakken, fra xl/workbook.xml ned til relasjonsfilene og innholdstypene, skrives med de strenge purl.oclc.org-vokabularene i stedet for de overgangsvise schemas.openxmlformats.org-vokabularene, og funksjoner Strict ikke tillater, avvises med et eksplisitt unntak i stedet for å skrives ut likevel

De fleste utviklere møter dette kravet gjennom et anskaffelsesdokument. Offentlige anbud i flere jurisdiksjoner ber om den ISO-standardiserte formen av Open XML, ikke den overgangsvise formen Office skriver som standard, og et arkiv som pålegger ISO 29500 Strict, vil avvise en vanlig .xlsx selv om Excel åpner den helt problemfritt. De overgangsvise navnerommene finnes for å ivareta gammel binær oppførsel; de strenge er selve standarden

Hva skiller egentlig Strict fra Transitional?

Den synlige forskjellen er vokabular. En strict arbeidsbokdel erklærer http://purl.oclc.org/ooxml/spreadsheetml/main som sitt rot-navnerom og http://purl.oclc.org/ooxml/officeDocument/relationships for relasjonsreferanser, og ingen overgangsvis navnerom får overleve noe sted i pakken. Relasjonstyper endres med det, så rot-relasjonsdelen navngir .../ooxml/officeDocument/relationships/officeDocument i stedet for den kjente openxmlformats-motparten, og den utvidede egenskapstypen skrives med liten forbokstav og stor midt i ordet, som extendedProperties

Den usynlige forskjellen er omfang. Strict utelater bevisst deler av det overgangsvise skjemaet som bare fantes for å kunne rundtripe gamle binærfiler, sammen med leverandørutvidelsene Office la til i etterkant. Det er derfor konverteringen ikke er et søk-og-erstatt over strenger: enkelte funksjoner har rett og slett ingen strict-stavemåte og skal ikke skrives i det hele tatt

Slå det på

Vanlig forfatterkode endres ikke. Bygg arbeidsboken slik du alltid gjør, sett flagget, og lagre:

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-utdata
    if Wb.SaveAs('archive-copy.xlsx') <> 1 then
      raise Exception.Create('strict save failed');
  finally
    Wb.Free;
  end;
end;

Flagget blir nullstilt ved starten av hver lagringsoperasjon og tildelt på nytt fra arbeidsbokegenskapen, slik at et unntak under én lagring ikke kan lekke strict-modus inn i den neste. Den detaljen betyr noe i serverprosesser der ett enkelt arbeidsbokobjekt betjener flere eksportforespørsler

Hvorfor kan en strict-lagring nekte å kjøre?

Fire funksjonsfamilier er Microsoft-utvidelser uten noe ISO 29500 Strict-motstykke, og HotXLS utløser et unntak ved lagringstidspunktet i stedet for å produsere en pakke som hevder strict-samsvar uten å ha det:

// Strict-utdata kan ikke bygge inn et VBA-prosjekt
//   -> lagre makroaktiverte arbeidsbøker som overgangsvis .xlsm
// Strict-utdata kan ikke bære skjemakontroller
//   -> knapper, avkrysningsbokser, kombinasjonsbokser og deres ctrlProps
// Strict-utdata kan ikke bære trådede kommentarer
//   -> den moderne persons/threads-modellen, ikke klassiske notater
// Strict-utdata kan ikke bære metadata for dynamiske arrayer
//   -> spill-områder registrert gjennom metadata-delen

Å feile høylytt er den riktige avveiningen her. Et VBA-prosjekt som stille droppes, gjør en fungerende arbeidsbok om til en ødelagt en som fremdeles åpnes, og rapporten om feilen kommer fra en bruker uker senere. Et unntak navngir funksjonen og egenskapen som må endres, mens den kallende koden fremdeles vet hva den eksporterte. Bevaring av makroer og eksterne lenker på den overgangsvise banen er dekket i bevaring av VBA-prosjekter og eksterne lenker

To utvidelsesfamilier behandles annerledes, og det er verdt å vite hvorfor. Datalinjer, sparklines og lignende funksjoner ligger i vokabularene x14 og xm, og SVG-variantene av bilder ligger i c15. Dette er utvidelseslisteinnhold der navnerommene er selvbeskrivende, generelle regnearkparsere tolererer dem, og det finnes ikke noe ISO-motstykke å oversette dem til. HotXLS beholder dem i stedet for å kaste brukerinnhold på gulvet. Hvis en validator i pipelinen din er streng også med hensyn til utvidelser og ikke bare navnerom, fjern disse funksjonene fra kildearbeidsboken før eksport

Oversettelsen må nå frem til deler ingen normalt skriver om

Det interessante tekniske problemet i strict-utdata er ikke regnearkets XML. Det er delene en rask skriver heller vil kopiere ordrett. HotXLS bevarer temaer, tilkoblinger, eksterne lenker, diagrammer og pivot-blobber ved å kopiere deres originale komprimerte byte rett gjennom, noe som er nøyaktig det riktige å gjøre for troskap og nøyaktig det gale for strict-utdata, fordi kopierte byte bærer overgangsvise navnerom

Under StrictOOXML bytter disse fem bevarte banene til ombygging eller til en oversettende gjenavspilling, og går utenom byte-kopi-hurtigbanen. All XML går gjennom én oversettelsesrutine, som forankrer seg i attributtverdier i doble anførselstegn, slik at en streng inni en celle som ser ut som en URI, aldri kan bli skrevet om ved et uhell. Celletekst som inneholder den samme URI-en, escapes som en entitet i XML-en, slik at den forankrede erstatningen ikke kan se den. Strømningsskriveren oversetter skjelettet sitt først og deler deretter ved sheetData, siden radblokkene ikke inneholder noen vokabular-URI-er i det hele tatt. Relatert mekanikk for bevaringsbanen er dekket i tapsfrie rundturer for temaer, utvidelseslister og calcChain

Lese filer som Excel lagret som strict

Utdata er bare halve historien. Excel tilbyr «Strict Open XML Spreadsheet» som et lagringsalternativ, og filer produsert på den måten må åpnes korrekt. HotXLS normaliserer relasjonstyper ved hvert relasjonsparsingssted i pakken, roten, eksterne lenker, regneark, tegninger og pivottabeller, slik at en strict relasjonstype matcher den samme interne konstanten som sin overgangsvise motpart

Motstykket på leser-siden er normalisering av navneromsprefikser, som lar vilkårlige prefikser og begge vokabularene løses til én kanonisk navnetabell. Det arbeidet gagner vanlige filer like mye som strict-filer, siden tredjepartsgeneratorer binder prefikser fritt, og det er den samme mekanikken beskrevet i OPC-relasjonsoppløsning i XLSX-pakker

En kort sjekkliste før du sender strict-utdata

Verifiser med pakken, ikke med Excel. Excel åpner begge formene uten problemer, så en vellykket åpning beviser ingenting om samsvar. Pakk ut resultatet og bekreft at xl/workbook.xml erklærer purl-navnerommet, at ingen del inneholder schemas.openxmlformats.org/spreadsheetml, og at relasjonstypene i _rels/.rels og xl/_rels/workbook.xml.rels bruker de strenge formene

Åpne deretter filen på nytt gjennom HotXLS og sammenlign verdier, formler, formater og hyperlenker mot kilden. En tilbakelesingstest er den eneste billige måten å bevise at oversettelsen ikke skadet innholdet, og den øver samtidig normaliseringen på leser-siden. Hvis arbeidsbøkene dine bærer diagrammer, sjekk dem også, siden diagramdelen er en av de bevarte delene som bytter til en ombygd bane under strict-modus

Strict-utdata, tolerant lesing og tapsfri bevaring er alle del av den samme OOXML-motoren for Delphi og C++Builder; den komplette funksjonslisten finnes på HotXLS Delphi regnearkkomponentsiden