Kuna Microsoft Office'i kasutab umbes miljard inimest, on DOCX-vorming kõige populaarsem de facto standard dokumendifailide vahetamiseks kontorite vahel. Selle lähimat konkurenti - ODT-vormingut - toetavad ainult Open / LibreOffice ja mõned avatud lähtekoodiga tooted, mistõttu see pole kaugeltki standard. PDF-vorming ei ole konkurent, kuna PDF-faile ei saa redigeerida ja need ei sisalda täielikku dokumendistruktuuri, seega saavad nad teha vaid piiratud kohalikke muudatusi, näiteks vesimärgid, allkirjad jms. Seetõttu luuakse enamik äridokumente DOCX-vormingus; selle asendamiseks pole head alternatiivi.

Kuigi DOCX on keeruline vorming, võiksite selle käsitsi sõeluda lihtsamateks toiminguteks, näiteks indekseerimiseks, TXT-ks teisendamiseks ja muude väikeste muudatuste tegemiseks. Soovin teile anda piisavalt teavet DOCX-i sisemiste osade kohta, et te ei peaks viitama ECMA spetsifikatsioonidele, mis on mahukas 5000-leheküljeline kasutusjuhend.

Parim viis vormingu mõistmiseks on luua MSWordiga lihtne ühesõnaline dokument ja jälgida, kuidas dokumendi redigeerimine muudab selle aluseks olevat XML-i. Teid ootavad mõned juhtumid, kus DOCX ei vormindata MS Wordis õigesti ja te ei tea, miks, või võite kohata juhtumeid, kui pole selge, kuidas soovitud vormingut genereerida. XML-is toimuva nägemine ja mõistmine aitab seda.

Töötasin umbes aasta DOCX-i redigeerijaga, CollabOffice ja ma tahan jagada mõnda neist teadmistest arendajate kogukonnaga. Selles artiklis selgitan DOCX-failistruktuuri, võttes kokku Internetis hajutatud teabe. See artikkel on vahendaja ECMA tohutute ja keerukate spetsifikatsioonide ning praegu saadaolevate lihtsate Interneti-õpetuste vahel. Selle artikliga kaasnevad failid leiate jaotisest toptal-docx minu projekti githubi konto .

Lihtne DOCX-fail

DOCX-fail on XML-failide ZIP-arhiiv. Kui loote uue, tühja Microsoft Wordi dokumendi, kirjutate selle sisse ühe sõna „Test” ja pakkige selle sisu lahti, näete järgmist failistruktuuri:

Kuigi oleme loonud lihtsa dokumendi, on Microsoft Wordi salvestamisprotsess XML-vormingus loonud vaiketeemad, dokumendi atribuudid, fonditabelid ja nii edasi.

Kõik DOCX-is olevad failid on XML-failid, ka laiendiga .rels. Piiksuma

Alustuseks eemaldage kasutamata asjad ja keskenduge document.xml -le, mis sisaldab peamisi tekstielemente. Kui kustutate faili, veenduge, et olete kustutanud kõik selle XML-failidest sellele viited. Siin on kood-diff näide selle kohta, kuidas olen kustutanud sõltuvused rakendustest.xml ja core.xml. Kui teil on lahendamata / puuduvaid viiteid, loeb MSWord faili katki.

Siin on meie lihtsustatud, minimaalse DOCX-dokumendi (ja siin on githubi projekt ):

Jaotame selle failide kaupa siit, ülevalt:

_rels / .rels

See määratleb viite, mis ütleb MS Wordile, kust dokumendi sisu otsida. Sel juhul viitab see word/document.xml:

[Content_Types].xml

_rels / document.xml.rels

See fail määratleb viited dokumendi sisusse manustatud ressurssidele, näiteks piltidele. Meie lihtsal dokumendil pole manustatud ressursse, seega on suhtemärgend tühi:

Test

[Content_Types] .xml

/word/styles.xml sisaldab teavet dokumendis sisalduvate kandjate tüüpide kohta. Kuna meil on ainult teksti sisu, on see üsna lihtne:

My heading 1

document.xml

Lõpuks on siin peamine XML koos dokumendi tekstisisuga. Olen selguse huvides mõned nimeruumi deklaratsioonid eemaldanud, kuid faili täisversiooni leiate projektist github. Selles failis leiate, et mõned dokumendi nimeruumi viited on kasutamata, kuid te ei tohiks neid kustutada, kuna MS Word vajab neid.

Siin on meie lihtsustatud näide:

styles.xml

Põhikasutaja esitab dokumenti ise, sisaldab lõike ja pesitseb lehe mõõtmetega, mille on määratlenud.

on atribuut, mida saate ignoreerida; seda kasutavad MS Wordi sisemised.

Heidame pilgu keerulisemale dokumendile, millel on kolm lõiku. Olen Microsoft Wordi ekraanipildil esile tõstnud XML-i samade värvidega, nii et näete korrelatsiooni:

w:p/w:r/w:rPr/*

Lõigu struktuur

Lihtne dokument koosneb lõikudest, lõik koosneb jooksudest (sama fondi, värvi jms tekstiseeria) ja jooksud koosnevad märkidest (näiteks). Siltidel võib olla mitu märki ja neid võib olla vähe samas jooksus.

Jällegi võime ignoreerida.

Teksti atribuudid

Põhilised tekstiomadused on font, suurus, värv, stiil jne. Seal on umbes 40 silti, mis määravad teksti välimuse. Nagu näete meie kolme lõigu näites, on igal jooksul oma omadused, täpsustus ja julgus.

Oluline on märkida, et omadused teevad vahet kahel märgirühmal, tavalisel ja keerulisel skriptil (näiteks araabia keeles), ja omadustel on erinev silt sõltuvalt sellest, millist tähemärki see mõjutab.

Enamikul tavalistel skripti atribuutide siltidel on sobiv keerukas skripti silt, millele on lisatud täht C, mis täpsustab, et atribuut on mõeldud keerukate skriptide jaoks. Näiteks: (kursiiv) saab ja normaalse skripti paks silt muutub keerulise skripti jaoks.

Stiilid

Microsoft Wordis on stiilidele pühendatud terve tööriistariba: tavaline, tühikuteta, 1. pealkiri, 2. pealkiri, pealkiri jne. Need stiilid on salvestatud kataloogi w:r/w:pPr/* (märkus: meie lihtsa näite esimeses etapis eemaldasime selle XML-i DOCX-ist. Selle nägemiseks tehke uus DOCX).

Kui tekst on stiilina määratletud, leiate viite sellele stiilile lõigu omaduste sildilt. Siin on näide, kus olen määranud oma teksti stiiliga Päis 1:

/word/styles.xml

ja siin on stiil ise w:styles/w:docDefaults/w:rPrDefault/*

w:styles/w:docDefaults/w:pPrDefault/*

Thexpath määrab, et font on rasvane, ja osutab fondi värvile. Juhendab MSWordi kasutama puuduvate omaduste jaoks stiili “Normal”.

Vara pärimine

Teksti atribuudid on päritud. Jooksul on oma omadused (w:type='paragraph'), kuid see pärib omadused ka paragrahvist (w:default='1') ja mõlemad võivad viidata stiili omadustele word/_rels/document.xml.rels

word/theme/themes1.xml

Lõigud ja jooksud algavad vaikeatribuutidega: a:themeElements/a:fontScheme/a:majorFont ja a:minorFont. Märkide omaduste lõpptulemuse saamiseks peate tegema järgmist.

1. Kasutage run / paragrahvi vaikeatribuute
2. Lisa jooksu / lõigu stiili atribuudid
3. Lisage kohaliku käitamise / lõigu atribuudid
4. Lisage tulemuste käitamise atribuudid lõigu omaduste kohale

Kui ütlen B-le A-le lisada, mõtlen ma kõigi B-omaduste kordamist ja kõigi A-omaduste tühistamist, jättes kõik ristumatud omadused muutumatuks.

Veel üks koht, kus vaikeatribuudid võivad asuda, on w:docDefaults/w:rPrDefault -ga märgistatud sildil ja w:val. Pange tähele, et jooksu sees olevatel märkidel endil pole kunagi vaikestiili, see ei mõjuta tegelikult ühtegi teksti.

Piiksuma

1554402290400-dbb29eef3ba6035df7ad726dfc99b2af.png)

Jooksul olevad tähemärgid võivad pärida selle paragrahvist ja mõlemad pärida saidilt styles.xml.

Lülita atribuudid

Mõned atribuudid on „lülitatavad” omadused, näiteks (paksus kirjas) või (kursiivis); need atribuudid käituvad nagu XOR-operaator.

See tähendab, et kui vanemstiil on paks ja lapsejooks on julge, on tulemuseks tavaline paksus kirjas tekst.

Atribuutide õigeks ümberlülitamiseks peate tegema palju teste ja pöördprojekteerimist. Vaadake ECMA-376 Open XML-i spetsifikatsiooni punkti 17.7.3, et saada ametlikud ja üksikasjalikud reeglid omaduste vahetamiseks /

Lülitusomadused on paigutaja jaoks kõige keerukam õigesti käsitseda. Piiksuma

Fondid

Fondid järgivad samu ühiseid reegleid nagu muud tekstiatribuudid, kuid fondi omaduste vaikeväärtused on määratud eraldi teemafailis, millele viidatakse jaotises 'left' nagu nii:

'center'

Eeltoodud viite põhjal leitakse vaikefondi nimi 'right', atagis, 'both' või 'left' silt.

Vaikefondi suurus on 10, välja arvatud juhul, kui 'center' silt puudub, siis on see suurus 11.

Teksti joondamine

Teksti joondamine määratakse atagiga nelja 'right' -ga saadaolevad režiimid: 'both', w:drawing/wp:inline/a:graphic/a:graphicData/pic:pic/pic:blipFill/a:blip/@r:embed, word/_rels/document.xml.rels ja word/_rels/document.xml.rels.

left right on vaikerežiim; teksti alustatakse lõik ristkülikust vasakul (tavaliselt lehe laius). (See lõik on joondatud vasakule, mis on standardne.)

w:spacing režiim keskendab ettearvatult kõik märgid lehe laiuse sisse. (See lõik on jällegi keskse joondamise näide.)

Aastal w:after režiimis on lõigu tekst joondatud parema veerise külge. (Pange tähele, kuidas see tekst on paremale küljele joondatud.)

w:before režiim paneb sõnade vahele lisavahe, nii et read muutuvad laiemaks ja hõivavad kogu lõigu laiuse, välja arvatud viimane rida, mis on vasakule joondatud. (See lõik on selle näide.)

Kujutised

DOCX toetab kahte tüüpi pilte: sisse- ja hõljuvaid.

Reasisesed pildid kuvatakse koos teiste tähemärkidega lõigu sees, kasutatakse (teksti) asemel. Pildi ID leiate järgmise xpath-süntaksiga:

w:line

Pildi ID-d kasutatakse failinime otsimiseks kaustast w:line fail ja see peaks osutama sõna / meedia alamkaustas olevale gif / jpeg-failile. (Vaadake githubi projekti 1.docx faili, kus näete pildi ID-d.)

Ujuvad pildid paigutatakse lõikude suhtes, mille ümber voolab tekst. (Siin on githubi projekt näidisdokument ujuva pildiga.)

Ujuvad pildid on kasutusel, nii et kui kustutate teksti, siis olge ankrutega ettevaatlik, kui te ei soovi pilte eemaldada.

MS Wordi pildivalikud viitavad pildi joondamisele kui 'teksti mähkimisrežiimile'.

Tabelid

Tabelite XML-märgendid sarnanevad HTML-i tabelite märgistustega - on samad, mis

, sobib, jne.

, tabel ise omab tabeli omadusi ja iga veeru omadus esitatakse sisemiselt. Ridad järgnevad ükshaaval tähtedele ja igal real peaks olema sama arv veerge, nagu on määratletud jaotises:

2.docx

Tabeliveergude laiuse saab määrata sildil, kuid kui te seda ei määratle, kasutab MS Word oma sisemisi algoritme, et leida optimaalne veergude laius väikseima efektiivse tabeli suuruse jaoks.

Ühikud

Paljud XML-atribuudid DOCX-is määravad suurused või vahemaad. Kuigi nad on XML-is täisarvud, on neil kõigil erinevad ühikud, nii et mõningane teisendamine on vajalik. Teema on keeruline, nii et soovitaksin see Lars Corneliusseni artikkel DOCX-failide üksuste kohta . Tema esitatud tabel on kasulik, ehkki väikese vale trükiga: tollid peaksid olema pt / 72, mitte pt * 72.

Siin on petuväli:

ÜHISED DOCX XML-ÜHENDUSTE TEISENDAMISED
	20. punkt	Punktid dxa / 20	Tolli pt / 72	Sentimeetrid aastal * 2,54	Fondi pool suurus pt / 144	EMU aastal * 914400
Näide	11906	595,3	8.27 ...	21 00086 ...	4,135	7562088
Seda kasutavad sildid	pgSz / pgMar / w: vahekaugus				aastal: sz	wp: ulatus, a: ekst

Näpunäited paigutuse rakendamiseks

Kui soovite teisendada DOCX-faili (näiteks PDF-failiks), joonistada see lõuendile või loendada lehtede arvu, peate juurutama paigutuse. Paigutus on algoritm märkide positsioonide arvutamiseks DOCX-failist.

See on keeruline ülesanne, kui vajate 100-protsendilist truuduse renderdamist. Hea küljendaja rakendamiseks kuluvat aega mõõdetakse inim-aastates, kuid kui vajate ainult lihtsat, piiratud, saab selle suhteliselt kiiresti teha.

Küljendaja täidab vanema ristküliku, mis on tavaliselt lehe ristkülik. See lisab jooksult sõnu ükshaaval. Kui praegune rida on üle voolanud, alustab see uut. Kui lõik on vanema ristküliku jaoks liiga kõrge, mähitakse see järgmisele lehele.

Paigutaja juurutamise otsustamisel peate meeles pidama järgmisi olulisi asju.

• Küljendaja peaks hoolitsema teksti joondamise ja piltide kohal hõljuva teksti eest
• See peaks olema võimeline käsitsema pesastatud objekte, näiteks pesastatud tabeleid
• Kui soovite sellistele piltidele täielikku tuge pakkuda, peate juurutama vähemalt kahe käiguga paigutuse, esimene samm kogub hõljuvate piltide asukohad ja teine ​​täidab tühja ruumi tekstimärkidega.
• Olge teadlik süvenditest ja vahekaugustest. Igal lõigul on enne ja pärast tühikud ning need numbrid määratakse
  abil silt. Vertikaalse vahekauguse määrab
  ja
  sildid. Pange tähele, et reavahe määrab

  |_+_|

  , kuid see pole rea suurus, nagu võib eeldada. Rea suuruse saamiseks võtke praegune fondi kõrgus, korrutage

    This is our example first paragraph. It's default is left aligned, and now I'd like to introduce   some bold text ,   and also change the   font style   to 'Impact'.   This is new paragraph.   This is one more paragraph, a bit longer.  

  -ga ja jagage 12-ga.
• DOCX-failid ei sisalda teavet lehitsemise kohta. Te ei leia dokumendis lehtede arvu, kui te ei arvuta, kui palju ruumi on vaja iga rea ​​jaoks lehtede arvu kindlakstegemiseks. Kui peate lehel leidma iga märgi täpsed koordinaadid, võtke kindlasti arvesse kõiki vahesid, taandeid ja suurusi.
• Kui rakendate täisfunktsionaalset DOCX-paigutust, mis haldab tabeleid, pange tähele erijuhtumeid, kui tabelid hõlmavad mitut lehte. Lahter, mis põhjustab lehe ületäitumise, mõjutab ka teisi rakke.
• Tabeliveergude laiuse arvutamiseks optimaalse algoritmi loomine on keeruline matemaatikaülesanne ning tekstitöötlejad ja küljendajad kasutavad tavaliselt mõnda optimaalsemat rakendust. Teen ettepaneku kasutada algoritm W3C HTML-ist esimese ligikaudsena tabeli dokumentatsioon. Ma pole leidnud MS Wordi kasutatud algoritmi kirjeldust ja Microsoft on algoritmi aja jooksul täpsustanud, nii et Wordi erinevad versioonid võivad tabeleid paigutada veidi erinevalt.

Kui midagi on ebaselge: muutke XML-i vastupidiseks!

Kui pole selge, kuidas see või teine ​​XML-märgend MS Wordis töötab, on selle välja selgitamiseks kaks peamist lähenemist:

• Looge soovitud sisu samm-sammult. Alustage lihtsast docx-failist. Salvestage iga samm oma faili, nagu näiteks jaotistes

  |_+_|

  ,
  Pakkige need lahti ja kasutage kaustade võrdlemiseks visuaalset diff-tööriista, et näha, millised sildid kuvatakse pärast teie muudatusi. (Kaubandusliku valiku jaoks proovige Araxis Merge'i või tasuta valiku WinMerge jaoks.)

• Kui loote DOCX-faili, mis MS Wordile ei meeldi, töötage tagurpidi. Lihtsustage oma XML-i samm-sammult. Ühel hetkel saate teada, millise muudatuse MS Word valeks leidis.

DOCX on üsna keeruline, kas pole?

See on keeruline ja Microsofti litsents keelab DOCX-i töötlemiseks kasutada serveri poolel MS Wordi - see on kommertstoodete jaoks üsna tavaline. Microsoft on siiski andnud XSLT-fail enamiku DOCX-i siltide käsitsemiseks, kuid see ei anna teile 100 või isegi 99-protsendilist truudust. Protsesse, nagu piltide ümber mähkimine, ei toetata, kuid saate toetada enamikku dokumente. (Kui te ei vaja keerukust, kaaluge kasutamist Märgistamine alternatiivina.)

Kui teil on piisav eelarve (tasuta DOCX-renderdamismootorit pole), võiksite kasutada selliseid kommertstooteid nagu Aspose või docx4j. Kõige populaarsem tasuta lahendus on LibreOffice DOCX-i ja teiste formaatide, sealhulgas PDF-failide vahel teisendamiseks. Kahjuks sisaldab LibreOffice teisendamise ajal palju väikseid vigu ja kuna see on keeruline, avatud lähtekoodiga C ++ toode, on truudusprobleeme aeglane ja keeruline lahendada.

Teise võimalusena, kui leiate, et DOCX-i paigutus on teie enda rakendamiseks liiga keeruline, saate selle teisendada ka HTML-ks ja kasutada brauserit selle renderdamiseks. Võite kaaluda ka ühte järgmistest ApeeScape'i vabakutselised XML-i arendajad .

DOCXi ressursid edasiseks lugemiseks

• ECMA DOCX spetsifikatsioon
• OpenXML-i teek DOCX-i manipuleerimiseks alates C #. See ei sisalda koodi paigutuse ega renderdamise teavet, kuid pakub klassi hierarhiat, mis sobib DOCX-i kõigi võimalike XML-sõlmedega.
• Alati saab otsige või küsige virnaülekandes märksõnadega nagu docx4j, OpenXML ja docx; kogukonnas on inimesi, kes on teadlikud.