ちょっとね～と言う話は出ていると思います。

MP3などで、タグの文字コードがShiftJISになっているとウィジェット上で文字化けしてしまう

と言う問題が少し前のバージョンからなっています。

単にShiftJISの表示サポートを切っただけだと思いますが、これになってからウィジェット上で曲名が確認できなくなって大変になりました。

さすがに戻すつもりはなさそうなので個人的に対応に出ることにしました。

対応策は「タグの文字コードをUTF-8にする」こと

です。つまるところ、文字コードの縛りを抜けるためにはもっと汎用的な文字コードにする、と言う解決法が最も妥当という判断です。

なお、タグの文字コードをUTF-8にしても、Windowsのエクスプローラ上ではちゃんと読めるのが不思議だったりします。

ただ、問題点としては

• Windows上でUTF-8でタグを扱ってくれるソフトがあまりない(MacやLinuxの場合は文字コードとしてShiftJISを扱うことが今ではあまりないので)
• ShiftJISに比べて全角文字を使うと文字を表すのに必要なデータ量が増えるためにタグの文字領域が不足する(MP3だとID3v1ではかなりの曲が入らなくなる。そのため、タグ形式をID3v2にして格納する必要があり)
• いままでに大量にShiftJISでタグを書いていた曲ファイルを持っているときにそれらすべてを変換しようとするととても手間

というものがあります。仕方がないのでAndroid上に転送してあるファイルだけ強制的に文字コードをUTF-8にして対応することにしました。

ソフトはUTF-8をつかってMP3タグ、と書いて検索に一番初めに出てきた「EasyTag」というプログラムを使用しました。

ちなみに、このEasyTagですが、描画でGTK+が必要だったり、文字コード変換用にiconv.dllを用意する必要があるなどちょっと導入に手間取りました。

しかも、どうも全角のファイル名の処理に対応していない(もしくは設定を忘れた)ようで、ファイル名が内部的に壊れるらしく、変換処理時に「ファイル名を変更しますか？」と聞いてきたくらいです。

(もちろん、逆にファイル名を変更するといろいろと問題が出るのでやってはいけませんよ)

2013/02/26 追記

こちらにEasyTagを使った直し方を改めて記事にしました。参考に。

変換がうまくいけば普通に表示されます

私の方もちゃんと表示が直って一安心です。次回以降の問題点としては次の曲追加時にはまた文字コード変換がいるので面倒なのですよね・・・。

バッチプログラムとか作って対応すると実は楽なのかもしれないな～と思った今日この頃。それくらいなら作るのは(タグの置き方さえ知っていれば)簡単なのですが・・・。