「iTunes の通信をシミュレートしてみる」の巻
単なる好奇心からであるが任意の画像を iTunes のアートワークに適用させる環境を構築してみた。そこに至るまでの経緯を備忘録代わりに記しておこうと思う。
1) はじめに
iTunes はトラックにアートワークが埋め込まれていない場合、アップルのサーバからアートワークを自動的にダウンロードする機能を持っている。ダウンロードされたアートワークは Artwork という専用のフォルダに置かれ iTunes により管理される(関連記事)。このアートワークがトラック(MP3 ファイル)に直接埋め込まれることはない。アートワークの埋め込みは非対応のプレーヤーやタグ編集ツールなどで問題を引き起こす危険性が高く、個人的には敬遠している。しかし iTunes や iPod であれば、埋め込み無しにプレーヤー上でアートワークを表示することが可能である。欠点はアップルのサーバにアートワークが存在するアルバムに限られるということ。手作業で登録したアートワークはやはりトラックに埋め込まれてしまう。
2) 動機
ひと言でいえば「アップルのサーバに存在しないアートワークをトラックに埋め込むことなく登録することは可能か?」ということ。必要に迫られたわけではなく、単に iTunes の技術的側面に関する好奇心である(笑)。
3) 下準備
iTunes はサーバとの通信に HTTP を利用している。HTTP の通信ログを調べるにはローカルプロキシを経由させる方法が手っ取り早い。ちょっと古いツールだが長年愛用の Proxomitron に活躍してもらうことにする。また今回は通信の監視だけでなく、HTTP のテストツールも必要となるだろう。さすがに telnet では解析の効率が悪すぎると専用のツールを探してみたのだが、イマイチしっくりくるものに出会えなかった。結局ツールは自作することにした。今後のことを考えれば、そのほうが得策だろうという判断である。とはいえツールの開発にばかり気を取られ iTunes の調査が先送りになるという本末転倒な状況は避けたいところ(笑)。
4) 調査開始
アートワークのダウンロードには iTunes ストアへのログインが必須であるから、まずは適当なアカウントでログインを済ませておく(著者は英語版の iTunes で日本語のストアにログイン)。次にアートワークを取得したいトラックを右クリックして "Get Album Artwork" を実行する(今回は Boston の "Third Stage" アルバムに収録されている "Amanda" で試した)。すると iTunes はサーバと以下のような通信を行う(ログは Proxomitron から、またマシンの固有情報と思われる部分は ***** でマスクしてある)。
注)すでにアートワークが設定されているトラックではリクエストを発行しない。iTunes が適用したアートワークであれば "Clear Downloaded Artwork" でクリアすることができる。ただし一つでもアートワークが適用されるトラックが残っているとクリアされないため、この作業はアルバム単位でまとめて行う必要がある。ちなみに iTunes 上でアートワークがクリアされるとダウンロードされたアートワーク自体も Artwork フォルダから削除される。
[リクエスト メッセージ]
[レスポンス メッセージ]
上記ログより iTunes はトラックのタグ情報を読み込み、アーティスト名とアルバム名を検索クエリとしてサーバに問い合わせていることがわかる。レスポンスは XML データを受け取っているが通信ログだけではその内容まではわからない。GET メソッドによるリクエストであることから下記の URL をそのままブラウザに渡してみたが異なるページに飛ばされるだけだった。サーバは明らかにリクエストヘッダを見て処理を振り分けている。
そこで出番となるのが自作の HTTP テストツール(笑)。ブラウザでは基本的にリクエストヘッダを変更することはできないが、Ship-a-tie では自由にこれを設定して iTunes のリクエストをシミュレートすることができる(ツールの紹介およびダウンロードは下記の記事を参照のこと)。
http://blog.goo.ne.jp/ghostwind/e/87b0af815fb2a7bc7ec9b6e4a781021f
ではウォーミングアップがてら早速テストしてみる。さきほどのリクエストメッセージを丸ごとコピーして [Import] ボタンを押すと自動的にメッセージが取り込まれる。一部文字がマスクされたままだが今は気にしない(笑)。あとは [Send] ボタンを押すだけ。
![](https://blogimg.goo.ne.jp/user_image/3b/2e/2f31c5315c515c2a771a5d563e6b33b3.png)
何らかのレスポンス が返ってくれば通信に成功している。しかしおそらくは Response Text には文字化けしたようなデータが表示されるだろう。
![](https://blogimg.goo.ne.jp/user_image/34/d0/811176fabef1db1ccf8dfe13c42efc99.png)
実はこれ、文字コードが合っていないのではなく、リクエストヘッダに Accept-Encoding: gzip が含まれているため。簡単にいうと「データを gzip で圧縮して送ってくれ」という要求をしているのである。レスポンスヘッダに Content-Encoding: gzip があることから受け取ったデータはご丁寧に gzip で圧縮されていることになる。もちろんこのデータをアーカイバなどで解凍すれば本来のデータは取り出せるが、そんなことをするまでもなくリクエストヘッダから Accept-Encoding: gzip を削除すればこれは解決する。つまりは「生のままの XML データを送ってくれ」と要求するわけである。もう一度 [Send] ボタンを押してみよう。今度は首尾よく XML データが表示されたことと思う。
![](https://blogimg.goo.ne.jp/user_image/01/6d/35d6a431d6278c5453a2c21d68637242.png)
ちなみにこのリクエストは最低限以下に挙げる二つのヘッダがあれば正常に受理される。Cookie をはじめ、その他のゴテゴテしたリクエストヘッダは特に必要ないということである。
[本章のまとめ]
アップルのサーバにアクセスしてアートワークを検索するには User-Agent と X-Apple-Store-Front ヘッダに適切な値をセットしなければならないが、事前ログインは特に必要ない。
単なる好奇心からであるが任意の画像を iTunes のアートワークに適用させる環境を構築してみた。そこに至るまでの経緯を備忘録代わりに記しておこうと思う。
1) はじめに
iTunes はトラックにアートワークが埋め込まれていない場合、アップルのサーバからアートワークを自動的にダウンロードする機能を持っている。ダウンロードされたアートワークは Artwork という専用のフォルダに置かれ iTunes により管理される(関連記事)。このアートワークがトラック(MP3 ファイル)に直接埋め込まれることはない。アートワークの埋め込みは非対応のプレーヤーやタグ編集ツールなどで問題を引き起こす危険性が高く、個人的には敬遠している。しかし iTunes や iPod であれば、埋め込み無しにプレーヤー上でアートワークを表示することが可能である。欠点はアップルのサーバにアートワークが存在するアルバムに限られるということ。手作業で登録したアートワークはやはりトラックに埋め込まれてしまう。
2) 動機
ひと言でいえば「アップルのサーバに存在しないアートワークをトラックに埋め込むことなく登録することは可能か?」ということ。必要に迫られたわけではなく、単に iTunes の技術的側面に関する好奇心である(笑)。
3) 下準備
iTunes はサーバとの通信に HTTP を利用している。HTTP の通信ログを調べるにはローカルプロキシを経由させる方法が手っ取り早い。ちょっと古いツールだが長年愛用の Proxomitron に活躍してもらうことにする。また今回は通信の監視だけでなく、HTTP のテストツールも必要となるだろう。さすがに telnet では解析の効率が悪すぎると専用のツールを探してみたのだが、イマイチしっくりくるものに出会えなかった。結局ツールは自作することにした。今後のことを考えれば、そのほうが得策だろうという判断である。とはいえツールの開発にばかり気を取られ iTunes の調査が先送りになるという本末転倒な状況は避けたいところ(笑)。
4) 調査開始
アートワークのダウンロードには iTunes ストアへのログインが必須であるから、まずは適当なアカウントでログインを済ませておく(著者は英語版の iTunes で日本語のストアにログイン)。次にアートワークを取得したいトラックを右クリックして "Get Album Artwork" を実行する(今回は Boston の "Third Stage" アルバムに収録されている "Amanda" で試した)。すると iTunes はサーバと以下のような通信を行う(ログは Proxomitron から、またマシンの固有情報と思われる部分は ***** でマスクしてある)。
注)すでにアートワークが設定されているトラックではリクエストを発行しない。iTunes が適用したアートワークであれば "Clear Downloaded Artwork" でクリアすることができる。ただし一つでもアートワークが適用されるトラックが残っているとクリアされないため、この作業はアルバム単位でまとめて行う必要がある。ちなみに iTunes 上でアートワークがクリアされるとダウンロードされたアートワーク自体も Artwork フォルダから削除される。
[リクエスト メッセージ]
GET /WebObjects/MZStoreServices.woa/wa/coverArtMatch?an=Boston&pn=Third%20Stage HTTP/1.1 Accept-Language: en-us, en;q=0.50 X-Apple-Tz: 0 Cookie: ***** X-Dsid: 152476744 User-Agent: iTunes/8.1.1 (*****) X-Apple-Validation: ***** Accept-Encoding: gzip X-Apple-Store-Front: 143462-1 Host: ax.itunes.apple.com Connection: keep-alive
[レスポンス メッセージ]
HTTP/1.1 200 OK Content-Encoding: gzip x-apple-application-site: CUP Content-Type: text/xml; charset=UTF-8 x-apple-asset-version: 58920 x-apple-max-age: 3600 x-apple-request-store-front: 143462-1 x-apple-date-generated: Sun, 03 May 2009 01:57:40 GMT x-apple-application-instance: 265 x-webobjects-loadaverage: 0 Content-Length: 461 X-NS-label: mzstoreservice-lb Vary: Accept-Encoding Expires: Sun, 03 May 2009 01:57:40 GMT Cache-Control: max-age=0, no-cache Pragma: no-cache Date: Sun, 03 May 2009 01:57:40 GMT Connection: keep-alive X-Apple-Partner: origin.0
上記ログより iTunes はトラックのタグ情報を読み込み、アーティスト名とアルバム名を検索クエリとしてサーバに問い合わせていることがわかる。レスポンスは XML データを受け取っているが通信ログだけではその内容まではわからない。GET メソッドによるリクエストであることから下記の URL をそのままブラウザに渡してみたが異なるページに飛ばされるだけだった。サーバは明らかにリクエストヘッダを見て処理を振り分けている。
http://ax.itunes.apple.com/WebObjects/MZStoreServices.woa/wa/coverArtMatch?an=Boston&pn=Third%20Stage
そこで出番となるのが自作の HTTP テストツール(笑)。ブラウザでは基本的にリクエストヘッダを変更することはできないが、Ship-a-tie では自由にこれを設定して iTunes のリクエストをシミュレートすることができる(ツールの紹介およびダウンロードは下記の記事を参照のこと)。
http://blog.goo.ne.jp/ghostwind/e/87b0af815fb2a7bc7ec9b6e4a781021f
ではウォーミングアップがてら早速テストしてみる。さきほどのリクエストメッセージを丸ごとコピーして [Import] ボタンを押すと自動的にメッセージが取り込まれる。一部文字がマスクされたままだが今は気にしない(笑)。あとは [Send] ボタンを押すだけ。
![](https://blogimg.goo.ne.jp/user_image/3b/2e/2f31c5315c515c2a771a5d563e6b33b3.png)
何らかのレスポンス が返ってくれば通信に成功している。しかしおそらくは Response Text には文字化けしたようなデータが表示されるだろう。
![](https://blogimg.goo.ne.jp/user_image/34/d0/811176fabef1db1ccf8dfe13c42efc99.png)
実はこれ、文字コードが合っていないのではなく、リクエストヘッダに Accept-Encoding: gzip が含まれているため。簡単にいうと「データを gzip で圧縮して送ってくれ」という要求をしているのである。レスポンスヘッダに Content-Encoding: gzip があることから受け取ったデータはご丁寧に gzip で圧縮されていることになる。もちろんこのデータをアーカイバなどで解凍すれば本来のデータは取り出せるが、そんなことをするまでもなくリクエストヘッダから Accept-Encoding: gzip を削除すればこれは解決する。つまりは「生のままの XML データを送ってくれ」と要求するわけである。もう一度 [Send] ボタンを押してみよう。今度は首尾よく XML データが表示されたことと思う。
![](https://blogimg.goo.ne.jp/user_image/01/6d/35d6a431d6278c5453a2c21d68637242.png)
ちなみにこのリクエストは最低限以下に挙げる二つのヘッダがあれば正常に受理される。Cookie をはじめ、その他のゴテゴテしたリクエストヘッダは特に必要ないということである。
User-Agent: iTunes X-Apple-Store-Front: 143462-1
[本章のまとめ]
アップルのサーバにアクセスしてアートワークを検索するには User-Agent と X-Apple-Store-Front ヘッダに適切な値をセットしなければならないが、事前ログインは特に必要ない。