【NEWS】Jアラート訓練:島根と岡山でメール読めず

 

Jアラート訓練:島根と岡山でメール読めず

生地からでは詳細は解らないが、Subject や本文のヘッダ部分とフッタ部分は読める事から、メールの送信を行うプログラムと考えた場合には、いくつかの想像で対処”案”が考えつく。

島根県が17日に送った予告メールは正常に送信されたといい、同県防災危機管理課は「原因究明を急ぎたい」としている。

と、いう所から、システム自体には欠陥はあるものの、”送信出来る場合”がある事が解る。
そして、送信日付が、

2017/08/18 11:00:02 発表

となっている。これは、すごく不自然な事だ。
そして、送信時間を示す所には

11:01

と表示されている。
実に1分近い差異が生じている。島根県で、1万5,000人/岡山県で、2万8,000人への同時送信となっている事から、1分の違いは、同時発信の問題ではないかと思われる。

メールという不確かな通信手段を用いているので、この位のタイムラグはしょうがないと諦めるしかない。

文字化けに関する事だが、この送信システムは、Webを利用して送られているのではないだろうか?
一度送信ができたシステムで、二度目が上手くいかないと考える時に、どういった事が考えられるかだが、画像を見れば、”文字化け”がエンコードの問題だとすぐに解る。

文字化けの様子から、UTF-8をSJIS又はEUCのエンコードだと送信してしまったのだろう。

この事から、アプリケーションでの送信は考えにくい。
そもそも、一度目と二度目の違いは、どこに有ったのだろうか?

私が現場の人間なら、一昨日に送った物と文面が同じなら、それをコピー&ペーストしたい気持ちになるだろう。
もし、アプリケーション的に作られていて、このようなミスが発生したのだとしたら、これを作った会社は、メールの事を勉強し直した方がいいだろう。

まずは、人的なミスがなく、しすてむてきに、以前正常に送信できた物を再度送信した場合だが・・・。以前の文章を、DBなり、テキストファイルなりにして保存していた事になるのだろう。そうなった場合に、文字化けが入り込む余地があるのは、DBやファイルに書き込む時か、読み出す時だろう。正しい、文字コードで保存できていないか、正しい呼び出しの設定がされていないか、又はその両方という事になる。しかし、これは、テストを行っているのだろう。通常では考えにくい現象だ。

アプリケーションになっている場合では、本文に街灯する部分は、TextBox を使っていると思う。それで、過去のメールの呼び出し機能が無いのだとしたら、TextBox にメールの本文を書かなければならない。その場合、一度書いた文面を、メモ帳やワード等で保存しておいて、次に送信する時に、そこからコピー&ペーストしているだろう。
通常の作り方をしていれば、TextBox に張り込まれた時点で文字コードは変換されている。打ち込んだ状態と同じ形式になる。この場合は、一度目に遅れている事から、二度目で文字化けを行うのは考えにくい。

次に、Webプログラムの場合にはどうなるのか?
コピペした時に、元の文字コードのまま張り付けられる事になる。

こういう流れではないだろうか?

  1. 17日に、テストメールを送信を行う。この時には、文面は画面上から入力を行った。”確認”画面は絶対にあるのだろう。担当者は、18日も同じ文面で送信することを思い出して、ブラウザの確認画面で表示されている文面をコピペする事にした
  2. コピーした文章を、メモ帳にペーストして、保存する(この時に、意識しなければ、文字コードはUTF8になってしまっている)
  3. 18日のメール送信時に、前日にコピーしたメモ帳の内容を取り出す。
  4. メモ帳の内容をそのままコピーして、ブラウザの入力場所にペーストする。メモ帳は、意識しなければ、全開保存した文字コードで開くようになっている。
  5. この時点で、入力はUTF-8になっている。
  6. Webのメールシステムは、その後の文字コードを意識していれば、EUCを要求していると思う。
  7. そのまま確認画面に進むが、確認画面ではブラウザが優秀で文字コードを解釈して、表示できてしまった
  8. 安心して送信して、文字化けが発覚する。

という流れだったのではないだろうか?

これなら文字化けが発生してもおかしくない。

それでは、修正はどうしたらいいのだろうか?
確実なのは、文字コードを意識する事だ。入力された文字列。送信しようとしている文字列しっかりチェックを行ったから送信を行えばいい。