ISO 29500 Strict -XLSX-tiedostojen kirjoittaminen Delphistä

HotXLS kirjoittaa ISO/IEC 29500 Strict Open XML -työkirjoja Delphistä ja C++Builderista asettamalla yhden ominaisuuden, StrictOOXML, ennen tallennusta. Jokainen paketin osa, aina tiedostosta xl/workbook.xml suhdetiedostoihin ja sisältötyyppeihin asti, kirjoitetaan tiukoilla purl.oclc.org-sanastoilla siirtymäkauden schemas.openxmlformats.org-sanastojen sijaan, ja ominaisuudet, joita Strict ei salli, hylätään selkeällä poikkeuksella sen sijaan, että ne kirjoitettaisiin silti ulos

Useimmat kehittäjät kohtaavat tämän vaatimuksen hankinta-asiakirjan kautta. Julkisen sektorin tarjouspyynnöt useissa oikeudenkäyttöalueissa pyytävät Open XML:n ISO-standardoitua muotoa, ei siirtymäkauden muotoa, jota Office kirjoittaa oletuksena, ja arkisto, joka edellyttää ISO 29500 Strict -muotoa, hylkää tavallisen .xlsx-tiedoston, vaikka Excel avaa sen täydellisesti. Siirtymäkauden nimiavaruudet ovat olemassa mukautuakseen vanhaan binäärikäyttäytymiseen; tiukat nimiavaruudet ovat itse standardi

Mikä todella eroaa Strictin ja Transitionalin välillä?

Näkyvä ero on sanasto. Tiukka työkirjaosa ilmoittaa juurinimiavaruudekseen http://purl.oclc.org/ooxml/spreadsheetml/main ja suhdeviittauksilleen http://purl.oclc.org/ooxml/officeDocument/relationships, eikä mikään siirtymäkauden nimiavaruus saa säilyä missään kohtaa pakettia. Suhdetyypit muuttuvat sen mukana, joten juurisuhteiden osa nimeää muodon .../ooxml/officeDocument/relationships/officeDocument tutun openxmlformats-vastineen sijaan, ja laajennettujen ominaisuuksien tyyppi on camelCase-muodossa extendedProperties

Näkymätön ero on laajuus. Strict jättää tarkoituksella pois osia siirtymäkauden skeemasta, jotka olivat olemassa vain vanhojen binääritiedostojen edestakaista muuntamista varten, sekä toimittajan lisäykset, jotka Office lisäsi myöhemmin. Siksi muunnos ei ole merkkijonojen etsi-ja-korvaa-operaatio: joillakin ominaisuuksilla ei yksinkertaisesti ole tiukkaa kirjoitusasua, eikä niitä saa kirjoittaa lainkaan

Käyttöönotto

Tavallinen kirjoituskoodi ei muutu. Rakenna työkirja kuten aina, aseta lippu ja tallenna:

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

Lippu nollataan jokaisen tallennustoiminnon alussa ja asetetaan uudelleen työkirjan ominaisuudesta, joten yhden tallennuksen aikainen poikkeus ei voi vuotaa strict-tilaa seuraavaan. Tällä yksityiskohdalla on merkitystä palvelinprosesseissa, joissa yksi työkirjaobjekti palvelee useita vientipyyntöjä

Miksi tiukka tallennus voi kieltäytyä suorittumasta?

Neljä ominaisuusperhettä ovat Microsoftin laajennuksia, joilla ei ole ISO 29500 Strict -vastinetta, ja HotXLS nostaa poikkeuksen tallennushetkellä sen sijaan, että se tuottaisi paketin, joka väittää olevansa tiukan vaatimustenmukainen mutta ei ole:

// Strict-tuloste ei voi upottaa VBA-projektia
//   -> tallenna makroja sisältävät työkirjat siirtymäkauden .xlsm-muodossa
// Strict-tuloste ei voi kantaa lomakeohjaimia
//   -> painikkeet, valintaruudut, yhdistelmäruudut ja niiden ctrlProps
// Strict-tuloste ei voi kantaa säikeistettyjä kommentteja
//   -> nykyaikainen henkilöt/säikeet-malli, ei klassiset muistiinpanot
// Strict-tuloste ei voi kantaa dynaamisten taulukoiden metatietoja
//   -> valumisalueet, jotka on tallennettu metatieto-osan kautta

Äänekäs epäonnistuminen on tässä oikea kompromissi. Hiljaa pudotettu VBA-projekti muuttaa toimivan työkirjan rikkinäiseksi, joka silti avautuu, ja raportti virheestä saapuu käyttäjältä vasta viikkojen kuluttua. Poikkeus nimeää ominaisuuden ja muutettavan asetuksen, samalla kun kutsuva koodi vielä tietää, mitä se oli viemässä. Makrojen ja ulkoisten linkkien säilyttäminen siirtymäkauden polulla käsitellään artikkelissa VBA-projektien ja ulkoisten linkkien säilyttäminen

Kahta laajennusperhettä käsitellään eri tavalla, ja on hyvä tietää miksi. Datapalkit, minikaaviot ja vastaavat ominaisuudet asuvat sanastoissa x14 ja xm, ja kuvien SVG-muunnelmat asuvat sanastossa c15. Nämä ovat laajennuslistan sisältöä, jonka nimiavaruudet ovat itsekuvaavia, yleiset laskentataulukkojäsentimet sietävät niitä, eikä niille ole ISO-vastinetta, johon ne voisi kääntää. HotXLS säilyttää ne sen sijaan, että se hylkäisi käyttäjän sisällön kokonaan. Jos putkessasi oleva validaattori on tiukka myös laajennusten suhteen nimiavaruuksien lisäksi, poista nämä ominaisuudet lähdetyökirjasta ennen vientiä

Käännöksen täytyy ulottua osiin, joita kukaan ei normaalisti kirjoita uudelleen

Kiinnostava suunnitteluongelma tiukassa tulosteessa ei ole laskentataulukon XML. Se on osat, jotka nopea kirjoitin mieluummin kopioisi sellaisenaan. HotXLS säilyttää teemat, yhteydet, ulkoiset linkit, kaaviot ja pivot-blobit kopioimalla niiden alkuperäiset pakatut tavut suoraan läpi, mikä on täsmälleen oikea toimintatapa uskollisuuden kannalta ja täsmälleen väärä toimintatapa tiukan tulosteen kannalta, koska kopioidut tavut kantavat siirtymäkauden nimiavaruuksia

Tilassa StrictOOXML nämä viisi säilytettyä polkua vaihtuvat uudelleenrakennukseen tai kääntävään toistoon, ohittaen tavukopioinnin nopean polun. Kaikki XML kulkee yhden käännösrutiinin läpi, joka ankkuroituu lainausmerkeillä ympäröityihin attribuuttiarvoihin, jotta solun sisällä oleva URI:lta näyttävä merkkijono ei voi koskaan kirjoittua uudelleen vahingossa. Solutekstiä, joka sisältää saman URI:n, käsitellään XML:ssä entiteettinä, joten ankkuroitu korvaus ei näe sitä. Suoratoistava kirjoitin kääntää ensin runkonsa ja pilkkoo sitten kohdasta sheetData, koska rivilohkot eivät sisällä lainkaan sanaston URI-osoitteita. Säilytyspolun liittyvä mekaniikka käsitellään artikkelissa teemojen, laajennuslistojen ja calcChainin häviötön edestakainen muunnos

Tiedostojen lukeminen, jotka Excel on tallentanut tiukkana

Tuloste on vain puolet tarinasta. Excel tarjoaa "Strict Open XML Spreadsheet" -tallennusvaihtoehdon, ja sillä tavoin tuotettujen tiedostojen täytyy avautua oikein. HotXLS normalisoi suhdetyypit jokaisessa paketin suhteiden jäsennyskohdassa, juuressa, ulkoisissa linkeissä, laskentataulukoissa, piirroksissa ja pivot-taulukoissa, joten tiukka suhdetyyppi täsmää samaan sisäiseen vakioon kuin sen siirtymäkauden vastine

Lukupuolen vastine on nimiavaruuden etuliitteiden normalisointi, joka sallii mielivaltaiset etuliitteet ja molempien sanastojen ratkeamisen yhteen kanoniseen nimitauluun. Tästä työstä hyötyvät sekä tavalliset tiedostot että tiukat, koska kolmannen osapuolen generaattorit sitovat etuliitteet vapaasti, ja se on sama koneisto, joka kuvataan artikkelissa OPC-suhteiden ratkaisu XLSX-paketeissa

Lyhyt tarkistuslista ennen tiukan tulosteen käyttöönottoa

Tarkista paketin avulla, ei Excelillä. Excel avaa molemmat muodot mielellään, joten onnistunut avaaminen ei todista mitään vaatimustenmukaisuudesta. Pura tulos zip-paketista ja varmista, että xl/workbook.xml ilmoittaa purl-nimiavaruuden, ettei mikään osa sisällä merkkijonoa schemas.openxmlformats.org/spreadsheetml, ja että suhdetyypit tiedostoissa _rels/.rels ja xl/_rels/workbook.xml.rels käyttävät tiukkoja muotoja

Avaa sitten tiedosto uudelleen HotXLS:n kautta ja vertaa arvoja, kaavoja, muotoja ja hyperlinkkejä lähteeseen. Takaisinlukutesti on ainoa halpa tapa todistaa, ettei käännös vahingoittanut sisältöä, ja se harjoittaa samalla lukupuolen normalisointia. Jos työkirjasi kantavat kaavioita, tarkista nekin, koska kaavio-osa on yksi säilytetyistä osista, jotka vaihtuvat uudelleenrakennettuun polkuun tiukassa tilassa

Tiukka tuloste, suvaitsevainen lukeminen ja häviötön säilytys ovat kaikki osa samaa OOXML-moottoria Delphille ja C++Builderille; täydellinen ominaisuusluettelo on sivulla HotXLS Delphi -laskentataulukkokomponentin sivulla