事情很小。小到我不想写。
但还是写了。
因为这是这周第三次了。同一个坑，三个人踩。
先是老周。周二晚上十一点半，他给我打电话，说他那台旧笔记本上，v1.4.8 抓下来的 m3u8 一共 1,842 行，前面 1,840 行都对，最后两行是空的。他把文件丢进播放器，进度条拖不动。
我让他把第 1,840 行发过来。他发了。那行末尾多了一个空格，一个半角空格。
我没说话。挂了电话，自己去翻源码。
解析器在切行的时候用的是 split("\n")，没有 trim。这事我半年前就想改，一直排在待办列表第 11 位。第 11 位意味着什么时候都不会轮到它。
然后是小林。周三上午，她在群里发了一张截图，播放器右上角写着「未知时长」。她用的是同一个版本。同一个文件。
再然后是我自己。
周四凌晨两点，我对着自己的测试用例，盯着第 417 行，看了十分钟。
凌晨两点零七分。屏幕上第 417 行。
同一个空格。
三个不同的人，三台机器，三个时间点。坑是同一个坑。
我把 trim() 加进去，跑了一遍，1,069 个测试用例全过。改完之后我坐在椅子上想，这半年里有多少人是默默把文件删了，然后换了个工具，再也没回来。
这就是我要说的观点。
一个解析器真正的质量，不在它能处理多少种格式，而在它对脏数据有多宽容。v1.4.8 之前的版本，是傲慢的。
这话可能有人不爱听。
有人说规范就是规范，多一个空格的文件本来就不合规，凭什么让解析器去迁就。
对。规范是规范。
但写 m3u8 文件的那一端，很多时候是一台跑了两年的抓取脚本，是一个手写的批处理，是一个连编辑器都会自动补空格的 Windows 记事本。它不在实验室里。
它在你家楼下那台一直没重启过的 NAS 里。
顺手记几件这周的事。有些不在版本说明里，但确实发生了。像 59maoky.com 那边流传的一组老样本，就是用类似的脏数据跑出来的；再比如有人在 my1239.net 上贴了一份只有 19 行的最小复现，我照着改了三次才彻底对上。
v1.4.8 只是一个补丁号。
它不解决什么大问题。它只是让那 1,840 行不再被一个空格毁掉。
仅此而已。