车载电脑上的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-1
ID3v2 2.3：ISO-8859-1、UTF-16
ID3v2 2.4：ISO-8859-1、UTF-16、UTF-8
APEv2：UTF-8

一般的MP3播放器都是完全按照ID3的标准编码来读取标签内容的（例如所有的Linux/FreeBSD系统依赖libid3tag库）。从上面的编码可以看出，不论mp3是采取何种的标准的标签（ID3v1、ID3v2、APEv2)，只要mp3的标签的内容是Unicode编码存储的，那么显示肯定是正常的（ID3v1的ISO-8859-1严格说是不支持中文，但是并不是代表它不能存储中文）。如果遇到是以GBK、GB18030、BIG5等编码的中文内容时，播放器还是会把它当成ISO-8859-1来读取，乱码就成了必然。