webarchiveからmhtmlに変換するPHPスクリプト

書きました。
https://gist.github.com/1477516

MaciOS系のブラウザでページの保存に用いられるWebArchiveファイル(.webarchive)を、主にWindowsで用いられるMHTMLファイル(.mht)に変換するためのPHPスクリプトです。

webarchiveファイルの読み込みにはCFPropertyListというライブラリを利用しています。
phpファイルを置いたディレクトリにcfpropertylistディレクトリを作り、その中にライブラリを丸ごと配置してください。
あとmbstringとか使ってます。新しめのPHPじゃないと動かないかも?

batファイルはWindows向けのおまけです。phpコマンドにPATHが通った状態なら使えます。
batファイルにwebarchiveファイルをドラッグ&ドロップすれば、順次変換してくれます。複数のファイルをドロップしてもひとつずつ変換されます。ただし毎度スクリプトを呼び出すため、遅いです。php側で複数ファイル対応にすればいいんですが、放置してます。


iCab Mobileとかで保存したwebarchiveファイル、Windowsユーザにはつらいですね。
WindowsではSafariくらいでしか開けませんから。とかいいつつ、mhtもあんまり対応ブラウザないか。
とりあえずバイナリ形式じゃないってことが重要なので、これで我慢。html+画像ファイルなど に変換したほうが便利だとは気づいてるけど、面倒なので作ってない。

テキストエリアを広げた状態でEchofonを開く方法。

Echofon 1.9.5.1での検証。
もちろん動作保証などはないので、自己責任での書き換えをお願いします。
動作検証も十分とは言えません。不具合があったときのため、元のファイルのバックアップも大切。


・Echofon.jar を解凍


・content/twitterfox.js の編集
onOpenPopup (810行目、Echofonを開くための関数) の最後に
this._window.showTextBox(true);
を追加。
Echofonを開いたときにテキストエリアを広げるため。


・content/window.xml の編集
(605行目、テキストエリアを広げるための関数) を探し、
var rows = (this.input.value.length != 0) ? 5 : 0;
if (rows == 0) return;
の換わりに
var rows = 5;
に書き換え。
テキストエリアに何らかの文字が入力されたら=0文字でなくなったら 5行分のテキストエリアを広げる というのが元々の動作。それを強制的に5行分広げるように書き換え。


ついでに showTextBox の次にある shrinkTextBox の中身をコメントアウトなどしておくと、テキストエリアが畳まれることもないはず。


・content,locale をまとめてZIPにし、 Echofon.jar にリネーム
ちなみに元のEchofon.jarは無圧縮のようです。圧縮しても動きますが、そこはお好みで。


無理やりな方法のため、もっとスマートな方法もあるでしょうが、書き換える量を減らした結果がこれです。
こっちのほうがいい という方法を見つけたら、どんどんネットに書いちゃいましょう。私はここまでということで。

NetFront Browser 4.0

NetFront Browser v4.0 for Windows Mobile コンセプト版が公開されましたが、設定項目が減っていたので調べてみました。


UserAgent等の設定例


[HKEY_CURRENT_USER\Software\Access\NFB40WM\CorePref]
"NavigatorUserAgent"="Mozilla/4.0 (compatible; MSIE 6.0; Windows CE; IEMobile 6.12) Toshiba/X01T"
"NavigatorAppName"="Microsoft IE Mobile"
"NavigatorAppVersion"="4.0 (compatible; MSIE 6.0; Windows CE; IEMobile 6.12) Toshiba/X01T"
"NavigatorAppCodeName"="Mozilla"
"NavigatorLanguage"="ja"
"NavigatorPlatform"="WinCE"


ただし、NavigatorAppVersionは指定しても反映されません。


v3.5のように複数のUserAgentを保存して切り替えて使用はできませんが、ひとつだけなら指定はできるようです。


以下、加筆することもあるかも。

        • -

NavigatorAppVersionをいじりたければ、*.muiをリソースエディタで編集すればいけるかも?

mixiの「青少年ユーザーへの機能制限」について。

もう何か月も前のことですが、mixiモバイル(以下mixi)を利用していると、コミュニティ機能が無効化されることがありました。
mixiからのお知らせとして、「機能制限のお知らせ」が届くんですね。

ケータイのフィルタリングサービスに加入していた場合、コミュニティ機能などが使えなくなるわけです。
加入していない場合でも、なぜか画像表示OFF設定のケータイも誤判定されてしまいました。
ここでは、その詳細を書きとめておこうと思います。

 

ケータイのフィルタリングサービスでは、mixiドメインは安全なサイトとしてホワイトリストに入っています。
しかしmixi側は、ホワイトリストに入っているmixi内で、フィルタリングサービスの有無によってコミュニティ機能などを制限しようとしました。本来なら実現する方法などないはずです。

 

まずは、この制限を導入した直後の仕様から。

mixiに接続した際、mixiはtoken(セッションIDのようなもの)を一つ生成します。
パッと見た感じ、tokenは
(おそらくSHA-1)_(UnixTime)
というフォーマットのようです。SHA-1が何を元にしたハッシュなのかは分かりませんが・・・。

接続した際に送られてくるHTMLの中に、
http://age-check.jp/check.gif?id=(mixiID)&token=(token)
というgif画像(1px * 1px)を読み込むimgタグが含まれています。
このage-check.jpというドメインは、mixiが各ケータイキャリアに依頼してブラックリストに登録されていると思われます。
詳細 : http://age-check.jp/
このHTMLがサーバから送信される時点では、mixi側がフィルタリングサービスの有無を判断できません。そのため、このHTMLではコミュニティ機能などが有効化されたままです。(それ以前からコミュニティ機能などを利用していたら の話ですが。)

tokenが生成されたにも関わらずcheck.gifが読み込まれない場合には、フィルタリングサービスに加入していると判断し、コミュニティ機能などが次回(もしくは数回以内で)接続時に無効化されます。ケータイ端末の画像表示OFF設定の場合に誤判定されるのはこのためです。

制限の導入直後は、確かこのimgタグがソースの下部に記述されていたと思います。
そのため、フィルタリングサービス未加入かつ画像表示ON設定の端末でも、mixiトップページが完全に読み込まれる前に、ページ移行した場合には制限にかかることがありました。

しばらくすると、このimgタグがソースの上部と下部の2か所に記述されるようになりました。
読み込まれる確率を上げたということでしょう。

 

そして、最近また調べてみると、仕様が変更されていました。

tokenの生成は今までと同じで、異なるのは、imgタグを用いた画像読み込みではなく、linkタグを用いたcssの読み込みに変更されている点です。
http://age-check.jp/check.css?id=(mixiID)&token=(token)
というURLでした。実際に読み込んでみると、中身は以前と同じgif画像でしたが・・・。

CSSの読み込みは、かなり前のケータイブラウザでも対応しています。
再現度こそ高くはありませんでしたが、文字色や背景色を変えるなどという基本的なことはできたように記憶しています。
そのため、この方法を用いることで、かなり多くのケータイ端末をサポートでき、かつ画像表示OFF設定であっても機能するようになりました。

Twitter周りの仕様について。

現時点での推測など。暫定まとめ。


■注意
・よく分かってないのに分かったつもりで書いてしまっている個所があるかもしれません。
Twitterのバグを見つけたり、裏技的な何かを見つけた記事ではありません。
・すでに知っている人にとってはまったく無益な記事です。
・この内容はreply、RTについてのみです。DMは考慮していません。
Twitter公式RT機能については存在しないものとします。


TwitterAPIを利用した投稿などでのreplyの仕様
●reply時の通信内容の説明
Echofonでreplyを行った際のPOSTデータ
status=%40falms%20hogehoge&source=TwitterFon&in_reply_to_status_id=1234567890

  • status

ツイート本文のこと
デコードすると、"@falms hogehoge"となる。

  • source

クライアント名

  • in_reply_to_status_id

reply時に送信される相手のツイートの固有ID
1234567890は架空の値である。
(過去の誰かの発言にこのIDが使われたことがあるとは思うが・・・)
このreplyは、
http://twitter.com/falms/statuses/1234567890 (実在しません!)
に対するreplyということになる。
●"in reply to ***"や"***宛"と表示される、つまりreply扱いされる条件

  1. status に相手のID(@id)を含む
  2. in_reply_to_status_id が指定されている
  3. ttp://twitter.com/(相手のID)/statuses/(in_reply_to_status_id) が存在する

これらの条件を全て満たす場合、ツイートはreply扱いされる。
どれか一つでも欠けた場合、投稿はreplyではなく、Mentionsとなる。
1つ目の条件が欠けた場合には、普通のツイートとなる。
注目すべき点は、1つ目の条件が、"status の先頭に〜"ではない点。
これらの条件に当てはまりすればよいため、通信経路中で in_reply_to_status_id を、存在する別発言のIDに書き換えたところ、別発言に対するreply扱いさせることもできた。
ついでに言うと、"***宛"という表現よりも、"***への返信"としたほうが元の英語の意味に合うと思う。


TwitterのWebインターフェースの仕様
●ツイートの書き方によるreply、通常のツイートの区別

  • 「@id メッセージ」

返信ボタンを押すと、ツイート入力エリアに相手のID(@id)が自動で入力される。
その後ろにメッセージをつけて送信することで、replyとなる。
@idと、@idおよび自分の共通するフォロワーのTLに表示される。@idのMentionsにも表示される。

  • 「.@id メッセージ」 (先頭にドットがついています!)

Webインターフェースでは返信ボタンを押したのち、入力された@idの前に文字をつけることで、reply扱いされなくなる。よって「どのクライアントを使用していても、@idが先頭になければ、reply扱いされなくなる」という誤解が生まれる。
入力エリア上の「いまなにしてる?/What are you doing?」の文字が変化するのを見るとよくわかる。JavaScriptで、@idがツイートの先頭にあるかどうかをリアルタイムにチェックしている。
自分のフォロワー全員のTLに表示される。@idのMentionsにも表示される。
TwitterのRT

  • そもそもTwitterにRT機能はなく、RTは勝手に広まった書き方の一つ。
  • replyをreplyにしない(自分のフォロワー全員に見せる)ための方法。
  • @idの前にドットをつけるのと、RTをつけるのは同じ効果。(なんらかの文字をつけた というだけ。)


■Echofonの仕様
Echofonとは、FirefoxTwitterクライアントアドオンのこと。
ここではiPhone用クライアントのことではない。
●Echofonでのreply

  • Echofonでは返信ボタンを押すことにより、ツイート入力エリアに相手のID(@id)が自動で入力される。それと同時に、入力エリアのすぐ上にreply先のテキストが表示される。
  • 返信ボタンを使って入力されたIDが消されるまで、reply先のテキストは表示されたままとなる。
  • reply先のテキストが表示されている限り、投稿時に in_reply_to_status_id が送信される。

●Echofonでreply、RTを使用する際の注意点
返信ボタンを押したのち、そのままツイートの右クリック→再投稿を選択すると、reply先テキストが表示されたままとなる。
その状態で投稿すると、「RT: @id: 〜〜〜」というツイートが@idへのreplyとして投稿されてしまう。RT本来の目的である、自分のフォロワー全員に見せる ということにはならない。


■言いたいこと
とにかくこれだけは言いたい!ってことを簡単に言うと、
RTしたときは、〜宛とか表示されてないか再確認を!
〜宛が表示されていると、それはreplyになってます!


■今回のテストに使用したソフト
Tween
Firefox, Tamper Data, Echofon
Burp Suite(Burp Proxy)


最後に、見にくい記事でごめんなさい。
初めてのはてダでいろいろと戸惑っています。

Twitter周りの仕様について、現時点での推測

整理しました。が、余計に長くなってます。
http://d.hatena.ne.jp/falms/20091106/1257517482


書きかけメモ。あとで整理する。

間違っているところが(多数)あるかもしれないですが、ツッコミはやさしくお願いします。
TamperData大活躍?このアドオン便利です。


TwitterのWebインターフェースでの仕様について。
「@id メッセージ」
@id以外のユーザーのTLには表示されない。@idにはMentionとして通知。

「メッセージ1 @id メッセージ2」
@id以外のユーザーのTLにも表示される。@idにはMentionとして通知。
メッセージ1は何でもよいため、「.@id メッセージ」などとして他人にも見せたりする。


Echofon(FirefoxTwitterクライアントアドオン)の仕様について。
・返信ボタンを押すと、自動入力された@idが消されるまでは、in_reply_toの値を投稿時に使用する(?)
・ゆえに、返信ボタン押し下げ後に@idの前にドットをつけて「.@id 〜〜〜」としても、@idへの直接の返信になってしまう。
・ドットをつけているのはただ単にシンプルだからという理由かと。別にどんな文字でもよいはず。
・困ったことに、返信ボタンを押した後にメッセージ右クリ→再投稿を押しても、in_reply_toの値を保持したままになる。投稿時にはその値を使用する。(?)


Twitter自体の仕様について。
・「投稿にin_reply_toに@idが指定されている」かつ「in_reply_toで指定されている@idが投稿中にも含まれる」場合、@idへの直接の返信となり、@id以外のユーザーのTLには表示されない。(?)


さらにメモ。
※ @idをフォローしていないユーザーのTLには表示されない
の一文に書き換えるべき個所多数?
・「(Web)で (id)宛」という表示は、@idを指定したすべての発言につくわけではなく、in_reply_toが指定されたときだけなので、実際には@idのとある発言に対するもの。「(Web)で (id)のこの発言への返信」くらいの意味で使われているはず。「(id)のこの発言」が発言に対するリンクとなっているとする。
・重要なのはin_reply_toではなくin_reply_to_status_id?


ここ重要!
・大学のPC(個人用ではなく、いっぱい設置されてるやつです><)でやっても、作業効率が悪いだけ。家帰ってからやる!家に帰るのは8時!飯食って風呂入って結局11時とかになるんだけどな!

はじめに

・Blog
検索避けをしているため、情報発信の場としてはよろしくない。
全然発信できていない。

Twitter
140文字じゃ全然足りない。
投稿するごとに他人のTLにも表示されるため、よろしく思わない人もいる(かも)。


というわけで、はてダはじめました!
geekな感じの内容がメインになると思います。