M3U 与 M3U8：播放列表、编码与 HLS

M3U 和 M3U8 都是文本播放列表。M3U8 表示 UTF-8 编码；直播场景中的 M3U8 地址也常指向单个 HLS 流的清单，IPTV M3U 则经常列出多个频道。因此，实际区别同时涉及编码与文件角色。打开之前，应查看内容，判断它是频道目录还是 HLS 资源描述。

编码是其中一个区别

UTF-8 能一致表示多种语言名称。M3U 也可以采用 UTF-8，较短扩展名并不能确定实际编码。M3U8 则预期使用 UTF-8 文本。这说明字符如何存储，不说明视频用了哪种编解码器。

HLS 的 RFC 8216 第 4 节描述了 HLS 文本清单的 UTF-8 要求，但不能推导出每个叫 M3U8 的文件都是有效 HLS 来源。文件名可以误导，服务器也可能不使用明确扩展名。

名称乱码时，检查原始文本如何编码和保存。名称正确而流失败时，编码不一定是原因。转换前保留副本；更改文本不能补充缺少的视频解码器，也不能恢复离线媒体。

常见 IPTV M3U 由频道名称和完整媒体 URL 组成。选择一个条目，才决定打开哪个来源。条目可以指向 HLS、兼容视频文件或浏览器不支持的协议。目录使用 M3U 扩展名，不代表里面所有格式都经过认证。

HLS 媒体清单引用分段，主清单可以引用不同码率版本。这样的 M3U8 描述一个流所需资源，而不是普通多频道目录。即使第一份清单能读取，也可能要完成多个后续请求，视频才会真正推进。

Apple 的 HLS 介绍提供背景。IPTV 描述更广的观看环境，HLS 是其中一种可能的传输方式，两者相关但不能互换。

这个 M3U 示例只引用一个频道。example.com 用于格式说明，不是实际媒体。

#EXTM3U
#EXTINF:-1 group-title="Learning",Example channel
https://example.com/live/channel.m3u8

它是一个目录：有名称的条目指向另一资源。导入之后可以选择这个条目；目标 M3U8 可能再描述真正的 HLS 流。

第二个纯格式示例是简化的 HLS 媒体清单，没有包含实际可播放分段。

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

两例都有 #EXTM3U 和 #EXTINF，所以只看这两种标签不足以判断用途。HLS 特有标签、分段和码率引用提供更多线索。不要仅凭大型文件的第一行就分类。

有完整媒体地址且允许使用的 M3U 可以本地导入。浏览器读取文本，不把它加入账号资料库。原来源应单独保留，方便之后更新。

M3U8 可以包含相对分段路径，原 URL 提供解析基准。只下载清单文本，并不会同时保存引用资源或确定其远程位置。应使用允许访问的原清单 URL，而不是认为本地副本能够独立播放。

M3U 播放器接受清单输入，也可以将远程 HLS 清单作为单流输入。这是实现能力，不保证所有 M3U8 来源都可用；访问许可、浏览器支持和引用资源仍然重要。

把 .m3u 改成 .m3u8 只改变文件名，不改变字节、URL 或视频编码，也不会把频道目录转换为有效 HLS 清单。HTML 错误页改名为 stream.m3u8 同样不能创建媒体。

浏览器要能解码实际音视频。使用 HLS 库播放时，引用资源还需要允许相应请求，hls.js 项目说明了跨来源要求。第一份清单加载成功，只是请求链中的一步。

假设允许使用的网页清单相对引用 segment000.ts。保存文本为本地文件后，原远程基准不再可用，媒体分段也没有随文本下载。这是假设的资源缺失案例，不能据此判断整个 M3U8 类别不受支持。

回到原清单 URL，按来源文档条件测试。仍失败时，比较可控演示和可见错误，不要不断重命名同一文件。播放帮助区分访问、编解码器和可用性问题。

查看格式与修改清单应分开。删除不认识的标签，或猜测分段文件名，可能破坏有效来源。反馈时，脱敏的文件头、相关 HLS 标签和引用类型通常比完整私有文件更有用。保留原文，便于比较本地变更。来源要求许可或受保护访问方式时，更换扩展名不会提供授权。

频道条目结构见 M3U 列表指南，当前实现与实际测试环境见兼容性说明。反馈时说明输入类型和失败阶段，提供脱敏示例，不要分享私有 URL。

实际决策不是哪个扩展名听起来更新，而是确认编码、列表用途，以及引用资源是否可访问。这三项检查能更清楚说明浏览器需要做什么。