技術

DOCXの非公式な紹介

約10億人がMicrosoftOfficeを使用しているため、DOCX形式は、オフィス間でドキュメントファイルを交換するための最も一般的なデファクトスタンダードです。最も近い競合製品であるODT形式は、Open / LibreOfficeと一部のオープンソース製品でのみサポートされているため、標準からはほど遠いものになっています。 PDFは編集できず、完全なドキュメント構造が含まれていないため、PDF形式は競合他社ではありません。そのため、透かしや署名などの限られたローカル変更のみを行うことができます。これが、ほとんどのビジネスドキュメントがDOCX形式で作成される理由です。それを置き換える良い代替手段はありません。

DOCXは複雑な形式ですが、インデックス作成、TXTへの変換、その他の小さな変更などの単純なタスクのために、手動で解析することをお勧めします。 DOCXの内部に関する十分な情報を提供したいので、5,000ページの膨大なマニュアルであるECMA仕様を参照する必要はありません。

形式を理解する最良の方法は、MSWordを使用して単純な1ワードのドキュメントを作成し、ドキュメントを編集すると基になるXMLがどのように変化するかを観察することです。 DOCXがMSWordで適切にフォーマットされておらず、その理由がわからない場合や、目的のフォーマットを生成する方法が明確でない場合に遭遇する場合があります。 XMLで何が起こっているのかを正確に見て理解することは、それを助けるでしょう。



私は約1年間、共同DOCXエディターで働いていました。 CollabOffice 、そして私はその知識の一部を開発者コミュニティと共有したいと思います。この記事では、DOCXファイルの構造について説明し、インターネット上に散在する情報を要約します。この記事は、巨大で複雑なECMA仕様と、現在利用可能な単純なインターネットチュートリアルの中間です。この記事に付属するファイルはtoptal-docxにあります。私のプロジェクト githubアカウント 。

単純なDOCXファイル

DOCXファイルは、XMLファイルのZIPアーカイブです。新しい空のMicrosoftWord文書を作成し、その中に「Test」という単語を1つ書き込んで内容を解凍すると、次のファイル構造が表示されます。

私たちの真新しいテストDOCX構造。

単純なドキュメントを作成しましたが、Microsoft Wordの保存プロセスでは、デフォルトのテーマ、ドキュメントプロパティ、フォントテーブルなどがXML形式で生成されています。

DOCX内のすべてのファイルは、拡張子が「.rels」のファイルも含めてXMLファイルです。

まず、未使用のものを削除して、メインのテキスト要素を含むdocument.xmlに注目しましょう。ファイルを削除するときは、そのファイルへのすべての関係参照を他のxmlファイルから削除したことを確認してください。 これがコード差分の例です app.xmlとcore.xmlへの依存関係をどのようにクリアしたかについて。未解決/欠落している参照がある場合、MSWordはファイルが壊れていると見なします。

簡略化された最小限のDOCXドキュメントの構造は次のとおりです（および これがgithubのプロジェクトです ）：

簡略化されたDOCX構造。

ここから、上からファイルごとに分類してみましょう。

_rels / .rels

これは、MSWordにドキュメントの内容を探す場所を指示する参照を定義します。この場合、word/document.xmlを参照します。

[Content_Types].xml

_rels / document.xml.rels

このファイルは、ドキュメントコンテンツに埋め込まれた画像などのリソースへの参照を定義します。単純なドキュメントにはリソースが埋め込まれていないため、リレーションシップタグは空です。

Test

[Content_Types] .xml

/word/styles.xmlドキュメント内のメディアの種類に関する情報が含まれています。テキストコンテンツしかないので、とても簡単です。

My heading 1

document.xml

最後に、ドキュメントのテキストコンテンツを含むメインのXMLを次に示します。わかりやすくするために名前空間宣言の一部を削除しましたが、ファイルのフルバージョンはgithubプロジェクトにあります。そのファイルには、ドキュメント内の名前空間参照の一部が使用されていないことがわかりますが、MS Wordで必要になるため、それらを削除しないでください。

簡略化した例を次に示します。

styles.xml

メインノードはドキュメント自体を表し、段落を含み、によって定義されたページディメンション内にネストされます。

無視できる属性です。 MSWordの内部で使用されます。

3つの段落からなるより複雑なドキュメントを見てみましょう。 Microsoft Wordのスクリーンショットで同じ色でXMLを強調表示したので、相関関係を確認できます。

スタイリングを使用した複雑な段落の例。

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

段落構造

単純なドキュメントは段落で構成され、段落は実行（同じフォント、色などの一連のテキスト）で構成され、実行は文字（など）で構成されます。タグには複数の文字が含まれる場合があり、いくつかある場合もあります。同じ実行で。

Pythonにログインする方法

繰り返しますが、無視できます。

テキストのプロパティ

基本的なテキストプロパティは、フォント、サイズ、色、スタイルなどです。テキストの外観を指定するタグは約40個あります。 3段落の例でわかるように、各実行には、内部に独自のプロパティ、指定、および太字があります。

注意すべき重要な点は、プロパティは通常のスクリプトと複雑なスクリプト（アラビア文字など）の2つの文字グループを区別し、影響を受ける文字のタイプに応じてプロパティのタグが異なることです。

ほとんどの通常のスクリプトプロパティタグには、プロパティが複雑なスクリプト用であることを指定する「C」が追加された、一致する複雑なスクリプトタグがあります。例:(斜体）はになり、通常のスクリプトの太字のタグは、複雑なスクリプトの場合になります。

スタイル

Microsoft Wordには、通常、間隔なし、見出し1、見出し2、タイトルなどのスタイル専用のツールバー全体があります。これらのスタイルはw:r/w:pPr/*に保存されます（注：簡単な例の最初のステップでは、このXMLをDOCXから削除しました。これを確認するには、新しいDOCXを作成してください）。

テキストをスタイルとして定義すると、段落のプロパティタグ内にこのスタイルへの参照が表示されます。これは、見出し1のスタイルでテキストを定義した例です。

/word/styles.xml

w:styles/w:docDefaults/w:rPrDefault/*のスタイル自体は次のとおりです。

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

Thexpathは、フォントが太字であることを指定し、フォントの色を示します。不足しているプロパティに「通常」スタイルを使用するようにMSWordに指示します。

プロパティの継承

テキストのプロパティは継承されます。実行には独自のプロパティ（w:type='paragraph'）がありますが、段落（w:default='1'）からプロパティを継承し、どちらもword/_rels/document.xml.relsからスタイルプロパティを参照できます。

word/theme/themes1.xml

段落と実行はデフォルトのプロパティで始まります：a:themeElements/a:fontScheme/a:majorFontおよびa:minorFont。キャラクターのプロパティの最終結果を取得するには、次のことを行う必要があります。

  1. デフォルトの実行/段落プロパティを使用する
  2. 実行/段落スタイルのプロパティを追加する
  3. ローカルの実行/段落プロパティを追加します
  4. 段落プロパティの上に結果実行プロパティを追加します

BをAに「追加」と言うときは、すべてのBプロパティを反復処理し、すべてのAのプロパティをオーバーライドして、交差しないすべてのプロパティをそのままにすることを意味します。

デフォルトのプロパティが配置される可能性のあるもう1つの場所は、w:docDefaults/w:rPrDefaultのタグです。およびw:val。ラン内のキャラクター自体がデフォルトのスタイルを持つことはなく、実際にはテキストに影響を与えないことに注意してください。

実行中の文字はその段落から継承でき、両方ともstyles.xmlから継承できます。

1554402290400-dbb29eef3ba6035df7ad726dfc99b2af.png）

実行中の文字はその段落から継承でき、両方ともstyles.xmlから継承できます。

プロパティを切り替えます

一部のプロパティは、（太字）や（斜体）などの「トグル」プロパティです。これらの属性はXOR演算子のように動作します。

これは、親スタイルが太字で子ランが太字の場合、結果は通常の太字ではないテキストになることを意味します。

トグル属性を正しく処理するには、多くのテストとリバースエンジニアリングを行う必要があります。 ECMA-376 Open XML仕様の17.7.3項を参照して、トグルプロパティの正式で詳細なルールを取得してください。

トグルプロパティは、レイアウト担当者が正しく処理するために最も複雑です。

フォント

フォントは他のテキスト属性と同じ一般的な規則に従いますが、フォントプロパティのデフォルト値は、'left'で参照される別のテーマファイルで指定されます。このような：

'center'

上記の参照に基づいて、デフォルトのフォント名は'right'、タグ内、'both'にあります。または'left'鬼ごっこ。

'center'でない限り、デフォルトのフォントサイズは10です。タグがない場合はサイズ11です。

テキストの配置

テキストの配置は、4つの'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でモードでは、段落テキストは右マージンに揃えられます。 （このテキストが右側にどのように配置されているかに注意してください。）

w:beforeモードは単語間に余分なスペースを入れて、行が広くなり、左揃えの最後の行を除いて段落幅全体を占めるようにします。 （この段落はそのデモンストレーションです。）

画像

DOCXは、インラインとフローティングの2種類の画像をサポートしています。

インライン画像は他の文字と一緒に段落内に表示され、using（text）の代わりに使用されます。次のxpath構文でイメージIDを見つけることができます。

w:line

画像IDは、w:lineでファイル名を検索するために使用されますファイルであり、word / mediaサブフォルダー内のgif / jpegファイルを指している必要があります。 （画像IDを確認できるgithubプロジェクトの1.docxファイルを参照してください。）

フローティング画像は、テキストが周囲を流れる段落を基準にして配置されます。 （これが3番目のgithubプロジェクトです サンプルドキュメント フローティング画像付き。）

代わりにフローティング画像を使用するため、内部のテキストを削除する場合、画像を削除したくない場合はアンカーに注意してください。

インラインvs.フローティング。

MS Wordの画像オプションでは、画像の配置を「テキスト折り返しモード」と呼んでいます。

テーブル

テーブルのXMLタグはHTMLテーブルマークアップに似ています–と同じです

、と一致します、など。

、テーブル自体にはテーブルプロパティがあり、各列プロパティは内部に表示されます。行は1つずつタグが続き、各行には次で指定されているのと同じ数の列が必要です。

2.docx

表の列の幅はタグで指定できますが、定義しない場合、MS Wordは内部アルゴリズムを使用して、最小の有効な表サイズに最適な列の幅を見つけます。

単位

DOCX内の多くのXML属性は、サイズまたは距離を指定します。これらはXML内の整数ですが、すべて異なる単位を持っているため、変換が必要です。トピックは複雑なので、お勧めします DOCXファイルのユニットに関するLarsCorneliussenによるこの記事 。彼が提示する表は便利ですが、小さな誤植があります。インチはpt * 72ではなくpt / 72である必要があります。

チートシートは次のとおりです。

一般的なDOCXXML単位の変換
ポイントの20番目 ポイント
dxa / 20		 インチ
pt / 72		 センチメートル
in * 2,54		 フォントのハーフサイズ
pt / 144		 EMU
in * 914400
例 11906 595.3 8.27..。 21,00086..。 4,135 7562088
これを使用したタグ pgSz / pgMar / w：spacing で：sz wp：extent、a：ext

レイアウトツールを実装するためのヒント

DOCXファイルを（たとえばPDFに）変換したり、キャンバスに描画したり、ページ数をカウントしたりする場合は、レイアウトツールを実装する必要があります。レイアウトツールは、DOCXファイルから文字の位置を計算するためのアルゴリズムです。

100％忠実なレンダリングが必要な場合、これは複雑なタスクです。優れたレイアウトツールを実装するために必要な時間は人年で測定されますが、単純で限られたものだけが必要な場合は、比較的迅速に実行できます。

レイアウト担当者は、通常はページの長方形である親の長方形を塗りつぶします。実行から単語を1つずつ追加します。現在の行がオーバーフローすると、新しい行が開始されます。段落が親の長方形に対して高すぎる場合は、次のページに折り返されます。

レイアウトツールを実装する場合は、次の点に注意してください。

  • レイアウト担当者は、テキストの配置と画像上に浮かぶテキストに注意する必要があります
  • ネストされたテーブルなどのネストされたオブジェクトを処理できる必要があります
  • このような画像を完全にサポートする場合は、少なくとも2つのパスでレイアウトツールを実装する必要があります。最初のステップではフローティング画像の位置を収集し、2番目のステップでは空のスペースをテキスト文字で埋めます。
  • インデントと間隔に注意してください。各段落には前後にスペースがあり、これらの番号は
    で指定されます。鬼ごっこ。垂直方向の間隔は
    で指定されますおよび
    タグ。行間隔は
    |_+_|
    で指定されますが、これは予想される行のサイズではないことに注意してください。行のサイズを取得するには、現在のフォントの高さを取得し、
      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レイアウトツールを実装する場合は、テーブルが複数のページにまたがる特殊なケースに注意してください。ページオーバーフローを引き起こすセルは、他のセルにも影響します。
    •  
  • テーブルの列の幅を計算するための最適なアルゴリズムを作成することは、難しい数学の問題であり、ワードプロセッサとレイアラーは通常、いくつかの次善の実装を使用します。私は使用することを提案します W3CHTMLのアルゴリズム 最初の概算としての表のドキュメント。 MS Wordで使用されているアルゴリズムの説明は見つかりませんでした。また、Microsoftはアルゴリズムを時間の経過とともに微調整してきたため、Wordのバージョンが異なればテーブルのレイアウトもわずかに異なる可能性があります。
    •  
 
不明な点がある場合：XMLをリバースエンジニアリングしてください！
 
これまたはそのXMLタグがMSWord内でどのように機能するかが明らかでない場合、それを理解するための2つの主要なアプローチがあります。
 
     
  •  
    目的のコンテンツを段階的に作成します。単純なdocxファイルから始めます。たとえば、
    |_+_|
    、
    のように、各ステップを独自のファイルに保存します。それぞれを解凍し、視覚的な差分ツールを使用してフォルダーを比較し、変更後に表示されるタグを確認します。 （商用オプションの場合はAraxis Mergeを、無料オプションの場合はWinMergeを試してください。）
     
    •  
  •  
    MS Wordが気に入らないDOCXファイルを生成する場合は、逆方向に作業してください。 XMLを段階的に簡素化します。ある時点で、MSWordが正しくないことがわかった変更を学習します。
     
    •  
 
DOCXは非常に複雑ですよね？
 
これは複雑であり、Microsoftのライセンスでは、サーバー側でDOCXを処理するためにMSWordを使用することは禁じられています。これは商用製品ではかなり標準的です。ただし、Microsoftは XSLTファイル ほとんどのDOCXタグを処理できますが、100％または99％の忠実度は得られません。画像のテキストの折り返しなどのプロセスはサポートされていませんが、ほとんどのドキュメントをサポートできます。 （複雑さが必要ない場合は、使用を検討してください マークダウン 別の方法として。）
2016年にもっとuberまたはlyftを支払う人

 
十分な予算がある場合（無料のDOCXレンダリングエンジンがない場合）、Asposeやdocx4jなどの商用製品を使用することをお勧めします。最も人気のある無料のソリューションは、DOCXとPDFを含む他の形式の間で変換するためのLibreOfficeです。残念ながら、LibreOfficeには変換中に多くの小さなバグが含まれています。また、LibreOfficeは洗練されたオープンソースのC ++製品であるため、忠実度の問題を修正するのは遅く、困難です。
 
または、DOCXレイアウトが複雑すぎて自分で実装できない場合は、それをHTMLに変換し、ブラウザーを使用してレンダリングすることもできます。次のいずれかを検討することもできます ApeeScapeのフリーランスXML開発者 。
 
さらに読むためのDOCXリソース
 
                    
                

            

        

    

    
    
    

        

            

                

                    

                        

                            
 デザイン教育の重要性 

                            
 Uxデザイン 

                                
                        

                        

                             デザイン教育の重要性
                        

                    

                

                

                    

                        

                             iOSアプリケーションでクライアント/サーバー相互作用ロジックを分離する方法
                        

                        

                            
 iOSアプリケーションでクライアント/サーバー相互作用ロジックを分離する方法 

                            
 モバイル