| 日記 |
| 2003年10月1日(水) ダイヤ改正 |
| 今日、JR各社のダイヤが改正されました。 東海道新幹線品川駅開業ということですが、品川折り返しはないようです。東海道新幹線の本数上限が東京駅の折り返し能力の不足によると言われていたのでやや意外。多客時の臨時は品川折り返しになるのかも。 しかし、それよりおおきかったのは165系全廃だったかも。165系というのは1963年に登場した国鉄の急行型電車で、急行が減った後も昔の（ムーンライトながらになる前の）大垣夜行とかムーンライトえちご（今年３月まで）に使われていましたが老朽化はげしく、９月２８日の「臨時快速こころ」を最後に全廃となりました（一部私鉄には譲渡車両が残っているようですが）。数日前に最後の167系も解体されたらしいので、これをもって153系（旧91系）から始まる急行型直流電車が全廃（あと廃車回送が数本あるらしいですが）になるようです。１つの時代が終わった感じを強く受けました。 今日のお菓子：  追記：どうやら、最後の営業運転は「急行さよならこころ」という列車だったらしいです。 |
| 2003年10月13日(月) カラオケ |
| 久しぶりにカラオケに行ってきました。 カラオケの鉄人というところで、統合システムだがメーカーを選び、さらにメーカーネイティブな番号を入力するタイプなので、新譜であっても調べていけば歌える点がSigmaより優れている。統合化されてるシステムはneon, CyberDAM, HyperJOY, Prologue21(SEGA), X-2000, U-kara3, B-kara, songokuと８種あり、NET7000とLavca以外全ての通信カラオケが利用できるようだ（今ウェブページを見たらLavcaも歌えるらしいが未確認）。 気になったこと。 「一球さん」（一球さんのエンディングテーマ）がDAMに入っているのだが、この統合システムの歌本では「一休さん」になっていた。しかも、この曲を演奏させると「一休さん」の絵が背景に出て来たあたり、結構ショックだった。 |
| 2003年10月14日(火) 「半角カナ」をネットワークで使用することについて | |
はじめに若いころ「インターネットでは半角カナを使ってはならない」と良く言われたものです。しかし、インターネットをとりまく状況が変化してきたことから、現在の規格を考慮した上でこの問題についてもう一度考えてみることにしました。日本語の表示当初、コンピュータで文字をあらわすのに1文字を7ビットで表す方法が標準化された。つまり文字コード0〜127の範囲のASCII(ISO 646)コード表である。アメリカ人にとってはこれで十分だった(オクテット中、最上位の第８ビットが保存されない、つまり8ビットクリーンでないソフトウェアが多数開発されてきたのは、これが理由である)。しかし、それ以外の国では不十分だったから、様々な拡張がなされた。当時のコンピュータ資源からすると、1文字を1オクテットで表すというのが自然だったので、8ビットすべてで256種類の文字を用いる文字コードが作られた。互換性を考え、その文字コードのうち0〜127についてはASCIIに準じ(記号の一部：例えば＼が￥になっているような違いがあるにしても)、128〜255に各国独特な文字を入れることとした。例えばラテンの国々では、ウムラウトやアクセントの付いたアルファベットを利用するためにlatin-1(ISO-8859-1)などのコードが生まれた。そして日本ではJIS C6220(後にJIS X0201)という文字コードが生まれた。半角カナは、この拡張部分に存在する。 「半角カナ」という呼び方についてプロポーショナルフォントが一般に利用される世の中で「半角カナ」という言葉に意味があるかどうか、という議論がしばしばなされているが、IANAで「csHalfWidthKatakana」という言葉を利用していることから、ここでは「JIS X0201の右半分」を半角カナと呼ぶことにする。インターネット(全般)における半角カナの利用IANAでは、インターネットで利用できる文字コードのセットのリストを配布している。これを書くのに参照した2003/9/19版によると、日本語の文字を表すのに以下の文字コードのセットを利用して良いことになっている。 Windows-31JというのはShift_JISにNECやIBMの特殊文字を加えたものである。良く�機↓兇箸い辰織蹇璽淇�字や� ↓△里茲Δ福�の中に数字の入った文字を「機種依存文字」として嫌うことがあるが、実は「charset=Windows-31J」と指定すれば問題なく利用できるのである。 Windows-31Jの文字セット とはいえ、限定利用と明記されているのであまりおすすめできないので以下の議論では除外することとする。 上記4つの文字コードのうち半角カナを含まないのはISO-2022-JP, ISO-2022-JP-2の2つだけ。逆に言えば、これら以外の文字コードを利用する限り、半角カナを使ってかまわない、ということになる。 しかしながら、半角カナを利用しない方が良い、という事情もいくつかある。
なお、ISO-10646-UCS-2,4やISO-10646-UTF-1,7,8,16,32 (Unicodeに関連するもの)では半角カナは問題なく利用できる。ただし、これは他のコードとの互換性のために設けられたものとされているので、積極的に利用すべきものかどうかは疑問。 電子メールの場合RFC 822によると、利用できる文字は文字コードにして10進数で0〜127の範囲と明示されている(さらに、これを置き換えるRFC2822ではascii code 1〜127と、0を除くように変更されている)。これは、sendmailのようなMTAが当時、8ビットクリーンでなかったためにこのような規格となり、互換性に問題が生じるため今となっては修正できないということだろう(推測)。よって、JIS X 0201をそのまま利用する限り、128〜255の領域を用いる半角カナをそのまま利用することはできない。いずれにせよ、電子メールで日本語を利用する場合、128文字では全然足りないので1文字を表すのに2バイト以上を用いる。具体的には以下の文字セットが良く使われている。
前者の場合、第８ビットを使わずに日本語の文字を表すことができるため、特にエンコードを要さないのが利点であり、日本語で書かれたメールのほとんどはこの文字セットを利用して送受信されてきている。もともと、この2つの文字コードは電子メールなどのメッセージ用として作られたものであり、RFC822の制限を意識して作られたのだから当然と言えよう。 さて、ISO-2022-JPはRFC 1468で定義されているが、1 byteコードとしてはJIS X 0201の「左半分」と明記されている。これはRFC 1554で規定されるISO-2022-JP-2も同様であり、これらの文字セットには半角カナは存在しない。存在しないものを利用できないのは当然である。 一方、後者の場合には8ビットすべてを用いる、つまり文字コードにして0〜255すべてを利用するため、何らかの方法(BASE 64ないしQuoted-printableが適切だろう)でエンコードし、文字コードを1〜127の範囲におさめなければならない。つまり、Shift_JISなりEUC-JPなりを用い、エンコードした上で電子メールを送信するのであれば、そのメッセージ中に半角カナが含まれていても(上で挙げた問題はあるにせよ)問題ない、ということになる。 ＃ただし、受信者がデコードしてまで読みたいかどうかは別問題。私なら読まずに捨てるだろう。 結論WWWページやIRCなどで半角カナを使うのは、そこで利用されている文字コードがISO-2022-JPまたはISO-2022-JP-2でない限り問題ありません。しかし、先に挙げた問題を考慮するとutf-8にするのが妥当でしょう。電子メールでは、RFC 2822が幅をきかせている限りISO-2022-JPかISO-2022-JP-2がメインに使われ続けるでしょうから、半角カナは利用できないと考えるべきでしょう。ただし、将来 8BITMIME(RFC 1652)やBINARYMIME(RFC 3030)のような規格が一般に利用されるようなことになれば、utf-8などが電子メールのメッセージとして普通に、かつエンコードなしに利用されるようになるでしょう。その時には堂々と半角カナも利用できるようになるかもしれませんが、しかしながらUnicodeの半角カナはあくまで後方互換性のためにあるため、その時には使用すべきでない文字とされているかもしれません。 参考： |
| 2003年10月16日(木) 最期の言葉占い | ||||||
あんよさんところからあなたがつぶやく最期の言葉。
いや、この結果の方がなんだかわからないんですが… さらに続き。 総合運：
今の睡眠薬はほとんど死ねないはずなんですけどねぇ… 仕事運：
金銭運：
恋愛運：
ラッキーワード：
これってどうよ？ 追記。この人と同じだった。かなり鬱。 |
| 2003年10月21日(火) P2Pの制限について |
| かつて、インターネットの帯域を最も多く使っていたサービスは、FTPだった。 「普通の」ユーザがISP経由でインターネットを利用できるようになり、HTTPのトラフィックが増加した。 そして、現在ではP2Pが相当の部分を占めるようになってきている。 P2PがFTPやWWWと大きく異なる点として、サーバ管理者やネットワーク管理者が制御しにくい点が挙げられるだろう。つまり、FTPやWWWなら（普通は）L4、つまりポート番号で判断できるため、いわゆる一般のトラフィックと分離するのが容易であり、FTPやWWWに対しては広帯域だがレイテンシの大きなネットワークを利用させるような制御が可能である（これにより回線費用が節約でき、また他の顧客へのサービス低下を防げるかも知れない）。しかし、P2Pはその歴史からしても「アングラ」なものであり、できるだけ目につかないような挙動をする（例えば、あるP2PソフトはDNSで使われる53/udpを用いて通信するらしい。これはL4での制御が不可能であることを意味する）。 一方、P2Pという技術自体には別の可能性がいくらでもあるだけに残念なことだが、P2Pは著作権侵害を助長するためのツールであるという認識が広く持たれている。よって、「P2Pのトラフィックは制御したいけど技術的に難しい」というのが多くのISPの本音ではなかろうか。 さて、大手ISPのぷららでは、次のようなサービスを開始するらしい。 この記事によれば、上りトラフィックの50〜70%がP2Pによるものであり、また約90%が別のISPからの要求によるもの、とのこと。まぁ、P2Pのトラフィックが多いことはISPにとって宣伝にもなり得ないので、制限していくのが良いんでしょうね。私としては、すべての大手ISPがこれをやってくれたらうれしいかも知れない。 技術的な話としては、JANOGメーリングリストによると、例えばEllacoyaのスイッチではP2Pを判別、制御することが可能らしい。 パケットを内部解析することでP2Pのトラフィックかどうかを判別するしかなさそうなので、以下のような問題が考えられる。
もっとも、誤検知などの可能性があるから「停止」でなく「制限」なのでしょうが。 とりあえずはしばらく様子見でしょうか。 |
Akiary v.0.42+puni.net patch 0.3