ハイドン、交響曲１００番「軍隊」、１０１番「時計」、５９番「火事」をリッピングしようとして Window Media Player を起動してＣＤを入れたんですが、表示されたアルバムタイトルは「Christmas with ... Kiri Te Kanawa Classical 1990」
曲目は 「White Christmas」「Have yourself a merry little Christmas」など。思わずＣＤを取り出して確認してしまいました。
挿入したＣＤはマリナー／アカデミーのハイドンの交響曲なんですけど・・・
まぁ、Windows Media Player が表示するタイトル、曲名はかなりいいかげんで、シャルル・ミュンシュがダニエル・バレンボイムに化けたり、３楽章しかない曲に「第４楽章」が表示されたり。
結局、トラック番号以外はあまり信用できない、という事ですね。
それにしても、これ、ちょっとひどくない？
音源サポートのテストをしていたら、突然、動かなくなってしまいました。
さっきまで動いていたのに。というより、再生しながら作業していたのですが・・・
渡辺貞夫「In Tempo」をリッピングしてセットアップして、再生しようとしたら
「エラーが起こりました。・・・・・」が表示され、全く再生できません。このエラーメッセージは私が書いたプログラムが出しているので、何が起こったのかは分かるのですが、「何故それが起こったか」は全く分からない。で、いろいろ調べ始めたのですが分からん。
あれやこれや調べているいるうちに、何故か復旧してしまいました。何が起こったんだろう？？？
バックグラウンドで実行される「Windows Update」が原因かなぁ・・という気がしなくもない。不具合が起こった時間帯に Windows Update が行われていたらしいから。それにしても、訳が分からん。困ったもんだ。
いやぁ～、久しぶりにハマりました。使っているデータベースは MySQL なんですが
スキーマを変更（alter）しようかとも思ったんですけど、動く状態のデータベースを壊すとまずいので、
utf8 で新しいスキーマを作り、バックアップを流し込みました。
・キーにしている文字列項目が長すぎる・・・にひっかりました。utf8 にすると１文字あたりのバイト数が増えるので・・・
・次に、キー全体の長さが長すぎる
文字列項目の長さを調節して何とかしました。
とりあえず「文字化け御免」という事で「Tchaikovsky. Sinfonía nº 5 en Mi m, Op. 64」を入れてみました
ちゃんとＤＢに書き込めたし表示もＯＫ。
テストに必要な最小限の「補助文字対策」をやって補助文字を入れてみると、ＤＢへの書込み時に「不正な文字」となってしまいました。
調べてみると「MySQL の utf8 は補助文字はサポートしない。補助文字を使うならば utf8mb4 を使え」だと。
で、ＤＢを作りなおすと、また「キーが長すぎる」
MySQL の utf8 は１文字あたり最大３バイト、utf8mb4 は最大４バイト。ちなみに、cp932 は１文字あたり２バイト。
また文字列項目の長さを調整してデータを入れなおしました。
さて、補助文字の入出力のテストなんですが、ここからハマりました。「不正な文字」になってしまうのです。
MySQL の文字コードは結構複雑で、クライアントの文字セット、接続の文字セット、サーバーの文字セット、結果の文字セットなどがあります。
これらが utf8mb4 を扱えなくてはならないのですが、一部の文字セットが utf8 のまま。utf8mb4 になってくれません。
MySQL の構成ファイルや、JDBC のパラメータをどう変更しても utf8 のまま。困ったねぇ。
仕方がない。プログラムでセットするか。という事で、【自分で作った】データベース接続クラスのソースを開けてみました。
そうしたら、なんと、自分で utf8 にセットしていたのです。これ、ＤＢの構成、JDBC の起動後なんで、構成ファイルや起動パラメータを変更しても「手応えなし」なのは当然でした。・・・そういえば・・・
何年か前に、MySQL がややこしい文字コードを扱うように変更された時、
・データベースは CP932
・Java はユニコード
なので、ＤＢ接続クラスに utf8 にセットする部分を追加したのを思い出しました。
ったく、しょ～もない。でも、ハマるのって、たいてい原因は「しょ～もない」事なんですよね。
以上、３日かかりました。疲れた。
現状は「限定された条件」付きですが、補助文字をＤＢに格納する、読み出して表示する、が出来るようになりました。
明日から、まだ手を付けていない部分のプログラムを修正する予定です。
テストを兼ねてＣＤをリッピングしてテスト環境に音源を設定していたところ、思いがけない問題に行き当たりました。まぁ、問題に行き当たるのは「常に予想外」なんですが・・・。
チャイコフスキーの交響曲第５番のファイル名で問題が起こりました。
Windows Media Player が作ったファイル名の一部（フォルダ名）に
「Tchaikovsky. Sinfonía nº 5 en Mi m, Op. 64」という文字列があったのです。
これの何が問題かというと、
・現システムは CP932 という文字コードで動いています。
・「Tchaikovsky. Sinfonía nº 5 en Mi m, Op. 64」には、CP932 には定義されていない文字が使われています。
なので、現システムでは、この名前の音源ファイルを扱う事ができません。具体的には「音源ファイルが見つからない」というエラーになってしまいます。
回避するのは簡単で、CP932 にない文字を CP932 にある文字に置き換える、削除するなどでＯＫなんですが、どの文字が CP932 にない文字なのかを見つけるのは大変です。
結局、疑わしい文字を片っ端から置き換えてやってみる事になるのですが、面倒。
Windows の文字セットは CP932 だったのですが、Vista の頃から unicode にも対応していたと思います。
でも、実際のファイル名などで unicode に出くわした事がなかったので、忘れていたんです。
CP932 をやめて UTF8 にすればいいんですけど、これ、面倒な作業になってしまいそうです。
どれほど大変かは調べなくては分かりませんが・・・
----------------------------------------------------------------------------------
以下、テクニカルです。
このシステムは Java で記述していますが、・・・
Java では文字は Unicode で表現されます。Java が Unicode を採用した当初は「１文字は１６ビット」だったのですが、その後 Unicode が拡張されて１６ビットでは表現できない文字（補助文字）が定義されているのです。
一方、Java で１文字を表す変数型 char はいまだに１６ビットのまま。３２ビットにしてくれれば良いのだけど、３２ビットにすると互換性の問題が起こるんだそうです。そりゃぁそうだ。１６ビットだと思って動いているＪＶＭもあるだろうし、そういうのに３２ビットデータを渡すとまずいよねぇ。
String などでは UTF16 が使われています。１６ビットよりも大きな文字コードは２つに分割して（２文字分の領域を使って）表現されます。
これをサロゲートペアと言います。
このシステムでは出力が HTML なので、HTML で予約された文字はエスケープしなくてはなりません。
また、データベースに書き込む場面でもエスケープが必要です。エスケープするには、「１文字単位での処理」が必要なんですが、
現プログラムではエスケープ不要な文字は直接 Writer に渡して出力しているのです。ところが
javax.servlet.jsp.JspWriter.write(char) はサロゲートペアの片方は受け付けないのです。
char[] か String で出力するしかなさそうです。
という事は、エスケープ不要な文字を出力する場合は「サロゲートペアかどうか」を判断して・・・が必要になるんです。
となると、いきなり出力ではなく StringBuffer か何かに入れておくか・・・。
現プログラムではサロゲートペアが混ざると文字が化けまくるはずです。
サロゲートペアを扱う事自体は難しくはないのですが、面倒。
問題が起こる可能性がある所を洗い出して修正しなくてはならないのですが、かなりの個所を修正する必要がありそうです。
下手すると１週間くらいはかかりそうです。やれやれ。暫くの間は化け文字とお付き合いになりそうです。
ずいぶん久しぶりに書き込みます。前回の投稿から何をやっていたのかというと、
ＣＤ管理システムの「第２版の構想を練る～テストプログラムを作る」のをやっていました。
やっているうちに、リッピングした音源ファイルを検索結果と関連づけて、ブラウザで再生できるようにするのを思いつきました。
第２版の構想を練るのは一時中断して、再生するためのプログラムを作っていました。
こういうのを作るのはブログを書くより面白い・・・で、サボっていました。（ごめんなさい）
（注）リッピング
ＣＤなどにある音楽等をＰＣに取り込むこと。ＣＤ上の音楽などは「ファイル」ではないので、単純なコピーではなくファイルへの変換が必要です。このため、「コピー」ではなく「リッピング」と言います。
リッピングした音源ファイルの再生は、テスト版が動作するようになった所で、これから本格的にテストの予定です。
順調ならば、リリースまでそれほど長い時間はかからないと思います。
で、どのような機能かというと、
・演奏編集画面でリッピングした音源ファイルのＵＲＬを入力する。
・検索結果表示画面、詳細表示画面などで再生する。
というものです。
アルバム検索結果（アルバム一覧），アルバム詳細、演奏検索結果（演奏一覧）、演奏詳細で再生する事ができます。
また、演奏編集では設定したＵＲＬが正しい事を確認するために再生する事ができます。
・曲または楽章を指定して再生する、曲に楽章がある場合は全楽章を連続して再生する。
・アルバム全体を連続して再生する。
・２枚組以上のアルバムの場合は、その全体を連続して再生する。
が可能です。
さて、音源は著作物なので、著作権法に違反しないようにしなくてはなりません。
いろいろ検討した結果「音源ファイルはサーバーには置かずローカルＰＣ（各ユーザーのＰＣ）に置く。」
という制限を設けました。つまり、【音楽配信はしない】という事です。
ところで、サーバーで作成したＷｅｂページからは、ローカルＰＣにあるファイルはアクセスできないのです。
これができてしまうと、悪意のあるＷｅｂページがＰＣ上のファイルを読み込んで、
それをサーバーに送信する事ができてしまいます。これを防止するために、そのようなアクセスは禁止されているのです。
ローカルＰＣにある音源ファイルを再生するには、ローカルＰＣでＷｅｂサーバーが動作していて、
Ｗｅｂサーバー配下のフォルダに音源ファイルがなくてはなりません。
幸いなことに、 Windows では標準でＷｅｂサーバーが用意されているので、これを使えば簡単に動かす事ができます。
「インターネット・インフォメーション・サービス」がそれで、
「コントロールパネル～プログラムと機能～Windows 機能の有効化または無効化」で
「インターネット・インフォメーション・サービス」を有効にするだけです。（デフォルトでは無効になっています）
インターネット・インフォメーション・サービスは c:\inetpub 以下のファイルを扱います。
c:\inetpub\wwwroot 以下に（適当なフォルダを作って）音源ファイルを置けばＯＫです。
マッキントッシュにも同様の機能があるようですが、私、マッキントッシュは素人なので説明を書く事ができません。
インターネット上に情報があるので、それを参考にして下さい。いくつかのページを読んだところでは、結構面倒なようです。
説明文に「・・・次のようにタイプします。 sudo ・・・」とかがありました。
sudo って、ＵＮＩＸ／ＬＩＮＵＸのコマンドじゃないの。普通のＰＣユーザーにはハードルが高いかも知れませんね。
最初はローカルＰＣ（localhost）だけを扱うようにしたのですが、ＬＡＮ上の他のマシンからも再生できると嬉しいので、
ローカルＰＣまたはＬＡＮ上のマシンにある音源を再生できるようにしました。インターネット上にある音源の再生はできません。
ここまで出来たら動画も・・・と思うわけです。オペラのＤＶＤをリッピングして・・・
でも、これは出来ないのです。技術的にではなく法律的にできないのです。
どういう事かというと、「不正コピー防止」を外して（回避して）コピーしてはならないと決まっているからです。
コピー防止を無効にするようなソフトもありますが、リッピングした時点でアウトです。
罰則はないようですが、不正を助長するような機能を作るつもりはないので、動画はサポートしません。
というところで、今日はここまでにします。