X-BASIC for iOS

長らく開発していた、iPad/iPod touch/iPhone向けBASIC言語、「X-BASIC for iOS」がようやく発売できました。で、その宣伝漫画なども作ってみたので公開。

転載可です。

 

X-BASIC for iOS

興味の湧いた方は、是非ご購入を<m(__)m>。

追伸（2013/01/01)
最新版V1.50が公開されました。
外部アプリからのファイル取り込み機能、電子メール送信機能などが追加されました。

追伸（2013/01/22)
V1.60が公開されました。
画面描画が大幅に高速化されました。その他機能も追加されています。

追伸（2013/01/24)
V1.70を審査に出しました。
バグ修正と、いくつか機能追加をしています。

追伸（2013/01/31)
V1.70は拒絶されました。
BASICプログラムを外部から入れられるようになってると、やはりはじかれるようです。
インポート機能を削除したV1.71を作成中です。

追伸（2013/02/01)
V1.71を再審査に出しました。

追伸（2013/02/08)
今後X-BASIC for iOSのサポートは専用ページに移行します。

iOSバグ写真集

iOSにはいろいろとバグがいる。
クラスライブラリの中にいて、プログラマーに要らぬ苦労をかける物もいるが、
中には見て「ちょっと楽しくなる」というか、「見つけてやったり！」と愉快になる
物もある。

そういう物の発生現場写真をいくつか紹介。

最初のは、「高温注意」のメッセージ。そもそもこれが出た状況自体が理解できない。
室温20度以下で､筐体を触っても熱い部分などなかった。充電はしていたので、
電池周辺の極狭い範囲で熱を発生していたのだろうか。充電器を外し、電源も完全に切ってしばらく放置したら直った。

「温度検知機能があるのだなあ」と思ったのだけど、それよりおかしいのは警告メッセージ。
文字が多重に表示されていて読めない。 正しくは下のようになる。

次はiCoundのバックアップメッセージの異常。
なぜか2重に表示された。しかもOK押しても動かないハングアップ状態。
このときは、リセット（HOME押しながら電源ボタン長押し)することで解消した。

なんか他にもあったような気がするけど、画面が発掘できたのはこの2つだけだった。
これからもバグハンターしていきたい(^_^;)

iOSシミュレーターの限界2；メモリアクセスの罠(第4版)

メモリアクセスにだいぶ間違いがあったので、テスト結果に基づいて再修正。

以前に「iOSシミュレーターの限界」という題で、実機とシミュレーターの違いに付いて書いたが、その後の開発で、さらに違いを見つけたので書いておく。

・CPUが違う

「当たり前」とか言われそうだが、意外にこれは重要な違いである。

私は、iOSシミュレーターはARMシミュレーター上で動いている物だと思っていたのだが、
シミュレーター上では86のコードでコンパイルされているようである。
(アセンブラコード見て気づけ！というのはなしの方向で。)

これがどんな違いをもたらすかというと、 「メモリ境界アクセスでの挙動が全く違う」のである。

ARMと86のメモリアクセスを考慮するとき、見るべきは・エンディアン；L->HなのかH->Lなのか
・バイト境界からの16bit以上アクセスは可能か
・ワード境界からの32bitアクセスは可能か
・ワード境界からの64bitアクセスは可能か
である。

多くの場合はObjective-Cが隠してくれるので気にする必要はないが、Cのライブラリを使うとき、特に構造体アクセスや、ワークエリアに可変長データを書き込む際に、要注意である。

エンディアンについては、ARMも86もリトルエンディアン、すなわちL->Hのアクセスなので、シミュレーターも実機も変わりない。

しかし、境界アクセスについては全く異なる。

86ではどのようなアドレスからでも16bit/32bit/64bitアクセスが可能である。
奇数アドレスからでも。

がしかし、ARMには制約がある。
1. バイト境界からのshort以上アクセスは不可
2. ワード境界からのlongアクセスは可能な時と不可の時がある
3. ワード境界からのdouble(long long)アクセスは不可
4. ロングワード境界からのdoubleアクセスは可能

どれも「ワード境界からなら行けるだろう」と思っていたら制約があったのでひっかかった。

わけがわからないのが2番めのlongアクセス。トラップを発生するときとしない時があり、 どの時できるの解明できていない。
したがって、現状では「できない」ものとして処理したほうがよさそう。

可変ワーク内に各種サイズのデータを書き込むようなプログラムの場合、そのアドレスによっては例外が発生してしまう。この場合はたとえば、

short *word=アドレス;
*word=0x0001;

という式の場合は、

short dt=0x0001;
memcpy(word,&dt,sizeof(word));

と書き換える必要がある。

Xcode V4.60以降には、memcpy()を、転送サイズが2バイト、4バイトまたは8バイトの倍数の時、それぞれshort、longまたはlong long単位で転送するようにインライン展開するというバグ、というかいらんお世話がいる。したがって、memcpy()では回避できないので、常にバイトまたはワード単位で転送するような関数を作って置き換える必要がある。

構造体では、メンバーはアクセスに問題ないように配置されるため、メンバー間整合のための予備バイトが挿入されることが有る。
したがって、厳密にメンバーのサイズとその配置に依存しているプログラムでは予想する動作をしない。この場合、

    #pragma pack(push,2)    構造体定義
    #pragma pack(pop)

と書くことで境界整合を制御できる。上記式は16ビット境界に配置する場合で、バイト境界にまでする場合は(push,1)とする。ただし、こうすると当然メモリアクセス処理が冗長になるので、速度低下を起こす。従って、可能なら位置やサイズへの依存をなくすようにプログラムを修正する方が良い。


拙作「X-BASIC for iOS」は言語処理部分はCで記述しており、しかも中間コードコンパイルではワークエリアへのデータ書き込みを可変長で行っているためこの問題に引っかかった。

設計上ワード境界アクセスにはしていて、シミュレーター上では全く問題なく動いていたのだが、実機上に持って行ったとたん例外が発生して動かなくなったので調べたらこうだった。

設計を変更して根本的回避ができないかも考えたが、構造があまりに複雑になりすぎるので、メモリアクセス側に対策して回避した。

ということで、「やっぱり実機での確認は欠かしたらあかん」「C言語に慣れている人ほど落とし穴にはまりやすい」という話。

----------2013/05/15更にテスト

以下のプログラムでテスト。これがまた、予想に反して全て正常動作してしまうという、結果になった。ARMの挙動、もしくはXcodeコンパイラの挙動はまったくもって不可解。

    // シミュレーター上=86上では全て問題ない
    // ARM上では？
    long work[32]; // このワークは正しい境界整合で確保されるはず
    char *bp=(char *)work;
    NSLog(@"work=%p",bp);
    unsigned long l=(unsigned long)bp;
    while (l&0xf) l++; // $~0まで移動
    bp=(char *)l;

    NSLog(@"work.0=%p",bp);
    //
    // .bからの.w
    short *wp=(short *)(bp+1);
    *wp=0x1122;
    NSLog(@"[%p]=$%x",wp,*wp);
    //
    // .wからの.l
    long *lp=(long *)(bp+2);
    *lp=0x11223344;
    NSLog(@"[%p]=$%lx",lp,*lp);
    //
    // .w境界から.llアクセス
    long long *llp=(long long *)lp;
    *llp=0x1122334455667788;
    NSLog(@"[%p]=$%llx",llp,*llp);

    // .l境界から.llアクセス
    llp=(long long *)(bp+4);
    *llp=0x1122334455667788;
    NSLog(@"[%p]=$%llx",llp,*llp);

ARM　Linuxでは例外をカーネルで受けてうまく処理しているらしいので、iOSでも「ある程度」やってくれているのかもしれない。不十分だけど。

ここも参照のこと↓
http://jr0bak.homelinux.net/~imai/linux/arm_gcc_badknowhow/arm_gcc_badknowhow-4.html#ss4.1

iOS6/568画面対応での要変更点

X-BASIC for iOSの開発を終了、さらに既存アプリも全てiOS6＆縦568(*2)対応させることで、その必要変更点がわかったので、ここに要約しておく。

ポイントだけ列記するので、詳細はドキュメント参照のこと。

（０）前に書いた画面回転処理の変更

（１）
[self presentModalViewController:viewCtrl animated:YES];
→
[self presentViewController:viewCtrl animated:YES completion:NULL];

実はiOS5から変更になっていたらしいが、iOS5では上の記述でも動いた。
でも6では動かない。

（２）
 [self dismissModalViewControllerAnimated:NO];
→
 [self dismissViewControllerAnimated:YES completion:NULL];

上の記述でもiOS6で動くが、推奨されない(審査は通る)。
iOS5にも対応するときは、バージョンを調べて 双方を切り替える必要がある。

（３）UIWebViewを使って動画再生させた後の挙動が違う
1つ前に指定した動画まで再生されてしまう。
バグだと思う。
MPMoviePlayerControllerに置き換える必要がある。

（４）View*Load/Appearの発生タイミングが違う
なんか並行動作が開始されるタイミングが変わったみたい。
このタイミングに強く依存していると誤動作する。

（５）iTunesArtworkがLarge Icon(だったと思う)という名前になって、1024*1024でしか受け付けなくなった。
 512*512のものは受け付けてくれないので、作り直しが必要。

（６）iPod5/iPhone5の縦長画面(568*2)の画面で「起動」したい時は、Default-568@2x.pngという起動画面を用意する必要がある。
(一応Xcode4上で自動作成させる方法はあるけど。)
これがないと、縦長画面機でもその中央部分だけ使って従来機と同じ画面縦幅で起動する。

568画面への対応は基本的には、UIViewのAutosizingで縦を有効にしておくだけで、自動再配置してくれる。
ちなみに、568画面で異なるUIViewController で表示させることも可能だが、iPodとiPadの切り替えはplistへの追記だけでいけるのに対し、こちらはiOS泥臭くプログラムを書くしかない、と思う。やりかたは画面幅を認識した後modalViewで表示するだけ。

拙作では「プログラマーず電卓 V2.00」で画面を変化させている。


追記。ImagePickerによるカメラ撮影時の画面は、iPod5/iPhone5でも画像部分のサイズは変わっていない。シャッターボタン周りの幅が広がっただけである（撮像素子にそんな縦長の物はないからである）。


（７）iPadでは起動画面に〜@2x.のものを用意したほうが良い。ただし、こちらは
 従来解像度のファイルのファイル名だけそれに変えたら通る。
(これもXcode4上で自動作成させる方法がある。)

以上。
結構細かく多いで手間はかかる。
私は、ビットマップで作っていたiTunesArtworkの大元データを、この際ベクトルデータのものに作りなおした。画像の用意をするのが一番面倒かも。

CGContextSetLineWidth()とCGContextSetLineDash()の関係

X-BASIC for iOS開発の過程で、CGContextSetLineWidth()とCGContextSetLineDash()の関係がどうにもわからないので調べてみた。線幅を1より大きくした時のDashの描かれ方が意図したとおりにならない。

dash=10,20の設定でlineWidth1〜10まで変化させた時、下図のようになった。


width=1の時は設定通りだが、widthが増えるとそうではなくなる。
widthは縦幅だけでなくON部分のみ横幅まで増やしてしまう。
およそではあるが、widthに＋1付きon区間が2増え、OFF区間が2減る。

最初iOSのバグかと思ったほど。
意図してこの2つを使いこなせる人間はいるのだろうか？

インターネットで色々調べてもLineWidth=1の時の描き方の例はあってもそれ以上の時は見つけられなかったので、ここに。

ちなみに、X-BASIC for iOSでは意図したとおりに描かれるようパラメーターを自動調整している。

iOSウオッチドッグの存在

今まで全く気にしてなかったが、どうもiOS中にもウォッチドッグタイマーが存在するようである。

ウォッチドッグが何であるか、詳しくは調べてもらうとして、超簡単に書けば、
暴走防止のためのタイマーである。 組み込み機器ではウォッチドッグにひかかったら、
暴走や(周辺デバイス)無反応とみなしリセットをかけるのが普通である。
(正確には、プログラム的に一定時間以内にウォッチドッグタイマーをリセットしないと、ハードウエア的にリセットがかかるようになっている。)

某所の情報によると、iOSでもWebView周りには

• Watchdog: 20秒(アプリケーション起動時など)
• DNS: 30秒
• TCP Connection: 75秒
• NSURLConnection: 60秒

というウォッチドッグがいるらしい。
"0x8badfood"という例外コードを返してくるとか。"ate bad food"ということらしい。
ateはeatの過去形。発音が8=eightと同じである。

しかし、X-BASIC for iOS開発時の調査の結果、カーネルそのものに関わるタイムアウトも存在ようである。

以下のループをシミュレーター上で実行すると、約256秒でプログラムが落ちる。
while (1) {
#if 0
    NSDate *dt=[[NSDate alloc ]initWithTimeIntervalSinceNow:0.0];
    [[NSRunLoop currentRunLoop]runUntilDate:dt];
    [dt release];
#endif
 }
これで落ちるときはEXC_???(11)(code=0,subcode=0x0)となる。

#ifの中は有効無効どちらにしても変化なし。
また、この中にどれだけ長いCの処理を書いていたとしても、落とされてしまう。
 iOS5.1/6.0とも。

しかもこれ、Xcodeにつないでいる実機上やシミュレーター上でもLeakでトレースしていると発生しない。単独の実機ではHOMEに戻ってしまうし、シミュレーター上で普通に実行している場合は、上記エラーというかトラップを発生して止まる。

2013/11/10追記
iOS7シミュレーターでは発生しない様な気がする。Xcode5で改善された？

・・・

無限ループらしきところを警告しているつもりなのかもしれないが、定期的にcurrentRunLoopに戻しても発生するから、迷惑な事この上ない。
警告ならメッセージで出すべきであって、プログラムを落とすのはやりすぎ。

普通ウォッチドッグタイマーにはそれをリセットする機構があるが、iOSにはない。
ゆえに、iOSは組み込み機器的には使えない。
(iPadやiPod touchが安いから、筐体に組み入れて組み込み機器にしたらいいじゃん、という意見を見たことがあるが、iOSはこの件を含め、組み込み機器向けじゃない。組み込み機器なめんなよってな感じ。)

    ・・・

さらなる調査で、RunLoop内では、如何様にしてもループを回し続けるのはご法度と判明。必ず落ちる。
バッググラウンド内なら回し続けても大丈夫。でもバックグラウンドからからは表示させることができない。というか、表示や入力に関わるすべてのUI要素が使えなくなる。UIWebViewに至ってはレポートまで出力して落ちる。
だが、バックグラウンドからRunLoopに通信する方法が見つからない。
（KVOは同一スレッド内で実行されるのでダメ。 Notificationもおそらく同様。)
これさえあれば何とかならんでもないのだが。

KVOの通知でフラグを立て、先のループ内で表示するという手を考えた。
while (1) {
    NSDate *dt=[[NSDate alloc ]initWithTimeIntervalSinceNow:0.1]; // 0.0はだめ
    [[NSRunLoop currentRunLoop]runUntilDate:dt]
    [dt release];
    if (flag) {
       // 表示
    }
 }
実際にこれで表示が出るには出る。が、秒１回くらいならずっとOKなのだが、秒３０回くらいの速度でしばらく回していると表示が出なくなる。どうも、NSRunLoopの行から帰ってこないようだ。RunLoopに入りっぱなしになるという感じ。バグじゃろうこれは。

→アップルのドキュメントの中にRunLoopにスレッドを接続する方法を発見。
何とかUIViewの表示だけは出来るようになった。が、問題はUIViewだけじゃなくUITextFiled等も含む全UI要素に関わるので対応が非常に大変。
→実機で落ちなけりゃそれでOKで無視することにした。

iOS6での画面対応について

iOS6での画面回転対応に非常に苦労したのでここに記録する。
iOS5以前にも対応するなら、従来の回転処理も残しながら、
新たに以下のメソッドを追加する。
細かい話は他のサイトで調べてもらうとして、ここではやり方だけ列記。

（１）基本的に、全てのUIViewControllerに以下の処理を実装する

- (NSUInteger)supportedInterfaceOrientations
// 回転を許可する方向を返す
{
#if 0　// リターン値はこの中から選択
    typedef NS_OPTIONS(NSUInteger, UIInterfaceOrientationMask) {
        UIInterfaceOrientationMaskPortrait,
        UIInterfaceOrientationMaskLandscapeLeft,
        UIInterfaceOrientationMaskLandscapeRight,
        UIInterfaceOrientationMaskPortraitUpsideDown,
        UIInterfaceOrientationMaskLandscape,
        UIInterfaceOrientationMaskAll,
        UIInterfaceOrientationMaskAllButUpsideDown,
    };
#endif
    return UIInterfaceOrientationMaskAll;
}

- (BOOL)shouldAutorotate
// 回転を許可するかどうかを返す
{
    return YES; // NOなら回転させない
}


もし個別のUIViewControllerに実装するのが面倒なら、以下の実装を入れればよい。
（各UIViewControllerの回転時にここが呼び出される。 ）

-(NSUInteger)application:(UIApplication *)application supportedInterfaceOrientationsForWindow:(UIWindow *)window
{
    return UIInterfaceOrientationMaskAll;
}



（２）[window addSubview:navigationController.view];
ではなく
    [window setRootViewController:navigationController];
に変更する。

ここまででiPadは回転するようになる。iPhone/iPod touchでもPortraitUpsideDown以外は回転するようになるが、PortraitUpsideDownだけが回転してくれない。



（３）UINavigationControllerの中にも上記回転制御を入れる。そのためにサブクラスを作る。


@interface NavigationControllerForiOS6 : UINavigationController
@end

@implementation NavigationControllerForiOS6
- (NSUInteger)supportedInterfaceOrientations
{

    return UIInterfaceOrientationMaskAll;
}

- (BOOL)shouldAutorotate
{
    return YES;
}
@end

UINavigationControllerを使っているところを全て、このNavigationControllerForiOS6
に変更する。



・・・

となる。
（３）がわかりにくいところ。（２）まででiPadまで動いてしまうので見逃しがち。

しかし、アップルはなんでこんな重要な、しかも非常によく使われている部分の仕様を変えたりするんだろうか。その上、変えてなにか良くなっったりしているとも思えないし。
まったく。

Mac Blu-ray playerのバグ

Mac上で唯一のBlu-rayディスクプレイヤーソフトであるというMacgo社の
「Mac Blu-ray Player」。

「こんな名前いいのん？」というような名前だが、早く出したもん勝ちである。
（Windows版も同じ名前なのはご愛敬？）

それはどうでもいいとして、最新版V2.8.5になっても「BDプレイヤー」としての挙動が全くなってない。「Mac Blu-ray Filer」に変名した方がいいくらい。


その出ているバグ。


＊V2.8.5に更新した後はMacの再起動が必要そう
再起動する前はDVDを読ませようとするとハングアップした。
（BDは読めた。)
Windows版では再起動は不要だった。


＊V2.8.3以降で出ているバグ
・音声選択名がおかしい
BDでのみ確認した。
Englishで日本語、無効で英語になり、Japaneseは選択できない。
最初、音声選択ができなくなっているのかと思った。
最新のV2.8.4でも治ってない。
V2.8.5では直ってた。

＊V2.8.4以降で出ているバグ
・スリープ明けに必ずハングアップする
しかもこのときディスクのアクセス権を握ったままにするので、ディスクが排出できなくなる。
OSでイジェクト命令を発効しても排出されない上に、そうしてしまうとOSからの認識もされなくなるので、強制排出でディスクを入れ替えても認識されない。結果、OSの再起動しかなくなる。
V2.8.5でも直ってない。

・音がおかしくなる
前の音の一部を引きずるような感じになる。

BD:モーレツ宇宙海賊２３～２６話の内どれか。重低音が効くところ。
V2.8.5で発生。以前のバージョンは不明。


なんでこんなにエンバグするのか、チェックが甘すぎる。

何回かバグレポート出しているけど一向に治す気配がないので、もはやそういう会社だということで。

・・・従来バージョンからずっと出ているバグ

＊ディスクによって出たり出なかったりするもの

・複数話が記録されているディスクで、途中の1話しか再生出来ないことがある
  　例)BD:Infinite Stratos 1枚目 第2話しか再生されない。
　最新版では治ってた。

・１話再生するごとに再生が止まってしまう
ファイラー的に動作しているので、各話が独立したファイルになっているディスクではこうなってしまう。
次の話を再生するためには、ディスク選択→オープン、その他のタイトルから話数選択をしなければならない。しかも音声選択していたときはそれも選択し直す必要がある。

・宣伝しか再生されない
　BD:シュタインズ・ゲート
　タイトル選択から本編を選べば本編の再生ができる。
　これもファイラー的動作によるものだろう。
　DVD版では、ちゃんとメニューから再生される。

・話の順番がおかしい
　BD:神のみぞ知るセカイII／けいおん！（第２期）
　そもそも連続再生できないが、「その他のタイトル」から選ぶと、第6話が9話目に入ってる（神のみぞ知るセカイ)。
V2.5.4.0994で治った気がする。でもまだ連続再生はできない。

・いきなり途中から再生が始まることがある
　BD:バカとテストと召喚獣
最新版では発生していない。

・字幕設定が1話毎にデフォルトに戻されてしまう

　DVDでも発生。

・全再生が終わると、メニューに戻るのではなく再生そのものが終わってしまう
・BDのメニューが表示できない
　２つはほぼ同じ意味。
　すべてのBDで発生。
　重大なバグ。

・タッチ反応エリアが狭すぎてディスクメニューがほとんど操作できないことがある
　例)DVD: MOONPHASE、タユタマ、シュタインズ・ゲート
　BDはメニューそのものが表示できないので発生し得ない。

・勝手にチャプターが飛ぶ
　例)BD:FINAL FANTASY VII
　最後最後、主人公のセリフが途中で飛んでしまう。しかもその飛び方が絶妙なのでセリフの意味が全く逆になってしまう。だめじゃん。

・チャプタージャンプが単なる時間ジャンプになってる
最新版では更にわけの解らんジャンプの仕方をする。およそ使いものにならない。

  ＊ディスクにかかわらず発生するもの
・再生中にスリープに入ると、スリープ明けに再生が継続されない事が多い


・再生中に停止すると、次回再生でファイル選択を求められる
最新版では、ここでディスクを選択すると一応前の再生位置から再生が再開される。
が、音声状態はディスクデフォルトに戻されてしまう。


・「最近の視聴履歴」というものがあるが、全く機能してない
　というか、今見ているディスクの名前しか出てこない。
　必要ないと思う。
これはメニューに出るのではなく、Dockの方に出る物だった。
正常動作している。


・AppleRemoteでの操作法が標準アプリの「DVDプレイヤー」とぜんぜん違う。
　ディスクメニューの操作がマウスで出来ないのにリモコンも使えないので操作不能に陥ってしまう。

・ディスクが排出出来ない
　DVDプレイヤーにはEjectボタンもあるし、ツールバーのEjectからでも排出可能だが、
　こいつはEjectボタンがない上に、 ツールバーのEjectを押しても排出できない。
　Finderからディスクをゴミ箱に入れてもダメ。このアプリを終了しないと排出されないのだ。排出のためにいちいちアプリ終了するなんて面倒な事この上ない。
最新版でも治ってない。
→1つ前版では、Eject出来ないだけでなく、再生中にEjectを実行し、その状態で再生を停止すると「ディスクを開く」を選んでもメディアが認識されないというバグも発生する。OSレベルで認識されていないようなので、Ejectされない事が問題の根本。
これをしてしまうとOSの再起動しか手がなくなる。極めて重大なバク。 


ディスクを取り出すだけなら、ドライブの強制排出を行うか、USBケーブルを抜き差ししてEjectボタンを有効化した方が楽だが（BDドライブは外付けしかないのでこの方法が使える）、OSから認識されない状況は変わらない。


・再生速度が微妙に変わる
これはこのソフトだけじゃなくMac上のほとんどのプレイヤーソフトいえるけど、
再生速度が微妙に速くなることがある。VLCでも発生する。

リズムがはっきりしている音楽再生時に音程が狂うのでよく分かる。
同じデータでもWindows上のプレイヤーでは発生したことがない。
Macの省電力に伴うクロック制御などが影響しているのだろうか。
Mac上での音楽再生はこの理由により、正確な意味では「実用的でない」と判断している。
→これはMacOSのバグだったようで、10.8.3で治ったような感じがする。治ってなかった。発生率は下がったけど未だ出ることがある。出たときのひどさは今までの比ではない。

・・・
特にBDでの再生があまりにもひどい。ちゅうか、DVDならMac標準の「DVDプレイヤー」でいけるのだから、ウリのBDでこの状況は「使いもんにならない」。
ディスク内に記録されているいろいろな情報の読み出しそのもの、またはその解釈が正しくないと思われる。もっとDVD/BDの仕様書を読んで正しく実装してほしい。

とりあえずもっとたくさんのディスクを再生して確認しろ。
テストディスク1枚くらいでしかやってないんじゃないか？
本当にデバッグしてるのか？
少なくとも複数枚組作品なんて見てないと思う。そうでなきゃ排出問題は絶対気づくはずだから。なんか、作品を変えるごとに違う不具合が出るんだけど。まともに操作を含む再生が出来る方が少ない。


徐々に良くなってきてはいるが、まだだめ。
フリーウエアじゃないのだから、メーカーには一日も早い全てのバグの修正をしてほしい。クリスマス対応とかしている暇があったらさっさと直せ。どうでもいいような修正でバージョン番号ばっかりあげてんじゃねぇ。


一向に改善されないので、とうとうメーカーに報告。
まあ、治らない可能性が大だけど。
→返答によると、５～６月頃にメニュー対応を初めとした大バージョンアップがあるらしい。

現状では先にも書いたとおりファイラーの域を出てないので、初心者には「全くおすすめできない」し、熟練者でも「なんとか我慢して使える」レベル。
Mac標準のDVDプレイヤーがBDにも対応してくれることを強くかつ、切に願う。

・・・2013/04/23追記
あまりに出来が悪いので、とうとう使用を中止。
来月以降にあるという大バージョンアップが出るまで使わない(当然検証もしない)。(他にモニタが用意できるなら)、専用BDプレイヤーを買った方がよほど精神衛生上良い。
そういうこと。
→ちゅうことでSONYのBDプレイヤーBDP-S190を買った。安いのにとてもいい機種。
HDMI入力に余裕がある人にはおすすめ。

・・・2012/10/24追記
とうとう新型iMacでも光学ドライブがなくなってしまった。
ということは、AppleはPCでのDVD/BD再生はもはやサポートする気が無さそうなので、
BD対応は将来的にもありえないかも。

NSTimerのバグ

NSTimerの時間指定は基本的に秒単位である。

例えば

+(NSTimer *)scheduledTimerWithTimeInterval:(NSTimeInterval)seconds target:(id)target selector:(SEL)aSelector userInfo:(id)userInfo repeats:(BOOL)repeats

のsecondsは秒単位なわけだが、０より大きく１より小さな数を指定すると１秒以下でも指定できる。

ここで、仕様書を読むと「負数を与えるとその負号を取った値を0.1ms単位として使う」と書いてある。これをそのまま理解すると例えば、-1000と指定すると1000*0.1=100msを指定したことになるはずである。

がしかし、実際にはそうはならない。
非常に短い時間でタイマーがかかってしまう。
NSTimerそのもののバグか、仕様書の間違いである。
少なくともiOS5.1まではこのとおりだ。

仕方ないので、0.??の値を使っている。

早々に正しい仕様を公開して欲しいところ。というか、仕様書通りに動くように直してくれ、Apple。

MountainLion v10.8.2での不具合ほか

iOS6にあわせてMoutainLionも10.8.2にバージョンアップされた。

V10.8.1にあったバグの修正具合を確認。update2でも変化なし。

（１）自動スリープ後、Ethernetが切れてしまうバグは修正された模様
 　　IPv6では接続できるがv4では接続できない状況になる。
　　未完全な修正だったということで。
（２）画面共有のログイン画面のスリープでスリープできないバグは修正された模様

が、また例によって新しいバグがいる。

 （３）スリープ明け後最初の受信で、メールが高確率で落ちる
メール側の対応漏れかOS側の問題かはわからないが、落ちたらあかん。

どうもスリープ明けの最初の受信メール有り時に高確率で落ちる様子。


（４）DVDプレイヤーで、話の切り替わり目で数秒〜数分が飛んでしまうことがあるバグは治っていない。
　やはりMac go社のMac Blu-ray Playerでは発生しないのでDVDプレイヤーのバグ。
（Mac Blu-ray Player自体もバグだらけなので使いものにならないが。）

（５）スリープ中にリマインダーの通知が来ると、スリープ明けに通知の「閉じる」を押しても閉じない。しかも二度と通知が操作できなくなる。
ユーティリティのアクティビティモニタで「通知センター」を選んで「プロセスを強制終了」すると一応治る。

アップルは少なくとも、まだ５倍はデバッグ要員を増やせ。

Xcode4.5およびiOS6の動作状況はこれから確認。
iOS5/5.1のバグは今回のアプリ開発でだいぶ見つけたのだけど、それらが治っているかどうか。

・・・ついでのXcode4.5の確認・・・

Xcode V4.4.1であったバグが4.5でどうなっているかの確認ちょっとだけ。

（１）Separate Assistant Editorの右側で補完候補がすぐに消えてしまうバグ
やっぱり治ってない。更に悪いことに、Google日本語入力では日本語入力がまともにできなくなった（ことえりでは未確認）。

（２）ソースファイルの改行コードが0x0d+0x0aのとき(Windowsで作っていたファイルを持ってきた時など)、エディターでDelete To End Of Lineを実行すると行末までを削除すると、次の行が接続されてしまう
これは前のバージョンから治ってない。

他は再現させるのが面倒なので省略。今のところ、ファイルの認識間違いは発生していない模様。

後バグじゃないけど、iPhone5対応のため、Launch ImageにRetina(4-inch)が追加されてる。
そのままでは黒画面画像(Default-586@2x.png)を入れられるので、何らかの置き換えが必要。私は、面倒だったので、従来のRetina(3.5-inch)の画像そのまま入れておいた。おいおい書き換えると言うことで。

NSString UIKit Additions のバグ

NSString UIKit AdditionsにあるsizeWithFont:は、文字列を指定フォントで表示した時の表示サイズを求めるメソッドとされている。


ところがこれ、横幅は正しいのだが、縦幅は正しくないことがある。
表示幅が取得値(size.height)より大きいことがあるのだ。

どのような場合にそうなるか。


指定フォントが英字フォントで、文字列に日本語を含む場合がそれに当たる。

この場合、英字部分は指定フォントが使われるが、日本語に関しては代替フォントが使われる。
例えば、標準的フォントとしてよく使われるHelveticaは英字フォントであり、実は日本語は含まない。それでも日本語も表示できるのは、この代替機能があるからだ。絵文字もこの機能によって、どのフォントでも表示できるようになっている。
（フォントが実際のところどの文字コードに相当するフォントを持っているかは、FontBookで情報を見ると分る。）

そして、殆どの場合その代替フォントのほうが大きいので、高さがそちらに合わせられる。
このため、実表示サイズが取得値と合わなくなる。

 sizeWithFontが返してくるのは指定したフォントのlineHeightであり、文字列に含まれるすべての文字を考慮した高さではないのだ。

その代替となっている日本語フォントのlineHeightを得ておけばいいと思うかもしれないが、それがそう単純ではなく、実際に表示される文字だけのフォント幅に合わせられる。
よって、表示文字列が固定ならいいが、文字列が可変なら高さも可変になる。

ということで、現在出来る回避策は、実際に表示させてみるしかない。
例えばUITextView.textに「改行付きで」代入し、その前後でcontentSize.heightの
差分を取る。これなら正確に取得できる。
ただし、.textへの代入の処理はかなり重いので、すべての行の高さを得ようと思うなら、ちょっと工夫が必要である。


アップルは英語圏なので、こういう日英文字混在の条件下ではデバッグされていないのだろう。iOS5.1でも治っていない。iOS6でどうかは未検証。


2012/09/25追記
drawAtPointの返してくる高さも同様と判明。横幅はなぜかちょっと違う。
sizeWithFontの方が小数点以下を切り上げた幅を返してきている感じ。

あと、ひょっとしたらこの問題はUITextView内に表示した時だけに発生するのかもしれない。UITextViewないならフォントの高さなんて気にしなくていいのではないかと思われるかもしれないが、外部表示との同期をかけようとすると問題になる。
それがどういうことかは、次回アプリを見てもらえばわかるかと。

2013/09/29追記
1年ぶりの追記。実はiOS7では contentSize.heightの返す値が全く意味不明になっておりこの方法が使えなくなってしまった。現状回避策は見つかってない。

Macのゴミ箱の中の消えないファイルの消し方

Macで「ゴミ箱を空にする」を実行しても消せないファイルが残ることがある。

（不要になった）TimeMachineのフォルダを削除したときなど、boot.efiというファイルにロックがかかっていて、情報からアクセス権を変更してロックを外そうにも外せず、
この状態になる。

こういう時は、Optionキーを押しながら「ゴミ箱を空にする」を実行すればよい。

たったこれだけで綺麗サッパリ消してくれる。

Xcode 4.4.1とMoutainLion V10.8.1のバグ

MacOSがMountainLionになってXcodeもV4.4.1が出た。

が、いつものごとく幾つものバグがあった。

（１）Finderからのドロップでプロジェクトにファイルを追加すると、コンパイル対象にならない

ファイルはあるはずなのにリンクが通らないという謎の現象が発生し、調査の結果がこれ。

プロジェクトのところでマウス右クリックのAdd File Toを使った場合はこうはならない。
ファイルがあるのにリンクが通らないとエラーが出る場合はこれが原因。
一旦Delete→Remove ReferenceしてからAdd File Toをやり直せばよい。

コンパイル対象でないファイルの追加にはドロップも使える(画像とか)。


（２）エディタで「Open in eparate Assistant Editor」で分割表示しているとき、
右側（Assistant Editor側）で単語補完候補がすぐ消えてしまう

入力がかなり面倒になる。
入力を続けていると、一時的に治ることもある。


（３）リアルタイムエラー検出で使うソースを間違える
例えば
proj-+--a.m,a.h
       +-lib--a.m,a.h
と同じファイル名のソース(.m/.h)が2箇所にあり、proj直下のファイルをプロジェクトにAddしていて、libはフォルダごと登録しているが、この2つのファイルは登録してないとする。
この時、本来lib下のファイルは無視されなければならないが、これがエラー検出に使われる。ソースを見ても絶対にあってるのに警告が出るときは、同一ファイルが複数箇所にないか確認したほうがいい。
これで一体どれだけ無駄なデバッグさせられたか。

同じファイル名のソースが複数出来てしまうのもバグ(に近い仕様)で、プロジェクトにAddするときコピーを作ってしまうとか、グループ間移動をした時ときに発生すると考えられる。


（４）iOS4.x用シミュレーターがないのはバグに近い仕様だと思う。
Device Debugging SupportはiOS3/4用ともまだあるが、シミュレーターは消えている。

まだあるじゃろうiOS4機。それとももう無視していいというお達しなのか？

仕方ないので、うちではVMware Fusion上にLionを構築してXcode4.3.2を復旧させた。
まさかこういう使い出があるとは。->だめ。一旦プロジェクトをXcode4.4用にしてしまうと4.3.2ではエラーが出てしまう。4.3.3にしたら通った。


（５）同名のグループが複数作れてしまう
多分、New Groupで作成したものとドラッグでフォルダごと入れた場合に出来るのだと思う。

（６）IBでClassを変更しても内部的に更新されないことがある。
サブクラスを作ってそれに変更したのに、正しく動作しない。
Cleanかけてもだめ。
結局そのViewを一旦削除して再度貼り付けたら直った。
参照するファイルを間違えるのと同じ原因ではないかと推察中。

（７）ソースコードを修正してもそれをコンパイラが認識しないことがある
発生させる一例。
１．あるメソッドの引数を変更する
２．それを使っている部分で警告が出るようになる
３．その部分を引数付きに書き換える。ただし、エラーが出るようする(間違えておく)
４．メソッドの引数を元に戻す
５．エラーが出ている行も引数を削除し、エラーが出ないようにする
としても、エラーが消えない。コンパイルしなおしてもダメ。
Cleanをかけたら消えた。
別の条件で発生したときはCleanをかけてもダメで、プロジェクトを一旦閉じて再度開いて、更に再ビルドでようやく直った。

幾つかの現象から、どうも、4.4.1にはソースの修正を正しく認識できないバグがいる模様。どうしてもおかしいと思ったら、Cleanをかけてみるか、プロジェクトを一旦閉じて再度読み直すか、IBなら一旦削除して貼り付け直しするのが吉。

（８）Settings.bundle内を編集し続けているとハングアップすることがある
2回発生したから確実かと。

（９）日本語名ファイルがGitで通らない
コミット時にエラーが出る。
コンソールからgitのコマンドを発行するとちゃんといけるので、
Xcode内のgit処理のバグだと思われる。ずっと前のバージョンから治ってない。

(10)gitの管理下にあるファイルで、編集していないのに「M」マークが付くことがある。
しかも、しばらくすると勝手に消えるという謎付き。
実害はない。

・・・

V4.3台で存在した「実機をつないでデバッグしているとき、NSLog()の中に日本語があると文字化けする」バグは「ほぼ」修正された模様。一度に大量に表示させると、まだときおり/???というUnicode形式で表示されることがある。




アップルは、毎度のことながらデバッグが全く足りてない。
この分だと、もうすぐ出てくるiOS6もすぐには対応作業しないほうが吉かも。
どうせバグだらけだろうから。
「アップルのソフトはバージョンアップがあってから入れるのが正解」。
・・・

ついでに、MountainLion(v10.8/10.8.1)のバグも少々。

・省エネルギー設定でコンピューターのスリープを「しない」にしっていしても
勝手にスリープしてしまう。スリープと言うより、アプリを終了してスタンバイ状態に
入ろうとする。

2時間くらいで落ちる気がする。
このため、一晩中処理を走らせ続けたいと思っても出来ない。
（スタンバイになる前にアプリの終了を確認しており、ここで処理が停止してしまうから。）
->これは、「使用しない状態が？分間続いたらログアウト」の設定によると判明。「セキュリティーとプライバシー」〜「一般」〜「詳細」の内にあり。


・画面共有で接続されているとき、ホスト側からスリープに入るよう操作してもスリープしない
要するに遠隔からスリープさせられないということ。だめじゃん。
10.8.1では治っていた。
やっぱり治ってない。
ログイン画面のスリープを押してもスリープしない。
その後ログインしてスリープをかけてもスリープしない。
どうも、ログイン画面でスリープを押すとおなしくなる様子。

・ネット先のドライブが応答しない時、リセットがかかってしまう
 エラーも出ずに急に再起動した。

・USBディスプレイドライバのDIsplayLinkDriver V1.8を入れているとスリープできなくなる＝スリープ時にシステムが落ちてしまう

→調査の結果、メーカーサイトの中の http://www.displaylink.com/support/ticket.php?id=331 に情報を発見。
要約すると「スリープ中にBluetoothデバイスの電源を切ると落ちる」らしい。
うちの場合、マウスがそれに相当している（手動で電源を切るだけでなく、デバイスが自動的に電源を切る場合も同様）。
これはOS X v10.8のバグで、10.8.1で修正される予定らしい。

「DisplayLinkを入れると露呈する」とある。
ということで、暫く待つしかなさそう。
→10.8.1では治っていることを確認。

・共有にしているフォルダの内容が更新されないことがある
ファイル削除したらそうなる感じなので、ファイル削除後のディレクトリエントリ作成周りにバグがいると思われる。

・Windows(7)とのファイル共有ができなくなった

今のところ、Win←Macはできているが、逆はできない。
画面共有はLion時はできなくなっていたが、MountainLionでは出来るようになったのに、
更に利用頻度が高いファイル共有ができなくなってどうするよ。
→出来る機体と出来ない機体が存在する。ということで、何かの設定だと思うのだけど、原因は不明。Mac間のファイル共有は出来てる。
→ようやく原因が判明。セキュリティとプライバシー」の設定で「ファイヤーウォール」〜「ファイヤーウォールオプション」〜「smbd」〜「外部からの接続をブロック」を「許可」に直したら治った。
こんなところいじった覚えはないので、10.8.1で勝手に設定されたと思う。

・スリープ明けにEthernetでつないでいるネットワークが切れてしまうことがある
省エネ設定の時間を過ぎて自動スリープに入った時に発生する。
ケーブルの抜き差しでは復旧せず、再起動するしかない。かなり致命的なバグ。
V10.8.3では発生頻度がかなり下がったが、まだ出る。

手動でスリープに入れたときは発生しにくいが、長時間スリープした後だと別症状で発生する。ただし、再度手動スリープして再起動すると治ったこともある。
V10.8.2で直った模様。まだ２回だけでの結果なので、もう少し様子見。
V10.8.2でも発生。IPv6では接続できているがV4では接続できない。
うちのプロバイダはｖ６を通さないのでインターネット接続ができなくなる。
WiFiでは発生しない。



・DVDプレイヤーで、話の切り替わり目で数秒〜数分が飛んでしまうことがある。
　例えば1話目が終わり、2話目が始まるとき、2話目の最初しばらくが飛ぶ。
　すべてのディスクではないが、かなり高い確率で発生する。
　SnowLeopard/Lionでは発生していなかったので、MoutainLion版のみのバグ。
　10.8.1で確認しているが、10.8.0がどうだったかは不明。
　ちなみに、Mac go社のMac Bru-ray Playerでは発生しない。
　（それはそれで他の問題が多すぎて常用しづらいのだけど。)
10.8.3では発生していないような気がする。

・フリーウエアのMacFaceが動かない
　対応版は出そうにない。まあ、必須ソフトではないけど。

・同muCommander v0.9.0が「ファイルが壊れてる」と出て実行できない(Lionでは動く)
10.8.1でも変わらず。
→「セキュリティーとプライバシー」〜ダウンロードしたアプリケーションの実行許可を「すべてのアプリケーションを許可」にすると実行可能と判明。
しかし、「実行できません」ならわかるけど「ファイルが壊れてる」というのはエラーメッセージが間違っているとしか思えない。


・ロジクールマウスの特殊ボタンが効かなくなった
ドライバーを更新しようにも、日本サイトにあるドライバはMountainLionには対応してない。米国サイト http://www.logitech.com/en-us/home で検索するとMountainLion対応の最新版がある。メッセージ英語のみになってしまうが、まあ、簡単だから問題ないかと。とありあえず日本語版が出てくるまでのつなぎはこれでOK。

・落ちる頻度はLion(10.7.4)より多い
まだ不安定な部分がある様子。
１ファイルへの多重アクセスをすると落ちやすいような気がする。
落ちるというか、無反応になってしまう。
Xcodeでタグ上に残っているファイルをDelete-Move trashとかすると一発。


とにかく、デバッグ要員を１０倍くらい増やせ、アップル。新機能より安定性重視。
特に企業に入って行く気ならそれは非常に重要(その気はないのかもしれないが)。

UTF8とSHIFT-JISの判別し方

UTF8はUTF16を算術演算して一定のコード範囲に収めるようにした文字コードである、らしい。

 実際のところ、以下の5つパターンに収束する。

   (1)c2～df+80～bf　　　                                             2バイト
   (2)e0～ef+80～bf+80～bf　　　                                 3バイト
   (3)f0～f7+80～bf +80～bf +80～bf                             4バイト
   (4)f8～fb+80～bf +80～bf +80～bf +80～bf                5バイト
   (5)fc～fd+80～bf +80～bf +80～bf +80～bf +80～bf   6バイト

UTF8データ群中では、先頭のバイトで長さがわかる。
逆に後ろからでも順次読んでいけばその文字の先頭がわかるのは、ASCIIコードは0x00～0x7eなので、重複部がないからである。

SHIFT-JISは
　　第1バイトは
　　　　（あ）0x80～0x9f
　　　　（い）0xe0～0xef (JISのどの水準までサポートするかで変化することがある)
　　第2バイトは
　　　　（A)0x40～0x7e
　　　　（B)0x80～0xfc
なので、2バイト目がASCIIと重複する部分がある。
このため、逆側からの読み出しでは正しく文字を認識できない。

また、SHIFT-JISのファイルには1バイト半角カタカナも入っている可能性も高いので、
　　0xa0(0xa1)～0xdf
のコードも存在する。UTF8中には1バイト半角カタカナはない。

そういう状況でのUTF8とSHIFT-JISの識別の仕方。

前から順に読んでいって、上記(3)～(5)のパターン、すなわち0xf0～0xfdが出てきたらUTF8で即確定できる。


逆に、（あ）が出てきたらSHIFT-JIS。UTF8では（あ）のコードはいきなり出てこないから。
0xa0～0xc1が出てきたときは、半角カタカナなのでSHIFT-JIS。
ここまでの識別でもまだわからないのが
　(1)と(2)
である。この部分の完全な判別はできない。

しかし、確率論的には推測できる。
（2）のコードはSHIFT-JISでも存在しうるが、その範囲は第二水準であり、
しかも次の1バイトが第1水準及び半角カタカナとなるため、事実上その並びが
普通のファイルで出てくることはほとんどありえないと考えていいだろう。
だからここはUTF8。

残りは（1）。
0xc2～0xdfは半角カタカナと重複するからここだけでは判別できない。

2バイト目が0x80～0x9fならSHIFT-JISの第1バイトかもしれない。
したがって、この先を更に読み続け、どちらかの文字コード範囲として矛盾が
出てきた時点でその可能性を排除する、という方法しかない。
ただし、場合によっては、UTF8とSHIFT-JISの双方でありえる可能性もある。

ということで、完全自動の文字コード認識は不可能という話。
基本自動、読めなかったら手動で、という風にしておく必要があるわけである。

X−BASIC for iOSではコード範囲を限定しているので、全自動。

UTF8とSHIFT-JISコードの特徴

UTF8<->16の変換関数を書いたので、UTF<->SHIFT-JISの変換関数も公開したいところだが、それは出来ない。

なぜかというと、出し惜しみじゃなくて、文字コードにおいて、UTFとSHIFT-JISの間に算術的相関関係がないからである。

(一部のコード範囲を除き)基本的には、１：１で変換テーブルを作るしかないのだ。

だから、変換処理を公開すると言うことはそのテーブルを公開することに等しく、
SHIFT-JISの文字数を考えたら、それは現実的ではない。高速化を考慮するなら、
交互の変換にはそれぞれ別テーブルが必要となるのでなおさらである。

実際に、全ての対応表を載せているHPがあったりするが、その表示はかなり重い。


・・・

さて、X-BASIC for iOSの開発でUTF-8の文字コード(正確には文字エンコード、らしいけど)についてかなりだいぶ理解できたと思う。
SHIFT-JISに関してはその誕生時から見ていて、X1-ｔurboからX68000、さらには
多くの組み込み機器にも処理を実装してきた。日本でもトップクラスの理解者である、と自負してたりする(^_^;)。
なもんで、両方のコードを理解した今となっては、怖いもん無しである(^_^;;)

いや、それは冗談として、 UTF-8の特徴を少し説明。

UTF-8は、JISコードに対するSHIFT-JISのような物で、UTF16に対して算術演算をかけることでコード範囲を限定している。

双方の特徴をまとめると以下のようになる。


SHIFT-JIS
・前から読まないと正しいコードが得られない
・しかしそれさえ守れば、ASCIIコードと混在可能
・ASCII用に書かれた処理の多くは、簡単な2バイトコード判定の追加するだけで流用可能
・基本的に見た目のバイト数と文字コードのバイト数が一致する
X68000の1/2角・1/4角文字など、例外も存在した（まあその範囲はそもそもJIS規定外だが)。
・第2水準漢字までが2バイトで収まる(第3水準以降は知らない)
・JISコード（＝連続コード)と算術演算による交互変換が可能なため、漢字フォントの位置を求めるのが楽。
JISコード並びの文字フォントはフリーで多数出回っているため、　無償で漢字を表示できるシステムを構築できる(読みやすさは別にして)。
・JISコード第1水準漢字は音読みで並べられているため、音読み漢字変換なら比較的簡単に実装できる



UTF8
・前からだけでなく後ろからでも正しい文字コードを得られる
・そのままASCIIコードとの混在が可能
・しかもASCII用に書かれた処理の多くがそのまま使える
・見た目のバイト数と文字コードのバイト数が一致しない
・第2水準漢字まででも3バイト以上になることがある(というか2バイトで収まる範囲は少ない)


どちらがいいというのではなく、目的さえ間違えなければ、どちらもよく考えられたコードだと言える。が、SHIFT-JISは組み込み機器で使うに有益な特徴を持ったコードで、UTF8はOS上で英語圏発祥の処理を多国語化するに良いコードだと言えよう。

UTF８については次回もう少し解説。

UTF8-16変換処理の抜け

先に発表したUTF8-16変換処理でdefine関数の部分の定義が抜けていたので公開。

#define b32(w)  (((w)&0xff000000)>>24)
#define b24(w)  (((w)&0x00ff0000)>>16)
#define b16(w)  (((w)&0x0000ff00)>> 8)
#define b8(w)  ( (w)&0x000000ff)
#define w16(h,l)   (((h)<<8 data-blogger-escaped-define="define" data-blogger-escaped-hh="hh" data-blogger-escaped-hl="hl" data-blogger-escaped-l="l" data-blogger-escaped-lh="lh" data-blogger-escaped-ll="ll" data-blogger-escaped-pre="pre" data-blogger-escaped-w16="w16" data-blogger-escaped-w24="w24" data-blogger-escaped-w32="w32">

UTF16をUTF8に変換する処理

今度はUTF16をUTF8に変換する処理。

実を言うと、UTF16はあまり使い道がない。と思う。
->とか書いてたけど、実はiOSの中の文字コードはUTF16だと判明。
characterAtIndexで返ってくるコードはUTF16である。
UTF8だと思って処理を書いてたらうまく動かないので調べたらそうだった。
(後日アップルのドキュメントを読み返したら、UTF16だとちゃんと書いてあった。
でも、あんなところに１行だけでは気が付く人少ないのでは？)
ただし、ソースコード(その中に記述する文字列)そのものはUTF8でなくてはならない。
ここは少しややこしいところ。

SHIFT-JISは、組み込み機器ではプログラムもデータも小さくなるので非常に使いやすい。
表示幅とバイト数が一致するのもいい点である。
UTF8はASCIIコードとの互換性が高く、ASCII用のプログラムを移植するに都合がいいことが、X-BASIC for iOSの開発でよくわかった。

SHIFT-JISとの変換に関してはUTF16の方が行いやすい。

ulong Utf16ToUtf8(ulong n)
// http://ja.wikipedia.org/wiki/UTF-8 参照
// Unicodeは文字コードの総称で、UTF-16やUTF-8はその表現方法の種類、である。
{
 if (n<=0x7f) return(n); // ASCII互換
 if (n<=0x7ff) {
  // 8421 8421   8421 8421
  // 110x_xxxx | 10xx_xxxx
  return  w16(             (0xc0|(n>>6))   , (0x80|(n&0x3f)) );
 }
 if (n<=0xffff) {
  // 8421 8421   8421 8421   8421 8421
  // 1110_xxxx | 10xx_xxxx | 10xx_xxxx
  return w24(       (0xe0|((n>>12)&0x0f)) , (0x80|((n>>6)&0x3f)) , (0x80|(n&0x3f)) );
  
 }
 // n<=0x1fffff
 // 8421 8421   8421 8421   8421 8421   8421 8421
 // 1111_0xxx | 10xx_xxxx | 10xx xxxx | 10xx xxxx
 return w32( (0xf0|((n>>18)&0x07)) , (0x80|((n>>12)&0x3f)) , (0x80|((n>>6)&0x3f)) , (0x80|(n&0x3f)) );
 
 // 定義上はこれ以上もあるが、実在しないので省略
} 

UTF8の文字コードをUTF16に変換する処理

しばらく忙しすぎて更新できてなかった。
理由は、どスランプとか開発作業とか。
中核の処理は動くようになったが、まだiOSへの対応については手つかず。
ずっとWindowsのCygwin上で開発してたので、Xcodeも忘れてしまった(^_^)。
まずはその思い出しから始めないと。

ということで、超久しぶりの更新は、そのプログラム中で使っている処理を１つ。
UTF8の文字コードをUTF16に変換する処理。
ただし、UTF8で32ビットの範囲に収まるコードのみ。

UTFまわりの処理はインターネットで探しても 意外と見つからない。
最近はOSや言語レベルでサポートされているようで、
Cでの記述、というかフローが正確にわかる物が無かった。
ということで、公開。

ulong Utf8ToUtf16(ulong b)
{
 if (b<=0xff) return(b); // ASCII
 if (b<=0xffff) {
  return (        (b16(b) & 0x1f) << 6) + (b8(b) & 0x3f);
 }
 return ( ((b24(b) & 0xf) << 12) + ((b16(b) & 0x3f) << 6) + (b8(b) & 0x3f) );
}