なんとかできました。オリジナルと違う点は次のとおり。まだまだバギーですので問題があればご連絡ください。

年度末ドタバタしている中SmultronへのNKFCocoaを組み込み中です。迷っているのはUnicode変換表にない文字を含むファイルの扱い。一応、NKFCocoaによるエンコードの判定そのものは組み込んだのですが、Shift_JISを正しく判定することができているにも関わらず読み込めないファイルがいくつかあって収まりが悪い。

メール関連のテキストを扱う必要があってSmultronでテキストを開こうとしたら予想どおりの文字化け。これまで文字コードの判定には何度か手を入れてきたけれど、ISO-2022-JPは特に何もしてこなかったので、今回はISO-2022-JP対応コードを書いてみました。

Smultron本体のエンコード判定方法の流れはv10.4で追加された新しいメソッド、NSString stringWithContentsOfFile:usedEncoding　error:を使うように変わっていて、ここで変換してうまくいかなければguessEncodingFromData:textDataを使うように変更になっていますが、このメソッドSJIS/EUCがダメでちょっとつかえません。

string = [NSString stringWithContentsOfFile:path usedEncoding:&encoding error:&error];
if (error != nil || string == nil) {
  if (textData == nil) {
    textData = [[NSData alloc] initWithContentsOfFile:path];
  }
  encoding = [SMLText guessEncodingFromData:textData];
  if (encoding == 0 || encoding == -1) {
    encoding = [[SMLDefaults valueForKey:@"EncodingsPopUp"] integerValue];
  }
}

なので、このメソッドの使用を後回しにしてこれまでどおりguessEncodingFromData:textDataを優先してエンコードを判定、まず判定したエンコードを用いて変換してみる。それでダメな場合にこちらを使うという流れに修正しました。

GW最終日、皆が疲れ切って早く寝て時間ができたのでSmultronのローカライズをシコシコやっていたらプレビュー機能が実装されていることに気が付きました。静的なHTMLを作成する時は先日購入したばかりのSkEditを使っていたのですがこれでSmultronだけでいけるようになるのかな？skEditを使う主な理由がコード補完とスニペットなんだけれどどちらもSmultronでサポートされているし、skEditはまだ使い始めて日が浅く便利さをまだ実感していないのかも知れないけれど、いろんな作業を一つのエディタでこなす方がやっぱ効率がいいよなぁ。お金払っちゃったので捨てる訳じゃないけれど今後はますますSmultron依存度が高まりそう。

それにしてもメニュー周りのローカライズをやってみたら実にいろんな機能が盛り込まれていることを再認識して実に有意義。そのアプリを使い倒すためにあえてローカライズをしてみるってことも有効な手だてかも知れません。もひとつ、Smultronの場合はソースが公開されていますから使いませんでしたがソースの公開されていないアプリでもローカライズする方法があるって事も今回知りました。Appleのサイト Localization Toolsでそのためのツールが公開されているんです。ちょっとだけ使ってみましたが簡単にローカライズできます。このツールの存在を知ったのもこのたびのオマケでちょっと得した気分。

MacOSXでRubyコードを書くのにはSmultronを愛用しています。最初はターミナルでviしていたのですがやっぱり日本語の入力が気に入らなくて（表示だけできてもしかたないじゃん）使っていたのですが、Smultronにも少し問題があって、エンコーディングを自動判定にしておいても全然自動判定してくれないんですね。ずっとバグなのかなぁ？って疑問で昨日ドキュメントを調べてみようと思い立ちWebをのぞいてみるとソースが公開されていました。
で、ソースを見たらhtmlの"charset"とxmlの"encoding"、UTF8と16の判定しかしていませんでした。しかもこのどれかにマッチしない場合いきなりNSISOLatin1StringEncodingでencodingするんですね。ここのNSISOLatin1StringEncodingで失敗してはじめてNSString defaultCStringEncodingを使うみたい。僕の場合、MacOSXの時はUTF8でコードを書いて会社から持ち帰るコードやテスト用のデータなんかはSJISなので開くたびアラートがあがってエンコーディング設定を選択し直していたので非常に面倒です。で、変更しちゃいました。本来、自動判定しているコードに自分のよく使うShiftJISとかEUCJPとかを追加するべきなんでしょうがObjectiveCはあまりよく知らないしCocoaもちょっと自信がありませんので最後の部分でNSISOLatin1StringEncodingしているところをNSString defaultCStringEncodingに、アラート用のフラグもこのエンコードに失敗したときセットするよう変更しました。これで、めでたく会社から持ち帰りのRubyスクリプトの変更が楽になりました。あとは、会社のLINUX用スクリプトのEUCですかね。こちらはちゃんとコードを書かないとダメそうです。
しかし、２バイト文字文化圏のプログラマはかならずこういうしなくても良いような（？）苦労をさせられますね。UNICODEが登場しても解決しないというかむしろ複雑になっているような気がします...