日記
バックナンバー

[先月] [目次] [来月] [最新版] [表トップ] [裏トップ] [digest]

2003年10月1日(水) ダイヤ改正
今日、JR各社のダイヤが改正されました。
東海道新幹線品川駅開業ということですが、品川折り返しはないようです。東海道新幹線の本数上限が東京駅の折り返し能力の不足によると言われていたのでやや意外。多客時の臨時は品川折り返しになるのかも。
しかし、それよりおおきかったのは165系全廃だったかも。165系というのは1963年に登場した国鉄の急行型電車で、急行が減った後も昔の(ムーンライトながらになる前の)大垣夜行とかムーンライトえちご(今年3月まで)に使われていましたが老朽化はげしく、9月28日の「臨時快速こころ」を最後に全廃となりました(一部私鉄には譲渡車両が残っているようですが)。数日前に最後の167系も解体されたらしいので、これをもって153系(旧91系)から始まる急行型直流電車が全廃(あと廃車回送が数本あるらしいですが)になるようです。1つの時代が終わった感じを強く受けました。

今日のお菓子:


追記:どうやら、最後の営業運転は「急行さよならこころ」という列車だったらしいです。
2003年10月13日(月) カラオケ
久しぶりにカラオケに行ってきました。
カラオケの鉄人というところで、統合システムだがメーカーを選び、さらにメーカーネイティブな番号を入力するタイプなので、新譜であっても調べていけば歌える点がSigmaより優れている。統合化されてるシステムはneon, CyberDAM, HyperJOY, Prologue21(SEGA), X-2000, U-kara3, B-kara, songokuと8種あり、NET7000とLavca以外全ての通信カラオケが利用できるようだ(今ウェブページを見たらLavcaも歌えるらしいが未確認)。

気になったこと。
「一球さん」(一球さんのエンディングテーマ)がDAMに入っているのだが、この統合システムの歌本では「一休さん」になっていた。しかも、この曲を演奏させると「一休さん」の絵が背景に出て来たあたり、結構ショックだった。
2003年10月14日(火) 「半角カナ」をネットワークで使用することについて

はじめに

若いころ「インターネットでは半角カナを使ってはならない」と良く言われたものです。しかし、インターネットをとりまく状況が変化してきたことから、現在の規格を考慮した上でこの問題についてもう一度考えてみることにしました。

日本語の表示

当初、コンピュータで文字をあらわすのに1文字を7ビットで表す方法が標準化された。つまり文字コード0〜127の範囲のASCII(ISO 646)コード表である。アメリカ人にとってはこれで十分だった(オクテット中、最上位の第8ビットが保存されない、つまり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版によると、日本語の文字を表すのに以下の文字コードのセットを利用して良いことになっている。
  • ISO-2022-JP (RFC 1468)
  • ISO-2022-JP-2 (RFC 1554)
  • Shift_JIS
  • EUC-JP (正式にはExtended_UNIX_Code_Packed_Format_for_Japanese)
  • ISO-10646-UCS-2,4
  • ISO-10646-UTF-1,7,8,16,32
  • Windows-31J (ただし限定的にしか利用できない)

Windows-31JというのはShift_JISにNECやIBMの特殊文字を加えたものである。良く機↓兇箸い辰織蹇璽淇字や ↓△里茲Δ福の中に数字の入った文字を「機種依存文字」として嫌うことがあるが、実は「charset=Windows-31J」と指定すれば問題なく利用できるのである。

Windows-31Jの文字セット

とはいえ、限定利用と明記されているのであまりおすすめできないので以下の議論では除外することとする。

上記4つの文字コードのうち半角カナを含まないのはISO-2022-JP, ISO-2022-JP-2の2つだけ。逆に言えば、これら以外の文字コードを利用する限り、半角カナを使ってかまわない、ということになる。

しかしながら、半角カナを利用しない方が良い、という事情もいくつかある。
  • EUC-JPの場合、半角カナは2バイトコード(0x8ea1〜0x8edf)になっている。しかし、後付けだったらしく、実際には実装されないことが多かったようだ(最近は実装されていると思うが)。よって正しく表示されないことがある。
  • 1998年に策定されたJIS X 0208:1997においてShift_JISが正式に規格化された一方、半角カナについては近い将来廃止する旨書かれた。
  • 漢字コードを自動判別に頼っている場合、半角カナが入った文章はEUC-JPと誤認識される危険性がある。サーバなどできちんと文字コードを指定するのが筋だとは思いますけどね。

なお、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バイト以上を用いる。具体的には以下の文字セットが良く使われている。
  1. ISO-2022-JP、ISO-2022-JP-2
  2. Shift_JIS、EUC-JP、UTF-8

前者の場合、第8ビットを使わずに日本語の文字を表すことができるため、特にエンコードを要さないのが利点であり、日本語で書かれたメールのほとんどはこの文字セットを利用して送受信されてきている。もともと、この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日(木)  最期の言葉占い
あんよさんところからあなたがつぶやく最期の言葉


もう、何がなんだかわからない
オーバードーズ、朦朧とした意識の中(推定年令:不明)


いや、この結果の方がなんだかわからないんですが…
さらに続き。

総合運:

あなたは実に崇高な魂の持ち主です。たとえ満員電車で寿司詰状態であったとしても、閉じられたあなたの眼の裏では、壮大な大宇宙が広がっているのではないでしょうか。あなた独自の生命論、世界観はなかなか聞き応えのあるもので、密かなファンも少なくないことでしょう。ただし、お酒の席での披露は禁物ですよ。
そんなあなたの最期は、ずばり、オーバードーズ。眠りの前に瞑想をする習慣が災いして不眠症ぎみなあなたは、つい飲みすぎた睡眠薬によって永遠の眠りにつきます。枕もとに重ねられたツルゲーネフやニーチェの背表紙が徐々にぼやける中、『もう、何がなんだか分からない』と解かれなかった己の人生の真理をつぶやきます。

今の睡眠薬はほとんど死ねないはずなんですけどねぇ…

仕事運:

凝り性なあなたは、学者肌なのですが、熱しやすく冷めやすいという生来の性格上、デイタイムは堅実な仕事に、アフターファイブは趣味にと、二足のわらじを履くのが良いでしょう。定時の仕事が引けてからは何をしようとあなたの自由ですが、法治国家に暮らすことをお忘れなく。


金銭運:

あなたはお金にシビアな星回りのようです。上手くお金と付き合っていると思っているようですが、ある意味、お金は生き物です。使い方一つで着実に増やした貯金額もパアとなる事も。もう少しお金を使い慣れる必要があるのかもしれませんね。そうそう。白蛇の夢を見ると金運がアップするらしいですよ。


恋愛運:

あなたにとっては、恋人としての他人の気持ちほどどうでも良いものはないのかもしれませんが、それはあまりに寂しすぎやしませんか? つれないあなたを慕う恋人のことをもう少し考えてあげることで、きっとあなたの囚われているレーゾンデートルから開放されるはずです。


ラッキーワード:
『Go ! My Way』 (家を出る前に鏡に向かってつぶやくとラッキー度、更にアップ!)


これってどうよ?

追記。この人と同じだった。かなり鬱。

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のトラフィックかどうかを判別するしかなさそうなので、以下のような問題が考えられる。
  • どの程度の効果が上がるのか?
  • P2P以外の通信の速度(帯域、レイテンシ)はどうなるのか?
  • 誤検知はないのか?あるなら、どの程度の確率か?
  • P2P側で対策される可能性は?
  • 通信傍受にあたるのか?
  • P2Pトラフィックを止めた場合、これが電気通信事業法第3条の「検閲」にあたるのか?


もっとも、誤検知などの可能性があるから「停止」でなく「制限」なのでしょうが。

とりあえずはしばらく様子見でしょうか。

[先月] [目次] [来月] [最新版] [表トップ] [裏トップ] [digest]

mimori@puni.net

Akiary v.0.42+puni.net patch 0.3