So-net無料ブログ作成
検索選択
RSS [RSS1.0] [RSS2.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」に変更すれば防げそうである。実際、今のところ、私が送信したメールで文字化けが生じたという報告は無い。


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映像が再生できることを願ってる。


Firefox45でvideoタグ内のembedタグの動画が勝手に再生される

 Firefox 45.0 である動画のページを開いた時に、スタートボタンを押してないのに音声が流れた。映像と音声が別になっていて音声だけが先にスタートしてしまったのかと思いながら再生ボタンをクリックしたら、流れている音声とは別に映像に合わせた音声も流れ始めた。映像上で右クリックして再生速度を2倍にしたら、映像とそれに合わせた音声は倍速になったが、ページを開いた時に流れ始めた音声は通常の速度のままだった。そのページのソースを確認したら、動画の部分は次のような構造になっていた。

<video preload="auto">
<source src="~">
<embed autoplay="false" controller="false" src="~">
</video>

 embedタグのsrcに記載された動画の音声が再生されているらしい。autoplay="false" とあるが、HTML5では無視されるらしい。音声だけでなく映像もスタートしているのかもしれないが、embedタグがvideoタグの中にあると見えない。
 IE11で確認したら問題は生じなかった。また、後に Google Chrome Portable 49.0.2623.87 で確認しても問題は生じなかった。同じページはFirefoxの以前のバージョンでも見ていたが、問題は生じてなかった。45.0にアップデートしたことにより生じたらしい。

 この件についてはしつこくツイートしている。

 再現実験のために、HTML5の動画をネット上で見つけて、ブログにアップロードして確認したら再現できた。そのページは開くたびに音が流れて迷惑なので、この記事をアップロードした後に削除した。代わりに、再現確認のためのページを用意した。

  1. 20160317_1.html(開いたら音声が流れるので注意)
  2. 20160317_2.html(開いたら大きな音が流れるので注意)

 それぞれのページの主要部分のソースは次のようになっている。

20160317_1.html:
<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="utf-8">
<title>
embedタグが含まれているvideoタグ
</title>
</head>
<body>
<video controls style="border:1px solid gray; padding:5px;">
<source src="sample_iPod.m4v">
<embed src="sample_iPod.m4v">
</video>
</body>
</html>
20160317_2.html:
<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="utf-8">
<title>
embedタグが含まれているvideoタグ
</title>
</head>
<body>
<video controls style="border:1px solid gray; padding:5px;">
<source src="sample_iPod.m4v">
<embed src="mp4_h264_aac.mp4">
</video>
</body>
</html>

 sourceタグの動画とembedタグの動画が異なる 20160317_2.html の方が確認しやすい。ページを開いた時に再生されるのは、embedタグ内のmp4_h264_aac.mp4(開いたら大きな音が流れるので注意)である。

 この問題はvideoタグにautoplay属性が付加されているとsourceタグの動画とembedタグの動画が同時に始まるので気付きにくい。実際に、そのようなページもあった。そこでも、動画の再生速度を2倍にすると音がずれるので気付く。
 Firefoxがアップデートされればこの問題が無くなるのか、それともこれはソースの書き方の問題でFirefoxの側には問題が無いのでそのままなのかは分からない。できれば改善してほしいが、それまではサイトの運営者がソースを工夫して音声が自動再生しないようにしてほしい。embedタグを追加しているのは、HTML5動画が再生できないブラウザへの配慮だと思うが…。この問題は速やかに改善されることを期待したが改善されそうにないので、この記事をアップロードしてからは諦めて、音声が二重になった状態で我慢して閲覧することにする。
 ちなみに、この問題を指摘している情報を探したのだが、私の探し方が下手なせいか見つからなかった。仕方なく、この記事を書くことにした。

続きを読む