ヘチマch

およそ40日ぶりの日記( ﾟ∋ﾟ)。

HetimaZipBrowserの機能を拡張させて、まともな画像ブラウザを作りたいなと思っているところ。HTZipItemとHTZipWrapperを抽象化させた基底クラスを作って、zip以外に普通のフォルダも読み込めるようにできた。見た目はiPhoto風の2ペイン。サムネイル表示もNSMatrixでとりあえず実装。スライダーでサイズをうにうに変えられる。

NSOutlineViewのドラッグ＆ドロップ対応、NSTaskをスレッドで動かすとたまにエラーの対処、フルスクリーンスライドショー、リソースフォークサムネイルの読み込み、くらいまで実装できればとりあえずアルファ版かな。その後ライブラリの保存機能とか付けてベータ版、バグを取って正式版、といったロードマップか。ゴールは遠い。

WebKitで作ったブラウザ（もどき）でformのtype="file"でvalue=""にあらかじめフルパスを記入したデータを開くと、最初からファイルがセットされてしまう。Safariでも同じ挙動だ。type="file"をtype="hidden"には出来なさそうだからまだ救いはあるが、セキュリティ的にまずいだろう。ちなみにCaminoだとvalueは無視して空の状態。

今作ってるソフトではこの仕様が逆に好都合なのだが、せめてhttpプロトコルの時には値をリセットするとかするべきでは。WebCore改造でなんとかなるだろうか？

WebKit.frameworkすごいぞ。nibでNSViewのサブクラスとしてWebViewを定義。NSViewを配置してCustomClassでWebViewにする。WebKit.frameworkをリンクしてビルドする。WebViewに他からURLをドロップすればとりあえず表示されてしまう。コードを1行も書かずにwebブラウザが作れてしまった！　スクロールバーも出てくるのでNSScrollViewで囲う必要もなし。

URLを開かせるだけでなくNSStringやNSDataでソースを渡せるのでいろんなことが出来そうだ。

待ちかねた1.0登場。フレームページの文字列検索が出来るようになってる。ブックマークの編集が軽くなった。自動判別も利いてるようだ。キャッシュからのフォーム送信は、環境設定で指定したデフォルトエンコーディングと同じエンコーディングのページでのみ発生しなくなっている模様。これじゃまだ気を抜けない。

で、うちのソフト。HetimaSafariHackEXのBookmarks Finderが機能しなくなっている。履歴関連のメソッド名が微妙に変わっていた。ソースの色選択を実装したら対応版をリリース予定。apeの方は問題なさげかな。クラッシュしないからよしとしとこう。全角スペースが相変わらず（ていうかそういう仕様）で、WebCore v85のソースも公開されたようだが、これだけのためにWebCoreビルドするのも面倒なのでapeで実装しようかなと思っているところ。

G5が欲しい。　　　

HetimaSafariHackEX 0.4.5 で、HTML ソースのフォントとサイズを変えられるようにしたが、公開した後でついでにタグの色を変える機能も付ければ良かったかなと思い当たる。まあ、これは次バージョンで。

また、ある不具合を解消するハックにも成功したのだが、これがInput Managerでは実現が難しい。出来るのかも知れないけれどまだ見つけられない。というわけでapeの方で実装する予定。似たようなソフトが2個あるのは紛らわしいので、そのうちapeは公開終了させようと考えていたんだけど、仕方がない。

このスレ見てアイデアいただき。とりあえず成功。近日公開（予定）。

追記：2003.06.02

そんなわけでセパレータ機能を追加した HetimaSafariHackEX 0.3 リリース

かなりいい加減にしか調べてないのでこの情報は間違ってる可能性あり。ご注意ください。

別のページに行ってから戻った状態のページからフォーム送信すると「???」になっちゃう問題。

まずキャッシュには3段階くらいあって、ディスクに保存されてるファイルとしてのキャッシュ、それがメモリ上に読み込まれている状態、ページキャッシュ、とあって後者に行くほど速い。ページキャッシュ以外は生のhtmlで、ページキャッシュはデコード、パースされている状態。と、正確にそうなっているかは自信がない。かなりあやしい。が、だいたいそんな感じと思う。
で、問題なのはページキャッシュだ。

ページのエンコーディングはKHTMLPartとDecoderが保持しているみたいだが、ページキャッシュ状態だとどちらの値も正しくなくなる。KHTMLPartは使い回すので、ページが変わるごとにエンコーディングを白紙にしている。Decoderは最初に読み込まれる時にだけ生成され、ページキャッシュ状態だとそもそも存在しない。ページキャッシュはKHTMLPageCacheにストアされるみたい。キャッシュにストア、レストアするときにエンコーディングも出し入れすればいいのだろうけど、上手く追えなかった。このページキャッシュ機能はWebKit.frameworkにも関わってるみたいだし。

暫定的に前ページのエンコーディングを継承するようにはできたが、これだとGoogleから他のサイトに飛んで戻る、みたいにエンコーディングが違うサイト間で失敗する。というわけで作業継続。。

ちなみに現状のSafariでこの文字化けを防ぐにはDebugメニューの「Use Back/Foward Cache」をオフにすれば大丈夫なようだ。ただしこれをやるとページ表示のたびにDecoderが生成されデコード、パースを行うので、Safariの魅力のひとつである驚異的なページ移動速度が若干失われる。またこの設定はひとつのViewにだけ有効で、新たにウィンドウやTabを開くと、そっちはページキャッシュ有効状態なので注意。


すべてのウィンドウとTabで最初からページキャッシュ無効にするには、Terminalで

defaults write "com.apple.Safari" WebKitPageCacheSizePreferenceKey -integer 0

と打ち込めばいいみたい。元に戻すには、

defaults delete "com.apple.Safari" WebKitPageCacheSizePreferenceKey

だ。元に戻す方法を忘れないようにしとこう。

Safariなんちゃらとかいうユーティリティでも可能かもしれない。

ちなみにDebugメニューを表示させるには、Safariなんちゃらとかいうユーティリティを使うか、Terminalで

defaults write "com.apple.Safari" IncludeDebugMenu -bool true

と打ち込む。これを再び無効にするにはもちろん

defaults delete "com.apple.Safari" IncludeDebugMenu

hetima.comを取ってみた。Value-Domainで1年1090円。安いものだな。それにあわせてサイト引っ越し＆デザインリニューアル。北国tv（ここ）もcssをカスタマイズできるようになったのでデザインをそろえた。

そんなこんなの作業が続き、しばらくProject Builder立ち上げてないのであった。

当方へなちょこプログラマなので、この情報は間違ってる可能性あり。ご注意を。

昨日の続き。

httpヘッダのcharset情報と環境設定で指定したエンコーディング、どこでごっちゃになってしまうのか追っていったらWebCoreBridgeまで辿り着いてしまった。WebCoreの外側、WebKit辺りがやってるのかな。

WebCoreをいじっても意味がないようだ。あるいはWebCore側から情報を送ってSafariの方で返すとかやってるのかも知れないけど、もう追うのに疲れた……。

たいていの人はデフォルトエンコーディングをShift JISにしてるだろうから、Shift JIS以外のエンコーディングがセットされていたらヘッダからの仮セットとみなし、自動判別はしないようにすればいいかな。ドキュメントに「デフォルトはShift JISにしてください」とでも書いとけばいいし。

というわけでWebCore73Hetima版03042001

当方へなちょこプログラマなので、この情報は間違ってる可能性あり。ご注意を。

WebCoreはまずサーバが返すヘッダにcharset情報が入っているか調べる。入っていたら「仮セット」する。入ってなかったら環境設定で指定したエンコードを仮セットする。仮セットというのは、エンコードの種類は指定するけれど、そのページがエンコードを持つかどうかの真偽値は「持っていない」ままという状態。

次にHTMLのHEADにあるMETAタグを調べる。見つかったらこっちを「本セット」する。本セットというのは、エンコードを持つかどうかの真偽値を「持っている」に変更するという状態。

ちなみにメニューバーからエンコードを手動で指定すると、メニューで選んだエンコードを最初から本セットする。本セットしているとMETAタグのチェックはスルーされる。

この後に日本語エンコード自動判別がはたらく（オリジナルは機能しないようになっている）。で、うちの改造版WebCoreでは、自動判別するかどうかの判定に、エンコードが本セットされているかどうかを基準にしている。自動判別ルーチンは間違えることはまずなさそうだが、JIS、SJIS、EUCの判定しかしていないのでUTF-8だったりするとうまく行かない。mkinoさんのWebCoreも同じみたいだ。

とまあこれが現状。この状態ではエンコードがUTF-8で、httpヘッダに情報が入っているがMETAタグがない場合文字化けする。httpヘッダの情報だけでは仮セットなので自動判別がはたらく。自動判別は上記3つのエンコードしか考慮してないので間違った結果を返す。

では解決策は？


・自動判別をUTF-8に対応させる方法。

自動判別のルーチンKanjiCode::judgeをUTF-8に対応させれば上記のようなページもちゃんと表示されるだろう。
しかし、この方法だとヘッダで指定されているのにわざわざ自動判別してしまうことになる。


・仮セットされたエンコードがヘッダで指定されているものか環境設定のものか区別できるようにする

こっちの方がスマートだと思うが修正個所が多くなりそう。仮セットの他にもう1個ビットが必要になる。自動判別の直前に仮セットされたエンコードとデフォルトのエンコードを比較するって手もあるが、あんまりスマートじゃなよいな。

とはいえ自動判別にUTF-8を追加するのは悪くないとは思う。ヘッダ情報もMETAタグもないUTF-8ページとかあるかもしれないし（あったら嫌だが……）。

日本語自動判別はいつもの通りで、リファラとチルダは改善されてる。全角スペースの問題でも追っかけようかなと思い、まず全角スペースはユニコードでいくつなんだろと検索したら、いきなり核心を突くKDEのMLがヒットした。これとかこれとかを試してみたけど、効果はあるが完全ではない。改善はされるが複数のスペースが1個分にしかならない。それらをふまえてQChar::direction()て関数を書き換えてみたところ希望通りの振る舞いになった。詳細はアーカイブに同梱のdiffを参照ください。

WebCore73Hetima版

SafariのBookmarks BarからsendActionを呼べるようにハックしてみた。メニューから実行するかわりにBookmarks Barから1クリックで呼び出せるようになるわけだが、はたして便利か？　リリースは次のパブリックベータが出てからにしようと思って……たら出てるじゃねーか！

Safariの履歴はWebKit.frameworkのWebHistoryクラスが管理している。shared instanceを返すクラスメソッドが付いてるので横取りが可能だ。[WebHistory sharedHistory]でインスタンスを取って、orderedLastVisitedDaysを呼ぶ。これはNSCalendarDateが入っているNSArrayを返す。この日付を使ってorderedEntriesLastVisitedOnDay:を呼べば実データが詰まったNSArrayが返ってくる。個々のデータはWebHistoryItemのインスタンス。これもWebKit.frameworkに属する。WebHistoryItemにはtitleやURLStringというメソッドがあり、NSStringを取得できる。ここまで来ればもうこっちのもの。HetimaSafariHackEXに機能追加してみた。ブックマークだけではなく履歴も検索対象になる。リリースは次のパブリックベータが出てからにしようと思ってるけどなかなか出ないな。。。

（画像アップロードのテストも兼ねて）

クリップボード（NSPasteboard）の中身を調べたくなり、UNIX Toolで作ってみた。Project Builderを使い、ひな形でFoundation Toolを選び、AppKit.frameworkを追加。

#import <Foundation/Foundation.h>

#import <AppKit/AppKit.h>



int main (int argc, const char * argv[]) {

  NSAutoreleasePool * pool=[[NSAutoreleasePool alloc]init];



  NSLog([[[NSPasteboard generalPasteboard]types]description]);



  [pool release];

  return 0;

}

たったこれだけで、とりあえずどんな種類のデータが入っているか分かる。CLIは楽でいいなぁ。

SafariのGoogle検索機能を追っかけた。GoogleSearchChannelというクラスがGoogle検索窓からの入力を受け取り、加工してブラウザにURLを渡す。これはSearchChannelのサブクラスになっている。

GoogleSearchChannelのインスタンス生成時にserverName:とleafName:を指定するようになっていて現在は"www"と"search"をいう文字列が渡されている。で、URL生成時にこれを使っている。この部分、固定ではないわけだ。Objective-Cで書けば

[NSString stringWithFormat:

    @"http://%@.google.com/%@?q=%@&ie=UTF-8&oe=UTF-8",

    @"www", @"search", @"Search String"]

みたいな感じ。将来的にはイメージ検索とかディレクトリ検索もできるようになるわけかな（既に隠し機能で実装されてる確率2％）。

とはいえGoogleだけじゃ物足りないと思いませんか。

CocoaMySQLていうMySQLのデータベースを見たりいじったりできるアプリケーションがあるのだが、EUCに対応してないので化ける。ソースが公開されているのでいじってみた。

リファラなんとかしようとWebCore見てたら、v68のWebCoreBridge.mm

- (NSString *)referrer

{

    // Do not allow file URLs to be used as referrers as 

    //that is potentially a security issue

    NSString *referrer = _part->referrer().getNSString();

    BOOL isFileURL = [referrer rangeOfString:@"file:" options:

    (NSCaseInsensitiveSearch|NSAnchoredSearch)].location != NSNotFound;

    return isFileURL ? nil : referrer;

}

だって。60では単に

- (NSString *)referrer

{

    return _part->referrer().getNSString();

}

となってる。v60をいじって試したが、送られるリファラは変わるし、バックキャッシュ状態(一旦「戻る」すると掲示板への投稿が化けちゃうあの状態。今命名)のページからでも問題なさげ。これはとりあえず解決、と。