MP3データベースの表記について

すでにお気づきの方もおられると思うのですが、MP3データベースの表記を日本語からアルファベット表記に変更しています。

例えば、

今までは、

「Rachmaninov:ピアノ協奏曲第2番 ハ短調 作品17」

だったのが、

「Rachmaninov:Concerto for Piano and Orchestra No.2 in C minor Op.18」

となっています
いろいろと考えてみたのですが、これが最も手間のいらないやり方だという結論に達しましたのでご理解ください。

マイクロソフトは一貫して日本語版では「shift_JIS」を基本の文字コードとして使用してきていました。日本語のようなマルチバイト文字をパソコンで表記するときはこの文字コードの問題は常に悩ましいのですが、マイクロソフトは「自分が標準だ！」というスタンスで、他には殆ど誰も使っていなかった「shift_JIS」を基本の文字コードとして使い続けていました。
しかし、さすがのマイクロソフトもそういう態度はとりづらくなったのか、ついにWindows8においては基本の文字コードを「UTF8」に変更したようです。基本的にはそれは喜ばしいことだとは思うのですが、局地的には色々と困ったことが起こっています。私の場合、その「困ったこと」というのはMP3データベースの文字コードです。

一般的にタグ編集ソフトの文字コードはOSに依存しています。ですから、長くXPで編集を続けてきた私の場合は、MP3ファイルのタグ情報の文字コードはすべて「shift_JIS」で書き込まれています。ですから、データベース（mySQL）も「UTF8」が標準になる中で、涙ぐましい努力で「shift_JIS」に対応させてきました。
それがここへきての「UTF8」への変更です。

タグ編集ソフトの文字コードはOS依存ですから、Windows8では「UTF8」で書き込まれます。この状態でサーバーにアップしてデータベースに読み込ませるとものの見事に「文字化け」を起こします。それなら、無駄な努力はやめてデータベースを標準の「UTF8」に戻せばいいのにと思われるかもしれませんが、すでに2000を超える録音が「shift_JIS」で格納されています。この状態でデータベース（mySQL）の文字コードを「UTF8」に変更すればその2000を超えるファイルのタグ情報が文字化けを起こしてしまいます。
かといって、すでに書き込んであるMP3の文字コードを変更して、再度データベースに読み込ませるというのは考えただけでもうんざりするような作業になります。

結局は、マイクロソフトの独善的な態度で二つの文字コードが混在してしまったのが原因です。
そして、この問題を解決するもっとも簡単な方法は、マルチバイト文字を使わないことです。

つまりは、タグ編集には日本語は使わずに、すべてアルファベット表記で行えば、「UTF8」で書き込まれたタグ情報を「shift_JIS」で読み込んでも文字化けは起こりません。
一昔前の輸入盤の売り場なんてのは日本語のポップなんてのは何もなくて、ひたすら英語表記の背を眺めてCDを選んだものです。そういう経験のある方ならばそれほど不自由は感じないと思います。

管理人のいらぬ手間を省くための策ということで、ご理解いただければ嬉しいです。