DOCX'e Gayri Resmi Bir Giriş

Microsoft Office'i kullanan yaklaşık bir milyar insanla DOCX formatı, ofisler arasında belge dosyalarının değişimi için en popüler fiili standarttır. En yakın rakibi olan ODT formatı, yalnızca Open/LibreOffice ve bazı açık kaynaklı ürünler tarafından desteklenir ve bu da onu standart olmaktan çıkarır. PDF formatı bir rakip değildir çünkü PDF'ler düzenlenemez ve tam bir belge yapısı içermezler, bu nedenle filigranlar, imzalar ve benzeri gibi yalnızca sınırlı yerel değişiklikleri alabilirler. Bu nedenle çoğu iş belgesi DOCX biçiminde oluşturulur; onu değiştirmek için iyi bir alternatif yok.

DOCX karmaşık bir format olsa da, indeksleme, TXT'ye dönüştürme ve diğer küçük değişiklikleri yapma gibi daha basit görevler için onu manuel olarak ayrıştırmak isteyebilirsiniz. 5.000 sayfalık devasa bir kılavuz olan ECMA spesifikasyonlarına başvurmanıza gerek kalmaması için DOCX'in dahili bilgileri hakkında size yeterli bilgi vermek istiyorum.

Biçimi anlamanın en iyi yolu, MSWord ile tek kelimelik basit bir belge oluşturmak ve belgeyi düzenlemenin temeldeki XML'i nasıl değiştirdiğini gözlemlemektir. DOCX'in MS Word'de düzgün biçimlendirilmediği ve nedenini bilmediğiniz bazı durumlarla veya istenen biçimlendirmenin nasıl oluşturulacağının açık olmadığı durumlarla karşılaşacaksınız. XML'de tam olarak neler olduğunu görmek ve anlamak buna yardımcı olacaktır.

Yaklaşık bir yıl ortak bir DOCX editörü olan CollabOffice üzerinde çalıştım ve bu bilgilerin bir kısmını geliştirici topluluğuyla paylaşmak istiyorum. Bu yazımda internet üzerinde dağınık halde bulunan bilgileri özetleyerek DOCX dosya yapısını anlatacağım. Bu makale, devasa, karmaşık ECMA spesifikasyonu ile şu anda mevcut olan basit internet eğitimleri arasında bir aracıdır. Bu yazıya eşlik eden dosyaları github hesabımdaki toptal-docx projesinde bulabilirsiniz.

Basit bir DOCX dosyası

DOCX dosyası, XML dosyalarının bir ZIP arşividir. Yeni, boş bir Microsoft Word belgesi oluşturursanız, içine tek bir kelime 'Test' yazıp içeriğini açarsanız, aşağıdaki dosya yapısını göreceksiniz:

Basit bir belge oluşturmuş olmamıza rağmen, Microsoft Word'deki kaydetme işlemi varsayılan temaları, belge özelliklerini, yazı tipi tablolarını vb. XML biçiminde oluşturdu.

Başlamak için, kullanılmayan şeyleri kaldıralım ve ana metin öğelerini içeren document.xml odaklanalım. Bir dosyayı sildiğinizde, ona ilişkin tüm ilişki referanslarını diğer xml dosyalarından sildiğinizden emin olun. İşte app.xml ve core.xml bağımlılıklarını nasıl temizlediğime dair bir kod farkı örneği. Çözülmemiş/eksik referanslarınız varsa, MSWord dosyayı bozuk olarak kabul edecektir.

İşte basitleştirilmiş, minimal DOCX belgemizin yapısı (ve işte github'daki proje):

Buradan, yukarıdan dosyaya göre ayıralım:

_rels/.rels

Bu, MS Word'e belge içeriğinin nerede aranacağını söyleyen referansı tanımlar. Bu durumda, word/document.xml dosyasına başvurur:

 <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <Relationships xmlns="http://schemas.openxmlformats.org/package/2006/relationships"> <Relationship Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/officeDocument" Target="word/document.xml"/> </Relationships>

_rels/document.xml.rels

Bu dosya, belge içeriğine gömülü resimler gibi kaynaklara yapılan başvuruları tanımlar. Basit belgemizde gömülü kaynak bulunmadığından ilişki etiketi boştur:

 <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <Relationships xmlns="http://schemas.openxmlformats.org/package/2006/relationships"> </Relationships>

[Content_Types].xml

[Content_Types].xml , belge içindeki ortam türleri hakkında bilgi içerir. Yalnızca metin içeriğine sahip olduğumuz için oldukça basit:

 <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <Types xmlns="http://schemas.openxmlformats.org/package/2006/content-types"> <Default Extension="rels" ContentType="application/vnd.openxmlformats-package.relationships+xml"/> <Default Extension="xml" ContentType="application/xml"/> <Override PartName="/word/document.xml" ContentType="application/vnd.openxmlformats-officedocument.wordprocessingml.document.main+xml"/> </Types>

belge.xml

Son olarak, belgenin metin içeriğini içeren ana XML buradadır. Netlik için bazı ad alanı bildirimlerini kaldırdım, ancak dosyanın tam sürümünü github projesinde bulabilirsiniz. Bu dosyada, belgedeki bazı ad alanı referanslarının kullanılmadığını göreceksiniz, ancak MS Word'ün bunlara ihtiyacı olduğu için bunları silmemelisiniz.

İşte basitleştirilmiş örneğimiz:

 <w:document> <w:body> <w:pw:rsidR="005F670F" w:rsidRDefault="005F79F5"> <w:r><w:t>Test</w:t></w:r> </w:p> <w:sectPr w:rsidR="005F670F"> <w:pgSz w:w="12240" w:h="15840"/> <w:pgMar w:top="1440" w:right="1440" w:bottom="1440" w:left="1440" w:header="720" w:footer="720" w:gutter="0"/> <w:cols w:space="720"/> <w:docGrid w:linePitch="360"/> </w:sectPr> </w:body> </w:document>

<w:document> ana düğümü belgenin kendisini temsil eder, <w:body> paragrafları içerir ve <w:body> içinde iç içe geçmiş <w:sectPr> tarafından tanımlanan sayfa boyutlarıdır.

<w:rsidR> yok sayabileceğiniz bir niteliktir; MS Word içindekiler tarafından kullanılır.

Üç paragraflı daha karmaşık bir belgeye bakalım. Microsoft Word'ün ekran görüntüsünde XML'i aynı renklerle vurguladım, böylece korelasyonu görebilirsiniz:

<w:pw:rsidR="0081206C" w:rsidRDefault="00E10CAE">
<w:r> <w:t xml:space="preserve">Bu, örnek ilk paragrafımızdır. Varsayılan, sola hizalıdır ve şimdi size tanıtmak istiyorum</w:t> </w:r>
    <w:r> <w:rPr>
    <w:rFonts w:ascii="Arial" w:hAnsi="Arial" w:cs="Arial"/>
    <w:color w:val="000000"/>
    </w:rPr> <w:t>biraz kalın</w:t>
    </w:r>
    <w:r> <w:rPr>
    <w:rFonts w:ascii="Arial" w:hAnsi="Arial" w:cs="Arial"/>
    <w:b/> <w:color w:val="000000"/>
    </w:rPr> <w:t xml:space="preserve"> metin</w:t>
    </w:r>
    <w:r> <w:rPr> <w:rFonts w:ascii="Arial"
w:hAnsi="Arial" w:cs="Arial"/> <w:color w:val="000000"/> </w:rPr>
    <w:t xml:space="preserve">, </w:t>
    </w:r>
    <w:proofErr w:type="gramStart"/>
    <w:r> <w:t xml:space="preserve">ve ayrıca </w:t> </w:r>
    <w:rw:rsidRPr="00E10CAE"> <w:rPr><w:rFonts w:ascii="Etki" w:hAnsi="Etki"/>
    </w:rPr> <w:t>yazı tipi stili</w:t> </w:r>
    <w:r>
    <w:rPr> <w:rFonts w:ascii="Impact" w:hAnsi="Impact"/> </w:rPr> <w:t xml:space="preserve"> </w:t>
    </w:r>
    <w:r> <w:t>'Etki'ye.</w:t></w:r>
    </w:p>
    <w:pw:rsidR="00E10CAE" w:rsidRDefault="00E10CAE"> <w:r> <w:t>Bu yeni paragraf.</w:t> </w:r></w:p >
    <w:pw:rsidR="00E10CAE" w:rsidRPr="00E10CAE" w:rsidRDefault="00E10CAE">
    <w:r> <w:t>Bu bir paragraf daha, biraz daha uzun.</w:t> </w:r>
    </w:p>

Paragraf Yapısı

Basit bir belge paragraflardan, bir paragraf satırlardan (aynı yazı tipine, renge vb. sahip bir dizi metin) ve satırlardan ( <w:t> gibi) oluşur. <w:t> etiketlerinin içinde birkaç karakter olabilir ve aynı çalıştırmada birkaç karakter olabilir.

Yine, <w:rsidR> yok sayabiliriz.

Metin özellikleri

Temel metin özellikleri yazı tipi, boyut, renk, stil vb.'dir. Metin görünümünü belirleyen yaklaşık 40 etiket vardır. Üç paragraflı örneğimizde görebileceğiniz gibi, her çalıştırmanın <w:rPr> <w:color> , <w:rFonts> ve <w:b> cesurluğunu belirten kendi özellikleri vardır.

Unutulmaması gereken önemli bir nokta, özelliklerin normal ve karmaşık komut dosyası (örneğin Arapça) olmak üzere iki karakter grubu arasında bir ayrım yapması ve özelliklerin hangi karakter türünü etkilediğine bağlı olarak farklı bir etiketi olmasıdır.

Çoğu normal komut dosyası özellik etiketi, özelliğin karmaşık komut dosyaları için olduğunu belirten eklenmiş bir "C" ile eşleşen bir karmaşık komut dosyası etiketine sahiptir. Örneğin: <w:i> (italik) <w:iCs> olur ve normal komut dosyası için kalın etiket <w:b> karmaşık komut dosyası için <w:bCs> olur.

stiller

Microsoft Word'de stillere ayrılmış tam bir araç çubuğu vardır: normal, boşluksuz, başlık 1, başlık 2, başlık vb. Bu stiller /word/styles.xml içinde saklanır (not: basit örneğimizin ilk adımında, bu XML'i DOCX'ten kaldırdık. Bunu görmek için yeni bir DOCX oluşturun).

Metni bir stil olarak tanımladığınızda, bu stile referansı paragraf özellikleri etiketinin içinde bulacaksınız, <w:pPr> . İşte metnimi Başlık 1 stiliyle tanımladığım bir örnek:

 <w:p> <w:pPr> <w:pStyle w:val="Heading1"/> </w:pPr> <w:r> <w:t>My heading 1</w:t> </w:r> </w:p>

ve burada styles.xml stilin kendisi:

 <w:style w:type="paragraph" w:style> <w:name w:val="heading 1"/> <w:basedOn w:val="Normal"/> <w:next w:val="Normal"/> <w:link w:val="Heading1Char"/> <w:uiPriority w:val="9"/> <w:qFormat/> <w:rsid w:val="002F7F18"/> <w:pPr> <w:keepNext/> <w:keepLines/> <w:spacing w:before="480" w:after="0"/> <w:outlineLvl w:val="0"/> </w:pPr> <w:rPr> <w:rFonts w:asciiTheme="majorHAnsi" w:eastAsiaTheme="majorEastAsia" w:hAnsiTheme="majorHAnsi" w:cstheme="majorBidi"/> <w:b/> <w:bCs/> <w:color w:val="365F91" w:themeColor="accent1" w:themeShade="BF"/> <w:sz w:val="28"/> <w:szCs w:val="28"/> </w:rPr> </w:style>

<w:style/w:rPr/w:b> xpath yazı tipinin kalın olduğunu ve <w:style/w:rPr/w:color> yazı tipi rengini belirtir. <w:basedOn> , MSWord'a eksik özellikler için "Normal" stili kullanma talimatı verir.

Mülkiyet Mirası

Metin özellikleri miras alınır. Bir çalıştırmanın kendi özellikleri vardır ( w:p/w:r/w:rPr/* ), ancak aynı zamanda paragraftan ( w:r/w:pPr/* ) özellikleri devralır ve her ikisi de /word/styles.xml öğesinden stil özelliklerine başvurabilir /word/styles.xml .

 <w:r> <w:rPr> <w:rStyle w:val="DefaultParagraphFont"/> <w:sz w:val="16"/> </w:rPr> <w:tab/> </w:r>

Paragraflar ve çalıştırmalar varsayılan özelliklerle başlar: w:styles/w:docDefaults/w:rPrDefault/* ve w:styles/w:docDefaults/w:pPrDefault/* . Bir karakterin özelliklerinin sonucunu almak için şunları yapmalısınız:

1. Varsayılan çalıştırma/paragraf özelliklerini kullan
2. Çalışma/paragraf stili özelliklerini ekle
3. Yerel çalıştırma/paragraf özelliklerini ekle
4. Paragraf özellikleri üzerine sonuç çalıştırma özelliklerini ekle

B'yi A'ya "ekle" dediğimde, tüm B özelliklerini yinelemeyi ve tüm A'nın özelliklerini geçersiz kılmayı, kesişmeyen tüm özellikleri olduğu gibi bırakmayı kastediyorum.

Varsayılan özelliklerin bulunabileceği bir yer daha, w:type="paragraph" ve w:default="1" ile <w:style> etiketindedir. Bir çalıştırma içindeki karakterlerin hiçbir zaman varsayılan bir stile sahip olmadığına dikkat edin, bu nedenle <w:style w:type="character" w:default="1"> aslında herhangi bir metni etkilemez.

1554402290400-dbb29eef3ba6035df7ad726dfc99b2af.png)

Özellikleri değiştir

Özelliklerden bazıları, <w:b> (kalın) veya <w:i> (italik) gibi "geçiş" özellikleridir; bu nitelikler bir XOR operatörü gibi davranır.

Bu, ana stil kalınsa ve alt çalıştırma kalınsa, sonucun normal, kalın olmayan metin olacağı anlamına gelir.

Geçiş niteliklerini doğru bir şekilde işlemek için çok sayıda test ve tersine mühendislik yapmanız gerekir. Geçiş özelliklerine ilişkin resmi, ayrıntılı kuralları almak için ECMA-376 Açık XML belirtiminin 17.7.3 paragrafına bakın/

yazı tipleri

Fontlar, diğer metin öznitelikleri ile aynı ortak kuralları takip eder, ancak font özelliği varsayılan değerleri, word/_rels/document.xml.rels altında şu şekilde referans verilen ayrı bir tema dosyasında belirtilir:

 <Relationship Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/theme" Target="theme/theme1.xml"/>

Yukarıdaki referansa dayalı olarak, varsayılan yazı tipi adı word/theme/themes1.xml içinde, bir <a:theme> etiketi, a:themeElements/a:fontScheme/a:majorFont veya a:minorFont etiketi içinde bulunacaktır.

w:docDefaults/w:rPrDefault etiketi eksik olmadığı sürece varsayılan yazı tipi boyutu 10'dur, bu durumda boyut 11'dir.

Metin hizalama

Metin hizalaması, mevcut dört w:val modu olan bir <w:jc> etiketi ile belirlenir: "left" , "center" , "right" ve "both" .

"left" varsayılan moddur; metin, paragraf dikdörtgeninin solundan başlar (genellikle sayfa genişliği). (Bu paragraf standart olan sola hizalanmıştır.)

"center" modu, tahmin edilebileceği gibi, tüm karakterleri sayfa genişliği içinde ortalar. (Yine, bu paragraf ortalanmış hizalamayı örneklemektedir.)

"right" modda, paragraf metni sağ kenar boşluğuna hizalanır. (Bu metnin sağ tarafa nasıl hizalandığına dikkat edin.)

"both" modu, satırlar genişleyecek ve sola hizalanmış son satır dışında tam paragraf genişliğini kaplayacak şekilde kelimeler arasına fazladan boşluk koyar. (Bu paragraf bunun bir göstergesidir.)

Görüntüler

DOCX iki tür görüntüyü destekler: satır içi ve kayan.

Satır içi görüntüler diğer karakterlerle birlikte bir paragraf içinde görünür, < <w:t> (metin) yerine <w:drawing> kullanılır. Aşağıdaki xpath sözdizimi ile resim kimliğini bulabilirsiniz:

w:drawing/wp:inline/a:graphic/a:graphicData/pic:pic/pic:blipFill/a:blip/@r:embed

Görüntü kimliği, word/_rels/document.xml.rels dosyasındaki dosya adını aramak için kullanılır ve word/media alt klasörünün içindeki gif/jpeg dosyasını göstermelidir. (Görüntü kimliğini görebileceğiniz github projesinin word/_rels/document.xml.rels dosyasına bakın.)

Kayan görüntüler, etraflarında metin akan paragraflara göre yerleştirilir. (İşte kayan bir resim içeren th github proje örnek belgesi.)

Kayan resimler <w:drawing> yerine <wp:anchor> kullanır, bu nedenle <w:p> içindeki herhangi bir metni silerseniz, resimlerin kaldırılmasını istemiyorsanız bağlantılara dikkat edin.

tablolar

Tablolar için XML etiketleri, HTML tablo işaretlemesine benzer– <tablo> ile aynıdır, <tr> vb. ile eşleşir.

<w:tbl> , tablonun kendisi, <w:tblPr> tablo özelliklerine sahiptir ve her sütun özelliği <w:gridCol> içinde <w:tblGrid> tarafından sunulur. Satırlar birer birer <w:tr> etiketleri olarak takip edilir ve her satır <w:tblGrid> içinde belirtilen sayıda sütuna sahip olmalıdır:

 <w:tbl> <w:tblPr> <w:tblW w:w="5000" w:type="pct" /> </w:tblPr> <w:tblGrid><w:gridCol/><w:gridCol/></w:tblGrid> <w:tr> <w:tc><w:p><w:r><w:t>left</w:t></w:r></w:p></w:tc> <w:tc><w:p><w:r><w:t>right</w:t></w:r></w:p></w:tc> </w:tr> </w:tbl>

Tablo sütunlarının genişliği <w:tblW> etiketinde belirtilebilir, ancak bunu tanımlamazsanız MS Word, en küçük etkin tablo boyutu için en uygun sütun genişliğini bulmak için kendi dahili algoritmalarını kullanır.

Birimler

DOCX içindeki birçok XML özelliği, boyutları veya mesafeleri belirtir. XML içinde tamsayılar olmalarına rağmen, hepsinin farklı birimleri vardır, bu nedenle bazı dönüşümler gereklidir. Konu karmaşık, bu yüzden Lars Corneliussen'in DOCX dosyalarındaki birimlerle ilgili bu makalesini tavsiye ederim. Sunduğu tablo, küçük bir baskı hatasıyla da olsa kullanışlıdır: inç, pt*72 değil pt/72 olmalıdır.

İşte bir hile sayfası:

Bir Düzen Uygulamak için İpuçları

Bir DOCX dosyasını (örneğin PDF'ye) dönüştürmek, tuval üzerine çizmek veya sayfa sayısını saymak istiyorsanız, bir düzenleyici uygulamanız gerekir. Düzenleyici, bir DOCX dosyasından karakter konumlarını hesaplamak için bir algoritmadır.

Yüzde 100 aslına uygun işlemeye ihtiyacınız varsa, bu karmaşık bir iştir. İyi bir düzenleyiciyi uygulamak için gereken süre adam-yıl olarak ölçülür, ancak yalnızca basit, sınırlı bir düzene ihtiyacınız varsa, nispeten hızlı bir şekilde yapılabilir.

Düzenleyici, genellikle sayfanın bir dikdörtgeni olan bir üst dikdörtgeni doldurur. Bir koşudan kelimeleri tek tek ekler. Mevcut hat taştığında yenisini başlatır. Paragraf, ana dikdörtgen için çok yüksekse, sonraki sayfaya kaydırılır.

Düzenleyici uygulamaya karar verirseniz aklınızda bulundurmanız gereken bazı önemli noktalar şunlardır:

• Düzenleyici, metin hizalamasına ve görüntülerin üzerinde kayan metinlere dikkat etmelidir.
• İç içe tablolar gibi iç içe nesneleri işleyebilmelidir.
• Bu tür görüntüler için tam destek sağlamak istiyorsanız, en az iki geçişli bir düzenleyici uygulamanız gerekir, ilk adım kayan görüntülerin konumlarını toplar ve ikinci adım boş alanı metin karakterleriyle doldurur.
• Girintilere ve boşluklara dikkat edin. Her paragrafın öncesinde ve sonrasında boşluk vardır ve bu sayılar w:spacing etiketi ile belirtilir. Dikey boşluk, w:after ve w:before etiketleriyle belirlenir. Satır aralığının w:line tarafından belirtildiğini unutmayın, ancak bu, beklendiği gibi satırın boyutu değildir. Çizginin boyutunu elde etmek için mevcut yazı tipi yüksekliğini alın, w:line ile çarpın ve 12'ye bölün.
• DOCX dosyaları sayfalama hakkında hiçbir bilgi içermez. Sayfa sayısını belirlemek için her satır için ne kadar alana ihtiyacınız olduğunu hesaplamazsanız, belgedeki sayfa sayısını bulamazsınız. Sayfadaki her karakterin tam koordinatlarını bulmanız gerekiyorsa, tüm boşlukları, girintileri ve boyutları dikkate aldığınızdan emin olun.
• Tabloları işleyen tam özellikli bir DOCX düzenleyici uygularsanız, tabloların birden çok sayfaya yayıldığı özel durumlara dikkat edin. Sayfa taşmasına neden olan bir hücre, diğer hücreleri de etkiler.
• Bir tablo sütunlarının genişliğini hesaplamak için optimal bir algoritma oluşturmak zorlu bir matematik problemidir ve kelime işlemciler ve düzenleyiciler genellikle bazı optimal olmayan uygulamaları kullanır. İlk yaklaşım olarak W3C HTML tablo belgelerindeki algoritmayı kullanmayı öneriyorum. MS Word tarafından kullanılan algoritmanın bir tanımını bulamadım ve Microsoft zaman içinde algoritmaya ince ayar yaptı, böylece Word'ün farklı sürümleri tabloları biraz farklı şekilde düzenleyebilir.

Bir şey net değilse: XML'de tersine mühendislik yapın!

MS Word'de şu veya bu XML etiketinin nasıl çalıştığı açık olmadığında, bunu çözmek için iki ana yaklaşım vardır:

• İstediğiniz içeriği adım adım oluşturun. Basit bir docx dosyasıyla başlayın. Her adımı, örneğin 1.docx , 2.docx gibi kendi dosyasına kaydedin. Her birinin sıkıştırmasını açın ve değişikliklerinizden sonra hangi etiketlerin göründüğünü görmek için klasör karşılaştırması için görsel bir fark aracı kullanın. (Ticari bir seçenek için Araxis Merge'i veya ücretsiz bir seçenek için WinMerge'i deneyin.)

• MS Word'ün sevmediği bir DOCX dosyası oluşturursanız, geriye doğru çalışın. XML'inizi adım adım basitleştirin. Bir noktada, MS Word'ün hangi değişikliği yanlış bulduğunu öğreneceksiniz.

DOCX oldukça karmaşık, değil mi?

Karmaşıktır ve Microsoft'un lisansı, DOCX'i işlemek için sunucu tarafında MS Word'ün kullanılmasını yasaklar; bu, ticari ürünler için oldukça standarttır. Ancak Microsoft, çoğu DOCX etiketini işlemek için XSLT dosyasını sağlamıştır, ancak size yüzde 100, hatta yüzde 99 aslına uygunluk sağlamayacaktır. Resimlerin üzerine metin kaydırma gibi işlemler desteklenmez, ancak belgelerin çoğunu destekleyebileceksiniz. (Karmaşıklığa ihtiyacınız yoksa, alternatif olarak Markdown kullanmayı düşünün.)

Yeterli bir bütçeniz varsa (ücretsiz DOCX render motoru yok), Aspose veya docx4j gibi ticari ürünleri kullanmak isteyebilirsiniz. DOCX ve PDF dahil diğer formatlar arasında dönüştürme için en popüler ücretsiz çözüm LibreOffice'dir. Ne yazık ki, LibreOffice dönüştürme sırasında birçok küçük hata içeriyor ve karmaşık, açık kaynaklı bir C++ ürünü olduğundan, aslına uygunluk sorunlarını düzeltmek yavaş ve zordur.

Alternatif olarak, DOCX düzenini kendiniz uygulamak için çok karmaşık bulursanız, onu HTML'ye dönüştürebilir ve işlemek için bir tarayıcı kullanabilirsiniz. Toptal'ın serbest çalışan XML geliştiricilerinden birini de düşünebilirsiniz.

Daha fazla okuma için DOCX Kaynakları

• ECMA DOCX spesifikasyonu
• C#'tan DOCX manipülasyonu için OpenXML kitaplığı. Düzenleme veya kod oluşturma hakkında bilgi içermez, ancak DOCX'teki her olası XML düğümüyle eşleşen bir sınıf hiyerarşisi sunar.
• Her zaman docx4j, OpenXML ve docx gibi anahtar sözcüklerle yığın akışında arama yapabilir veya sorabilirsiniz; Toplumda bilgili insanlar var.