本地曲库攒到几千首之后最先崩掉的往往不是播放器而是你的歌单。我很长一段时间里都在用 Folia 管本地音乐曲库扫描、专辑封面、歌词这些都没什么可挑的真正让我反复折腾的是三件事队列一关就没了、排序规则看不懂为什么这么排、歌单想在别的播放器里接着用却导不出去。这篇就把这三件事一次讲透围绕Folia 的本地歌单把队列保存、排序逻辑、M3U8 导入导出这条链路打通。如果你手上有一个几百上千首的本地曲库或者你习惯在多个播放器之间倒腾歌单又或者你想用脚本批量管理播放列表下面这些内容应该都能直接用上。文中涉及的具体菜单名称在不同版本里可能略有差异我会尽量描述操作意图而不是死记按钮位置思路和排查方法是一致的。1. 先把需求捋清楚为什么本地歌单这件事值得认真对待1.1 队列和歌单根本不是一回事很多人把这两个概念混着用结果就是我明明存了歌单怎么下次播放顺序又变了。队列Queue描述的是此刻正在播的这一串它有明确的当前指针、有播放位置、有随机和循环状态本质是一个带游标的临时序列歌单Playlist描述的是我希望长期保留的一组曲目及其顺序它没有现在播到第几首这个概念是一个持久化的集合。Folia 里这两者的存储位置和生命周期的差别比想象中大队列通常跟着会话走退出进程就可能重置歌单则是落盘的一份数据。搞清楚这个区别之后很多操作就有了明确的意图。比如你想把今天随手加的一堆歌固定下来正确做法是把队列另存为歌单而不是指望队列自动保留反过来你想临时插一首歌进去但别污染我的精选集那就往队列里塞别动歌单。我见过不少人反过来操作把精心排序的歌单当成播放队列用一边听一边拖拽最后顺序全乱了还以为是软件的排序功能有 bug。还有一个容易被忽略的点队列是有状态的包括当前播放到哪一首、这首歌播到第几秒、随机模式是否开启、循环是单曲还是列表。一个完整的队列快照要保存的是这些状态的总和而不是单纯一个曲目 ID 数组。这决定了后面我们做队列保存的时候需要保存哪些字段、恢复时要还原到什么程度。1.2 为什么选 M3U8 而不是数据库或 JSONFolia 自己的歌单数据一般存在内部数据库里字段齐全、查询高效但它有个致命的缺点换一个播放器就读不懂了。你要是想把歌单带到车载系统、带到另一台机器上的播放器、或者发给朋友内部格式完全没用。这就是 M3U8 存在的意义——它是一个几乎所有播放器都认的交换格式从桌面软件到手机 App 到硬件播放器支持面极广。这里必须先澄清一个高频混淆点M3U8 这个名字有两个完全不同的用途。一个是 HLS 流媒体播放列表里面会出现#EXT-X-TARGETDURATION、#EXT-X-STREAM-INF这类标签用于切片传输另一个就是我们这里说的本地歌单文件内容极其简单就是一个曲目路径列表加上可选的元信息。两者都叫 .m3u8 后缀但语义无关。你导出本地歌单的时候不用担心我是不是在做流媒体只要文件里没有#EXT-X-开头的标签它就是纯粹的本地列表。那为什么不直接用 JSON 或者 CSVCSV 的问题是没有任何元信息承载能力路径里一旦有逗号就崩JSON 结构灵活但没有播放器认M3U8 处于一个恰到好处的位置——足够简单到任何程序都能解析又足够规范到能携带标题、艺术家、时长这些基础信息。而且它是纯文本出问题的时候你可以直接用文本编辑器打开看这一点在排查路径失效、编码错误的时候价值极高。我在处理别人的歌单文件时第一件事永远是cat一下看前二十行八成的问题肉眼就能看出来。1.3 方案的整体设计曲库、歌单、队列三层结构把这套东西想清楚我建议在心里建一个三层模型。最底层是曲库也就是 Folia 扫描进来的所有音频文件每条记录至少包含路径、标题、艺术家、专辑、时长、采样率这些信息核心是一个稳定的曲目标识中间层是歌单它引用曲目标识并附加一个顺序号是可以长期保存、可以导出成 M3U8 的最上层是队列它引用歌单或者曲库里的曲目额外带上播放游标和播放模式。这个分层带来的好处是导出和导入的逻辑变得非常清晰。导出歌单时你只需要遍历歌单里的曲目把每个曲目解析成文件路径再拼上元信息写成文本导入 M3U8 时你逐行读路径拿路径去曲库里做匹配匹配上就建立引用关系匹配不上就单独记下来待处理。队列保存其实就是把队列的曲目序列复制成一份歌单额外把游标和播放模式作为附注记下来恢复的时候反向操作。我之所以强调这个模型是因为后面所有的坑几乎都能归到某一层的假设被打破了。比如路径失效是曲库层的标识和实际文件系统脱节了顺序错乱是歌单层的顺序号没被正确写入或者被重新排序覆盖了编码乱码是导出时文本层的字符集选错了。心里有这三层排查的时候就能快速定位是哪一层出的问题而不是在一堆设置项里瞎试。2. 核心机制拆解队列保存、排序、M3U8 到底怎么运作2.1 队列的持久化从内存列表到可恢复快照队列在程序里通常就是一个数组加一个下标再配上几个枚举值表示循环和随机状态。要让它在重启后还能恢复需要把这些内存结构序列化成一份快照。快照里我认为至少要包含五样东西曲目标识的有序列表、当前播放索引、当前曲目的播放进度、随机与循环模式、快照写入时间。少了任何一样恢复出来的体验都会打折扣——比如只存列表不存索引重启后永远从第一首开始播用久了会非常烦。这里有个设计上的取舍值得说一下快照里存的是曲目标识还是文件路径存标识的好处是稳定曲库重新扫描、文件被移动位置只要标识逻辑能对上队列就能恢复坏处是标识依赖内部数据库一旦库重建就可能全丢。存路径的好处是直观、跨程序可用坏处是文件一动就失效。我倾向于两者都存以标识为主、路径为兜底恢复时先按标识找找不到再按路径模糊匹配一次这样能覆盖绝大多数场景。恢复过程本身要设计得抗打击。真实情况是你保存队列的时候曲库里有 500 首下次打开的时候可能有 3 首被删了、2 首被改名了。如果恢复逻辑是任何一首找不到就整个放弃那体验会非常糟糕。合理做法是逐条恢复、跳过失效项、最后给一个提示已恢复 495 首5 首未找到。我在实际使用中最看重的就是这个容错度宁可少恢复几首也不要整个队列打不开。注意队列快照会随着播放频繁写入如果你把写入频率设得太高比如每次切歌都落盘在机械硬盘或者网络存储上会造成明显的 IO 抖动。常见的做法是节流比如切歌后延迟几秒再写或者只在暂停、退出、手动保存时写。2.2 排序逻辑看起来简单坑最多的地方排序这件事表面上是按标题排还是按艺术家排实际上一旦你的曲库里有中文、有数字、有大小写混杂、有多碟专辑问题就会成串冒出来。我先说最容易被误解的一点排序不会改变歌单的原始顺序除非你显式地应用了排序。很多播放器的行为是显示时排序和保存时排序分开的你在界面上看到按字母排好了导出的 M3U8 里可能还是原始顺序。Folia 里也一样你要区分视图排序和写入顺序前者只影响你看后者才影响导出结果。第二个坑是字符串排序和自然排序的区别。纯字符串比较会把 Track 10 排在 Track 2 前面因为字符 1 小于 2。对于音轨号、碟号这种带数字的字段必须用自然排序natural sort把连续数字当作整数比较。这个问题在古典音乐或者多碟套装里几乎必然出现你会看到第二碟的第一首莫名其妙跑到第一碟第十首前面。第三个坑是中文排序的规则。默认的字符串比较是按 Unicode 码点走的结果就是中文标题的排序看起来毫无规律。想要按拼音排需要引入 locale 相关的排序规则或者干脆把标题转成拼音再做比较。我的建议是如果你的歌单里中文占多数别指望默认排序老老实实用拼音键或者手动排序。手动排序虽然费点事但至少结果可预期。排序维度适用场景需要注意的点标题杂食歌单、单曲集合中文需转拼音否则顺序不可读艺术家按人听专辑多艺术家合作曲目归到哪个键要定规则专辑 音轨号完整专辑播放音轨号必须自然排序碟号要参与比较添加时间最近收藏的歌依赖入库时间戳重扫曲库可能被刷新时长通勤、运动场景时长读取失败会变成 0排在最前手动顺序精心编排的精选集必须有稳定的顺序号字段不能靠数组下标还有一点经验多级排序一定要有稳定的兜底键。比如按艺术家、再按专辑、再按音轨号如果这三项都相同比如同一张专辑里的重复曲目排序结果在不同实现下可能不一致导出两次顺序就不一样。加一个文件路径或者曲目 ID 作为最后一级比较能保证结果稳定可复现。2.3 M3U8 格式规范逐行拆解M3U8 的结构简单到可以用一句话概括第一行是#EXTM3U头之后是若干组扩展信息行 路径行。扩展信息行的格式是#EXTINF:时长,显示名称时长单位是秒未知时写 -1 或者干脆省略路径行就是音频文件的位置可以是绝对路径也可以是相对路径。除此之外以#开头的都是注释或扩展标签解析器一般会忽略不认识的。一个典型的文件长这样#EXTM3U #EXTINF:245,某艺术家 - 某曲目 /music/albums/demo/01.flac #EXTINF:198,某艺术家 - 另一首 /music/albums/demo/02.flac看起来没什么但细节全在看不见的地方。第一编码必须是 UTF-8。这是 M3U8 和 M3U 最本质的区别老的 M3U 用的是系统本地编码在中文环境下经常是 GBK一换机器就乱码。有些导出工具会额外加 BOM 头EF BB BF部分老播放器不认 BOM会把第一行读成\ufeff#EXTM3U从而认为文件无效。我的做法是导出时不写 BOM导入时主动剥掉可能的 BOM兼容性最好。第二换行符。Windows 习惯 CRLF类 Unix 习惯 LF很多解析器两者都能处理但有些粗糙的实现会把\r当成路径的一部分导致路径明明对却找不到文件。如果你导出的文件要给车载或者老设备用CRLF 更保险。第三时长字段的精度。规范上写整数秒但有些工具导出的时长会带小数或者千分位解析时要做好容错。时长写错本身不影响播放它主要影响导入时按时长做去重或者匹配的准确度。第四路径的写法。这是导入导出里最容易出问题的地方我在下一节会专门拆开讲。简单说绝对路径跨机器必然失效相对路径依赖基准目录Windows 的反斜杠在跨平台时经常需要转成正斜杠。3. 实操把队列存下来、把顺序理干净、把歌单导出去3.1 环境与前置准备动手之前先把三件事确认好能省掉后面一大半的返工。第一是曲库的路径规划。我强烈建议把音乐放在一个固定的根目录下比如统一放在某个盘符下的Music目录子目录按艺术家/专辑组织。这样做的好处是相对路径有意义导出 M3U8 时可以用相对路径整个目录搬到别的机器上歌单跟着一起搬还能用。如果你的音乐散落在十几个不同目录那只能走绝对路径跨机器必然要重新匹配。第二是确认曲库扫描是完整的。导出歌单时如果某首歌在数据库里有记录但文件其实已经不在原位导出出来的路径就是死链。所以导出前先在 Folia 里触发一次曲库重新扫描或者完整性检查把失效条目清掉。这一步看起来很笨但比导出之后发现一半是坏的强。第三是编码和 locale。如果你打算用脚本处理 M3U8脚本运行环境要保证读写都是 UTF-8。Python 3 默认按 locale 决定open()的编码在某些系统上默认不是 UTF-8读中文路径会直接抛异常。稳妥写法是显式指定encodingutf-8读的时候用errorsreplace兜底。# 快速确认一个 m3u8 文件是不是 UTF-8、有没有 BOM file -i playlist.m3u8 head -c 3 playlist.m3u8 | xxd如果输出显示utf-8且前三个字节不是efbbbf说明文件是干净的 UTF-8、没有 BOM跨播放器兼容性最好。3.2 队列保存与恢复的完整操作队列保存的操作意图是把当前播放队列连同游标状态落盘下次能原样接上。在 Folia 里通常有两条路径可选——一是自动会话恢复退出时自动保存、启动时自动还原二是手动另存为歌单把队列固化成一个正式歌单。这两者的用途不同我是这么用的日常听歌靠自动恢复不用管一旦某个队列我听着顺耳、想长期保留就手动另存成一个歌单起个明确的名字之后从歌单加载。手动另存的时候有个细节要注意是否保留当前播放位置。多数实现会另存成一个普通歌单游标信息丢失下次从这个歌单加载会从第一首开始。如果你希望恢复的是接着刚才的位置播那要确保自动会话恢复是开启的而不是靠歌单。这两个机制不要指望互相替代。恢复环节最需要关注的是失效处理策略。理想的行为是逐条尝试恢复找不到的跳过并记录最后汇总提示。我自己踩过的坑是早期版本里只要有一首找不到整个队列就恢复失败而且不给任何提示表现就是打开播放器队列空了非常迷惑。后来我养成了一个习惯保存队列之后立刻去文件管理器里确认一下曲目都还在尤其是那些放在移动硬盘或者网络位置上的。提示如果你的音乐库在可移动存储上挂载点变化比如从/Volumes/DiskA变成/Volumes/DiskA-1会让所有绝对路径失效。这种情况用相对路径导出歌单或者干脆固定挂载点名称。还有一个实用技巧定期把重要队列另存为带日期的歌单。比如通勤-2024-05这种命名既是备份也是归档回头想找某段时间常听的歌直接翻歌单就行。这比依赖播放历史靠谱得多历史记录通常只能看不能直接播。3.3 排序规则配置与自定义顺序Folia 的排序入口一般有两处歌单内的排序和曲库视图的排序。前者影响你导出的顺序如果导出时选择按当前显示顺序后者只影响浏览。我建议养成一个习惯进歌单之后先看一眼当前排序是什么如果是按标题而你希望导出的是原始编排顺序记得切回手动/自定义再导出否则导出的文件顺序和你预期完全对不上。自定义顺序的实现依赖一个顺序号字段。你在界面上拖拽调整位置本质上是在改这个字段的值。这里有个经典的实现问题如果顺序号是连续的整数每次插入都要把后面所有项重新编号歌单一长就卡如果顺序号是稀疏的比如步长 1000插入只改一项性能好很多但插入次数多了会耗尽间隙、需要重排。你在使用中如果发现拖拽之后顺序偶尔错乱很可能是间隙耗尽的边界情况。多级排序的配置我的一般做法是整理阶段用艺术家 → 专辑 → 碟号 → 音轨号把整张专辑排整齐然后切到手动模式在这个基础上微调。这样既有结构又不失灵活。对于杂食歌单用添加时间倒序快速找到最近收的歌再手动往合适的位置挪。场景推荐排序链理由完整专辑播放专辑 → 碟号 → 音轨号还原原始唱片顺序单艺术家精选艺术家 → 添加时间同一个人按收录先后听通勤随机歌单手动顺序精心编排不交给算法最近收藏添加时间倒序新歌优先古典/现场专辑 → 音轨号自然排序乐章顺序不能乱最后再强调一次自然排序。任何带数字的字段音轨号、碟号、作品号都必须按数值比较不能按字符串比较。你可以自己做个小测试建一个歌单放十首标题带序号的曲目按标题排序看看第 10 首是不是跑到了第 2 首前面。如果跑过去了说明这个版本用的是纯字符串比较那就别用标题排序来组织有序号的曲目。3.4 导出 M3U8参数选择与路径策略导出时的核心决策只有一个用绝对路径还是相对路径。这个选择直接决定了歌单的可移植性。绝对路径的优点是导出即可用双击就能播不需要任何基准目录。缺点是换机器、改目录名、换挂载点全部失效。相对路径的优点是整个音乐目录可以整体搬迁只要 M3U8 和音乐目录保持相对关系到哪都能用。缺点是有基准目录的概念播放器要能正确解析。我的选择是给自己用导相对路径给别人用导绝对路径。别人拿到你的相对路径歌单基准目录对不上等于没用。具体到相对路径的计算规则通常是以 M3U8 文件所在的目录为基准用../往上跳。比如歌单放在Music/playlists/下曲目在Music/albums/demo/01.flac那相对路径就是../albums/demo/01.flac。import os def to_relative(track_path, playlist_dir): 把绝对路径转成相对于歌单目录的路径统一用正斜杠 rel os.path.relpath(track_path, playlist_dir) return rel.replace(os.sep, /)这段代码里.replace(os.sep, /)很重要。Windows 上os.path.relpath返回的是反斜杠虽然本机播放器多半能认但一旦文件传到别的系统就废了。统一成正斜杠是最省心的做法现代 Windows 播放器也能正常处理正斜杠。导出参数方面还有几个选项值得留意是否写入时长、是否写入扩展标签、是否包含失效条目。时长建议写虽然不影响播放但很多工具会用它来估算歌单总时长缺了会显示 0。扩展标签比如#EXTALB、#EXTPERFORMER是 Foobar2000 那类播放器的扩展写了不影响兼容性但不认识的播放器会忽略属于写了没坏处的类型。失效条目一定要排除否则导出的歌单里混着一堆死链导入的时候还要再清理一遍。注意导出后一定要抽检。随机打开文件看前几行确认头行是#EXTM3U、编码没乱、路径分隔符正确。我遇到过一次导出工具把中文路径转成了 URL 编码%E4%B8%AD播放器完全认不出来肉眼扫一眼就能发现。3.5 导入 M3U8匹配失败怎么办导入的本质是路径匹配拿到 M3U8 里的一行路径去曲库里找对应的曲目。匹配成功的条件通常是路径完全一致宽松一点的实现会做规范化统一分隔符、忽略大小写、解析符号链接后再比较再宽松一点会用文件名匹配忽略目录差异。这三档的匹配率差异很大。匹配失败的原因按出现频率排大概是这样失败原因表现处理方式绝对路径跨机器整片失败改用文件名匹配或用脚本重写路径前缀目录改名/移动部分失败批量替换路径中的旧前缀盘符变化Windows 上整片失败脚本替换盘符编码不一致中文路径乱码转成 UTF-8 重新保存大小写差异少量失败匹配时忽略大小写反斜杠/正斜杠部分失败匹配前统一分隔符符号链接部分失败解析真实路径后再比较我的实战顺序是先改编码再统一分隔符然后处理路径前缀最后才考虑用文件名兜底。前几步都是无损的、可批量脚本化的最后一步有风险因为同名文件可能匹配错。路径前缀替换是最常用的一招。比如歌单里全是/Volumes/OldDisk/Music/...而音乐现在在/Volumes/NewDisk/Music/...一条sed就能搞定sed -i s|/Volumes/OldDisk/Music/|/Volumes/NewDisk/Music/|g playlist.m3u8在 Windows 上换成盘符替换也是同理。注意sed -i在部分系统上需要额外参数用之前先备份一份原文件这是血泪教训——我有一次替换写错了一个字符把整个歌单的路径全毁了幸好有备份。导入之后还有一步验证要做看看成功导入了多少首、失败了多少首、失败的是哪些。如果失败列表很长不要急着一条条手动修先看失败项有没有共同特征比如都指向同一个旧目录有共同特征就能批量处理。4. 用脚本把重复劳动自动化4.1 批量生成 M3U8 的思路与代码如果你有大量专辑目录想一次性给每张专辑生成一个 M3U8手动操作会疯掉。写个脚本扫目录是最省事的。思路很直接遍历目录树找出音频文件按目录分组每组写一个 M3U8文件名用目录名。import os from pathlib import Path AUDIO_EXT {.flac, .mp3, .m4a, .wav, .ogg, .opus, .ape} def build_m3u8(album_dir: Path, out_path: Path) - int: tracks sorted( (p for p in album_dir.iterdir() if p.is_file() and p.suffix.lower() in AUDIO_EXT), keylambda p: p.name ) if not tracks: return 0 lines [#EXTM3U] for p in tracks: # 时长未知时写 -1显示名用文件名去掉扩展名 lines.append(f#EXTINF:-1,{p.stem}) lines.append(p.name) # 同目录下直接用文件名就够了 out_path.write_text(\n.join(lines) \n, encodingutf-8) return len(tracks) def walk(root: str): root_p Path(root) total 0 for album_dir in sorted({p.parent for p in root_p.rglob(*) if p.is_file() and p.suffix.lower() in AUDIO_EXT}): out album_dir / f{album_dir.name}.m3u8 n build_m3u8(album_dir, out) if n: total n print(f{out} {n} 首) print(f共生成曲目条目 {total} 条) if __name__ __main__: walk(./Music)这段代码有几个刻意的设计。第一曲目路径写的是文件名而不是完整路径因为 M3U8 和曲目在同一目录下相对路径就是文件名本身最简洁也最可移植。第二排序用的是文件名如果你的文件名规范带序号01 - xxx.flac自然就是正确顺序如果文件名不带序号得改成读标签排序。第三编码显式指定 UTF-8避免默认编码带来的乱码。想读标签拿时长和艺术家的话装个 mutagenfrom mutagen import File as MutaFile def tag_info(path: Path): try: f MutaFile(path) if f is None or f.info is None: return -1, path.stem dur int(f.info.length) title str(f.tags.get(title, [path.stem])[0]) if f.tags else path.stem artist str(f.tags.get(artist, [])[0]) if f.tags else name f{artist} - {title} if artist else title return dur, name except Exception: return -1, path.stem用try/except把整个读取包起来是有必要的损坏的文件、非标准容器、权限问题都可能导致抛异常而批量处理最忌讳的就是遇到一个坏文件整个任务挂掉。4.2 歌单校验与去重脚本M3U8 文件用久了必然会积累问题重复条目、死链、空目录引用。写个校验脚本定期跑一遍比事后手动修省事得多。from pathlib import Path def check_m3u8(m3u8_path: Path): base m3u8_path.parent missing, seen, dup [], set(), [] current None for raw in m3u8_path.read_text(encodingutf-8, errorsreplace).splitlines(): line raw.strip().lstrip(\ufeff) if not line: continue if line.startswith(#EXTINF): current line continue if line.startswith(#): continue p (base / line).resolve() if not Path(line).is_absolute() else Path(line) key str(p).lower() if key in seen: dup.append(line) seen.add(key) if not p.exists(): missing.append(line) return missing, dup if __name__ __main__: for f in Path(./Music).rglob(*.m3u8): m, d check_m3u8(f) if m or d: print(f[{f}] 死链 {len(m)} 条重复 {len(d)} 条) for x in m[:5]: print( 缺失:, x)去重的键我用的是转小写后的完整路径因为同一首歌在 Windows 上大小写不敏感01.FLAC和01.flac指向同一个文件不转小写会漏判。如果你希望按内容去重不同路径的同一首歌那得算文件哈希或者比对标签里的艺术家加标题加时长成本更高一般没必要。lstrip(\ufeff)这行是专门处理 BOM 的。有些工具导出的文件带 BOM第一次读进来首行会变成\ufeff#EXTM3U不剥掉的话虽然它仍然以#开头会被当注释跳过但如果 BOM 出现在第一个路径行前面就会导致那个路径匹配失败。全行剥一次最保险。4.3 跨播放器格式转换不同播放器支持的格式略有差异。有的只认 M3U不认 M3U8有的支持 XSPF 或者 PLS。转换的核心其实只有一处编码。M3U 传统上用本地编码在中文环境下是 GBKM3U8 用 UTF-8。所以从 M3U8 转 M3U重点是把 UTF-8 的内容用 GBK 重新写一遍写不了的字符用替换符兜底from pathlib import Path src Path(playlist.m3u8) dst Path(playlist.m3u) text src.read_text(encodingutf-8, errorsreplace) dst.write_text(text, encodinggbk, errorsreplace)反过来从 M3U 转 M3U8先用gbk读、再用utf-8写。如果原文件编码不确定可以装个chardet之类的库猜一下或者干脆两种编码都试一遍看哪种解出来的中文是正常的。我处理别人给的歌单时基本都会先试着用 UTF-8 读一遍报错就换 GBK再不行就 GB18030这三个覆盖了绝大多数中文场景。还有个小细节转换成 M3U 之后部分老播放器对 CRLF 有要求写文件的时候可以指定newline\r\n。这个参数在Path.write_text里不支持得用open()打开再写。5. 常见问题与排查实录5.1 导入后顺序全乱这是报得最多的问题原因基本可以归成三类。第一类是导出时选了错误的排序。你在界面上按标题看的导出时也选了按当前显示顺序那导出的就是标题顺序当然不是你编排的顺序。解决方式是导出前切回手动或自定义排序。第二类是顺序号丢失。有些导出实现只写路径不写顺序导入的时候按文件系统返回的顺序重建而文件系统的遍历顺序是不保证的。这种情况你在 M3U8 里能看出来——条目顺序和你记忆中的不一样而且没有明显的规律。解决办法是导出后检查文件如果顺序不对要么换导出方式要么手动调整后重新导出。第三类是排序规则不一致。导出时按艺术家排的导入的播放器按标题重排了一遍。这种是显示排序覆盖了文件顺序得去播放器设置里把导入后自动排序之类的选项关掉。排查方法很简单用文本编辑器打开 M3U8看条目顺序。文件里顺序对那就是播放器的问题文件里顺序就不对那就是导出环节的问题。这一步能直接砍掉一半的排查时间。5.2 中文乱码与特殊字符乱码的根源永远是编码不匹配。M3U8 应该是 UTF-8如果你看到的是锟斤拷或者一堆问号说明文件不是 UTF-8 却按 UTF-8 解读了或者反过来。用file -i看一眼就能确定。file -i playlist.m3u8 # 输出 charsetiso-8859-1 或者 unknown-8bit基本就是编码不对修复的方式是用正确的编码读、用 UTF-8 写我在 4.3 节已经给过代码。需要注意的是如果文件已经被错误地保存过一次原始字节可能已经损坏这时候没法挽回只能重新导出。特殊字符方面最麻烦的是路径里带#和%。#在 M3U8 里是注释标记路径行以#开头会被当成注释忽略。%是 URL 编码的引导符有些解析器会尝试解码。如果你有文件名带这两个字符最省事的办法是改文件名别跟格式较劲。逗号也值得注意因为#EXTINF:时长,名称里逗号是分隔符名称里带逗号一般没问题只取第一个逗号后面的全部但某些粗糙的解析器会切错。还有中文路径的长度问题。Windows 的传统路径长度限制是 260 个字符深层嵌套目录加长文件名很容易超限超了之后文件能创建但某些 API 读不到。这个问题在导入时表现为文件明明存在却匹配失败很容易误判成编码问题。排查时可以尝试把文件挪到更浅的目录试试。5.3 路径失效的三种典型场景场景一换机器。绝对路径里的盘符、用户目录全部对不上。这种情况没有捷径只能做前缀替换或者改用文件名匹配。预防的办法是导出时就用相对路径。场景二移动硬盘挂载点变化。同一个硬盘插到不同电脑上挂载点可能从/Volumes/Disk变成/Volumes/Disk 1。这会让所有绝对路径失效。解法有两种一是给硬盘设置固定的卷标让挂载点稳定二是用相对路径让歌单跟着音乐目录走。场景三目录重命名。比如你把华语改成了中文流行下面所有歌单里的路径全废。批量替换能救但要注意替换的粒度别把别的路径也误伤了。我一般会先grep一下确认影响范围再动手替换。grep -c 华语 playlist.m3u8 # 先数一下影响多少行 sed -i s|/华语/|/中文流行/|g playlist.m3u85.4 时长显示为零、重复条目与空歌单时长显示为 0 通常是因为导出时没读标签写了 -1 或者 0。这不影响播放但会影响按总时长排序、影响某些播放器的进度条预估。要修复只能重新导出并且开启读取时长选项或者用脚本读标签补上。重复条目的产生原因通常是多次导入同一个歌单或者合并歌单时没去重。Folia 里一般有去重功能但它的判定标准可能是曲目 ID 而不是路径如果同一首歌在曲库里存在两条记录比如扫描了两个不同路径去重就失效了。这时候得先清理曲库里的重复记录。空歌单的原因就比较多了路径全失效导致全部跳过、编码错误导致一行都没解析出来、文件本身只有头行。排查顺序是先看文件大小如果是几百字节那就是真的空再看头几行再看有没有#EXTINF但没有路径行的情况——有些工具写文件的时候会漏掉路径这是实现 bug。5.5 问题速查表现象最可能的原因第一步动作导入 0 首编码错误 / 路径全失效file -i看编码文本编辑器看前几行顺序错乱导出时用了显示排序检查 M3U8 内条目顺序中文乱码非 UTF-8 被当 UTF-8 读用正确编码重读重写部分曲目找不到路径前缀变化 / 大小写统一分隔符、批量替换前缀时长全是 0导出未读标签重新导出开启时长读取有重复条目多次导入 / 曲库重复按路径转小写去重先清曲库首行报错BOM 头读时剥掉\ufeff播放器显示空歌单文件里只有头行检查文件大小和路径行数量排查工具用途一行命令file判断编码与文件类型file -i x.m3u8head看头几行快速判断结构head -20 x.m3u8grep统计某类条目数量grep -c EXTINF x.m3u8sed批量替换路径前缀sed -i s|旧|新|g x.m3u8wc看总行数是否合理wc -l x.m3u8我把这套方法用了挺长时间最大的体会是歌单出问题九成能在纯文本层面看出来。不要一上来就怀疑播放器的数据库坏了、去重装软件先head一下文件很多问题当场就现形了。另外任何批量替换之前一定先备份这个习惯帮我省过好几次事。至于队列别指望它自动帮你留住什么觉得好听就立刻另存成歌单这是我踩过最多的坑之后固定下来的动作。 
长河君 · 2026/11/3 17:17:40 · 阅读 1.2k Folia本地歌单：队列保存、排序逻辑与M3U8导入导出
本地曲库攒到几千首之后最先崩掉的往往不是播放器而是你的歌单。我很长一段时间里都在用 Folia 管本地音乐曲库扫描、专辑封面、歌词这些都没什么可挑的真正让我反复折腾的是三件事队列一关就没了、排序规则看不懂为什么这么排、歌单想在别的播放器里接着用却导不出去。这篇就把这三件事一次讲透围绕Folia 的本地歌单把队列保存、排序逻辑、M3U8 导入导出这条链路打通。如果你手上有一个几百上千首的本地曲库或者你习惯在多个播放器之间倒腾歌单又或者你想用脚本批量管理播放列表下面这些内容应该都能直接用上。文中涉及的具体菜单名称在不同版本里可能略有差异我会尽量描述操作意图而不是死记按钮位置思路和排查方法是一致的。1. 先把需求捋清楚为什么本地歌单这件事值得认真对待1.1 队列和歌单根本不是一回事很多人把这两个概念混着用结果就是我明明存了歌单怎么下次播放顺序又变了。队列Queue描述的是此刻正在播的这一串它有明确的当前指针、有播放位置、有随机和循环状态本质是一个带游标的临时序列歌单Playlist描述的是我希望长期保留的一组曲目及其顺序它没有现在播到第几首这个概念是一个持久化的集合。Folia 里这两者的存储位置和生命周期的差别比想象中大队列通常跟着会话走退出进程就可能重置歌单则是落盘的一份数据。搞清楚这个区别之后很多操作就有了明确的意图。比如你想把今天随手加的一堆歌固定下来正确做法是把队列另存为歌单而不是指望队列自动保留反过来你想临时插一首歌进去但别污染我的精选集那就往队列里塞别动歌单。我见过不少人反过来操作把精心排序的歌单当成播放队列用一边听一边拖拽最后顺序全乱了还以为是软件的排序功能有 bug。还有一个容易被忽略的点队列是有状态的包括当前播放到哪一首、这首歌播到第几秒、随机模式是否开启、循环是单曲还是列表。一个完整的队列快照要保存的是这些状态的总和而不是单纯一个曲目 ID 数组。这决定了后面我们做队列保存的时候需要保存哪些字段、恢复时要还原到什么程度。1.2 为什么选 M3U8 而不是数据库或 JSONFolia 自己的歌单数据一般存在内部数据库里字段齐全、查询高效但它有个致命的缺点换一个播放器就读不懂了。你要是想把歌单带到车载系统、带到另一台机器上的播放器、或者发给朋友内部格式完全没用。这就是 M3U8 存在的意义——它是一个几乎所有播放器都认的交换格式从桌面软件到手机 App 到硬件播放器支持面极广。这里必须先澄清一个高频混淆点M3U8 这个名字有两个完全不同的用途。一个是 HLS 流媒体播放列表里面会出现#EXT-X-TARGETDURATION、#EXT-X-STREAM-INF这类标签用于切片传输另一个就是我们这里说的本地歌单文件内容极其简单就是一个曲目路径列表加上可选的元信息。两者都叫 .m3u8 后缀但语义无关。你导出本地歌单的时候不用担心我是不是在做流媒体只要文件里没有#EXT-X-开头的标签它就是纯粹的本地列表。那为什么不直接用 JSON 或者 CSVCSV 的问题是没有任何元信息承载能力路径里一旦有逗号就崩JSON 结构灵活但没有播放器认M3U8 处于一个恰到好处的位置——足够简单到任何程序都能解析又足够规范到能携带标题、艺术家、时长这些基础信息。而且它是纯文本出问题的时候你可以直接用文本编辑器打开看这一点在排查路径失效、编码错误的时候价值极高。我在处理别人的歌单文件时第一件事永远是cat一下看前二十行八成的问题肉眼就能看出来。1.3 方案的整体设计曲库、歌单、队列三层结构把这套东西想清楚我建议在心里建一个三层模型。最底层是曲库也就是 Folia 扫描进来的所有音频文件每条记录至少包含路径、标题、艺术家、专辑、时长、采样率这些信息核心是一个稳定的曲目标识中间层是歌单它引用曲目标识并附加一个顺序号是可以长期保存、可以导出成 M3U8 的最上层是队列它引用歌单或者曲库里的曲目额外带上播放游标和播放模式。这个分层带来的好处是导出和导入的逻辑变得非常清晰。导出歌单时你只需要遍历歌单里的曲目把每个曲目解析成文件路径再拼上元信息写成文本导入 M3U8 时你逐行读路径拿路径去曲库里做匹配匹配上就建立引用关系匹配不上就单独记下来待处理。队列保存其实就是把队列的曲目序列复制成一份歌单额外把游标和播放模式作为附注记下来恢复的时候反向操作。我之所以强调这个模型是因为后面所有的坑几乎都能归到某一层的假设被打破了。比如路径失效是曲库层的标识和实际文件系统脱节了顺序错乱是歌单层的顺序号没被正确写入或者被重新排序覆盖了编码乱码是导出时文本层的字符集选错了。心里有这三层排查的时候就能快速定位是哪一层出的问题而不是在一堆设置项里瞎试。2. 核心机制拆解队列保存、排序、M3U8 到底怎么运作2.1 队列的持久化从内存列表到可恢复快照队列在程序里通常就是一个数组加一个下标再配上几个枚举值表示循环和随机状态。要让它在重启后还能恢复需要把这些内存结构序列化成一份快照。快照里我认为至少要包含五样东西曲目标识的有序列表、当前播放索引、当前曲目的播放进度、随机与循环模式、快照写入时间。少了任何一样恢复出来的体验都会打折扣——比如只存列表不存索引重启后永远从第一首开始播用久了会非常烦。这里有个设计上的取舍值得说一下快照里存的是曲目标识还是文件路径存标识的好处是稳定曲库重新扫描、文件被移动位置只要标识逻辑能对上队列就能恢复坏处是标识依赖内部数据库一旦库重建就可能全丢。存路径的好处是直观、跨程序可用坏处是文件一动就失效。我倾向于两者都存以标识为主、路径为兜底恢复时先按标识找找不到再按路径模糊匹配一次这样能覆盖绝大多数场景。恢复过程本身要设计得抗打击。真实情况是你保存队列的时候曲库里有 500 首下次打开的时候可能有 3 首被删了、2 首被改名了。如果恢复逻辑是任何一首找不到就整个放弃那体验会非常糟糕。合理做法是逐条恢复、跳过失效项、最后给一个提示已恢复 495 首5 首未找到。我在实际使用中最看重的就是这个容错度宁可少恢复几首也不要整个队列打不开。注意队列快照会随着播放频繁写入如果你把写入频率设得太高比如每次切歌都落盘在机械硬盘或者网络存储上会造成明显的 IO 抖动。常见的做法是节流比如切歌后延迟几秒再写或者只在暂停、退出、手动保存时写。2.2 排序逻辑看起来简单坑最多的地方排序这件事表面上是按标题排还是按艺术家排实际上一旦你的曲库里有中文、有数字、有大小写混杂、有多碟专辑问题就会成串冒出来。我先说最容易被误解的一点排序不会改变歌单的原始顺序除非你显式地应用了排序。很多播放器的行为是显示时排序和保存时排序分开的你在界面上看到按字母排好了导出的 M3U8 里可能还是原始顺序。Folia 里也一样你要区分视图排序和写入顺序前者只影响你看后者才影响导出结果。第二个坑是字符串排序和自然排序的区别。纯字符串比较会把 Track 10 排在 Track 2 前面因为字符 1 小于 2。对于音轨号、碟号这种带数字的字段必须用自然排序natural sort把连续数字当作整数比较。这个问题在古典音乐或者多碟套装里几乎必然出现你会看到第二碟的第一首莫名其妙跑到第一碟第十首前面。第三个坑是中文排序的规则。默认的字符串比较是按 Unicode 码点走的结果就是中文标题的排序看起来毫无规律。想要按拼音排需要引入 locale 相关的排序规则或者干脆把标题转成拼音再做比较。我的建议是如果你的歌单里中文占多数别指望默认排序老老实实用拼音键或者手动排序。手动排序虽然费点事但至少结果可预期。排序维度适用场景需要注意的点标题杂食歌单、单曲集合中文需转拼音否则顺序不可读艺术家按人听专辑多艺术家合作曲目归到哪个键要定规则专辑 音轨号完整专辑播放音轨号必须自然排序碟号要参与比较添加时间最近收藏的歌依赖入库时间戳重扫曲库可能被刷新时长通勤、运动场景时长读取失败会变成 0排在最前手动顺序精心编排的精选集必须有稳定的顺序号字段不能靠数组下标还有一点经验多级排序一定要有稳定的兜底键。比如按艺术家、再按专辑、再按音轨号如果这三项都相同比如同一张专辑里的重复曲目排序结果在不同实现下可能不一致导出两次顺序就不一样。加一个文件路径或者曲目 ID 作为最后一级比较能保证结果稳定可复现。2.3 M3U8 格式规范逐行拆解M3U8 的结构简单到可以用一句话概括第一行是#EXTM3U头之后是若干组扩展信息行 路径行。扩展信息行的格式是#EXTINF:时长,显示名称时长单位是秒未知时写 -1 或者干脆省略路径行就是音频文件的位置可以是绝对路径也可以是相对路径。除此之外以#开头的都是注释或扩展标签解析器一般会忽略不认识的。一个典型的文件长这样#EXTM3U #EXTINF:245,某艺术家 - 某曲目 /music/albums/demo/01.flac #EXTINF:198,某艺术家 - 另一首 /music/albums/demo/02.flac看起来没什么但细节全在看不见的地方。第一编码必须是 UTF-8。这是 M3U8 和 M3U 最本质的区别老的 M3U 用的是系统本地编码在中文环境下经常是 GBK一换机器就乱码。有些导出工具会额外加 BOM 头EF BB BF部分老播放器不认 BOM会把第一行读成\ufeff#EXTM3U从而认为文件无效。我的做法是导出时不写 BOM导入时主动剥掉可能的 BOM兼容性最好。第二换行符。Windows 习惯 CRLF类 Unix 习惯 LF很多解析器两者都能处理但有些粗糙的实现会把\r当成路径的一部分导致路径明明对却找不到文件。如果你导出的文件要给车载或者老设备用CRLF 更保险。第三时长字段的精度。规范上写整数秒但有些工具导出的时长会带小数或者千分位解析时要做好容错。时长写错本身不影响播放它主要影响导入时按时长做去重或者匹配的准确度。第四路径的写法。这是导入导出里最容易出问题的地方我在下一节会专门拆开讲。简单说绝对路径跨机器必然失效相对路径依赖基准目录Windows 的反斜杠在跨平台时经常需要转成正斜杠。3. 实操把队列存下来、把顺序理干净、把歌单导出去3.1 环境与前置准备动手之前先把三件事确认好能省掉后面一大半的返工。第一是曲库的路径规划。我强烈建议把音乐放在一个固定的根目录下比如统一放在某个盘符下的Music目录子目录按艺术家/专辑组织。这样做的好处是相对路径有意义导出 M3U8 时可以用相对路径整个目录搬到别的机器上歌单跟着一起搬还能用。如果你的音乐散落在十几个不同目录那只能走绝对路径跨机器必然要重新匹配。第二是确认曲库扫描是完整的。导出歌单时如果某首歌在数据库里有记录但文件其实已经不在原位导出出来的路径就是死链。所以导出前先在 Folia 里触发一次曲库重新扫描或者完整性检查把失效条目清掉。这一步看起来很笨但比导出之后发现一半是坏的强。第三是编码和 locale。如果你打算用脚本处理 M3U8脚本运行环境要保证读写都是 UTF-8。Python 3 默认按 locale 决定open()的编码在某些系统上默认不是 UTF-8读中文路径会直接抛异常。稳妥写法是显式指定encodingutf-8读的时候用errorsreplace兜底。# 快速确认一个 m3u8 文件是不是 UTF-8、有没有 BOM file -i playlist.m3u8 head -c 3 playlist.m3u8 | xxd如果输出显示utf-8且前三个字节不是efbbbf说明文件是干净的 UTF-8、没有 BOM跨播放器兼容性最好。3.2 队列保存与恢复的完整操作队列保存的操作意图是把当前播放队列连同游标状态落盘下次能原样接上。在 Folia 里通常有两条路径可选——一是自动会话恢复退出时自动保存、启动时自动还原二是手动另存为歌单把队列固化成一个正式歌单。这两者的用途不同我是这么用的日常听歌靠自动恢复不用管一旦某个队列我听着顺耳、想长期保留就手动另存成一个歌单起个明确的名字之后从歌单加载。手动另存的时候有个细节要注意是否保留当前播放位置。多数实现会另存成一个普通歌单游标信息丢失下次从这个歌单加载会从第一首开始。如果你希望恢复的是接着刚才的位置播那要确保自动会话恢复是开启的而不是靠歌单。这两个机制不要指望互相替代。恢复环节最需要关注的是失效处理策略。理想的行为是逐条尝试恢复找不到的跳过并记录最后汇总提示。我自己踩过的坑是早期版本里只要有一首找不到整个队列就恢复失败而且不给任何提示表现就是打开播放器队列空了非常迷惑。后来我养成了一个习惯保存队列之后立刻去文件管理器里确认一下曲目都还在尤其是那些放在移动硬盘或者网络位置上的。提示如果你的音乐库在可移动存储上挂载点变化比如从/Volumes/DiskA变成/Volumes/DiskA-1会让所有绝对路径失效。这种情况用相对路径导出歌单或者干脆固定挂载点名称。还有一个实用技巧定期把重要队列另存为带日期的歌单。比如通勤-2024-05这种命名既是备份也是归档回头想找某段时间常听的歌直接翻歌单就行。这比依赖播放历史靠谱得多历史记录通常只能看不能直接播。3.3 排序规则配置与自定义顺序Folia 的排序入口一般有两处歌单内的排序和曲库视图的排序。前者影响你导出的顺序如果导出时选择按当前显示顺序后者只影响浏览。我建议养成一个习惯进歌单之后先看一眼当前排序是什么如果是按标题而你希望导出的是原始编排顺序记得切回手动/自定义再导出否则导出的文件顺序和你预期完全对不上。自定义顺序的实现依赖一个顺序号字段。你在界面上拖拽调整位置本质上是在改这个字段的值。这里有个经典的实现问题如果顺序号是连续的整数每次插入都要把后面所有项重新编号歌单一长就卡如果顺序号是稀疏的比如步长 1000插入只改一项性能好很多但插入次数多了会耗尽间隙、需要重排。你在使用中如果发现拖拽之后顺序偶尔错乱很可能是间隙耗尽的边界情况。多级排序的配置我的一般做法是整理阶段用艺术家 → 专辑 → 碟号 → 音轨号把整张专辑排整齐然后切到手动模式在这个基础上微调。这样既有结构又不失灵活。对于杂食歌单用添加时间倒序快速找到最近收的歌再手动往合适的位置挪。场景推荐排序链理由完整专辑播放专辑 → 碟号 → 音轨号还原原始唱片顺序单艺术家精选艺术家 → 添加时间同一个人按收录先后听通勤随机歌单手动顺序精心编排不交给算法最近收藏添加时间倒序新歌优先古典/现场专辑 → 音轨号自然排序乐章顺序不能乱最后再强调一次自然排序。任何带数字的字段音轨号、碟号、作品号都必须按数值比较不能按字符串比较。你可以自己做个小测试建一个歌单放十首标题带序号的曲目按标题排序看看第 10 首是不是跑到了第 2 首前面。如果跑过去了说明这个版本用的是纯字符串比较那就别用标题排序来组织有序号的曲目。3.4 导出 M3U8参数选择与路径策略导出时的核心决策只有一个用绝对路径还是相对路径。这个选择直接决定了歌单的可移植性。绝对路径的优点是导出即可用双击就能播不需要任何基准目录。缺点是换机器、改目录名、换挂载点全部失效。相对路径的优点是整个音乐目录可以整体搬迁只要 M3U8 和音乐目录保持相对关系到哪都能用。缺点是有基准目录的概念播放器要能正确解析。我的选择是给自己用导相对路径给别人用导绝对路径。别人拿到你的相对路径歌单基准目录对不上等于没用。具体到相对路径的计算规则通常是以 M3U8 文件所在的目录为基准用../往上跳。比如歌单放在Music/playlists/下曲目在Music/albums/demo/01.flac那相对路径就是../albums/demo/01.flac。import os def to_relative(track_path, playlist_dir): 把绝对路径转成相对于歌单目录的路径统一用正斜杠 rel os.path.relpath(track_path, playlist_dir) return rel.replace(os.sep, /)这段代码里.replace(os.sep, /)很重要。Windows 上os.path.relpath返回的是反斜杠虽然本机播放器多半能认但一旦文件传到别的系统就废了。统一成正斜杠是最省心的做法现代 Windows 播放器也能正常处理正斜杠。导出参数方面还有几个选项值得留意是否写入时长、是否写入扩展标签、是否包含失效条目。时长建议写虽然不影响播放但很多工具会用它来估算歌单总时长缺了会显示 0。扩展标签比如#EXTALB、#EXTPERFORMER是 Foobar2000 那类播放器的扩展写了不影响兼容性但不认识的播放器会忽略属于写了没坏处的类型。失效条目一定要排除否则导出的歌单里混着一堆死链导入的时候还要再清理一遍。注意导出后一定要抽检。随机打开文件看前几行确认头行是#EXTM3U、编码没乱、路径分隔符正确。我遇到过一次导出工具把中文路径转成了 URL 编码%E4%B8%AD播放器完全认不出来肉眼扫一眼就能发现。3.5 导入 M3U8匹配失败怎么办导入的本质是路径匹配拿到 M3U8 里的一行路径去曲库里找对应的曲目。匹配成功的条件通常是路径完全一致宽松一点的实现会做规范化统一分隔符、忽略大小写、解析符号链接后再比较再宽松一点会用文件名匹配忽略目录差异。这三档的匹配率差异很大。匹配失败的原因按出现频率排大概是这样失败原因表现处理方式绝对路径跨机器整片失败改用文件名匹配或用脚本重写路径前缀目录改名/移动部分失败批量替换路径中的旧前缀盘符变化Windows 上整片失败脚本替换盘符编码不一致中文路径乱码转成 UTF-8 重新保存大小写差异少量失败匹配时忽略大小写反斜杠/正斜杠部分失败匹配前统一分隔符符号链接部分失败解析真实路径后再比较我的实战顺序是先改编码再统一分隔符然后处理路径前缀最后才考虑用文件名兜底。前几步都是无损的、可批量脚本化的最后一步有风险因为同名文件可能匹配错。路径前缀替换是最常用的一招。比如歌单里全是/Volumes/OldDisk/Music/...而音乐现在在/Volumes/NewDisk/Music/...一条sed就能搞定sed -i s|/Volumes/OldDisk/Music/|/Volumes/NewDisk/Music/|g playlist.m3u8在 Windows 上换成盘符替换也是同理。注意sed -i在部分系统上需要额外参数用之前先备份一份原文件这是血泪教训——我有一次替换写错了一个字符把整个歌单的路径全毁了幸好有备份。导入之后还有一步验证要做看看成功导入了多少首、失败了多少首、失败的是哪些。如果失败列表很长不要急着一条条手动修先看失败项有没有共同特征比如都指向同一个旧目录有共同特征就能批量处理。4. 用脚本把重复劳动自动化4.1 批量生成 M3U8 的思路与代码如果你有大量专辑目录想一次性给每张专辑生成一个 M3U8手动操作会疯掉。写个脚本扫目录是最省事的。思路很直接遍历目录树找出音频文件按目录分组每组写一个 M3U8文件名用目录名。import os from pathlib import Path AUDIO_EXT {.flac, .mp3, .m4a, .wav, .ogg, .opus, .ape} def build_m3u8(album_dir: Path, out_path: Path) - int: tracks sorted( (p for p in album_dir.iterdir() if p.is_file() and p.suffix.lower() in AUDIO_EXT), keylambda p: p.name ) if not tracks: return 0 lines [#EXTM3U] for p in tracks: # 时长未知时写 -1显示名用文件名去掉扩展名 lines.append(f#EXTINF:-1,{p.stem}) lines.append(p.name) # 同目录下直接用文件名就够了 out_path.write_text(\n.join(lines) \n, encodingutf-8) return len(tracks) def walk(root: str): root_p Path(root) total 0 for album_dir in sorted({p.parent for p in root_p.rglob(*) if p.is_file() and p.suffix.lower() in AUDIO_EXT}): out album_dir / f{album_dir.name}.m3u8 n build_m3u8(album_dir, out) if n: total n print(f{out} {n} 首) print(f共生成曲目条目 {total} 条) if __name__ __main__: walk(./Music)这段代码有几个刻意的设计。第一曲目路径写的是文件名而不是完整路径因为 M3U8 和曲目在同一目录下相对路径就是文件名本身最简洁也最可移植。第二排序用的是文件名如果你的文件名规范带序号01 - xxx.flac自然就是正确顺序如果文件名不带序号得改成读标签排序。第三编码显式指定 UTF-8避免默认编码带来的乱码。想读标签拿时长和艺术家的话装个 mutagenfrom mutagen import File as MutaFile def tag_info(path: Path): try: f MutaFile(path) if f is None or f.info is None: return -1, path.stem dur int(f.info.length) title str(f.tags.get(title, [path.stem])[0]) if f.tags else path.stem artist str(f.tags.get(artist, [])[0]) if f.tags else name f{artist} - {title} if artist else title return dur, name except Exception: return -1, path.stem用try/except把整个读取包起来是有必要的损坏的文件、非标准容器、权限问题都可能导致抛异常而批量处理最忌讳的就是遇到一个坏文件整个任务挂掉。4.2 歌单校验与去重脚本M3U8 文件用久了必然会积累问题重复条目、死链、空目录引用。写个校验脚本定期跑一遍比事后手动修省事得多。from pathlib import Path def check_m3u8(m3u8_path: Path): base m3u8_path.parent missing, seen, dup [], set(), [] current None for raw in m3u8_path.read_text(encodingutf-8, errorsreplace).splitlines(): line raw.strip().lstrip(\ufeff) if not line: continue if line.startswith(#EXTINF): current line continue if line.startswith(#): continue p (base / line).resolve() if not Path(line).is_absolute() else Path(line) key str(p).lower() if key in seen: dup.append(line) seen.add(key) if not p.exists(): missing.append(line) return missing, dup if __name__ __main__: for f in Path(./Music).rglob(*.m3u8): m, d check_m3u8(f) if m or d: print(f[{f}] 死链 {len(m)} 条重复 {len(d)} 条) for x in m[:5]: print( 缺失:, x)去重的键我用的是转小写后的完整路径因为同一首歌在 Windows 上大小写不敏感01.FLAC和01.flac指向同一个文件不转小写会漏判。如果你希望按内容去重不同路径的同一首歌那得算文件哈希或者比对标签里的艺术家加标题加时长成本更高一般没必要。lstrip(\ufeff)这行是专门处理 BOM 的。有些工具导出的文件带 BOM第一次读进来首行会变成\ufeff#EXTM3U不剥掉的话虽然它仍然以#开头会被当注释跳过但如果 BOM 出现在第一个路径行前面就会导致那个路径匹配失败。全行剥一次最保险。4.3 跨播放器格式转换不同播放器支持的格式略有差异。有的只认 M3U不认 M3U8有的支持 XSPF 或者 PLS。转换的核心其实只有一处编码。M3U 传统上用本地编码在中文环境下是 GBKM3U8 用 UTF-8。所以从 M3U8 转 M3U重点是把 UTF-8 的内容用 GBK 重新写一遍写不了的字符用替换符兜底from pathlib import Path src Path(playlist.m3u8) dst Path(playlist.m3u) text src.read_text(encodingutf-8, errorsreplace) dst.write_text(text, encodinggbk, errorsreplace)反过来从 M3U 转 M3U8先用gbk读、再用utf-8写。如果原文件编码不确定可以装个chardet之类的库猜一下或者干脆两种编码都试一遍看哪种解出来的中文是正常的。我处理别人给的歌单时基本都会先试着用 UTF-8 读一遍报错就换 GBK再不行就 GB18030这三个覆盖了绝大多数中文场景。还有个小细节转换成 M3U 之后部分老播放器对 CRLF 有要求写文件的时候可以指定newline\r\n。这个参数在Path.write_text里不支持得用open()打开再写。5. 常见问题与排查实录5.1 导入后顺序全乱这是报得最多的问题原因基本可以归成三类。第一类是导出时选了错误的排序。你在界面上按标题看的导出时也选了按当前显示顺序那导出的就是标题顺序当然不是你编排的顺序。解决方式是导出前切回手动或自定义排序。第二类是顺序号丢失。有些导出实现只写路径不写顺序导入的时候按文件系统返回的顺序重建而文件系统的遍历顺序是不保证的。这种情况你在 M3U8 里能看出来——条目顺序和你记忆中的不一样而且没有明显的规律。解决办法是导出后检查文件如果顺序不对要么换导出方式要么手动调整后重新导出。第三类是排序规则不一致。导出时按艺术家排的导入的播放器按标题重排了一遍。这种是显示排序覆盖了文件顺序得去播放器设置里把导入后自动排序之类的选项关掉。排查方法很简单用文本编辑器打开 M3U8看条目顺序。文件里顺序对那就是播放器的问题文件里顺序就不对那就是导出环节的问题。这一步能直接砍掉一半的排查时间。5.2 中文乱码与特殊字符乱码的根源永远是编码不匹配。M3U8 应该是 UTF-8如果你看到的是锟斤拷或者一堆问号说明文件不是 UTF-8 却按 UTF-8 解读了或者反过来。用file -i看一眼就能确定。file -i playlist.m3u8 # 输出 charsetiso-8859-1 或者 unknown-8bit基本就是编码不对修复的方式是用正确的编码读、用 UTF-8 写我在 4.3 节已经给过代码。需要注意的是如果文件已经被错误地保存过一次原始字节可能已经损坏这时候没法挽回只能重新导出。特殊字符方面最麻烦的是路径里带#和%。#在 M3U8 里是注释标记路径行以#开头会被当成注释忽略。%是 URL 编码的引导符有些解析器会尝试解码。如果你有文件名带这两个字符最省事的办法是改文件名别跟格式较劲。逗号也值得注意因为#EXTINF:时长,名称里逗号是分隔符名称里带逗号一般没问题只取第一个逗号后面的全部但某些粗糙的解析器会切错。还有中文路径的长度问题。Windows 的传统路径长度限制是 260 个字符深层嵌套目录加长文件名很容易超限超了之后文件能创建但某些 API 读不到。这个问题在导入时表现为文件明明存在却匹配失败很容易误判成编码问题。排查时可以尝试把文件挪到更浅的目录试试。5.3 路径失效的三种典型场景场景一换机器。绝对路径里的盘符、用户目录全部对不上。这种情况没有捷径只能做前缀替换或者改用文件名匹配。预防的办法是导出时就用相对路径。场景二移动硬盘挂载点变化。同一个硬盘插到不同电脑上挂载点可能从/Volumes/Disk变成/Volumes/Disk 1。这会让所有绝对路径失效。解法有两种一是给硬盘设置固定的卷标让挂载点稳定二是用相对路径让歌单跟着音乐目录走。场景三目录重命名。比如你把华语改成了中文流行下面所有歌单里的路径全废。批量替换能救但要注意替换的粒度别把别的路径也误伤了。我一般会先grep一下确认影响范围再动手替换。grep -c 华语 playlist.m3u8 # 先数一下影响多少行 sed -i s|/华语/|/中文流行/|g playlist.m3u85.4 时长显示为零、重复条目与空歌单时长显示为 0 通常是因为导出时没读标签写了 -1 或者 0。这不影响播放但会影响按总时长排序、影响某些播放器的进度条预估。要修复只能重新导出并且开启读取时长选项或者用脚本读标签补上。重复条目的产生原因通常是多次导入同一个歌单或者合并歌单时没去重。Folia 里一般有去重功能但它的判定标准可能是曲目 ID 而不是路径如果同一首歌在曲库里存在两条记录比如扫描了两个不同路径去重就失效了。这时候得先清理曲库里的重复记录。空歌单的原因就比较多了路径全失效导致全部跳过、编码错误导致一行都没解析出来、文件本身只有头行。排查顺序是先看文件大小如果是几百字节那就是真的空再看头几行再看有没有#EXTINF但没有路径行的情况——有些工具写文件的时候会漏掉路径这是实现 bug。5.5 问题速查表现象最可能的原因第一步动作导入 0 首编码错误 / 路径全失效file -i看编码文本编辑器看前几行顺序错乱导出时用了显示排序检查 M3U8 内条目顺序中文乱码非 UTF-8 被当 UTF-8 读用正确编码重读重写部分曲目找不到路径前缀变化 / 大小写统一分隔符、批量替换前缀时长全是 0导出未读标签重新导出开启时长读取有重复条目多次导入 / 曲库重复按路径转小写去重先清曲库首行报错BOM 头读时剥掉\ufeff播放器显示空歌单文件里只有头行检查文件大小和路径行数量排查工具用途一行命令file判断编码与文件类型file -i x.m3u8head看头几行快速判断结构head -20 x.m3u8grep统计某类条目数量grep -c EXTINF x.m3u8sed批量替换路径前缀sed -i s|旧|新|g x.m3u8wc看总行数是否合理wc -l x.m3u8我把这套方法用了挺长时间最大的体会是歌单出问题九成能在纯文本层面看出来。不要一上来就怀疑播放器的数据库坏了、去重装软件先head一下文件很多问题当场就现形了。另外任何批量替换之前一定先备份这个习惯帮我省过好几次事。至于队列别指望它自动帮你留住什么觉得好听就立刻另存成歌单这是我踩过最多的坑之后固定下来的动作。