Power Automate 的 Create HTML table 動作會回傳沒有內聯樣式、沒有 <tbody> 包裝標籤、且屬性未加引號的原始標記——這樣的結果幾乎總是在能可靠地呈現在電子郵件內文或 SharePoint 頁面之前需要清理。這個動作擅長從陣列產生資料列與儲存格，但刻意略過了呈現樣式:沒有 border-collapse 規則、沒有儲存格內距、沒有隔行變色的背景，也沒有字型大小，因為 Power Automate 預期你會自己用下游字串串接，或在相同運算式中加入一個 <style> 區塊來補上這些樣式。一旦這個字串送到 Outlook、Gmail、Teams 調適型卡片 fallback 或 SharePoint 頁面，接收端的解析器會套用各自的規則——而在生產環境中，格式出問題往往就是發生在這裡。瀏覽器會默默插入缺少的 <tbody>、將標籤名稱轉為小寫，並為屬性加上引號。電子郵件用戶端可能會剝掉樣式、整個 <style> 區塊，或拒絕接受針對 HTML 屬性設定的 class。若想停止猜測收件者實際會看到的結果，你可以預覽瀏覽器解析器實際產生的內容。HTML Cleaner 工具會以 text/html 模式把你的 HTML 片段送進 DOMParser，只序列化 body.innerHTML，並把標準化後的結果顯示在一個唯讀的文字區中。這能讓你在把表格貼回流程或交給設計師之前，先對標準化後的表格有一個可預期的樣貌。

how to format html table in power automate
如何在 Power Automate 中格式化 HTML 表格

Create HTML Table 動作實際輸出的內容

Create HTML table 動作接收一個陣列、一組可選的欄位，以及一個標頭標籤，然後回傳一個包含已渲染表格的單一字串。其確切的標記只是堪用，並不算精緻。預設情況下，Power Automate 會產生類似下列結構的輸出:

  • 小寫標籤，例如 <table>、<thead>、<tbody>、<tr>、<th> 與 <td>，大多數瀏覽器都能毫無問題地接受。
  • 未加引號的屬性，出現在儲存格上，特別是可能包含 width:100% 或 color 運算式的 style 值。
  • 完全不包含 CSS，除非你自己在運算式中串接一個 <style> 區塊，或加上 inline style="" 屬性。
  • 在某些邊緣情況下，儲存格或資料列沒有結尾標籤，寬容的 HTML 解析器會在渲染時自動修補。

這個輸出雖然正確到足以讓瀏覽器渲染，但很少是設計師想要的結果。大多數讀者會預期有內距、邊框，以及用視覺上區隔第一列與資料列的標頭背景。Power Automate 中典型的變通做法，是建立第二個字串，用一個 <style> 區塊、一個帶 class 的外包 <div>，或每個儲存格上的 inline style 屬性，把動作的輸出包起來。這些做法都沒有改變解析器實際看到的底層結構——它們只是新增了解析器必須遵循的宣告。

為什麼瀏覽器標準化會改變你貼回去的輸出

每個使用你 HTML 字串的接收端，在渲染之前都會重新解析標記。Outlook 使用 Word 的 HTML 引擎。Gmail 套用自己的清理規則。SharePoint 則依賴瀏覽器的 DOM。這代表解析器所產生的標記，就是收件者實際看到的標記，而非 Power Automate 原本輸出的字面值。根據 WHATWG HTML Living Standard,text/html 解析器刻意設計得寬容:它會把標籤名稱轉為小寫、為屬性值加上引號、插入隱含的元素(例如 <tbody>)，並修補一些遺漏的結尾標籤。

格式不一致的問題也會在這裡悄悄出現。Power Automate 輸出為 style=width:100% 的屬性，經過任何瀏覽器解析器後都會被加上引號成為 style="width:100%"，這才是收件者實際收到的內容。大寫寫成的 <TABLE> 會變成 <table>。在字串處理過程中遺失結尾標籤的資料列，會在正確的邊界被靜悄悄地閉合。這個結果在現代瀏覽器之間是一致的，因為它們遵循相同的 WHATWG 規格，但它仍可能與你的來源字串有些差異，而這些差異在 diff、除錯與下游自動化時可能很重要。在把字串提交到電子郵件動作之前，先透過解析器預覽跑一次，就可以得到與收件者相同的結果。

使用 HTML Cleaner 標準化產生的表格

在你把表格字串提交到電子郵件動作或 SharePoint HTTP 要求之前，先用 HTML Cleaner 跑一次，看看瀏覽器實際會產生的 body 標記。這個工具只做標準化，絕不會加上縮排美化，也絕不會壓縮或重寫你的 CSS。輸出結果就是解析後文件的 body-only 序列化內容。

  1. 從 Create HTML table 動作(或是加上 <style> 區塊的包裝運算式)複製 HTML 字串。
  2. 開啟 HTML Cleaner，把片段貼到輸入區。超過 500,000 個 UTF-16 字碼單位的輸入會在解析前被拒絕，因此請先精簡大型表格。
  3. 決定是否要啟用 Remove HTML comment nodes 選項。Power Automate 範本有時會帶有除錯註解——啟用會把它們移除，停用則會保留。
  4. 標準化輸入，並在唯讀文字區中讀取輸出。序列化取自 body.innerHTML，因此輸入中任何 <!DOCTYPE>、<head>、<title>、<meta> 與 <link> 內容都會刻意被排除在結果之外。
  5. 複製完整的結果，並在貼回 Power Automate 之前，先判斷目的地是否也需要一個真正的 HTML 清理器。標準化並不等於安全性;片段中任何 <script>、onerror 或 javascript: URL 都會原封不動地保留下來。

你複製的輸出，是一份由 DOMParser.parseFromString 在 text/html 模式下產生的卸離文件的 body。解析過程中不會執行 script，也不會渲染任何即時預覽，但瀏覽器仍可能會抓取 <iframe> 或 <img> 元素所參考的資源。如果你的表格內嵌了遠端圖片，標準化時請預期這些要求會從你的瀏覽器發出。

瀏覽器解析器自動執行的表格修補

下面的對照表整理了當你把 Power Automate 的表格字串貼到 HTML Cleaner 時最常見的標準化結果。請把它當作檢查輸出時的核對清單。

Power Automate 輸出中的來源樣式瀏覽器解析器產生的結果
大寫的 <TABLE><table>(由 WHATWG tokenization 轉為小寫)
資料列內容沒有明確的 <tbody> 包裝由樹狀建構器插入隱含的 <tbody>
style=width:100%(未加引號的屬性)style="width:100%"(在序列化時加上引號)
缺少結尾標籤的儲存格或資料列修補後的標記，由解析器推斷出正確的邊界
字串中殘留的 <!-- debug: iteration 7 -->啟用註解移除選項時會被刪除;否則保留下來

這些修補在現代瀏覽器之間是一致的，因為每個渲染器都遵循 WHATWG HTML Living Standard。它們並不保證你還原出來的結構與你輸入的完全一致——格式錯誤的輸入會被修補，而不是像 XML 那樣回報錯誤——但它們已經足夠可靠，讓 HTML Cleaner 的輸出能忠實預覽收件者所看到的 DOM。

何時仍需要針對目的地的清理器

標準化改變的是標記的撰寫方式，並不會改變這個標記被允許做什麼。HTML Cleaner 的契約很明確:script、事件處理屬性、javascript: URL、<iframe>、表單、inline style、data 屬性與未知元素，都會與解析後的內容完全一致地保留下來。如果你的 Power Automate 流程正在渲染使用者提供的內容——例如 SharePoint 清單欄位值、表單回應、留言——那麼你標準化過的字串，在貼到實際運作的頁面或電子郵件內文中時，仍然具有危險性。

在這些情況下，請把 HTML Cleaner 與一個針對目的地的 HTML 清理器搭配使用。Outlook、SharePoint、Teams 與公開網站的政策各不相同，針對其中之一設定的清理器，不會適用於其他用途。正確的模式是:先標準化以查看解析器產生的內容，再依目的地的規則進行清理，最後再送出。瀏覽器的 innerHTML 參考文件也記載了同樣的風險:片段序列化是為了檢查之用，並非用於安全發佈。

如果你還需要把表格的結構化資料以 JSON 形式往下游傳送——例如寫入 Dataverse 資料列或 Logic App 陣列——關於將 HTML 表格轉為 JSON 給 Power Automate 使用的配套指南，涵蓋了本文未涉及的解析部分。

把輸出貼回 Power Automate 之前的快速核對清單

每次把標準化後的表格字串從 HTML Cleaner 複製出來並貼回流程時，請依序檢查下列項目:

  • 確認輸出不是空的。解析或移除註解後得到空白的 body，是合法的零長度結果，但這通常代表你的輸入已經損壞到無法修補。
  • 確認輸出低於 1,000,000 個 UTF-16 字碼單位的上限。HTML Cleaner 會以明確的訊息拒絕，而不是切片處理。
  • 抽查你的 <style> 區塊是否存活下來。inline CSS 與 style 元素會被標準化保留下來，因此針對 HTML 元素的 class 仍應能正確對應。
  • 如果你的下游範本依賴 Outlook 的條件式註解(<!--[if mso]>)，請切換註解移除選項後再重跑一次。
  • 如果表格要放進電子郵件內文，請在最後的 Send an email 動作之前，把標準化的輸出交給一個針對目的地的清理器。單靠標準化並無法防範主動式內容。

遵循這個流程，就能把 Create HTML table 動作的精簡輸出，轉成一段你可以信賴的、可預期的字串，同時把呈現方式的決定權完全保留在你手中。瀏覽器解析器負責處理那些無聊的修補;HTML Cleaner 讓你看到它做了什麼;而流程的其餘部分則能專注在樣式、清理與傳送。

如果你正在權衡各種選項，如何逐步編輯 HTML 網頁對此有詳細說明。