オープンソースのRubyでOOXML形式のパーサーをレイアウトしました。 GitHubおよびRubyGems.orgで入手でき、AGPLv3ライセンスの下で無料で配布されています。 すべてがファッショナブルなRuby開発者のようなものです。

サードパーティのパーサーを使用しなかった理由

パーサーがRubyの最初のOOXMLパーサーではないことは秘密ではありません。 サードパーティ製品を使用することもできますが、使用しないことにしました。 私たちが見つけた解決策には、いくつかの問題があります。

a）開発者によって長い間放棄されてきた。
b）基本的な機能のみをサポートします。
c）通常、3つの個別のライブラリとして配布されます。 多くの場合、docxパーサーとxlsxパーサーは異なる人々によって作成されたため、それらのインターフェースは劇的に異なる可能性があります。 同意します、これは不便です。

パーサーの違いは何ですか

私たちは自分自身と私たちのタスク（ドキュメントエディタのテスト）のために書きましたが、その後、おそらく他のRuby開発者を助けることができることに気付きました。

a）積極的に開発中です。
b）エディターのすべての機能をサポートしており、それはたくさんあります。 ここで読むことができます。
c）docx、xlsx、pptxで動作するため、OOXMLパーサーを呼び出しました。

機能b）-機能について説明します。 標準の可能な機能をすべて実装していますか？ いや。 ECMA-376標準は4ボリュームで、合計9000ページを超えています（いいえ）。 実際、約7000です。 息を吐くことができます。



一般的に、あなた自身が理解しています。すべてが私たちと一緒に実装されるわけではありません。 しかし、必要なものはすべてあります。段落、表、自動数値が認識されます。 のような複雑なもののサポートがあります

• カラースキーム;
• 段落と表のスタイル。
• 組み込みのグラフ。
• 自動図形のプロパティ;
• スピーカー;
• リスト。

なぜパーサーが必要なのですか

ネタバレ-なぜパーサーが必要なのですか？
彼はテスト部門で生まれました。
自動テストの最初から、機能テストという単一のコンセプトを採用しました。

最も簡単なテストを実施してください。

1.新しいドキュメントを作成します。
2.テキストを印刷し、その太字プロパティを設定します。
3.太字が設定されていることを確認します。

ONLYOFFICEエディターはCanvasで記述されています。つまり、文書内のテキストは画像です。 画像内のフォントの太さを確認することは非常に困難です。 ただし、任意のフォントに太字を適用できます！



一部のフォント（Arial Blackなど）では、ボールドが視覚的にまったく表示されない場合があります。 画像をimagemagickと比較することは最良の選択肢ではないことに同意します。

したがって、テストの検証手順は別の段落で強調表示されました。つまり、

4.結果のファイルをdocx形式でダウンロードし、テキストに太字パラメーターが設定されていることを確認します。

そのようなパラメーターは数百あります。 同時に、既存のソリューションはどれも、テキスト、テーブル、およびその他のいくつかの最も単純なグラブ以外のものをサポートしていませんでした。 そこで、独自のライブラリを作成することにしました。

これらのフォーマットをすべて編集用に開くことができるドキュメントエディターを開発しています。 エディターから既製のソリューションを使用して、それを通してテストを検証してみませんか？

どうして？

1.エディターのサーバー側では、パーサーはC ++で記述されており、自動テストのプロセス全体がRubyで構築されています。 移動中、これをすべて結び付ける方法は完全には明確ではありませんでした。

2.現在、Linux用のバージョンがあります（それがメインです）が、テスト用のインフラストラクチャ全体の統合が開始された時点で、ドキュメントのサーバー部分はプラットフォームとしてWindowsのみをサポートしていました。 同時に、テストでは常にUbuntuと派生物を使用しました。 それをすべて接着するには、トリッキーなスキームを考え出す必要があります。

3.サーバーパーサーを標準と見なすことは可能ですか？ 製品自体を使用して製品の結果を検証しますか？ 疑わしいアイデア。

パーサーの仕組み

docxファイルをアーカイブしようとしたことがある場合、圧縮率が非常に小さいことに気づいたかもしれません。 なぜそう 簡単です。ooxmlファイルは、xmlファイルのアーカイブセットにすぎません。 それらの構造は非常に簡単です。



たとえば、ONLYOFFICEエディターで簡単なグリーティングファイルを作成し、docxでダウンロードします。 次に、それをzipファイルとして解凍し、このドキュメントの重要な部分が保存されている場所を確認します。

次の構造が表示されます。

#tree ├── [Content_Types].xml ├── docProps │ ├── app.xml │ └── core.xml ├── _rels └── word ├── document.xml ├── fontTable.xml ├── _rels │ └── document.xml.rels ├── settings.xml ├── styles.xml ├── theme │ ├── _rels │ │ └── theme1.xml.rels │ └── theme1.xml └── webSettings.xml 

私たちは内部を掘り下げ始めます。 順番に。

[Content_Types] .xml-ドキュメント内のMIMEタイプのリスト。 寒いです。

app.xml-ドキュメントのメタデータ、作成者アプリケーション、統計。 すでに暖かく、情報は興味深く有用です。

core.xml-最新の変更に関するメタデータ。

document.xml-ああ、それはビンゴです。 ドキュメントのコンテンツはこのファイルに隠されています。後で検討します。

fontTable.xml-ドキュメント内のフォントの表。 便利です。

document.xml.rels-アーカイブ内のすべてのファイルのリスト。このリストは、写真やグラフを含む複雑なドキュメントの場合に非常に役立ちます。

settings.xml-名前から、デフォルトのズーム、数字の区切りなど、さまざまなドキュメントパラメータがそこに保存されていることが明らかです。

styles.xml、theme1.xml、およびtheme1.xml.relsは、ドキュメントのスタイルとテーマのパラメーターを含む非常にかさばる非常に詳細なファイルです。 これらのドキュメントを理解する機能は、製品の重要な機能の1つです。

webSettings.xml-ドキュメントのWebバージョンに関する設定。 docxの最も一般的な機能ではありません。省略してください。

そのため、単純なドキュメントでは、 word / document.xmlが興味深いことがわかりました。



シンプルなxml。 幸いなことに、Rubyでのxmlの解析に問題はありません。 のこぎりを取り、DOMツリーを取得します。 さて、それは技術の問題であり、標準を読んでください（怠notではない場合、ドキュメントは非常に大きいです）、または古き良きリバースエンジニアリングで必要なパラメーターがドキュメントのどこに隠れているかを理解するだけです。

パーサーの記述方法

作業の最初に、私たちは多くの間違いを犯しました。それは、意識が高まるにつれて自分自身を修正しました。 2つの最も重大な誤りを以下に説明します-それらは過去に良いことであり、私たちはもはや恥ずかしくありません。 私たちの経験が、同じレーキを越えないように他の人を助けることを願っています。

巨大なファイル
したがって、3つの異なるドキュメント形式を処理するタスクがあります。 このコードをどのように整理しますか？ もちろん、4000行のコードの3つのファイル（実際には、形式の一般的な方法もあるため、4000行のコードの4つのファイルでさえも）。

問題の解決に最も時間がかかった。 私はこのすべての経済をきちんとした形にしなければなりませんでした（ただし、300行のファイルがまだポップアップすることがあります）、きちんとしたクラスのメソッドを選択するなど。 現在、4つではなく200以上のソースファイルがあります。 バグを修正するのは簡単です。

テストの欠如
ロジックは次のとおりです。メイン製品のONLYOFFICE Document Serverをテストするためのパーサーを作成していますが、なぜパーサー自体をテストする必要があるのですか？

いや いや いいえ!!!

生活シーン：

-ここで何かを修正する必要があります。図の色が間違って決定されています。

-はい、今、そこにタイプミスがあり、1つの文字を修正し、コミットしました。

結果：

すべてが落ちました。 パーサー、エディター、ドル為替レート、ハンプティダンプティ、自尊心。

あなたがしなければならなかったのは、 `spec`フォルダを作成し、そこに数百のファイルを置き、夜に静かに眠るためにたくさんのパラメータをチェックし、仕事を離れる前に行ったコミットがメニューで設定されたオプションの検証を壊さないことを知っていることでしたネストの第3レベル。 「左側の3番目の星」と呼びます。

しかし、目を細めただけではありません。 また、健全な考えもありました。 最もクールなもの：

RuboCopを使用する
RuboCopはRuby用の静的コードアナライザーであり、それが気に入っています。 本当に、本当に。 そして、私たちは常に彼の意見に耳を傾けます。 コードを適切な状態に保ち、愚かな間違いを避け、次のコミット後にコードが汚れたり悪化したりしないように厳密に監視するのに役立ちます（ overcommitによる統合のおかげ）。

彼の仕事は次のようになります。苦労して一日を過ごした後、Rubyの変数は通常大文字で始まることを忘れて、次の形式のコードをコミットしようとします。

-path_to_zip_file = copy_file_and_rename_to_zip（path_to_file）
+ ZIP_file = copy_file_and_rename_to_zip（path_to_file）

この場合、エラーが発生します。

RuboCopで分析........................................ [RuboCop]が失敗しました
変更された行のエラー：
ooxml_parser / lib / ooxml_parser / common_parser / parser.rb：8：7：E：動的定数の割り当て

追加の操作なしでこのコードをコミットすることはできません（ `SKIP = RuboCop git commit -av`）。 これは愚か者に対する大きな防御です。

オープンソースプロジェクトのオリエンテーション
パーサー開発のほぼ最初から、他のオープンソースプロジェクトに焦点を当てました。 私たちのコードがオープンソースでレイアウトされるかどうかはわかりませんでしたが、私たちは常にこの準備ができていました。 「Lay out」コマンドが到着したら、GitHubの「make public」ボタンをクリックするだけで、追加のコーミングやその他の操作は一切必要ありません。

これは同じRuboCopの大きなメリットです。変更ログやgem構造などの特定のトピックをどのように整理するのが最善かを考えながら、コードをよく覗きました。 さらに、すべての開発、コミット、変更の履歴などは、最初は英語で行われました。

ドキュメントのデータベースを使用する
パーサーをテストするとき、以前の成果は役に立ちました。3つの形式のあらゆる種類の奇妙で巨大で理解できないファイルを含む大規模なデータベースです。

昔々、ONLYOFFICEエディターの開発の初期段階で、これらのファイルをインターネット上で収集しました。彼らは複雑で非標準のドキュメントのレンダリングをチェックしました。 数年後、パーサーは同じドキュメントベースで実行されました。 その結果、難易度の異なるさまざまな問題が発生し、それらを解決するために数週間を費やした後、優れた製品が得られました。

合計

だから、すべてが利用可能で、それをRubyアプリケーションに追加し、docxを解析し、それらの統計を構築し、xlsxファイルのアカウンティングがどのように機能するかを分析し、4番目のスライドの製品プレゼンテーションでどのmemesikがPMを隠したかを調べます。 そして、これはすべて無料です。

GitHubで問題のあるファイルを見つけて問題を作成することもできます。これは解決します。 自分で編集してプルリクエストを送信することもできます。