HTML 電子郵件轉 Markdown｜Outlook、Gmail 免上傳

Q: 郵件的 layout 會原樣轉成 Markdown 表格嗎？

不會。layout 用的嵌套 會被扁平化後崩塌（實測中 6,491 bytes 的全文原始碼變成了 12 欄的扁平表格）。對策是只取出本文區塊來轉換。另一方面，郵件本文中包含的真正資料表格（例如費用表、訂單明細）會正確轉成正常的 pipe 表格。

Q: 郵件中的圖片怎麼處理？

src 指向一般 web URL（https://...）的圖片會轉成 ![alt](圖片URL) 形式的 Markdown 圖片語法。cid: 開頭的引用是郵件內部的附加資源，在郵件 client 外面無法顯示。1x1 的 tracking pixel 建議轉換後手動刪除。

想把電子報內容存進個人筆記、把收到的規格變更通知轉成技術文件、或是把郵件往還當作 context 傳給 LLM，理由很多。但不管什麼原因，一打開 HTML 郵件的原始碼，你看到的跟一般網頁完全不同層級的髒亂 markup 會讓你嚇到：好幾層嵌套的 layout 表格、每個元素都掛上 style 屬性、還混著看不見的 tracking pixel。這篇文章用實測數據說明同一封郵件「從哪裡複製」會導致完全不同的轉換結果，然後帶你從 Gmail、Outlook、.eml 檔案中正確取出 HTML 本文，以及轉換後的後續整理。

先講結論：要保留什麼決定走哪條路

選工具之前，先決定的是成果物。你想從郵件中把哪些資訊保留到 Markdown，最短路徑就不一樣。

只要保留打開的幾封郵件的本文文字：瀏覽器內轉換最快。把本文區塊的 HTML 複製，貼到 HTML to Markdown 轉換器。免費、不需註冊、貼上不會傳送到任何伺服器
要保留寄件者、主旨、日期、引用回覆串、附件清單，或手上有幾十封 .eml 檔案：能直接解析 .eml 的 CLI 工具（後述的 eml2md 系列）比較合適
要建置定期匯入郵件的自動化 pipeline：用 Python 的 email 模組搭配 markdownify 套件，取出你要的 MIME part 再轉換

兩個前提要注意。第一，瀏覽器內轉換工具處理的是「取出的 HTML 文字」，不是 .eml 檔案本身。.eml 是包含 header 與編碼後 multipart 的 MIME container，不是 HTML 文件，直接貼上無法轉換。第二，大多數郵件是 multipart/alternative 格式，同時包含 HTML 版與純文字（text/plain）版。如果純文字版就夠用，可能根本不需要轉換。要把郵件內容傳給 LLM 時，Markdown 與 HTML 哪種格式更省 token，見 LLM Markdown vs HTML。

實測：複製範圍決定結果完全不同

用一封重現典型電子報結構的樣本郵件（手製 fixture，不是真實寄出郵件的統計），以與 FormatArc 轉換工具相同設定的 Turndown 7.2.4 跑過比較。測量日 2026-07-17，重現腳本、樣本、原始結果數據在 repo 的 scripts/benchmarks/html-email-to-markdown/ 中。以下所有數值都來自這次實測。

全文貼上會變成 12 欄的扁平表格

樣本郵件的全文原始碼大小是 6,491 bytes。裡面包含 8 個 <table> 元素（全部是 layout 用的嵌套）、33 個 style 屬性、3 個 MSO 條件式註解、1 個 1x1 tracking pixel、4 個點擊追蹤用的 redirect 連結。

直接拿去轉換，輸出會壓成一個 12 欄的 pipe 表格（含分隔列共 10 列）。嵌套表格的所有列都被扁平化成一個大表格，本文相同的句子在多個儲存格中重複出現，當作表格不能用、當作文章也讀不下去。另外 <head> 內的 <title> 文字與 <style> 區塊 380 bytes 的 CSS 會直接漏到輸出開頭。

這個表格崩塌的現象，是因為轉換規則把表格所有列收集成一個 pipe 表格。資料整理過的普通表格運作正常，但跟 layout 用的嵌套表格完全不相容。不管用哪個工具，把包含 layout 表格的郵件全文直接轉換，都不會得到乾淨的結果。

只貼本文區塊就能得到 477 字的乾淨 Markdown

從同一封郵件只取出本文區塊（包著本文內容的元素的 HTML，1,086 bytes）來轉換，結果完全不同。輸出是 477 字的整齊 Markdown：標題變 #、段落維持段落、連結維持連結。8 個 style 屬性全部被移除。

不過點擊追蹤用的 redirect URL 會原樣保留為連結目標，這是轉換後處理階段的事（後述）。結論很簡單：不要貼全文，只貼本文區塊。

為什麼郵件 HTML 會這麼亂

郵件 HTML 跟一般網頁 HTML 有結構性差異，原因很具體：

Layout 全部用嵌套表格：郵件 client 的 CSS 支援範圍極有限。例如 Windows 版經典 Outlook 是用 Word 的 HTML 渲染引擎來顯示郵件，Microsoft 官方文件有說明在新分頁中開啟，該文件的不支援清單中列出 float、position、max-width。表格以外沒有其他 layout 手段
MSO 條件式註解：<!--[if mso]> 開頭的條件式註解是專門給 Outlook 看不同 markup 的機制。轉換時被當作 HTML 註解處理，自動從輸出中消失
內聯 style 屬性：因為很多 client 會忽略外部樣式表或 <style> 標籤，所有視覺設計都直接內聯到每個元素的 style 屬性上
追蹤元素：開啟追蹤的 1x1 透明圖片、點擊追蹤的 redirect 連結（https://click.example.com/track?dest=... 這種形式）混在本文 markup 中

從郵件 client 取出 HTML 本文

轉換成敗在這個步驟。逐一 client 說明：

最可靠的方法：開發者工具（F12）複製本文區塊

Gmail 以及任何 webmail 都適用，對應實測中「只轉本文區塊」的情境。

在瀏覽器中打開郵件，在本文文字上右鍵點擊，選「檢查」（Inspect）。
在開發者工具（Elements 分頁）中，把選取範圍往上提一到兩層，到包著整個本文（段落、標題、圖片都包含在內）的 parent 元素。
在該元素上右鍵，選 Copy > Copy outerHTML。

這樣就能把解碼後的純本文 HTML 複製到剪貼簿，不包含郵件匣 UI 或 header 區域。

「顯示原始訊息」的陷阱 — quoted-printable 編碼

Gmail 的「顯示原始訊息」或 Thunderbird 的原始碼檢視，看到的是 MIME 訊息整體。裡面的 HTML part 通常用 Content-Transfer-Encoding: quoted-printable 編碼，直接複製會得到壞掉的 HTML：

Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

<td style=3D"padding:24px 32px 12px 32px; font-family:Arial, Helvetica, san=
s-serif;">

這裡的 =3D 是 = 的編碼表示，行末單獨的 = 是 soft line break（解碼時會跟下一行連接）。RFC 2045 第 6.7 節在新分頁中開啟規定的 quoted-printable 規則不只一種，在編輯器中單純把 =3D 全部替換回來不一定能正確還原。解碼應該在 MIME part 層級處理，所以與其從原始碼檢視複製，不如改用開發者工具或下面的 CLI / Python 路徑。

Outlook、Apple Mail、Thunderbird

Windows 版經典 Outlook：從訊息右鍵選單或功能表執行「顯示原始碼」，解碼後的 HTML 會開啟在編輯器中。從這裡複製就不會遇到 quoted-printable 的問題
Apple Mail 與 Thunderbird：可以把訊息拖出或用「另存為」存成 .eml 檔案。.eml 是 MIME container，用文字編輯器打開找 HTML part 不如直接交給下一節的 CLI 工具，更快也更準確

用 FormatArc 轉換 — 無上傳的瀏覽器內處理

拿到本文區塊的 HTML 之後，轉換只要 3 步：

打開 HTML to Markdown 轉換器。
把複製的 HTML 貼到左側輸入區。
點轉換按鈕，右側即時輸出 Markdown 結果。

在瀏覽器內將 HTML 電子郵件本文轉換為 Markdown 的 FormatArc 介面

所有轉換都在瀏覽器內的 JavaScript engine 中執行，貼上的內容或郵件資料不會傳送到任何外部伺服器。處理有保密協議的商業郵件、內部通知、包含個人資訊的郵件時，這是跟上傳型線上轉換網站最大的安全差異。判斷標準整理在線上轉換工具的安全性。HTML 轉 Markdown 的基本操作與元素對照表，見 HTML 轉 Markdown 指南。

轉換後的檢查清單

即使只轉本文區塊，郵件特有的殘留還是會跑到 Markdown 裡。儲存或分享前檢查以下 5 項：

追蹤連結還原：https://click.example.com/track?dest=https%3A%2F%2F... 這種點擊追蹤 redirect URL，把 dest= 參數做 URL 解碼還原成真正的目標連結，或是不必要的話直接移除。不要為了「確認連結有效」而批量在瀏覽器中打開這些 URL，那會觸發點擊追蹤計數
追蹤 pixel 移除：![](https://.../open/...) 這種 alt 為空的 1x1 追蹤圖片如果還留著，直接刪掉
cid: 內聯圖片處理：本文可能出現 ![](cid:image001) 這種引用，這是 multipart/related 中附加的內部圖片，在郵件 client 外面無法顯示。需要圖片的話要從郵件或 .eml 中另外匯出替換
  空白與空行清理：HTML 郵件中用於間隔調整的   可能產生多餘的連續空白或空行
署名與取消訂閱 footer：底部的寄件者署名、免責聲明、電子報取消訂閱連結、之前回覆的引用文，決定保留多少

批量轉換 .eml — CLI 與 Python

有好幾封 .eml 檔案要一次處理、或要把 header 的寄件者、收件者、日期等 metadata 也一併保留成 Markdown 時，用能正確解析 MIME 結構的專用工具。

CLI 方面，pip 可安裝的 eml-to-md在新分頁中開啟會輸出包含 header 資訊的 Markdown，也適合「不給 AI agent 整個郵件匣存取權、只傳需要的 context」這種用途。Rust 寫的 eml2md在新分頁中開啟也有。

pip install eml-to-md
eml2md message.eml            # 單封轉換
eml2md *.eml -o converted/    # 整個資料夾批量轉換

要用 Python 組自動化 pipeline 的話，用標準函式庫的 email 模組在新分頁中開啟搭配 markdownify在新分頁中開啟套件。重點是：用 binary 模式（rb）讀檔、傳入 policy.default、用 get_body() 選取 part。get_content() 會自動處理 quoted-printable 與 Base64 的解碼。

import email
from email import policy
from markdownify import markdownify

with open("message.eml", "rb") as f:
    msg = email.message_from_binary_file(f, policy=policy.default)

body = msg.get_body(preferencelist=("html", "plain"))
print(markdownify(body.get_content()))

除此之外，取出的 HTML 也可以交給 pandoc在新分頁中開啟處理，或在 terminal 中用 pipeline 串接（cat body.html | formatarc html-to-markdown）。FormatArc 的 CLI 版見 formatarc npm 套件。

方法比較表

轉換方式	適合情境	所需環境	Header・串列資訊	機密郵件處理
HTML to Markdown 轉換器（瀏覽器）	打開的幾封郵件的本文	瀏覽器（免費・免安裝）	僅本文	瀏覽器內處理（不外傳）
eml2md 系列 CLI	幾十封 .eml 檔案批量	pip / cargo	含 header	本機處理
Python（email + markdownify）	定期自動化 pipeline	Python 環境	自由控制	本機處理
上傳型線上轉換器	其他工具都無法使用時	瀏覽器	視工具而定	傳送至外部伺服器（有限次或付費制）

常見問題

Gmail 中郵件的 HTML 原始碼在哪裡看？

郵件右上方的選單中選「顯示原始訊息」，可以看到完整的 MIME 訊息。但裡面的 HTML 通常經過 quoted-printable 編碼，直接複製會得到壞掉的標籤。只要本文的話，在本文上右鍵選「檢查」，複製本文 container 元素的 outerHTML 最可靠。

郵件的 layout 會原樣轉成 Markdown 表格嗎？

不會。layout 用的嵌套 <table> 會被扁平化後崩塌（實測中 6,491 bytes 的全文原始碼變成了 12 欄的扁平表格）。對策是只取出本文區塊來轉換。另一方面，郵件本文中包含的真正資料表格（例如費用表、訂單明細）會正確轉成正常的 pipe 表格。

郵件中的圖片怎麼處理？

src 指向一般 web URL（https://...）的圖片會轉成 ![alt](圖片URL) 形式的 Markdown 圖片語法。cid: 開頭的引用是郵件內部的附加資源，在郵件 client 外面無法顯示。1x1 的 tracking pixel 建議轉換後手動刪除。

機密郵件內容貼到線上轉換器安全嗎？

上傳型的一般線上轉換器，貼上瞬間資料就傳到外部伺服器，有被儲存的風險。FormatArc 的轉換完全在瀏覽器內記憶體中完成，不透過網路傳送至任何伺服器，所以內部工作郵件或重要文件也可以安全轉換。

.eml 檔案能直接貼上轉換嗎？

不能。.eml 不是純 HTML 文件，是包含 header 與編碼後 multipart 資料的 MIME container 檔案。單封的話在瀏覽器中複製本文區塊來轉換，多封的話用 eml2md 系列 CLI。

總結

HTML 電子郵件轉 Markdown，最關鍵的是「從哪裡複製」。全文原始碼直接貼上，嵌套的 layout 表格會壓成 12 欄的扁平表格、CSS 也會混進來；只複製本文區塊，就能得到 477 字的乾淨 Markdown（實測依據：scripts/benchmarks/html-email-to-markdown/）。

瀏覽器中打開的幾封郵件只要本文：用開發者工具複製本文區塊，貼到 FormatArc 的 HTML to Markdown 轉換器
多封 .eml 檔案或需要保留 header：用 eml2md 系列 CLI 或 Python 的 email 模組比較有效率
不管走哪條路徑，轉換後清理追蹤連結與 tracking pixel 的後處理都要包含在流程裡