M3U8 是什麼？HLS 串流協定與 .m3u8 播放清單完整指南

M3U8 是 HLS（HTTP Live Streaming）協定使用的 UTF-8 文字播放清單，本身不含影片畫面，而是一份列出影片片段（.ts 或 .m4s）URL、長度與位元率變體的清單。播放器讀取 .m3u8 後依序抓取片段，並即時拼接成可播放的影片串流——這正是 YouTube、Netflix、Twitch、Apple TV+ 等多數主流串流服務在 2026 年底層使用的核心機制。

你是否曾試圖從串流網站儲存影片，結果拿到的不是一個乾淨的 .mp4，而是上百個小小的 .ts 檔？或是打開瀏覽器的 Network 面板，期望看到乾淨的下載 URL，結果卻看到一串永無止盡的兩秒區塊源源不絕地流入？你沒做錯什麼。你看的是 HLS——現代網路上多數串流影片所仰賴的協定——而 HLS 不會把影片送成單一檔案。它送的是「食譜加零件」。

食譜是稱為 .m3u8 播放清單的小型文字檔。零件是短小、可獨立解碼的影片片段，你的播放器即時把它們拼接起來。HLS 由 Apple 於 2009 年為初代 iPhone 創建，並以 RFC 8216 標準化，如今幾乎所有主流瀏覽器、行動裝置和電視都原生支援。

本指南將走過 .m3u8 實際包含什麼、串流服務為何選擇這種設計、.ts 與 fMP4 片段如何配合、2026 年哪些平台使用 HLS，以及當你試圖把這類串流儲存到磁碟時會發生什麼。

重點摘要 {#key-takeaways}

• HLS 是串流協定，不是檔案格式。 它以播放清單（.m3u8）加上短片段（.ts 或 fragmented MP4），透過普通 HTTP 傳送影片。
• .m3u8 是索引，不是影片。 只儲存 .m3u8 拿到的是沒有食材的食譜。
• Apple 在 2009 年為 iPhone 創建 HLS，並在 2017 年標準化為 RFC 8216。如今它在 iOS/Safari 上是強制的，並在其他地方幾乎被普遍支援。
• 片段每段 2–10 秒的影片——短到足以在它們之間切換畫質，又長到能讓 HTTP 額外負擔保持合理。
• 主播放清單列出變體；媒體播放清單列出片段。 播放器讀取主清單、挑選變體，再載入該變體的媒體清單。
• .ts 片段正被 fragmented MP4（CMAF）取代，使同一個檔案可以從一個源服務 HLS 和 DASH 播放器。
• 多數現代串流都建立在 HLS 或 DASH 上，常常兩者並用——包括 YouTube、Netflix、Disney+、Twitch、Apple TV+ 與 Cloudflare Stream。

M3U8 vs MP4：核心差異對比

很多人第一次接觸 .m3u8 是因為下載影片時拿到的不是熟悉的 .mp4 而是一份小文字檔。兩者經常一起出現，但根本不是同一類東西——一個是清單（playlist），另一個是容器（container）。下面這張表把日常使用中最常被搜尋的差異一次說清。

一句話總結：M3U8 是「目錄」，MP4 是「成品檔案」。 線上觀看時瀏覽器拿到的是 M3U8 清單，依需求拉取片段；想離線長期保存或分享給朋友，最終通常還是要把片段合併回 MP4。

簡單的解釋

先把協定放一邊。想像一位導演要在不穩的網際網路上把一部完成的電影送給全世界的觀眾。送一個巨大的 MP4 是不行的：如果觀眾的連線在下載到一半時斷了，就得從零開始，而且沒有辦法在不重新下載的情況下切換畫質。所以導演把電影切成數百個 6 秒的短片，並寫一份編號的播放清單：「播 001，再播 002，再播 003……」觀眾的播放器下載播放清單、抓取前幾段、開始播放，其餘的在後頭串流而入。若連線變慢，播放器切換到下一段的較低畫質版本，畫面不會少一個。

這就是一句話的 HLS：把電影切成短片，加上一份 .m3u8 播放清單告訴播放器下一段要播哪一個。

從觀眾的座位來看，這個設計藏了不少魔法。拖曳即時生效，因為播放器可以直接跳到涵蓋目標時間點的片段，而不必從整個檔案串流過去。畫質切換很順，因為播放器可以為下一段挑不同變體，而不必重新開始播放。緩衝很輕鬆，因為播放器只需要領先幾段——通常 10 到 30 秒——而不必預先下載一大段檔案。直播能運作，因為當廣播者產出新片段時可以附加到播放清單，播放器每幾秒輪詢 .m3u8 取得新項目。

如果你曾納悶為什麼 YouTube 或 Netflix 在 Wi-Fi 不穩時還能順暢繼續，而直接從某個網站下載的 MP4 卻會停滯死掉，原因就在這。整套技術堆疊是圍繞「網路很亂、連線時斷時續」的假設打造的。關於播放器如何即時調整畫質的深入討論在另一篇文章；這裡只要注意，片段加播放清單的設計就是讓那種調整能成立的根本。

HLS 實際運作的方式

一條 HLS 串流是兩層播放清單加上一堆片段，全部透過普通 HTTP 提供。 沒什麼異國風，沒有自訂協定——你的瀏覽器原本就懂得做這裡的每一個部分。

主播放清單

播放器首先抓的就是主播放清單。這是一個副檔名為 .m3u8 的小型文字檔，列出該串流每個可用的變體——通常是不同的畫質等級——以及每個變體的頻寬與解析度。下面是一個經過輕度修剪的實際例子：

#EXTM3U
#EXT-X-VERSION:6
#EXT-X-STREAM-INF:BANDWIDTH=5000000,RESOLUTION=1920x1080,CODECS="avc1.640028,mp4a.40.2"
1080p/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=2800000,RESOLUTION=1280x720,CODECS="avc1.4d401f,mp4a.40.2"
720p/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=1400000,RESOLUTION=854x480,CODECS="avc1.4d401e,mp4a.40.2"
480p/index.m3u8

#EXTM3U 一行標記檔案為擴充 M3U 播放清單。#EXT-X-VERSION:6 宣告使用的 HLS 協定版本。每一個 #EXT-X-STREAM-INF 區塊描述一個變體：其位元率、解析度、編碼器字串，後面接一個指向該變體第二個播放清單的 URL。播放器讀取此檔案，估算你的頻寬，並挑選它認為你可以維持的變體。

媒體播放清單

一旦播放器挑了變體，它就會抓該變體的媒體播放清單。實際的片段 URL 就在這裡：

#EXTM3U
#EXT-X-VERSION:6
#EXT-X-TARGETDURATION:6
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:6.000,
segment000.ts
#EXTINF:6.000,
segment001.ts
#EXTINF:6.000,
segment002.ts
#EXT-X-ENDLIST

#EXT-X-TARGETDURATION:6 表示沒有任何片段長於 6 秒。每個 #EXTINF:6.000, 行宣告一個片段的精確時長，後接片段 URL。#EXT-X-ENDLIST 告訴播放器這是隨選視訊串流——不會再加任何片段。直播省略 #EXT-X-ENDLIST，播放器每幾秒重新請求此清單以發現新片段。

片段：.ts 與 fMP4

片段是短的視訊與音訊區塊——通常 2 到 10 秒——在關鍵影格邊界切開，這樣播放器可以從任一片段開頭開始解碼。當播放清單宣告 #EXT-X-INDEPENDENT-SEGMENTS，每個片段都保證可以獨立播放；沒有該旗標時，下游片段可能依賴更早片段中所攜帶的資料。歷史上片段是 MPEG-2 Transport Stream 檔，副檔名 .ts——和衛星與有線電視所用的容器格式相同。MPEG-TS 是為了雜訊多的廣播通道設計的，因此對部分損壞具有穩健性，任何能解碼 .ts 封包的播放器都能播放 HLS 片段。

典型片段長度是 2 到 10 秒。片段越短，延遲越低、位元率切換越靈活，但每分鐘的影片會有更多 HTTP 請求與額外負擔。片段越長，壓縮效率越高、請求越少，但對頻寬變化的反應較慢。Apple 原始規格建議 10 秒片段；現代服務通常落在 2–6 秒範圍。

自 2016 年起，業界一直從 .ts 遷移至 fragmented MP4 片段——具體是 Common Media Application Format (CMAF)，標準化為 ISO/IEC 23000-19。CMAF 片段使用和 MPEG-DASH 相同的 MP4 分段，這意味著 CDN 上的一組檔案可以同時服務 HLS 和 DASH 播放器。這是串流服務一項重大的成本勝利：一次編碼、一組位元組、兩種協定。YouTube、Netflix 和 Apple 提供的現代 HLS 串流幾乎全是 CMAF，而非傳統的 MPEG-TS。

全程都是 HTTP

HTTP Live Streaming 中的「HTTP」才是重點。線上沒有特殊協定——HLS 的每一個部分都跑在和你瀏覽器用來取 HTML 與 JPEG 同一個 HTTPS 請求上。CDN 喜歡這樣，因為它們本來就為 HTTP 做了最佳化。防火牆放行，因為看起來沒什麼異常。CDN 可以把熱門片段快取到邊緣。範圍請求、gzip、HTTP/2、HTTP/3、TLS——全部免費可用。

這也是 HLS 為什麼勝出。較早的串流協定如 RTMP、RTSP 和 MMS 需要專用連接埠、具狀態的伺服器、特殊的防火牆規則。HLS 看起來就像在提供大量小檔案的網站。

多數使用者不需要手動處理這一切——VidMost 在背景解析 .m3u8 manifest，並把片段合併為乾淨的 MP4。

你在真實世界中遇到 HLS 的地方

HLS 出現在 2026 年實質上每一個主要串流服務上，常與 DASH 並存。 Apple 在 2009 年發明 HLS，特別是為了把影片送到原版 iPhone——這台裝置無法在行動網路上良好處理漸進下載，而 Apple 想要一種對電信業者而言看起來只是 HTTP 流量的串流格式。此協定隨後成為網際網路上一大片區塊的預設方案。

• Apple 自家的服務僅使用 HLS。Apple TV+、iTunes Store、Apple Podcasts，以及每一段在 Safari、iOS 或 tvOS 上播放的影片，全都建立在 HLS 上。Apple 平台沒有內建 MPEG-DASH 解碼器，因此任何想在 iPhone 上播放的服務都必須提供 HLS 饋送。
• YouTube 在網頁和 Android 上的主要協定是 MPEG-DASH，但對 iOS、Safari、AirPlay 和多數 TV 應用提供 HLS。在 Safari 上 YouTube 打開瀏覽器開發者工具，你會看到 .m3u8 請求；在 Android 的 Chrome 上你會看到 DASH .mpd 請求。
• Netflix、Disney+、Hulu、Max 和 Amazon Prime Video 都採混合方式。它們的智慧電視與主機應用常使用 HLS 加 FairPlay 或 PlayReady DRM；網頁播放器常切到 DASH 加 Widevine。同樣的內容、不同的用戶端、不同的協定。
• Twitch 自 2014 年放棄播放端的舊版 RTMP 堆疊起便執行 HLS。Twitch 上每一條直播與每一段 VOD 底層都是 HLS。
• 直播鏡頭與創作者平台——Bigo Live、Chaturbate、OnlyFans 直播、Fansly 串流——幾乎都使用 HLS 進行瀏覽器播放，因為它不需外掛、又能容忍不穩的連線。
• 託管影片供應商如 Vimeo、Mux、JW Player 和 Cloudflare Stream 預設提供 HLS。若一個網站嵌入 Vimeo 或 Mux iframe，底下的影片幾乎可以肯定是 HLS。
• 體育與新聞廣播機構——ESPN、BBC iPlayer、DAZN、Sling TV——全都依靠 HLS 進行直播事件傳遞，常在上面加一層 DRM。

HLS 跳出 iOS 起源，是因為它解決了真實問題，不只是給 Apple 解決。等到 DASH 在 2012 年到來時，HLS 已經有了廣泛的 CDN 支援、實際運作的播放器與動能。如今這兩個協定共存；周到的串流服務會同時支援兩者，許多服務在兩個 manifest 格式下提供同一組 CMAF 片段。關於 DASH 與 HLS 的細部比較，姊妹文章從頭到尾介紹。

如果你想儲存影片，這意味著什麼

了解 HLS 的運作後，一個實際問題突然變得明顯：你無法靠「右鍵 → 另存為」拿到下載好的 HLS 影片。 原因有幾個是機制性的、幾個是微妙的，還有一兩個會讓你吃驚。

• 瀏覽器的「另存為」只會儲存 .m3u8。 .m3u8 是頁面開始播放時實際下載的東西——一個小型文字檔。儲存它你拿到的是食譜，不是食物。在 VLC 中開啟那個檔案有時可行（VLC 會跟隨裡面的 URL），但只在原工作階段仍有效且 URL 還沒過期時。
• 每個片段都是獨立的 HTTP 請求。 一段 30 分鐘、片段 6 秒的影片就是 300 次獨立的下載。你得列舉播放清單、抓取每個片段，然後依正確順序串接它們，才能作為單一檔案播放。
• 變體選擇是真實的選擇。 主播放清單列出多種畫質。選錯了會拿到一部原本以 1080p 串流的電影的 480p 副本。正確的選擇通常是你的儲存空間與耐性能吸收的最高頻寬變體。
• HTTPS 保護的是傳輸中的位元組，不是磁碟上的位元組。 片段 URL 幾乎總是透過 HTTPS 提供，因此網路上的竊聽者無法讀取你串流的內容。但一旦片段抵達瀏覽器，它就是明文影片——TLS 對已能存取回應的工具毫無阻擋。
• HLS 支援 AES-128 片段加密作為內容層。 當 .m3u8 攜帶 #EXT-X-KEY 標籤時，每個片段以 AES-128 加密，播放清單指向播放器透過 HTTPS 抓取的金鑰 URL。若儲存片段而沒有金鑰，你拿到的是一堆密文。這是內容加密，與傳輸安全分開，且內建沒有授權檢查——金鑰 URL 本身就是入口。
• 商業 DRM 是不同的問題。 Netflix、Disney+ 與 Apple TV+ 這類高級服務在 HLS 上疊上 FairPlay（Apple）、Widevine（Google）或 PlayReady（Microsoft）。線上加密仍以 AES 為基礎，但金鑰是在播放器在受信任裝置上證明授權後才由授權伺服器簽發，解密發生在硬體支援的安全模組中，畫面永遠不會接觸應用程式記憶體。完整介紹請見 什麼是 DRM 保護內容？。
• 令牌與簽署 URL 會過期。 許多 .m3u8 URL 和片段 URL 以短期令牌簽署，幾分鐘內便會失效。等你手動寫好下載腳本時，可能一半連結都已死。

這就是 VidMost 接手的地方。VidMost 用於在合規前提下保存你有合法權利存取的 HLS 內容——你自己直播的回放、付費課程的離線副本、自由授權或公有領域的影片、未啟用商業 DRM 的企業培訓素材，以及付費訂閱服務條款明確允許下載的內容。它解析 .m3u8 manifest，挑選可用的最高畫質變體，從你瀏覽器原本就在通訊的同一個 CDN 並行下載每個片段，自動處理一般的 AES-128 片段加密，並在完成後將片段重新封裝為單一乾淨的 MP4 檔案。對於受 FairPlay、Widevine、PlayReady 等商業 DRM 保護的串流（Netflix、Disney+、Apple TV+ 等高階服務），請遵守對應平台的服務條款與所在地法律。對使用者而言，整個體驗就是「貼一個合規的 URL，拿一個 MP4」——協定層消失了。

常見的陷阱與誤解

關於 HLS 的一些誤解反覆出現在論壇討論串中。值得釐清。

• 「.m3u8 不是影片檔。」 它是索引。實際影片在播放清單所引用的片段中。如果某個工具說它能「下載 m3u8」，問清楚它是否也會抓取並合併片段——否則你拿到的是無用的文字檔。
• 「.ts 檔在大多數播放器中不能直接播放。」 單一片段在 VLC 中可能播放幾秒，但整段影片並非資料夾裡的 .ts 序列——它是必須依序解碼並縫合在一起的序列。不會說 HLS 的播放器最多只會播放第一個片段，就停了。
• 「HLS 不一定代表直播。」 「HTTP Live Streaming」在 2026 年是個誤導性的名字。HLS 同樣適用於隨選視訊：相同的播放清單、相同的片段，只是用 #EXT-X-ENDLIST 標記有限串流。Netflix、Disney+ 與 Apple TV+ 目錄中的絕大多數內容是 VOD HLS，而非直播。
• 「在連線會掉的時候，高位元率不總是代表高畫質。」 一個 10 Mbps 變體在光纖上看起來很棒，在 3 Mbps 行動連線上會慘不忍睹。自適應設計的整個重點就是讓播放器選你的連線能維持的東西——手動覆寫常常讓體驗變得更糟，而非更好。
• 「瀏覽器下載工具通常在 HLS 上失敗。」 通用的「影片下載器」擴充功能會找指向 MP4 檔的 <video src="..."> 標籤。HLS 串流不會暴露這樣的 URL；播放器使用 Media Source Extensions 以程式化方式餵入 video 元素片段。這正是為什麼會有專門解析 manifest 的工具存在。

結語

HLS 是你觀看的多數影片底下默默運作的基礎設施。它能行得通是因為它放棄了在傳輸上耍小聰明——沒有自訂協定、沒有特殊伺服器，只有透過你瀏覽器原本就會說的 HTTP 抓取的 .m3u8 文字檔與 .ts 或 fMP4 片段。Apple 在 2009 年解決了一個手機問題，意外打造了接下來兩個十年的主流串流格式。

一旦你能在瀏覽器的網路面板中辨識出 .m3u8 請求並讀懂播放清單，大量串流行為——短暫的畫質切換、即時拖曳、「緩衝中」指示、你最終得到的奇怪 .ts 資料夾——就不再神秘。一切都是同一個迴圈：抓取播放清單、挑變體、抓片段、解碼、重複。

如果你寧可完全跳過協定層、直接儲存影片，VidMost 處理 HLS、DASH、fMP4 和 DRM 保護的串流。

延伸閱讀

• 線上影片是如何播放的——從攝影機到螢幕的完整管線。
• MPEG-DASH 與 HLS 對比——各協定何時勝出，以及為什麼多數串流服務兩者皆提供。
• 為什麼影片畫質會在播放中途改變——每個 HLS 與 DASH 播放器內部的 ABR 邏輯。
• 影片容器 vs 編碼器——.mp4、.ts 或 .m4s 內部實際上是什麼。
• 什麼是 DRM 保護內容？——Widevine、FairPlay 和 PlayReady 如何把關那些你無法輕易儲存的加密變體。