So-net無料ブログ作成
検索選択
RSS [RSS1.0] [RSS2.0]

MOZ_NO_REMOTE を削除してThunderbirdからFirefoxを起動するソフトを作り直した

 コマンドラインオプション -no-remote を使用してThunderbirdを起動するとFirefoxを起動しようとした時に次のような警告が表示されることがある。

Firefoxは起動していますが応答しません。新しいウィンドウを開くには既存のFirefoxプロセスを終了させなければなりません。(クリックで拡大)

 2014/2/19頃に試行錯誤(参照)を始めたのだが、どうやら次の2ケースにまとめられそうである。

  1. デフォルトのプロファイルでFirefoxを起動して、そのFirefoxが起動中の場合、-no-remote というコマンドラインオプションを付けて起動したThunderbirdからはFirefoxを起動できない。
  2. Thunderbirdを -no-remote というコマンドラインオプションを付けて起動し、そのThunderbirdからFirefoxを起動して、そのFirefoxが起動中の場合、ThunderbirdからもThunderbird以外からでも、デフォルトのプロファイルでFirefoxを起動できない。

 かなり前から指摘されているバグ、あるいは仕様らしく、対策もネット(参照)にあった。環境変数「MOZ_NO_REMOTE」を unset すれば良いらしく、「MOZ_NO_REMOTE」の値はbatファイルで変えることができるらしい(参照)。試しに、次のようなbatファイルを作って、フリーウェアの【Batch To Exe Converter】を使ってexeファイルに変換して、-no-remote を使用して起動したThunderbirdのリンクをクリックしたら、既にデフォルトのプロファイルでFirefoxが起動していても、警告が出ることなくFirefoxが起動した。

@echo off
Set MOZ_NO_REMOTE=
start "" "firefox.exe" "%1"
exit

 デフォルトのブラウザはFirefoxにしてある。また、Thunderbirdからデフォルトのブラウザ以外のソフトを起動する方法は検索して見つけた【ThunderBirdに任意のブラウザを関連付ける:G'sのだらだらぐーたら日記 on blog】で紹介されていたので参考にした。残念ながらThunderbirdのリンクをクリックしてbatファイルを起動することはできないようである。選択できるのは拡張子が .exe か .com のソフトだけである。

 これで問題が解決したかと思ったが、「=」や「&」のあるURLをクリックした時に正常にリンクが開かない問題が生じた(参照)。これはThunderbirdがURLを外部ソフトに引数として渡す時にダブルクォート""で囲んでくれず、さらに、【Batch To Exe Converter】で変換したexeファイルは引数を囲んでいたダブルクォート""を消して処理することも分かった(参照)。
 この引数問題を解決する方法をネット検索で探していたら、JScriptWScript.Argumentsを見つけたので、JScript を使って引数をダブルクォート""で囲んでからbatファイルに渡すことにした(参照)。Thunderbirdから起動するためにJScriptのファイルをexeファイルに変換する必要があるが、まずは【MakeExe】を使った。翌日からは複数のファイルをまとめてexeファイルに変換できる【nandemoExe】を使って変換して、exeファイルの内部でbatファイルを実行(実際の動作は一時フォルダにコピーしたbatファイルを起動?)するようにした。

 この自作ソフトを2年半の間、ほとんど問題なく利用していたのだが、JScriptで環境変数「MOZ_NO_REMOTE」を削除できる可能性を、【BATファイルとEXEファイルとで引数の扱いが異なる件】のコメント欄で指摘された(コメント)。実は環境変数「MOZ_NO_REMOTE」をbatファイルで削除するヒントになったページ【Chicagrafo: MOZ_NO_REMOTE】にはJScriptのスクリプトも記載されていて、そのスクリプトを参考にしてexeファイルを作成してみたのだが、Thunderbirdから起動した時に冒頭の警告が表示された(2014/3/15の私のツイート2014/3/16の私のツイート)。それで諦めていたのだが、コメントで紹介されたリンク先のVBSのスクリプトを参考にしてJScriptのスクリプトを作って【MakeExe】でexeファイルに変換してみたら、問題なくThunderbirdから起動できた。すなわち、batファイルが不要になった。そのスクリプトは次の通り。

var shell = new ActiveXObject("WScript.Shell");
var openFx = "Firefox.exe";
// var openFx = "Firefox.exe -new-window"; // 新しいウインドウで開く
// var openFx = "Firefox.exe -new-tab"; // 新しいタブで開く
// var openFx = "\"C:\\Program Files (x86)\\Mozilla Firefox\\firefox.exe\""; // Firefox.exeのフルパス
var geturl = WScript.Arguments;
if (geturl.length < 1) {var openurl = ""} else {
var openurl = geturl(0);
openurl = "\"" + openurl + "\"";
}
// shell.Popup(openurl); // 引数を確認する

var WshShell = WScript.CreateObject("WScript.Shell");
var WshSysEnv = WshShell.Environment("Process");
WshSysEnv.Remove("MOZ_NO_REMOTE");

var command = openFx + " " + openurl;
// shell.Popup(command); // 実行されるコマンドを確認する
shell.run(command);

 コメントで紹介された【[環境変数を削除する]】とマイクロソフトの記事【Environment プロパティ】を参考にした。

 今回作り直した「MOZ_NO_REMOTEを削除してThunderbirdからFirefoxを起動するソフト」は次のリンク先にアップロードしてある。

 最後に、今回作成したソフトFxfromTB.exeの使い方を書いておく。

  1. FxfromTB.exefirefox.exe と同じフォルダに入れる。
  2. ThnuderBirdを起動して、オプションの詳細ウインドウから[設定エディタ]を開いて network.protocol-handler.warn-external.http を検索する。
  3. network.protocol-handler.warn-external.httpnetwork.protocol-handler.warn-external.httpsTrue に変更する。
  4. メール内の http や https で始まるリンクをクリックする。
  5. [プログラムを起動]ウインドウが開くので[選択]をクリックする。
    [プログラムを起動]ウインドウ(選択前)
  6. 開いたウインドウでFirefoxのフォルダ(firefox.exe のあるフォルダ)を開いて、FxfromTB.exe を選択して[開く]をクリックして、[プログラムを起動]ウインドウに戻る。
    [プログラムを起動]ウインドウ(選択後)
  7. [今後http リンクは同様に処理する(R)]にチェックして[OK]をクリックする。
  8. 起動したFirefoxで表示されたページがクリックしたリンク先であることを確認する。
  9. 念のため、オプションの[添付ファイル]のウインドウで、「ファイルの種類」がhttp や https の所の「動作設定」が「FxfromTB.exe で開く」になっていることを確認する。
    オプションの[添付ファイル]
    (クリックで拡大)
  10. 次回からはThunderbirdのリンクをクリックした時に冒頭の警告が出ることなくすぐにFirefoxが開く。

 さて、Thunderbirdのリンクをクリックした時に「Firefoxは起動していますが応答しません。新しいウィンドウを開くには既存のFirefoxプロセスを終了させなければなりません。」という警告が出る問題に取り組んでから、警告が出ないようにするソフトを作って、作り直すまでを振り返った。同じ問題で困っている人がどの程度いるのか分からないが、参考になれば幸いである。

これまでの関連記事:


nice!(0)  コメント(0)  トラックバック(0) 
カテゴリー:サイトを見て

絵文字のせいでソネブロのツイートまとめ投稿が正しく機能しない

 私のブログ(正己 (self7777) from Twitter)では、ソネブロの「ツイートまとめ投稿」を利用して一時的に自動投稿しているのだが、偶然にバグを発見した。「ツイートまとめ投稿」は「Twitterでつぶやいた1日分のツイートを、まとめてブログに投稿する機能」で「指定の時刻に自動で投稿される」仕組みである。【正己 (self7777) from Twitter】では0:00に前日の0:00から24:00までのツイートを取得して昇順に表示しているのだが、2016/8/21の0:00に取得した8/20のツイート(Twilogソネブロ)が途中までしか表示されてなかった。

8/20のツイートのTwilogとソネブロの比較(クリックで拡大)

 以前はツイッターの調子が悪くて途中までしか取得できなかったのかと思っていたのだが、どうやら2014年の4月からツイートに表示できるようになった絵文字(Twitterサポートさんのツイート)が原因らしく、8/17のツイート(Twilogソネブロ)でも絵文字が最初に登場した所から下が切れていた。
 【正己 (self7777) from Twitter】では一月に一度、自動取得のページを削除して別の表示に置き換えるので、別のブログに削除しないページ(2018/8/22の13:00までののつぶやき(降順))を用意した。このページは8/22の13:00に8/21の13:00からの全ツイートを取得して新しいツイートから順に表示するように設定した。ページを見て分かる通り、3件しか表示されてない。8/21のその時間までのツイート数は11件である(正己(@self7777)/2016年08月22日 - Twilog)。新しいツイートから3件目の途中で切れている。その切れた直後に絵文字がある。

ソネブロが表示した2018/8/22の13:00までののつぶやき(降順)(クリックで拡大)

 ソネブロの「ツイートまとめ投稿」では返信元も表示されて分かりにくいので、Javascriptを切って表示すると次のようになる。

ソネブロが取得した2018/8/22の13:00までののつぶやき(降順)(クリックで拡大)

 比較のために【正己(@self7777)/2016年08月22日 - Twilog】のスクリーンショットも載せておく。

Twilogが取得した2018/8/22の13:00までののつぶやき(降順)(クリックで拡大)

 さて、絵文字は2014/4/3(Twitterサポートさんのツイート)には表示できるようになっていたようだから、ソネブロのまとめ投稿でツイートが欠落している現象は、その頃から生じていたと思われる。ソネブロの【ツイートまとめ投稿が正しく機能しない。:Q&A よくある質問】に載っていないのでスタッフは気付いていないのかもしれない。手動でツイートを引用する場合(Twitter連携:使い方 マニュアル)は大丈夫だった。だから、最近のツイートなら、手動で置き換えることができる。しかし、手動で行う場合は最新の100件が限界である。それ以前のツイートは取得できない。トラブルは2年前から継続している。その間のツイート数は膨大である。回復することはできるのだろうか? ソネブロの【ツイートまとめ投稿】を信頼していた人にとってはショックな不具合かもしれない。ブログに投稿されるたびに確認して修正した用心深い人は大丈夫かもしれないが…。
 それにしても、このバグはGoogleで検索しても見つからなかった。2年以上も生じていたのに気付いた人はいなかったのだろうか?


freemlの承認待ちになったメールで文字化け

 少し前に起こった文字化けメールについてまとめておく。

 文字化けが生じたのは、freemlで「承認待ち」になって承認されたメールをhtml形式で表示した場合である。「添付ファイルがある/またはHTMLメールである」場合は承認が必要になるように運営していると、添付ファイルがなくてもHTML形式のメールが届くたびにメーリングリスト(ML)の管理人が承認する必要がある。文字の一部が文字化けすることは何度もあったが、今回の文字化けは異質で、ユーザーによる対処が難しいので注意していただきたい。

 以前(2011/2/6)に【Thunderbirdが勝手にUTF-8に変えて送信するのに警告を出さない】を書いたのだが、この仕様がfreemlを利用する時に悪影響をもたらしそうである。最近は、Thunderbirdに限らずメールをUTF-8でエンコードするソフトが増えてきたと思うが、freemlを利用する時には注意が必要である。
 私が遭遇した文字化けを避ける方法を先に書いておく。以下のいずれかの方法で避けられると思われる。

  1. HTML形式のメールが承認待ちにならないように運営する。
  2. HTML形式のメールを承認する前に「HTML形式で表示する」をクリックして確認して、文字化けしていたら承認しない
  3. 常にテキスト形式で送信してもらう。
  4. 返信時を含めて必ずISO-2022-JPでエンコードして送信してもらう。
  5. base64やquoted-printableでエンコードして送信してもらう。

 さて、文字化けしたメールのソースは次の通りである。

 上のソースはfreemlで承認待ちになって承認された後に届いたメールであるが、同時に自分宛にも送信していて、そちらは次のようなソースで文字化けしなかった。

 送信にはThunderbird 45.1.1 を利用した。他のメールソフトでは未確認であるが、GmailのWebメールやモバイルを使った送信では「content-type: text/html; charset=UTF-8」の方が「content-transfer-encoding: base64」となって、文字化けしないと思われる。また、Yahoo!メールのWebメールからだと「content-type: text/html; charset=UTF-8」の方が「content-transfer-encoding: quoted-printable」となって、文字化けしないと思われる。Thunderbirdでは、「content-type: text/html; charset=UTF-8」の方が「content-transfer-encoding: 8bit」となっていて、これがfreemlの「承認」を経由した場合に文字化けが生じる条件だと思われる。

 メールのソースを分析した時、私は文字コードの混在が文字化けの原因だと勘違いした。文字化けしたソースとしてないソースを比べると、freemlの承認サーバーを経由したメールは「content-type: text/plain」の方が「charset="iso-2022-jp"」となっていて、「content-type: text/html」の方は「charset=UTF-8」で異なってる。freemlの承認サーバーを経由しなければどちらも「charset=UTF-8」である。それで勘違いしたのだが、文字化けした方のメールの「content-type: text/html」で文字化けしている部分を文字化けしてないメールからコピーして、ファイルをUTF-8で保存してThunderbirdにドラッグ&ドロップして確認したら、文字化けしなかった。HTML形式での表示ではUTF-8で問題なく表示され、テキスト形式ではJISで問題なく表示される。また、文字化けしてないメールの<p> から </p> までを【エンコードマニアックス】を使ってエンコードしても、文字化けしたメールのようにできないし、文字化けしたメールの方の同じ部分をデコードしても元の文字には戻せなかった。そこで、別の原因を推測しなければいけなくなった。

 文字化けした方のメールをよく見ると、</p> が前の文字化けに巻き込まれて /p> となっている。それで、以前(2010/11/18)に書いた【Yahoo!グループでSubjectが文字化けする原因】を思い出した。
 そこでは、次のように結論付けた。

まとめると、『Yahoo!グループでは送信されたメールのSubjectで分割されているJISコードを一度合成してから処理して再度分割するのかもしれないが、再分割の際に「GyRC」や「GyhC」を無視するなどして、分割してはいけない所で分割してしまい文字化けを発生させている。(追記:あるいは再分割せずにメールサーバに送り、76文字を超えていることでメールサーバーが機械的に分割することで不適切な所で分割されてしまって文字化けを発生させている。【参照】)』ということだろう。
Yahoo!グループでSubjectが文字化けする原因

 今回の文字化けはUTF-8で起こっているので、Yahoo!グループのケースとは少し異なる。ただ、「content-type: text/html; charset=UTF-8」の方をいったんbase64でエンコードしてからデコードして元に戻した時に文字化けが生じていそうである。content-transfer-encoding が 8bit ではなく、base64 や quoted-printable の場合はエンコードしてないかもしれないし、エンコード後にデコードしても文字化けしないだろう。
 【Yahoo!グループでSubjectが文字化けする原因】で参考にした【第235章 base64の基礎 】を見ると次のように書いてある。

base64では、次のような方法をとります。
1.エンコードしたい文字列を前から順番に3バイトずつ区切ります。
2.これを今度は前から順に6ビットずつ区切りなおします。
3.この6ビットの値に応じてA-Z, a-z, 0-9, +,/の文字に置き換えます。
第235章 base64の基礎
1.各漢字のJISコードを調べる
2.2進法で表す
3.前から6けたずつ区切る
4.16進(10進でもいいですが)になおす
5.それぞれの数値に対応する記号(A-Z, a-z, +, /)になおす
第235章 base64の基礎

 詳しいことは調べてないが、今回は次のような手順かもしれない。

1.各漢字のUTF-8コードを調べる
2.2進法で表す
3.前から6けたずつ区切る
4.16進(10進でもいいですが)になおす
5.それぞれの数値に対応する記号(A-Z, a-z, +, /)になおす

 【第235章 base64の基礎 】には「JISでは2バイト文字の始まりの合図として(0x1b, 0x24, 0x42) の3バイトを付けなくてはなりません」「2バイト文字の後にはASCII文字が来るので(0x1b, 0x28, 0x42) を付け加えます」とあるが、UTF-8の場合は分からない。ただ、上記のメールの文字化けした<p> から </p> までをまとめてbase64にエンコードした場合と、2バイト文字とASCII文字を分けてからbase64でエンコードした場合は異なるので、デコードする前に何かをすると文字化けするかもしれない。
 【Yahoo!グループでSubjectが文字化けする原因】の時のように手動でエンコードして全く同じ文字化けを再現してみたいが、今は時間と気力が無いので省略する。興味がある人は自分で確認してほしい。

 freemlの承認メールでの文字化けがbase64によるエンコード→デコード処理によるものかどうかは分からない。しかし、文字コードの混在や機種依存文字によるものではないことは確かだろう。freemlの方は改善する余裕が無いかもしれない。だからユーザーの側で気をつけるしかない。対処法は上の方に記載したとおりである。
 Thunderbirdの場合、返信時などに勝手にUTF-8で送信してしまうことがあるが、【Thunderbirdが勝手にUTF-8に変えて送信するのに警告を出さない】に書いたとおり、Thunderbirdのオプションの詳細から「設定エディタ」(about:config)を開いて mailnews.disable_fallback_to_utf8.ISO-2022-JP を「true」に変更すれば防げそうである。実際、今のところ、私が送信したメールで文字化けが生じたという報告は無い。


nice!(0)  コメント(0)  トラックバック(0) 
カテゴリー:サイトを見て

UstreamはHTML5動画ではなかった?

 2016/5/28の午前中にIE11でUstreamの埋め込み動画が表示されないトラブルが発生した。生中継が配信されたことを示すサムネイルは表示されるが、クリックすると真っ黒な画面になるだけだった。配信する側のミスかと思ったのだがFirefoxでは表示されたので、IE11の問題だと判断した。5/27の午前中は問題が無かったので、その間に私が行ったことが怪しい。実際、5/27の午後はMIDIファイルをWAVに変換しようとして様々なフリーウェアを試し、LNSOFTで提供されてる「音楽変換無双」を試した時にJWordとMcAfeeがインストールされてしまった。即座に「音楽変換無双」を削除してJWordとMcAfeeをアンインストールしたのだが、5/28の朝にIE11を開くとホームページが www.fooooo.com に書き換えられそうになった。IE11が警告してくれたのでホームページが書き換えられることは防いだ(参照)が、その前に不明なアドオンがインストールされたらしい。IE11を開いた時に下に「ディスカッション」という初めて見るツールバーのようなものが現れて、「アドオンの管理」を見ると「ディスカッション」というアドオンが有効になっていて、その最終アクセス日が5/28になっていた。このアドオンは無効にしたが、削除はできてない。他には有効になっている怪しいアドオンは無かった。どのプログラムがホームページを書き換えようとしたかは判明してない。
 前置きが長くなったが、IE11でUstreamの埋め込み動画が真っ黒になる問題を解消するためにネット検索をしていたら、HTML5動画になっていたと思っていたUstreamのLIVE映像が実はFlash動画のままだったのではないかという疑問が生じた。その件について記録しておきたい。

 UstreamはIBMに買収されたらしく(参照)、Ustreamの運営がUstream Asiaではなくなった(参照)。その結果、私のツイート(参照)に張った【Ustream「埋め込み再生」機能を全ユーザーに開放 | Ustream News】へのリンクは切れてしまって見ることができない。また、【Ustream Asia / Japan サポートブログ】へのリンクも「USTREAMサポートセンター」にジャンプしてしまって、見ることができない(15:31 - 2015年9月21日のツイート)。ググって、何とか見つけたのがURLの異なる次のページである。

 上記ページのリンク先は表示できないが、上記ページには次のように書いてある。

09/11/15--06:28: HTML5インタフェースを使った新しいUIのプレーヤーをリリース

本日(9/11)にUstreamのHTML5で作られた新しいUIのプレーヤをリリースいたしました。この新しいプレーヤでは、視聴されている方のデバイスに合わせて最適な視聴経験ができるようにレスポンシブなデザインされています。

加えて、FlashPlayerからHTML5に変更することでプレーヤに以下の新しいインタフェースを追加・変更しました。

  • プレーヤの制御部分はすべて一番下のバーにシンプルにまとめました
  • 番組タイトルは左下のに表示されていたものを左上に表示するようにしました。
  • 視聴数(同時視聴数と合計視聴数)のカウントは番組タイトルの下に。
  • 今回より配信ごとの合計視聴数の表示ではなく、チャンネル開設以降の合計視聴数に変更
  • オンエアー中の表示は右上にライブ配信中は"LIVE"と表示するようにいたしました。
  • Ustreamのロゴについてはクリック可能で、エンベッド先からUstreamのチャンネルページへ移動するようになっています。
  • プレイヤーの制御部分はライブ・録画含め再生時には非表示となり視聴の邪魔をしない設計になっています。
  • 共有ボタンはチャンネルページではプレーヤの外に設置。
  • 埋め込みプレーヤの際は動画上にマウスオーバしていただくとメニューが出ます

すでにチャンネルページおよびダッシュボードや、プレーヤから取得できる埋め込みタグは本日をもって、新プレーヤが適応されるコードとなっています。

Ustream Asia / Japan サポートブログ

 この情報は次のブログでも引用されている。リンク切れになった元の正式ページ(Ustream Asia / Japan サポートブログ - HTML5インタフェースを使った新しいUIのプレーヤーをリリース (2015/09/11))からの引用だと思われる。

 「Ustream Asia / Japan サポートブログ」のコピーページらしき所からの引用を続ける。

10/29/15--04:02: 新埋め込みコードへの移行のお願いと旧コードの動作変更(リダイレクト)について

HTML5インタフェースを使った新しいプレーヤーリリースにともない、15年9月11日よりUstream 映像プレーヤーの埋め込みコードが更新されました。
15年9月11日以前の埋め込みコードは引き続きご利用いただけますが、15年11月末より旧コードでの映像再生方法が変更となりますので旧コードをご利用の場合は新コードへの移行をお願いいたします。

旧コードご利用の場合の変更点
埋め込み先サイトやページにおいてその場で映像が再生されず、Ustreamサイト内の映像ページへリダイレクトされた後に映像が再生されます。

新、旧コードの見分け方は「iframe ソースに記述されているURLに変数「?html5ui」が含まれているかいないか、となります。 含まれていない場合旧コードをご利用されている事になりますので新コードを取得の上置き換えください。

旧コードサンプル
<iframe width="480" height="302" src="http://www.ustream.tv/embed/5883040?v=3&wmode=direct" scrolling="no" frameborder="0" style="border: 0px none transparent;"></iframe><br><a href="javascript:;" style="font-size: 12px; line-height: 20px; font-weight: normal; text-align: left;" onclick="wob(sdl('we twa p.m :u. /st /tvhwr t', 21, 27, 4, 8));">Broadcast live streaming video on Ustream</a>
新コードサンプル
<iframe width="480" height="270" src="http://www.ustream.tv/embed/5883040?html5ui" allowfullscreen webkitallowfullscreen scrolling="no" frameborder="0" style="border: 0 none transparent;"></iframe>

埋め込みコード取得方法
Ustreamの映像ページにアクセスし、映像プレーヤー下部にある「埋込み」をクリックすると埋め込みコードが表示され取得できます。

Ustream Asia / Japan サポートブログ

 埋め込みコードの取得方法は運営がIBMに変わった後の公式ページでも紹介されている。埋め込みコードは動画の下に表示される。

 さて、「Ustream Asia / Japan サポートブログ」のコピーページらしき所には気になることが書いてある。

12/11/15--00:29: Ustream HTML プレイヤー に関するアップデート

Ustream HTML プレイヤー アップデート

HTML5ビデオ再生に関する開発を進めておりますが、2016年の早い時期にHTML5対応を完了する予定です。2015年12月11日現在の進捗については以下のとおりです。

もっと読む ≫

Ustream Asia / Japan サポートブログ

 残念ながら「もっと読む ≫」をクリックしても「USTREAMサポートセンター」のトップページにジャンプしてしまって、読むことはできない。

 さて、「HTML5インタフェースを使った新しいUIのプレーヤーをリリース」が書かれたのは2015/9/11である。しかし、その後の2015/12/11のブログに「HTML5ビデオ再生に関する開発を進めておりますが、2016年の早い時期にHTML5対応を完了する予定です。」と書いてある。この時点ではHTML5対応は完了しておらず、HTML5ビデオ再生は開発中だったらしい。この時点でUstreamの動画はYouTubeのようなHTML5動画だったのだろうか?
 残念ながら、Ustreamの運営はその後にIBMに移った。「USTREAMサポートセンター」には情報が無い。ただ、【配信/動画をウェブサイトに埋め込む】に載ってるキャプチャの埋め込みコードには「?html5ui」か「?html5ui=1」が見えるので、変更されていないのだろう。

 では、「Ustream Asia / Japan サポートブログ」のコピーページらしき所に載ってる新旧のコードを張り付けてみる。

旧コードサンプル
新コードサンプル

 2016/5/29の午前4時頃のキャプチャは次の通りである。

新旧埋め込みコード比較(再生前)

 再生すると次のようになる。

新旧埋め込みコード比較(再生中)

 確かに、新旧コードでは「USTREAM LIVE」などの位置が異なる。
 では、新コードのLIVE映像はHTML5動画なのだろうか?
 確認する良い方法がある。新コードのLIVE映像をFirefoxで再生し、音量調整をWindowsの「音量ミキサー」を使って行ってほしい。音量が小さくて分かりにくいのだが、Adobe Flash Player のアイコンが表示されているはずである。これが表示されている時はFlash動画が再生されていると考えて良い。HTML5動画であれば、Firefoxのアイコンの所で音量を調整する。YouTube動画の再生で違いを確認すると良い。IE11ではFlash動画でもIE11のアイコンの所で調整するので、再生にはIE11ばかり使っている私は気付かなかった。

新旧埋め込みコード比較(再生中)

 さて、これを確認したのは2016/5/28の午前中のトラブルの後であるが、トラブルの前はどうだったのだろうか?
 2016/5/28の午前中のトラブルの前は新コードで再生するとHTML5動画だったのだろうか?
 今現在は確認できないが、トラブルの前からFlash動画のままで、私がHTML5動画に変わったと勘違いしていたような気がする。

 ところで、2016/5/28の午前中にIE11で真っ黒になってしまった埋め込みコードであるが、上記のコードと少し違う。

私が使っていた埋め込みコード
<iframe width="360" height="203" src="http://www.ustream.tv/embed/5883040?html5ui=1" allowfullscreen="true" webkitallowfullscreen="true" scrolling="no" frameborder="0" style="border: 0px none transparent;"></iframe>

 2016/5/29、早朝の今はこのコードで問題なく再生される。

 しかし、新埋め込みコードを次のように変えると、旧コードと同じ映像(「USTREAM LIVE」が映像の下)になる。

<iframe width="480" height="270" src="http://www.ustream.tv/embed/5883040?html5ui" style="border: 0 none transparent;"></iframe>

 以前は、このコードでも新コードと同じ映像だったように思う。2016/5/28の午前中のトラブル後、しばらくしてから旧コードのように表示されるようになった。原因は分からない。Ustreamの開発の方で何かをしているのかもしれないが情報が無いので分からない。
 allowfullscreen などを省いたのには理由がある。Another HTML Lint - GatewayでHTML5のソースが正しく書かれているかチェックをすると、次のように怒られたからである。

  • <IFRAME> に不明な属性 `ALLOWFULLSCREEN` が指定されています。
  • <IFRAME> に不明な属性 `WEBKITALLOWFULLSCREEN` が指定されています。
  • HTML5ではSCROLLING属性は<IFRAME>タグ中で未サポートです。CSS を使用してください。
  • HTML5ではFRAMEBORDER属性は<IFRAME>タグ中で未サポートです。CSS を使用してください。

 2016/5/28の午前中のトラブルの前までは、省いても問題なかった。「?html5ui」を付加した効果が見られた。しかし今は省いたら「?html5ui」を付加する意味がなくなる。そもそも、「?html5ui」を付加してもHTML5動画にならないのであれば、ウインドウを旧コードの時よりも広く使えること以外のメリットは無さそうであるが…。

 さて、私が次のブログを書いた2015/9/21の後、あるいは追記を書いた2015/12/6の後、2016/5/28の午前中のトラブルまで、UstreamのLIVE映像はHTML5動画だったのだろうか。それとも、私の勘違いでFlash動画のままだったのだろうか。

 とりあえず今は、今後も「?html5ui」を含む新埋め込みコードでIE11でも無事にLIVE映像が再生できることを願ってる。


nice!(0)  コメント(0)  トラックバック(0) 
カテゴリー:サイトを見て