水無月ばけらのえび日記

検定で GO!

「インターネット ルール＆マナー検定 (rm.iajapan.org)」。話題のようなので、みぃはぁな私は早速「信頼済みサイト」に登録してチャレンジしてみました。

※「信頼」するのはスクリプトを有効にするためです。ちなみに、フォームの submit ボタンのようなものは実際には submit ボタンではありません。そのため、IE6 でもパスワードのオートコンプリートが利用できないという結構つらい罠があります。

いろいろな意味で難問揃いです。私が特に悩んだのはこれ。

消去法で考えました。まず、明確に判断できるのは 4 です。半角カナが「インターネットの標準」に含まれているかは客観的に判断できます。

※見た瞬間に「インターネットの標準」とは何なのかという疑問が湧く人もいるでしょうけれど、実は設問 17 に「インターネットで使われる技術の標準を記した文書は」という問題がありました。その選択肢は GNU, RFC, ISO, XML でした。答えは GNU や XML ではあり得ませんし、ISO は組織であって文書ではありませんから、問題作成者は「インターネットの標準」たる基準を RFC に求めているものと思われます。ここではそれを前提として考えています。

さて半角カナですが、これは ISO10646 (Unicode) の基本多言語面に "halfwidth-katakana-letter" として定義されている文字で、UTF-8 (RFC2279) でも UTF-16 (RFC2781) でも問題なく表現することができます。ISO に根拠を求めても、RFC に根拠を求めても、半角カナが「含まれている」ことは明確です。これが「インターネットの標準」に含まれることは間違いないでしょう。よって 4 は消えます。

ただし、話をインターネットメールに限るなら 4 が正解となる可能性はあります。日本語のメールでは、今でも文字符号化方式は ISO-2022-JP (RFC1468) が主流です。ISO-2022-JP では、そもそも半角カナが表現できません。にもかかわらず、それを無理やり独自の符号化で表現しようとするメーラが存在していて、そのため半角カナを使用すると文字化けして読めなくなることがよくありました。しかし、これは特定のメーラの実装に関する問題に過ぎませんし、UTF-7 (RFC2152) で符号化したメールで半角カナを使用するという選択肢もありますから、やはり「インターネットの標準」に半角カナは含まれることになるでしょう。

これで 4 が消えましたので、次に 2 について検討します。文字が小さくて読みにくいかどうかは、ユーザのフォントの設定などに依存する問題です。実際、「MS UI ゴシック」などでは全角のカタカナも半角のカタカナも大差ありません。濁点や半濁点が文字と独立しているのが読みにくい、という話を聞いたことがありますが、選択肢 2 はあくまで文字の大きさだけを問題にしていますから、違うでしょう。

これで 2 が消え、残ったのは 1 と 3 ですが、実はどちらにも論拠があります。ISO 10646 は「一つの文字には一つのコードポイントを割り当てる」ということを前提としています (そのために「似たような文字」がくっついてしまったりしていますが、それはまた別の話)。この原則からすると全角と半角は一つにまとまるべきなのですが、既存の符号化方式との変換の際に支障が出るという理由で、あえて半角カナを定義しています。つまり以下のようなことが言えます。

• 本当は一つであるべき (全角と半角の2つは必要ない)
• 過去に使われていた符号化方式との互換性のために用意されている (半角カナは時代遅れ)

こう考えると 1 と 3 のどちらも正しいのですが、後者についてよく考えてみると、Shift_JIS や EUC-JP などは本当に過去のものなのか、という疑問が湧きます。UTF-8 が使われる場面は増えてきましたが、現在でも Web サイトの多くは Shift_JIS や EUC-JP などで符号化されています。

これで 3 が消え、1 が残りました。自信をもって回答したのですが……。

やってもうた。

……いや、いちおうそういう (出題者がショボイという) 可能性も考えないではなかったのですが、「JIS X 0201カナ集合」なんて言葉が使われているので、出題者は JIS 規格や ISO 規格や RFC などの内容には精通しているのかなと思ってしまったりした次第でありまして。

※しつこいようですが明確に宣言しておきますと、HTML の仕様は文字符号化方式を ISO-2022-JP に限定などしておらず、むしろ RFC2854 などは明確に UTF-8 を推奨しています。そして前に述べたとおり、UTF-8 では半角カタカナが表現できます。使うべきかどうかはまた別の話ですが、少なくとも「RFC に含まれていない」というのは完全に誤りといって良いでしょう。

あとついでに、私が自信を持って間違えた問題。

ファイルをダウンロードしても、それが自分の環境で利用できないものだったら意味がありません。特に動画や音声にはファイル形式がたくさんありますから、必ずしも再生できるとは限りません。ファイルが大きければそれだけ「ダウンロードしたけど再生できなかった」時のダメージは大きくなるでしょう。サイズも重要ですが、それ以前にまずファイル形式を明示しなければお話になりません。

こう考えて、自信を持って 1 を選択。

……ひょっとして考えすぎなのでしょうか、私。

もうひとつ。

分かりやすく (?) 言い換えると「メールヘッダの Date: フィールドはどの時計に依存するか」という問題です。これは最初に SMTP を喋ったものが設定しているはずです。

LAN など組まれておらずスタンドアローンで稼働している Windows + Outlook Express というようなクライアントマシンを仮定すると、メールクライアントはそのマシンの設定時刻を元に Date: を生成して SMTP に渡すことになるでしょう。従って Date: の値はクライアントマシンの時計に依存します。

しかし、telnet でメールを読んでいるような人 (犀川先生?) などを仮定すると、その人はログイン先のサーバ内で MUA を起動して使っているわけで、送信時にはそれがそのままサーバ内の MTA にメールを渡すことになります。この場合は telnet 端末側の時刻設定など全く関係なく、サーバの時計が使われるでしょう。そんな極端な例でなくても、グループウェアを使っている場合はグループウェアのサーバが SMTP を喋りますから、クライアントの時計ではなくサーバの時計が使われます (これは実際に Microsoft Exchange Server が導入されている環境で確認しました)。

普通はまず前者を想定するところですが、私の念頭には何故か後者の例しか出てきませんでしたので、迷わず 4 と答えてしまいました。きっと犀川先生のせいだと思いますが、それはともかくとして、用意されていた正解はこんな感じでした。

ああそうね、と一瞬思いましたが待ってください。3 (過去からのメール) ではなく 2 (未来からのメール)? 設問には「実際より 3日ほど早くなっていた」とありますが、これはたとえば実際は 7月23日であるところが、時計はそれより 3日早い 7月20日になっていたということですよね。だとすると Date: は過去の日付になり、過去からのメールになるはずです。そうではなくて、「3日ほど早く時を刻んでいた」という意味だったのでしょうか？

まあ、どちらにしても私は間違えてしまったわけですが、どうして「進んでいる」「遅れている」という言い方をしないのでしょうね……？

• 「検定で GO!」へのコメント (50件)

関連する話題: 出来事 / 文字 / RFC