Macintosh Developer Online (MDOnline)


2002年3月3日発行号 - Authorization Servicesのリファレンス



MDOnlineを廃刊にしないで、いろいろなところと提携して、模索しないのかという話もいただいていますが、残念ながら、いろいろやった後なのです。実は、MacWIRE(敬称略失礼します)への独占配信をした段階で、ある意味で万策尽きたため、最初にあきらめているというところがあります。メール配信数が少ないので広告はまったくダメですが、最初の目論見は、いくつかのポータル/ニュース系サイトに売り込むってことでした。だけど、大口で行けたのはMacWIREだけだったので、その後、他を見つけることはあきらめ、WIRE一本にさせてもらって、よりたくさんの費用をいただけるようにしたのです。その段階で退路を切っているので、MacWIREへの配信がなくなった昨年11月の段階が最初の危機です。もちろん、その後に購入していただいた方々も多かったので、少しは明るい兆しがあったから、半年ほどは我慢して引き付けようとしたのですが、その矢先に解雇というわけです。今年の前半がんばってからその先を考えるつもりでした。もっとも、ちゃんと売り込んだのかというご批判もあるかもしれませんが、可能な限りは努力してきたつもりです。だけど、1人で執筆から編集までする上に、さらに営業となるとおのずと限界があります。最初から分かっていたことではありますが、なんとかならないものもあります。
MacWIRE独占にしたときに、ある意味では、購入は頭打ちになることは予測はしましたが、その後に独占でなくなったときに引き付けることができなかったのも敗因でしょうね。ただ、今までやってきた感覚では、読者の人がついてくれるのってけっこう時間がかかります。半年〜1年は我慢してもいいと思うところです。MDOnlineの初期の頃の売上実績からすると、そこそこがんばって続けて存在感を保つというのがどうしても必要だったのです。だからこそ、昨年後半から地道系コンテンツにシフトしているということもあります。媒体の内容的にも、引きのあるキャッチで広告を打ったところで読者は増えないでしょうから、いかすれば「買わざるを得ない」という状況になるかを一生懸命考えたわけです。その結果、「充実したコンテンツ」という正攻法で行くしかないかと考えた次第です。ただこれを言えばグチになりますが、市場原理だとか消費者主導とかはその通りなのだけど、そうしたシステムを傘に、単に潰し合いをしているだけというのもどうかと思います。それが行き過ぎると単にストレス解消の道具にしているというか。否定するだけではなく、育てるものは育てないといけないのです。その辺り、勘違いしている人たちが、そこここにいらっしゃるのではないでしょうか。
(新居雅行 msyk@mdonline.jp


Around the System and Development》データと文字コード(1)ASCIIコード

いろいろな用語辞典系の書籍やサイトなどを当たっていると、たまに、8ビット(1バイト)の説明で、「これだけあればアルファベットの文字にすべてのコードを割り当てられる」とういような記述が見られる。嘘でははないにしても、結果論だと言えるだろう。データをコンピュータで表現し記憶するということには、さまざまな要因がからむ。一方で、少し慣れてしまうとそうした細かな事情は考えなくてもいいようになり、かえって意識しなくなってしまう。そのあたりが便利なところでもあり、すばらしいところでもあり、一方で難しくするところもでもあり、トラブルのもとになる。

それでは、0と1の世界や16進数の世界に入って見よう。データという言葉はもはや説明のしようがないくらい当たり前の概念となっているだろう。そのデータを、コンピュータで扱って処理をしたいとなると、コンピュータに合わせた手法が必要になる。歴史的には先に数値をどう扱うかといったことがあったわけだが、ここでは説明をしやすいように、文字から話をしてみたい。
文字は、人間が話していることばなどを、記述するために利用するものだ。一定の規則に従って文字は記述されるが、その実体はグラフィックスである。ただし、人間はトレーニング等によって、話し言葉を文字で記述できるようになる。また、文字を言葉で発することができるようになる。言語を表現する基礎が文字であると言えるだろう。文字については、いろいろな要素がからみあって難しくなるが、ここでは、まずはデータとして扱うという基本的な線を考えよう。

文字をデータとして扱えるようにするために、文字1つ1つに、番号を割り振るということをする。もちろん、文字の種類ごとに異なる番号を振るが、同一の文字は常に同じ番号である必要がある。特定の文字に割り当てられた数値は「文字コード」と呼ばれる。数値は、2進数で表現してもいいのだが、10進数ないしは16進数が使われるのが一般的だ。どういう数値が割り当てられるかということは、大昔はコンピュータメーカごとにまちまちだったが、基本的には統一されている。たとえば、アルファベットのAは現在では65というのがだいたいほとんどの体系で決まっていると言えるだろう。そうすれば、文字コードの数値を記憶することで、コンピュータの中で文字を記憶することができるようになる。

19世紀後半に電信の世界で開発された規格は、最初は5ビットだった。5ビットだと、00000〜11111でつまりは、32通りしかない。これだと、アルファベットだけならともかく、数字を入れると数が足りなくなる。だから、あるコードは「モード切り替え」に使い、そのコードが一発入った後は、同じコードでも違う文字と扱う。たとえば、01010はRなのだが、モードを切り替えると「1」となると言った具合だ。初期状態がどちらのモードなのかと言うことが決まっていれば後は通信できるだろう。
当初からいきなりややこしいことをしている。これは、ビット数というものが簡単に拡張できなかった時代だからではないだろうか。今だと「じゃあ6ビットにしろよ」と思うところだが、当時の通信技術は、事実上の1ビットと言えるモールス信号(これも成り立ちを論理的に考えると不思議なものだ)があったものの、その発展系として、電気信号で「5ビットもの」たくさんのデータを扱えるようになったという状態だったのではないかと思われる。
実は、5ビットはまだ使われている。ほとんど使われなくはなっているが、「テレックス」という伝送系がある。超昔的感覚なら、マスコミに備えていて世界中の情報が電送されてくるといったイメージが強いかもしれない。そのテレックスのデータ体系は、マレー符号などと呼ばれているが、基本的には一方で端末をたたき、伝送された先ではラインプリンタ、つまり逐次紙に印刷するプリンタを使う。そこで、プリンタのコントロールをしないといけないので、文字以外に「印字ヘッドを頭に戻す」「次の行へ移動する」という、機能を持つコードを定義しなければいけなかった。これが、現在のコンピュータでもCR(13H)やLF(10H)といった制御コードとして残っているのである。
コンピュータのビット数を増やすのは部品を増やすことだけであるが、通信の世界でのビット数を上げるというのは、相手がいて成り立つ通信でもあり、容易ではなかったようだ。しかしながら、コンピュータ同士の通信が仮にできても、コード体系が一致していなければ、データの交換は難しくなるわけで、1960年代前半にASCIIコードが制定された。このASCIIとは、American Standard Code for Information Interchangeである。つまり、「アメリカ」の規格なのである。だが、このASCIIコードは、その後のコンピュータでの文字処理に多大な影響を及ぼし、この時点で「日本語は不利」であることは将来に渡って約束されたと言って良いだろう。
ASCIIコードは、7ビットで文字を表現するが、すると、128通りの文字が表現できる。そのうち、00H〜1FH、7FHは制御コードとして文字ではなく何かの機能や要求を伝達・記録するためのものとして確保された。そして、20H〜7EHまでが文字として割り当てられた。ただ、20Hのスペースは機能コードとしての位置付けだったようである。これだけのバリエーションがあれば、アルファベットの大文字小文字、そして数字、各種記号はそれぞれに番号を振ることができる。もちろん、Macintoshの中でも今でもASCIIコードは生きている。

一方で、和文の伝送ということで日本では6ビットというコード体系が、通信の世界で運用されていた時期もある。最初はもちろん、漢字ではなく、カナ文をなんとかやり取りしたいというのが目標であった。5ビットだと少ないのは明白であるが、おそらく通信時間を節約したいとかいったいろいろな理由で、今風の漢字コードのような5ビットを2つ並べるという発想はしなかったに違いない。ただ、その後に漢字を含めた伝送をしたい場合に、6ビット×2という手法を用いるようにもなった。そうした方法で、約2000文字余りの漢字かな文をコード化するということが可能となったのである。これらは、紙テープを使っていた時代の話である。

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

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


Around the System and Development》データと文字コード(2)文字コード体系の問題

英語はアルファベットが26文字である。大文字小文字があるとしても、後は数字とスペースやカンマ、ピリオドなどの記号が表現できれば、おおむね、「英語という言語」に基づいた文章や会話は記述できることになる。と言ってしまえば簡単なのだが、26文字であると言ってしまったところで、1つの壁を取り除いている。ある文字があったとき、何をもって同じ文字だと区別するのだろう? たとえば、Aという文字でも、人によって、その書かれた文字は違う。丸い感じにAと書く人もいれば、崩れたAの人もいる。これら、誰が書いても、一定の枠組みにあるものは同じAという文字であるという考え方だ。もちろん、そういう考え方は全ての言語に通じる考え方だ。ところが、日本語の場合には少し事情が違う。もちろん、達筆な「あ」も、崩れた「あ」も、「あ」というひらがなであると認識する点は同じだ。だが、「斉藤」と「斎藤」などのように、人名が絡むと文字というものに対するアルファベットのような割り切った考え方はされなくなる。日本語が絡むと「同じ」という感覚はいろいろ難しいし、明らかに日本語という言語文化の問題になる。たとえば他には、AppleとAppleは同じなのか違うのか…これは現在の日本語のコンピュータの世界では避けてとおれない問題であもる。つまり、「文字」というものの考え方が、欧米と日本とではどうも根底の部分で違うようである。もっともローマン系の文字でも、ヨーロッパ系のものはアルファベット26文字にいくつかプラスαされるし、ウムラウトやアクサンといった文字にプラスアルファ的な要素を組み入れることもある。そうした考慮が可能になるのは結果的に後の時代と言うことになる。だが、最初にアルファベット26文字に押し込めた結果、後々にさまざまな問題点の起源にもなった。ただ、当時は、文字の体系に言語という要素を入れるほどの技術的な成熟がなかったとも言えるだろう。
もちろん、厳密には「A」や「あ」といった基本的な文字についての考え方と、「斎藤」「渡邊」といった人名の文字のバリエーション(異体字)の問題は区別されているのだが、最初に割り切ってしまったあたりで、何か将来を強く暗示してしまったのではないだろうか。言語をデータ化するときの最初の「文字の区別」という壁については、すっかりアメリカ的な思想でコンピュータが推移したことは否定できないだろう。
また、ASCIIコード表を実際に見てもらうと分かるのだが、文字コード41Hが「A」で、61Hが「a」である。そして、アルファベット順に並んでいる。そうなると、「大文字小文字の変換は32(20H)の加算ないしは減算でできる」と考えてしまう。もちろん、それは正しいのであるが、それで便利なのは英語をはじめとしたローマン系言語だけの話である。こうした言語的な意味での変換は日本語では、カタカナとひらがなの変換もある。こうした変換がやりやすいコード体系もある意味では便利であるが、大文字小文字変換は日本語の文字列という前提があると成り立たない。もちろん、すべての事情をコード体系に含めるということは無理なことは明白だが、コード体系はコンピュータの処理のベースになっている。それだけに、大文字小文字変換といったことのような「便法」がコード体系に入っていることも、ある意味ではソフトウエアのローカライズや国際化という側面では必ずしもプラスに働かなかったと言えるのではないだろうか。

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

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


Mac OS Xで管理者認証をしてroot権限で実行するAuthorization Services

Mac OS Xに組み込まれているAuthorization ServicesのリファレンスマニュアルがPDFの形式で公開された。また、サンプルプログラムも1つが公開されている。Mac OS Xでのソフトウエア実行では、root権限で実行したい場合が時々出てくるだろう。そのときに、管理者のアカウントとパスワードをダイアログボックスで入力した後に、root権限で実行させるなどの手法がMac OS Xでは採用されている。そのために利用するのがAuthorization Servicesである。認証を行い、特定のコマンドなどをroot権限で実行するというAPIが用意されている。サンプルコードのAuthSampleの添付書類にも、実行に関連する内容がある程度解説されているので、そちらも参照すると良いだろう。

◇Authorization Services Reference
 http://developer.apple.com/techpubs/macosx/CoreTechnologies/securityservices/authservref.pdf

◇AuthSample
 http://developer.apple.com/samplecode/Sample_Code/Security/AuthSample.htm

カテゴリ:アップルからの開発資料, Mac OS X


DVD Playerが3.1にアップデートし、ハードディスク上のオーサリング結果の再生などが追加

Mac OS XのDVD Playerアプリケーションが、Ver.3.0から3.1にアップデートされた。ソフトウエア・アップデートで更新できる。サイズは5.1MBである。ボリューム内にある「VIDEO_TS」フォルダ内のデータを再生することができるようになった。DVDオーサリングの機能と組み合わせて、オーサリング結果を手軽にプレイヤレベルで試してみることができるだろう。さらに、AppleScriptに対応した。アプリケーション自体の対応は、プレイやストップなどに加えて、各種のウインドウやパレット等の位置、状態などをスクリプトで制御できる。VIDEO_TSフォルダを開く命令もある。また、DVD Playerにスクリプトを呼び出すメニューが追加されており、すでにいくつかのサンプルのスクリプトが用意されている。DVDを単に再生するだけでなく、新しい用途の開拓ができるかもしれない。他に情報ウインドウの変更などの変更点がある。

カテゴリ:メディアプレイヤ


FutureBasic Release 6が正式にリリース

STAZ Softwareは、β版としてリリースしていたFutureBasic Release 6を正式にリリースした。2001年夏に発売されたRelease 5でCarbon対応を行ったが、新しいリリースでは全てのAppearance Managerのボタンに対応し、またフローティングウインドウなどの全てのタイプのウインドウにも対応した。価格は$169で、アップデートは$99となっている。

関連リンク:STAZ Software
カテゴリ:開発ツール


AirMac 2.0.2が公開、一部のケーブルモデムに対する不具合を対応

Mac OS X向けのAirMac 2.0.2がリリースされた。2.0.1から約1か月でのアップデートだ。変更点は、Motorolaのケーブルモデムとの互換性の解消と、パスワードセキュリティの向上となっている。なお、Ver 2.0でAirMacは128ビットの暗号化などに対応している。ソフトウエア・アップデートでの更新が可能となっている。なお、Mac OS 9対応のAirPort 2.0.2は、英語版だけが公開されている。

◇AirPort 2.0.2 for Mac OS X: Information and Download
 http://www.info.apple.com/kbnum/n120097

◇AirPort for Mac OS 9: Information and Download
 http://www.info.apple.com/kbnum/n120099

カテゴリ:ネットワーク, OS関連ソフトウエア


KBase》Mac OS Xのネットワークポートの稼働を確実に確認するには

Mac OS Xのネットワークポートについて、たとえば接続されていないEthernetポートについても、Apple System Profilerで「入」となっていたり、あるいはコマンド等での確認で、Up(稼働中)という表示が出ることについての解説が掲載されている。ポートが稼働しているかどうかを確認するには、Network Utilityでリンク状況を確認するのが確実である。

関連リンク:Mac OS X: Network "Up" Flag Does Not Accurately Indicate Working Connection
カテゴリ:Knowledge Base(旧TIL), ネットワーク


KBase》Open Firmwareのコマンド入力状態になってしまう場合の対処

Macintoshを起動しても、Open Firmwareのコマンドライン入力モードになってしまう場合の対処方法が記載されている。PRAMのリセットで通常はコマンドラインモードにはならないようになるのだが、場合によっては、Open Firmwareのプロンプトでreset-nvram、reset-allといったコマンドを打ち込んで、設定をリセットすることで対処できることもある。

関連リンク:Macintosh: Computer Starts to Text-Based Open Firmware Screen
カテゴリ:トラブルシューティング, Knowledge Base(旧TIL)