1引言
之前写了几篇关于动感歌词的简单介绍，相信大家还有印象，这里就不多说了，这篇要说的是，关于翻译歌词和音译歌词，以及我在解析和显示这两种歌词的时候，遇到的一些难题、技术和心得。
2动感歌词格式
下面我简单说一下，关于翻译歌词和音译歌词保存在哪里的问题。因为我主要研究的是krc歌词，所以这里我会以krc解析为主。当然，我也根据自己的实际需求，自定义了一种歌词格式，方便自己使用，这里也会简单说一下，为了区分音译和翻译歌词，我把原来的歌词，称为：【原始歌词】，音译和翻译歌词统称【额外歌词】。
2.1krc歌词
krc歌词，分析篇也说了，虽然是加密了，但是也难不到万能的网友。以下是根据网上提示的算法，得到解密后的歌词内容：
锘�[id:$0145B5C5]
[ar:�跺お][ti:蹇��ㄥ����]
[by:]
[hash:fa8e1508c06761a9b82631f1cf7c3b54]
[al:]
[sign:]
[qq:]
[total:1230449]
[offset:0]
[language:eyJjb250ZW50IjpbeyJsYW5ndWFnZSII6MX0= 。。。。。。。。。。。（此处省略100字）。。。。。]
[28131,4758]<0,1302,0>璧�<1302,951,0>��<2253,401,0>��<2654,250,0>��<2904,1854,0>��[33690,5705]<0,800,0>��<800,2152,0>浜� <2952,201,0>��<3153,249,0>��<3402,402,0>��<3804,199,0>��<4003,903,0>娴�<4906,799,0>��

对的，你看到的不是乱码，这是我为了找到有翻译和音译的krc歌词，而找的一份歌词（茶太 - 志在千里_{恋姫喚作百花王}.krc），里面的乱码其实是日语来的，好了废话不多说，其实我们只要细心看便会看到歌词里，有一行：
[language:eyJjb250ZW50IjpbeyJsYW5ndWFnZSII6MX0= 。。。。。。。。。。。（此处省略100字）。。。。。]

是的，就是这一行，krc歌词里面的翻译歌词和音译歌词，都在这一行里面，看到这些abcd是不是好眼熟？对的，这些字符串，就是base64加密后的字符串。我们解密来看看，是什么东东，解密内容如下：
{"content":[{"language":0,"lyricContent":[["a","kaku","ne","nyu","ru"],["a","kanegumo","shi","zu","shi","zu","naga","ru"],。。。。（此处省略100字）。。。。。。。。。。。],"type":0},{"language":0,"lyricContent":[["\u71C3\u7684\u706B\u7EA2"],["\u7EC6\u7EC6\u6447\u66F3\u7684\u6697\u7EA2\u8272\u7684\u4E91\u6735\u9759\u9759\u6D41\u52A8"],["\u8EAB\u540E\u9668\u843D"]。。。。（此处省略100字）。。。。。。],"type":1}],"version":1}

从解密后的内容可以看到，type=0是音译歌词，type=1是翻译歌词，其中歌词中看不到与时间相关的标签，这是因为【原始歌词】中已经含有了时间的标签和精准到【字】的时间标签。翻译歌词相对简单，只需要与原始歌词的【行】对应即可。音译歌词，除了与原始歌词的【行】对应外，还与【行】歌词里的每个【字】相对应。
2.2hrcs歌词
该歌词格式是之前hrcx歌词的升级版。我们先回顾一下hrcx歌词的格式：
[ti:右手戒指];
[total:272706];
[ar:金海心];
[offset:0];
[by:HappyPlayer-PC];
haplayer.lrc('<1270,9630>','金海[心 ][- ]右手戒指','<1010,780,830,1410,800,1210,1410,910>');
haplayer.lrc('<18710,19810>','[la ][la ][la ]','<300,400,400>');haplayer.lrc('<20020,22840><77150,79970><163120,165840><191920,194740>','是你梦中的女郎','<200,300,400,300,510,500,610><310,400,300,510,400,400,500><200,510,400,400,410,500,300><210,400,300,400,400,510,600>');

从歌词格式内容，我们可以看到，在解析歌词的时候，我们还要费时去解析歌词行的每个【字】（最可怜的还是要判断该【字】是中文、英文、韩文还是日文，最变态的还是泰文），然后对歌词进行分割，得到【字】然后，最后解析后面的时间标签再得到【字】对应的时间。是的，解析歌词行的每个【字】，这是在制作歌词的时候，才需要去做的事情啊，所以这里也是需要优化的地方，加上各种歌词间相互转换时，该格式存在出错的概率比较多，往往会因为得到的【字】个数与后面的【字】时间个数不对应，而报错。所以基于以上的种种原因，我重新改良了该歌词的格式：
haplayer.tag[qq:];
[ti:志在千里];
haplayer.tag[total:1230449];
haplayer.tag[by:];
haplayer.tag[sign:];
haplayer.tag[al:];
[ar:茶太];
[offset:0];
haplayer.tag[hash:fa8e1508c06761a9b82631f1cf7c3b54];haplayer.extra.lrc('eyJjb250ZW50IjpbeyJseXYSI。。。。（此处省略100字）。。。。。。。。。。。sImkiLCJ0ZSJdXX1dfQ==');
haplayer.lrc('<28131,32889>','<赤><く><燃><ゆ><る>','<1302,951,401,250,1854>');

从上面的内容可以看出，该歌词格式也是支持音译歌词和翻译歌词的（参考krc原理）。主要优化在歌词行：
haplayer.lrc('<28131,32889>','<赤><く><燃><ゆ><る>','<1302,951,401,250,1854>');

在这里，我将每个【字】用<>来包住，这样子在解析时，除了简单，相对准确性会比较高。
3歌词实体类结构变化
歌词实体，添加音译歌词和翻译歌词

原始歌词行实现，添加分割后的歌词行集合

音译歌词实体

4歌词过长换行显示思路
在上面的歌词实体，新添加分割后的歌词行集合。当歌词内容过长，超出了显示的view时，歌词超出的部分会换行显示。在这里，我不是在显示的时候，才对歌词进行换行处理的，我的思路如下：
解析歌词文件，得到原始的歌词集合
根据view的大小，对歌词集合中的原始行歌词，进行分割，得到换行后的歌词集合

5多行原始歌词（包含歌词过长换行）显示思路
关于多行歌词的显示方式，我在显示篇的时候，已经讲解过，原理也是差不多的。这里以android为例子，在文章最后我会贴上我的源码，之前关于view的平滑移动是使用ValueAnimator的动画来实现的，我发觉它在实现fling的效果时，并不是好理想。所以我就转用了scroller来实现view的平滑移动，这里需要注意的是，scroller只做动画，不要使用它来移动view。我实现的思路如下：
主要是以分割后歌词集合作为绘画当前歌词的数据。
行的高度= （歌词高度 + 空行高度）* 分割后歌词的行数
每行歌词与所在view的位置绑定，公式：Y=行号（歌词高度 + 空行高度）
动感歌词行居中显示，公式：（view的中间值+（歌词高度 + 空行高度））0.5 + 移动到当前行号所需的Y值- offsetY
offsetY是从当前歌词行切换到下一行时，需要的偏移值，公式：offsetY= 移动到【新】行号所需的Y值 - 移动到当前行号所需的Y值
移动到行号所需的Y值 = 第0个到行号的每行高度累加值。
歌词滑动快进时，在计算滑动所在的行号（需要注意行的高度），可通过offsetY值和每行歌词与view所绑定的位置关系，来计算当前对应的是第几行歌词。
在绘画歌词的过程中，顺序需要变一下，存在歌词过长换行的情况，所以每行歌词的Y值会有变化。先绘画当前歌词行，计算绘画分割后的当前行所需的Y值后，再使用该Y值来绘画当前歌词行下面的歌词。

实现效果预览：

6多行额外歌词显示思路
原理和多行原始歌词显示差不多，需要注意如下问题：
音译歌词：音译歌词因为需要知道每个【字】的时间，所以需要在原始歌词的基础上构造音译歌词。
翻译歌词：如果需要像音译歌词那样显示动感效果，则需要获取歌词的持续时间，计算每个【字】的平均时间，所以也是需要在原始歌词的基础上获取开始时间和结束时间，计算每个【字】的平均时间。
移动到行号所需的Y值，需要加上额外歌词行的高度
绘画歌词时，画完当前行分割的歌词后，需要向下画行对应的分割额外歌词。最后再向下画下一行歌词。在画当前行歌词上面的歌词时，先画额外歌词。

实现效果预览：