M3U
一個沒有視訊的文字檔案，IPTV 訂閱實際上就是這樣。
M3U 是附加名稱的媒體位址的純文字清單。它不包含任何音訊或視訊。當 IPTV 提供者向您出售訂閱服務時，您收到的是其中一個連結 - 頻道名稱、徽標、群組和串流地址的列表，玩家可以將其轉換為頻道指南。
2026年7月30日
系統原生即可開啟
iOS 或 macOS 中沒有任何內容將 M3U 讀取為播放清單。點選其中一個會顯示一堵文字牆。它不是一種媒體格式，也沒有任何系統會將其視為一種媒體格式——它需要一個能夠理解清單*用途*的App。
基本資訊
| 全名 | MP3 URL，或運動影像專家小組音訊第 3 層統一資源定位符 |
|---|---|
| 種類 | 播放列表 — 位址列表，無媒體 |
| 擴展 | .m3u（任何文字編碼）、.m3u8 (UTF-8) |
| 已發布 | 20 世紀 90 年代末，Fraunhofer 為 Winamp 創作；從未正式標準化 |
| 結構 | #EXTINF 行命名每個條目，後面跟著其位址 |
| IPTV 擴展 | tvg-id、tvg-name、tvg-logo、group-title — 按慣例添加，而不是按規範添加 |
| 地址指向什麼 | 通常是 HLS 播放清單或 MPEG-TS 串流；有時是純檔案 |
| 典型的提供者大小 | 數十萬個頻道中的清單需要幾百 KB 到 200 MB 以上 |
姓名和地址列表
格式非常簡單。每個條目都是兩行：一行以“#EXTINF”開頭，用於命名該事物，另一行是它所在的位址。其他一切——標誌、頻道號碼、成為播放器類別的群組——後來作為人們同意放在「#EXTINF」行上的屬性出現。沒有任何標準機構批准過其中任何一項。
這種非正式性是 M3U 檔案差異如此之大的原因。一個提供者寫為“group-title=”Sports”，另一個提供者寫為“group-title=”SPOR”，第三個提供者完全忽略它並期望玩家猜測。能夠很好地處理IPTV的播放器大多是遇到很多寫得很糟糕的M3U檔案的播放器。
與M3U8的混淆值得澄清：「8」指的是UTF-8文字編碼，僅此而已。每個 HLS 播放清單都是 M3U8，但並非每個 M3U8 都是 HLS — 儲存為 UTF-8 的 IPTV 頻道清單也是 .m3u8，與分段串流無關。
為什麼尺寸是整個問題
提供者清單以前所未有的方式成長。大型提供者提供的檔案在 2010 年只有幾百行，現在卻包含數十萬個條目和數百兆位元組的文字。
簡單的讀取方式－將檔案載入記憶體中，解析它，保存結果－在此之前很久就失敗了。以這種方式解析 200 MB 的列表意味著 iPhone 無法容忍記憶體峰值，iOS 會結束App而不是等待。這就是為什麼如此多的 IPTV App在大型提供者上崩潰的原因。
有效的方法是根本不保存清單：從磁碟中讀取它，在解析時將每個通道直接寫入資料庫，然後從該資料庫中分頁畫面。 FoxDL 是針對包含 200 萬個頻道的 485 MB 清單進行測量的 - 導入時間為 123 秒，額外記憶體為 9 MB，繪製第一頁需要 4 毫秒，搜尋整個清單需要 400 毫秒。這些數字之所以有趣，是因為簡單的方法根本無法產生它們。
使用一個
- 將其新增為 URL，而不是檔案
提供者更新他們的清單－頻道移動，位址輪換。持有該URL的玩家可以刷新；持有您曾經下載過的副本的播放器在第一次發生任何變化時就已經過時了。
- 預計群組會混亂並使用搜尋
類別名稱來自提供者，不遵循任何約定。在大型清單中，搜尋頻道比導航到頻道更快，前提是App搜尋資料庫而不是載入的陣列。
- 知道清單不是內容
M3U 是位址。這些地址是否合法觀看是關於提供者的問題，而不是關於檔案或播放器的問題。沒有任何App會提供頻道，也沒有任何App可以保證您提供的清單。