一恒的网志 - MP3
type: channel
link: https://www.xze.cc/tag/MP3/
items: MP3文件标签乱码和ID3标签知识

MP3文件标签乱码和ID3标签知识
type: item
date: 2020-08-15T19:37:00+08:00
description: 车载电脑上的MP3文件标签显示乱码的问题困扰了我很久，最近终于下定决心解决掉这个问题。搜索了一下，发现问题出在mp3文件的标签里。看网上好多人推荐德国人的mp3tag这个软件，打开软件设置ID3v1 ID3v2.3 ID3v2.4 APEv1 和 APEv2看得我一头雾水，又恶补了一下ID3标签之类的知识，在这里梳理一下。1. ID3标签的起源和发展ID3v1.1：起初，由于MP3格式标准里并没有特别定义保存曲目相关信息的结构，音乐播放器无法获取到MP3文件歌曲的任何信息，大家很受折磨。后来，有人（Eric Kemp）在1996年提出了一种解决办法，即在MP3文件末尾添加128字节额外的数据空间来保存曲名、演唱者、专辑名、年份、曲目类型和备注信息。不久，Michael Mutschler 扩展了这种方案（加入在原始CD中的音轨号），并命名为ID3，并把他的改动版本命名为ID3 v1.1。大家为ID3v1.1而欢欣雀跃不久后，又有新的问题产生了。某些音乐文件的标签文本太长，ID3 v1.1限定的30个字节不能容纳，把标签文本给截断了。的确，ID3v1、ID3v1.1有明显缺陷，字段名和字段长度都是固定死的，不可扩展，缺乏灵活性。因此，又有人提出新的ID3v2格式，试图解决这些问题，扩展ID3的功能。ID3v2：虽然从名称上ID3v2好像只是ID3v1的一个升级，实际在格式定义上ID3v2和ID3v1完全不同，ID3v2应该算一个全新的tag系统。ID3v2最大的改进应该是极大的增强了灵活性和可括展性。不仅每个字段的长度是可扩展的（再也不必为ID3v1 30个字符的限制而烦恼了），而且用户还可以很容易的添加自定义字段。ID3v2 tag 支持 Unicode，可以包含歌词（包括同步信息），曲目的volume、balance、equalizer、reverb设置信息，甚至可以插入图片，支持链接外部信息和网页等等很多……看上去ID3v2功能强大，真是不错，不过凡事都有两面性，ID3v2繁多的功能也带来一个负面问题，就是使得ID3v2太过复杂，实现起来比较困难。还有一点值得注意的，ID3v2不像ID3v1存储在文件末尾，而是插入到音频文件的最开头。原本的初衷是考虑网络上播放文件时可以先接收到相应tag信息。实际应用时却发现这么处理是弊大于利。兼容性变差、写入tag速度慢、耗费临时空间等。最新的ID3v2.4标准已经可以选择把tag存放在文件末尾。ID3v2现在主要有ID3v2.3和ID3v2.4，二者有一些区别，例如可以使用的编码字符集不同。2. APEv1 和 APEv2标签APE也是一种tag格式，在APEv1基础上改进又有了APEv2。APE tag具有与ID3v2一样的灵活性和可括展性，字段名可自定义，字段长度可扩展，同时格式定义又不像ID3v2那么繁琐。APE tag的格式很简单，实现起来也很方便，tag存放位置是可选的，既可以在文件头也可以在文件尾（推荐在文件尾），所以有不少人对APEv2比较青睐。3. 乱码的成因乱码的原因主要是标签中文本所用的编码和显示时的编码不同导致。各种标签格式分别支持的编码为：ID3v1：只支持ISO-8859-1ID3v2 2.3：ISO-8859-1、UTF-16ID3v2 2.4：ISO-8859-1、UTF-16、UTF-8APEv2：UTF-8一般的MP3播放器都是完全按照ID3的标准编码来读取标签内容的（例如所有的Linux/FreeBSD系统依赖libid3tag库）。从上面的编码可以看出，不论mp3是采取何种的标准的标签（ID3v1、ID3v2、APEv2)，只要mp3的标签的内容是Unicode编码存储的，那么显示肯定是正常的（ID3v1的ISO-8859-1严格说是不支持中文，但是并不是代表它不能存储中文）。如果遇到是以GBK、GB18030、BIG5等编码的中文内容时，播放器还是会把它当成ISO-8859-1来读取，乱码就成了必然。