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

ツイッターのタイムラインからツイートが消えた

 IE11でツイッターのタイムライン https://twitter.com/ を見ていた時に並び順か何か違和感があって確認したら「前回ログインからのできごと」という枠で括られたツイートがあった。普通に時間順に表示したかったので右上の閉じるボタン × をクリックして閉じて、「同じようなツイートの表示を減らす」か何かをクリックした後、表示されるはずの複数のツイートが表示されないトラブルが起こった。表示されないツイートのアカウントはフォローしていてブロックしていないので表示されるツイートもある。自分がフォローしていない人へのリプライでもない。そのアカウントのプロフィールページ(ユーザータイムライン)では見ることができる。ついっぷるでも見ることができる。Firefox 50.0.2 でIE11と同じようにタイムラインを表示しても見ることができる。大切な人の大切なツイートを見逃しかねないトラブルなので解消する方法を検索して探したけれど私と全く同じトラブルは見つからず、解消方法も分からなかった。
 似たようなトラブルを指摘している2016/3/26のブログ記事は見つけた。【【Twitter】ツイートが全部表示されない(抜けがある)原因】に次のように書いてある。

twitterを使っていて自分以外のユーザーのアカウントページに行き、ツイートを閲覧する事があると思います。この時、ツイートが全部見られない事が、実はあります。
例えば「A・B・C・D」という4つのツイートを本来しているのに、見えるのは「A・C」の2つだけ・・・と言う事があります。これは一体なぜなのでしょうか?
【Twitter】ツイートが全部表示されない(抜けがある)原因

 2014年2月14日 09:04 のTwitterサポートのツイートが紹介されている。

 私が遭遇したトラブルはプロフィールタイムラインではなく、ホームのタイムラインなので違うかもしれないが、ログアウトした後にキャッシュを削除して再ログインすれば表示されるかもしれないということなので試してみた(Internet Explorer11のブラウザキャッシュ(インターネット一時ファイル)の削除方法)。ツールボタンをクリックして表示されたメニューから「セーフティー」→「閲覧履歴の削除」を選択して「閲覧の履歴の削除」ウインドウで「インターネット一時ファイルおよびWebサイトのファイル」をチェックして「削除」ボタンをクリックすれば良い。
 しかし、残念ながら、この方法では消えたツイートは表示されなかった。「履歴」も削除したけれどダメだった。
 翌朝、ブラウザのトラブルではクッキーを削除すれば解消されることを思い出したので試してみた。ツールボタンをクリックして表示されたメニューから「セーフティー」→「閲覧履歴の削除」を選択して「閲覧の履歴の削除」ウインドウで「クッキーとWebサイトデータ」をチェックして「削除」ボタンをクリックすれば良い。

閲覧の履歴の削除

 クッキーを削除すると他のサイトもログアウトしてしまうなど他のサイトに影響があるので避けていたのだが、この方法で消えていたツイートが表示された。
 同じトラブルに遭遇した人はお試しあれ。


ソネブロのツイートまとめ投稿に取得漏れがある

 ソネブロのツイートまとめ投稿は「Twitterでつぶやいた1日分のツイートを、まとめてブログに投稿する機能」で「指定の時刻に自動で投稿される」ことになっている(参照)。便利で利用しているのだが、このツイートまとめ投稿されたブログ記事に含まれていないツイートが見つかった。

 まず、私は【正己 (self7777) from Twitter】で次のように設定している。

Twitterまとめ投稿の設定
(クリックで拡大)

 並び順を「昇順」にして「00:00」を1日の区切りにしてある。この設定でブログ記事の投稿時刻は「00:01」になるらしい。例えば、2016/11/6に投稿されたツイートを自動取得したブログ記事(参照、確認できるのは2016/12/1まで)の投稿時刻は「2016-11-07 00:01」になっている。

「前日分の自動取得 2016/11/07」の末尾
(クリックで拡大)

 この記事が取得した最後のツイート(参照)の投稿時刻は「7:43 PM - 6 Nov 2016」(19:43 - 2016年11月6日)である。
 では、翌日の「2016-11-08 00:01」に投稿されたブログ記事(参照、確認できるのは2016/12/1まで)を見てみる。

「前日分の自動取得 2016/11/08」の最初
(クリックで拡大)

 この記事が取得した最初のツイート(参照)の投稿時刻は「6:57 AM - 7 Nov 2016」(6:57 - 2016年11月7日)である。2016/11/7に投稿された記事が自動的に取得されているはずであるが、実は、このツイートよりも前に投稿されたツイートがある。それは【正己(@self7777)/2016年11月07日 - Twilog】で確認できる。「posted at 06:57:54」のツイートよりも前に7つもツイートがある。前日の最後のツイートは【正己(@self7777)/2016年11月06日 - Twilog】で確認できるが、「posted at 19:43:34」で、上記の「2016-11-07 00:01」に投稿されたブログ記事(参照、確認できるのは2016/12/1まで)と同じである。すなわち、11/7の「00:32:37」から「00:50:21」に投稿された7つのツイートが「2016-11-08 00:01」に投稿されたブログ記事(参照、確認できるのは2016/12/1まで)から漏れている。

 もう一つ、それ以前に確認していた異常がある。「00:00」を1日の区切りにしてあるが、それよりも後に投稿されたツイートが含まれてしまうことがある。

「前日分の自動取得 2016/11/11」の末尾
(クリックで拡大)

 「2016-11-11 00:01」に投稿されたブログ記事(参照、確認できるのは2016/12/1まで)の末尾二つのツイート(0:07 - 2016年11月11日0:08 - 2016年11月11日)は「2016-11-11 00:01」よりも後に投稿されたツイートである。投稿時刻が正しければ取得できるはずがないツイートで、この2つのツイートは翌日の「2016-11-12 00:01」に投稿されたブログ記事(参照、確認できるのは2016/12/1まで)の頭に含まれていなければいけない。
 ちなみに、ソネブロのツイートまとめ投稿ではツイートの投稿時刻が「12:07 AM - 11 Nov 2016」と「12:08 AM - 11 Nov 2016」となっているが、誤りである。「AM」ではなく「PM」である。あるいは「0:07 AM - 11 Nov 2016」「0:08 AM - 11 Nov 2016」である。これはツイッターの方のバグかもしれない。

 どうしてこのようなことが起こるのだろうか。
 まず、ブログの投稿時刻は「00:01」となっているが、実際に投稿された時刻はもっと後だろう。そうでなければ投稿時刻よりも後のツイートを取得できるはずがない。
 次に、取得するツイートの選択であるが、実際の投稿時刻、あるいは自動投稿のブログラムが動き出した時刻よりも前の24時間に投稿されたツイートが取得されるのではないだろうか。例えば、「2016-11-08 00:01」に投稿されたことになっているブログ記事の本当の投稿時刻は「2016-11-08 00:50:21」よりも後で、仮に「2016-11-08 00:51:00」とすると、取得できるのはそれよりも24時間前の「2016-11-07 00:51:00」より後になる。すると、11/7の「00:32:37」から「00:50:21」に投稿された7つのツイートが漏れてしまう。前日の「2016-11-07 00:01」に投稿されたことになっているブログ記事の本当の投稿時刻が「2016-11-07 00:51:00」であれば、11/7の「00:32:37」から「00:50:21」に投稿された7つのツイートはそちらに含まれるだろう。しかし、本当の投稿時刻が「2016-11-07 00:30:00」であれば、11/7の「00:32:37」よりも後のツイートは含まれない。それで、どちらのブログからも漏れてしまう。

 さて、このバグは直してもらえるのだろうか?
 とにかく、【ツイートまとめ投稿】を利用している人は注意してほしい。絵文字の問題(【絵文字付きツイートをソネブロに埋め込むときには要注意】)と同様に、改善されるまでは、毎日確認した方が良いだろう。ツイートが抜けていた場合は手動で入れるしかないだろう。


絵文字付きツイートをソネブロに埋め込むときには要注意

 【絵文字のせいでソネブロのツイートまとめ投稿が正しく機能しない】で私は『手動でツイートを引用する場合(Twitter連携:使い方 マニュアル)は大丈夫だった』と書いた。しかし、Twitterの公式の埋め込みソースをブログに貼り付けても絵文字以降が削除されるケースがあることが分かった。

 例えば次のツイートで生じる。

 このツイートの埋め込みソースを取得すると次のようになっている(取得方法)。

<blockquote class="twitter-tweet" data-conversation="none" data-lang="ja"><p lang="ja" dir="ltr">簡単な再現法。<br>ソネブロの記事入力欄に次のよう入力。<br>--この下から--<br>この絵文字があるとダメ。<br>😇<br>ここは削除される。<br>--この上まで--<br><br>保存後に次のようになる。<br>--この下から--<br>この絵文字があるとダメ。<br>--この上まで--</p>&mdash; 正己 (@self7777) <a href="https://twitter.com/self7777/status/782087984170491905">2016年10月1日</a></blockquote>
<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>

 ソネブロの編集画面で入力欄に 😇 のような絵文字があると、「保存」ボタンをクリックして保存した後に絵文字の後のソースが全て削除されてしまう。このトラブルはツイートの埋め込みの場合に限らない。上に引用したツイートに書いてある通り、次のテキストをコピーしてソネブロの編集画面の入力欄に貼り付けて試してほしい。絵文字 😇 以降が削除される。

この1行目だけが残る。
😇
この3行目は削除される。
この4行目は削除される。
この5行目は削除される。

 場合によっては大量に書き直さなければいけなくなり、一種の悲劇である。
 絵文字でも 😊 なら大丈夫である。次のテキストをコピーしてソネブロの編集画面の入力欄に貼り付けて試してほしい。

この1行目は残る。
😊
この3行目も残る。
この4行目も残る。
この5行目も残る。

 ソネブロで後ろのソースごと削除されてしまう絵文字と削除されない絵文字の違いが何か調べるために【絵文字一覧】を作った。左から「数値文字参照(16進数による指定)」「16進数による指定で表示される絵文字」「数値文字参照(10進数による指定)」「10進数による指定で表示される絵文字」「記事入力欄に絵文字を記載した場合のソネブロでの表示」という順番になっている。一覧を作成するために次のサイトを利用してデータを取得し、Excelと Windows 7 の「メモ帳」で加工した。

 【絵文字一覧】を見ると、ソネブロでは表示されなかったり、 という文字になったり ? になっている絵文字がある。後ろのソースごと削除されてしまった絵文字 😇 のソネブロでの表示は ? である。一方、削除されなかった絵文字 😊 ではソネブロ用の画像が表示されている。【絵文字一覧】のソースを入力して保存した後に、絵文字のソースがソネブロ用に書き換えられた。全てを試したわけではないが、いろいろと試したら、ソネブロでの表示が ? になる絵文字があると、絵文字の後のソースが全て削除されてしまうようである。

 この問題の対処法は、絵文字の部分を数値文字参照で記載すれば良い。この記事では数値文字参照を利用している。ツイートの埋め込みソースの場合は絵文字の部分だけでなくツイート文字全てを削除してもツイートが表示されるので、埋め込みツイートを文字検索の対象にしないのなら<p lang="ja" dir="ltr"></p>内を全て削除してしまえば良い。

 さて、この問題にはまだ謎がある。上に『ソネブロの編集画面で入力欄に 😇 のような絵文字があると、「保存」ボタンをクリックして保存した後に絵文字の後のソースが全て削除されてしまう』と書いたが、 😇 があっても後ろのソースが削除されない場合もある。
 例えば、次のテキストをコピーしてソネブロの編集画面の入力欄に貼り付けて試したら、ソースが削除される問題は生じなかった。

この1行目は残る。
😃
😇
この4行目も残る。
この5行目も残る。
この6行目も残る。

 保存後に編集画面を開いてソースを確認すると次のようになっている。

この1行目は残る。
<img src="https://blog.so-net.ne.jp/_images_e/140.gif" width="15" height="15" alt="[わーい(嬉しい顔)]" border="0" class="sonet-icon" />
?
この4行目も残る。
この5行目も残る。
この6行目も残る。

 😇 の上に 😃 があるだけで「絵文字の後のソースが全て削除されてしまう」問題が生じない原因は全く想像できない。【絵文字一覧】でも【絵文字と数値文字参照(10進数による指定、一部は文字実体参照?)】でも問題の絵文字を編集画面の入力欄に記載したが大丈夫だった。この件については興味があるが、深く調べないことにする。
 また、【絵文字のせいでソネブロのツイートまとめ投稿が正しく機能しない】【ツイートまとめ投稿】で生じる問題を書いたが、これは記事を保存した時に起こる上記のトラブルとは異なり、ソネブロで表示できる( ? にならない)絵文字でも起こる。ただし (数値文字参照は&#10071;)や (数値文字参照は&#9996;あるいは&#9996;&#65039;)など一部の絵文字では問題がなかったことを確認している。この件についても興味があるが、深く調べないことにする。

 以上、ソネブロで、ソネブロが想定してない絵文字を使った場合のトラブルについて書いてきたが、とにかく、webページから絵文字を含んだテキストをコピー&ペーストしてソネブロで使わない方が良いだろう。トラブルが起こった後に対処しても良いが、せっかく書いた大量の文章が削除されてしまったら悲劇である。ツイートの埋め込みも絵文字が含まれてないかチェックした方が良い。【ツイートまとめ投稿】を利用している場合は、問題がないか毎日チェックが必要である。100件を超えたら問題があっても対処できないので、一日に100件を超えるツイートをしないこと、100件前のツイートが削除されないように翌日にツイートする前に確認することが必要である。面倒だが、仕方がない。仕様がコロコロ変わるTwitterに付き合ってソネブロの仕様変更をするのは大変かもしれないが、ソネットの担当者がこの問題を改善してくれることを願う。
 ところで、ソネブロ以外のブログでは生じないのかな?


Internet Explorerで見るとUstreamが真っ黒

 2016/9/29にUstreamのチャンネルをInternet Explorer 11(以下、IE)で見ようとしたらライブ映像が真っ黒だった(参照)。毎日見ているチャンネルで、前日の同じ時間は問題なかった。以前も同じことがあった(2016年5月28日のツイート)。前回は問題のあるフリーウェアをインストールしたことでIEに異常が生じた可能性があったので、そのことを中心に原因を探ってフリーウェアとは無関係だと推測した(参照)。結局は原因が分からないまま、しばらくしたら改善した。今回は、IEの状態は前日と同じである。Ustreamの側に何らかの変化があったと考えるのが妥当だろう。そこで、ユーザーの側で対処する方法がないか探った。この記事を書いた翌日にはUstreamの側で改善しているかもしれないが、何度も同じことが起こりそうなので記録しておく。

 私がUstreamの真っ黒状態を確認したのは自作の埋め込み動画だったが、Ustreamの公式ページで見ても次のように真っ黒だったことを確認した。

UstreamのチャンネルをIEで見ようとしたら映像が見ると真っ黒
(クリックすれば拡大)

 Firefoxで見れば問題ない。同じ問題に遭った人は他にもいて、EdgeやChromeでは問題が生じてないらしい。どうやら真っ黒になるのはIEを使って見た時だけらしい。丸一日の試行錯誤の末、次のような情報を見つけた。

エミュレーション ツールを使うと、さまざまなドキュメント モード、ユーザー エージェント、画面サイズ、画面解像度、GPS の位置座標で、Web ページがどのように動作するかをテストできます。
(中略)
IE のみで発生し他のブラウザーでは発生しないエラーをデバッグする場合は、ユーザー エージェント文字列の変更を最初に試してみることをお勧めします。ユーザー エージェント文字列は、基本的には、IE 自体を異なるバージョンまたは別のブラウザーとして識別するように、IE に命令する方法です。
フロントエンドやバックエンドのスクリプトが、使っているブラウザーを検出する場合があります。また、コード内でブラウザー検出を使っていない場合でも、サード パーティの JavaScript ライブラリやサーバー側のスクリプトを使ってブラウザー検出を行うことができます。
ブラウザー検出の問題点は、Web ページの機能のスケール バックや変更を行うためにブラウザー検出が使われる場合があることです。このような機能のスケール バックや変更は、機能検出を使って検出したブラウザーの実際の機能ではなく、スクリプトの開発者が想定するブラウザーの機能に基づいて行われる可能性があります。このため、予期しない動作が発生する場合があります。これは、Microsoft Internet Explorer 6 を対象としたコードが IE11 では異なる動作をしたり、お使いのブラウザーで完全にサポートできる機能がスクリプト開発者の想定が原因で機能しない可能性があるためです。
ユーザー エージェント文字列の変更によって問題が解決された場合、ブラウザー検出が原因である可能性があります。
ブラウザー、画面サイズ、GPS の場所をエミュレートする (Windows)

 実際、この情報を見つける前に「F12開発者ツール」(キーボードのF12を押して表示)の「エミュレーション」タブで「ユーザーエージェント文字列」の所を「既定」から「Mozilla Firefox」や「Google Chrome」に変えたらライブ映像が表示された。上の引用は開発者ツールの「エミュレーション」の使い方を探していた時に見つけたものである。

「F12開発者ツール」の「エミュレーション」タブ
(クリックすれば拡大)

 上に引用した日本語を読んでもIEで見た時にUstreamの映像が真っ黒になった原因は分かりにくいのだが、要するにUstreamのスクリプト開発者がIE11では機能しないコードを使っていて、ブラウザ検出でIE11を検出してもIE11用にコードを変更するようなスクリプトになっていないから問題が生じたと解釈した。間違っているかもしれないし、スクリプトのどの部分に問題があるのかは調べてない。

 さて、これで問題が解決したと思ったのだが、この「F12開発者ツール」はエミュレーション後に閉じると「ユーザーエージェント文字列」が「既定」に戻ってしまう。標準でこれを固定する方法がないか探したのだが見つからなかった。そこで、「ユーザーエージェント文字列」を変更したままに使い続けられるソフトを探したら見つけた。ググった結果、【IEのユーザーエージェントを変更したい 拡張ツールで便利なのない?】を見つけた。ここで紹介されてるリンク先の【Bayden Systems - UAPick】を確認したら「System Requirements Internet Explorer 8, 9 or IE10/IE11 (Desktop mode only) 150kb disk space」と書いてある。使用中のIE11でも動作しそうなのでインストールして確認した。

「アドオンの管理」ウィンドウ
(クリックすれば拡大)

メニューバーの「ツール」メニュー
(クリックすれば拡大)

「Select User-Agent string」ウィンドウ(デフォルト)
(クリックすれば拡大)

 IEのメニューバーの「ツール」メニューの中に「Set UA String」というメニューがあるので、選択すると「Select User-Agent string」ウィンドウが現れる。ここで注意が必要である。「Select User-Agent string」ウィンドウがIEの後ろに隠れたりすると、再表示させるのに一手間かかる。最適な方法は分からないが、私は「タスクマネージャー」を使って再表示させた。
 さて、インストールした直後は「UA」欄にIEのデフォルトのユーザーエージェント文字列が入力されている。私の場合は「Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko」だった。変更するには「Templates」のセレクトメニューから選択して「Reuse this UA string for new Windows」にチェックを入れて「Save Changes」ボタンをクリックすれば良い。「Reuse this UA string for new Windows」にチェックを入れないと、IEを閉じて再起動したら「F12開発者ツール」と同様にデフォルトに戻ってしまう。変更したユーザーエージェント文字列を継続して利用するのなら、「Reuse this UA string for new Windows」にチェックを入れるのを忘れてはいけない。デフォルトに戻したければ、次回にチェックを外して「Save Changes」で保存すれば良い。「UA」欄がどんな文字列であれ、IEを再起動した後はデフォルトに戻っている。単に文字列を確認した場合もチェックを入れずに閉じる(保存する)と次回からはデフォルトに戻ってしまうので注意が必要である。

 「Select User-Agent string」ウィンドウで「Templates」のセレクトメニューから選択すれば、該当するユーザーエージェント文字列が「UA」欄に入力されるのだが、私はどれを選択したら良いか分からなかった。そこで、実際に使っているFirefoxのユーザーエージェント文字列を入力して保存することにした。Firefoxのユーザーエージェント文字列はJavaScriptのnavigator.userAgentを使えば確認できるらしい。

JavaScript:
今のユーザーエージェント文字列:<script>document.write(navigator.userAgent);</script>
結果:
今のユーザーエージェント文字列:

 私が使っていたFirefoxのユーザーエージェント文字列は「Mozilla/5.0 (Windows NT 6.1; WOW64; rv:49.0) Gecko/20100101 Firefox/49.0」だったので、これを「Select User-Agent string」ウィンドウの「UA」欄に入力して保存した。

「Select User-Agent string」ウィンドウ(Firefox49.0に変更)
(クリックすれば拡大)

ユーザーエージェント文字列の変更確認

 さて、Ustreamの仕様変更か何かが原因でIEで見た場合にライブ映像が真っ黒になっていても対処できるようになった。では、いつまで「ユーザーエージェント文字列」を変更したままにしておけば良いのだろうか。変更したままだと、Ustream側が改善しても気付かない。5/28に起こった真っ黒現象の時は、改善前も後も、Ustream側から何の報告も無かったように思う。今回も何の報告も無しに改善されるのかもしれない。「ユーザーエージェント文字列」を変更したままIEを使い続けた状態で、「ユーザーエージェント文字列」がデフォルトでもライブ映像が正常に表示されるようになったことを確認するにはどうしたら良いかが、今の私の悩みである。

続きを読む


タグ:不具合 ustream