M3U
一个没有视频的文本文件，而 IPTV 订阅实际上就是这样。
M3U 是带有附加名称的媒体地址的纯文本列表。它不包含任何音频或视频。当 IPTV 提供商向您出售订阅服务时，您收到的是其中一个链接 - 频道名称、徽标、组和流地址的列表，玩家可以将其转变为频道指南。
2026年7月30日
系统原生即可打开
iOS 或 macOS 中的任何内容都不会将 M3U 读取为播放列表。点击其中一个会显示一堵文字墙。它不是一种媒体格式，也没有任何系统会将其视为一种媒体格式——它需要一个能够理解列表*用途*的应用程序。
基本信息
| 姓名 | 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 会结束应用程序而不是等待。这就是为什么如此多的 IPTV 应用程序在大型提供商上崩溃的原因。
有效的方法是根本不保存列表：从磁盘中读取它，在解析时将每个通道直接写入数据库，然后从该数据库中分页屏幕。 FoxDL 是针对包含 200 万个频道的 485 MB 列表进行测量的 - 导入时间为 123 秒，额外内存为 9 MB，绘制第一页需要 4 毫秒，搜索整个列表需要 400 毫秒。这些数字之所以有趣，是因为简单的方法根本无法产生它们。
使用一个
- 将其添加为 URL，而不是文件
提供商更新他们的列表——频道移动，地址轮换。持有该URL的玩家可以刷新；持有您曾经下载过的副本的播放器在第一次发生任何变化时就已经过时了。
- 预计群组会混乱并使用搜索
类别名称来自提供商，不遵循任何约定。在大型列表中，搜索频道比导航到频道更快，前提是应用程序搜索数据库而不是加载的数组。
- 要知道列表并不是内容
M3U 是地址。这些地址是否合法观看是关于提供商的问题，而不是关于文件或播放器的问题。没有任何应用程序会提供频道，也没有任何应用程序可以保证您提供的列表。