核心流程
- 上傳 Word 檔至伺服器
- 伺服器端解析內容轉為 HTML
- 前端載入 HTML 內容呈現（含圖片路徑處理）
方案一：Microsoft.Office.Interop.Word（傳統、重度相依）
// 需安裝 Office、設定 DCOM 權限
var app = new Microsoft.Office.Interop.Word.Application();
var doc = app.Documents.Open(wordPath);
doc.SaveAs(htmlPath, Microsoft.Office.Interop.Word.WdSaveFormat.wdFormatHTML);
doc.Close(); app.Quit();
| 優點 | 缺點 |
|---|
| 轉換保真度高（官方引擎） | **伺服器必須安裝完整 Office**，授權成本高 |
| 支援 .doc / .docx 全格式 | DCOM 設定複雜、權限問題頻發、非執行緒安全 |
| 多伺服器部署極其痛苦、不支援 Linux 容器化 |
結論：僅適合單機、內網、已有 Office 授權的舊專案維護。
方案二：Open XML SDK（官方、純 managed、免 Office）
// 僅支援 .docx (OOXML)，不支援 .doc (Binary)
using DocumentFormat.OpenXml.Packaging;
using DocumentFormat.OpenXml.Wordprocessing;
using (var doc = WordprocessingDocument.Open(docxPath, false))
{
// 需自行將 Open XML 元素轉 HTML，或使用第三方轉換器
// 如 OpenXmlPowerTools.HtmlConverter
}
| 優點 | 缺點 |
|---|
| 無 Office 相依、跨平台、NuGet 即裝即用 | **不支援 .doc (Word 97-2003)** |
| 可深度操控文件結構 | 轉 HTML 需自行實作或引入額外庫（如 OpenXmlPowerTools） |
| 效能佳、記憶體可控 | 複雜排版（浮水印、文字方塊、智慧圖表）轉換保真度較低 |
方案三：Aspose.Words（商業、功能最完整、推薦）
// 僅需一個 ~2MB DLL，無 Office、無相依
var doc = new Aspose.Words.Document(wordPhysicalPath);
doc.Save("d:\\1.html", Aspose.Words.SaveFormat.Html);
| 優點 | 缺點 |
|---|
| 支援 .doc / .docx / .rtf / .odt 等全格式 | **商業閉源、需購買授權**（單開發授權約 $999+，網站授權更高） |
| 轉換保真度極高、圖片/表格/樣式/目錄完整保留 | 破解版/反編譯修改涉及法律風險，企業專案不可取 |
| 圖片自動輸出至同目錄，HTML 相對路徑 | DLL 體積較大（~20MB 含相依） |
| API 直覺、文件豐富、技術支援完善 | |
圖片路徑後處理（通用需求）
Aspose 輸出 HTML 圖片標籤為 <img src="image001.png">，需替換為虛擬路徑：
string html = File.ReadAllText(htmlPath);
html = Regex.Replace(html, @"<img\s+src=['""]([^'""]+)['""]",
m => $"<img src='{VirtualPath}/Images/{m.Groups[1].Value}'");
其他替代方案簡評
- LibreOffice Headless + unoconv：Linux 可用、免費、轉換品質不錯，但需維護進程、啟動慢、字型相容性問題。
- Pandoc：支援格式極廣、命令列工具，但 Word 複雜排版轉 HTML 仍有落差。
- Google Docs API / Microsoft Graph API：雲端轉換、需網路、授權流程複雜、資料隱私考量。
選型建議決策樹
- 預算充足、追求最高保真度、商業專案 → Aspose.Words
- 僅處理 .docx、團隊有開發能力、開源偏好 → Open XML SDK + OpenXmlPowerTools
- 舊專案已深度綁定 Interop、單機部署 → 維持 Interop，規劃遷移
- Linux 容器化部署、免費開源 → LibreOffice Headless 或 Pandoc
