« 2010年12月 | トップページ | 2011年2月 »

2011年1月

2011年1月31日 (月)

バイナリ(binary)のbase64エンコードをnkfにかけて失敗する

バイナリ(binary)のbase64エンコードをnkfにかけて失敗する

Time-stamp: "Tue Oct 12 15:29:19 JST 2010"

nkfの説明を見たらmimeを解読するとある。コマンドオプションの説明に base64の文字がある。ひょっとしたらエンコードされた圧縮ファイルがnkf でデコードできるのではと勘違いする。圧縮ファイルをbase64でエンコード したfileに対して「nkf -mB file」とすると処理はされる。しかし、出来上 がったファイルを解凍ソフトに掛けても溶けない。

理由が分からないのでネット検索する。情報は見つからない。実は見つかる 筈がない。そもそもnkfの処理対象はテキストファイルに限るのである。テ キストファイルの漢字コード(Shift-JIS、EUC、JISなど)を相互変換をする ためのツールがnkfである。その基本機能にテキストファイルをエンコー ド・デコードする御負け機能が後付けされている。

nkfがテキストファイル専用ということを忘れてバイナリファイルをnkfに掛 けてしまうという大失敗をする。毒にも薬にもならないごみファイルが出来 るだけで実害はなかった。

デコードしようとした圧縮ファイルの中身は複数個のテキストファイルであ る。それを書庫化圧縮したらバイナリファイルに変わる。この圧縮ファイル を、バイナリファイルをエンコードするソフト(wincodeなど)に掛ける。そ うしてbase64にエンコードしたファイルをnkfでデコードしようとしたので ある。

元ファイルがテキストであろうがバイナリであろうがbase64でエンコードし たものは英数字(A~Z、a~z、0123~9)及び記号のプラス(+)とスラッシュ (/)の合計64種類の文字の並びになる。デコードファイルのチョッと見だけ では元ファイルがテキストなのかバイナリなのかは分からない。

説明書きによるとnkfはISO-2022-JP (B encode) とISO-8859-1 (Q encode) のみを解読するとある。これの意味を考えることなく読み飛ばして失敗した。

そのスジの人なら当然に読み落すことはない内容だろうがnkfを初めて使う 超ド素人にはあまりにもアッサリとさりげなすぎて言っていることが理解で きない。専門的な用語ばかりの説明は分からない。マニュアルには何が出来 るとは書いてあっても何が出来ないとは書かれていない。コマンドの使用例 が一番役立つのだがオプションの箇条書き説明のみの記事が多くて首を傾げ る。

nkfに関するネット上の情報源は少ない。それらの多くはコマンドのオプ ション一覧である。誰しも憶え切れないオプションの多さにうんざりしてい るようだ。具体的な使用例は少ない。失敗談がいちばん為になるのだが、そ れはほとんどない。

バイナリファイルのbase64エンコードをnkfを使ってデコードすることは無 理と気付いたが、それを指摘する情報はなかなか見つからない。ようやくの こと次を見つける。

「nkf 1.9
MIME エンコードの機能を付けました。コード変換されてしまうので、画像 とかの単なるエンコーダとしては使えません。かなりいい加減です。 Subjectやメールアドレスを、エンコードする時に便利なように変換しま す。
で、少し言い訳します。ほとんどのアスキー文字は変換しません。だから、 これで変換したから安全なメールアドレスになるなんてことはありません。 でも、この方がSubject:行やFrom:行を変換するには、便利だろうと僕は想 像します。たまに76文字/行を越えることがあります。これは規格違反なん ですが、これは、直すのは結 構めんどう。良いアルゴリズムがあるなら採 用します。(ないんだったら、こんな規格はなくして欲しいよ)
nkf -M | nkf で、もとに戻らないのは、デコードの際にMIMEの後の改行を 無視しないのと、エンコードの時に改行を含めてエンコードしないからで す。これを、いつ無視するのかを自動的行うことは、できない規格になって いるようです。nkf -MB | nkf -mB では、ちゃんと元に戻ります。」

ascii文字一覧表ツールを使う

文字コード関係の話題を扱うときにはアスキーコードの一覧表があると便利 である。次のツールを見つけるまではその度に印刷物の表を繰るか、あるい はネット上に色々とあるアスキー文字コード表を一々ブラウザを立ち上げて 見にゆくかしている。どちらにしても面倒である。印刷物によっては文字が 小さすぎて見えにくい。幸いなことに私(60歳すぎ)は辞書が眼鏡なしで読め る。しかし周りが暗いと不自由する。

その面倒を解消するためのwindows用のツールを見つける。ツールの名前は そのものズバリの「ascii」という。ただアスキー文字コード表を一覧する だけではなく各文字を拡大表示できたりチルダなどの記号の呼び方も分か る。さらに制御文字をコピーアンドペーストでエディタの編集画面に貼り付 けられる。

ツールの画面には16進数が縦横に並べられ16×16個の桝目にアスキー文字等 が配置される。0x00~0x20までの制御文字及び0x20のスペースと0x7fの制御 文字であるdelがある。0x70~0xffまでには8ビットの特殊文字が配置され る。

各文字コードの16進表示と10進表示を知ることができる。記号などの読み方 が出るのは便利である。0x00~0x20に割り振られた制御文字をテキストエ ディタに入力することは難しい。制御文字の16進表示数に0x40を加えた16進 数に相当する英大文字をコントロールキーと一緒に押すことで入力できる場 合がある。これはテキストエディタのキー定義で決まる。

パソコンソフトにおいてコントロールキーはショートカットキーの組み合せ キーの一つとして使われることが多い。そちらが優先されるのでコントール キーを押しながらの英大文字が制御文字の入力になることは少ない。制御文 字の殆どは普通のパソコン操作で使うことがない。

asciiツールに表示される制御文字をコピーコマンドでエディタ編集画面に 貼り付けることができる。バイナリエディタを使わないでもテキストファイ ルに制御文字を入力できる。

ここにはアーカイブが置かれてない。ツールはベクターにしかない。
このページに制御文字をテキストエディタの編集画面に貼り付ける方法の解 説がある。

インターネットメールが、安全に通るのは7ビット文字である

インターネットメールとして間違いなく伝わると保証されるのは7ビットア スキー文字に限られる。それは0x00~0x7fの16×8=128文字である。イン ターネットという仕組みが考え出されたのは、アルファベット26文字で済ま せられるアメリカである。同じようなアルファベットを使うフランス語やド イツ語では英字26文字以外に文字の上に二重点とかバッククォートのような ものが付くとか文字の下側に尻尾のようなものがぶら下がるような特種文字 が使われる。

アメリカ式の文字コード(アスキー文字コード)にはフランス語やドイツ語な どで使われる特種文字は入っていない。アスキーは8ビット(1バイト)の前半 部分(0x00~0x7fで8ビットの最高位ビットが0であるもの)しか使わない。そ こで8ビットの後半部分(0x80~0xffで8ビットの最高位ビットが1であるも の)のアメリカ式で使わない領域に英語以外のヨーロッパ語で必要な特種文 字を割り当てる。日本語では8ビットの後半部分に半角片仮名を割り当て る。

インターネットをアスキー文字コード(アルファベット26文字と数字及び記 号の94文字)の電子メールが流れるとき、8ビット(1バイト)の最高位ビット は必要ない。図形文字は94個しかなく8ビットの前半部分(8ビットの最高位 ビットに1が立たない)にあたる7ビット文字でこと足りるからである。

そのためメールサーバーは7ビット文字を処理できればよいものとして作ら れたらしい。これで困ったのは英字26文字を含む94文字では足りなくて8 ビット後半部分への文字割り当てを余儀なくされているフランス・ドイツ語 などである。一台のパソコン内なら8ビット後半部分に割り当てた文字を処 理できる。それはパソコンの内部問題であるからどうにでもなる。

インターネットメールを通すという外部問題になるとアメリカ式の7ビット 文字しか正しく伝わらない仕組みに何とか工夫を凝らして合わせるしかな い。インターネット界の先頭走者(leader)の流儀であるアメリカ方式が事実 上の標準(de facto standard、デファクトはラテン語になる)である。二番 手以降はその仕様を有り難く受け入れるしかない。

8ビットの後半部分も使う電子メールをインターネットに流すときは、何ら かの変換規則を設けて7ビット文字の並びに変換(エンコード)する。それを インターネットに流し、受け取った側が元の文字並びに逆変換(デコード)す る。インターネットに入る前と抜けた後で8ビット文字に戻す操作をする。

符号化(エンコード)と復号化(デコード)の仕組みを整備すれば7ビット文字 しか通らないインターネットメールの仕様もクリアできる。インターネット メールの仕組みはそのままにしてそれを騙すような裏技を使う。その処理に 手間と時間がかかる不利はあっても使えないよりはましである。日本語のメ ールを通すにはインターネットメールの仕様がお粗末にすぎたのだとうそぶ いておこう。

しかし94文字で済む簡単があったからこそ電子メールというシステムをひね り出せたに違いない。簡単なことを手短に手軽にこなすことから仕事は始ま る。電子メールからさかのぼってゆくと機械式タイプライターに行き着く気 がする。和文タイプライターは英文タイプライターを真似したものだろう。 日本人には機械印字それも電線を通して遠隔地へ伝送(電送)する発想が湧か ない。必要な文字数が多すぎて途方にくれるだけだった。電信やテレタイプ のアイデアは生まれようがない。

電線を通して文字情報を伝える仕組みを考え出してくれた人達には脱帽する しかない。要は先人が敷いてくれたレールを走るコンテナ(7ビット文字)に 積み込めればよい。荷造りと荷解きにあたって7ビットの規格に合うように 切断し再結合する。

日本語は8ビット文字でも文字数が足りない。そこで1文字1バイトを諦めて1 文字を2バイト(以上)で表す多バイト文字方式にする。それを考える予備知 識として7ビット文字の割り当て状況を知っておく必要がある。

7ビット文字(16個×8列=128個)のうち0x00~0x1fまでの16個×2列=32個及 び0x7fのdelは制御文字になる。残り95個のうち0x20はspace(空白)文字であ る。文字として目に見える図形文字は16個×6列-2個=94個になる。図形文 字にはアルファベットの大文字と小文字(26×2=52個)と10個の数字、そし て32個の記号(!, ?など)からなる。

7ビットを使うといっても2^7=128個の文字が使えるわけではなくて目に見 える図形文字の94個に限られる。それでは不足しすぎる日本語では7ビット 文字2個相当分の数値(ビット)で漢字一文字を表す仕組みを考える。

初期のパソコンではカタカナしか使えなかったらしい。アスキーコードの後 半部分に半角片仮名を割り当てる方式がある。最高位ビットに1が立つ0x80 から0xffまでの領域のうちの16個×4列へ半角カタカナを割り当てたものに その片鱗が残っている。

0x80~0x9fまでの二列には7ビット文字の制御文字(0x00~0x1f)と対称性を 保つように別種類(拡張かな?)の制御文字がある。0xa0~0xdfの16個×4列 =64文字の部分に半角片仮名がある。8ビット文字後半部分にある0xa0は 0x20の空白と0x80だけ離れた位置にあることから空席になっているらしい。 したがって図形文字としては16個×4列-1個=63文字に半角片仮名が割り当 てられる。

片仮名としては五十音(アカサタナハマヤラワのうちヤ行はヤユヨの3音、ワ 行はワのみの1音である。これで44音になる。その他にンとヲが加わり46音 になる)、実際には46音がある。これに拗音・促音(小書き)の 「ぁぃぅぇぉゃゅょっ」の9字が加わる。以上で55文字になる。残り8字が次 の約物(記号類)になる。ちなみに英字で大文字・小文字と呼ぶものを仮名で は大書き・小書きという。

句点(マル)、開き括弧、閉じ括弧、読点(テン)、中黒(なかぐろ)、音引(お んびき)、濁点、半濁点

なお、全角仮名には濁点・半濁点の付いた一文字がある。半角片仮名では一 字(清音)に濁点・半濁点を後置することになる。圧倒的な場所不足のために 濁点・半濁点付きの仮名文字は定義できない。

ここに現われる半角仮名を見ると電報が頭に浮かぶ。濁点・半濁点を一文字 として独立の文字枠に書く流儀は電報特有であろう。そしてマルやテンはあ まり使わない。小書き(拗音・促音のぁぃぅぇぉゃゅょっ)はない(電報にお ける和文通話表、朝日のア、いろはのイのように伝える方式に小書きは定め られていない)。

(雑談)電報では句読点を見かけない。空白で区切ったと思う。ところで空白 は課金の対象となったのであろうか。wikipediaによると空白を含む字数の 課金とある。文字間の空白は一字になるが電文の最終文字以下は字数になら ない。最終文字のあとに打つ句点は無駄になる。マルより空白終わりがよ い。
括弧「」で区切られた中の文章が複数個の文の並びであるときの最終文には 句点(マル)を付けない。私は「」で囲まれた会話体とか引用文に含まれる複 数個の文の末尾すべてに律儀にマルを付けていた。あるとき最終文にはマル を付けないという習慣(常識?)を知る。さっそく手元にある本を見ると確か にそうなっている(会話体の多い小説本がよい)。なんと不注意だったのかと 恥じる。しかし今だに会話とか引用の最終文にマルを付けることが多い。マ ルを付けない閉じ括弧だけでよい。二個続きの約物(句読点などの記号類)は うっとおしい。話しはぶっ飛んでいるが電報でマルを使わない理由と一脈つ うじているかもしれない。
「内国電報は永らくカタカナのみであり、かつ電報料は濁点半濁点・空白・ 句読点を含めた字数で課金される為、文語体をカナ化しかつ濁点・半濁点を 省略するのが一般的であった、また、単語そのものを略語化した電報略号や 符丁も多用された。 KDDによる外国電報では英数字のみが使え、電報料は字 数課金であったため、内国電報と同様に電略や符丁も多用された。 電報に より送達される文章、又はその文体を電文といった。」

jisコードのメールは7ビットだからメールサーバーを正しく流れる

漢字に区点コードというものがある。最近の漢和辞書には区点コードが載っ ている。手元にある三省堂の「全訳漢辞海」には区点コードとユニコードが 入っている。漢字コードについては殆ど知識がない。その方面の本は専門的 にすぎて読む気に(買う気にも)ならない。そんな中で電子メールの文字化け について書かれた次の本を買う。

  • 神崎正英著「プロフェッショナル電子メール」2001年(株), ハルアンドワーク

文字コード専門の本は難しいし値段が高い。それほどに細かいことは必要な い。メールの文字化けについて調べているときにこの本を知る。他に類書が ないこともあり速攻で買い込む。

漢字の区点コードとは94×94=8836個の桝目に漢字を配置したものという。 全区画に割り当てがあるわけではなく空席もかなりあるらしい。ここに現わ れる94という数字はどこから出てきたものであろうか。本を丁寧に読めば ちゃんと書かれているのだが読み飛ばしてしまう。

この94個という数字はアスキーの図形文字の総数になる。7ビット文字の 0x20から0xffの16個×6列=96文字うち0x20の空白及び0xffの制御文字(del) を除いたものが94個の図形文字(目に見える、印刷できる文字)である。

0xff(127)-0x20(32)+1-2=94

アスキーの図形文字94個に相当する7ビット数値の二つ分で漢字一文字を表 すようにする。その仕組みから94×94=8836個の漢字が扱えることになる。

用意された8836桝にどう漢字を配置するか、そしてそれにjisコードをどう 割り振るかの規則を知る必要はない。パソコンに任せておけばよい。

区点コードやjisコードなどから該当漢字を知るには次のツールkanji(漢字 コード表)が便利である。その昔に本屋さんで漢字コード表の辞書みたいな 本があるのを見たことがある。一年に一回くらいしか手にしないと思う。ア ホらしくて買う気がしない。このツールをパソコンに入れておけば十分であ る。

ここにはアーカイブが置かれてない。ベクターにしかない。

Kanji(漢字コード表)ツールは漢字の区点コードやjis文字コードの数値で表 される漢字そのものを知るために使う。これとは逆に実際の漢字に割り振ら れた文字コードの数値を知るにはパソコンに備えられているme-imeやatokと いった仮名漢字変換プログラムの文字一覧表を使えばよい。

jisコードが漢字の背番号として7ビット数値2個を割り振るに対して、 shift_jisやeuc-jpは94×94=8836個(空席あり)の漢字(区点コード)に8ビッ ト数値2個を割り当てる。これら二つの方式では8ビット後半部分(最高位 ビットに1が立つもの)も使うのでメールサーバーを安全に通過できない。電 子メールにjisコードを使うのは、漢字を表す2バイトのどちらもが7ビッ ト数値(どちらのバイトも最高位に1が立っていない)のためメールサーバー を安全に通るからである。

現在のメールサーバーは8ビット文字を通す

神崎正英著「プロフェッショナル電子メール」を読むと、メールには7ビッ ト文字を使わなければいけないとある。ところが電子メールに関するネット 上の記事に、8ビット文字を通すメールサーバーがあるとの記述を見つけ る。そして現在は8ビットを通すサーバー(が多い)らしい。

経路上に7ビットしか受け付けないメールサーバーがあるかもしれないので8 ビット文字を避ける、という制限はなくなってきているらしい。2001年発行 (第1刷は1999年)の上記「プロフェッショナル電子メール」にはそのことが 書かれてない。10年後(2010年)にはすっかり事情が変わったということのよ うである。

「インターネットはアメリカで発達してきました。最近ではだいぶ様子が変 わってきていますが、8年ぐらい前まではアメリカの独占状態だったと言っ ても過言ではないでしょう。そのために、メールの取次ぎをするサーバの中 には、7ビットの文字しか通さないものがあります。7ビットの文字だけで なく8ビットの文字も通すサーバも存在し、そのようなサーバばかりを通っ てきたとしたら、8ビットのメールも文字化けは起こらないのですが、7 ビットの文字しか通さないサーバーを通過した場合は、文字化けが起こるこ とになります。
そういう7ビット文字オンリーのサーバーは、8ビットのメールに対して、 quoted-printable(latin1=iso-8859-1と呼ばれる、ASCIIにドイツ語のウ ムラウト文字など西ヨーロッパ諸国のアルファベットや記号を追加した文字 コードの場合、追加されたアルファベットは8ビットですが、その8ビット文 字を7ビット文字に変換する時によく用いられる方式)や base64(後述しま すが、画像ファイルなどバイナリファイルを7ビットに変換する方式です) と言われる方式で 7ビットに変換する作業(エンコードと言います)を施し てから、次のサーバにメールをリレーしていきます。そして、本来ならエン コードされたメールは再び 8ビットの情報に変換(「デコード」と言いま す。)されなければならないのですが、利用しているメールソフトが仮に、 日本語のテキストメールが quoted-printableやbase64で届くということを 想定していない場合は、そのまま表示してしまうことになります(最近の メールソフトでは、滅多にこういうことはありません。)。つまり、文字化 けが起こります。
とは言っても、最近のメールソフトは賢くなってきているので、メール本文 がエンコードされている場合でも、ちゃんとデコードできるようになってい ます。この辺りの事情は「8bitメールは問題ないのか?」を参照してくださ い。
一番厄介なのは、経由するMTA(Mail Transfer Agent。メールサーバ)に よっては、8ビットメールを受信した際に、最上位ビットを削ぎ落とし、無 理から7ビットにしてしまうMTAが存在するらしいことです。こうなった ら、復元がほぼ不可能になります。
そして、困ったことに、どのメールサーバーを通って、送信者の元から受信 者の元へメールが届くかは、時と場合によって違うのです。つまり、Aさん が8ビットの文字でメールをBさんにいつも送信していて、今まではうまく 行っていても、ある日突然メールが文字化けするということが有り得るので す。
こういう時は、受信者は送信者にもう一度送ってもらえばいいのですが、そ のまま送ってもらったのでは、また文字化けする可能性もあります(運良く 文字化けしないで届く可能性もあります)。やはり、7ビット文字のJISで送 り直してもらうのが確実でしょう。」
「しかしながら、皆さんの中には、メールを送信する際はISO-2022-JPを使 うという「戒め」の根拠として、「Shift_JISやEUC-JPなどの文字コードは 8bitであり、7bitしか通さない仕様のメールサーバ(Mail Transfer Agent でMTAと略されることが多いです。)を通過した場合、最上位ビットの8bit 目が落とされて文字化けメールが発生することがある」ということを聞いた ことのある方もいらっしゃると思います。8bit目が欠落したり、8bitだから とバイナリーファイル扱いで、Quoted-Printable で勝手にエンコードして しまうMTAの存在も指摘されてきました。
実際、私がUTF-8メールの送受信テスト(WindowsXP+Outlook Express6.0の デフォルト設定で実施。)を行っている場合、メールのヘッダーには 「Content-Transfer-Encoding: 8bit」と付加されます。つまり、本文は生 のUTF-8がそのまま流れます。テストした限りでは、"幸い"、8bit目が欠落 するケースには遭遇しませんでしたが、テストメールのあて先のメールアド レスによっては、「X-MIME-Autoconverted: from quoted-printable to 8bit by **.hogehohe.com ****」というヘッダーをつけているものもありま した。これは「quoted-printableから8bitにエンコードしなおしました。」 という意味ですが、Outlook Expressの場合、8bitで送られているのは間違 いありませんので、逆に言えば、8bit本文をquoted-printableエンコードし た MTA・Aが存在し、さらにMTA・Bがquoted-printableから8bitに戻してい ると考えられます。
特に、最後に紹介したスペイン語に関するサイトによると、かなり昔の話に なりますが、98年10月までは@niftyでも、JISコード(ISO- 2022-JP)以外 のメールは認められていなかったようですね。これは、今ではほとんど考え られない仕様ではあると思いますけれど、それでも8bit目をそぎ落とすMTA は間違いなく実在するようです。
私がテストした限りでは、”たまたま”成功しましたが、確かに8bitメール をサポートしていないMTAを通過した場合は厄介です。Windows版 Outlook Expressでは、UTF-8のメールを「Content-Transfer-Encoding: 8bit」でそ のまま送りますから、こうして送信されたUTF-8メールはお陀仏でしょう。」
「いずれにせよ、8ビットを通すメールサーバか、Quoted Printable をサ ポートするメールクライアントのどちらかが十分普及するまでは、スペイン での流通度とエンコーディングなしの簡便さをとるなら8ビットそのまま、 ネットワーク経路上での安全性をとるなら Quoted Printable といった選択 を、各々の必要に応じてしなければならないようです。」
「SMTP(メールの送信・伝送に使われるプロトコル)の最初の仕様では、「1 文字=7ビット」の伝送しか保証されておらず、このようなシステムで、1文 字=8ビットのコードであるシフトJISやEUC-JPでエンコードされた文字を伝 送しようとすると、8ビット目が欠落したり書き換えられたりして、文字化 けが生じるという事態になります。
それに対し、電子メールで通常使われる「ISO-2022-JP」コード、いわゆる 「JISコード」は、1文字=7ビットでエンコードされていて、SMTPの仕様に関 する問題を回避することができます。
ところが、この「ISO-2022-JP」コードには、半角カタカナにあたる文字が 定義されていません。未定義のものを無理やり使おうとすると、問題が発生 する可能性があります。
以上のような理由から、(ISO-2022-JPでエンコードする場合)電子メールで 半角カタカナを使ってはいけません。
なお、現在使われているメールサーバーは、8ビットの伝送が保証されてい るESMTPが使われることが多く、ESMTPが使われているサーバーだけを経由す るのであれば、8ビットコードでエンコードされたメールも問題なく送るこ とができますが、経路途中で7ビットのエンコードしか保証されていない SMTPを使っているサーバーを通る可能性は考えられますので、やはり7ビッ トコードでエンコードしたほうがいいでしょう。
(シフトJISやEUC-JP、UTF-8などのエンコードを使っていれば、半角カタカ ナを含む電子メールを問題なく送ることは可能です。ただし、今言ったよう に、これら8ビットコードをそのままSMTPに通すのは危険なので、8ビット コードで電子メールを書く場合、Quoted-Printableなどの方式を使って、1 文字=7ビットの形にする必要があります。)」
「Windowsで読もうがLinuxで読もうが、送り主は、JIS(SJISじゃなく、 iso-2022-jp)で送らないといけない、というのは、死語?>識者殿」
筆者の勘違いを記録されたもので、とても有益な内容になっている。

エンコード・デコードの原理

8ビット文字やバイナリデータは、7ビット図形文字の並びにエンコードしな いとメールサーバーを安全に通過させることができない。実際には7ビット 図形文字94個の全部ではなくて、そのうちの英大文字と小文字、10個の数字 及びプラスとスラッシュの64個の文字並びにエンコードする。

プラスとスラッシュ以外の記号が使われないのは、それらの記号が特種な意 味付けを伴っていることが多いからである。例えばバックスラシュはdosな 世界ではディレクトリ区切りに使われる。パイプ記号(|)はコマンドプロン プトにおいてデータを次のコマンドに渡す機能になる。記号の多くは正規表 現検索のメタ文字として使われる。そのためテキスト処理で不都合を生じる おそれがある。

エンコード方式におけるキーワードは「3:4分割」である。バイト列の先頭 から3バイトずつを取り出す。取り出した3バイトは3×8=24ビットになる。 この24ビットをその先頭から6ビットずつ4個に分解する。6桁二進数は 000000から111111までの2^6=64個になる。64個の6ビット数値に64個の文字 を対応させる。つまり長大な連続ビット列を6ビット列の並びに分解する。

(1)base64

base64では6ビットの0~63に対してA~Z, a~z, 0, 1, 2~9, +, /の順番で 割り当てる。取り出したバイト列が3バイトに満たない場合は不足バイト数 個の「=」を付ける。変換した一行は76文字で改行することが多い。かつて はメール伝達システムの制約であった1行76文字が解消された今でも、そ の約束が残っているということらしい。base64エンコードに関しては1行何 文字でも受け付ける。極端には改行なしでもよいらしい。1行文字数に依存 する変換手順はない。問題はそのような長大な一行メールが正しく流れるか どうかが分からないことにある。

(素人の素朴な疑問?)テキストファイルがバイト単位のデータ並びであるこ とは間違いない。文字コードは1文字が何バイトかの並びになる。アスキー 文字なら1バイト1文字だし、shift_jisなら2バイトで1文字になる。テキス トでない他のデータもバイト単位で記録していそうな気がする。どんなバイ ナリファイルもバイト単位になるのだろうか。最後のバイトが8ビットに満 たないということはないのだろうか。コンピュータの機械語がバイト単位だ からバイナリファイル(実行ファイル)もバイト単位だろう。初めは8ビット マシンだった。それ以前のことは分からない(知らない)。16ビットから32 ビットそして今は64ビットマシンらしい。
コンピュータ関連のファイルはすべてバイト単位なのだろう。ファイルのお 仕舞いに1バイトに満たない尻切れトンボのビット列がくっついていたら不 正なファイルと判断するのではなかろうか。そうでないとbase64エンコード の手順をファイル末尾で実行するときに困る気がする。

(2)uuencode

uuencodeでは6ビットの0~63に対して32を加えた数字に相当するアスキー コードにする(32を加えることで0x00~0x1fの制御文字を回避する)。 アスキーコードの4列分である0x20(スペース)~0x5f(アンダースコア)まで の64個を使う(英小文字は含まれない)。

エンコード文字列は60文字で改行する。そして60文字で表される元データの バイト数(60バイト(6×60ビット)×3/4=45)に32を加えた77(0x4d)に相当す る文字Mを行頭に付ける。結局エンコードファイルの一行は61文字で必らず 行頭にラージエム(M)が現われることになる。

uuencodeではエンコードにスペースが含まれる。インターネット上にある サーバーでこのスペースが消失する場合がある。そこでスペースの代りに 「`」(バッククォート)を使う方言が出来ている。

(3)quoted-printable

quoted-printableは「3:4分割」をしない。各バイトを16進数で表現し、そ の前に「=」を加えた3バイトで表す。ただし「=」以外のアスキー図形文字 及び空白とタブはそのままで変換しない。次の行にデータが続くときは、行 末に「=」を置く。これがないときは元のデータに改行があるとみなす。

quoted-printableはアスキー文字を変換しないので英文の文書は大部分がそ のまま読める。

「しかしメールの文字コードには決まりごとがあって、メールヘッダ内の日 本語はJISの文字列をBASE64にエンコードしたもの、本文はJIS、となってい るらしいです。
これらの決まりは MIME というそうです。Multipurpose Internet Mail Extensions の略だそうです。 RFC1341、RFC1342で定められ、最新版は RFC2045とRFC2046とのこと。ただ原文は英語だし厳密すぎて分かりにくいの で読んでません (^^; 」

メールヘッダーを読むなど軽い作業用としてnkfにmime解読機能が御負けと して後付けされたということである。バイナリファイルのデコードは想定外 である。そもそもnkfはテキストファイル処理用なのだからバイナリファイ ルという時点で既に対象外になる。

| | コメント (0) | トラックバック (1)

2011年1月26日 (水)

SandS(space and shift)はskkのためにある!

SandS(space and shift)はskkのためにある!

Time-stamp: "Mon Sep 27 11:27:40 JST 2010"

SandSはスペースキーをシフトキー兼用として使う方法である。スペース キーを押すと同時に他のキーを押すとシフトキーとそのキーの同時押しと解 釈する。スペースキーだけを押した場合はスペースキー本来の役目をする。 スペースキーとして働くのはスペースキーを押し込んでいるときではなくて 指先を離してキーボタンが復帰するときになる。

単純にキーを入れ換えするだけではないのでタイミングにより希望の動作に ならない場合があるようである。私は「猫まねき」か「窓使いの憂鬱」によ りSandSを便利に使っている。

仮名漢字変換としてskkを使っている。skkによる漢字入力の際は、その読み のローマ字の最初の英字を大文字で入力する。そして読みの入力が終ったな ら仮名漢字変換するためにスペースキーを押す。漢字を入力する度にその最 初にシフトキーを押す。人差し指から薬指までのどれかでローマ字の最初の 文字を押し反対の手の小指でシフトキーを押す。場合によっては片手で二つ のキーの同時押しもある。とくに右シフトキーは右手のホームポジションか ら遠いために押しにくい。右小指でシフトキーを押すときはたいてい右手指 のすべてがホームポジションから完全に離れてしまう。また、左右どっちの 小指を使うかが瞬時に決められなくてうろたえることが多い。

単語間を空白で区切る「分かち書き」の英語ではスペースキーの出番が多 い。入力する単語数とほぼ同じ個数のスペースを使う。それに対してベタ書 きを普通とする日本語文の入力ではスペースキーの出番は極端に少ない。行 頭インデント(字下げ)でスペースを使うくらいである。文章の途中に空白区 切りを使うことはない。日本語入力におけるスペースキーの使用頻度の少な さこそが仮名漢字変換の変換開始キーとしてスペースキーを使うアイデアと なったのであろう。

仮名漢字変換の設定しだいでは一文の読みを全部入力して句点(おしまいの マル)を打ったことを合図にして仮名漢字変換が行なわれたりする。誤変換 とか区切り変更が必要になろうが変換開始キーとしてのスペースキーの出番 は少なくなる。頭に浮かんだことを一気に書き付けてゆくには便利である。 誤変換を気にしないでドンドン入力してゆく。急ぎのメモ書きには変換結果 を無視する柔軟な其の場凌ぎもありと思う。変換間違いがあっても平仮名ベ タ書きよりは漢字混じりのほうが読み易い。

skkでは漢字の読みの最初の英字を大文字(シフトキーとの同時押し)とし読 みの入力終わりで変換開始のスペースキーを押す。漢字入力の度にシフト キーとスペースキーの両方を使う。通常のms-imeやatokによる仮名漢字変換 でシフトキーを使うことはほどんどない。

英文入力においてスペースキーが両手親指の担当になっているのは、スペー スキーの使用頻度が非常に多いことが理由だろう。多いからこそ両手の二本 の親指をシフト専用にしたのだろう。また、指の構造からして親指に幾つも のキーを割り当てるのは無理である。

skkは漢字入力の度に小指(シフトキー打鍵)が駆り出される。そこでシフト キーをスペースキーに肩代りさせることが出来ればとても好都合になる。 SandSとはskkのために考え出されたのではないかと思える。おそらくアイデ アの源泉は富士通のワープロであるオアシスが採用した親指シフトにあるの だろう。SandSの提唱者である木村清氏がskk使いではないことは氏のホーム ページから読み取れる。

skkをテキストエディタmeadowで使い始めてから少なくとも5年くらいは経っ ている。その間ずっと漢字入力の初めには小指でシフトキーを押してきた。 今年平成22年7月に拡張ローマ字入力azikに出会ったことが切っ掛けになり SandSを使うようになる。

最初のうちは漢字変換開始(漢字の読みの入力終わり)に使うスペースキーを 漢字読みの入力始めにも使うことに少しばかり違和感があった。慣れてしま うと猫まねきや窓使いの憂鬱を無効化しても指はSandSがあるものとして動 くようになる。思う通りに動かないことにイラついているうちに無効化した ことに気付く。

SandSでskkを使うと漢字変換開始のシフトキー(小指)が親指(SandSのスペー ス)に置き換えられるので両手指がホームポジションから離れにくくなる。 SandSはskkのためにあると言える。

「SandS はスペースキーをシフトとして使えるようにするものです。スペー スキーを押しながら他のキーを押すとシフトになり、スペースキーを単独で 入力するとスペースが入力されます。AquaSKK や ddskk などの SKK を使っ ているとシフトの入力が非常に多くなりますので、小指の疲労を劇的に軽減 させるこの SandS は必須とさえ言えます。」

SandSを実現する方法として最初に使ったのは一番簡単な仮想デバイスドラ イバによるものであった。

「仮想デバイスドライバ(フリー) OSのバージョンに合わせた仮想デバイスドライバが必要になります。これら のドライバの使用にあたっては各自の責任のもとでご使用ください。 ※これらのドライバはKAZIKの開発者萩谷洋治さんに作成していただきまし た。」

詳しい説明が次にある。これはSandS.lzhに含まれるものである。アーカイ ブをダウンロードする前にブラウザでインストールやアンインストールのや り方を確認できる。

この仮想デバイスドライバでは希望通りの動きをしないことがあるような気 がした。SandSという方法の使い心地を手っ取り早く知るには便利である。 現在は主に猫まねきを使っている。

猫まねきはスタートアップメニューに入れてある。パソコン起動時からタス クトレイに常駐する。常駐を止めて終了すれば猫まねきが働かなくなる。つ まりSandSは効かなくなる。スペースキーは文字通りのスペースを入力する ためだけ(仮名漢字変換では変換開始キーとして働く)のキーに戻る。

上記の仮想デバイスドライバによるSandSを停止させるにはSandS.vxdを c:\windows\systemディレクトリから削除すること、 c:\windows\system.iniに書き加えた記述を削除すること、そしてパソコン を再起動する。ワンクリックでSandS機能を止めることはできない。

猫まねきならそれを起動したり終了させたりするだけでSandSの有効・無効 を簡単に切り替えられる。

猫まねきはwindow vista以降では使えなくなったためにメンテナンスが終了 している(というかその必要がない)。作者ページも消滅している。詳しい解 説はウェブアーカイブに残っている。

猫まねきの単独キータブの左下にある「よくある設定」ボタンから拡張設定 タブにある「Spaceにシフトの働きを兼用させる」にチェックを入れると SandSが有効になる。SandSとは表示されてない。ヘルプに説明がある。

猫まねきを常用するようになってからパソコンがフリーズしたときにタスク マネージャーの猫まねきが反応なしになっていることに気付いたことがあ る。

猫まねきの他にSandSを手軽に使えるものとして「窓使いの憂鬱」があるこ とを知る。windows 2000以降でないと使えないという記述が多い。かつてそ ういう時期があったらしい。それ以降にデバイスドライバが作られて古い windows me以前でも使えるようになったという。

猫まねきも窓使いの憂鬱も開発は終了している。windows vista以降に対応 できないためである。ただ窓使いの憂鬱については後継のものが sourceforgeで作られている。どちらの原作者ページも閉鎖されている。 ウェブアーカイブをみるしかない。

guiな猫まねきのほうが手っ取り早く試してみるには便利である。オープン ソースで後継のある窓使いの憂鬱のほうがosを更新しても使えるかもしれな い点で心配ないといえる。猫まねきはフリーソフト化して開発は止まってい る。ベクターに猫まねきはある。窓使いの憂鬱はベクターには置いてない。 それはsourceforgeにある。

窓使いの憂鬱の作者ページはsourceforgeに移行している。詳しい解説は ウェブアーカイブに残っている。

「Q17. 「窓使いの憂鬱」は Windows95/98/ME では使えないのですか。 小林義明さんがドライバを書いてくださったので、バージョン 3.19 から使 用できるようになりました。」

窓使いの憂鬱の最新版(最終版)はmayu-3.30-xp.exe, mayu-3.28-9x.exe, mayu-3.28-nt.exeになる。

猫まねきや窓使いの憂鬱はシステム常駐で動作する。windows起動と同時に 起動するようにスタートアップに入れておく。タスクバー右端のタスクトレ イにアイコンが現われる。その右クリックメニューから終了を選べばこれら のソフトで設定したキー入れ替えは無効になり元の状態に戻る。窓使いの憂 鬱には一時停止もある。

キー入れ替えに慣れなくて鬱陶しいと感じるなら終了させればよい。気が向 いたときだけ使うならスタートアップから外しておく。その気になったとき に起動する。アンイストールするのではなく自動起動しないようにしておけ ばよい。時々使って馴染んできたら自動起動に戻すという手もある。

使い始めて少し経つと案外とキー入れ替えに慣れている。キー入れ替えソフ トを終了させたときに気がつく。キー入れ替え開始時はそれを意識している から間違えない。キー入れ替え解除しても入れ替えが身に染み付いているの で?となる。例えばcapslockとctrlの入れ替えを元に戻したことを忘れる。 思うようにいかなくて試行錯誤しているうちに、そうかキー入れ換えソフト を終わらせたんだと気付く。

私のパソコンでは猫まねきのほうが窓使いの憂鬱より相性がよいようであ る。主に猫まねきを使い予備として窓使いをそのまま残している。どちらも 時折トラブルの原因になるようである。この手ソフトの宿命なのかもしれな い。普段のSandSによる快適さに比べれば些細なことでしかない。

SandSの発案者は誰だろう

「ここで提案する『SandS』キーは、スペースキーにシフトキーの機能も持 たせたものです。 親指でスペースキーを押しながら、アルファベットキー を押すと大文字が入力できます。単にそれだけですが、使って見ると意外に 使いやすいです。最近は日本語の文章でもアルファベットが多く混じるよう になりました。特にNHK、IBM、SONYなど、アルファベットの大文字が続くよ うなケースが多いようです。SandSはこのような場合に威力を発揮します。 『SandS』はSpace and Shift の略です。これが本当の親指シフトですよ ね。」

SandS(space and shift)は拡張ローマ字入力法azikの作者である木村清氏が 提唱したものらしい。猫まねきにヘルプに次の記述がある。

「Space and Shift(SandS)機能」は、親指で押してい るスペースキーにシフトキーの機能を抱き合わせたもので、木村さんが提唱 されています。
木村さんのホームページ http://hp.vector.co.jp/authors/VA002116/
SandSを紹介したページ
http://hp.vector.co.jp/authors/VA002116/sands/ 」

SKK専用スレッド Part4にbase64エンコードで投稿されている作者不詳の sands-0.1.tar.gzがある。これはunix系で使われているsandsのソースファ イルになる。それに含まれるreadmeに次の記述がある。アーカイブそのもの は方々で引用されている。

「sands は、木村清氏が提唱する「SandS」(*1)を X 上で実現するプログラ ムです。のぞむ氏作の keyfake (*2)を元に作りました。
このプログラムを動かすには、X サーバが XTest Extention をサポートし ている必要があります。
(*1)
http://hp.vector.co.jp/authors/VA002116/sands/
(*2)
AZIK for skkfep
http://www.geocities.co.jp/SiliconValley-Bay/7584/keyfake/ 」

なお、sands-0.1.tar.gzのエンコード貼り付けの直前に次の発言がある。

「それほど大きなプログラムではないので貼っておきます。keyfake という ソフトを元にしています。X や C++ のプログラミングの経験がないので、 附加コードにえらく泥臭い処理の部分があります。
実のところ、keyfake の作者さんは SKK 遣いの上に skkfep for AZIK の パッチの作成もなさっているので、SandS についても御存じである可能性が あります。ついでに作ってもらうようにお願いした方が良かったかもしれま せん。作っていたときは、keyfake の不審の動作(キー出力がダブることが ある)の問合わせをかねて連絡するつもりでいたんですが。そのまま放置し ておりました。
動作に関しての注意点は、
・space 押したもののキーの出力止めたいと思ったときは、shift キーや control キーなどの modifier key を押せばよい(見掛けの上ではそうなる)
・space を押した状態で Tab を押すと space が出力される。オートリピー トが効くので連続して space を入力したいときに便利の2点ぐらいでしょう か。
前にも書いたように SKK で有効に使わないままでいるので、使い心地に関 しては何とも言えません。やはり、意識して訓練しないと手が覚えてくれま せんからね。
以前はそういうことがなかったのですが、最近 w3m 上でシフト状態のまま になることがあります。疑うべきは sands でしょうが、作るときに仕入れ た知識や記憶がすでに忘却の彼方にあって、何が原因が特定できていませ ん。X に詳しい方にチェックしてもらいたいところです。」

2チャンネル記事からsands-0.1.tar.gzを復元(デコード)する

2チャンネルに三回に分けて投稿されたものを一つにつなぎあわせたテキス トファイルを作る。中程に挟まる投稿番号部分は取り除いて一続きにする。 最初の----BEGIN BASE64(sands-0.1.tar.gz)----と最終行の----END BASE64----は残しておいた。このテキストファイルをwincodeでdecodeしよ うとしても拒否される。code typeがuueと判定されるようである。code typeは説明書きに従ってauto-1にしている。最初と最後にあるbase64を解釈 してくれない。

なぜ、この内容を確認したかったのかは、それに含まれるであろうreadme ファイルにsandsの発案者が書かれているかもしれないと思ったことであ る。残念ながらsands-0.1.tar.gzにはその作者すら名乗り出てない。

どうすればよいのか分からなくなりwincodeを諦めてmime base64 エンコー ド/デコードを使うことにする。投稿記事にbase64とあるし、エンコード文 字列の特徴から見てもbase64らしいことは明らかである。

同じテキストファイル(sands.b64)をmime base64 エンコード/デコードにか けるとちゃんと処理される。しかし出力されたファイルを解凍ソフトにかけ ても処理できないという。lhaユーティリティ32でも7zipでも開かない。そ こでネット検索を続けていたら作者は日本人らしいが英語表記(日本語なし) のページに次の記述があった。前後に付いているbegin行とend行を削除せよ とある。最初と最後のbase64を含む行が悪さをしていると気付く。これらを 取り込んでデコードするために不正なファイルになってしまうに違いない。 今迄の試行錯誤からしても、これら二行の情報は無視されている。悪いこと にエンコード文字列の前後に空行を入れてない。エンコードデータの区切り を正しく認識していないのである。

``According to this
http://forum.ubuntulinux.jp/viewtopic.php?pid=10976
Get the source, res 73 to 76.
http://www.bookshelf.jp/2ch/unix/1049225392.html#73
Copy from there, paste that on a Editor, and remove this two lines.
----BEGIN BASE64----(sands-0.1.tar.gz)
and
----END BASE64----
Then save the text.
Decode the BASE64 text to sands-0.1.tar.gz.''

そこでエンコード文字列以外の余分なものを消去してしまう。それ (sands.b64.txt)をmime base64エンコード/デコードで処理して出来たファイ ルを解凍ソフトにかけたら正常に解凍できるsands-0.1.tar.gzが得られた。

mime base64エンコード/デコードで出来たことがwincodeで出来ないのはど うしてだろうと気にかかる。そこで同じテキストファイルを使いwincodeに おいてdecode typeをauto-1やauto-2ではなくてbase64に決め打ち指定した ら正常に処理された。

mime base64エンコード/デコードはbase64しか扱わないのでcode typeを選 ぶという選択肢はない。wincodeは対応形式が多いので適切に選ぶ必要があ る。そして処理しようとしたエンコードファイルにはwincodeが処理するに 必要な情報がなかったのである(現物エンコード文字列からエンコード形式 を推測することはしない)。そのため仕方なくuueとしてデコードしようと試 みたが現物はbase64なので失敗に終ったということらしい。

wincodeの使い方説明にはauto-1かauto-2にしておけばソフトが自動的に塩 梅してくれるとある。これはwincodeが必要とするエンコード(デコード)方 式がメールのヘッダーのような形式で書かれておれば自動的に処理してくれ るという意味らしい。必要な情報が書き込まれていないエンコード文字列だ けのものを解析してエンコード形式を適切にセットしてくれるのではない。 2チャンネル投稿記事のエンコード文字列の前後にあるbase64という表示は 人間用であってwincodeが理解できるものではなかった。

なお、エンコード結果であるテキストファイルの最終行が行の途中で終わっ ており、その末尾にeofのあることがソフトには気に入らないらしい。それ を指摘するメッセージが出た。しかしデコード自体はできている。気持ちが 悪いのでエンコードファイルの最終行の末尾を改行にしてやりなおした。

デコードが成功するまでに色々と試行錯誤する。エンコード文字列が一行76 文字というのがある。これを揃えなければならないのだろうか(方々を探し 回っているうちに改行なしもあるという)。また改行文字がdosとunixで扱い が違うのだろうかと元ファイルを改変してみた。結局のところ不要な文字列 を除くこととエンコード形式をはっきり指定することが肝要と知る。

ファイル添付機能を備えてない(機能は備わっていても上手く復元できない) メールソフトのためにwincodeはある。文字しか入力できないメールソフト であってもwincodeでエンコードしたものをメール本文の末尾にコピーアン ドペーストすればファイル添付したことになる。着信側ではテキストファイ ルに保存したメールをwincodeに掛ければエンコード文字列部分を復号して 元の添付ファイルに復元してくれる。

現在のメーラーソフトにおいてメールへのファイル添付作業はメーラーソフ トが自動的にやってくれる。それが実はバイナリファイルをエンコードした 文字列をメール本文の末尾に付け加えることで実現していると知る機会がな い。すべてメーラーソフトが裏面で自動的に処理しておりユーザーがその動 きに触れることはない。

メールをファイル保存してテキストエディタに表示したときにエンコード文 字列を見えるとか、メーラーソフトが添付ファイルの処理に失敗したため本 文にエンコード文字列がそのまま表示されてしまうくらいしかない。

いわゆるhtmlメールが流行りはじめた頃、それに対応してないメーラーソフ トでhtmlソースがそのままメール本文として表示されて鬱陶しいということ があった。

メーラーソフトに添付ファイルのエンコード形式を選ぶ設定あるのだろう が、たぶんデフォルト設定のままで気にしない。ソフトにお任せで問題は起 こらない。添付ファイルを扱うためにエンコード/デコードの単独ソフトを 使うことはない。

パソコンにインストールしたメーラーソフトにメールをダウンロードして読 むことは少なくなっている。メールはサーバーに残したままにして、しかも 専用のメーラーソフトによるのではなくてホームページを見るブラウザを通 してメールを読み書きするウェブメールの時代になっている。従来方式で あってもメーラーソフトの性能向上によりファイル添付でトラぶることはな い。

エンコード/デコード専用ソフトを単独で使うことはなくなっている。その せいか、この手のソフトには古いもの(こなれたもの)しかない。wincodeと いう名前は知っていたがそれを使うのは今回が初めてなので解決までに二、 三日かかってしまった。

webツール(オンラインツール)でも復号できた。不要部分は取り除いたもの にしたほうがよいらしい。保存したメール本文を含めたままでも添付ファイ ルを取り出せるらしい。失敗するようなら不要部分を切り落してみることに なる。なお、オンラインツールはアクセスが集中してるとかで拒否されるこ とがある。

文字入力エリアに貼り付ける形式になる。長大なものを復号するには不向き だろう。負荷が大きいと拒否する場合がある。

wincodeとmime base64エンコード/デコードは何処にあるか

「メールの添付ファイルがなんかの拍子に復元されないことがあります。そ ういうときには、メール本文を Wincode に喰わせてやると、添付ファイル を復元してくれます。古いソフトで Win16 API ですので、Windows Vista では動きません。Windows XP では問題なく動作してます。」
「本ソフトは、MIME Base64のエンコーディング、デコーディングを行う ActiveXコントロールのサンプルプログラムです。フリーソフトですので一 般の方はご自由にお使いください。」

| | コメント (0) | トラックバック (0)

2011年1月14日 (金)

wakatigakiとbetagaki(分かち書きとベタ書き)

wakatigakiとbetagaki(分かち書きとベタ書き)

Time-stamp: "Sun Sep 19 15:52:46 JST 2010"

分かち書きに相当する英単語を探そうとする。辞書の説明のように数語で表 すものはあるが一語でそのものズバリとなる簡潔なものが見つからない。 よーく考えてみると、英語は分かち書きすることが当たり前である。単語間 をスペースで区切らないと読めない。そんな当たり前なことにワザワザ名前 を付けることはしない。何かを別なものと区別するためにはっきりと指し示 さなければならないとき、そのものに特別な呼び名を付ける。

ところで「分かち書き」の用語自体も「分ち」+「書き」の複合語である。 雌牛をcow、そして雄牛をoxと呼び分けるようなそのものズバリ表現ではな い。ネット上にあるオンライン和英辞書で次を見つける。

separating words in Japanese with spaces. e.g., in kana-only books for children

こんな長たらしいものではいけない。もっと簡潔な一語表現が欲しい。残念 ながらローマ字でwakatigakiとするしかないようである。この説明を素直に 読むと分かち書きとは日本語特有なものになる。だからこそ英語には分かち 書きに相当する特別な呼び名がないのである。当たり前すぎることは話しの 題材にもならない(必要ない)。ならば津波をそのままtunamiとするように wakatigakiを使うしかない。

分かち書きの反対語は何か?ベタ書きとなるらしい。和英辞書に次がある。

writing without spaces

これも一語ではない。日本語も「べた」+「書き」の複合語である。ローマ 字ならbetagakiになる。どうやら分かち書きもベタ書きも(日本語)ローマ字 を使うしかないようである。ここで「ベタ」を片仮名で書いているのは前に ある他の平仮名とつながるものではないことをはっきりさせるためである。 外国語だから片仮名を使っているというわけではない(「better」を語源と みる珍説もあるらしいが)。

「べた」は左官作業の壁塗りで使われる用語からきている。左官用具の鏝 (こて)を使って境目のない平面の壁面に仕上げるとき、鏝を壁面に押し付け るときの「べたべた」という音をそのまま使ったに違いない。

英語は分かち書きが当たり前なのでその表記法に特別の名前を付けない。逆 に日本語の仮名漢字交じり文はベタ書きが普通なためこちらにも特別な名前 がない。ところが日本語には漢字を使わない仮名オンリーな書き方がある。 これは分かち書きにしないと非常に読み難い。そこで分かち書きという用語 が出来た。それに対立するベタ書きも必要になるということである。

分かち書きとかベタ書きに相当する英単語にこだわったのはココログ投稿記 事のタイトルにそれを入れたいからである。ウェブログ記事のファイル名は 大抵投稿日時由来のものになる。いつ頃書いた記事であるかが分かって便利 ということらしい。日記の延長としてのブログであれば日付け由来がよいの かもしれない。自分は記事内容をファイル名から分かるようにしたいと思 う。ココログはタイトルにアルファベット文字列を混ぜ込んでおくとそれら をファイル名の一部にしてくれる。どんな名前になるかはブログ作成システ ム任せで予想がつかない。それでも日付由来の背番号方式よりはファイル内 容が分かりやすい。

歴史を遡ってみると最初から英語を分かち書きとしたものではないらしい。 (表音)文字は音声(肉声)による口承(orality、人々が口から口へと伝説など を語り伝えること)の補助手段として発明されたものである。音声で伝える のが本筋であり文字は補助手段でしかなった。音声として聞かせながらそれ を記号(文字)にして見せることで音声と文字の対応付けを憶えさせる。紙に 書かれた文字から肉声を思い出して自ら発声し自分の耳で聞く。一人で先生 と生徒を兼ねることができるようになる。

「英語は、スペースで くぎりながら表記するのが あたりまえだと おもっ ていませんか? もちろん、いまでは「あたりまえ」なのですが、これが発明 され、導入されたものだということは、あまり しられていないように感じ ます。」
「中世初頭、写本は、単語と単語の間にもパラグラフの変わり目にも一切の 分離のない「連続記法」で書かれる。それを「音読」できたのもテクストの 内容はすべて暗記されており、テクストはメモ書きとしてあるからである。 音読が修道院の読書の習慣であり、それは各々の語について聴覚的筋肉的記 憶を刻み付け、その記憶が瞑想の手がかりを与えるからである。しかし6世 紀以降、個人的な読書や他人を妨げない自分自身のための読書の必要性から 「黙読」に注意が払われるようになる。 「分かち書き」を始めるのはアイ ルランドの写字生たちで、8世紀のことである。分かち書きにより写字生 は、写本を精読するのに目の照準を定めることができるようになる。12世 紀には分かち書きによるテクスト形式が定着を見る。そして14、5世紀に は個人の黙読が普及する。分かち書きの始まりが黙読の始まりなのであ る。」
「ウォルター・オングは「今日の私たちには奇妙に感じられるのだが、書か れた資料は耳で聞くことの補助として使われていた」という。現在ではこの 逆といってよかろう。わたしは、わが国のある学会で、口頭発表を終えた若 手の研究者に、年配者が「ご苦労さま、これが印刷されるのを楽しみにして います」と声をかけた場面に遭遇したことがある。なるほど、現在では、そ して少なくともわが国の学会の常識としては、声を出して発表しただけでは 不十分で、発表原稿に加筆修正を施したうえで、印刷出版して初めて学問的 価値が認められるのだと納得した。しかし、わたしの乏しい経験でいえる限 りでは、欧米の学会ではそんなことはない。口頭発表した段階で、重要な意 味をもって受けとめられる。学問の進歩が早い分野では、発表後2,3年して 出版されたときは既に潮流から外れてしまう場合もあるのである。」

先生が暗唱している内容を肉声を通して生徒が聞く。生徒がそれを真似て暗 唱する。先生と生徒の同時作業(発声と聴取)でお互いが拘束しなくて済むよ うに音声を記号(文字)で記録する。音声が連続したものであれがそれを活写 する文字も連続したものになる。言葉の区切りは音声の抑揚として伝える。 音声と一緒(同時)に文字を見るのであるから言葉の区切りは発声の調子、い わば節回しとして伝えることになる。たぶん口伝えの節回しをベタ書き連続 文字の脇に記号として書き入れたりしたのではなかろうか。仏教の経典にそ のような記号を見る。

音声聴取の補助手段であった文字に、単語間区切りの空白を挟む分かち書き という工夫を加えることで音声を伴わないでも文字だけで内容を伝達できる ようになる。音声を伝える補助手段としての表音文字ならベタ書きでよかっ たが音声がなくなると単語間が分からないアルファベット羅列の視覚情報で は伝わりにくい。

分かち書きをしない仮名だけの文章は読み難いものであるがまったく読めな いというものではない。スラスラとはいかないが、たどたどしい読み方なら できる。それは音声や文字列を一塊として見るパターン認識があるからだろ う。連続した仮名文字列から意味のあるパターン(文字並び)を試行錯誤 (trial and error、トライアルアンドエラー方式)で探しだす。

次の平仮名べた書きは案外すんなりと読める。

「にほんごだったらひらがなだけですべてのぶんしょうがあらわされてい るのとおなじことになります。」

これが英語になると難しい。やはり使用年数の違いは大きい。べた書きの文 章から意味のある文字列のパターンを切り出すための英語のボキャブラリー に比べると日本語の語彙の蓄積数量が圧倒的に多いからであろう。

「英語は表音文字で表記しますが、"Igotoschool"とは書かず、"I go to school"と単語と単語の間に空白を置いて書きます。これが分かち書きで す。」

英語で書かれた教科書は英語という科目の時間でしか使わない。その他の科 目では日本語のものを使う。英語そのものを学ぶのではなくて例えば数学の 教科書として英語版を使うことは大学までないだろう。この差は大きい。

「それではパターン認識とは何かと言うことを、もう少し説明しましょう。 まずパターンとは何かということです。日常わたし達はパターンと言う言葉 を様々な場面で使います。わたし達は文字を読んだり、言葉を聞いてそれを 処理して判断や行動を行ないます。これは人間のパターン認識の典型的な例 です。つまり文字や音声はパターンです。もっと広く目に入って来るもの― ―現実に見える木や人の顔や机や犬などもパターンです。ステーキの匂い、 ニンニクの臭いもパターンです。チョコレートの甘さ、ラーメンのスープの 味もパターンです。松の木の肌のザラザラもシャム猫の柔らかな手触りもパ ターンです。既にお分かりのように視覚・聴覚・嗅覚・味覚・触覚と呼ばれ る五感はすべてパターンと呼ぶことが出来ます。つまり見分ける、聞き分け る、嗅ぎ分ける・・・ことが出来るものはすべてパターンというわけです。
ではパターン認識つまりパターンを“認識する”とはどういうことでしょ う。認識論そのものは哲学的対象として古くから――プラトン、アリストテ レスの時代から――扱われてきたものです。ここではそのような基本的でか つ困難な問題はさておいて、機械によるパターン認識を意識して、パターン 認識問題を形式化しておきましょう。
先に文字はパターンであると言いました。そのうち平仮名の「あ」を考えて みましょう。「あ」と書かれた文字はそれこそ無数にあります。「あ」と読 むことの出来る文字の一つ一つをパターン信号と呼びます。起こりうるすべ てのパターン信号の集合をパターンのクラスと呼びます。「あ」という文字 図形の集合、「い」という文字図形の集合、更には音声の集合、顔画像の集 合等々はすべてパターンクラスの例です。
パターン認識とはあるパターン信号が示されたとき、それがどのクラスに属 するかを決定することです。通常はパターンが決定されるべきパターンクラ スの数は有限個です。
常用漢字だと1945クラス、アルファベットだと26クラスといった具合 です。繰り返しますが、ここでのパターン認識とは、パターン信号が与えら れたとき、それがどのパターンクラスのものかを識別決定することです。か なり限定的な割り切った言い方をしましたが、このようにしても人間のパ ターン認識能力の素晴しさを説明するのにさして差し支えはありません。自 分の日常の行動を考えて、様々な例を見つけてみて下さい。」

ベタ書きな文字列から一定の意味ある文字並びのパターン(単語)を探し出す にはどれだけ多くの単語(パターン)を憶えているかの記憶力(語彙の数量)が 頼りになる。分かち書きの効能を説明するために普通の英文から単語間ス ペースを取り除いてしまった英文が実例として取り上げられている。同じよ うに日本語文のひらがなベタ書きが如何に読みにくいかの例もよくみる。

ひらがなベタ書きならそこそこ読めるに対してアルファベットべた書きな英 文は殆ど読めない。一文が数語の英文なら何とかなるが何十語もの長い文章 は察しが効かない。英語の語彙数が日本語のそれに比べて圧倒的に少ない。 文字列パターンを発見するための手掛りの持ち合せが少なすぎる。

日本語を読むとき国語辞書を引くことは殆どない。本気で辞書を引くのは学 校の宿題を片付けるときだけである。提出とか発表を義務づけられないもの はそのままにして読み進める。辞書を引かないでそのままにして読み進めて しまう。分からないのは一点(一語)だけだから読み進めるうちに何となく察 しがついてくるものである。

しかし英文読解は日本語文のようないい加減(よい加減)な解決とはいかな い。分からない単語の前後に書いてあることの理解にもう一つ自信がない。 そんな中にある分からない単語で立ち往生してしまう。一つのことが気にな り動けなくなる。とりあえず分からない単語は一つであってもそれが気にな り前後の内容に自信が持てない(疑心暗鬼になる)。

読み取りにくいベタ書き仮名文を読むときとか使い慣れない機械のマニュア ルを見るときなどには呟き(つぶやき)読みとか音読することが多い。声に出 さなくても微かに口が動いたりする。文字の習い始めは音声と文字の対応付 けを確かめながら一歩一歩ゆっくりと進む。聞いたことのない言葉に出会う と初めて文字を習ったときの習慣が蘇えるのではなかろうか。つい声に出し て読んでしまう。

石碑とか墓碑を読むときは大抵つぶやき読みする。碑面の文字を指差しなが ら、可能であれば一文字一文字を人差し指で触れながら読んでみる。摩滅し た碑面で文字欠けがあったりすると視点を左右上下に大きく動かしてみる。 碑面を照らす光線の向きで格段に読み易くなることもある。声に出しながら のトライアルアンドエラーを繰り返すうちに石碑が語りかけてくるかのよう にして判読できることを経験する。

文字が鮮明で使い慣れた言葉ばかりの文章というような迅速に読み取れる条 件が揃っておれば黙読で済ますことに無理がない。不鮮明で古い言葉や画数 の多い漢字などの現われる文章は無意識のうちに音読になるようである。読 み上げることで音声パターンと文字列パターンの対応付けを急いて造りあげ ているように思える。多くの人達が黙読であっても頭の中で音読していると いう。難しい内容であればあるほどに、思わず口が動いたり声が出たりす る。頭の中で読み上げて声なき声を聞いているような気がする。

日本語文では二種類の仮名と漢字、おまけにアルファベットも使う。文字種 が非常に多いため分かち書きしなくても有意な文字並びのパターンを切り出 すことは容易である。英語はアルファベット26文字の表音文字だけなのでベ タ書きするとアルファベットの羅列から単語の切り出しにかかるトライアル アンドエラーに必要な試行回数が極端に多くなり判読できなくなる。そのた め単語間を空白区切りにする分かち書きが欠かせない。

音楽の楽譜は音を記号(音符)で表わす。私はまったく楽譜が読めない。五線 譜の上のほうが振動数が大きいことくらしか分からない。あんなに複雑なも のを瞬時に読み取れるなんて信じられない。そういう達人の様子を見ている とハミング(鼻歌)とか指先や腕を指揮棒のように動かすとかして音響のパ ターン(旋律、メロディー)を自分で発声してそれを自分の耳で聞くというサ イクルを繰り返すようである。

「黙読こそ近代化(コト化)を象徴する行為だと思っているんです。黙読なん て、今では当たり前、音読するのは学校の授業くらいだと思ってるじゃない ですか。でも、実際は、黙読というのはとっても不自然な行為なのかもしれ ない。そうですねえ、たとえば音楽を黙読するというのと同じだと考えてみ てください。数百年後、我々人類は音楽を聴いたり、演奏したりするんじゃ なくて、楽譜を黙読するようになったらどうでしょう。信じられないですよ ねえ。でも、音読が当たり前だった時代の人々からすると、我々の黙読は、 それと同じくらい信じられない行為なのかもしれません。」

音楽でも文章でも音響や音声の一塊であるパターンが一曲、一文のなかに たった一回しか現われないということはない。もしそうであれば雑音でしか ない。何度も繰り返されるものには意味を持たせることができる。重要な用 語ほど何回も繰り返される。耳に心地良い音楽は聞き覚えのあるメロディー が少しずつ変化しながら何度も繰り返して現われる。我々はこうした特徴の ある一連の音声や音楽を文字や音符として記録する。一文字一文字、一音符 一音符は短かい音で意味のない雑音でしかない。複数個の文字や音符の組み 合せなら意味やメロディーを持つようになる。

ベタ書き仮名文は意味を持つ綴り字パターンを見つけだすための区切り個所 を探すトライアルアンドエラーにとても時間がかかる。文字並びを発音する ことはパターンを探す手助けになる。書いてある内容が理解できないときは 声にして読み上げることを無意識のうちにする。

分かち書きを採用すると空白で区切られた一塊の文字列(単語)は切り離すこ とができなくなる。問題は行の終わりにその一塊が収まりきらないときに起 こる。一塊を途中でぶつ切りにして前行の末尾と次行の先頭に配置したとき それら二つが本来は一つの単語なのか独立な二つ単語の並びなのかが分から なくなる。

手書きやタイプライターなら行末に収容しきれない単語は次行に送ってしま う。そのため各行の行末が凸凹で一直線には揃わない。活版印刷の書籍であ れば生き別れて行末になった前半の綴りにハイフンを後置することで次行先 頭が同一単語の後半であることを伝えるようにする(ハイフネーション処 理)。手書きやタイプライターでは行末のガタガタを止むなしとする人達も 書籍では綺麗に揃った行末にこだわるようである。

英語のhtmlなホームページを見るとハイフネーション処理はされていないこ とに気付く。画面幅とフォントサイズにより一行に収容できる文字数が変わ るためにハイフネーションしてもディスプレイ次第で最終的にどう表示され るか分からない。そのためhtmlの行末はタイプライターのスタイルでガタガ タの凸凹でハイフネーションはない。

分かち書きをしない日本語文では一文の何処でも切り離すことができる。例 外は行末に開き括弧が来てはいけないとか、促音の「っ」とか長音の「ー」 が行頭に来ないようにする禁足処理である。まったく自由に切れるとはいか ないが英語のように何文字もの空白ができることはない。せいぜい一、二文 字である。印刷物の書籍ではそれすらも嫌い、字間を調整するなどでまった くの一直線に揃えてしまう。

日本語文では段落の一行めの一字下げと途中で終わるかもしれない最終行を 除いた他の行の行頭と行末を一直線に揃える。そうでないものは粗雑な文書 と見られてしまう。そのため段落内の初めのほうの文章に修整を加えるとそ の影響が以降の段落内にあるすべての文字位置の変更を引き起こすかもしれ ない。

英文タイプライターで作成する文書の行末が凸凹で構わないのであるから一 文を構成する何行分かの手直しだけでよい。段落内で修整する文章に引き続 く他の文章は影響を受けない。

日本語は漢字、ひらがな、カタカナ、そしてアルファベットと文字種が多 い。全文がひらがなオンリーとかなでないかぎり空白区切りにしなくてもス ラスラと読める。分かち書きが必須であるのは仮名に相当する文字しか使え ない点訳(点字翻訳)になる。分かち書きの技術面の詳しい解説は点訳方面に 多くある。

「で、引用文にもあるとおり、文節でわかちがきするのは「第1原則」で、 このほかに「第2原則」として「切れ続き」っていうものがある。くわしく いうと「自立語内部の切れ続き」っていうんだけど、これについての説明も この本から引用する。」
「そのうちの、文節ごとに切っていくことを「分かち書き」といいます。 (複合語の内部でマスをあけることは「切れ続き」と言って、あとで出てき ます)文節で切る、というのは、大雑把に言えばかなり簡単なことで、付属 語と言われる助詞・助動詞は、前の自立語(動詞・形容詞・形容動詞・名 詞・代名詞・連体詞・副詞・接続詞・感動詞)に続ける、それ以外は切る、 ということです。
つまり、ずらずらと続けて打ってあったらわかりにくいので、なるべく短く 切りたい。但し、単独で置いても意味がわかる言葉はいいけれど、意味がわ からなくなりそうなものは、独りでは置けないので、前にくっつけてやる、 というわけです。」

ところでパソコンの仮名漢字変換では仮名入力にせよローマ字入力にせよ仮 名ベタ書きな入力をする。人間にとって仮名ベタ書きが読み難いように仮名 漢字変換プログラムは苦労しているに違いない。そのことを思えば少しばか りの誤変換は我慢すべきといえる。

私は仮名漢字変換としてローマ字入力専用のskkを使っている。ms-imeや atokのようなwindowsの仮名漢字変換と違ってダッダーッとローマ字で仮名 文字列を編集画面に表示させてからスペースキーを押して漢字変換させると いう使い方ではない。

skkではローマ字で入力した仮名は確定操作をしなくても平仮名として確定 する。漢字を入力したいときはその読みのローマ字のうち第一字目を大文字 で、二文字以降は小文字で入れる。ローマ字で漢字の読みを入力したらス ペースキーを押す。語句の切れ目ごとに漢字変換操作をする。文字種が変わ るごとに分かち書きするような入力方法をとる。

skkは機械に任せていた分かち書き化作業を人間が肩代りして機械に負担を かけない。そのお陰で誤変換は本人の勘違いでしか起こらない。長々しい仮 名文字列を入力したあとで適切な漢字に置き換えられているかどうかを振り 返る必要はない。文頭から逐次に変換確定してゆく。手書きするのと同じで ある。漢字変換が正しいかどうかを振り返るような思考の流れを止めること がない。

ms-imeやatokなら頭に浮かんだことをとりあえず仮名で一気に打ち込んだあ とにスペースキーを一回押すとそこそこ正しい漢字に変換してくれる。打ち 込み直後なら手直しは速い。内容を憶えているから。時間が経つと何をどう 書いたかを忘れてくるので読み直しに苦労するだろう。たいていは直前の文 章を読み直しながら書き進める。その際に見つけた誤変換や誤字脱字をその ままにして次に移るのは憚られる。

どんな長文も一文毎に確定してゆくことを繰り返すのが普通である。仮名で 入力するとき、どの部分を漢字にするかを考えながら仮名入力する。全体の 仮名読みを入力したあとで漢字を想定した部分に立ち返り確認することは二 度手間である。それなら頭に浮かんだ時点の漢字をその時点で確定してしま うほうがよい。手書きなら何時もそうしているのである。忘れた漢字を思い 出すために辞書を引っ張り出すことがあったとしても文案は頭の中で文末の 句点(おしまいのマル)まで決めているはずである。

ms-imeやatokのように仮名文字列が適切な漢字に変換されたかを後戻りして 確認することを繰り返す方式よりはskkのように文頭から漢字仮名を適切に 逐次確定してゆく方式のほうが気持ちよい。三歩進んで二歩下がる(一行程 で確実に一歩だけは進む、行きつ戻りつ方式)よりはゆっくりでも前へ前へ と後戻りせずに進みたい。

| | コメント (0) | トラックバック (0)

« 2010年12月 | トップページ | 2011年2月 »