Excel 報表輸出該怎麼做 - COM 自動化 / Open XML / 範本方式的判斷表
· 小村 豪 · Excel, 報表, Windows 開發, Office, COM, Open XML
在 Excel 報表輸出的案子中，「想輸出到 Excel」這一句話裡，其實經常混雜著好幾個不同的需求。
- 使用者之後要手動修改
- 想保留現有的
.xlsm - 連樞紐、圖表、列印設定都要原封不動使用
- 要在夜間批次中大量產出
- 要在伺服器上無人值守執行
- 也需要 PDF
這些需求沒辦法用單一方式一次完美解決。
應該先看的不是函式庫的名字，而是 要驅動 Excel 應用程式，還是要產生 Excel 檔案。
若在這裡抓錯方向，一開始也許能動，但日後維運會變得很痛苦。
本次以 Windows 應用或業務系統上的 Excel 報表輸出為前提，整理 COM 自動化 / Open XML / 範本套版 / 既有 VBA 併用 的選擇方式。
1. 先下結論
先把結論列出來，大致如下。
- 使用者之後會打開 Excel 編輯的報表，首選是 範本 +
.xlsx/.xlsm直接生成。 - 伺服器 / 服務 / 排程器自動生成的情境下，不要以 Office 自動化為前提 才比較安全。
- 想活用 既有的
.xlsm、VBA、圖表、樞紐、列印設定 時，把 版型與 Excel 特有功能放在範本側、程式碼專注在資料套版，比較不容易壞。 - 只有在 真的需要 Excel 應用程式本身的行為 時，才把 COM 自動化 限定於桌面上有人操作的情境使用，這樣最自然。
- 如果只是單純的清單輸出，從一開始就選 CSV / PDF / Web 畫面 往往更符合需求。
簡單來說，大多數業務報表並不是「操作 Excel」，而是「組裝 Excel 檔案」比較自然。
2. 最先要決定的事
Excel 報表輸出最先想決定的，是下面這些項目。
| 確認項目 | 先決定的理由 |
|---|---|
最終產物是 .xlsx / .xlsm / PDF / CSV 中的哪一個 |
這裡就能相當程度縮小方案範圍 |
| 使用者輸出後是否會在 Excel 中編輯 | 若前提是會編輯，Excel 功能與版型維持就很重要 |
| 執行場所是使用者 PC，還是伺服器 / 服務 / 批次 | 能使用 COM 自動化的範圍會大幅改變 |
| 是否保留既有的 VBA / 巨集 / 增益集 | 需要 .xlsm 範本或階段式遷移的設計 |
| 圖表、樞紐、列印範圍、頁首 / 頁尾是否要固定 | 放在範本比放在程式碼更不容易壞 |
| 每次的行數、檔案數、同時執行數大約多少 | 大量輸出時，直接生成比 COM 更合適 |
| 報表外觀由誰負責變更 | 若不只開發者、現場也會動，範本方式比較契合 |
3. 主要的實作方式
3.1 Excel COM 自動化
啟動 Excel，透過 COM 操作 Workbook、Worksheet、Range 的方式。
想成是「駕駛一台真正的 Excel」就很容易理解。
強項是能直接使用 Excel 特有的行為。
與既有活頁簿、圖表、樞紐、列印設定、巨集、PDF 輸出的相容性很好，能直接處理「Excel 最終會怎麼呈現」。
但弱點也相當明顯。
- 需要安裝 Excel
- 會背負行程生命週期、檔案鎖、對話框、bitness、使用者 Profile 相依等問題
- 無人伺服器或服務執行 Office Automation，並不受 Microsoft 自身推薦或支援
3.2 .xlsx 直接生成
.xlsx 是 Open XML 格式，因此可以不啟動 Excel 就直接組裝檔案。
使用 Open XML SDK 這類手段，就能從程式碼操作活頁簿、工作表、儲存格、樣式、表格。
這種方式的強項在於 即使環境沒有 Excel 也能動，與批次或伺服器契合度高。
另一方面，若想自然地重現 Excel 本身偏 UI 側的行為，就會比較吃力。
欄寬自動調整、分頁、複雜外觀、既有活頁簿的深度編輯等，如果全部想只用程式碼漂亮地完成，很快就會陷入泥巴戰。
3.3 範本套版
實務上最容易推薦的，是 先做好 Excel 範本，程式碼只負責資料套版 的方式。
報表的外觀、公式、條件式格式、列印範圍、頁首 / 頁尾、Logo、圖表都放在範本側。
程式碼側則複製範本，並往名稱範圍、表格、儲存格範圍這些「事先決定好的入口」寫入資料。
這樣做之後，版型修改與業務邏輯修改就會分開。
也能相當程度避免 Excel 報表中常見的 Cells[37, 9] = ... 地獄。
3.4 保留既有 VBA 資產的方式
既有的 .xlsm 或 VBA 還活著時，往往不要一次全部重做比較自然。
把報表的 UI 與最後的整形留給 VBA，重計算、DB / HTTP、業務邏輯則移到 C# / .NET 側，這種分工相當實際。
這時候重要的是 不要讓職責模糊。
- VBA 側：活頁簿內部的行為
- .NET 側：資料取得與業務處理
- 兩者的交界：以名稱範圍、表格、對外介面等固定下來
3.5 使用 Microsoft 365 / Graph 的情境
如果 Excel 檔案一開始就在 OneDrive / SharePoint 上，而且想從 Web App 或行動 App 共同使用，Microsoft Graph 的 Excel API 也進入選項。
只是它並不是把本機 PC 任意檔案粗暴量產的通用解。權限、儲存位置、Session、運維，從一開始就以 M365 為前提。
3.6 是否真的需要 Excel
如果報表需求是「人之後要動的表」，Excel 是相當自然的選擇。
但如果需求是下列之一，其他格式往往更直白。
- 印出來存檔 -> PDF
- 匯入其他系統 -> CSV / TSV / JSON
- 只要在瀏覽器看得到 -> HTML / Web 畫面
- 目的是彙總與視覺化 -> BI 或儀表板
4. 方式比較
把這些方式的差異大致用一張表來看，如下。
| 方式 | 需要安裝 Excel | 與無人執行的契合度 | 既有版型再利用 | 與 Excel 特有功能的契合度 | 適用情境 |
|---|---|---|---|---|---|
| COM 自動化 | 需要 | 弱 | 強 | 非常強 | 使用者 PC 上的輸出、既有 .xlsm、最後轉 PDF |
.xlsx 直接生成 |
不需要 | 強 | 中 | 中 | 批次、伺服器、大量輸出 |
| 範本套版 | 不需要（輸出時） | 強 | 強 | 中～強 | 多數業務報表的首選 |
| 既有 VBA 併用 | 依使用形態 | 弱～中 | 非常強 | 強 | 階段式遷移、既有資產活用 |
| Graph Excel API | 以 M365 為前提 | 中 | 中 | 中 | OneDrive / SharePoint 上的共同使用 |
5. 常見需求的選法
5.1 在使用者 PC 上輸出，然後直接編輯
這種情境下，範本 + 直接生成 相當有力。
因為使用者會在輸出後用 Excel 打開，最終編輯可以交給 Excel。
5.2 在夜間批次或服務上大量生成
這種情境下，最好先 排除 COM 自動化。
生成集中在 .xlsx 直接生成，需要時再由使用者用 Excel 打開。
5.3 想沿用既有的 .xlsm / VBA
這種情境下，把 .xlsm 保留為範本，僅從外部進行資料套版 是比較實際的做法。
5.4 明細行很大
Excel 單一工作表的上限是 1,048,576 列 × 16,384 欄。
所以當明細量很大時，一開始就要決定下列事項。
- 超過幾列就切換工作表
- 超過幾筆就切換檔案
- 從一開始是不是用 CSV 更自然
6. 實務上容易推薦的組合
實務上不容易壞的組合，是分成下列 4 層。
| 層級 | 角色 | 這一層不做的事 |
|---|---|---|
| ReportModel | 整理報表所需的值 | 不知道儲存格位址 |
| Template | 擁有外觀、公式、列印設定、圖表 | 不知道 DB 或業務邏輯 |
| Binder | 把資料寫到名稱範圍 / 表格 | 不夾帶商業判斷 |
| Finisher | 必要時做 VBA / COM / 轉 PDF | 不負責原始資料取得 |
這樣分工的好處是 程式碼比較不會被 Excel 的外觀拖著走。
7. 常見坑點
7.1 不要把儲存格位址當成業務規格
一旦 Cells[12, 7] 開始表達業務規則，版型變更就會等於規格變更。
程式碼透過名稱範圍或表格名來操作報表，可以撐得比較久。
7.2 不要把合併儲存格當成資料入口
合併儲存格是給外觀用的功能。
當作套版目標時，新增列或範圍計算很容易出事。
7.3 不要用「已帶格式的字串」填入數值或日期
數值就用數值放進去，外觀放在儲存格格式比較自然。
7.4 不要讓範本變更淪為野放式管理
範本雖然不是程式碼，但實質上就是規格本身。
所以當成版本控管、差異確認、審查對象來處理會比較安全。
7.5 用 COM 時，不要輕忽 bitness 與生命週期管理
在 COM 自動化或 VBA 整合中，32bit / 64bit 的差異、Excel 行程的善後、檔案鎖、使用者環境差異，都會默默地造成影響。
8. 總結
Excel 報表輸出看起來只是「輸出到 Excel」這麼一句話，實際上需要先決定下列分支。
- 是要驅動 Excel 應用程式
- 還是要組裝 Excel 檔案
- 使用者 PC、或無人執行
- 是否保留既有 VBA 或
.xlsm - 最終產物是 Excel，或是 PDF、CSV
實務上的首選，範本 + 直接生成 相當強。
視情況再加上 既有 VBA 的再利用 或 使用者 PC 上最後的 Excel 處理，整體就會比較好收斂。
9. 參考資料
- Considerations for server-side Automation of Office
- Considerations for unattended automation of Office in the Microsoft 365 for unattended RPA environment
- About the Open XML SDK for Office
- How to: Copy a worksheet using SAX (Simple API for XML)
- Working with Excel workbooks and charts using the Microsoft Graph API
- Access OneDrive and SharePoint using the Microsoft Graph API
- Excel specifications and limits
相關文章
共用相同標籤的最新文章。能以相近的主題延伸理解。
什麼是 VBA - 限制、未來走向、該被取代的情境與務實的遷移模式
本文從實務角度釐清 VBA 的本質、桌面前提的限制、Excel for the web 與巨集封鎖、64bit 與伺服器自動化的注意事項，並依職責分派 Office Scripts、Office Add-ins、.NET 外移等替代目標，提示階段性遷移的具體步驟。
開發 COM 元件、OCX／ActiveX 時常見的坑 - 整理 Visual Studio 的 32bit／64bit、註冊、管理員權限
整理開發 COM、OCX、ActiveX 元件時最容易卡關的四個面向：宿主行程的 32bit／64bit、Visual Studio 2022 變成 64bit 後的設計時整合、regsvr32 與 Regasm 的註冊位置、以及管理員權限與 HKCU／HKLM 的關係，協...
什麼是 Reg-Free COM - 免註冊使用 COM 的機制，以及合用與不合用的情境
整理 Reg-Free COM 的本質、執行時 activation context 與 manifest 的協作方式，以及好處與極限。同時釐清 bitness、相依 DLL、TLB／設計時參考是另一條線，幫助你判斷哪些情境適合導入、哪些情境得另想辦法，並避開常見的部署陷阱。
從 VBA 帶型別使用 .NET 8 的 DLL - 以 COM 發布 + dscom 產生 TLB
本文整理把 .NET 8 類別庫以 COM 公開、再用 dscom 產生 TLB，並從 VBA 以 early binding 帶型別呼叫的最短流程。涵蓋介面設計、bitness 對齊、regsvr32 與 tlbregister 註冊和發布要點，幫你穩穩整合既有 Offi...
COM / ActiveX / OCX 是什麼 - 差異與關係一次整理
從實務角度釐清 COM、ActiveX、OCX 三者的差異與關係：COM 是 Windows 元件互動的 binary 契約底層，ActiveX 是以 COM 為基礎的可嵌入 control 脈絡，OCX 則為 ActiveX control 常見的副檔名。讀完能分清機制、...
相關主題
與本文相近的主題頁面。以本文為起點，可進一步連到相關服務與其他文章。
Windows 技術主題
彙整 KomuraSoft LLC 關於 Windows 開發、故障調查與既有資產活用文章的主題中心。
ActiveX 遷移
整理保留、包裝或替換 COM / ActiveX / OCX 資產的階段性判斷的主題頁面。
與本主題相關的服務
本文連結到以下服務頁面，歡迎從最接近的入口查看。
Windows 應用程式開發
支援包含常駐處理、設備連動、運作日誌與可維護結構的 Windows 桌面應用程式。
既有資產活用 & 遷移支援
在持續活用 COM / ActiveX / OCX 資產、原生程式碼與 32 位元相依的同時，協助規劃階段性的遷移。
作者檔案
本文作者的個人檔案頁面。
Go Komura
小村軟體有限公司 代表
以 Windows 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。