「via Internet」談義

URL中のチルダにまつわる話、ほか

(初出:1998年5月15日、自己顕示録

(改定:1999年1月9日)

チルダを書いていいのか悪いのか

現在のところ、URLを規定しているのはRFC1738です。

それによれば、URLの(いわいる)ファイル名/ディレクトリ名の部分にtilde「~」を書くのは仕様違反です。HTML文書ソース内では&を&と書くように、URL中では「~」を%7E(%7e? )と書くべきです。これを「URLエンコード」といいます。エンコードしなきゃいけない理由は、「一部のシステムでは、それが予約語だから」です。

でも、僕は「~」をそのまま書いています。なぜかといえば、そのエンコードはUAが行うべきだと思われるフシがあるからです。

「エンコード」であるがきりは、その結果は「符号化」されたものであり、「生」ではありません。そして、URL本来の姿は「生」のほうのハズです。「生」から「エンコード結果」を生成するのは機械的な仕事であり、まさにUAの仕事だと考えられます。

しかし、「HTML文書中にはURLは生に書いておけばよい」と断言するだけの根拠もなかったので、これまで明言は避けました。だが、どうもこの姿勢でOKだといえる根拠らしきものを発見したので、明言することにしました。


余談

HTMLの&は「実体参照」(Character entity references)というもので、符号化とはちょっと事情が違います。

実体参照は、特定のキーワードを別のものに置換する仕組みで、(1)入力できない記号を別名で記載する、(2)国によって表記が違う記号を統一的に記載する、ような場合に使うものです。たとえば、「コピーライトを意味する(c)マーク」は通常のキーボードでは入力できません。それを表示するためには、HTMLソースには&:copy;とかいておけば良いのです。こうすれば、貴方のブラウザでは「©」と表示されます。

(注:WINのIE4.0ではグラフィックで○の中にcの文字が表示されました。Mozは半角で「(c)」と表示しました。)

実体参照として採用されているキーワードは、HTMLの仕様書に明示されています。


根拠は、INTERNET-DRAFTのdraft-fielding-uri-syntax(Uniform Resource Identifiers:version02、March 4, 1998)です。この仕様によれば、明確に「(ファイル名/ディレクトリ名として)使ってはいけない」のは、「<>#%{}|\^{}`」です。RFC1738では「unsafe」であった「~」は、こちらではたんなる「unreserved」です。

さきに「ダメ」としてあげた記号には、特別な意味が用意されています。たとえば、../i_net/term.html#uaですね。この#は、httpにおける「ファイル名とid名のデミリタ」専用の記号として予約されており、ファイル名の一部には使えません。こちらはURIの都合であり、「絶対」です。

一方、「~」などは他のシステムの都合であるわけです。今回の仕様書では、「unreserved」は「絶対にOKという確証は与えられない記号」であり、「エスケープが必要なシステムを通過する場合は、そのシステムが自動的にエスケープするべし」となっています。つまり、ユーザは「生」のURLを書いておけばOKなわけです。

In some cases, data that could be represented by an unreserved character may appear escaped; for example, some of the unreserved "mark" characters are automatically escaped by some systems.

ドラフトとはいえ、このドキュメントはRFC1738を「上書き」する予定です。無視する必要はないでしょう。

というわけで、私は生で「~」を書きます。


RFCは不変じゃない

RFCといえば、この業界の事実上の標準規定文書だ。でも、RFCは「絶対」ではないことに注意。たとえば、古いRFCは新しいRFCに「上書き」され、無効になることがある。また、実装のデファクトスタンダードとRFCがあまりに異なっている場合、残念ながら、そのRFCに有効性はない。理論よりも現実のスタンダードが強い。(なお、もともとRFCは、現実のデファクトスタンダードを後から「つじつまを合わせられるように調整して」仕様にまとめたものが多い。)

実効性のないRFC記述の最たるものが、URLの「~」だったんじゃないかな。だから、新しい仕様によって、実際に合うように修正されるのは望ましいことだ。

注:これは変な妥協じゃないんだよ。UAの仕事をきちんと位置づけて、ユーザの仕事を減らしただけなんだから)

では、RFC1866(HTML2.0)も、実効性の無いもの? W3CのHTML仕様も意味の無いもの? いや、違う、「技術の仕様/技術の実装」のズレと、「言語の仕様/言語プロセッサ(パーサ、インタプリタ)の実装」のズレでは、意味合いが違う。プロセッサ(パーサ、インタプリタ)にあわせて言語仕様を修正するのは本末転倒だ。というわけで、僕のHTMLに関する主張は変更しないことにする。

なお、RFCの原文はInterNICにあるが、各所にミラー(複製保管)されており、たとえばRingServerからも入手できる(http://www.ring.gr.jp/http://ring.nacsis.ac.jp/)。

URIとURLの違い

URIは"Universal Resource Identifiers"(RFC1630)の略で、ずいぶんザルな「汎用情報ポインタを作ろうぜ」っていう掛け声だけっぽいもの。それを具体的にしたものの一つがURL(RFC1738)。URNというのもあるらしいが、よく知らない。現段階では、URI = URL + URNと捉えればよいようだ。

1998年から、W3CはURLという呼称をSTOPさせて、すべてURIと呼んでいる。でも、僕はこの姿勢に反対。どうして限定できる話題を、わざわざ抽象論に押し上げなければならないの? それは、「人間」の話題の文章に書かれた「人間」という単語を、わざわざ「哺乳類」と書き直すようなものではないだろうか? 

だが、前述のドラフトがRFCに昇格し、「URI(UniversalからUniformに変身)」という単語に実効性のある仕様ができ、URLという名称が廃棄されるのであれば、まあ、そうすることに反対はしない。でも、既に浸透しているURLという名称を捨てるのはもったいないと思うけどなあ。






ご意見ご要望及び苦情はE-MAILにて

e-mail to : jy3k-sm#!#!asahi-net.or.jp