コグノスケ

ニコニコ動画ダウンロードスクリプト改良

以前、ニコニコ動画:Qの動画ダウンロードスクリプト（2012年10月25日の日記参照）を載せましたが、奥さんに「Google Chromeで動かない」と突っ込まれました。

試したら確かに動かない。ChromeだとXMLHttpRequestでニコニコ動画のgetflv APIを呼ぶとstatus 0が返ってきます。SeaMonkeyだとstatus 200が返ってきて、動画のURLが取得できているのですが…？

何故Chromeだけ動かないのかわからなくて、しばらくウンウンうなってたのですが、わかってみれば何てことはなかった。単にgetflv APIのURLが間違っていただけでした。

誤「http://www.nicovideo.jp/api/getflv/(movie ID)」
正「http://flapi.nicovideo.jp/api/getflv/(movie ID)」

というわけで、修正。SeaMonkeyとChromeで動作確認しました。

javascript:

function received() {
    if (request.readyState == 4 && request.status == 200) {
        /* received */
        var strurl = decodeURI(request.responseText);
        strurl = new String(strurl.match(/url=[^&]+/));
        strurl = strurl.replace('url=', '');
        strurl = decodeURIComponent(strurl);
        
        var btn_container = document.getElementById('videoHeaderDetail');
        var btn = document.createElement('a');
        
        btn.href = strurl;
        btn.style.fontSize = '2em';
        btn.textContent = '[download]';
        btn_container.appendChild(btn);
    }
}

var docurl = document.URL;
var doccookie = document.cookie;
var flvurl = docurl;
flvurl = flvurl.replace('www.nicovideo.jp/', 'flapi.nicovideo.jp/');
flvurl = flvurl.replace('/watch/', '/api/getflv/');

var request = new XMLHttpRequest();
request.open('GET', flvurl, true);
request.withCredentials = true;
request.setRequestHeader('Cookie', doccookie);
request.onreadystatechange = received;
request.send('');

注意点を一つ書いておきます。SeaMonkeyだと [download] リンクをクリックすると保存するかい？と聞かれます。しかしながらChromeは [download] リンクをクリックすると再生（※）してしまいますので、リンクを右クリックして「リンク先を保存」で保存してください。

最後に一つ心残りがあるとすれば、SeaMonkeyはなんで間違ったURLで正常に動いていたんだろう？ってことですかね。まあ、ご機嫌で動いているから、もうどうでもいいんだけどね。

（※）ChromeはContent-typeがvideo/mp4だと「ダウンロード」じゃなくて「ブラウザ内蔵プレイヤーで再生」してしまうようです。気が利いているというか、余計なお世話というか…。

Javaのリフレクションとコンストラクタ

Javaのリフレクションを使ったコンストラクタの取得で躓いています。正解が分からない…。

あるクラスTestがあり、パラメータにクラスAしか取らないコンストラクタがあるとします。

クラスTestのコンストラクタに対し、クラスAと全く関係ないクラスCのインスタンスを渡せばコンパイルエラーになります。クラスAの派生クラスBのインスタンスであれば渡せます。これはオブジェクト指向言語なら当たり前です。

しかしリフレクションを使ってコンストラクタを得ようとすると、派生クラスを渡せるコンストラクタをどうやって取得すれば良いかわからないのです。

public class Test {
    public Test(A a) {
    }
}

public class A {
    public A() {
    }
}

public class B extends A {
    public B() {
    }
}

public class Main {
    public static void main() {
        Test obj1 = new Test(new A()); //OK
        Test obj2 = new Test(new B()); //OK

        Constructor<Test> cons1 = Test.class.getConstructor(A.class); //OK
        Constructor<Test> cons2 = Test.class.getConstructor(B.class); //NG

        Test obj3 = cons1.newInstance(new A()); //OK
        Test obj4 = cons1.newInstance(new B()); //OK

        //Test obj5 = cons2.newInstance(new B());
    }
}

上記のようなコードがあったとします（try〜catchは省いています）。

クラスTestには、クラスAをパラメータにとるコンストラクタしかありません。従って、派生クラスBをパラメータに取るコンストラクタをくれ（＝Test.class.getConstructor(B.class)）と頼むと「そんなコンストラクタは無い」と例外がスローされます。

どうしてTest.class.getConstructor(B.class) としたとき、「ありません」なんだろうか？基底クラスを取るコンストラクタ（Test(A a)）があるのだから、そちらを教えてくれれば良いのに…。

鶏と卵

クラスTestには、クラスBを取るコンストラクタはないから、この動きは正しい。
とか、
基底クラスAを取るコンストラクタ（cons1）を得て、派生クラスBのインスタンスを渡せば良いだけだ。（つまりobj4を生成しているように書く）
という反論はわかるのですが、それだとせっかくのリフレクションなのに本末転倒になってしまいませんか？

クラスTestの利用者側の立場からすれば、クラスTestに、クラスAを取るコンストラクタがあるか？クラスBを取るコンストラクタがあるか？なんて知らないわけです。自分が呼び出したいコンストラクタが既にあるとわかっているなら、リフレクションなど使わずに直接呼べば良いのです…。

クラスTestのコンストラクタを全部取得して、クラスBの基底クラスを取るコンストラクタがないかどうか、全て探すしかないのでしょうか…。うーん、それはさすがに格好悪いような…。

車の修理が終わった

先日レガシィを運び込んだ（2013年3月25日の日記参照）ディーラーから電話があり「バッテリーが完全に死んだのが原因」とのこと。説明を聞いていたのですが、どうも向こうの言う原因と今回の現象が繋がりません。

エラーが初めて出た日（水曜日）にはバッテリーは生きていたよ？
牽引前にJAFの方がブースター繋いだけどかからなかったよ？
バッテリーが完全に死んだのは牽引の直前だよ？
前にバッテリー上がったときは出なかったよ？
Er HCの意味は？なぜバッテリーが原因なの？
というようなことを聞き返したら「折り返し電話する」とのこと。なんだそりゃ…？

しばらくして2回目の電話。観念して（？）整備マニュアルを見つつ説明してくれたようで、やたら詳しかったです。ひとまず結論だけ一言でいえば「統合ユニットの誤報」でした。

と言われてもわかんないですね。覚えている限りですが、説明の要点は次の通り。

• 電圧降下のエラーが統合ユニット（エンジン制御のコンピュータ）に記録が残っていた。
  →もともとバッテリーがかなり弱っていたと考えられる。
• バッテリーがかなり弱っていると、ブースターを繋いでもかからないことがある。
  →聞き流しちゃったけど、これ本当なのかな？
• バッテリーを交換したところ、エンジンがかかった。
  →機械類に故障はないと考えられる。
• Er HCは高速CAN通信エラー、つまりエンジン周りのセンサーなどとの通信エラー。
  センサーに異常があれば、バッテリー交換後もEr HCエラーが出る。
  だが、バッテリー交換後センサーのエラーは出ていないし、統合ユニットにも記録が残っていない。
  →センサー類に故障はないと考えられる。

以上から所見としては「バッテリーの電圧が一時的に下がったか何かで、統合ユニットのメモリにエラーが生じ、Er HCエラーが出た。しかしバッテリー交換によりエラーが消えたところを見るに、エンジンや統合ユニットに異常はないと考えられる。」とのことらしいです。

修理代的な観点だとエンジン周りは壊れていないから、交換不要。バッテリーは死んでいたから、交換した。ってことです。

悪意はないのだろう

もう！最初からそうやって説明してくれれば良いのに！！って思った。でも後で良く考えたら、車に興味のない人に統合ユニットだ、CANだ説明したところで「はぁ？何それ？で、修理代いくらなの？」って言われるのが関の山だろうなあ。

一生懸命説明しても虚しいから、いつも端折って説明してきたのに、今回だけは（私が）やたら食いついてきたもんだから、観念して整備マニュアル引っ張ってきた、ってところでしょうか。単なる推測に過ぎませんが…。