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のサポートは専用ページに移行します。

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８については次回もう少し解説。