若要在 Power Automate 中將 JSON 轉換成 HTML 表格，請將 JSON 貼到一個嚴格輸入的轉換器中，複製產生的語意表格片段，然後注入到 Compose、HTML 電子郵件或核准動作中，無需撰寫結構描述、無需手動逸出，也沒有指令碼注入風險。Power Automate 內建原生的 Create HTML table 和 Create CSV table 動作，但它們要求表格陣列結構，只會扁平化所發現的欄位，而且在 JSON 包含巢狀物件、缺少欄位或對 HTML 敏感的字串（例如 <、>、& 和引號）時，行為不一定穩定可預期。一個在瀏覽器端運作、在本機產生已逸出的語意標記的轉換器，可以給你一個可直接複製的片段，無需上傳任何資料就能交給流程的輸入使用。JSON to HTML Table Converter 採用了這種做法：它會剖析嚴格的 JSON、合併所有記錄的欄位、對每個標頭和儲存格進行 HTML 文字內容的逸出，並使用 React 文位元組點而非注入的 HTML 來渲染預覽，因此你在預覽中看到的值，就是你的流程在取用該片段時會收到的值。
為何 Power Automate 的原生表格動作有時不敷使用
Power Automate 的 Create HTML table 動作位於 Data operations 群組中，會將記憶體中的陣列轉換成表格樣式的 HTML 字串。對於扁平陣列（每一列都公開相同的屬性）而言運作良好，並會將標記寫成單一字串，你可以將其串接進 Office 365 Outlook、Send approval mail 或 Create file 動作中。當 JSON 來自 HTTP 觸發程序、具有查找欄位的 SharePoint 清單、Dataverse 查詢，或傳回巢狀物件的自訂連接器時，麻煩就出現了。原生命作往往會將巢狀陣列和物件渲染成空白儲存格或字面文字「object」，無法區分缺少的欄位與明確的 JSON null，也無法保證每個儲存格中都對 < 和 & 等字元進行逸出。
舊版的 Convert JSON to HTML table 動作正是因為這些邊角案例而被棄用。Microsoft 現在將使用者導向較新的 Create HTML table（建構於 Power Fx 之上），但仍沿用相同的結構假設。一個獨立轉換器會記錄其逸出規則、預先拒絕格式錯誤的輸入，並產生一份純語意表格，讓開發人員得以掌控最終出現在電子郵件內文、Teams 自適應卡片或核准表單摘要中的標記。
轉換器強制執行的 JSON 輸入規則
Power Automate 流程接受任何 HTTP 動作所回傳的內容，但轉換器本身刻意保持嚴格。它使用與 RFC 8259 相同的規則來剖析 JSON，並會拒絕 JavaScript 開發人員可能會蒙混過關的輸入：行註解和區塊註解、結尾逗號、undefined、NaN、Infinity、BigInt 後綴，以及帶引號鍵或單引號字串的 JavaScript 物件常值，都會在任何表格產生之前失敗。
當你餵入 Power Automate 輸出時，有兩項結構規則最為重要。單一物件會成為一列，而陣列必須至少包含一個物件，且每個陣列成員本身都必須是物件。基本型別的根（例如數字、字串，或由基本型別組成的陣列）會被拒絕，因為它們無法提供穩定的具名欄位。若你的流程傳回純量負載，請先將其包進一個屬性中，或在送入轉換器之前將其展開為物件。
物件鍵的順序是另一個經常令人措手不及的規則。欄位會依照首次觀察到的鍵順序出現：第一筆記錄的鍵排在前面，後續記錄中新出現的鍵會附加在後面。標準 JSON 剖析也會在產生表格之前先處理重複的成員名稱，因此重複的鍵無法作為資料使用，應在上游 API 而非轉換器中加以修正。
JSON 輸入結構與轉換器的對應方式
| 輸入結構 | 是否接受？ | 產生的表格 |
|---|---|---|
| 單一物件 | 是 | 一列資料，使用該物件本身的鍵 |
| 物件陣列 | 是 | 每個物件一列資料，依首次出現順序合併欄位 |
| 基本型別陣列 | 否 | 拒絕，無法形成穩定的具名欄位 |
| 單一基本型別（字串、數字、布林值、null） | 否 | 拒絕，必須先包進屬性中 |
| 含巢狀陣列的物件 | 是 | 巢狀陣列在儲存格中序列化為精簡 JSON |
| 含註解或結尾逗號的 JavaScript 常值 | 否 | 在任何欄位建立之前即拒絕 |
| 含重複鍵的物件 | 部分 | 剖析器保留最後存活的值，欄位由該值建立 |
將 JSON 轉換為 HTML 表格片段
- 將一個嚴格的 JSON 物件，或一個非空物件陣列，貼到轉換器的輸入區域。請使用 Power Automate 流程中 Compose 輸出或 HTTP 觸發程序主體所呈現的原始內容，不含任何註解或結尾逗號。
- 執行轉換。工具會剖析 JSON、合併所有記錄的欄位，並在輸出旁邊渲染預覽窗格。請閱讀預覽以確認欄位順序、列數以及任何巢狀資料所顯示的值。
- 檢查欄位模型。後續記錄的新欄位應出現在標頭列右側。缺少的儲存格應顯示為空白。明確的 JSON null 值應顯示為「null」字樣。巢狀陣列和物件應以精簡 JSON 形式出現在單一儲存格內。
- 檢查任何對 HTML 敏感值的逸出情況。包含 <img onerror=...>、「雙引號」或「單引號」的負載，在預覽中應顯示為字面字元，而非被剖析為標籤。若發現任何異常，請修正上游 JSON，而非編輯標記。
- 從輸出面板複製 HTML 片段。產生的結果是一個 <table> 元素，其中 <thead> 包含單一標頭列，<tbody> 包含所有資料列。沒有附加任何行內樣式、CSS 類別、標題、ID 或無障礙屬性。
- 在目的地文件中加上標題、欄位寬度、邊框或交替列色彩，然後在實際將使用該片段的 Power Automate 動作中進行測試。
將 HTML 放入 Power Automate 流程中
在 Power Automate 設計工具中，注入自製 HTML 最安全的位置，是一個會將內容餵給下游電子郵件、核准、Teams 或 Create file 動作的 Compose 動作。將複製的片段貼到一張名稱例如 HtmlTableFragment 的 Compose 卡中，使流程參考變成 outputs('HtmlTableFragment')。這個單一字串參考能讓流程其餘部分保持可讀性，並讓你在不更動下游卡片的情況下替換來源 JSON。
若是核准或 Office 365 Outlook 電子郵件，請新增 Send approval mail 或 Send an email (Office 365 Outlook) 動作，並將 Compose 輸出放入 Details 或 Body 欄位。若你的租用戶需要 HTML 骨架，請將其包入簡單的 HTML 結構中，並在表格應呈現的位置插入 Compose 參考：
- 核准內文：將片段貼到 Send approval mail 動作的 Details 欄位中，並確認核准者看到的是真正的欄位標頭。
- Outlook 內文：在 Send an email 動作的 Body 欄位中，將其放入 <html><body> 包裹中，使表格以實際標記而非逸出文字的形式呈現。
- Teams 自適應卡片：從 Adaptive Card JSON 運算式參考 Compose 輸出，或直接將其貼到 Post message 動作的 Message 欄位，並依該動作的模式確認 Teams 將其視為文字或 HTML。
- SharePoint 欄位格式化工具：將片段送入一個 Send an HTTP request 動作，目標為欄位格式化工具端點，其中逸出的文字字元須符合 SharePoint 在 JSON 負載中所要求的格式。
第一次執行後，請在實際信箱中驗證電子郵件或核准內文，而非僅依賴執行歷程的預覽。Power Automate 有時會對已逸出的內容再次進行逸出，因此請再次確認資料中的 < 和 & 並未在第二輪處理時變成 < 和 &。關於接收端的視覺美化，Power Automate HTML 表格格式化指南 涵蓋了在 Outlook、Teams 和 SharePoint 中皆適用的標題位置、邊框樣式與欄位寬度設定。
逸出機制如何保護下游動作
由於片段最終會出現在 HTML 電子郵件、自適應卡片和 SharePoint 欄位格式化工具中，每個標頭和儲存格在被放入 <th> 或 <td> 標籤之前，都會先針對 HTML 文字內容進行編碼。& 會變成 &，小於符號會變成 <，大於符號會變成 >，雙引號會變成 "，單引號（撇號）會變成 '，如 WHATWG HTML 語法 規範所定義。因此像 <script>alert(1)</script> 這樣的值，會以可見文字的形式抵達你的信箱，永遠不會成為標籤；相同的行為也能防止屬性內容中出現諸如 " onmouseover="alert(1) 的逃逸攻擊。
預覽窗格會再次落實這個承諾。它是使用原始儲存格值、由 React 文位元組點建構而成，因此轉換器絕不會在產生的片段上呼叫 innerHTML。若你在預覽中看到字面的 <script> 字元，下游消費者在文字內容中渲染該標記時，也會看到相同的字元。若你的目的地是透過 innerHTML 注入該片段，逸出規則同樣適用，而你刻意放置的任何 HTML 都會被啟用——這對於刻意的注入是正確行為，對於意外的注入則是安全的行為。
對於能控制部分 JSON 欄位的攻擊者而言，僅靠這層逸出機制並不足夠；請同時搭配目的地本身的內容安全策略 (Content Security Policy)，將不受信任的內容保留在文字內容而非屬性內容中，並避免將片段貼入允許行內指令碼的文件。OWASP XSS 防範速查表 說明了將已逸出文字轉化為完全防禦接收點所需的周邊控制措施。
Documented Limits Inside the Converter
The converter is bounded, and every limit is enforced by failing the conversion rather than by silently truncating. Knowing the ceiling of each layer up front keeps your Power Automate run from blowing up on the largest JSON array the upstream API can return. The table below lists the documented limits straight from the tool.
| Resource | Limit | Behaviour when exceeded |
|---|---|---|
| Input characters | 500,000 | Conversion fails with a clear error |
| Data rows | 10,000 | Conversion fails before partial output |
| Columns | 200 | Conversion fails with a column-count message |
| Output characters | 5,000,000 | Conversion fails rather than truncate the HTML |
Power Automate imposes its own per-action and per-flow ceilings for inputs and outputs, and those numbers vary by tenant and licence. For a safe handoff, sample the largest array your upstream connector returns, run it through the converter, and compare both the resulting fragment size and the row count against your tenant's action limits before you publish the flow.
Related reading: Avoid Mistakes When Converting JSON to Rust Structs.