Perl处理iTunes导出XML时Unicode字符输出异常的技术问询

你遇到的异常本质是两个层级的Unicode处理缺失，和复现场景的对应关系非常明确：

• 输入子串Pre%CC%81是macOS版iTunes导出路径的典型编码特征：URL编码的分解式（NFD）Unicode字符é，解码后对应字符序列为e（U+0065）+ 组合重音符号（U+0301）
• 输出的PreÌ是典型的字节误读错误：%CC%81是U+0301的UTF-8编码字节（0xCC、0x81），如果这两个字节没有被按UTF-8规则解码为单个Unicode字符，而是被逐字节按Latin-1单字节编码解释，0xCC会被映射为独立字符Ì（U+00CC），0x81为不可见控制字符最终被丢弃，就出现了拆分显示的异常。

1. 修正URL解码环节的编码逻辑 #

当前代码依赖URI::Escape解码路径，但uri_unescape函数默认仅把%xx格式的占位符替换为原始字节，不会自动将字节流按UTF-8解码为Perl内部的Unicode字符串，这是产生PreÌ异常的直接原因。
对应调整逻辑：

use URI::Escape qw(uri_unescape);
# 处理iTunes Location字段的标准流程
my $raw_encoded = <从XML节点取出的Location字段值>;
# 先剥离file://前缀
$raw_encoded =~ s{^file://}{};
# 解码URL编码为原始字节
my $path_bytes = uri_unescape($raw_encoded);
# 关键：将UTF-8字节流显式解码为Perl内部Unicode字符串，避免单字节误读
utf8::decode($path_bytes);

2. 补充Unicode规范化步骤 #

即使完成正确的UTF-8解码，此时的路径字符还是macOS特有的分解式（NFD）形式：e和组合重音是两个独立的字符，这种形式在Windows路径、跨平台播放列表兼容性上存在问题——Windows系统的文件系统默认采用预组合式（NFC）Unicode存储文件名。
需要在路径清洗完成后增加规范化步骤：

use Unicode::Normalize qw(NFC);
# 将分解形式的NFD字符转换为预组合形式的NFC字符，此时「e + 组合重音」会合并为单个字符「é」
my $compat_path = NFC($path_bytes);

3. 排查其他易遗漏的配置点 #

• 确认XML::LibXML的加载逻辑没有绕过自动解码：load_xml(location=>$source)默认会根据XML声明的编码自动将节点内容解码为内部Unicode字符串，该环节无需额外调整，但如果后续流程里手动读取文件、拼接字符串，就需要同步确认编码状态
• 避免在路径处理的中间环节出现编码降级：比如拼接路径时不要用默认字节模式的操作破坏内部UTF-8 flag，正则处理路径时如果匹配Unicode范围，需要显式加/u修饰
• 输出环节的配置无需修改：当前代码中binmode(m3uHandle, ":utf8")的逻辑是正确的，只要确保所有写入文件的字符串都是Perl内部Unicode字符串，就不会出现编码错位

内容的提问来源于stack exchange，提问作者Coltrane58