Macintosh Developer Online (MDOnline)


2002年3月18日発行号 - いよいよExpo



一気にExpoの週が来ましたが、前にもお知らせしたように、Expoの期間中は、すみませんが、半分休刊状態にさせてください。少しは記事をお届けできるかもしれませんが、不定期になるかと思います。また、来週が最後になりますので、あと2週間ですが、がんばります。購読料の返金に関するお知らせは必ず今晩に処理をする予定です。返金の辞退をメールされた方もいらっしゃって大変恐縮です。どうしようかと思ったのですが、僭越ではございますが、辞退についても送るメールの指示にしたがって処理をしていただけませんでしょうか。250ほどのアカウントの処理をしないといけないので、手作業でははまりそうです。メールでの申し込みの自動処理をしますので、よろしくお願いします。
いきなりExpoの展示会入場券が手に入ったので、プレゼントしますが、タイミング的に微妙です。現地手渡しにしてもいいのですが、開催期間中は、私は時間的にフレキシブルではないので、すみませんが、郵送のみでお願いします。到着しなかった場合には、あきらめてください。

===============================プレゼント
「Macworld Expo展示会3日間共通券」(3枚、ファイルメーカー、MOSA提供)
――――――――――――――――――――――――――――――――――――


(新居雅行 msyk@mdonline.jp


【MacWIRE配信予定】テクニカルピットがMacworld Expoで福袋とミニコンサル

2002年3月21〜23日の日程で開催されるMacworld Conference & Expo Tokyo 2002で、WebObjects関連の開発を行うテクニカル・ピットは展示会場での出展を行い、倉橋浩一氏らがブースで同社の開発業務やコンサルテーションサービスなどをアピールする。ブースでは、同社のWebObjects教材などを特別価格で販売する。初級向けの自習用教材「Homework 1.5」を、10,000円値引きする(たとえばWebObjects 5対応のパーソナルライセンスが正価は30,000円)。4月中旬に東京で行われる予定の初級向けトレーニングについては正価が120,000円のところを優先予約価格として80,000円で受講できる。また、4月20日に発売予定のeコマース教材の「SimpleOrder 2.0 for WO 5」は正価が100,000円のところを、先行予約として80,000円で販売する。教材、サポート権、セミナー券などの入った福袋も販売する。
展示ブースでミニコンサルテーションも行い、WebObjectsの導入、教育、受託開発などに関するご相談を無償で受ける。ただし、プログラミングおよび運用に関する技術上のご質問については有償となるが、1件1000〜20000円と内容により価格は異なる。コンサルテーションは時間が決められているので、同社のWebサイトを確認してもらいたい。
同社のブースにOpenBase Japan代表の河本公夫氏を招き、OpenBaseに関するご相談も受け付ける。ブースにてOpenBase SQLを10%割り引きで購入できるチケットも配付する。

関連リンク:WebObjectsのページ
カテゴリ:WebObjects, サービス, イベント


【MacWIRE配信予定】MacworldでのWebObjects関連のセッション

いよいよ今週に迫ったMacworld Conference & Expo Tokyo 2002であるが、たくさんあるセッションの中から、WebObjects関連のものを紹介してみたい。WebObjects関連のセッションは、2月22日(金)のWeb Applicationトラックに集まっている。
11:00〜12:10には「WebObjects 5.1 アップデート -最先端の開発手法-」として、Apple ComputerのDr. Ernest Prabhakar氏および、アップルコンピュータの鷲滝薫氏によって、最新版のWebObjects 5.1関連の講演が行なわれる。また、このセッションの参加者には、WebObjectsの評価版が配付される予定となっている。
13:00〜14:10には、テクニカルピットの倉橋浩一氏による「はじめてのWebアプリケーション,はじめてのWebObjects」が開催され、WebObjectsを使った開発のメリットなどを、WebObjectsを使ったことがない開発者やあるいはユーザに向けて講演される。
14:40〜15:50にはパネルディスカッションとして「WebObjects開発・運用ノウハウ完全公開 -パネル+Q&A-」が開催される。パネラーは田畑英和(株式会社プラネットコンピュータ)、羽生章洋(有限会社エア・ロジック)、河本公夫(OpenBase Japan)、久保一人(株式会社システム情報)、小野眞司(大成建設)の各氏で、司会はMDOnlineの新居雅行が行う。システム開発のノウハウなど現場で開発をしているデベロッパーあるいはユーザとして、WebObjectsに対して語り合うと同時に、会場からの質問を受け付けて回答するという時間も設けている。このセッションでは、WebObjects 5.1他多数の豪華景品が用意される予定だ。
16:20〜17:30にはサイバー・ラボの加藤康之氏による「WebObjectsによる究極のシステム開発 -CyberFramework-」として、効率的かつ高度な開発作業が可能なパッケージであるCyberFrameworkについての紹介が行われる。なお、3月23日に開催されるMedicalトラックのうち、14:40〜16:20の「EBMのための臨床情報の活用」において、「EBM支援による電子カルテと病診連携支援による広域医療システムの構築」として加藤氏がWebObjectsを使った電子カルテシステムの紹介をする他、16:30〜17:00の「パネルディスカッション:医療情報の蓄積とEBMの実践」でも加藤氏が登壇する。

関連リンク:Macworld Conference & Expo Tokyo 2002
カテゴリ:WebObjects, イベント


Around the System and Development》データと文字コード(5)シフトJISとEUC

文字に1つ1つ番号を当てはめたのが文字コードである。それをそのまま、2進数の数値として表現して、コンピュータのメモリやあるいは記憶装置に保存すると言う方法が1つの基本的な手法であった。しかしながら、数値で例をだしたように、1バイトだと、0〜255の整数となるが、それは、1900〜2155という数値を表現するということも可能である。つまり、記録したいデータという一般的な存在があり、それを機械の中やあるいは通信においてどのように表現するかは必ずしも一致しないということに他ならない。一致していると一見簡単そうだが、それだけだと表現力に欠けると言えるだろう。
漢字を表現するためには、ASCIIコードのような7ビットのコードでは不足することで、7ビット×2のJISコードが作られたことは前回説明した。主要な漢字やひらがな、カタカナ、そして後には記号も含めて、日常的な漢字はJISコードによって番号が付けられ(コードが割り当てられ)、それは規格となりメーカーが違うとコードも違うといった問題も置きないという素地ができた。だが、JISコードの文字列の特徴は、7ビットのそれぞれを取り出したとき、ASCIIコードに対応する文字列があるので、単にデータの一部分だけを取り出したらそれは漢字コードの半分なのか、ASCIIコードの1文字なのかは判別できない。そこで、エスケープシーケンスとして、特別なコードを文字列中にはさみ、エスケープシーケンスによって「以後はJISコード」「以後はACSIIコード」といった切り替えが必要となった。
極端な例だけど、「abcあいう」という文字なら、途中に1回エスケープシーケンスを入れればいいけど、「aあbいcう」だと少なくとも5回のエスケープシーケンスが入る。だから、同じ6文字でもデータの長さ(バイト数)は大きく違ってしまうという結果になる。言い換えれば、一定のサイズのメモリを用意しても、入る文字数は一定しないということになる。これはプログラミング上ではちょっとやっかいなことでもある。
そこで、こうしたエスケープシーケンスが不要な漢字コードというものが考えられた。それが「Shift-JIS(シフトJIS)」である。CP/M-86やMS-DOSあたりから利用が始まり、Macintoshでも採用されている。今は、メモリの中、そしてディスクの中の漢字といえば、シフトJISであることが当たり前になってきているが、メモリの中についてはUnicodeへの移行が進んでいるところでもある。
このシフトJISでも、やはり漢字を扱うために8ビットより大きな桁が必要になるわけだが、コンピュータ自体が8ビットないしはその倍数での処理に対応していることから、8ビット×2、つまり2バイトのコードを利用するということになった。ASCIIコードにカナを加えたJIS X 0201では、00〜7FHはASCIIコードと基本的に同じで文字が割り当てられている。また、A0H〜DFHがカタカナとなっている。一方で、80H〜9FH、E0H〜FFHは文字が割り当てられていない。そこで、これらの範囲のコードだと、日本語文字列であるという解釈が可能となることを考えた。つまり、1バイト目は、ASCIIコードやカナに一致しないものがあると、その文字は2バイトで構成される文字であり、その次の文字と一体化してコードを算出し、そのコードに対応した文字であると解釈するわけである。結果的に、1バイト目は81H〜9FHとE0H〜FCH、2バイト目は40H〜FCH(7FHを除く)ということになった。記号類などとの混同をなるべく避けるという配慮等があったものと思われる。そして、ある一定の変換規則を適用して、シフトJISでの文字コードを求められるように工夫をした。シフトJISで新たに文字コードを割り当てたのではなく、JISコードから機械的に変換できるようにしたのである。
ところで「漢」はJISコードとして3441Hとなっているが、シフトJISでは8ABFHとなっている。そういえば、「シフトJIS規格」のようなものがあるのかと思うところだが、実際にはシフトJIS自体は規格ではなく、デファクトスタンダードなのである。したがって、規格の上では「漢」という文字はあくまで3441Hだが、各社のOSの上ではその文字を8ABFHというコードで表現しているというのがより実際に近い表現だと言えるだろう。
なお、エスケープシーケンスを否定したことから、結果的には、JIS X 0208を拡張するJIS X 0212(補助漢字)の利用は、シフトJISでは結果的にできないことにもなり、結局、なされなかった。

‥‥‥‥‥‥‥この項、続く‥‥‥‥‥‥‥[新居雅行]‥‥‥‥‥‥‥

カテゴリ:テキスト/フォント, Around the System and Development


Around the System and Development》データと文字コード(5)シフトJISとEUC(続き)

シフトJISの大きな特徴は、文字をなぞれば比較的簡単に、バイト数、つまりデータのサイズが求められることだ。日本語は2バイト、英語は1バイトということであるが、まずここで、「英語は日本語の半分のサイズ」という事実が出来上がった。そして、当時のパソコンの画面では、日本語の文字幅と、英語の文字幅が2:1でもあった。こうして、日本語文字のことを「全角」、英語の文字のことを「半角」と呼ぶ習慣が出来てしまった。
また、仮名文字でも、JISコードで規定されたカタカナやひらがなの「全角カナ」と、JIS X 0201つまり、A0H〜DFHのコードで定義された「半角カナ」の存在があった。前者は1文字で2バイト、後者は1文字で1バイトであったのである。もっとも、インターネットでは半角カナは使わない方がいいということになったこともあって、半角カナは廃れ気味ではあるものの、以前は混乱する要素としての代表格でもあった。(実はもっと混乱する要素として、半角と同じサイズの文字で、コードは全角と同じく2バイトという「2バイトの半角カナ」というものまであって、さらに混乱に拍車がかかった。)
今や高度なグラフィックス機能を備えたOSが常識となった段階では、「半角」「全角」という表現はあまり的を得てはいないと言えるだろう。また、文字コードのサイズを持って、「1バイトコード」「2バイトコード」と言ったところで、実は必ずしもそうではない。その後の規格の進化により、特にUnicodeとなると、文字を何バイトで表現するかは一定しない。つまり、割り当てられたコードとその表現は、よりはっきりと分離したと言える。いずれにしても、漢字が必ずしも2バイトとは限らなくなったのである。それでも、ベテランの人は、無意識に口をついて出てしまうのが「半角」や「2バイトコード」という言葉である。もちろん、通じればいいという考え方もできるし、今でも用語としては死んではない。だが、実情とある程度かけ離れてきていても、言葉としては残っているのである。

ここでシフトJISも、1バイト目はASCIIコードとの重なりがないようになっているが、2バイト目にはある程度の重なりがある。「記号の範囲を除く」という考えは、なかなかいい考えだったが、完全ではなかった。ASCIIコードのアルファベットの後に5BH〜5FHなど、ちょこちょことあちらこちらに記号がちりばめられている。とくに5CHにバックスラッシュ(JIS X 0201では¥)が問題となることが多かった。バックスラッシュは、MS-DOSそしてWindowsでは、ファイルのパスを記述する場合、つまりどのフォルダにファイルがあるかを記述する場合に、フォルダ名を区切ることに使われる。つまり、パスの文字列を1バイト単位で見て行くと、日本語の文字列の中にバックスラッシュがあることもありうる。アプリケーションソフトが、シフトJISコードかどうかをチェックするよりもバックスラッシュを優先的に見るようになっていれば、ファイル名やフォルダの指定がうまくいかない。えてして、90年代のアプリケーションはそうした動作がむしろ当たり前だった。
実は「表」という文字はシフトJISでは955CHだった。WindowsやMS-DOSでは英語版のソフトはたいがいは日本語がうまくいかなかったものの、Macintoshのソフトは逆に英語版でも日本語がたいがいうまく行っていた時代もあった。そこで発売された1-2-3のMacintosh版の英語版を早速使ってみたのだが、ファイルに保存しようとして「表計算テスト」という名前にしようとするとエラーになってしまったという笑い話がある。どうも、Macintosh版なのに1-2-3のコアの部分はMS-DOS的に動いていたのがこれで明白なのだが、バックスラッシュコードの問題は、ソフトウエアを必ずローカライズしないといけないという結果にもなっていた。

ASCIIコードと日本語が混在した状態でもきちんとソフトウエアが動作するということを目指したのが、EUCである。Extended Unix Codeということで、まさにUnixで使われていたものである。文字コードは、JISコードの7ビットのそれぞれのコードに対して、最上位の8つ目のビットに1を設定したものを採用する。これは、7ビットのこーどそれぞれに、80H=128を加えるのと同じことになる。たとえば、「漢」はJISコードでは3441Hであるが、EUCだとB4C1Hということになる。つまり、1バイト目も、2バイト目も、ASCIIコードにかかる文字列が存在しないことになる。
ただし、ここでA0H〜DFHまでの「半角カナ」の存在とぶつかってしまう。EUCで表現されたコードは、半角カナ領域と重複する。そこで、たとえば、半角カナの「ア」はB1Hなのだが、8EB1Hが半角カナの「ア」であるというように、コードの前に8EHなら半角カナと解釈するようにする。だから、半角カナは2バイトだ。さらに、JIS X 0212の文字は3バイトで表現するので、EUCは2バイトとは限らない。ただ、現実的にはJIS X 0208を超える範囲の文字は今時はUnicodeが原則となっているし、また半角カナは使わないのが原則とすれば、ほとんど「EUCは文字コードは2バイト」と言っていいだろう。
Unixのオープンソフト系のさまざまなソフトは、現在では「とりあえずEUCを使えば大丈夫」ということになっているが、本来は、7ビットの文字しかダメということではなく8ビットでもOKとするなどのハードルはいろいろある。しかしながら、いずれにしても、オープンソースの開発やあるいはテスティングなどに日本人を始めとしてASCIIコード以外の言語圏の人たちが加わることで、日本語などをデータとしては問題なく扱えるように活動がなされてきたことでの現在のUnixのブームがあるとも言えるわけだ。

∽∽∽∽∽∽∽この項、以上∽∽∽∽∽∽∽[新居雅行]∽∽∽∽∽∽∽

カテゴリ:テキスト/フォント, Around the System and Development


Mac OS Xで周辺機器とSCSIコマンドでやりとりする機能を解説したSDK

Mac OS X 10.1以降で利用できる「SCSI Task User Client SDK」が配付されている。SDKは、ドキュメントとサンプルコードであり、/Developer/Documentation/IOKit/scsi-commands/AH_Sam_DevInterface.pdfといったドキュメントや、/Developer/Examples/IOKit/scsi-commandsにいくつかのサンプルが組み込まれる。システムに組み込まれたSCSI Task User Clientの機能により、アプリケーションから、周辺機器に対してSCSIコマンドを送ることができるようになる。実際のバスについては、FireWireでもUSBでもATAPIでも関係はなく、ターゲットとなる周辺機器がSCSIコマンドを受け付ける形式のものであれば、この機能を使ってアプリケーションから周辺機器のコントロールができるというわけだ。CD-RWドライブとのやりとりが必要なアプリケーションなどで、SCSI Task User Clientの機能を使うことになるだろう。サンプルのアプリケーションにはCarbonのものとCocoaのものが用意されている。

関連リンク:SCSI Task User Client SDK
カテゴリ:アップルからの開発資料, 周辺機器


REALbasic 4.0.2a日本語版が公開、Officeでの日本語の文字化けを一部解消か

REALbasic 4.0.2a日本語版が公開された。Office AutomationやDatabase Plug-inの日付も更新されているので、併せてダウンロードしておこう。Microsoft Officeとの文字列のやりとりで日本語が文字化けしていた点を解消したとしている。文字列をUnicodeに変換して、WordやExcelにセットすることで、日本語の文字列も設定できるとしている。しかしながら、Office側にある文字列をREALbasic側に取り出す場合の日本語化には対応しておらず、解決向けて努力しているとしている。そして、Wordの文書に文字列を設定する簡単なサンプルが付属している。
サンプルプログラムを実際に参照してみると、REALbasicの関数を使って、MacJapanese(つまりShift-JIS)の文字列をUTF-8に変換してWordの文書中にセットしている。しかしながら、筆者が試したところでは、Wordにセットされた文字列も、やはり文字化けしていた。サンプルとして公開する限りはチェックはしているとは思われるが、何が原因で筆者の環境で文字化けするのかは定かではない。結果的に解決策になっているのかどうかは確認できなかった。なお、REALbasicのアプリケーションとプラグインフォルダを、Officeフォルダに置かないといけない点は変更はないようだ。

関連リンク:REALbasic日本語版
カテゴリ:開発ツール, REALbasic


AppleのサンプルコードのソースがWebで参照可能に

Appleが開発者向けに提供しているサンプルコードのサイトに機能が増えて、Webページ上でプログラムリストを参照できるようになった。プロジェクトファイルなどのダウンロード提供は行われているが、実行させたい場合はそれでもいいが、単にソースにどう書けばいいかということをちょっと見たいときには手軽になったと言えるだろう。各サンプルのページの上部に、ポップアップメニューが付属し、そこでソースファイルの一覧が出てくる。それを選択すると、ソースがWebページに表示される。ただし、テキストカラーは1色だけなので、開発ツールのようなカラーリングはされないが、コピー&ペーストももちろんできるので、サンプルコードを調べる作業もより手早くできるようになったことは確かだろう。

関連リンク:Sample Codes
カテゴリ:アップルからの開発資料, サービス


CarbonLib 1.6 SDKが公開

CarbonLib 1.6 SDKがADCメンバー向けに配付が開始された。ダウンロードはADCのダウンロードサイトから行うようになっている。Carbonがさらにバージョンアップすることになる。このバージョンも、Mac OS 8.6以降での利用となっている。CarbonLibは、Mac OS XとMac OS 8/9での共通のAPIインタフェースを提供するフレームワークである。

関連リンク:Carbon
カテゴリ:Carbon/CF


KBase》Base Stationのアップデートは一部のケーブルモデム向け

最初のAirMac Base Station向けのアップデートが公開されている。ComcastないしはRogersのケーブルモデムを利用したときの問題を解消するアップデートである。グラファイトカラーのBase Station向けであり、現行のスノーホワイトカラーのタイプには適用する必要はない。AirMac 2.0.2を利用しているMac OSないしはMac OS Xを利用して、Base Stationのソフトウエアを書き換える。

関連リンク:AirPort Software Base Station Update 3.84: Information and Download
カテゴリ:Knowledge Base(旧TIL), ネットワーク