- HMDT archive-
December, 2004

MacDevCenter.com に、「Build an eDoc Reader for your iPod, Part 2」が登場。iPod でテキストを読むためのソフトを作る記事の、第二弾だ。今回は、iPod にテキストを流し込むところを説明。次回で最後らしい。

Apple の Tiger Developer Overview Series に、Developing 64-bit Applications が登場。Tiger での 64 bit 環境について説明している。 この記事が解説する 64 bit の利点は、ずばりメモリ空間の広さ。32 bit 環境では 4GB のメモリしかサポートできない。そろそろ、現実的に 4GB を超えるメモリが出てきそうだし、科学技術計算の世界ではすでにもっと多くのメモリが必要になっている。そこで 64 bit 環境に移行すると、16 エクサバイトのメモリが使えるようになる。16 エクサバイトがどのくらいでかいかというと、まぁ、とんでもなくでかい。 ここまでは、みんな知っていたこと。問題は、Tiger では 64 bit API はどこまでサポートされるか、ということと、32 bit 環境との互換性はどうなるか、ということだ。この記事は、これらの疑問に対する Apple の方針を教えてくれる。 まず、64 bit API について。この記事では、「Tiger は基本的な UNIX API のほとんどを実装した 64 bit システムライブラリを持つ」と書かれている。どの API まで対応するかは明文化されていないけど、まぁ、基本的なものはだいじょうぶなんだろう、と信じることにしよう。さらに、64 bit Power PC ABI（アプリケーション・バイナリ・インタフェース）も提供される。 逆にサポートしない API は？予想されていたことだけど、Cocoa および Carbon API の 64 bit API は提供されない。つまり、GUI 環境はまったく 32 bit のままでいくということだ。これは、64 bit 化は科学技術計算などの分野で主に必要とされていて、GUI アプリケーションではあまり恩恵がない、という判断に基づくものなんでしょう。現実的だけど、面白くないな。 あと、I/O 関係では、64 bit アプリケーションは POSIX の read、write、ioctl を使う必要があるらしい。ただし、read、write、ioctl が 64 bit 拡張されているかどうかは触れられていない。また、64 bit アプリケーションは IOKitLib や　 IOUserClient は使えないと明言されている。うーむ。 互換性に関しては、FAT バイナリ作戦でいくらしい。FAT バイナリとは、ひとつのバイナリファイルに、複数のプラットフォーム向けのバイナリが合わさって入っている構造。つまり、1 つのアプリケーションに、32 bit バイナリと 64 bit バイナリの両方を入れて、ユーザの環境に応じてどちらかを使う、という構造にするそうだ。この方法の利点は、ユーザ側の負担が少なくて済むこと。欠点は、バイナリがでかくなること（文字通り FAT になる）。 ということで、Tiger の 64 bit 環境は、科学技術計算 UNIX アプリケーション向けに限定されるらしい。真っ当で現実的な選択だ。予想通りすぎて、あんまり面白くないけどね。

シイラ Nightly build 041221。 ソースコード設定のアイコンを追加（Thanks to akimaro）。 サイドバー設定に、サイドバーの位置の設定項目を改良。 セキュリティ設定に、JavaScirpt ダイアログを開くときに警告音を鳴らす設定を追加。 多数のタブを開いたときの挙動の改良に挑戦中。 まず、環境設定にアイコン追加。akimaro さん、ありがとうございました。 続いて、サイドバー環境設定に「自動的に広い方を優先する」という項目を追加。このチェックボックスをオンにすると、デオフォルト位置の余白が足りなかったら、逆側を選ぶようになる。ということは、デフォルト位置を右にして、これをオンにすると、いままでと同じ挙動になるわけだ。次は、セキュリティ環境設定。JavaScript によるダイアログが開くときに、警告音を鳴らす設定を追加。この辺は、掲示板での指摘に基づくものです。 で、最後。多数タブの挙動の改良に挑戦中。これがまた、難しいんだわ。長くなりそうなので、節を変えますか。

タブの挙動改良について、簡単な説明とお願いを。 まず、最初に一言。現在の OS 上でのアプリケーションのパフォーマンス測定は、本当に複雑だ。そのときの OS の状況、他のアプリケーションの起動状況、メモリの状況、ネットワークの状況に激しく左右される。確実にパフォーマンスが上がったと断言すること、およびそれを再現することは、ほんと難しい。 ま、それはさておき。タブの挙動改良だけど、今回はレンダリング時間に注目してみた。現在のブラウザにおいて、時間のかかる処理は 2 カ所にある。ネットワークからのデータ取得と、HMTL のレンダリングだ。タブっていうのは、一気にページを開くためのアーキテクチャだけど、たとえば 10 枚のページを開いたら、10 枚分のデータ取得とレンダリングの時間がかかる。これはしょーがない。ページブラウジング時間保存の法則と呼ばれるものだ（ウソ）。時間が減らないとなると、これをいかに分散するか、というのが焦点になる。 今回試してみたのは、必要の無いページのレンダリングは行わない、っていう方法だ。タブで 10 枚のページを読み込んでも、見るのは 1 ページずつだ。そこで、裏のタブで読み込んでいるページのレンダリングは、ページを表示するまで行わないようにしてみた。これにより、10 枚のタブを開くときに、9 枚分のレンダリング時間が節約できる。 ただし、新しいタブに移動するそのときに、レンダリングが必要になる。ここでちょっと時間がかかってしまう（ただし 2 回目からはかからない）。そのかわり、タブを開いて読み込みが終わるまでの時間は速いぞ。 いろいろ試しているうちに、速いかどうか分からなくなってきたので、使ったら感想を教えて下さい。厳密に速くなったかどうか判定するのは難しいので、使用感が知りたいです。使ってて速さを実感できるか、それともタブ移動のときのつっかかりの方が気になるか。それをもとに、さらにいろいろ実験します。

MacDevCenter.com に、「Build an eDoc Reader for your iPod」という記事が。テキストファイルや PDF ファイルを iPod で読む、eDoc リーダソフトを作ろう、という記事だそうな。 ステップ・バイ・ステップで書かれていて、説明通りに操作していけば、Cocoa アプリケーションが出来上がる。何回かのシリーズもので、今回はユーザインタフェースを作るところまで。 eDoc リーダといっても、つまるところ、このソフトの目的は、PDF ファイルからテキストを抜き出すところになるでしょう。これをどうやって実現するかというと、記事では Cocoa-Java ブリッジを使う、といっているから、Java で書かれた PDF 読み込みライブラリを使うらしい。そこのところは後日になるらしい。

シイラ Nightly build 041216。 サイドバー設定パネルのアイコンを追加（Thanks to akimaro）。 ソースコード設定パネルを追加。 まずは、いつもシイラのアイコンを描いていただいている akimaro さんがサイドバー環境設定用のアイコンを追加してくれた。ありがとうございました。 そして、さらにソースコード環境設定パネルを追加。ここで、HTML ソースを表示する際のフォント、色を設定できるぜ。

シイラ Nightly build 041215 っす。 英語環境でクラッシュする問題の修正。 サイドバー設定パネルでクラッシュする問題の修正。 国際化ドメインに対応。 まず、数日前からレポートが来ていたクラッシュの問題。いろいろ調べた結果、英語リソースが壊れていた。だから、英語環境でしか発生しなかったようだ。気づかなかったよ、ごめんなさい。だから英語でのバグレポートしかこなかったんだな。あと、サイドバー環境設定で、「右左」のラジオボタンをクリックするとクラッシュする問題の修正。 そしてもう一つ、国際化ドメインに対応。これで日本語ドメインのサイトにもアクセスできる。たとえば、日本語.jp のように。

国際化ドメインについて少し補足。 国際化ドメインってのは、ドメイン名に ASCII 文字以外も使えるようにしたものだ。だから日本語もオッケーだ。ただ、いままでインターネットの世界は ASCII でドメインを記述する、っていう前提でなりたっていたから、そのまま漢字とかを流し込んだら大混乱が起きる。 そのために必要になるのが、文字のエンコードだ。ネットワークの中を流すときは、非 ASCII 文字で書かれたドメインにある変換をかまして、ASCII だけでかけるようにする。Web ブラウザとかで表示するときは、逆変換をかまして、もとの文字に戻せばいい。このエンコードで、インターネットの世界で使われているのは、Punycode と呼ばれているものだ。2003 年あたりに仕様が決定したらしい。このページ（@IT：いますぐ使える国際化ドメイン名の理論と実践）とか見ると、だいたい分かると思う。 じゃ、Mac OS X でこのエンコード、デコードを行うにはどうすればいいか。Safari がやっているんだから、たぶんなんか API があるんだろう、と思って探した。てこずったけど、見つけた。Web Kit に含まれていた。 まず、Punycode のエンコード、デコードを行うには、NSString の WebNSURLExtras カテゴリに含まれている _web_encodeHostName と _web_decodeHostName を使う。 NSString (unofficial) @interface NSString (WebNSURLExtras) - (id)_web_encodeHostName; - (id)_web_decodeHostName; これを使うと、Punycode でエンコード、デコートした NSString を得ることができる。 NSURL にも似たような、かつとても便利な API が含まれている。ユーザが入力した非 ASCII 文字を含む URL から NSURL インタンスを作るためのメソッドと、インスタンスから ASCII じゃなくて非 ASCII でドメイン名を取り出すためのメソッドだ。 NSURL (unofficial) @interface NSString (WebNSURLExtras) + (id)_web_URLWithUserTypedString:(id)URLString; - (id)_web_userVisibleString; _web_URLWithUserTypedString: を使うと、'http://日本語.jp' みたいな文字列から、NSURL インスタンスを作ることができる。そうやってできたインスタンスから、_web_userVisibleString を使うと、もとの文字列が取り出される。普通に absoluteString を使うと、エンコードされた文字列 'xn--fdajkljfk' って感じのものが出てくる。 面白かったんでサンプルを作ってみた。興味がある人はどうぞ。 ダウンロード PunyTest.dmg

Apple が、Tiger の開発者向けオーバービューとして、Dashboard の情報を公開している。Dashboard はご存知のように、小さい Widget と呼ばれるアクセサリというかアプリケーションのようなものを実現するもの。今回の Apple の記事では、この技術を開発者の視点から紹介している。 この記事で強調されているのは、開発者から見た Dashboard は、素早く作成できて素早く公開できるプラットフォームである、ということ。Tiger の機能を 1 つだけ試してみたいときとか、アプリケーションのちょっと面白いアイディアを思いついたときに、満足に動くアプリケーションを作って公開できるレベルにまで持っていくのは、なかなか大変だ。でも Dashboard なら、さくっと試してさくっと公開、ということができる。なるほど、これは面白い視点だ。つまり、RAD 環境の 1 つとして使ってもいいわけだね。ユーザインタフェースがちょっと限られてしまうけど、それもまたよし。制約があるところから、新しいアイディアが産まれるのはよくあることだ。 他に、記事を読んでいて気になったことをいくつか。まず、Widget は一つずつがプロセスとして扱われるらしい。そして Widget がクラッシュすると、Dashboard Server によって自動的に再起動される。ただし、3 回連続でクラッシュすると、Dashboard から削除されるらしい。ちょっと笑った。きっと、「Widget が自動的に削除されてしまいました」という質問が FAQ になってしまうのでしょう。 あと、Widget は Apple 独自拡張 HTML をベースにしている。具体的には、canvas タグ、img タグの composite 属性、input タグの search タイプが追加されているんだけど、Apple はいまこれの標準化に動いているそうだ。標準化が認められれば、将来 Safari 以外の Web ブラウザで Widget が動く、ということもあるかも。

シイラ Nightly build 041213。 環境設定にサイドバーパネルを追加。 サイドバーの初期設定をするためのパネルを追加。サイドバーの位置、自動伸縮を行うかどうか、ブックマークをシングルクリックで開くかダブルクリックで開くか、といった設定が行えるよ。環境設定のアイコンは、テンポラリ。

2、3 日前から、シイラで右クリックをするとクラッシュする、っていうメールがたくさんきて調査しているんだけど、ぜんぜん再現しない。こっちの環境ではまったくクラッシュしないんだけど、他にもクラッシュしている人いますか？ Safari 関係のユーティリティとのコンフクリトかなぁ？前もそういうことあった。

シイラ Nightly build 041209。 ブックマークのドラッグアンドドロップの問題を修正。 HTTP リクエストのヘッダを表示。 ブックマークのドラッグアンドドロップは、ソースコードをかなり見直した。いままで、拡張に拡張を重ねて、かなり汚くなっていたのをすっきりさせた。これで、だいぶバグが取れたはず。 もう 1 つの方は、HTML ソースを表示するウィンドウで、いままで HTTP レスポンスヘッダだけを表示していたのを、リクエストも表示できるようにした。これは、リダイレクトのデバッグをしているときに欲しくなったので、付けてみた。また、ブラウザのユーザエージェント名が気になっている人も、ここを見るといいと思う。実際に、サーバに送っているユーザエージェント名を見ることができるよ。

シイラ Nightly build 041207。 画像の自動リサイズ機能の問題を修正。 シイラで大きな画像を単体で表示させると、自動的にウィンドウの大きさに合わせる、っていう機能があるんだけど、それに実装上の問題があったのを修正。いままで動いたり、動いてなかったりしてたけど、これで安定して動くと思う。さらに、画像のドラッグアンドドロップができなくなる問題も修正。

実はこの修正、えらくトリッキーなことをやってます。 まずは、状況の説明を。この機能は、Web Kit の画像表示を担当している、WebImageView のサブクラスを作って（WebImageViewEx という名前）、それを poseAs: することで実現していたんだ。それ自体には問題が無いんだけど、困ったのは WebImageView は非公開クラスで、かつシンボルが export されていないということ。WebImageView のインタフェース自体は、class-dump などで知ることができる。でも、シンボルが export されていないと、リンクができない。つまり、ビルドが通らない。これが困った。 以前は、しょうがないからダミーの空っぽの WebImageView クラスを定義して通していた。ただこれだと、1 つの Objective-C ランタイムに同一名のクラスが 2 つ存在することになる。これはまずいよなぁ。知ってたけど、いままでそうしていました。 やっぱりそれはよくない、っていうんで別の解決策を考えてみた。この問題は、ビルドするときに WebImageView のクラス情報を知ることができないから起こる。ということは、だ。起動してからクラスを作ってやればいい！ 具体的な手順はこうなる。まず、WebImageViewEx の代わりに、WebImageViewEx_pseudo というクラスを定義する。これは、WebImageViewEx と同じ実装だけど、WebImageView じゃなくて、NSView を継承している。 このクラスのビルドは通る。そしてアプリケーションが起動した後、WebImageViewEx_pseudo の load の中で、WebImageViewEx を作ってやる。インスタンスを作るんじゃなくて、クラスの定義を作るんだ。この時点なら、WebImageView がロードされているので、このクラスの情報を知ることができる。 動的なクラスの作成の手順は、この「Objective-C プログラミング言語：objc_addClass」を参照するといい。クラスの定義をあらわす objc_class 構造体を作ってやって、objc_addClass を呼べばいい。今回は、さらにその後に class_poseAs も呼んでいる。 これで実現できた！正直な話、えらくダーティでアクロバティックな方法だ。Apple が WebImageView のインタフェースを公開していれば、それで済んだ話なんだけど。でも、こういうハックはすごく楽しい。Objective-C は、自身のランタイムが C で書かれていて、それに制約なくアクセスできるから、可能な話だ。この辺が、柔軟な開発環境と呼ぶこともできるし、言語としては汚いと呼ぶこともできるか。

Apple が Technical Note 2124: Mac OS X Debugging Magic を公開している。これは、いままでドキュメント化されていなかったものが多かった、デバッグに関する情報をまとめものだ。とても使える情報がたくさんあるよ！ カバーしているライブラリも広範囲で、CrashReporter、BSD、Core Services、ディスク、印刷（CUPS）、ApplicationServices、Carbon（HIToolbox）、そして Cocoa が含まれている。現在アプリケーションの開発を行っている方には、強く一読をお勧めしますよ。 ついでなので、Cocoa のセクションに関する要約を作ってみた。 Mac OS X Debugging Magic: Cocoa GDB のシェルで、print-object コマンド（または po）を使うと、オブジェクトの description メソッドを呼び出すことができる。 - Foundation Foundation の NSDebug.h には、デバッグで使用できる環境編集が定義されている。それらは、ゾンビオブジェクトや NSAutoreleasePool に関するデバッグに利用できる。 - AppKit NSQuitAfterLaunch 環境変数を 1 に設定しておくと、アプリケーションが起動してイベントループに入ったときにすぐ終了させることができる。起動時間を計ったり、起動時のメモリリーク調査に利用できる。 - AppKit イベント デフォルトデータベースで NSTraceEvents を YES に設定しておくと、イベントに関する情報をすべてログとして表示する。 例： % /Applications/TextEdit.app/Contents/MacOS/TextEdit -NSTraceEvents YES - AppKit ビュー デフォルトデータベースで NSShowAllViews を YES に設定しておくと、すべての AppKit のビューが枠線を表示する。 例： % /Applications/TextEdit.app/Contents/MacOS/TextEdit -NSShowAllViews YES デフォルトデータベースで NSShowAllDrawing を YES に設定しておくと、すべての AppKit のビューで、描画するとき一瞬フラッシュする。値として数字を設定することで、フラッシュする時間を変更できる。デフォルトは 100ms。NSShowAllDrawingColor に、'0.0 1.0 0.0' のように RGB 値を設定すると、色を変えることができる。さらに "CYCLE" という文字列を設定すると、周期的に色が変更するようにもできる。 例： % /Applications/TextEdit.app/Contents/MacOS/TextEdit -NSShowAllDrawing YES % /Applications/TextEdit.app/Contents/MacOS/TextEdit -NSShowAllDrawing 500 % /Applications/TextEdit.app/Contents/MacOS/TextEdit -NSShowAllDrawing YES -NSShowAllDrawingColor CYCLE - その他 デフォルトデータベースで NSDragManagerLogLevel に数値を設定すると、ドラッグアンドドロップのログを表示する。 デフォルトデータベースで NSAccessibilityDebugLogLevel に数値を設定すると、AppKit のアクセスシビリティ API のログを表示する。 以上。きっとどこかで役に立つことでしょう。

IE のお気に入りを読み込むための、長い道のり。 いまさらながら、Internet Explorer のお気に入りファイルを読み込むプログラムを書こうとしている。すでに多くの方がご存知のように、IE のお気に入りは、~/Library/Preferences/Explorer/Favorites.html に書き出されているんだ。これは Netsacpe Bookmark File Format っていうのと互換で書かれているらしい。簡単な説明がここにある。一言で言うと、HTML ファイルとして保存してある訳だ。ガッデム。再利用するときにめんどくさいじゃないか。XML にしろよ。 文句をいってもしかたがないので、どうにかすることを考える。まず、HTML ファイルをパースしないといけない。これは Cocoa ではできない。Web Kit を使うか？WebView を作成して、HTML ファイルを読み込ませて、DOM ツリーを取得。これならできそうだけど、たかがお気に入りファイルを読むために、そこまでやるのはおおげさすぎる。Web Kit の HTML パーサに直接アクセスできればいいんだけど。で、検討の結果、libxml2 を使ってみることにした。 libxml2 は、XML を取り扱うためのライブラリ。Panther あたりから、Mac OS X に標準で付いてくる（これ重要）。HTML のパーサもついている。次のようなコードで、HTML をパースしてツリーを得ることができる。 (sample) #include <libxml/HTMLParser.h> #include <libxml/HTMLTree.h> int main(int argc, char** argv) { htmlDocPtr htmlDoc; htmlDoc = htmlParseFile( "/Users/mkino/Library/Preferences/Explorer/Favorites.html", NULL); } おぉ、簡単だ。htmlParseFile を呼べばよろし。どのくらいの HTML ファイルに対応しているかは分からないけど、IE のお気に入りはとりあえず読み込めるようだ。 あと、エンコーディングも取得できる。HTML ファイルに、charset でエンコーディングが指定してある場合は、 htmlGetMetaEncoding で取得できる。

次に、このツリー構造を解析する。解析の仕方は 2 つ。1 つは、一個ずつ手でたぐっていく方法。もう 1 つは XPath を使う方法だ。XPath を使えば、ダイレクトに目的のノードにアクセスできる。たとえば、IE のお気に入りだと、トップ階層にあるフォルダは、HTML の body 要素の下の、dl 要素の下の、dt 要素の下の、h3 タグとして表現されている。これにアクセスするコードは、次のような感じになる。 (sample) void getFolder(htmlDocPtr htmlDoc) { xmlXPathContextPtr context; context = xmlXPathNewContext(htmlDoc); xmlXPathObjectPtr result; result = xmlXPathEvalExpression( (xmlChar*)"/html/body/dl/dt/h3", context); xmlXPathFreeContext(context); xmlNodeSetPtr nodeSet; nodeSet = result->nodesetval; if (!xmlXPathNodeSetIsEmpty(nodeSet)) { int i; for (i = 0; i < nodeSet->nodeNr; i++) { xmlNodePtr nodePtr; nodePtr = nodeSet->nodeTab[i]; printf("name %s\n", nodePtr->name); printf("content %s\n", xmlNodeListGetString( htmlDoc, nodePtr->xmlChildrenNode, 1)); } } xmlXPathFreeObject(result); } HTML ツリーに対して、/html/body/dl/dt/h3 っていう XPath を評価する。これで h3 タグの一覧が得られる訳だ。 XPath は便利だけど、今回のお気に入りの読み込みではフォルダをたぐるため、再帰的にアクセスする必要があるので、手でやった方が効率がいいかもしれない。これで、どうにかタイトルとアドレスは得ることができそうだ。

さらなる問題。お気に入りのフォルダには、通常のフォルダと、お気に入りツールバーとして使われる特殊なフォルダがある。これをどうやって見分けるか？結論から言うと、フォルダの名前から見分けるしかない。がーん。 名前で見分ける場合の問題は、ローカライズへの対応だ。「お気に入りツールバー」という文字列を使ってしまうと、あたりまえだけど、日本語環境でしか動かなくなる。じゃ、どうするかというと、あらかじめすべての言語用の名前を持っておくしかないか。 IE アプリケーションのパッケージを開いて、Resources のフォルダをのぞくと、各国ローカライズの .lproj フォルダの下に、デフォルトのお気に入りファイルがある。それを開いて、ツールバーのフォルダに使われている文字列を調べて、持っておくしかないな。うーん、不格好だ。 結論。Netscape Bookmark File Format は、いや。

いま思い立って、Firefox を調べてみたら、こいつも Netscape 形式なの。やめてー。

昨日の Safari 1.3 の話で書き忘れたことが一つ。Safari 1.3 は XSLT に対応する。ということは、きっと libxslt がインストールされるはず。これで、自分のアプリでためらうことなく XSLT が使えるようになる。いやっほう。

ローラン株式会社のMac OS 技術情報で、Cocoa プリンティングの翻訳が公開されています。原文はこちら。 このドキュメントは、Cocoa アプリケーションから印刷機能を使うための情報の、ほとんどをカバーできるもので、ドキュメントを扱うアプリケーションを作るときは必読です。とても有用な情報なので、どんどん読みましょう、および公開ありがとうございました。

Safari 1.3 のリリース間近、っていう情報があちこちで流れてるねー。 新しい Safari も楽しみなんだけど、Web Kit 使いとしては、Safari 1.3 とともにアップデートされる Web Kit が待ち遠しい。今度の Web Kit のバージョンアップは、おそらく去年の公開以来最大のものになりそうで、Web Kit 2 って呼んでもいいぐらいのインパクトがあるんじゃないかと思ってる。 新しい Web Kit では、編集機能や DOM アクセスやページアーカイブといった機能が追加されているはず。これによって、Web Kit アプリケーションは、いままでは文字通り「ブラウザ」としての機能しか持てなかったのが、「エディタ」として大きく様変わりできることになる。いやー、面白そう。これでシイラにがんがんといろんな機能を突っ込めるのだ。

シイラ Nightly build 041201。 認証できない証明書を、とりあえず受け入れるためのダイアログを表示。 いままでは、ログインするときに証明書が使われるサイトで、「証明書に未知のルートが含まれています」とかなんとか言われて、入れなかったことがあったと思う。その問題を対策した。ダイアログが表示されて、とりあえず現在の証明書を使うなら、「続ける」をクリックすることで次に進めるようにした。

で、この問題だけど、前にも書いたように、Web Kit というか Mac OS X が、渡された証明書の妥当性を決定できない、というのが問題。原因はいろいろあって、証明書が Mac OS X が認めている機関が認証していないとか、期日が切れているとか、データがおかいしとか、そんな感じらしい。実は、あまりよく理解していない。 この認証は、Web Kit より下のレイヤで行われているらしい。だから、Web Kit を使っているアプリケーションにはエラーだけが通知されて、おしまい。これじゃ、読み込みを続けることができねーよ。 でもやはり同じところでひっかかっている人はいたようで、Google で探すとこんな ML のアーカイブにたどり着いた。”NSURLConnection and self-signed certs.”証明書のエラーが返ってくるんだけど、これをどうやって無視すればいいの？と。 いろいろな話が出ているけど、結論は 2 つ。まず、この認証は Secure Transport ライブラリを使っている。だから、それに含まれる SSLAllowsAnyRoot API を呼んでやればいい。これですべての証明書が許可される。なるほど、低レベル API を使った正攻法だ。でもめんどくせーな。 もう 1 つの方法は、NSURLRequest の隠し API である、setAllowsAnyHTTPSCertificate:forHost: を使うこと。おいおい、そのものずばりじゃないか。これを呼べば一発だ。ということで、シイラではこちらを利用することにした。 しかし、これって結構重要な API だよな。これが公開されていないってのは、ひどくないか Apple？Safari はたぶん使っているだろうし。この辺は、実際に組んでみないと分からないとこだよな。