文書(コンテンツ)のメタ情報の扱いに関する話その３です(その１、その２)。前回までで、必須であり、切り離すと文書自体が成り立たない(読めない)ような情報は、文書に埋め込むべきではない、と結論しました(*)。
*:こういう書き方だと、必須なら文書と一緒になってないとまずいじゃないか、と思ってしまいますが、それはそのとおり、ただ本文と明確に切り離せて、安全に読み込める必要があるというのが前回の話です。
最終的に、「メタ情報はコンテンツに埋めこむべきか外部に置くべきか」という話にしたいと思って書きはじめていたので着眼点がそっちに触れていますが、正直、指針を出すのが難しい問題なので、書きながら整理中であるというのが実情です_o_。
どうも、このような、本文ダイジェストと署名の突合せをするだけでも、それに意義があると思っている開発者がけっこういるようだ。たしかに、悪意がない状況で、通信路上で一部が書き換わったものを検出することはできるだろう。 だが、それがしたいのなら公開鍵暗号なんて使わなくていい。チェックサムでも使っておけばいい。
移転作業お疲れ様でーすってことで、はてながプライベートモードになっていてまだ読めていなかった記事を引っ張ってきて感想を。
チェックサムに該当するのは Content-MD5 あたりですが、既に述べられているとおり、このヘッダなどは事故の防止程度であり、悪意に対しては無力ですね。
証明書検証なしで署名手続きだけが正当であったかを確認するのは、確かに、Content-MD5 と本文を検証するのと同じ程度の行為。
まぁ、S/MIME なメッセージに Content-MD5 を付ける送信元はほとんどないでしょうから、事故防止目的であっても S/MIME の署名照合をするだろうな、とは思います。それだけだと 「S/MIME 対応」等とは断じて言ってはならないのですが。
誰が署名したかははっきりしないけど、内容は署名した人によることは間違いないですよ機能。いや、署名した人が不明な場合は後者すら保証はできないか…。やっぱり、通信路上での「事故」防止機能でしかないですね。いまどきそれは少ないと思いますけど。
先の記事(メタ情報の扱いに関する話)を前提として。
さて、ここで唐突にトラックバックなんぞを見てみます。トラックバックは MovableType が独自に実装した「実装先行」の仕様であり、当然当初は日本語に対する考慮なんてありませんでした。でも、今はそこそこ正しく日本語を含むトラックバックが送受信できています。でも、一部のサイトにはトラックバックを送ると文字化けが起こるということが未だに発生しています。これはなぜでしょうか？
まぁ、海外からやってきた技術は全般的にそうなので仕方がないという話でもありますが、センスの悪い解決方法しか取れていないからです。とはいえ、こうなってしまう根本的な問題はトラックバック以前に HTTP、というより HTML(FORM) の仕様にあるのですが。
現在は、POST するデータ内部に charset=EUC-JP;title=.... のように記述する方式が言われています。これは前回書いたとおり、センスの悪い方式です。トラックバック程度であれば charset パラメタを探してから全体を再デコードするのも対して苦ではないため、まだよいですが。
本来はリクエストヘッダにて charset が指定されるべきですし、それで容易に解決できるはずの問題でした。しかし HTTP リクエストに関してはいつまでたってもその方式を取らずに、application/x-www-form-urlencoded という文字エンコードに関する規定のない(なかった)方式を世界中で使っているのです。それによって、リクエストボディを読み込むために必須のメタ情報であるはずの文字エンコーディングが、いったいどこを見たらいいのか解らないという混乱がずっと続いています。
トラックバックの文字コードに関する約束はセンスが悪いですが、通常の POST ではまったく規定のない最悪の状態であることを考えるとまだマシというわけです。つまり、問題は HTML(FORM) の仕様にあるわけです。
他の例も少しだけ挙げます。必須のメタ情報がコンテンツに埋め込まれている例としては、メジャーな物として画像フォーマットなどにおける MAGIC があります。たとえば GIF 形式のファイルをバイナリエディッタなどで開くと先頭が "GIF87a" 等となっていたりします。これはそのファイルが GIF であることを識別できるようにするためのものですが、前記事の前提に則ると、やはり本来ここにあるべき物ではない、と言えます。しかし、コンテンツ以外の部分から常にこのメタ情報が入手できるか、というと、そうもいかないケースも多いことから、現在はほとんどのマルチメディア系コンテンツが採用している方式です。前記事で言うところの「情報をひとくくりにするというメリットとのトレードオフ」なのです。
この例を由とするなら、前記事の meta タグの件や今回のトラックバックについても許せる話じゃないか、と言われそうですが、やはりそれぞれ以下の問題からこの二つは画像フォーマットのようなケースと同一視できないセンスの悪さを感じます。
リクエストボディ(QUERY_STRING はまた別として)のエンコーディングは、慣習に沿った普通の感性ならリクエストの Content-Type にて明示されるべきものに思えます。しかし、POST でデフォルトで用いられる application/x-www-form-urlencoded というメディアタイプでは事実上 charset パラメタを付けてはいけないとされてしまっています。現在は HTTP-POST でリクエストの文字エンコーディングを明示したい場合は multipart/form-data を用いろ、と言われていますが、それを守っているブラウザは現状は皆無でしょう。
これ、実はメジャーなブラウザがポンっとサポートしてしまえば一気に解決できるのではないかと思えるのですが、何年たっても一向に状況に変化がないようですね。application/x-www-form-urlencoded ではなく、text/x-www-form-urlencoded にして charset を指定する、とか、ブラウザ側がやったとしても大抵のサーバにはいきなり影響が出ることはないわけだし…あんまり考えてはいないですが。
というか、IANA には未だに登録されていない(multipart/form-data はあるのに)し、HTML 仕様の方でしか規定されていないのってなんなのよ。
参考：application/x-www-form-urlencoded
現実には携帯電話などは application/x-www-form-urlencoded; charset=Shift_JIS といったこともやるようです。私はそれでよいと思いますけどね。XForms では UTF-8 を使うことと書かれていますが過去との互換性を考えるとまだまだ移行は厳しいでしょう。
このあたりに関連する話は、[XML-users-8594] から続くスレッドでも以前詳しく議論されていました。
このようなメタ情報に関する約束は、最初に拡張性のある方式が取られていることと、最初にサポートする人にセンスがあることが如何に肝心であるかを感じさせます。
(追記)
書いた直後に発見。
Trackback I18N: blog.bulknews.net
お、現在は(Content-Type の) charset パラメタを付けるようになってるんですかねぇ…？それなら大歓迎ですが。日本での実装的には UTF-8 / EUC-JP しかなさそうで、今後は UTF-8 決め打ちに進むんでしょうけど EUC しか受け付けてないサーバは…サポートしてもらうしかないでしょうな。
小ネタです。
たとえば HTML で <meta http-equiv="Content-Type" content="text/html;charset=UTF-8" /> のように書くことの意味は、「この文書は HTML であり UTF-8 (と言う文字コード形態)で書かれています」と宣言するということです。これは文書の内容ではなく、その文書自体がどういうものであるか、という「メタ情報」です。だから、meta タグな訳ですが
で、この情報の中で、「UTF-8 である」という部分に関しては、その情報が無いとこの文書自体をまともに取り扱えない可能性がある重要なものです。ここの記述ミスによる文字化けはちょっとネットを見回っている人であればそこらじゅうで見聞きしますね。
しかしそもそもメタ情報というのは、文書そのものに埋め込まれるようなものではないです。なぜならこれは「その文書がどのようなものであるか」という情報な訳ですから、それが文書の中にあるのでは、いくら「自分はこれこれな属性を持った文書です」と言ったところで、その部分を読むより前の部分では、読み込んだアプリケーションはそのメタ情報のことを知らないでいるわけですから。
たとえば、以下のような HTML を書くと簡単に文字化けを起こします。
<html> <head> <title>UTF-8 で書かれたタイトル</title> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> </head> <body> :
「この文書は UTF-8 で書かれています」という宣言の前に UTF-8 で書かれたタイトルが読み込まれて処理されてしまうのです。
まぁ、いくらでも処理のしようはある、という意見も聞こえそうではありますが、大抵はある地域を前提にした解法であり、十分に汎用的な手法ではなかったりするので困るなぁ、というのが今回の趣旨なのですが。
上記の場合は、根本的な解決としては、meta タグのそもそもの存在意義である、「あるコンテンツに特化した HTTP ヘッダの指定」を忠実に守って、meta タグに書くような内容を HTTP サーバが適切にレスポンスヘッダにて返却しさえすれば良い話です。現在は現実的では無いということでサポートされていませんが、代わりに .htaccess という仕組みなどを使うことができます。
以下は文書と文書のメタ情報が切り離されている例です。
: ─┐ Content-Type: text/html; charaset=UTF-8 │ヘッダ Content-Length: 10234 │ Transfer-Coding: chunked ─┘ <html> ─┐ここからが文書本体 <head> ↓ <title>UTF-8 で書かれたタイトル</title> </head> <body> :
これなら、ヘッダ部だけを見て文書がどのようなものであるかが解るので、それに従って文書を適切に読み込むことができます。逆に言うと、ヘッダを見ないでコンテンツだけを解釈するのは難しいです。
これはいわゆるプロトコル全般に関する基礎知識です。すなわち、機械的に解釈できるように、どのようなものであるかを宣言してからそれを送る、という。上記では「ヘッダ」と呼びましたが、別のプロトコルでは「エンベロープ」つまり「封筒」と呼ばれたりもする部分です。封筒と中身は別の物、封筒の内容と中身が同時に書かれているのは、言ってみれば「葉書」ですが、葉書は宛先を書く部分と本体部分が容易に区別が付きますし、宛先の部分はフォーマットが決まっているのでこれもれっきとしたプロトコルです。しかも、本文がメタ情報に依存して、メタ情報が無いと読むことすらできないというものではありません。
それに比べると、文書の中でその文書自体がどうやったら読み込めるかを記しているというのはまったく非効率でおかしな話なのです。
昨日、xml 宣言や meta タグを見て入力エンコーディングを切り替える処理を書いて、ストリーム途中からの入力エンコーディングの変更が相当に厄介な問題であることを再認識した次第-_-。文字エンコーディングはステートフルなものまであるからねぇ…。
そのようなわけで、文書自体を読み込むために必須のメタ情報が、文書中に埋め込まれているという状況が大変センスの悪いものであるということは伝わったでしょうか。情報をひとくくりにするというメリットとのトレードオフではあるのですが、上記のような明確な区切りを設けていない場合(冒頭の meta タグのようなもの)はセンスが悪いと断言できるでしょう。
まずはここまでで。
