ด้วยผู้คนประมาณหนึ่งพันล้านคนที่ใช้ Microsoft Office รูปแบบ DOCX จึงเป็นมาตรฐานโดยพฤตินัยที่ได้รับความนิยมมากที่สุดสำหรับการแลกเปลี่ยนไฟล์เอกสารระหว่างสำนักงาน คู่แข่งที่ใกล้เคียงที่สุด - รูปแบบ ODT - รองรับเฉพาะ Open / LibreOffice และผลิตภัณฑ์โอเพนซอร์สบางอย่างเท่านั้นซึ่งทำให้อยู่ไกลจากมาตรฐาน รูปแบบ PDF ไม่ใช่คู่แข่งเนื่องจากไม่สามารถแก้ไข PDF ได้และไม่มีโครงสร้างเอกสารทั้งหมดดังนั้นจึงสามารถทำการเปลี่ยนแปลงในท้องถิ่นได้อย่าง จำกัด เช่นลายน้ำลายเซ็นและสิ่งที่คล้ายกัน นี่คือสาเหตุที่เอกสารทางธุรกิจส่วนใหญ่สร้างในรูปแบบ DOCX ไม่มีทางเลือกอื่นที่ดีในการแทนที่
แม้ว่า DOCX จะเป็นรูปแบบที่ซับซ้อน แต่คุณอาจต้องการแยกวิเคราะห์ด้วยตนเองสำหรับงานที่ง่ายกว่าเช่นการจัดทำดัชนีการแปลงเป็น TXT และการแก้ไขขนาดเล็กอื่น ๆ ฉันต้องการให้ข้อมูลเพียงพอเกี่ยวกับ DOCX ภายในดังนั้นคุณจึงไม่ต้องอ้างอิงข้อกำหนด ECMA ซึ่งเป็นคู่มือขนาดใหญ่ 5,000 หน้า
วิธีที่ดีที่สุดในการทำความเข้าใจรูปแบบคือการสร้างเอกสารคำเดียวง่ายๆด้วย MSWord และสังเกตว่าการแก้ไขเอกสารเปลี่ยนแปลง XML ที่อยู่เบื้องหลังอย่างไร คุณจะต้องเผชิญกับบางกรณีที่ DOCX ไม่ได้จัดรูปแบบอย่างถูกต้องใน MS Word และคุณไม่รู้สาเหตุหรือเจอกรณีที่ไม่สามารถระบุวิธีสร้างการจัดรูปแบบที่ต้องการได้ การมองเห็นและเข้าใจสิ่งที่เกิดขึ้นใน XML จะช่วยได้
ฉันทำงานร่วมกับโปรแกรมแก้ไข DOCX ที่ทำงานร่วมกันมาประมาณหนึ่งปี CollabOffice และฉันต้องการแบ่งปันความรู้บางส่วนกับชุมชนนักพัฒนาซอฟต์แวร์ ในบทความนี้ฉันจะอธิบายโครงสร้างไฟล์ DOCX โดยสรุปข้อมูลที่กระจัดกระจายอยู่บนอินเทอร์เน็ต บทความนี้เป็นสื่อกลางระหว่างข้อกำหนด ECMA ขนาดใหญ่ที่ซับซ้อนและบทแนะนำทางอินเทอร์เน็ตแบบง่ายๆที่มีอยู่ในปัจจุบัน คุณสามารถค้นหาไฟล์ที่มาพร้อมกับบทความนี้ได้ใน toptal-docx โครงการของฉัน บัญชี github .
ไฟล์ DOCX อย่างง่าย
ไฟล์ DOCX เป็นไฟล์ ZIP ของไฟล์ XML หากคุณสร้างเอกสาร Microsoft Word ใหม่ที่ว่างเปล่าเขียนคำว่า 'Test' เพียงคำเดียวภายในและคลายซิปเนื้อหาคุณจะเห็นโครงสร้างไฟล์ต่อไปนี้:
แม้ว่าเราจะสร้างเอกสารอย่างง่าย แต่กระบวนการบันทึกใน Microsoft Word ได้สร้างธีมเริ่มต้นคุณสมบัติของเอกสารตารางแบบอักษรและอื่น ๆ ในรูปแบบ XML
ไฟล์ทั้งหมดใน DOCX เป็นไฟล์ XML แม้กระทั่งไฟล์ที่มีนามสกุล '.rels' ทวีตในการเริ่มต้นให้เราลบสิ่งที่ไม่ได้ใช้และเน้นที่ document.xml ซึ่งมีองค์ประกอบข้อความหลัก เมื่อคุณลบไฟล์ตรวจสอบให้แน่ใจว่าคุณได้ลบการอ้างอิงความสัมพันธ์ทั้งหมดออกจากไฟล์ xml อื่น ๆ นี่คือตัวอย่างรหัสแตกต่าง เกี่ยวกับวิธีที่ฉันล้างการอ้างอิงกับ app.xml และ core.xml หากคุณมีข้อมูลอ้างอิงที่ยังไม่ได้รับการแก้ไข / ขาดหายไป MSWord จะพิจารณาว่าไฟล์เสีย
นี่คือโครงสร้างของเอกสาร DOCX ที่เรียบง่ายและเรียบง่ายของเรา (และ นี่คือโครงการบน github ):
มาแยกย่อยทีละไฟล์จากด้านบน:
_rels / .rels
สิ่งนี้กำหนดการอ้างอิงที่บอก MS Word ว่าจะค้นหาเนื้อหาของเอกสารได้ที่ไหน ในกรณีนี้จะอ้างอิง word/document.xml:
[Content_Types].xml_rels / document.xml.rels
ไฟล์นี้กำหนดการอ้างอิงถึงรีซอร์สเช่นรูปภาพที่ฝังอยู่ในเนื้อหาเอกสาร เอกสารอย่างง่ายของเราไม่มีทรัพยากรที่ฝังอยู่ดังนั้นแท็กความสัมพันธ์จึงว่างเปล่า:
วิธีการเริ่มโครงการ angularjs
Test [Content_Types] .xml
/word/styles.xml มีข้อมูลเกี่ยวกับประเภทของสื่อในเอกสาร เนื่องจากเรามีเพียงเนื้อหาข้อความจึงค่อนข้างง่าย:
My heading 1 document.xml
สุดท้ายนี่คือ XML หลักที่มีเนื้อหาข้อความของเอกสาร ฉันได้ลบการประกาศเนมสเปซบางส่วนเพื่อความชัดเจน แต่คุณสามารถค้นหาเวอร์ชันเต็มของไฟล์ได้ในโปรเจ็กต์ github ในไฟล์นั้นคุณจะพบว่าการอ้างอิงเนมสเปซบางส่วนในเอกสารนั้นไม่ได้ใช้งาน แต่คุณไม่ควรลบออกเนื่องจาก MS Word ต้องการ
นี่คือตัวอย่างที่เรียบง่ายของเรา:
styles.xmlตัวเลขหลักหมายถึงเอกสารเองมีย่อหน้าและซ้อนอยู่ภายในคือมิติของเพจที่กำหนดโดย
เป็นแอตทริบิวต์ที่คุณสามารถเพิกเฉยได้ มันถูกใช้โดย MS Word ภายใน
มาดูเอกสารที่ซับซ้อนมากขึ้นโดยมีสามย่อหน้า ฉันได้เน้น XML ด้วยสีเดียวกันบนภาพหน้าจอจาก Microsoft Word ดังนั้นคุณจะเห็นความสัมพันธ์:
w:p/w:r/w:rPr/*โครงสร้างย่อหน้า
เอกสารอย่างง่ายประกอบด้วยย่อหน้าย่อหน้าประกอบด้วยการเรียกใช้ (ชุดข้อความที่มีแบบอักษรสีเดียวกัน ฯลฯ ) และการรันประกอบด้วยอักขระ (เช่น) แท็กอาจมีอักขระหลายตัวอยู่ภายในและอาจมีไม่กี่ตัว ในการดำเนินการเดียวกัน
อีกครั้งเราสามารถเพิกเฉย
คุณสมบัติข้อความ
คุณสมบัติข้อความพื้นฐาน ได้แก่ แบบอักษรขนาดสีลักษณะและอื่น ๆ มีแท็กประมาณ 40 แท็กที่ระบุลักษณะข้อความ ดังที่คุณเห็นในตัวอย่างสามย่อหน้าของเราการรันแต่ละครั้งมีคุณสมบัติของตัวเองภายในการระบุและความหนา
สิ่งสำคัญที่ควรทราบคือคุณสมบัติจะสร้างความแตกต่างระหว่างอักขระ 2 กลุ่ม ได้แก่ สคริปต์ปกติและสคริปต์ที่ซับซ้อน (เช่นภาษาอาหรับ) และคุณสมบัติจะมีแท็กที่แตกต่างกันขึ้นอยู่กับประเภทของอักขระที่มีผลต่อ
แท็กคุณสมบัติสคริปต์ปกติส่วนใหญ่มีแท็กสคริปต์ที่ซับซ้อนที่ตรงกันโดยมี 'C' ที่เพิ่มเข้ามาเพื่อระบุคุณสมบัตินั้นมีไว้สำหรับสคริปต์ที่ซับซ้อน ตัวอย่างเช่น: (ตัวเอียง) กลายเป็นและแท็กตัวหนาสำหรับสคริปต์ปกติกลายเป็นสำหรับสคริปต์ที่ซับซ้อน
รูปแบบ
มีแถบเครื่องมือทั้งหมดใน Microsoft Word เฉพาะสำหรับรูปแบบ: ปกติไม่มีการเว้นวรรคส่วนหัว 1 ส่วนหัว 2 ชื่อและอื่น ๆ รูปแบบเหล่านี้ถูกเก็บไว้ใน w:r/w:pPr/* (หมายเหตุ: ในขั้นตอนแรกในตัวอย่างง่ายๆเราลบ XML นี้ออกจาก DOCX สร้าง DOCX ใหม่เพื่อดูสิ่งนี้)
เมื่อคุณกำหนดข้อความเป็นสไตล์แล้วคุณจะพบการอ้างอิงถึงสไตล์นี้ภายในแท็กคุณสมบัติย่อหน้า นี่คือตัวอย่างที่ฉันกำหนดข้อความของฉันด้วยสไตล์ Heading 1:
/word/styles.xmlและนี่คือสไตล์จาก w:styles/w:docDefaults/w:rPrDefault/*:
w:styles/w:docDefaults/w:pPrDefault/*Thexpath ระบุว่าฟอนต์เป็นตัวหนาและระบุสีฟอนต์สร้างคำสั่งให้ MSWord ใช้สไตล์“ Normal” สำหรับคุณสมบัติที่ขาดหายไป
การสืบทอดทรัพย์สิน
คุณสมบัติข้อความได้รับการสืบทอด การรันมีคุณสมบัติของตัวเอง (w:type='paragraph') แต่ยังสืบทอดคุณสมบัติจากย่อหน้า (w:default='1') และทั้งสองสามารถอ้างอิงคุณสมบัติสไตล์จาก word/_rels/document.xml.rels
word/theme/themes1.xmlย่อหน้าและรันเริ่มต้นด้วยคุณสมบัติเริ่มต้น: a:themeElements/a:fontScheme/a:majorFont และ a:minorFont. เพื่อให้ได้ผลลัพธ์สุดท้ายของคุณสมบัติของตัวละครคุณควร:
- ใช้คุณสมบัติรัน / ย่อหน้าเริ่มต้น
- ผนวกคุณสมบัติลักษณะการรัน / ย่อหน้า
- เพิ่มคุณสมบัติการรัน / ย่อหน้าในเครื่อง
- ผนวกคุณสมบัติการรันผลลัพธ์เหนือคุณสมบัติย่อหน้า
เมื่อฉันพูดว่า“ ผนวก” B กับ A ฉันหมายถึงการวนซ้ำผ่านคุณสมบัติ B ทั้งหมดและแทนที่คุณสมบัติของ A ทั้งหมดโดยปล่อยให้คุณสมบัติที่ไม่ตัดกันทั้งหมดตามที่เป็นอยู่
อีกหนึ่งสถานที่ที่คุณสมบัติเริ่มต้นอาจอยู่ในแท็กที่มี w:docDefaults/w:rPrDefault และ w:val. โปรดทราบว่าตัวละครภายในการวิ่งไม่เคยมีรูปแบบเริ่มต้นโซดาไม่มีผลกับข้อความใด ๆ
เรียนยาก
1554402290400-dbb29eef3ba6035df7ad726dfc99b2af.png)
อักขระในการรันสามารถสืบทอดจากย่อหน้าและทั้งสองสามารถสืบทอดจาก styles.xmlสลับคุณสมบัติ
คุณสมบัติบางอย่างเป็นคุณสมบัติ 'สลับ' เช่น (ตัวหนา) หรือ (ตัวเอียง); แอตทริบิวต์เหล่านี้ทำงานเหมือนตัวดำเนินการ XOR
ซึ่งหมายความว่าหากสไตล์พาเรนต์เป็นตัวหนาและการรันของเด็กเป็นตัวหนาผลลัพธ์จะเป็นข้อความปกติไม่ใช่ตัวหนา
คุณต้องทำการทดสอบและวิศวกรรมย้อนกลับจำนวนมากเพื่อจัดการแอตทริบิวต์การสลับอย่างถูกต้อง ดูที่ย่อหน้าที่ 17.7.3 ของข้อกำหนด ECMA-376 Open XML เพื่อรับกฎอย่างเป็นทางการโดยละเอียดสำหรับคุณสมบัติการสลับ /
คุณสมบัติการสลับเป็นสิ่งที่ซับซ้อนที่สุดสำหรับ Layouter ที่จะจัดการได้อย่างถูกต้อง ทวีตแบบอักษร
แบบอักษรเป็นไปตามกฎทั่วไปเช่นเดียวกับแอตทริบิวต์ข้อความอื่น ๆ แต่ค่าเริ่มต้นคุณสมบัติแบบอักษรจะระบุไว้ในไฟล์ธีมที่แยกจากกันซึ่งอ้างอิงภายใต้ 'left' แบบนี้:
'center'จากข้อมูลอ้างอิงข้างต้นชื่อฟอนต์เริ่มต้นจะอยู่ใน 'right', ภายใน atag, 'both' หรือ 'left' แท็ก
ขนาดฟอนต์เริ่มต้นคือ 10 ยกเว้น 'center' ไม่มีแท็กแสดงว่ามีขนาด 11
การจัดตำแหน่งข้อความ
การจัดแนวข้อความถูกระบุโดย atag ด้วยสี่ 'right' มีโหมด: 'both', w:drawing/wp:inline/a:graphic/a:graphicData/pic:pic/pic:blipFill/a:blip/@r:embed, word/_rels/document.xml.rels และ word/_rels/document.xml.rels.
left right เป็นโหมดเริ่มต้น ข้อความเริ่มต้นที่ด้านซ้ายของสี่เหลี่ยมผืนผ้าย่อหน้า (โดยปกติคือความกว้างของหน้า) (ย่อหน้านี้จัดชิดซ้ายซึ่งเป็นมาตรฐาน)
w:spacing โหมดคาดเดาได้ว่าจะจัดกึ่งกลางอักขระทั้งหมดให้อยู่ในความกว้างของหน้า (อีกครั้งย่อหน้านี้เป็นตัวอย่างการจัดตำแหน่งกึ่งกลาง)
ใน w:after โหมดข้อความย่อหน้าจะชิดขอบด้านขวา (สังเกตว่าข้อความนี้จัดชิดด้านขวาอย่างไร)
โหนด js เรียกส่วนที่เหลือ api
w:before โหมดเพิ่มระยะห่างระหว่างคำเพื่อให้บรรทัดกว้างขึ้นและใช้ความกว้างเต็มย่อหน้ายกเว้นบรรทัดสุดท้ายซึ่งจัดชิดซ้าย (ย่อหน้านี้เป็นการสาธิตสิ่งนั้น)
รูปภาพ
DOCX รองรับรูปภาพสองประเภท: อินไลน์และลอย
รูปภาพแบบอินไลน์จะปรากฏภายในย่อหน้าพร้อมกับอักขระอื่น ๆ ใช้แทนการใช้ (ข้อความ) คุณสามารถค้นหารหัสรูปภาพด้วยไวยากรณ์ xpath ต่อไปนี้:
w:line
รหัสรูปภาพใช้เพื่อค้นหาชื่อไฟล์ใน w:line และควรชี้ไปที่ไฟล์ gif / jpeg ภายในโฟลเดอร์ย่อย word / media (ดูไฟล์ 1.docx ของโปรเจ็กต์ github ซึ่งคุณสามารถดูรหัสรูปภาพได้)
ภาพลอยจะถูกวางโดยสัมพันธ์กับย่อหน้าที่มีข้อความไหลอยู่รอบ ๆ (นี่คือโครงการ github เอกสารตัวอย่าง ด้วยภาพลอย)
ใช้รูปภาพลอยแทนดังนั้นหากคุณลบข้อความใด ๆ ภายในโปรดระมัดระวังกับจุดยึดหากคุณไม่ต้องการให้นำรูปภาพออก
ตาราง
แท็ก XML สำหรับตารางคล้ายกับมาร์กอัปตาราง HTML ซึ่งเหมือนกับ
| การแปลงหน่วย XML DOCX ทั่วไป | ||||||
| จุดที่ 20 | คะแนน dxa / 20 | นิ้ว จุด / 72 | เซนติเมตร ใน * 2,54 | ขนาดตัวอักษรครึ่งหนึ่ง จุด / 144 | EMU ใน * 914400 | |
| ตัวอย่าง | 11906 | 595.3 | 8.27 ... | 21,00086 ... | 4,135 | 7562088 |
| แท็กโดยใช้สิ่งนี้ | pgSz / pgMar / w: ระยะห่าง | ใน: sz | wp: ขอบเขต a: ext | |||
เคล็ดลับในการติดตั้ง Layouter
หากคุณต้องการแปลงไฟล์ DOCX (เป็น PDF เป็นต้น) วาดบนผืนผ้าใบหรือนับจำนวนหน้าคุณจะต้องติดตั้ง Layouter Layouter คืออัลกอริทึมสำหรับคำนวณตำแหน่งอักขระจากไฟล์ DOCX
นี่เป็นงานที่ซับซ้อนหากคุณต้องการการเรนเดอร์ความเที่ยงตรง 100 เปอร์เซ็นต์ ระยะเวลาที่ต้องใช้ในการติดตั้ง Layouter ที่ดีนั้นวัดได้เป็นปีมนุษย์ แต่ถ้าคุณต้องการเพียงแบบเรียบง่ายและมีจำนวน จำกัด ก็สามารถทำได้ค่อนข้างเร็ว
เค้าโครงจะเติมสี่เหลี่ยมพาเรนต์ซึ่งโดยปกติจะเป็นรูปสี่เหลี่ยมผืนผ้าของหน้า เพิ่มคำจากการเรียกใช้ทีละคำ เมื่อบรรทัดปัจจุบันล้นบรรทัดจะเริ่มต้นใหม่ หากย่อหน้าสูงเกินไปสำหรับสี่เหลี่ยมผืนผ้าระดับบนสุดจะถูกรวมไว้ในหน้าถัดไป
ต่อไปนี้เป็นสิ่งสำคัญที่ควรทราบหากคุณตัดสินใจใช้ Layouter:
- ผู้จัดวางควรดูแลเกี่ยวกับการจัดแนวข้อความและข้อความที่ลอยอยู่เหนือรูปภาพ
- ควรสามารถจัดการกับวัตถุที่ซ้อนกันได้เช่นตารางที่ซ้อนกัน
- หากคุณต้องการให้การสนับสนุนอย่างเต็มที่สำหรับรูปภาพดังกล่าวคุณจะต้องใช้ Layouter ที่มีอย่างน้อยสองรอบขั้นตอนแรกจะรวบรวมตำแหน่งของรูปภาพลอยและขั้นที่สองเติมพื้นที่ว่างด้วยอักขระข้อความ
- ระวังการเยื้องและระยะห่าง แต่ละย่อหน้ามีระยะห่างก่อนและหลังและตัวเลขเหล่านี้ระบุโดย แท็ก ระยะห่างแนวตั้งถูกระบุโดย และ แท็ก โปรดทราบว่าระยะห่างระหว่างบรรทัดถูกระบุโดย
|_+_|
แต่นี่ไม่ใช่ขนาดของบรรทัดอย่างที่คาดหวัง เพื่อให้ได้ขนาดของเส้นให้ใช้ความสูงของแบบอักษรปัจจุบันคูณด้วย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.
แล้วหารด้วย 12 - ไฟล์ DOCX ไม่มีข้อมูลเกี่ยวกับการแบ่งหน้า คุณจะไม่พบจำนวนหน้าในเอกสารเว้นแต่คุณจะคำนวณว่าคุณต้องการพื้นที่เท่าใดสำหรับแต่ละบรรทัดเพื่อยืนยันจำนวนหน้า หากคุณต้องการค้นหาพิกัดที่แน่นอนของอักขระแต่ละตัวในหน้าให้แน่ใจว่าได้คำนึงถึงระยะห่างการเยื้องและขนาดทั้งหมด
- หากคุณใช้เค้าโครง DOCX แบบเต็มรูปแบบที่จัดการกับตารางโปรดสังเกตกรณีพิเศษเมื่อตารางครอบคลุมหลายหน้า เซลล์ที่ทำให้เพจล้นยังส่งผลต่อเซลล์อื่นด้วย
- การสร้างอัลกอริทึมที่เหมาะสมที่สุดสำหรับการคำนวณความกว้างของคอลัมน์ในตารางเป็นปัญหาทางคณิตศาสตร์ที่ท้าทายและตัวประมวลผลคำและเค้าโครงมักจะใช้การใช้งานที่ไม่เหมาะสม ฉันขอเสนอโดยใช้ไฟล์ อัลกอริทึมจาก W3C HTML เอกสารตารางเป็นการประมาณครั้งแรก ฉันไม่พบคำอธิบายของอัลกอริทึมที่ใช้โดย MS Word และ Microsoft ได้ปรับแต่งอัลกอริทึมอย่างละเอียดเมื่อเวลาผ่านไปดังนั้น Word เวอร์ชันต่างๆอาจจัดตารางแตกต่างกันเล็กน้อย
หากมีบางอย่างไม่ชัดเจน: ทำวิศวกรรมย้อนกลับ XML!
เมื่อไม่ชัดเจนว่าแท็กนี้หรือแท็ก XML ทำงานอย่างไรใน MS Word มีสองวิธีหลักในการค้นหา:
-
สร้างเนื้อหาที่ต้องการทีละขั้นตอน เริ่มต้นด้วยไฟล์ docx ง่ายๆ บันทึกแต่ละขั้นตอนลงในไฟล์ของตัวเองเช่น
|_+_|
, ตัวอย่างเช่น คลายซิปแต่ละอันและใช้เครื่องมือ Visual Diff สำหรับการเปรียบเทียบโฟลเดอร์เพื่อดูว่าแท็กใดปรากฏขึ้นหลังจากการเปลี่ยนแปลงของคุณ (สำหรับตัวเลือกเชิงพาณิชย์ลองใช้ Araxis Merge หรือ WinMerge ตัวเลือกฟรี) -
หากคุณสร้างไฟล์ DOCX ที่ MS Word ไม่ชอบให้ย้อนกลับไป ทำให้ XML ของคุณง่ายขึ้นทีละขั้นตอน ในบางจุดคุณจะได้เรียนรู้ว่าการเปลี่ยนแปลง MS Word ใดที่ไม่ถูกต้อง
DOCX ค่อนข้างซับซ้อนใช่หรือไม่
มีความซับซ้อนและใบอนุญาตของ Microsoft ไม่อนุญาตให้ใช้ MS Word บนฝั่งเซิร์ฟเวอร์เพื่อประมวลผล DOCX ซึ่งเป็นมาตรฐานที่ดีสำหรับผลิตภัณฑ์เชิงพาณิชย์ อย่างไรก็ตาม Microsoft ได้ให้ไฟล์ XSLT ไฟล์ เพื่อจัดการแท็ก DOCX ส่วนใหญ่ แต่จะไม่ให้ความถูกต้อง 100 เปอร์เซ็นต์หรือ 99 เปอร์เซ็นต์ ไม่รองรับกระบวนการต่างๆเช่นการตัดข้อความบนรูปภาพ แต่คุณจะสามารถรองรับเอกสารส่วนใหญ่ได้ (หากคุณไม่ต้องการความซับซ้อนลองใช้ไฟล์ Markdown เป็นอีกทางเลือกหนึ่ง)
หากคุณมีงบประมาณเพียงพอ (ไม่มีเครื่องมือแสดงผล DOCX ฟรี) คุณอาจต้องการใช้ผลิตภัณฑ์เชิงพาณิชย์เช่น Aspose หรือ docx4j โซลูชันฟรีที่เป็นที่นิยมมากที่สุดคือ LibreOffice สำหรับการแปลงระหว่าง DOCX และรูปแบบอื่น ๆ รวมถึง PDF น่าเสียดายที่ LibreOffice มีจุดบกพร่องเล็ก ๆ มากมายระหว่างการแปลงและเนื่องจากเป็นผลิตภัณฑ์ C ++ แบบโอเพนซอร์สที่ซับซ้อนจึงแก้ไขปัญหาด้านความเที่ยงตรงได้ช้าและยาก
หรือหากคุณพบว่าการจัดวาง DOCX ซับซ้อนเกินไปที่จะใช้งานด้วยตัวเองคุณสามารถแปลงเป็น HTML และใช้เบราว์เซอร์เพื่อแสดงผลได้ คุณยังสามารถพิจารณาหนึ่งใน นักพัฒนา XML อิสระของ ApeeScape .
แหล่งข้อมูล DOCX สำหรับการอ่านเพิ่มเติม
- ข้อกำหนด ECMA DOCX
- ไลบรารี OpenXML สำหรับการจัดการ DOCX จาก C #. ไม่มีข้อมูลเกี่ยวกับการจัดวางหรือการแสดงโค้ด แต่มีลำดับชั้นของคลาสที่ตรงกับโหนด XML ที่เป็นไปได้ใน DOCX
- คุณสามารถ ค้นหาหรือถามใน stackoverflow ด้วยคำหลักเช่น docx4j, OpenXML และ docx; มีคนในชุมชนที่มีความรู้
