numa (4467) の日記
最近、バツ印(ペケ印)として「☓」を使われている例が目立つ。いままで「×」を使い慣れ、見慣れていたので、違和感があった。そこで、少し調べてみた。
まず「×」について。日本でバツ印として使われる「×」は、JIS X 0208、いわゆるJIS漢字で乗算記号として定義されていたものである。バツ印は乗算とは全く異なる用途なので、これは目的外使用だと思うが、他に適当な文字がなかったのだからしようがない。UnicodeではU+00D7 Multiplication Signとなっている。UnicodeコードブロックはLatin-1 Supplement (Latin-1増補) で、ISO/IEC 8859-1で定義されたコードポイントを踏襲したものである。
次に「☓」について。「☓」はUnicodeではU+2613 Saltireとなっている。Saltireは、旗などに使われる斜め十字の紋章。UnicodeコードブロックはMiscelaneous Symbols (雑多な記号類)。
ほかに似たような文字を記号類ブロックから探すと次のものが見つかった。
- Box Drawing (罫線素片)
- 「╳」U+2573 Box Drawings Light Diagonal Cross (細罫線斜め十字)
- Dingbats (辞書によると、文中の切れ目を示したり下品な単語を伏字にしたりするための記号。また、愚か者という意味もある)
- 「✕」U+2715 Multiplication X (乗算X)
- 「✖」U+2716 Heavy Multiplication X (太字乗算X)
- 「✗」U+2717 Ballot X (投票X)
- 「✘」U+2718 Heavy Ballot X (太字投票X)
罫線素片にある文字は、使い方がよくわからない。Dingbatsにある文字は、これらのコードポイントの直前にチェックマーク「✓」と太字チェックマーク「✔」があるので、投票X印は意味がわかる。外国で、投票用紙の候補者の欄にチェックを入れるときの記号だろう。日本でも最高裁判所裁判官国民審査で似たようなことをするが、意味が逆になる。乗算Xは、まあ乗算記号なのだろう。昔Dingbatフォントで使われていたのでここに入ったのだと思う。
結局のところ、バツ印そのものの意味で使える文字はなく、どの文字を使っても代替的に使用しているだけ、ということになる。
ちなみにマル印は「○」U+25CB White Circleと「●」U+25CF Black Circle。JIS X 0208では白丸と黒丸をペアで定義していたのだから、そうなるのは当たり前。
- 5 コメント
モデレーション(以下、モデと略す)は、たまにコメントや日記を書くと、それから2日ぐらいしてから回ってくる。普段は特に何も書き込まないし、それこそ見てもいないことも多いので、何か書き込んでいると生存確認されて、やらせてみようということになるのだろう。slashcodeは見てないので憶測に過ぎないし、他の人がどうかは知らないけれど。
メタモデは、以前は毎日のようにやっていたけれど、最近はやらなくなった。コメントのモデが妥当かどうかは元のストーリーを見ないと判断できないし、その中での文脈を見ないとコメントの意味がわからないし、コメントから張られたリンクをたどるのも億劫だし。ストーリーに、特に見たいのが少ないのが原因の一つでもある。
モデが回ってきた場合、自分がまず書き込まない、けれども興味があるというややこしい条件のストーリーを選ぶ必要がある。なんせ、そのストーリーにコメントを書けばモデが無効になるから。まあ、モデしようと思ってストーリーを見るわけではなく、その場の判断で決めるだけだが。
さて、モデを始めると、どのコメントに、どのモデを適用するかが問題となる。基本方針は次の通り。
- 基本的にプラスモデを行う。よほどのことがない限り、マイナスモデは行わない。
- ACコメントで、スコアが0のものを1にすることを優先する。もちろん、IDコメントでもスコア1のものを2に上げるのは積極的に行う。スコア3以上はものによる。なお、スコアが−1になっているが、それがないと返信の意味が理解できない場合、多少の欠陥には目をつぶってプラスモデすることもある(ので、「不当プラスモデ」を食らうことも多い)。
- 素人判断を恐れない。どうせ全てわかっていることなど少ない(し、わかっている話には自分でコメントを書きたくなる)から、コメントを見て、それが良さそうかどうかだけで判断する。ただし、返信に否定的コメントが多い場合は評価を保留するかもしれない。(これも「不当プラスモデ」の対象になるかも。)
- モデは、原則的に1つのストーリーで終わらせる。別のストーリーに持ち越すと、後で「あのコメントをプラスにすればよかった」とか思うかもしれないから。
モデの種類の使い分け基準は次の通り。
- 参考になる (Informative)
- 何であれ、情報提供になっているもの。情報には、コメント内容とリンクの両方を考慮する。
- 興味深い (Interesting)
- コメントで表明されている意見について、面白いと思ったもの。これには、「そういう考え方はなかった」を含む。ただし、必ずしもその考え方への同意を意味するものではない。「参考になる」との境界が曖昧になることが多いので、英語のinformativeとinterestingを比べて、どちらに当たるか考えて選ぶ。
- すばらしい洞察 (Insightful)
- 「すばらしい」などと書いてあるので敷居が高そうだが、insightがすばらしいかどうかは問われていない。人物や状況に対する(特に直観的な)理解の正しさを評価するものだからだ。これまた「興味深い」との境界が問題になる。「なるほど、それは正しいな」と思えるもので、深い理解を感じさせるものを選ぶ。なお、こちらはコメントに対する同意が前提となる。
- おもしろおかしい (Funny)
- 文字通り、笑える内容のものを選ぶ。何を笑うかは人それぞれで、特定知識がないとわからない内輪受けも多い。なので、他人が見てどうかまでわからない。そこで、自分が笑えたものを独断と偏見で選ぶ。
- 既出 (Redundant)
- 他のコメントと内容が同一で、かつ返信がついていなくて、さらに日付が新しいという条件がないと使えない。面倒だから、モデのポイントが余った時でもないと使わない。
- オフトピック (Off Topic)
- 雑談サイトなので、そんなに厳密にチェックするのも大人げない。ただし、スレ違いの誤爆で投稿者本人が認めているものについては、積極的にスコアを落とす。それから、ネガティブな雰囲気を振りまいていて、なおかつオフトピックなもの。
- 不当プラスモデ/不当マイナスモデ (Overrated/Underrated)
- あまり使わない。評価を上げるにしろ下げるにしろ理由が必要と思うのだが、これには理由がつかないので。
- 荒らし (Troll)
- 誹謗中傷など、明らかに有害なものは、この分類にして落とす(つもりだが、やったことはない)。
- フレームのもと (Flamebait)
- 「荒らし」との使い分けが難しい。これは、よほどの煽り文句で、かつ何の意見がない場合でないと使わないと思う。使ったことはない。
基準がいい加減だって? スラドのモデなんて、そういうものよ。
まあ、モデは原則的に誰がやったかはわからないようになっているので、私が、などといってもどれがそれに対応するかは言えないけれど、ご参考まで。
- 0 コメント
前回の記事のさらにまた続き。
前回いろいろとキーボード配列変更プログラムを探したのだが、そのときに見つけたものにMicrosoft Keyboard Layout Creatorがある。 これは、デバイスドライバーを生成することによって、キーボード配列や複数キーの操作による文字入力を実現するものだ。残念ながら、CapsLockキーをCtrlキーに置き換えるようなことはできない。
これで実現できる機能は次の通り:
- キーボード配列変更方式
既存のキー(記号キーなど)に別の文字を割り当てる。
たとえば、「[」「]」「\」の各キーに「ä」「ë」「ö」を、それぞれ割り当てるようなやり方である。もちろんShiftキーを押しながらそれらのキーをタイプすれば、それぞれの大文字版が入力されるように設定する。CapsLockについても同様。
それじゃ「[」「]」「\」が入力できないって? このキーボード配列とは別に、普通のキーボード配列も登録しておけばよい。そうすればAlt + Shiftで配列を切り替えられる。 - デッドキー方式
いくつかのキーをデッドキーとして扱い、それと別の1文字との組み合わせで、さらに別の1文字を入力する。
たとえば、「`」をデッドキーとする。「`」だけをタイプしても文字は入力されず、その次に「a」をタイプすることで「à」を入力できるようにする。どの組み合わせでどの文字が入力されるかは、キーボード配列を設定するときに決めておく。ちなみに、「`」という文字自体を入力したい場合は、「`」を2回タイプするように設定すればよい。(いや、別に「`」の後に空白というのでもいいけれど。) - コンポーズキー方式
どれか1つのキーを「Compose」というキーに割り当てる。たとえば、「à」を入力したい場合は、「Compose」「`」「a」の順番でタイプする。 - シフト状態追加方式
別のシフト状態を追加し、さらにいくつかの追加文字を入力可能にする。
CapsLockではアルファベットが大文字シフトになるが、ここで一部の記号類に別の文字を割り当てる。たとえば、CapsLock状態で「[」「]」「\」の各キーが「ä」「ë」「ö」になるよう設定する。そうすると、次のような動作になる:- 通常状態:
- [ キー ⇒ [
- Shift + [ キー ⇒ {
- CapsLock状態:
- [ キー ⇒ ä
- Shift + [ キー ⇒ Ä
(ここに挙げた例は説明のためのもので、実用性を考えたものではない。)
なお、通常のシフト状態でもCtrl + Altを押しながら別のキーをタイプして1文字入力という技があり、それの大文字版は当然Shift + Ctrl + Altを押すのだ。もはや曲芸である。 - 通常状態:
キーボード配列変更方式は直感的でわかりやすいが、文字を割り当て可能なキーの数に制限がある。そもそもキーの数には限界があるし、アクセント付アルファベットを普通のアルファベットとして使うキーに割り当てるわけにもいかない。
それに対してデッドキー方式は、キーの数に対する制約はキーボード配列変更よりも少ないが、1文字入力するのに2回キータイプを行う必要がある。なお、デッドキー方式は、昔のタイプライターでも使われていた古典的な方式だ。他にもたとえば、文字にアンダーラインを引きたいときに、まず「_」をタイプし(ここで文字送りは行われない)、その後に別の文字「A」をタイプすれば、アンダーライン付きの文字「 A 」が完成する。
コンポーズキー方式は、デッドキー方式よりもさらに制約が少ないが、1文字入力に3回タイプする必要がある。また、1つのキーを「Compose」に割り当てると、そのキーはほかの用途には使えない。
シフト状態追加方式は操作が複雑なので、よほどのことがない限り使わない方がいいだろう。でも、スイスのドイツ語キーボードでは、標準でこの方式を使うらしい。もちろん、上に挙げた例ほどひどくはないけれど。
なお、このツールは日本語キーボードをサポートしていない(と、ドキュメントには書いてある)。日本語キーボードには他では使っていないキーが1つあって(Backspaceの左のキー)、これには対応していないらしい。もちろん、「変換」や「無変換」にも対応していない。
たまにヨーロッパで使われるアクセント記号付き文字を入力したい場合がある(この文章を書いている時とか)ので、そういうときには使えそうだ。いまはコード表から探しているので、少々面倒なのだ。でもまあ、さすがに「♥」に専用キーを割り当てようとは思わないけれど。
- 1 コメント
以前、英語キーボードでCapsLockキーにCtrlキーの機能を割り当てた。今回はその続きとなる。
いま使っているキーボードはカーソルキーが逆T字型に配列されたもので、上矢印キー(↑)の左右にPgUp/PgDnキーが配置されている。ありがちなことだが、この配置だと、左右矢印キーと間違えてPgUp/PgDnキーを押してしまう。そうすると、カーソルを左右に動かすだけのつもりなのに、それが1ページ分上下に動いてしまい、大慌てすることとなる。そこで、その対策を講じてみた。
さて、キー割当てを変更したいという要求はよくあることで、そのためのツールも多数公開されている。PgUp/PgDnを無効にしたり、左右矢印キー(Left/Right)の機能を割り当てたりするだけならば、どれでも好きなツールを使えばよい(なんなら、レジストリを直接変更してもよい)。しかし、それではPgUp/PgDnに相当するキーがなくなってしまう。キー操作でその機能は利用したいのだ。ただ、そのキーを使うのを避けたいだけのことで。
そこで、次のようなキー割当てを実現することを目的として、ツールを探してみた。
- PgUpに左矢印(Left)機能を、PgDnに右矢印(Right)機能を、それぞれ割り当てる。
- Ctrl+PgUpにPgUp機能を、Ctrl+PgDnにPgDn機能を、それぞれ割り当てる。
- Ctrl+UpにHome機能を、Ctrl+DownにEnd機能を、それぞれ割り当てる。Home/Endキーは存在するが、カーソル操作キーからは遠く、不便なのだ。
- PrtSc (Print Screen)にAppsキー(右クリックメニューを呼び出すキー)を割り当てる。現状ではAppsキーは存在せず、右Altと右Ctrlの間にPrtScキーがある(他のキーボードなら右Alt、右Windows、Apps、右Ctrlの順に並んでいるところ。)。メーカーの考えでは、Appsキーはなくてもいいが、PrtScキーは欲しいということらしい。しかし、どちらかというとAppsキーの方を使いたいので、ここで割当てを変更する。
- PrtScも、ごくたまに使いたくなる可能性もあるので、Ctrl+PrtScにその機能を割り当てる。
ShiftやCtrlの状態を含めたキー割当てを行う場合、レジストリ変更では済まず、常駐プログラムの厄介になる。そこで、AutoHotkeyを使うことにした。これは、機能は豊富だが、その分とっつきが悪い。GUIでボタンをいくつか押しておしまい、ではなく、定義ファイルを書く必要があるからだ。その代り、プログラムで細かい制御ができる。
さて、AutoHotkeyで最初に書いた定義ファイルは次の通り。
^PgUp::PgUp
^PgDn::PgDn
PgUp::Left
PgDn::Right
^Up::Home
^Down::End
^PrintScreen::PrintScreen
PrintScreen::AppsKey
ただし、“a::b”という表記は“aキーをbで置き換える”という意味で、“^X”はCtrlキーとXキーを同時に押すという意味である。やってみた結果、PrintScreenはうまくいったが、その他のカーソル制御関係は、編集モード時にうまくいかない。Ctrl+PgUpでは何も起きないし、Ctrl+Upで行の先頭にカーソル移動してほしいところが、バッファの先頭に移動したりする。そこで方針を変えてみた。
PgUp::Send {Left}
PgDn::Send {Right}
^PgUp::Send {PgUp}
^PgDn::Send {PgDn}
^Up::Send {Home}
^Down::Send {End}
PrintScreen::Send {AppsKey}
^PrintScreen::Send {PrintScreen}
ただし、“Send {キー名}”は、“キー名”で示されるキーが押されたという信号を送る命令である。こちらではうまくいった。なぜそうなったか、原因は調査中。
これで、取りあえずの要求は満足できた。AutoHotkeyはなかなか面白そうなので、しばらく遊んでみようと思う。
- 2 コメント
21世紀にもなって、メールの文字化けなんてものに悩まされるとは思わなかったよ。いい加減にしてくれ、AppleでiPhone Mailを作っているお馬鹿さん お利口さん。こっちは文字化けメールをもらって、状況の把握に手間がかかってしようがない。まったく。
- 問題:
- iPhone/iPadから送信された日本語メールが、受信側では文字化けする。送信者が自分で書き込んだ部分は読み取れ、別メッセージから引用された部分が文字化けすることもある。何をどうすれば、そんなことができるのか。わけがわからないよ。
- 症状:
- メール本文の化け方を見る限り、シフトJISで送ってきている。しかし、ヘッダーを見るとContent-Type: text/plain; charset=cp932になっている。 cp932なるcharset名はIANAに登録されていない非標準のものである(登録されているのはShift_JISおよびWindows-31J)ため、受信側では解釈できず、結果的にエラーとなる。これはiPhone Mailの問題であり、受信側の問題ではない。charset指定をShift_JISまたはWindows-31Jにしてくれれば解決する。
- 解決方法:
- ネットを検索したところでは、解決方法には次の2種類がある。
- iPhone Mailの設定を変更し、常にUTF-8で送信するようにする。いまどきUTF-8を解釈できないお馬鹿さんはいないはずだから、これで問題ない。(ケータイのメールは、ゲートウェイで変換してくれるはず。)とっても間違えたような気がするので追記。あちこちのページで見かける「文字エンコーディングをUTF-8に切り替える方法」というのが、Outlookの設定変更のように思える。みんな同じことを書いているからiPhoneのことだと思ったら。受信側を設定させるにしても、なぜOutlookだけ?
- メール本文に、ISO-2022-JP/Shift_JIS/Windows-31J/EUC-JPには存在しないがUnicodeには存在する文字を挿入し、強制的にUTF-8で送信させる。 ただし、ケータイ絵文字はシフトJISに存在する文字とみなされるらしいので、「⌘」など、絵文字にもない文字を使う必要がある。 (実際には、署名にそういう文字を入れておけばよい。)
具体的にどうやって設定するかは、検索すれば山ほど出てくるから、ここでわざわざ説明しない。iPhoneは使ってないから、説明しろと言われても困る。どちらの方法を採用すべきか? 判断できないなら両方やってくれ。
解決方法としては前者のほうが正統的だが、後者の方法を紹介している例が多い。まあ、とにかくUTF-8で送ってくれればいい。
なお、後者の方法は、プログラムの文字エンコーディング自動判別機能に対して、判別が容易な文字を与えて確実に認識させようとするものだ。 こんなad hocなdirty hack(ああ、バッド・ノウハウって言うんだっけ)がいまだに存在して、エンドユーザーの手を煩わせているなんて、信じられない世界だ。
ところで、文字化けといっても、一般人の住む世界(旧陸軍では「地方」、旧海軍では「娑婆」、ネット用語では「リアル」、日本語では「世間」、英語では「Real World」)では2種類の症状をどちらも「文字化け」と称してくれるので性質が悪い。整理すると:
- メールに含まれる文字のうち、絵文字その他、一部の文字が「?」のような別の文字に置き換えられる。
- メールの本文の文字がすべて意味不明の文字に置き換えられ、完全に読解不能の状態になる。
それが、どちらの話なのかはっきりしないままに、auからSoftBankでは化けたとか、Docomoだと症状が違うとか、Outlookのバージョンがどうだとか、Gmailだとどうなったとか、ぐだぐだとした細かい話になって、何を言っているのかわからない。それも、送られてきたメッセージのサンプルもないままに話が進むため、誰がどんな悪さをしているのか、見当もつかない。素人さんの議論を読んでも埒が明かない。
まず、「絵文字だけが化ける」話。こちらは簡単。化けるのは受信側に存在しない文字だから。ない文字は表示できないんだから、あきらめろ。絵文字や顔文字は、他機種には伝わらないと覚悟すべき。
- charset=UTF-8で送信された場合は、受信側では「絵文字であることはわかるがフォントがない」という理由で表示されない。
- charset=Shift_JISで送信された場合は、絵文字がシフトJISの未定義コードポイント(外字用)を使っているため、受信側は「何の文字が送られたかわからない」ので表示できない(charset=Windows-31Jでも同様)。相手によっては、そのコードポイントには別の文字が登録されているために、違う文字が表示されるかもしれない。ケータイ各社間をまたがって送ると、絵文字の再配置をするので、さらに状況がややこしくなる。
- charset=ISO-2022-JPで送信された場合は、そもそもシフトJISで絵文字に使っているコードポイント自体がISO-2022-JPの有効範囲外なので、まともに変換できない。変換できても「文字として解釈できない」から表示できない。
- charset=cp932で送信された場合は、そもそも「何のエンコーディングで送られたかわからない」から、絵文字だけじゃなくてメールのメッセージ全体が化けるのが正常な動作で、化けなかったら奇跡である。
それから、「メッセージ全体が化ける」話。文字エンコーディングが判別できないことから発生する。判別できない理由は、送信側にあったり受信側にあったりする。
- 送信側の問題は、だいたいがcharset指定を間違えること。charset=cp932のように、わざわざ未定義のエンコーディング名をつければ化けること間違いなし。本文とcharset指定の内容が矛盾すれば、やはり化けるが、いまどきそれはないだろう。それよりも、charsetを指定しないという大技のほうがまだありそうだ。
マルチパートのパートごとでエンコーディングが違うから問題を起こす、という話があるが、個々のパートでcharset指定が正しく行われていれば、それでも問題はないはず。 テキストの途中で文字エンコーディングを変えるなんて反則技をされると、charsetに何を指定すればいいかわからないけれど。 - 受信側の問題は、charset指定を無視して、わざわざ独自動作をしようとすることで起きる。たとえば:
- 以前のOutlookでは、テキストの添付ファイルの場合にcharset指定を無視して、無条件にWindows-31Jだと解釈し、そのままユーザーに提示するという悪癖があった。Windows-31Jではないエンコーディングで送られてくると、受信したユーザーの観点では文字化けしているようにしか見えない。
- また、Internet Explorer 6あたりは、サーバー側のcharset指定にかかわらず、常に自動判別を作動させて、ご丁寧にも判別をしくじるという奇行で知られていた。添付したHTMLファイルが化けるというのは、ひょっとしたらこれかもしれない。
- Eudoraだったかで、添付ファイルにファイル名を指定するフィールドがあって(Content-Disposition: attachment; filename="foo.doc"とか)、ここに日本語ファイル名を指定しようとしてしくじるという、おふざけをかましてくれたことがある。これは、そもそもfilenameにcharsetを指定する方法が規定されていない。
こんな場合でも、受信側で表示できてしまうことがある。それは、たいてい文字エンコーディングを自動判別する等の小細工をしているはずなので、余計なことをしていない相手に転送したら化けた、とか、別の問題を引き起こす。こうなると完全な2次災害で、犯人探しも容易ではなくなる。
メールやウェブがらみで文字化けするのは、たいていの場合自動判別が絡んでいる。だいたい、自動判別なんてヤクザな機能に頼るから、かえって文字化けが起こるのだ。100%確実に判別できるはずはないから、どうしても誤判別は避けられない(その結果、文字化けする)。だから、勝手に判別しようなんてせず、charsetに指定してある通りに解釈すればいい。charsetの指定と実際の文字エンコーディングが違っていたら? そんなもの、送ってくるほうが悪いのだから、化けて当然。下手に救済しようとするからややこしくなる。小さな親切、大きなお世話。
そういう余計なお世話ばかりやっているから、自動判別に甘えて、必要なcharset情報をまともに指定しない、あるいは指定されていても無視する奴らが出てくる。頭の良いことをしようとして、頭の悪い結果を招く。ネットワークのトラブルは、すぐには誰が悪いかわからないから、いちいち調べまわる羽目になる。プロトコルをちゃんと守ってくれないとこっちが迷惑するのだ。
自動判別がらみのトラブルは大昔からある。それに対するバッド・ノウハウも。HTMLのコメントに「美乳」と書いておけばEUC-JPとShift_JISとの間の誤判別が起こりにくい、とか。(ところで、何度変換しても「微乳」になるのはなぜ?)
まったく、いつまでたっても進歩しない世界だ。Microsoft Outlookといい、Apple iPhone Mailといい、なんで、どいつもこいつも標準を無視して俺様スタンダードを作るんだ。それも日本オンリーのガラパゴス俺様スタンダード。グローバル企業の名が泣くぞ。こんな連中の相手ばかり、もう疲れたよ。
- 1 コメント
- 2 コメント
日本語版Windows 7で、英語キーボード(厳密にはUS Englishキーボード。UK Englishキーボードは配列が違う)を使うための、現時点でのいちばん簡単な設定変更の方法をまとめておく。なお、Windows 8でどうなるかは、使ったことがないのでわからない。
- Happy Hacking Keyboard公式サイトで公開されているツール「HHKBキー配列切替ツール」(プログラム名はHHKBCNG.exe)を入手して実行する。
- CapsキーをCtrlキーとして使いたい場合、SysinternalsSuiteに含まれるツールCtrl2Cap(プログラム名はctrl2cap.exe)を実行する。
このツールはコンソールプログラムであり、コマンド プロンプトから実行する。
プログラム起動時に、管理者権限がないので実行できないという旨のメッセージが表示される場合、次の手順で管理者権限を取得する。- スタートメニューで、「プログラムとファイルの検索」の入力フィールドに「コマンド プロンプト」と入力する。(実際は「コマンド」だけで十分。)
- 検索結果として、当然ながら「コマンド プロンプト」が現れるので、そこにマウスカーソルを移動させて、右クリックでコンテキストメニューを表示させる。
- コンテキストメニューで「管理者として実行(A)...」を選択すると、コマンド プロンプトが管理者権限で起動される。(ウィンドウのタイトルが「管理者: コマンド プロンプト」になる。)
なお、これを行うためには、ユーザーアカウントにAdministrator権限が必要ではないかと思うが、本当にそうかどうかは確認していない。 また、これを一度やったところ、その後起動されるコマンドプロンプトがみな管理者権限になってしまった。別にそれで問題ないので、そのままにしている。
戻したい人はやり方を調べてくれ。調べた結果をすぐ次の記事で公開した。
これらの設定はシステムを再起動しないと有効にならないので、必要に応じて再起動すること。
この方法の利点は、設定を元に戻したいときも同様の操作で戻せることである。また、Happy Hacking Keyboardに限らず、どのキーボードでも問題なく使える。実際、この文章はIBM Space Saver II Keyboardで打ち込んでいる。
実のところ、キー配列情報は、基本的にはデバイスドライバーで決まり、Ctrlキーについてはレジストリで管理されている。上記プログラムは、それを書き変えているだけ。 よって、キーを押したときに生成されるキーコードが同じなら、どのメーカーの、どのタイプのキーボードでも、同様に適用できるのだ。PS/2接続だろうが、USB接続だろうが、ノートPCの本体キーボードだろうが。
なお、コントロールパネルの「キーボードまたは入力方法の変更」で入力言語に「US」を追加する方式は、これとは違う動作をする。 コントロールパネル方式では、入力言語を「US」に切り替えればたしかに英語キーボードが使えるようになる。しかし、英語キーボードからは日本語が入力できない(仮名漢字変換が使えない)。日本語を入力したい場合は、入力言語を日本語(「Microsoft IME」なり「ATOK」なり)に切り替え、別途接続した日本語キーボードから打ち込む必要があるのだ。本当にやりたいのは、英語キーボード一つで、日本語入力を含めたすべてのキー入力ができることである。
ここで説明した方法なら、「Alt+`」(「Alt」と「`」(バッククォート)を同時に押す。バッククォートは日本語キーボードの「半角/全角」キーの位置にある)で日本語入力のON/OFFができる。もちろん日本語文字はローマ字入力で打ち込む。英語キーボードに慣れた手には、これが一番やりやすいのだ。なんせ、タッチタイプは英語で覚えたし、日本語を入力するようになった頃には、日本語キー配列を覚えるような悠長なことをしている余裕はなかったのだから仕方がない。さらにいえば、昔は「A」キーのすぐ左、いまの「Caps」キーの位置には「Ctrl」キーがあるのが普通だったのだ。(もっといえば、「Esc」は「Tab」のすぐ上にあった。)今から見れば、恐竜時代の話かもしれないけれど。
- 3 コメント
最近、思うこと。
正論は、(少なくとも建前上は)正しいがゆえに誰も反論できない。よって、会議などの際に、うるさいやつを黙らせるのには非常に有効である。 しかし、それは同時に周囲を萎縮させる効果もある。 反論を許さない雰囲気を作り出してしまったら、活発な議論など起こりようがないのだから。うるさいやつと一緒に、参加者全員を黙らせてしまう。
たとえば、上司が常に正論を言い続けた場合、それは(本人の意図がどうであれ)部下を威圧することになる。 部下は上司を恐れて戦々恐々とし、上司の目をうかがいながら仕事をするのだ。部内の空気が悪くなることは間違いない。
上記のように、正論は危険な武器であり、使用には細心の注意が必要である。 これは伝家の宝刀であり、それがもっとも効果的な場合にのみ抜くべきものなのだ。 普段から抜き身を振り回すのは、気違いに刃物という。
そして、(名目上)正論は正しいものであるがゆえに、その実施は容赦なく行われる。正を行わないのは邪だからだ。反論は許されない。無理が通れば道理が引っ込む。 最終的には無茶がまかり通ることになる。抵抗は無意味だ。
世の中、正論だけで済むわけはないのだが。 水清ければ魚棲まず。まあ、偉い人にはわからんのでしょうけれど。
- 0 コメント
はじめに
先の記事を書くに当たっていろいろ調べていたところ、「Ruby M17N の設計と実装」という記事を見つけた。そこで、今回はこれをネタに思うところを語りたい。ダシに使われたほうはいい迷惑かもしれないが、記事を公開すればそういうこともあるので、あきらめてほしい。
なお、この文章には用語の定義らしきものがいくつか出てくるが、いずれも厳密なものではない。ここでの議論に十分な程度のものなので承知されたい。
CSIとUCS Normalization
前掲記事ではCSI (Code Set Independence) とUCS Normalization(UCSはUniversal Charcter Setの略。かならずしもUnicodeとは限らない)とを対比して議論している。 (なお、前掲記事ではCode Set IndependenceではなくCode Set Independentを使っているが、形容詞と名詞を対比するのはおかしいので、ここではCode Set Independenceで統一する。)
CSIは特定の符号化文字集合(Coded Character Set (CCS)。長いので以下「文字セット」と略す)および文字エンコーディングスキーム(Character Encoding Scheme (CES)。以下「文字エンコーディング」)に依存しないプログラミングを指す。これは非常に美しく、また高い理想である。誰でも、特定の環境にべったり依存したポータビリティのないプログラムよりは、環境に依存しないものがいいと思うし、これは、それを文字表現について実現しようとするものだから。
いっぽうUCS Normalizationはその対極にある。特定の文字セット・文字エンコーディングを内部処理に決め打ちし、外部との入出力はデータの変換によって実現しようというものだからだ。これにより、同一方式をとる処理系間でのポータビリティが実現されるが、これはCode Set IndependenceならぬCode Set Dependence(CSD。いまここで作った用語で一般的なものではない)そのものである。CSIの理想主義の対極にある、ある意味、現実主義かも知れない。
なお、これらの概念は別に新しいものではない。ヨーロッパではISO/IEC 646の各国語版やISO/IEC 8859シリーズという複数の文字セットに対応する必要があった。また、各言語ごとに日付表記・ソート順が違っていたり、各国ごとに数値・通貨等の表記が異なっていたので、それにも対応が必要だった。単一市場でそれらに個別対応するのは難しかった。(だからCode Set Indepencdenceなのだ。ここでいうCode SetはCoded Character Setの略。MIMEでいうcharsetもCharacter Setの略なので、根源は同じ。)
いっぽう日本では、1980年代半ばにはISO-2022-JP、Shift_JISおよびEUC-JP(当時そんな用語はなかったし、厳密には違うところもあるけれど)が出揃っており、これらの文字エンコーディングに対応するためにUCS Normalization的アプローチをとったものもある。たとえばNemacs (Nihongo Emacs) は内部処理にEUC-JPを使い、ISO-2022-JPおよびShift_JISも入出力できた(なお、NemacsはのちにMule (Multilingual Emacs) に発展し、最終的にGNU Emacsに統合された)。
I18NとL10N
前掲記事では、L10Nについて:
L10N とは Localization の略で、地域化を意味しています。(cf. nls / national language support) 具体的には、それぞれの地域・言語に適したように変更することとなります。(後略)
と説明しており、その続きの文章を見ると、特定の地域・言語・文字エンコーディングその他にだけ、専用に対応することのように読める。また、I18Nについては:
I18N とは Internationalization の略で、国際化を意味しています。I18N とは、
- ソフトウェアのマルチバイト対応
- 各種メッセージや通貨記号等を地域ごとに容易に切り替えられる仕組みの整備
を行うことです。(後略)
と説明している。
しかし、上でいうL10Nはdirect localizationといって、I18Nとセットで語られるL10Nとは違うのである。(たしかに、大昔はそうやっていたというのは事実だけれど。Rubyなんて、21世紀にもなってそれに近いことをやっていたようなのだけれど。そういえば、JPerlってのもありましたねぇ。皆さん、面白いくらいに同じことをやっている。)
そもそもI18Nは、文字セット・文字エンコーディング・言語・地域その他に依存する情報・機能をモジュール化してプログラム本体から切り離し、それを状況に応じて動的に組み込むことで各種の言語・地域その他に対応できるようにする枠組みを作ることを指し、L10Nは、そのような枠組みのなかで組み込み可能なモジュールを作ることを指す。別にマルチバイト対応やメッセージ・通貨記号等の切り替えだけに特化した話ではない。 上記のような説明は極端な矮小化というべきだろう。 (まあ、ネットで検索してみるとそういう説明ばかり目につくのは事実だが。)
M17Nについては……コメントを差し控えさせていただきたいと思います。
CSIであることの困難
さて、CSIを実現するには、どこか下位レベルにCSDなモジュールが必要である。これは、たとえばOSがデバイスドライバーというデバイス依存部を下位レベルにもつことにより、ユーザープログラムにデバイス独立性を提供するのと同じである。
RubyではtranscodeおよびEncoding::Converterクラスがこの役目を果たしているように見える。これによって、外部の文字エンコーディングと、内部処理用の文字エンコーディングとの間に独立性が提供できる。これはPerlのEncodeモジュールに相当する。また、Rubyでは内部処理を文字エンコーディングに依存しないようにするためのさまざまな機能が提供されているようだ。
CSIのユーザープログラムが特定の文字エンコーディングに依存すべきではないのは、定義からして明らかだ。そして、それを実現するためには、ユーザープログラムはシステムから提供されるAPIを通じてのみ文字データを処理することが必要になる。
問題は、ユーザープログラムの要求を満たすだけのAPIが提供できるかどうかである。しかし、千差万別・多種多様の要求に対応できるAPIをあらかじめすべて用意しておくなんてことは、どう考えても無理である。 よって、ユーザープログラム側で自分の要求を満たす機能を作ることになる。
もちろん、そういう機能はモジュール化しておくことが望ましいし、汎用化されて標準提供モジュールになるかも知れないけれど、それらは必然的にCSDになってしまう。 美しいCSIの実現のためには、泥をかぶってくれるCSDなモジュールが必要なのだ……ユーザープログラムのレベルで。あれれ、CSIってどういう意味だったっけ。
ユーザープログラムのCSIを実現するために、それと同一レベルにCSDなモジュールが必要になってしまう。しかも、そういうモジュールは呼び出し元の文字エンコーディングに合わせて値のやり取りをする必要があり、内部的にはUCS Normalization的な構造になる可能性も高い。CSIのためのCSDに、CSIのためのUCS Normalization。やれやれ、まったく難儀なことである。
おわりに
あ、最後にいっておきますが、私は別にどちらがいいとかいってませんよ。UCS Normalizationは別の難儀を抱えているだけなんで。さらにいえば、Unicodeがいいともいってませんから。
Unicodeで処理を統一しても、それが使えなくて、別のものでやらざるを得なくなるかも知れないし。 16ビットUnicodeで統一したはずのJavaやWindowsは、Surrogate Pairが出てきて、Shift_JIS処理でバイト単位にやっていたのと同じことを16ビット単位でやっているし。Combining CharacterやらVariation Selectorやら、面倒くさいのはいっぱいあるし(Combining Character類似のものはISO/IEC 6937ってのがありましてねぇ、別にUnicodeの専売特許じゃありません。Backspaceで重ね打ちなんて古典芸能もありましたし)。ああ、Normalization Formってのもありましたね。ややっこしいったらありゃしない。どうせ、似たようなことはまた起こります。これが最後の一匹とは思えない。
まったく、世の中同じことの繰り返し。これが学園祭の前日なら、繰り返しも楽しかったかもしれないけれど。
- 0 コメント
どうも、自分のなかには、昭和30年代から40年代に建てられた古い建物、特に商業施設に対する愛好があるようだ。なぜか、落ち着くというか、郷愁を感じさせるというか、そういう感覚がある。
もっと古い建物、たとえば神田連雀町の蕎麦屋とか、旧交通博物館(元万世橋駅)とか、ああいうのも風情があっていいのだが、懐かしいとまでは思えない。時代が違いすぎているせいか、自分とは別の世界に属しているように感じてしまう。
さて、なぜ商業施設かというと、そういう古い建物に新しい店、新しい商品が並んでいるところが、微妙にミスマッチな雰囲気を醸し出していていいのかもしれない。なにもかも古いままでは、時間が止まってしまった世界のようなもので、あまり面白みを感じない。 といって、新しいオシャレなビルには、自分の身の置き場所がないような気がする。
古い建物は老朽化のために建て替えが推進されていて、徐々に減っていきつつある。 東急文化会館の閉鎖以来、それが加速されたような気もする(そういう時期だったのだろう)。文化会館には大きな劇場があったし、三省堂も2フロアあって、わりと行くことが多かった。三省堂の一方はマンガ専門店だったと思う(渋谷にはマンガ専門店も多い)。古いといえば、大盛堂の旧店舗も古かったものだ。あそこのエスカレーターはいつ止まるかと思うような動き方をした。渋谷ハチ公斜め向かい、いまはTSUTAYAが入っているビルは、むかし渋谷宝塚劇場があった場所である。宝塚の名のとおり東宝系だったが、ここも古かった。これ以降、渋谷の書店は全体的に弱体化し、映画館も小さなものが多くなる。どんどんオシャレなビルが建てられて、どんどん入りづらくなっていく。
映画館といえば、新宿の映画館も激減した。歌舞伎町にたくさんあった映画館(やはり、どれも古かった)は、東急系を除いて絶滅したし、東映パラスも新宿ピカデリーも建て替えられて、いまやオシャレなシネコンである。 パラスは、むかし大劇場だったのを無理やり4つ(だったか)に分けたため変な構造になっていて、椅子もへたってガタガタだった。あれでは終わりも近いと思っていたが、ピカデリーはそこまで古かったわけではない。まあ、シネコンになるのも時代ではある。あまり面白くはないけれど。
最近では、ラジオ会館もアキハバラデパートも消えてしまった。あとはラジオデパートが残るのみ。アキバにはさすがにオシャレビルは似合わないだろうが、アキバ人種も変わっていきつつあるしなあ。ファッショナブルなアキバ……ないな、やっぱり。アキバのファッションはメイドさんだけでいいよ。
ちょっと昔に戻れば、あちこちで同様のことが起きていた。大和の駅前も、地上に電車が走っていた頃は、古臭い建物もあったものだが、知らないうちに小奇麗になっていた。まあ、駅からちょっと離れれば昔ながらの街ではあるのだが。
もっとずっと昔の話をすると、川崎の地下街が完成する前は駅ビルも結構古くて、私の好きなにおいがした。映画街もチネチッタになる前で、やはり古かった。地下街と駅ビルと映画街がほぼ同時期に新しくなり、川崎は急にモダンになった。それでもやっぱり川崎なのだが。チネチッタはさらに改装され、いまでは流行のシネコンである。なんだかなあ。
というわけで、古いものはやがて消えてゆく運命にある。そろそろ私も消えようか。
# ここに並んでいる街に共通するキーワードがあるような気もするが、たぶん気のせいだろう。
- 0 コメント