aiskillstore/marketplace

DOCXファイルの作成、編集、分析

概要

ユーザーから.docxファイルの作成、編集、または内容の分析を依頼されることがあります。.docxファイルは基本的に、XMLファイルやその他のリソースを含むZIPアーカイブであり、読み取りや編集が可能です。タスクごとに異なるツールとワークフローが用意されています。

ワークフロー決定木

コンテンツの読み取り/分析

以下の「テキスト抽出」または「生XMLアクセス」のセクションを使用してください

新しいドキュメントの作成

「新しいWord文書の作成」ワークフローを使用してください

既存のドキュメントの編集

• 自分のドキュメント + 簡単な変更 「基本のOOXML編集」ワークフローを使用してください

• 他の人のドキュメント **「変更履歴ワークフロー」**を使用してください（推奨デフォルト）

• 法律、学術、ビジネス、または政府の文書 **「変更履歴ワークフロー」**を使用してください（必須）

コンテンツの読み取りと分析

テキスト抽出

ドキュメントのテキストコンテンツを読むだけでよい場合は、pandocを使用してドキュメントをマークダウンに変換する必要があります。Pandocはドキュメント構造を保持するための優れたサポートを提供し、変更履歴を表示できます。

# 変更履歴を含めてドキュメントをマークダウンに変換
pandoc --track-changes=all path-to-file.docx -o output.md
# オプション: --track-changes=accept/reject/all

生XMLアクセス

コメント、複雑な書式設定、ドキュメント構造、埋め込まれたメディア、およびメタデータには、生XMLアクセスが必要です。これらの機能のいずれかを使用するには、ドキュメントを解凍し、生のXMLコンテンツを読み取る必要があります。

ファイルの解凍

python ooxml/scripts/unpack.py <office_file> <output_directory>

主要なファイル構造

• word/document.xml - メインのドキュメントコンテンツ
• word/comments.xml - document.xmlで参照されるコメント
• word/media/ - 埋め込まれた画像とメディアファイル
• 変更履歴は、<w:ins>（挿入）と<w:del>（削除）タグを使用します

新しいWord文書の作成

新しいWord文書をゼロから作成する場合は、docx-jsを使用してください。これにより、JavaScript/TypeScriptを使用してWord文書を作成できます。

ワークフロー

1. 必須 - ファイル全体を読む: docx-js.md（約500行）を最初から最後まで完全に読んでください。このファイルを読むときは、範囲制限を絶対に設定しないでください。ドキュメント作成を進める前に、詳細な構文、重要な書式設定ルール、およびベストプラクティスについて、ファイルの全文を読んでください。
2. Document、Paragraph、TextRunコンポーネントを使用してJavaScript/TypeScriptファイルを作成します（すべての依存関係がインストールされていることを前提としますが、そうでない場合は、以下の依存関係セクションを参照してください）
3. Packer.toBuffer()を使用して.docxとしてエクスポートします

既存のWord文書の編集

既存のWord文書を編集する場合は、Documentライブラリ（OOXML操作用のPythonライブラリ）を使用します。このライブラリは、インフラストラクチャのセットアップを自動的に処理し、ドキュメント操作用のメソッドを提供します。複雑なシナリオでは、ライブラリを介して基になるDOMに直接アクセスできます。

ワークフロー

1. 必須 - ファイル全体を読む: ooxml.md（約600行）を最初から最後まで完全に読んでください。このファイルを読むときは、範囲制限を絶対に設定しないでください。DocumentライブラリAPIと、ドキュメントファイルを直接編集するためのXMLパターンについて、ファイルの全文を読んでください。
2. ドキュメントを解凍します: python ooxml/scripts/unpack.py <office_file> <output_directory>
3. Documentライブラリを使用してPythonスクリプトを作成して実行します（ooxml.mdの「Document Library」セクションを参照）
4. 最終的なドキュメントをパックします: python ooxml/scripts/pack.py <input_directory> <office_file>

Documentライブラリは、一般的な操作用の高レベルメソッドと、複雑なシナリオ用の直接DOMアクセスの両方を提供します。

ドキュメントレビューのための変更履歴ワークフロー

このワークフローにより、OOXMLで変更を実装する前に、マークダウンを使用して包括的な変更履歴を計画できます。重要: 完全な変更履歴を実現するには、すべての変更を体系的に実装する必要があります。

バッチ戦略: 関連する変更を3～10個のバッチにグループ化します。これにより、デバッグが管理しやすくなり、効率を維持できます。各バッチをテストしてから、次のバッチに進みます。

原則: 最小限で正確な編集 変更履歴を実装するときは、実際に変更されたテキストのみをマークします。変更されていないテキストを繰り返すと、編集のレビューが難しくなり、プロフェッショナルでない印象を与えます。置換を次のように分割します: [変更なしテキスト] + [削除] + [挿入] + [変更なしテキスト]。元の実行のRSIDを変更なしテキストに保持するには、元の<w:r>要素を抽出して再利用します。

例 - 文中の「30 days」を「60 days」に変更:

# 悪い例 - 文全体を置換
'<w:del><w:r><w:delText>The term is 30 days.</w:delText></w:r></w:del><w:ins><w:r><w:t>The term is 60 days.</w:t></w:r></w:ins>'

# 良い例 - 変更された部分のみをマークし、変更なしテキストには元の<w:r>を保持
'<w:r w:rsidR="00AB12CD"><w:t>The term is </w:t></w:r><w:del><w:r><w:delText>30</w:delText></w:r></w:del><w:ins><w:r><w:t>60</w:t></w:r></w:ins><w:r w:rsidR="00AB12CD"><w:t> days.</w:t></w:r>'

変更履歴ワークフロー

1. マークダウン表現を取得: 変更履歴を保持したままドキュメントをマークダウンに変換:

   pandoc --track-changes=all path-to-file.docx -o current.md
   

2. 変更を特定してグループ化: ドキュメントをレビューし、必要なすべての変更を特定し、論理的なバッチに整理します:

   位置特定方法（XML内の変更を見つけるため）:

   • セクション/見出し番号（例：「セクション3.2」、「第IV条」）
   • 段落識別子（番号が付いている場合）
   • 一意の周囲テキストを使用したgrepパターン
   • ドキュメント構造（例：「最初の段落」、「署名ブロック」）
   • マークダウンの行番号は使用しない - XML構造に対応していません

   バッチ編成（バッチごとに3～10の関連変更をグループ化）:

   • セクション別: 「バッチ1: セクション2の修正」、「バッチ2: セクション5の更新」
   • タイプ別: 「バッチ1: 日付の修正」、「バッチ2: 当事者名の変更」
   • 複雑度別: 単純なテキスト置換から始め、複雑な構造変更に進む
   • 順次: 「バッチ1: 1～3ページ」、「バッチ2: 4～6ページ」

3. ドキュメントとドキュメントの解凍を読む:

   • 必須 - ファイル全体を読む: ooxml.md（約600行）を最初から最後まで完全に読んでください。範囲制限を絶対に設定しないでください。「Document Library」と「Tracked Change Patterns」のセクションに特に注意してください。
   • ドキュメントを解凍: python ooxml/scripts/unpack.py <file.docx> <dir>
   • 推奨RSIDに注意: 解凍スクリプトは、変更履歴に使用するRSIDを提案します。このRSIDをコピーして、ステップ4bで使用します。

4. 変更をバッチで実装: 変更を論理的にグループ化し（セクション、タイプ、または近接性によって）、1つのスクリプトでまとめて実装します。このアプローチは:

   • デバッグを容易にします（バッチが小さいほど、エラーの特定が容易になります）
   • 段階的な進行を可能にします
   • 効率を維持します（バッチサイズ3～10が適切に機能します）

   推奨バッチグループ化:

   • ドキュメントセクション別（例：「セクション3の変更」、「定義」、「終了条項」）
   • 変更タイプ別（例：「日付変更」、「当事者名更新」、「法的用語置換」）
   • 近接性別（例：「1～3ページの変更」、「ドキュメント前半の変更」）

   関連する変更の各バッチについて:

   a. テキストをXMLにマッピング: word/document.xmlをgrepして、テキストが<w:r>要素間でどのように分割されているかを確認します。

   b. スクリプトを作成して実行: get_nodeを使用してノードを見つけ、変更を実装し、doc.save()を実行します。パターンについては、ooxml.mdの**「Document Library」**セクションを参照してください。

   注意: スクリプトを作成する直前に必ずword/document.xmlをgrepして、現在の行番号を取得し、テキストコンテンツを確認してください。行番号は、スクリプトを実行するたびに変更されます。

5. ドキュメントをパック: すべてのバッチが完了したら、解凍されたディレクトリを.docxに変換し直します:

   python ooxml/scripts/pack.py unpacked reviewed-document.docx
   

6. 最終確認: 完全なドキュメントを包括的にチェックします:

   • 最終ドキュメントをマークダウンに変換:

     pandoc --track-changes=all reviewed-document.docx -o verification.md
     

   • すべての変更が正しく適用されたことを確認:

     grep "original phrase" verification.md  # 見つからないはず
     grep "replacement phrase" verification.md  # 見つかるはず
     

   • 意図しない変更が導入されていないことを確認します

ドキュメントの画像への変換

Word文書を視覚的に分析するには、2段階のプロセスを使用して画像に変換します:

1. DOCXをPDFに変換:

   soffice --headless --convert-to pdf document.docx
   

2. PDFページをJPEG画像に変換:

   pdftoppm -jpeg -r 150 document.pdf page
   

   これにより、page-1.jpg、page-2.jpgなどのファイルが作成されます。

オプション:

• -r 150: 解像度を150 DPIに設定します（品質とサイズのバランスを調整）
• -jpeg: JPEG形式で出力します（PNGが望ましい場合は-pngを使用）
• -f N: 変換を開始する最初のページ（例：-f 2は2ページ目から開始）
• -l N: 変換を終了する最後のページ（例：-l 5は5ページ目で停止）
• page: 出力ファイルのプレフィックス

特定の範囲の例:

pdftoppm -jpeg -r 150 -f 2 -l 5 document.pdf page  # 2～5ページのみを変換

コードスタイルガイドライン

重要: DOCX操作用のコードを生成する場合:

• 簡潔なコードを作成する
• 冗長な変数名や不必要な操作を避ける
• 不要なprint文を避ける

依存関係

必要な依存関係（利用できない場合はインストール）:

• pandoc: sudo apt-get install pandoc（テキスト抽出用）
• docx: npm install -g docx（新しいドキュメント作成用）
• LibreOffice: sudo apt-get install libreoffice（PDF変換用）
• Poppler: sudo apt-get install poppler-utils（pdftoppmを使用してPDFを画像に変換するため）
• defusedxml: pip install defusedxml（安全なXMLパース用）