第22回 第2部 第34問

ブックマークレットで用いられている技術として、正しいものを１つ選びなさい。

ａ． PHP
ｂ． SSI
ｃ． Java Servlet
ｄ． JavaScript

「ブックマークレットとブックマークは別物なの？」


「うん、ブックマークを利用した技術がブックマークレットなんだよ。」


「ほうほう。」


「ブックマークの使い方は知ってるね？」


「気に入ったホームページを登録しておいて、そこから開くからいちいち検索しなくても良いんだよね、便利だよね～。」

「ブックマークレットはさらに、開いた後に小さなJavaScriptプログラムが実行されて色々な事をしてくれるサービスなんだ。」

「どんな事をしてくれるの？」


「ホームページの外観を変更(文字サイズの変更とか)したり、データを集計したり、他のページ(翻訳ページとか)に飛んだり、子画面を開いたりといろいろできるんだ。」

「なんだか何でもできそうで、逆によくわからないや。」


「そうだね、たとえば、ある文章をコピーしてgoogleのページをブックマークレットで開くと検索してくれるとかね。」

「ははあ、いちいち貼り付けなくても良いのか・・・するとスマートフォンなんかだと便利かもね。」

「うん、実は携帯電話のブラウザにも使えるんだよ。」


「へ～、ってでもボクはスマホ使ってないんだった・・・。」


「うん、使うにはインストールしたり登録したりする必要があるので初心者には敷居が高かったんだねこれが。」
「なので、便利な機能はブラウザが独自につけてしまったり、同じような機能のソーシャルボタンに人気を取られてしまってあんまり普及しなかったんだよ。」

「そうだったのか～。ちょっと勿体ないね。」

【 第22回 第2部 第34問 解答＆解説 】

［解答］ｄ． 
［解説］ 
ブックマークレットは、Webブラウザで動作するJavaScriptプログラムです。利用されている技術はJavaScriptです。 

第23回 第2部 第38問

PCから携帯電話のメールアドレス宛にメールを送信したが、宛先の携帯電話にメールが届かなかった。以下の選択肢のうち、原因となる可能性のあるものを2つ選びなさい。

ａ．メール本文に機種依存文字を使用していた。
ｂ．携帯電話で受信するメールを、ドメイン指定で制限していた。
ｃ．メールに添付したファイルの容量が大きかった。
ｄ．メール本文の文字コードをUTF-8で送信していた。
ｅ．メールの１行の文字数が、携帯電話画面の１行で表示できる文字数を超えていた。

「自宅のＰＣから友達の携帯にメールを送っても届かない時があるのって、なんでかな？」

「おそらく迷惑メール関連の設定が影響してるんじゃないかな。」
「ＰＣと携帯電話でメールをやり取りする際に起こる問題としては大きく分けて、①届かない、②届いたけど正しく表示できないの二つだけど、今回は①の問題だね。」

「メールが届かない原因ってどんな事が考えられるのかなぁ？」

「届かない理由として考えられるものは、①メールアドレスが間違えている、もしくは存在しない、②迷惑メール対策がされていてメールがブロックされる、③送信するメールの容量が規定値を超えている、④受信側のメールサーバが一杯になっている、といったことが考えられるんだよ。」

「メールアドレスを間違えるって・・・・そりゃ届かないよねぇ。」

「よくあるのは、文字の入力ミスやドメインの入力ミスなどだね。」

「迷惑メール対策って・・・？」

「携帯電話なんかだと受信指定と呼ばれたり、ＯＣＮで提供している迷惑メールブロックサービスといった受信したくないメールを拒否することが出来るサービスのことだよ。」

「なるほど！僕の携帯電話もＰＣからのメールは受信しないように設定してあるよ。」
「じゃあメールの容量が規定値を超えているっていうのはどういうことなの？」

「メールには一回の送信で送れる容量が決まっていて、それを超えるメールは送信出来ないんだよ。」
「写真など容量の大きなデータをメールに添付する時には注意が必要だよ。」

「そういえば前に携帯電話から写真を１０枚くらい送ろうとした時に送れなかったのはそのせいだったのかー」

「一回あたりに送れる容量は利用しているメールによって違うから注意が必要だよ。」

「はい！」

「最後の受信側のメールサーバが一杯になっているというのは、メールサーバにメールが溜まりすぎているときに起こる現象だね。」

「どんな時に起こるの？」

「例えば長い間メールを受信しなかった時や、受信する時にメールのコピーをサーバに残すような設定をしていると起こる可能性があるね。」

「なるほど、いろいろな理由があるんだね」

「さて、設問の中からこれらの理由に該当しそうなものは・・・。」

「う～ん・・・ａは機種依存文字を使うっていういうのはさっきの理由の中に無かったし違うよね。」

「そうだね。これは携帯電話の絵文字などがそうだね。」
「この場合、絵文字が『〓』で表示されたりするけど、メール自体は受信できるから質問の答えではないよね。」

「ｂのドメイン指定で制限したというのは、携帯電話からのメール以外は受信しないとかってことだから、これは正解だね！」

「そうだね。携帯電話のメール設定でＰＣからのメールや特定のアドレスやドメインからのメールを拒否設定するとそれ以降受信しなくなるからね。」

「ｃの添付したファイル容量が大きかったというのは、さっき先生が説明してくれた理由にあったよね。」

「うん、なのでｃも正解ということだね。」

「じゃあ、残りの二つは誤りってことなんだね。」

「そうだよ。」
「文字コードというのは、コンピュータ上で文字を利用するために各文字に割り当てられるコードのことを指すんだけど、文字コードが違っていると『a?‡a-?a??a?‘ 』という風に文字化けを起こすことはあるけど、受信出来ないことはないんだよ。」

「ほぅほぅ。」

「最後のｅも、携帯電話で表示する時にはキチンと改行されるから受信出来ないわけではないんだよ。」

「答えは、ｂとｃって事で良いんだね。」

「正解！」
「この問題は、受信が出来ない理由を覚えておけば解きやすいよ。」

「わかったよ、ありがと～！」



【 第23回 第2部 第38問 解答＆解説 】
［解答］ｂ，ｃ．
［解説］
ａ．誤り。 メール本文に機種依存文字を使用していた場合は文字化けが起こる可能性があるが、受信できない理由にはならない。
ｂ．正しい。 迷惑メール防止のために携帯電話で受信するメールを、ドメイン指定で制限することが可能である。
ｃ．正しい。 添付したファイルの容量が大きい場合には、携帯電話側で受信が出来ない場合がある。
ｄ．誤り。 メール本文の文字コードの違いでメールが受信できないことはない。
ｅ．誤り。 メールに一行の文字数が多くても、携帯電話側で改行されて表示されるためメールが受信できない理由とはならない。

第22回 第2部 第33問

文字コードに関する説明として、適切なものを2つ選びなさい。

ａ．JIS(ISO-2022-JP)は主に日本語の電子メールに利用されている。
ｂ．シフトJISはMac OS X の標準文字コードとして採用されている。
ｃ．UnicodeにはUTF-8、UTF-16など複数の符号化方式がある。
ｄ．EUCは欧州の文字コードのため、日本語を表示することはできない。

「６月の模擬試験で誤答が多かった設問だ。しっかり覚えようね。」



「先生、そもそもなんで文字コードっていっぱいあるの？」


「もともとアメリカで開発されたコンピューターにはアルファベットと数字くらいしか文字が必要なかったんだ。」
「ところが、日本に入ってきたときにどうやって日本語のひらかな・カタカナ・漢字を表記させようかで問題になってね、パソコンメーカーがそれぞれ勝手に作っていったのが大元なんだ。」

「あ～やっぱりそこなんだ、はじめに規格を統一すればよかったのにね。」


「まあ、もともとネットでパソコン同士がつながるなんて思ってなかったからね。」

「JISコードとShiftJISコードは日本でよくつかわれているコードだね、特に電子メールでは『JIS(ISO-2022-JP)』が使われるので『ａ』は適切。」

「Ｍａｃ ＯＳ Ｘって、Ｍａｃはアメリカ生まれだよね。ShiftJISが標準というのはまちがいなんじゃないかな。」
「『ｂ』は不適切だよね。」

「そうだね。ＭａｃＯＳ ＸはUTF-8の一種を使っているんだ。」
「お次の Unicode は世界中の文字を収めようとした文字コードなんだ。大抵の言語は収録されているよ。」

「それはすごいね！」


「まあ、なかなかうまくいかなくていろんな派閥があるんだけどね。『ｃ』は適切だよ。」


「EUCってヨーロッパっぽいね？」


「いやいや、EUCはExtended UNIX Code の略だからユニックスコードの拡張版って意味。ヨーロッパとは関係ないので『ｄ』は不適切だね。」





【 第22回 第2部 第33問 解答＆解説 】

［解答］ａ，ｃ．
［解説］
ａ．日本語の電子メールでは、JISコードを利用することが推奨されています。
ｂ．シフトJISはMAC OS Xではなく、Windowsなどで標準的に用いられる文字コードです。
ｃ．Unicodeには、UTF-8やUTF-16など複数の符号化方式があります。
ｄ．EUCはUNIXで利用される文字コードで、日本語の表示もできます。

第21回 第2部 第32問

Aさんは「会議の日程」という件名(Subject)でBさんにメールを送り、Bさんから返信をもらった。
次にAさんはBさんから受け取った返信メールをCさんに転送した。
このとき、Cさんが受け取るメールの件名はどのように表示されるか。あてはまるものを1つ選びなさい。
なお、Aさん、Bさん、CさんともメールクライアントにはWindows Liveメールを使っており、一連のやりとりは「返信」「転送」ボタンによって実施し、だれも件名を編集していないものとする。

ａ． Fw:会議の日程
ｂ． Fw:会議の日程 Re:会議の日程
ｃ． Fw:Re:会議の日程
ｄ． Re:会議の日程 Fw:
ｅ． Re:Fw:会議の日程
ｆ． Re:Re:会議の日程



「メールを返信したことはあるけど転送したことは無いなぁ・・・。」


「返信をもらったときの件名(Subject)はどういう風になってたかな？」


「Re：という文字が付いてるよね？」


「そうだね！それは返信を表す記号なんだ」


「じゃあ転送したときも何か記号が付くの？」


「するどいじゃないか！その通りだよ。頭にFw：という記号がつくんだ」
「『Fw』はフォワードの略だよ。意味は転送だ。」

「てことは、今回の問題はまずAさんがBさんからもらった返信メールでの表示が『Re:会議の日程』で・・・。」
「そのメールをCさんに転送してCさんが見たメールの表示は さっきのに更に『Fw』が付くから『Fw:Re:会議の日程』なのか！」

「その通り！ちなみにRe：やFw：という表示はメールクライアントによっても若干表示の仕方が違う場合があるんだよ」

「どういう表示になったりするの？」


「返信の数によってRe2:とかRe3：と増えたり、Re：Re：Re：とずっと増えていったりするものもあるんだ」

「へーそうなんだぁ。この問題はメールクライアントにはWindows Liveメールとあるけど返信はRe:、転送はFw：でいいんだよね？」

「間違いないよ。記号を覚えておけばすぐに分かる問題だから覚えておこうね～。」





【 第21回 第2部 第32問 解答＆解説 】
［解答］ ｃ
［解説］
a． 誤り。
b． 誤り。
c． 正しい。
d． 誤り。
e． 誤り。
f． 誤り。

第24回 第1部 第15問

以下は、受信メールのメッセージのソースである。
これから判断できるものを2つ選びなさい。



ａ． 添付ファイルのデコードに失敗している。
ｂ． このメールには画像ファイルが添付されている。
ｃ． 添付ファイルのエンコード方式はBase64が使われている。
ｄ． このメールは、MIMEの規格に沿って送信されている。

「このメールは宇宙からのメッセージなの？」


「ははは、コムたろう君は面白いことを言うね！」
「ちゃんとした電子メールだよ。」
「普段みんなが見ているメールは、メーラー（メールソフト）が、人間の見やすい形で表示してくれているんだ。」

「本当は見やすい形じゃないってこと？」


「メールは本文だけじゃなくて、メーラーが仕事しやすいように様々な情報が詰まっているんだ。」
「普段見ている件名や本文とかはメールに含まれる情報の一部なんだよ。」
「この設問の図のように色々な情報が見える状態のものをソースって呼ぶんだ。ソースってのは『元』って意味だ。」

「そっか～。メーラーが仕事するのには必要だけど、ユーザーは意識しなくてよい情報があって、普段ボク達はそれを見てないって事なんだね。」

「そうだよ。」
「そしてもう一つ重要な話があってね。インターネットのメールはもともとテキストデータしか送れない仕様になっているんだ。」

「ええ？！画像とかの添付ファイルは送れないの？？？」


「いいや、実際には送れてるから、ちゃんと方法はあるんだよ。」
「それをこれから説明していこう。」




「メールはもともとテキストデータしか扱えないうえに、使えるのは半角英数と一部の記号のみだったんだ。」
「でもフランス語の変な記号も使いたいし、日本語や他にも独自の文字を持つ国はいっぱいあるよね。」
「使いたい文字が他にあるからと言って、それぞれの国が独自の仕様メールを送ったりすると、他所の国じゃ読めなかったりするよね。」

「あ、知ってる！文字コードってやつでしょ。」
「JISとかなんかいろいろあるやつ。」

「そうだね。画面に表示される文字って実は、コンピューターの中では文字コードっていうコードの状態なんだ。」
「OSやメーラーとかの様々なアプリケーションが、このデータの文字コードは何々だって判断して変換したうえで表示してくれているんだ。」

「思い出してきたぞ～。文字コードの判断が間違っていると文字化けするんだよね。」


「そのとおり。で、まぁそんなんじゃ外国の人とメールのやり取りするのに不便で困るよね。」
「そこで、色々と不便を乗り越えるためのルールが決められたんだ。それがＭＩＭＥ（マイム）っていう規格なんだ。」

「ふーん。この規格の登場で、色々な文字を使ってメールのやり取りができるようになったのかー。」

「ＭＩＭＥって規格には色々なルールが含まれていて、画像などの添付ファイルについての取り決めもあるんだ。」





「突然だけどＦＡＸはどうやって文字や絵を電話線で送るか知っているかな？」


「知ってる、知ってる～。原稿を読み取って、電話線に流せる形のデータに変換してるんだ～。」

「お、よく知ってるね～。その変換ってのがミソなんだ。」
「メールの添付ファイルも同じ様に、メールの扱えるデータに変換しちゃうんだ。」
「ＭＩＭＥによって、色々な文字に対応したけども、実は相変わらずテキストデータしか扱えなくてね・・・。」
「Ｂａｓｅ６４ ってエンコード方式を使って、画像や音声や他のファイルも一旦テキストデータに変換しちゃうんだよ。」

「そうか。メールの直接扱えない情報でも一旦テキストデータにしちゃえば送信できるようになるんだね！」

「そうなんだよ～。そして Ｂａｓｅ６４ て変換方法は広く使われているので覚えておこうね。」

「さて、そろそろ問題を解いていこうか」


「せんせ～、選択肢ａのデコードってなに～？」


「デコードってのはエンコードされたものを元に戻す処理のことだよ。」
「添付ファイルは一旦テキストデータに変換されるからね、実際に開いてみるには変換された状態から元の状態に戻す必要があるんだ。」

「ふ～ん・・・添付ファイルが見つからないよ？いつもはクリップのアイコンがあるんだけど・・・」

「そうだね～、これはメールのソースを見ているから、人間には分かりにくい形になっているね」
「下の方のごちゃごちゃっとした文字化けみたいなのが添付ファイルだよ。」

「ええ～？！文字化けしちゃってるの？」
「これって、ファイルが壊れちゃってるのかな？」

「文字化けしてるわけじゃないんだ。これがＢａｓｅ６４でエンコードしてテキストデータに変換した添付ファイルなんだ。」

「う～ん、ドット先生はどうやって見分けたりしてるの？」


「じゃあ、このメールのソースを上から順番に見ていこうか。」
「Message-ID ってのはこのメールに割り当てられたＩＤ、つまり識別番号だね。」
「返信されたメールを元のメールと紐付けたりするのにも利用されるんだよ。」

「へぇ～。そんな仕組みになってるんだ～。」
「あ、次の From は分かるよ！差出人だよね。」

「そうだね。それに対して、ひとつ飛ばして４行目の To は宛先だね。」


「うんうん。」


「戻って３行目は、送信日時なんだけど、ここはサーバー側で付与したり、クライアント側で付与したりと結構自由になってるね。」

「+0900ってのはなんだろう？」


「タイムゾーンっていってね、グリニッジ標準時との時差だよ。これは＋９時間だね。」
「地球には緯度と経度があるだろ？グリニッジ標準時はグリニッジ天文台のある経度０度の場所を基準にした時間だよ。」
「５行目の Subject は件名なのは分かるね。」
「そして次の MIME-Version:1.0 てのが MIME規格のバージョン1.0に合わせたメールですって目印なのさ。」

「じゃあ選択肢の ｄ は正しいってことか～。あと一つはどれだろう？」


「次の Content-Type:multipart/mixed; ってのは、このメールの中身は複数のパーツが組み合わさっていますって意味だ。」
「コンテンツって聞いたことあるだろう？あれはコンテントの複数形で中身って意味だ。」

「本文と添付ファイルがあるから複数のパーツが組み合わさっているってことなんだね～。」

「そういうこと。そして複数のパーツがあるってことは、その区切りが分からないと困るよね。」
「そこで次の行の boundary の出番だ。boundaryってのは境界って意味で、boundary=のあとの””で囲ったやつが境界線って事になるんだ。」

「あ～、よく見たらあちこちに ----------------01CD735EC9AEF960 ってのが有るね。これが区切りなんだ～。」

「よく気付いたね。じゃあ、ひとつめの境界線の次は何かわかるかな？」


「ん～・・・「よろしくお願いいたします。」ってあるから・・・本文かな？」


「お、鋭いね～。Content-Type が Textなんちゃら でテキストデータなのを示していて、後ろの charset で文字コードを指定しているんだ。」
「chrsetはキャラクターセットの略だね。キャラクターは文字って意味だ。」
「ここはまぁ、これくらいで、次の境界線のあとのパーツは何かわかるかな？」

「添付ファイル？」


「そのとおり！」
「文字化けっぽい塊を含んでいることからテキストデータじゃないものをテキストデータに変換したものだと判断できるけど、ほかにも見分け方があるよ」
「境界線のすぐあとに Content-Type:application/pdf ってあるから、ｐｄｆファイルってことが判るんだ。」

「ｐｄｆファイルってAdobeのやつで見れる形式だね。なるほど～。」
「あれ？じゃあ添付されているのは画像じゃなくいてｐｄｆファイルなんだ！ｂ は正しくないね。」

「そうだね～。画像ファイルだったら、その画像の形式が Content-Type のところに入るよ。image/bmp とか image/jpeg とか。」

「そうやって見分けるのかぁ～。」
「じゃあさ、この添付ファイルはデコードってやつは失敗してるかどうかはどこを見るの？」

「うん、それはね。この画面じゃ判断できないんだな。とりあえずｐｄｆのファイルが添付されてきたのは分かるけど、開けるかどうかはこの画面じゃ分からない。」
「ていうかこの状態はエンコードされたものが見えてるからね。まだデコードしてないんだ。失敗するしないって問題じゃないんだね。」

「そういうことか～」


「そして、添付ファイルのContent-Type の２つ下に Content-Transfer-Encoding:base64 ってあるだろ？」

「うんうん、あるね！」


「これが、添付ファイルをBase64でエンコードしましたよって意味なんだ。」
「トランスファーは変換って意味ね。」

「なるほど～・・・てことは。ｃ は正しくて、ａ は正しくないんだね。」
「なるほど～、ドット先生、わかったよ！」

「落ち着いてよく見れば、ヒントになるキーワードが散りばめられているから本番でも落ち着いてね。」

「は～い。」

【 第24回 第1部 第15問 解答＆解説 】
［解答］ｃ，ｄ．
［解説］
ａ．誤り。 文字化けしたように見える部分が添付ファイルの部分である。デコードに失敗しているわけではない。
ｂ．誤り。 添付されているのはpdfファイルである。
ｃ．正しい。 Content-Transfer-Encoding:base64より、PDFファイルのエンコードにBase64が使われていることが読み取れる。
ｄ．正しい。 メールにはPDFファイルを直接添付することができず、一旦テキスト形式にエンコードして添付する。この規格がMIMEである。