2017年10月13日(金) 15時57分06秒 [ソフトウェア]

Windows LiveメールのユーザがWindows10に移行する際の選択肢3つ

私の友人がメーラとして「Windows Liveメール」を使っていました。
これは、Microsoftが無償配布していた「Windows Essentials」というソフトウェアセットに含まれているメーラなのですが、今年の頭で公開が終了してしまいました。
その友人が、Windows10搭載の新PCを購入したそうなんですけども、新PCに同じメール環境を構築しようと思ったところ、既にWindows Liveメールが手に入らなくなっており困っていました。(^_^;)

新PCには、Microsoft Officeが搭載されていて、メーラとしてはOutlookが用意されています。
しかし、話によると「Windows LiveメールのデータをエクスポートしてもOutlookへインポートできなかった」とのこと。これは方法がマズかったからであって、実はちゃんとインポート可能なんですけども。
その辺も含めて、新しいWindows10 PC上でメール環境を用意する、以下の3つの選択肢をアドバイスしました。

• (1) Windows LiveメールをWindows10にインストールして使い続ける方法
• (2) Outlook 2016に、Windows Liveメールのデータをインポートする正攻法
• (3) Thunderbirdに乗り換えて、Windows Liveメールのデータをインポートする方法

私はメーラにThunderbirdを使っているので、お勧めは(3)なんですけども。^^;
以下は、上記1～3の詳細です。

1. Windows LiveメールをWindows10にインストールして使い続ける方法

Microsoft自身は「Windows Liveメール」の配布を終了してしまいましたが、それでもまだWindows10へ強引にWindows Liveメールをインストールする方法はあります。
詳しい方法は、以下のブログ記事に画面イメージ付きで解説されていましたので、それを読むのが分かりやすいです。^^;

■windows10にWindows Liveメール2012をインストールする（＠パソコンりかばり堂本舗）

世の中のウェブサイトを、過去バージョンも含めてことごとく保管している「Internet Archive」というサイトには、Windows Liveメールのインストーラもアーカイブされており、そこ経由でなら今でもダウンロードできるとのこと。
上記ページの解説によると、「Windows Liveメール」はWindows10でも動作するようですから、それを使い続けるのも1つの方法でしょう。
インストール時にちょっとした選択肢の工夫とかが必要っぽいので、詳しくは上記のページをご参照下さい。

とはいえ、もはやWindows Liveメールがサポートされなくなった点に変わりはないので、このような機会に乗り換えを検討するのも良いとは思います。
なお、Windows Liveメールを使い続ける選択肢を採用する場合、Windows Liveメールが「過去のメーラ」扱いになればなるほど、将来的に他のメーラへのインポート手段がなくなる可能性が出てきそうなので注意が必要です。

2. Outlook 2016に、Windows Liveメールのデータをインポートする正攻法

個人的には大してお勧めはしませんが、これがたぶんMicrosoftが望んでいる正攻法でしょうね。(^_^;)
新PCにプリインストールされているMicrosoft Officeに含まれているOutlookを後継メーラとして使うことができます。
Windows LiveメールのデータをOutlookへ移す(＝インポートする)方法は、以下のNECサイトで詳しい画面イメージと共に解説されています。

■Windows Liveメール（2012）のメールデータをOutlook 2016に移行する方法（＠NEC LAVIE公式サイト）

ポイントは、Windows Liveメール側でデータをエクスポートする際に、「Microsoft Exchange」という形式を選択してファイルに出力することです。
データ形式を「Windows Liveメール」のままでエクスポートしてしまうと、Outlookへはインポートできないようです。

3. Thunderbirdに乗り換えて、Windows Liveメールのデータをインポートする方法

私が個人的にお勧めするのは、メーラをThunderbird(サンダーバード)に乗り換える方法です。(^_^;)
Thunderbirdは、ブラウザのFirefoxを開発しているMozilla製のメーラで、無料でダウンロードして利用できます。

Thunderbirdなら、（アドオンを使えば）Windows Live Mailからもデータをインポートできます。
そもそも「Windows Liveメール」を使っていた方々は、その前のWindows XP時代には標準のメーラ「Outlook Express」を使っていたのではないかと思います。
Thunderbirdの画面構成はOutlook Expressとも似た感じなので、見やすくて使いやすいでしょう。
個人的には、メールの実態ファイルが「1フォルダ1ファイル」で管理されていて、複数PCで同期を取りやすい点も気に入っています。

▼Thunderbird本体と、Windows Liveメールからデータをインポートできるアドオンをダウンロードする

そんなThunderbirdは、公式サイト https://www.mozilla.org/ja/thunderbird/ からダウンロードできます。

インストールすればすぐに使えますが、ここでの本題は「Windows Liveメールからのインポート」ですね。
それは以下のページや記事で紹介されています。

■Windows Mail メッセージのインポート(Moziila公式サポートページの短い解説)：
■Windows Live Mail（Liveメール） を 簡単にThunderbird（サンダーバード）に移行する方法（＠有限会社ケンシステム）

後者のブログ記事の方が、画面イメージ付きで分かりやすいです。

メーラのThunderbirdは、ブラウザのFirefoxと同じようにアドオンで機能を追加できます。
Thunderbird上からアドオンを探したりインストールしたりもできるのですが、「Windows Liveメールからデータをインポートするためのアドオンである『ImportExportTools』」はどうもその方法ではインストールできないので、上記のページに書かれている方法を使って、「ローカルにダウンロードしたアドオンファイル」を使ってのインストール操作が必要です。その点がやや面倒ではありますね。まあ、最初の1回だけの話なので、頑張って下さい。^^;

メーラはOSと結びついていない方が良い気がする

というわけで、以上、Windows LiveメールのユーザがWindows10に移行する際の選択肢3つでした。

Windows環境に限りませんが、メーラはOSメーカー以外が開発しているのを使うのが吉な気がします。
OSメーカーが開発していると、OSのアップグレードに併せて勝手にいろいろ仕様が変わったり、新しいメーラへの移行が促されたりしますよね。
サードパーティ製のメーラを使っておけば、OSが変わっても従来のインターフェイスのまま使える可能性が高いでしょう。もちろん、開発が継続されるかどうかは開発元の大きさやユーザの多さ次第ではありますが。
その点、Thunderbirdは昔からユーザ数も多いですし、Moziilaによる(？)オープンソースで開発されているメーラなので、今後に現れる新環境でも使い続けられる可能性は高そうに思います。（と言いつつ、将来的には開発プロジェクトをMoziilaから独立させるという話もありましたが。^^;）

何にせよ、メーラみたいに日常的に使う連絡手段は、とにかく使い慣れたインターフェイスで使い続けられることが最も重要だとは思います。

2017年10月 2日(月) 12時48分17秒 [Web関連]

構築中のウェブサイトで自分以外にはメンテ中の表示を見せる方法

構築中のウェブサイトでは、「構築している途中の状態を一般公開したくない」場合があります。
ローカル環境で表示確認しながら作れば良いだけなら、わざわざ構築途中の状態をウェブ上にアップロードする必要はないわけですが、ウェブサーバ上で表示確認しつつ構築する方が簡単な場合も多々あります。

例えば、

• ウェブサーバ上にセットアップされたWordPressなどのCMSツールをベースにして構築する場合
• 既にウェブ上にセットアップされているMySQLなどのデータベースを使って表示するページを構築する場合

などでしょうか。
ウェブ上に構築されているシステムを利用してウェブサイトを作る場合には、最初からウェブ上で作業する方が楽です。

ただ、その場合は、第三者に構築途中のウェブサイトを見られるのはあまり望ましくありません。
まず見た目がよくない可能性もありますし、見られるとセキュリティ面で望ましくない情報が表示されてしまう可能性もあるでしょうし。
そんなときには、

• 自分だけが構築中のウェブサイトを閲覧でき、
• 自分以外にはメンテナンス中である旨の表示を見せる

という方法が便利です。

自分だけが閲覧可能で、自分以外には「403 Forbidden」エラーを見せる方法

方法は簡単で、

• 自分が使っているIPアドレスからのアクセスだけを許可して、
• それ以外のIPアドレスからのアクセスを拒否すれば良いだけ

です。
さらにエラーページを独自にカスタマイズして「ただいま構築途中ですよ」と表示しておけば、分かりやすくて良い気がします。

▼アクセス制限と、アクセス拒否時に独自メッセージを表示するための.htaccessファイルを書く

上記のような動作(表示)を実現するには、例えば以下のように.htaccessファイルを書きます。

# ▼1 ：Forbiddenエラーページを用意する
ErrorDocument 403 /nuc.html

# ▼2 ：自分以外のアクセスを拒否する
order deny,allow
deny from all
allow from 59.106.19.87

# ▼3 ：特定のファイルはアクセス拒否対象の例外とする
<Files ~ "^nuc.+">
allow from all
</Files>


上記でやっていることは、以下の3点です。

1. アクセスを拒否した場合(＝403 Forbiddenエラーを出す際)には、nuc.html を表示する。
   ※nucは、Now Under Construnctionの略のつもり。(^_^;) ファイル名は何でも良いです。
2. 自分のIPアドレス(※ここでは例として 59.106.19.87 としています)からのアクセスだけを許可し、それ以外をすべて拒否する。
3. ただし、ファイル名が「nuc」で始まるファイルだけは、誰でもアクセス可能にする。

自分以外の閲覧を拒否する設定は「2」です。
自分以外のアクセス者にエラーページを見せる設定は「1」と「3」です。

▼第三者に見せるエラーメッセージ(構築途中ですよと知らせる案内)の注意

独自にエラーページを用意しないなら「1」も「3」も不要です。
その場合は、アクセス拒否された人のブラウザには、たぶん「403 Forbidden」というデフォルトのエラーメッセージが表示されるでしょう。お使いのレンタルサーバ会社によっては、独自のエラーメッセージが出るかもしれません。

独自にエラーページを用意する場合で「1」しか書かなかった場合は、エラーページそのものへのアクセスも拒否されるため、エラーページは表示されず、デフォルトのエラーメッセージ(＝Forbiddenなど)だけが表示されてしまいますので注意して下さい。

※独自のエラーページ(HTMLファイル)を、アクセス制限の対象になっていないディレクトリに置いているのであれば、「3」は不要です。ここでは、ウェブサイト全体をアクセス制限対象にしていることを想定しているので、「3」も加えました。

▼アクセス拒否の例外とするファイル名

上記の.htaccessファイルの記述なら、ファイル名が「nuc」で始まるファイルはすべてアクセスが許可される(※正規表現^nuc.+がその意味)ので、

• エラーページの本体： nuc.html
• エラーページ内で表示される画像： nuc1.png , nuc2.jpg
• エラーページ内で読み込まれるCSS： nuc.css

などのように、誰にでも見せたいファイルが複数ある場合は、全部ファイル名の先頭を「nuc」で始めておけば良いです。

▼アクセスを許可したい人が複数居る場合は

自分以外にも、例えば納品先の担当者にも閲覧を許可したい場合には、allow from XXX.XXX.XXX.XXXの記述を必要なだけ増やせば良いです。
例えば以下のように。

order deny,allow
deny from all
allow from 59.106.19.87
allow from 202.181.97.54 ◀◀◀許可するIPアドレスを追加


なお、モバイルネットワーク経由で接続している場合など、その時々によって自分のIPアドレスが変化する場合には、ちょっと面倒ですが毎回.htaccessファイルを書き換えるか、上記のように追記していくかする必要があります。

ウェブサイトの構築が完了したときに、この.htaccessファイルを削除すれば、一般公開(＝誰でも閲覧可能な状態に)できます。

2017年10月 1日(日) 13時55分31秒 [Web関連]

さくらインターネット上のWordPressをHTTPS化した際にプラグインが出力するURLがHTTPSにならない問題の解決記録

WordPressのプラグインの中には、そのプラグインが用意している独自のCSSやJavaScriptファイルをヘッダなどで読み込もうとするものも多数あります。
WordPressへのアクセスをHTTPからHTTPSに切り替える際には、それらのプラグインが読み込むCSSやJavaScriptなどの外部ファイルもHTTPSで読み込むよう記述が修正されなければなりません。
ウェブページ自体がHTTPSで読み込まれているときに、CSSやJavaScriptファイルがHTTPで読み込まれようとする場合には、ブラウザはそれらのファイルを読み込みませんから。（画像の場合は、警告アイコンを表示するだけで、読み込み自体は拒否されませんが。）

WordPressのアドレス(URL)設定をhttps://～に修正すれば済むと思ったんだけど

HTTP環境でセットアップされたWordPressをHTTPSでアクセスできるようにするためには、まずは、URLの設定を変更します。
方法は簡単で、WordPressのメニュー[設定]→[一般]にある『WordPressアドレス(URL)』項目と『サイトアドレス(URL)』項目の2つを、http://～ ではなく https://～ に書き換えれば良いだけです。
このように設定しさえすれば、プラグイン側が読み込もうとする各種ファイルも、当然https://～に書き換わるものだ、と思っていたのですが、どうもうまくいかないものがありました。

▼プラグインがhead要素内に追加するJavaScriptファイルのURLがhttp://～のまま

私がセットアップしたWordPressでは、人気記事ランキングを表示するために「WordPress Popular Posts」というプラグインを使っています。
24時間・7日間・30日間など単位で閲覧数の多い順に記事ランキングを生成してくれる便利なプラグインです。
このプラグインは、閲覧回数をカウントするために、ヘッダ領域にtracking.jsというJavaScriptファイルを読み込ませた上で、カウント用のJavaScriptソースを1行生成します。
そのURLが、なぜかhttp://～のままになってしまって、https://～になってくれません。

▼プラグイン側の問題だとは言い切れない気がする

とはいえ、このプラグインがHTTP固定仕様になっているわけではありません。
というのも、最初からHTTPS環境としてセットアップしたWordPressにインストールしてある同じプラグインでは、問題なくhttps://～で読み込むよう出力されているからです。
なので、「HTTP環境でセットアップされたWordPressを、後からHTTPS化した場合」にのみ発生する問題っぽい気がします。

この原因が、果たしてプラグイン側にあるのかWordPress側にあるのかは分かりませんでした。
プラグインを一旦無効にしてから再度有効化したり、WordPressのパーマリンクの設定を保存し直してみたりしたんですが、一向に変わりません。JavaScriptファイルはhttp://～で読み込まれてしまいます。
※そもそもこういうファイルは絶対URIではなく相対パスで読み込んで欲しいんですけどね……。(^_^;;;

WordPressのSSL化を支援するプラグインを併用してみることに

そこで、WordPress生成サイトをSSL化する支援プラグインを使ってみることにしました。
この手のプラグインは多数あります。
たぶん、やっていることは「http://～」で出力されようとしているURLを強制的に「https://～」に書き換える処理でしょう。

全自動で何もかもやってくれるようなプラグインもありますが、負荷を考えればできるだけ必要最小限の処理だけに留めておきたいので、HTTP→HTTPSの書き換え処理対象を細かく設定できる「SSL Insecure Content Fixer」プラグインを採用してみました。
インストールすると、下図のように修正対象が選べます。

最初は「シンプル」が選択されていて、WordPressのwp_register_script()などで登録されたスクリプトファイルや、wp_register_style()などで登録されたCSSファイルなどのみを対象にして、http://～をhttps://～に書き換えてくれます。

ウェブサイト内の画像参照やリンクを極力「相対パス」で書いている場合には、この「シンプル」設定だけで充分だろうと思います。
最高レベルの「すべてキャプチャ」を選択した場合は、WordPressが出力しようとしている内容を全走査して、http://～をhttps://～に書き換えるっぽいです。

さくらインターネットのウェブサーバでは、HTTPSであることを検出できていないっぽい？

で、最終的には「シンプル」設定で良かったんですが、最初に試したときにはうまくいきませんでした。JavaScriptファイルは相変わらずhttp://～で読み込まれています。
1段階ずつ修正レベルを上げていって、最高レベルの「すべてキャプチャ」に設定しても、懸案のJavaScriptファイルはHTTPで読み込まれるまま変わりませんでした。
ここでふとおかしいな、と気付きました。

▼出力文字列を全走査してもhttp://～をhttps://～に修正できないなら……

設定を「すべてキャプチャ」にすれば、WordPressが出力しようとしている全文字列を走査する（だろうと思う）のに、それでも修正されないということは、そもそも何も処理がなされていないのではないか？ と。
そこで、この「SSL Insecure Content Fixer」プラグインの設定画面の末尾にある『HTTPSの検出方法』という項目が気になりました。

ここには、「ページがHTTPSで読み込まれたことをWordPressが検出する方法を選択してください」とあり、デフォルトの「標準のWordPressの機能」が選択されています。わざわざ赤色文字で「*推奨設定として検出されています」と表示されているので変更する必要性を最初は感じなかったのですが。(^_^;)

しかし、そもそもさくらインターネットでは、HTTPS化する際にはちょっと特殊な方法を使う必要があります。
方々で説明されているのでここでは詳しくは書きませんが、一般的に .htaccess ファイル内でmod_rewriteを使って（HTTP接続だったらHTTPS接続にリダイレクトする目的などで）HTTPSによるアクセスではない状態を検出するには、

RewriteCond %{ENV:HTTPS} !^on$

のように記述しますけども、さくらインターネットの場合はこの記述では認識されず、以下のように書く必要があります。

RewriteCond %{HTTP:X-Sakura-Forwarded-For} ^$

つまり、さくらインターネットのサーバ上では、標準の方法ではHTTPS接続であることを検出できないわけですよね。たぶん。
そこで先ほどの「SSL Insecure Content Fixer」プラグインの設定画面の末尾にある『HTTPSの検出方法』という項目を見直すと、最下部に『HTTPSを検出する方法がない』という項目があります。^^;

試しにこれをチェックしてみると……、うまく動作しました！

懸案のJavaScriptファイルは、ちゃんとhttps://～で読み込まれるようになっていました！
めでたし、めでたし！

▼HTTPSかどうかを判別しなくなり、問答無用でHTTPS用に修正するようになるけど、実害はない

上記のように「HTTPSを検出する方法がない」項目を選択すると、たぶん現状の接続がHTTPなのかHTTPSなのかを判別しなくなるのでしょう。
そのため、HTTPSではなくHTTPでページを表示させた場合でも、URLはhttp://～ではなくhttps://～に修正されていました。
しかし、そもそも「HTTPSで接続しているときにHTTPでファイルを読み込むのが問題」なだけで、逆のパターン「HTTPで接続しているときにHTTPSでファイルを読み込む」のは何も問題ありません。
なので、上記のようにHTTPSであることを判別しない設定でも実害はありません。

※そもそも、ウェブサイトのアクセスを全部HTTPS化したいのであれば、「HTTPで接続されるケース」自体がなくなるわけですから、何も問題ありません。

というわけで、さくらインターネットのサーバ上では、HTTPSであることを判別しなければうまくいく、ということが分かりました。(^_^;)