MOSA Multi-OS Software Artists

「Wonderful Server Life」　　第69回　　田畑 英和

　 〜Open Directory編〜

　Open Directoryの解説が続きますが今回はクライアント側のお話です。MacOS XをOpen Directoryのマスターが稼働するMac OS X Serverに接続する方法について解説します。

　まず最初に2つの重要な事を解説します。TigerではOpen Directoryへの接続設定に「ディレクトリアクセス」というユーティリティを使用していましたが、Leopardでは「ディレクトリユーティリティ」という名前に変わりました。インストール場所はこれまでと同じ「/アプリケーション/ユーティリティ」です。「ディレクトリ」というよく似た名前のユーティリティもありますがこちらは別の目的で使用しますので注意してください。
　2つ目ですがLeopard Serverを標準またはワークグループ構成でセットアップし「システム環境設定」でユーザを登録するとネットワークユーザを作成できます。ネットワークユーザはクライアントコンピュータへのログインに使用できるのですが、「システム環境設定」でユーザ登録しただけではクライアントコンピュータへログイン可能なネットワークユーザは作成できません。なぜならばログインシェルがデフォルトでは「/usr/bin/false」に設定されているからです。ネットワークユーザとしてクライアントコンピュータにログインする場合には「ワークグループマネージャ」でログインシェルを変更しておく必要があります。またホームがデフォルトでは「/var/empty」に設定されていますので、別途ネットワークの設定も必要になります。
　いずれにせよシェルやホームが使用できなかったとしても、「システム環境設定」で管理するファイル共有、iCal、iChat、Mail、Web、VPNなどの各サービスは利用可能ですので、必ずシェルやホームを設定しなければならないというわけではありません。実際には使用目的に応じて設定していけばよいでしょう。また標準／ワークグループ構成では、クライアントコンピュータへのログインはクライアント側のローカルユーザを使用することを想定しているといった考え方もできます。
　ネットワークユーザでクライアントコンピュータへログインしないのなら、Open Directoryへの接続など不要ではないかと思う方もいらっしゃると思います。しかし、この後詳しく説明するように接続するとアプリケーションを自動設定したり、ローカルユーザとネットワークユーザを関連付けてローカルユーザでログインした場合でもシングルサインオンを実現することができます。

◇Open Directoryへの接続
　では実際の接続方法を解説しましょう。まずは先ほど説明した「ディレクトリユーティリティ」を起動します。場合によってはログイン時あるいは「ディレクトリユーティリティ」を起動した時点で自動的にネットワーク上のOpenDirecotoryを検出して接続設定が始まる場合があります。検証したところサーバが標準もしくはワークグループ構成の場合、Open Directoryのサーバを自動的に検出するようです。
　サーバが自動検出されなくても、画面左下の「＋」ボタンをクリックして手動で接続先のサーバを指定することもできます。左下のアイコンがロックされている場合には事前に管理者権限でロックを解除しておきます。
　確実に接続先のサーバを指定して接続したい場合は、自動検出されたサーバは使わずに手動で接続先のサーバを指定してもよいでしょう。

・ディレクトリユーティリティ
http://www.htabata.com/Site/LeopardServer/Pages/DirectoryUtility.html#7

　「＋」ボタンをクリックした次は、サーバのアドレスを入力します。接続するディレクトリのタイプはデフォルトでOpen Directoryになっていますが、タイプを変更すればActive Directoryに接続することもできます。
　サーバのアドレスを入力すればOpen Directoryのマスターへの接続ができます。

・サーバのアドレスを指定
http://www.htabata.com/Site/LeopardServer/Pages/DirectoryUtility.html#8

◇クライアントコンピュータの自動設定
　サーバが標準もしくはサーバ構成なら、Open Directoryへ接続したときにクライアントコンピュータを自動設定することもできます。具体的には次のような設定が可能ですが、自動設定をおこなうにはあらかじめサーバ上で該当するサービスが起動している必要があります。

・自動設定
　　- メールアカウントの設定(IMAPを使用)
　　- iChatアカウントの設定
　　- CalDAVアカウント(iCalカレンダー)の設定
　　- VPNの設定

　自動設定を行う場合にはサーバ上のアカウントを指定し、ログイン中のローカルユーザとの関連付けを行ってから一度ログアウトします。具体的には関連付けるサーバ上のネットワークユーザの名前とパスワードおよびログイン中のユーザのパスワードを入力します。

・認証設定（ローカルユーザとネットワークユーザの関連付け）
http://www.htabata.com/Site/LeopardServer/Pages/DirectoryUtility.html#11

　設定が完了すると、関連付けたネットワークユーザのパスワードがローカルユーザのパスワードと同期され、各種アプリケーション(Mail、iChat、iCal)のアカウントが自動登録されます。また、設定後にログインし直すとシングルサインオンが有効になっています。

　以上Open Directoryへの接続方法について解説しました。次回は自動設定の具体的な内容や、ローカルユーザとネットワークユーザとの関連付けについて解説します。
次回へつづく　　　　　　　　　　　　　　　　　　　　　　　　　　　　

小池邦人のCarbon視点でCocoa探求（2008/04/18）

〜　NSCodingプロトコルを実装する　〜

「しんぶんし 3」でドキュメントのロードやセーブを実現するには、ImageFileクラスに対してもう一仕事する必要があることが分かりました。今回は、先んじてこの点を解決してから画像ファイル関連の話へ移りたいと思います。

おさらいとして、もう一度ImageFileクラスのインスタンス変数を見てみます。スーパークラスとして定義されているNSObjectのさらに右側の表記 が、このクラスがNSCodingプロトコルに準拠していることを示します。

@interface ImageFile : NSObject   
{
   NSString        *path;
   NSString        *type;
   CGRect          srt;
   unsigned int    flag;
   int             kind;
   int             para;
}

NSCodingプロトコルに準拠させるために、ImageFileクラスにencodeWithCoder:とinitWithCoder:メソッドを実装してみます。具体的には、ImageFileオブジェクトからNSDataへ変換する（エンコード）アーカイブ処理と、NSDataからImageFileオブジェクトへ戻す（デコード）アンアーカイブ処理の両方を実現する必要があります。

ImageFileクラスのインスタンス変数を構造体のメンバーと見なせば、それを一つずつエンコードしていき、6つ全部実行すれば作業は終了となります。以下が、エンコード用に実装するencodeWithCoder:メソッドです。NSMutableArray（list）に保存されているImageFileオブジェクトが順次アーカイブ処理される時に、このメソッドが逐次呼び出されて実行されるわけです。

- (void)encodeWithCoder:(NSCoder *)coder
{
   [coder encodeObject:path];
   [coder encodeObject:type];
   [coder encodeValueOfObjCType:@encode(unsigned int) at:&flag];
   [coder encodeValueOfObjCType:@encode(CGRect) at:&srt];
   [coder encodeValueOfObjCType:@encode(int) at:&kind];
   [coder encodeValueOfObjCType:@encode(int) at:&para];
}

インスタンス変数の最初の2つはNSStringです。既存のCocoaオブジェクトについては、まずはそのクラスが定義されているヘッダファイル（NSString.h）を見てみます。すると、クラス定義の＠interface行に対応しているプロトコル名が列記されていることが分かります。

@interface NSString : NSObject 

つまり、NSStringの場合には、NSCopying、NSMutableCopying、NSCodingの3つのプロトコルが実装されています。エンコード対象のクラスにNSCodingプロトコルが実装されていれば、NSCoderクラスのencodeObject:メソッドを使えます。これが、対象オブジェクトのencodeWithCoder:メソッドを呼び出すことで、処理が芋ヅル式に進みます。NSStringのpathとtypeに対する処理はこれでOKです。

続いて、整数（int）、浮動小数点（float）、構造体などの非オブジェクトのエンコードとなります。こちらの実現には、encodeValueOfObjCType:at:メソッドを使います。メッセージとして渡している@encode()は、エンコードされた内容（種類）をC文字列で返すコンパイラ指示子です。例えば、@encode(int)なら”i”に、@encode(flaot)なら “f”となります。構造体の@encode(CGRect)の場合には、”{?=ffff}”（4つの浮動小数点）というC文字列となります。@encodeには、sizeof()演算子の引数として使用できる任意の型を指定できるわけです。@encodeについての詳しい内容については、以下のドキュメントを参照してみてください。

「Objective-C 2.0プログラミング言語」127ページ

http://developer.apple.com/jp/documentation/Cocoa/Conceptual/ObjectiveC/

続いて、ImageFileクラスのデコード用に実装するinitWithCoder:メソッドです。

- (id)initWithCoder:(NSCoder *)coder
{
   if( self=[super init] )
   {
       self.path=[coder decodeObject];
       self.type=[coder decodeObject];
       [coder decodeValueOfObjCType:@encode(unsigned int) at:&flag];
       [coder decodeValueOfObjCType:@encode(CGRect) at:&srt];
       [coder decodeValueOfObjCType:@encode(int) at:&kind];
       [coder decodeValueOfObjCType:@encode(int) at:&para];
   }
   return self;
}

こちらも、NSCodingプロトコル準拠のオブジェクトについては、NSCoderクラスのdecodeObject:メソッドを使います。そうでない整数等はdecodeValueOfObjCType:at:メソッドを使います。この時、デコード順序がエンコード順序と異なると処理は正しく行われません。デコード処理はエンコード時と同じ順序で列記してください。
ところで、ImageFileクラスのインスタンス変数はプロパティ宣言されています。プロパティの「属性」が（retain）であるpathとtypeは、返り値をself.pathとself.typeに代入しています。これは、コンパイラが用意したアク
セッサメソッド経由で値を代入したのと同じ意味を持ちます。ここで、返り値をpathやtypeにダイレクトに代入してしまうと、得られたNSStringがautoreleaseされますので、ある時点でエラーが発生してしまいます。注意しましょう。

また、ImageFileクラスのスーパークラスはNSObjectなので、先んじて以下の様な処理を実行していますが…

 if( self=[super init] )

もし、このスーパークラスがNSObjectではなくNSCodingプロトコルに準拠した別のクラスであれば、上記の部分は以下のように書き換える必要があります。こちらも注意しましょう。

if( self=[super initWithCoder:coder] )

さて、これでようやくImageFileオブジェクトのエンコード＆デコード処理が実装されました。これにより、オブジェクトデータのドキュメントファイルへの書き出しと読み込み（アーカイブ処理）が無事可能になったわけです。続いて「しんぶんし 3」のドキュメントファイルや画像ファイルの取り扱いを考えてみます。

・ドキュメントファイルの場合

（1）ファイルメニューの「開く…」でファイルを読み込み内容をウィンドウに表示
（2）ファイルメニューの「保存」で内容をファイルへ書き出す
（3）ファイルメニューの「別名で保存…」で名称を変えてファイルへ書き出す
（4）ファイルメニューの「最後に保存した状態に戻す」で編集をキャンセルする
（5）未保存の編集済みウィンドウを閉じた時には「保存」処理を実行する
（6）終了時に未保存の編集済みウィンドウに対して「保存」処理を実行する
（7）アプリ・アイコンへのドロップで起動と内容を表示したウィンドウを開く
（8）新規や登録済みウィンドウにドロップすることでその内容を追加登録する
（9）ドキュメントのエイリアスファイルでも上記同等の処理を行えるようにする

・画像ファイルの場合

（1）登録ボタンでウィンドウに画像を追加登録
（2）ドラッグ＆ドロップでウィンドウに画像を追加登録
（3）アプリ・アイコンへのドロップで新規ウィンドウを開き画像を登録
（4）画像ファイルが含まれたフォルダについても上記と同等の処理を行う
（5）画像ファイルのエイリアスファイルについても上記と同等の処理を行う

ドキュメントファイルの（1）から（7）までの処理は、Info.plistに対象ドキュメントのタイプや拡張子を正しく記載しておけば、NSDocumentクラスが自動で処理してくれますが、（8）や（9）の一部、画像ファイルの（1）から（5）までの処理については自分で実装する必要があるでしょう（多分）。Carbonアプリケーションであれば、こうしたファイル処理は、すべて自分自身で実装（処理用のコードを記述する）することになりますが、「CocoaDocument-based Application」テンプレートを利用すると随分と楽ができます（笑）。

ただし、Cocoaアプリケーションの場合でも、NSDocumentの力を借りなければ、多くのファイル処理を自分で実装する必要があります。その良いサンプルは、/Developer/Examples/AppKit/に含まれる「TextEdit」です。このサンプルソースコードは、Mac OS X付属アプリ「テキストエディット」のXcodeプロジェクトとなります。Cocoaのドキュメント処理に関してさらに突っ込んで勉強したい方は、ぜひ参照してみてください。

今回は、ドキュメントや画像ファイルについて実装すべき処理を列挙してみました。ただし、先んじてウィンドウに画像を表示する仕組みを作らないと、こうした処理の動作確認は困難です。次回は、登録された画像ファイルの内容をウィンドウに表示する方法について色々と考察してみたいと思います。
つづく　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

ターミナルの向こうから　　　　　　第24回　　海上 忍

〜  日本語文字コードについて考える （3）〜

　Mac OS Xが支持を集める理由の1つに、”UNIXの資産”を活用できることが挙げられます。スクリプト言語の処理系を見ても、AppleScriptはもちろんPerlにRubyにPythonに……と、有名どころがOS標準で提供されていたりします。今回は、そのうちの1つ「Ruby」を利用し、日本語文字コードを変換してみます。

・LeopardにおけるRubyの状況
　本題から始まるのも唐突な印象がありますので、まずは現状認識から。ここ数年でサポートの強化が著しい「Ruby」のいまを、かんたんにまとめてみましょう。
　Leopardでは、Cocoaをはじめとするフレームワークのブリッジ機能を提供する「RubyCocoa」が標準装備されるようになりました。Rubyを利用してMac OSXアプリケーションを開発できることが最大の特徴ですが、コンパイル/リンク不要、対話型のインターフェイス (irb) の装備といった付随機能も充実しています。MOSA伝では、藤本さんの連載「りんご味Ruby」で詳しく紹介されています。
　Leopardリリース後に登場した「MacRuby」も、インパクト大です。MacRubyでは、オブジェクトクラスの親がObjective-CのNSObjectクラス — つまり、すべてのRubyオブジェクトがNSObjectを継承、すなわちCocoaのオブジェクトとなるため、Ruby<->Cocoa間の変換コストが発生しない（Toll-freebridge）うえ、Objective-C 2.0のガベージコレクタも利用できます。Leopardの新機能
「ブリッジサポート」による恩恵といえますが、あらゆるフレームワークの機能をirbで対話しながら呼び出せることは、多くの開発者にアピールするのではないでしょうか。

・Rubyで日本語文字コードを変換する
　Leopardに収録されているRubyのバージョンは、1.8.6です。このバージョンでは、文字コード変換ライブラリとして「Kconv」と「NKF」、「Iconv」の3種類が標準装備されているため、そのうちのいずれかを利用すれば、たいていの日本語文字コード変換処理が可能です。とりあえず、以下では「Kconv」の利用を前提に話を進めます。

　Kconvでは、「Kconv#to*」を利用すると日本語文字コードを変換できます。変換元の文字コードを推定する機能を備えているため、変換先の文字コードを指定するだけでOKです。基本的な使用法は、冒頭でkconvライブラリをロードしておき、「newstring = string.tojis」のように、「to***」の部分に文字コードを示す文字列（jis / euc / sjisなど）を指定します。以下の例では、文字列（ここではシフトJISとします）をUTF-8に変換しています。

- - - - -
# -*- encoding: SJIS -*-
require 'kconv'

origin = "日本語の文字列です"
origin_utf8 = origin.toutf8
puts origin_utf8
- - - - -

　注意点としては、いわゆる半角カタカナ（JIS X 0201）を全角カタカナ
（JIS X 0208）に変換すること、MIME文字列をデコードすることが、デフォルトの動作として設定されている点が挙げられます。以下の例では、ターミナルのデフォルトの文字コードにあわせ、メールヘッダでMIMEエンコードされている文字列をUTF-8に変換していますが、特にオプションは使用していません。

- - - - -
$ /usr/bin/irb -Ku
≫ moji = "=?ISO-2022-JP?B?TU9TQRskQjt2TDM2SRsoQg==?="
=> "=?ISO-2022-JP?B?TU9TQRskQjt2TDM2SRsoQg==?="
≫ moji_utf8 = moji.toutf8
=> "MOSA事務局"
- - - - -

★編集部注：≫は実際には>>です。

　以上の方法では、Kconvによる推測が誤っている場合、「文字化け」が発生します。変換元の文字コードが明らかな場合、変換前後の文字コード（下表参照）を明示したほうが確実でしょう。以下の例では、シフトJISエンコードされた文字列を、UTF-8に変換しています。

- - - - -
moji_utf8 = moji.kconv(Kconv::UTF8, Kconv::SJIS)
- - - - -

　Kconv.guessを使用すると、文字列のエンコード形式を推測できます。戻り値は、Kconvの定数となります。以下の例では、ターミナルで入力した日本語文字列（UTF-8）を判定しているので、期待どおり「6」の値が表示されています。

- - - - -
$ /usr/bin/irb -Ku
≫ moji = " 343 201 275 343 201 222 343 203 240 343 201 237 343 203 223 343 202 262 343 201 252 343 201 277 343 202 207 343 200 234 343 202 223"
=> "ぽげムたビゲなみょ〜ん"
≫ Kconv.guess(moji)
=> 6
- - - - -

- – - – -
表：Kconvで使用できる定数

定数  値    文字コード
JIS    1     ISO-2022-JP
EUC    2     日本語EUC
SJIS   3     シフトJIS
BINARY 4     バイナリ
ASCII  5     ASCII
UTF8   6     UTF-8
UTF16  8     UTF-16
- – - – -

　RubyCocoaを使用して文字コード変換ツール（もどき）を作成するつもりでしたが、紙幅が足りず……というわけで、次回に続きます。

◇MOSAからのお知らせと編集後記は割愛します◇