にしし ふぁくとりー:西村文宏 個人サイト

Presented by Nishishi via Movable Type. Last Updated: 2022/04/22. 12:56:06.

Sakura Scope (2016年10月)

ちょっと倒錯気味な、ただの日記です。(^^;)
これはやばいと思われた場合は、お早めに閲覧を中止されることをお勧め致します。

低音の耳鳴り(低音型難聴)再発症と処方薬の記録

今年の6月に発症して7月で一応完治した低音型難聴(低音の耳鳴り)症状ですが、完治から1ヶ月後にあえなく再発症してしまいました。
症状は以前と全く同じで、左耳だけで低音の耳鳴りがしたり、耳の奥が詰まっているような閉塞感が続いて、低音域が聞き取りにくくなります。聞こえる耳鳴りの音は、ハッキリした低音であることもあれば、エアコンの稼働音みたいな風っぽい音であることもあって、その時々で変わります。これらの症状も以前と同じです。

★初回発症時の症状と治療の記録は以下のページに記してあります。
→『低音の耳鳴りを発症(17日目でようやく治まってきた治療記録)
このときは、発症から1ヶ月後の7月19日で一応の「完治」となりました。

今回は、再発症時に一時的ではありますが目眩(めまい)もあったことと、その後の投薬で処方薬の種類が増えたこともあって、まあ今後のために(?)以下に記録をまとめてみました。

【目次】

耳鳴り症状の再発症と治療タイムライン

まず、初回発症の完治からちょうど1ヶ月後に再発症しました。
1ヶ月間ほどは何の問題もなかったんですけども、突然、再発症してしまいました。
このときは、再発症から7回の診察・投薬を経て、再発症後26日目あたりに治りました。

経過は以下の通りです。※日付部分のリンク先は、そのときの処方箋(※診察日のみ)。

  • 再発症01日目:8月16日(火):低音の耳鳴り、再発症。左耳の聞こえにくさは、前より酷い気が。
  • 再発症03日目:8月18日(木):目眩(めまい)
  • 再発症05日目:8月20日(土):耳鼻科診察1回目(投薬3日間):リンデロン錠は朝夕2錠ずつ。
  • 再発症08日目:8月23日(火):耳鼻科診察2回目(投薬3日間)
  • 再発症11日目:8月26日(金):耳鼻科診察3回目(投薬4日間):メニレット70%ゼリー追加。
  • 再発症15日目:8月30日(火):耳鼻科診察4回目(投薬7日間):耳鳴りの音は「夜はあるが朝には消える」感じが続く。リンデロン錠だけ削減して処方。
  • 再発症17日目:9月01日(木):耳鼻科診察5回目(※リンデロン錠だけ追加で投薬4日分)
  • 再発症22日目:9月06日(火):耳鼻科診察6回目(投薬4日間):風みたいな耳鳴りと耳奥の閉塞感が続く。
  • 再発症26日目:9月10日(土):耳鼻科診察7回目(投薬3日間):聴力検査では問題なし。微小な耳鳴りがするので一応3日分ほど処方。

タイミングの悪いことに、再発症したときは耳鼻科がお盆休みで長期休業中だったので、診察に行けたのは再発症から5日目でした。
再発症から26日目で一応は治ったんですが、また再々発症することになります。(それは後述)
上記の26日間の経過はだいたい以下のような感じでした。

再発症▼低音耳鳴りよりも先に、耳奥の閉塞感・圧迫感が先

まず、最初の再発症時ですが、低音耳鳴りの音はまったくしませんでした。
ただ、左耳で詰まった感覚がするな……という気はしていて、このままだとマズいなとは思っていました。すると翌朝には(左耳だけで)明らかにおかしい感じが増していました。耳鳴りはしないんですが、音の聞こえにくさが以前の症状よりも酷い気がしました。

前回は「低音耳鳴り+低音型難聴」だったわけですが、今回の場合は、耳鳴りの音はほとんど気にならず、耳詰まりのような感覚(閉塞感?)の方が大きくて、左耳だけで音が聞こえにくいので、「低音型難聴(突発性難聴?)」寄りの症状のような気がします。

再発症3日目▼目眩もあった!

再発症から3日目の日中に、突然、目眩がしました。
ハッキリした目眩ではなかったんですが、「目が回っているのかどうかはハッキリしないけど、乗り物酔いみたいな感じで気分は悪い」というような状態です。前回の発症期間中にはとくに目眩(めまい)の症状はなかったので、とうとう目眩の症状も出てしまったかと驚きました。
さすがに目眩は困りますね……。何もできなくなりますから。

「ちょっと安静にしていましょうか……」と思って横になったら、ぐーるぐる激しく目の前が回り出して、さらに驚きました。身体を起こしたら回転はほぼなくなるんですけども。
つまり、耳の傾きによってめまい具合が変化するってことなんですかね!?

この目眩の症状は、

  • 身体を起こしている時は、「多少ふらふらする程度」の目眩
  • 身体を横にした途端に、「目の前がぐるぐる回転し出す」ような目眩!(@_@)

です。
まあ、何をどうしていても常時目が回っているよりは、「身体を起こしていれば回らない」という方が遙かにマシではありますが。しかし、いつ悪化するか分からない、という状態ではなかなか気は休まりません。とはいえ仕方がないので、身体を完全に横にはせず、座椅子を使って中途半端な感じに斜め横になっていました。(^_^;)
幸い、この目眩は翌日にはなくなったので、翌日からは問題なく横になれたのですが。

医療系解説サイトによると「低音性難聴は、めまいの伴わないメニエール病」だと解説されていましたから、悪化すると目眩がするのかな、と解釈しています。(※これ以後、目眩は1度もありませんでした。)

処方薬は概ね前回同様

処方された薬は前回同様です。リンデロン錠の有無だけは、その時々で調整される感じでした。
なお、メニエル治療薬らしい「メニレット70%ゼリー」は、最初の2回は処方ナシでしたが、3回目の診察時から毎回処方されるようになりました。

  • リンデロン錠 0.5mg (朝夕)×各2錠
  • カルナクリン錠50 (朝昼夜)
  • トリノシン腸溶錠20mg (朝昼夜)
  • メチコバール錠500μg (朝昼夜)
  • マーズレンS配合顆粒 (朝昼夜)
  • メニレット70%ゼリー30g (朝昼夜):3回目の診察時から追加処方

再発症15日目▼治るかな……と思ったら、突然悪化

再発症から15日目には、わりと治まりつつはありました。
耳鳴りの音は、寝て朝に起きたらほぼ消えている感じです。聞こえても風っぽい音くらいです。
夜になるとハッキリと「ぽーーー」という低音が聞こえ続けているんですけども。
寝てリラックスすれば回復する、ということでしょうかね。

で、そんな感じで治まりつつあったので、一気に7日分の薬を処方(リンデロン錠はナシで、それ以外は同じ処方)してもらいました。
これで1週間後に完治していると良いな……と期待していたのですが――

再発症17日目▼突然悪化。一連の検査の中で最も悪い結果

翌々朝、左耳を指で塞いでみたときと、塞がずにいたときとで、聞こえ方がまったく同じ……という恐ろしい状態であることに気付いたので、急遽耳鼻科へ突撃してきました。
聴力検査をすると、今回一連の検査の中で最も悪い結果でした。
とにかくしっかり休む以外にないとの話。
既に一昨日に7日分の薬を処方されていましたから、今回はリンデロン錠だけを追加で4日分ほど処方されました。

耳を指で塞いでみると当然音が聞こえにくくなるハズですが、「指で塞いでも塞がなくても聞こえ方が同じ」(つまり最初から聞こえにくい状態)というのは、なかなか恐怖ですね……。

▼再発症後26日目で一応の完治

再発症から26日後、7回目の診察の段階で一応の完治となりました。
ごく静かな環境ではまだ微小な耳鳴りがする気がするので、念のために3日分の薬はもらいましたが、3日経っても問題がなければもう検査は不要、とのことでした。
実際に3日後になっても特段の問題はなかったので、やれやれ治ったか、ということで、めでたしめでたし……と一旦はなったんですけども。(^_^;;;
その後、再々発症が待っていたのでした。

耳鳴り症状の再々発症と治療タイムライン

2度目の耳鳴り症状の完治から、わずか2週間弱で再々発症。3度目です。
なかなか治らないので、8度目の診察時に、点滴を受けることにもなりました。(^_^;;;

経過は以下の通りです。※日付部分のリンク先は、そのときの処方箋(※診察日のみ)。

  • 再々発症01日目: 9月22日(木):耳鳴りはないものの、左耳だけの閉塞感が出てくる。
  • 再々発症03日目: 9月24日(土):耳鼻科診察1回目(投薬3日間):リンデロン錠は朝夕各2錠(他は同じ)
  • 再々発症06日目: 9月27日(火):耳鼻科診察2回目(投薬4日間):従来の薬に加えて、プロサイリン錠(1回2錠)が追加。
  • 再々発症10日目:10月01日(土):耳鼻科診察3回目(投薬3日間):そこそこ良くなってきたので、リンデロン錠だけを削減して他は同じ処方。
  • 再々発症13日目:10月04日(火):耳鼻科診察4回目(投薬4日間):左耳の閉塞感が続く。聴力検査も悪化で、リンデロン錠(朝夕2錠)が復活。
  • 再々発症17日目:10月08日(土):耳鼻科診察5回目(投薬3日間):聴力検査の結果、左右の耳で聞こえ方に差がなくなったことが判明。完治までもうすぐか!?
  • 再々発症20日目:10月11日(火):耳鼻科診察6回目(投薬4日間):耳鳴り復活のため、リンデロン錠(朝夕2錠)も復活。
  • 再々発症24日目:10月15日(土):耳鼻科診察7回目(投薬3日間):リンデロン錠を朝夕1錠に減らして全て継続。
  • 再々発症27日目:10月18日(火):耳鼻科診察8回目(投薬3日間):2時間弱の点滴を受ける。(詳細は後述)
  • 再々発症30日目:10月21日(金):耳鼻科診察9回目(投薬3日間):50分弱の点滴(2度目)を受ける。
  • 再々発症31日目:10月22日(土):耳鼻科診察10回目:1時間程度の点滴(3度目)を受ける。
  • 再々発症33日目:10月24日(月):耳鼻科診察11回目(投薬3日間):1時間程度の点滴(4度目)を受ける。
  • 再々発症34日目:10月25日(火):耳鼻科診察12回目:1時間程度の点滴(5度目)を受ける。
  • 再々発症36日目:10月27日(木):耳鼻科診察13回目(投薬4日間):55分程度の点滴(6度目)を受ける。
  • 再々発症37日目:10月28日(金):耳鼻科診察14回目:45分程度の点滴(7度目)を受ける。
  • 再々発症40日目:10月30日(月):耳鼻科診察15回目:大病院への紹介状をもらう。

ステロイド剤であるリンデロン錠は、あまり長く使い続けるわけにはいかないという判断なのか、「まずは、リンデロン錠(1回2錠)を処方」→「症状がよくなってきたらリンデロン錠は削除」→「また悪くなってきたらリンデロン錠(1回2錠)を復活」→「症状がよくなってきたらリンデロン錠は削除」……みたいな感じで、増やしたり減らしたりを行ったり来たりでした。
大丈夫なんかな、これ。(^_^;;;

▼重低音が左耳ではかなり聞こえにくい……!

ヘッドホンで片耳ずつ音楽を聴いてみると、右耳ではハッキリ聴き取れている重低音が、左耳ではあまり聴こえなくてショックでした……。なんか左耳で聞くと、昔のラジカセみたいな軽ーい音になっていました……。orz
これは結構なショックです。耳鼻科の聴力検査だと「ピー、ピー、ピー」と鳴る音を聞くだけなので、聞こえにくくても「まあ、この音域は聞き取りにくいんだな」くらいにしか思わないですが(^_^;)、音楽で重低音の音域が聞こえないとなると、悪影響先が明確に分かってしまうので。

▼処方薬:プロサイリン錠(1回2錠)を追加

再々発症後、2回目の診察で、これまで処方されていなかった「プロサイリン錠」という飲み薬が1つ追加されました。1回2錠です。
調剤薬局でもらった資料によると、「末梢循環をよくする、血管を広げて血液の流れを良くする、血栓ができるのを抑える」役割の薬みたいですね。

  • リンデロン錠 0.5mg (朝夕)×各2錠
  • カルナクリン錠50 (朝昼夜)
  • トリノシン腸溶錠20mg (朝昼夜)
  • メチコバール錠500μg (朝昼夜)
  • マーズレンS配合顆粒 (朝昼夜)
  • メニレット70%ゼリー30g (朝昼夜)
  • プロサイリン錠 (朝昼夜)×各2錠:新規追加

再々発症2週間後▼聴力検査でも問題がなくなったが……

再々発症から14~15日目あたりで、ようやく耳鳴りも治まり、閉塞感などの問題もなくなりました。

ヘッドホンで音楽を聴いてみると、まだ明らかに左耳では(右耳よりも)重低音が聞こえにくいんですが。ただ、まったく聞こえないわけではない(※以前は重低音がさっぱり聞こえなかった)ので、「ああ治りつつあるんだな」というような期待というか希望は感じられました。^^;

ようやく完治になるかな、と思いつつ受けた17日目の診察では、聴力検査の結果、ようやく左右の耳で聴こえ方の差がなくなったことが分かりました。この結果だけを見ると「完治」と解釈もできそうですが、これまでの経過を考えるに耳鳴り症状は全然安定していないので、念のためにあと3日だけ薬を継続してみて判断しよう、ということになりました。
このまま完治すると良いな~~……と思ったんですが、

▼あえなく復活

しかし、翌日あたりから微妙に風のような耳鳴りの音や、若干の耳の閉塞感みたいなのが復活してきて、20日目の診察の際には低音難聴の症状が復活していました。
耳鳴りの音はハッキリ聞こえる低音ではなく、あくまでも風っぽい音なのですが。
前回の良好な聴力検査結果が嘘のように、今回の聴力検査ではまた元に戻った感じです。
その結果、リンデロン錠が再処方。リンデロン飲みすぎじゃないかな?と思わなくもないんですが。

まさか耳鼻科で点滴を受けることになるとは (7回)

まさか耳鼻科で点滴を受けるとは予想しませんでした。(^_^;)
再々発症27日目の診察8回目で、低音耳鳴り(低音難聴)症状が長引いていることと、この症状に効果のある他の種類の飲み薬は特に存在しないないことから、「ちょっと点滴をしてみますか?」という話になって、1時間45分間くらい耳鼻科のベッドで点滴を受けてきました。(^_^;)

下記写真は、耳鼻科の明細書です。点滴の成分が書いてありました。

  • 低分子デキストランL注 250ml 1袋
  • ソル・コーテフ静注用 250mg (溶解液付) 1瓶
  • アデホス-Lコーワ注 20mg 1管
  • メチコバール注射液 500μg 1管

「低分子デキストランL注」というのは、点滴のベースにする液体みたいですね。
ソル・コーテフ静注用」はステロイド剤、
アデホス-Lコーワ注」は耳鳴り・難聴用の薬、
メチコバール注射液」はビタミンB12薬で、飲み薬として処方されているのと同じ薬ですね。

点滴は高いのかな?と思っていたんですがそうでもなく、保険点数は202点。3割負担で606円でした。
費用よりも、かかる時間が長いです。まさか、1時間45分もかかるとは思いませんでした。(^_^;;;
(※2回目以降の点滴時には、前の反省を活かして太めの注射針を使った結果、50分弱くらいで終わりました。)

▼点滴は1週間続けることで1セットの治療

耳鼻科の先生曰く「この点滴は1週間続けることで1セットの治療になる」とのことで、ほぼ毎朝耳鼻科に通って、60分間程度の点滴を受け続けました。(耳鼻科の休診日には点滴はできないので、実際には1週間連続ではありませんでしたが。診療日だけで7日間ほど点滴したので、トータルの期間は10日間くらいです。)

治療のためには仕方がないとはいえ、毎朝点滴を受けるとほぼ午前中が耳鼻科だけで潰れてしまうので、なかなか時間的に厳しいですね……。まあ、治すのが先決ですから、毎日通いましたが。(^_^;)

▼点滴の効果は……

1度目の点滴のときには、「まあ、何らかの効果があると良いなあ……」と期待していたんですけども、1日経っても特に何か症状が改善した気は残念ながらしませんでした。(-_-)

しかし、2度目の点滴の後には、だいたい点滴の4時間後くらいに、なんとなく症状が改善しているような気はしました。(ただ、雑音の多い環境に居るので、耳鳴り症状に関してハッキリと判断はできないのですが。)

しかーし。
7回の点滴を経て、結局、目立った効果はなかった気がします。まあ、症状を軽減する効果くらいはあったのかも知れませんけども。完治には至りませんでした。

なかなか完治に至りませんなあ……

というわけで、まだ完治はしておりません。
ぬぅ。

ただ、初回の低音耳鳴り発症時とは違って、ハッキリした低音の耳鳴りを感じる頻度はかなり低いです。耳鳴りがするとしても、風のような音が聞こえるくらいで、むしろ圧力というか耳が詰まるような閉塞感の方が気になる感じです。なんか、「治りかけてはいるんだけど、最後の最後の症状だけがしぶとく残っている」ような感じというか。(^_^;;;

とにかく、ストレスを避けて生活する以外になさそうなので、なんか抜本的に生活を改めないといけないのかも知れません……。

大病院の耳鼻科へ紹介状を書いて頂く

再々発症37日目の治療の時点で、「良くなったり悪くなったりを繰り返しているので、一度大きな病院で検査を受けた方が良い」との診断を頂きまして、40日目に大病院への紹介状を頂きました。
というわけで、これ以後の治療は大病院で行うことになりそうです。(※このブログを書いている翌日に行ってきます。^^;)

→ 大病院の受診以後の記録はこちら:「低音の耳鳴り(低音型難聴)再々発症でMRI造影検査をした記録」(2016年12月記録)

Windows10で強制再起動を回避できるアクティブ時間の設定方法

Windowsがアップデート適用後に強制再起動する問題は以前からあって、強制再起動を回避する設定方法もいろいろありました。(例えばWindows7の場合は、自動インストール時刻を指定できました。)
Windows10 Anniversary Update以後は、この強制再起動を回避する時間帯の設定機能が用意されたみたいですね。デフォルトの設定のままでも、少なくとも昼間の時間帯に強制再起動することはなさそうですが、自分の使用状況に合わせて設定しておく方が良さそうです。特に夜中にメインの作業時間がある人とかは。(^_^;)

以下は、その話。

アクティブ時間外に再起動するというポップアップが

先日、Windows10 PCを使っていると下図のようなポップアップが出てきました。

お使いのデバイスをアクティブ時間外に再起動します。
再起動が必要です
お使いのデバイスをアクティブ時間外に再起動します。アクティブ時間を変更するか今すぐ再起動するには、このメッセージを選択してください。

問答無用で再起動したりはせず、どうするか確認してきました。
ここで「今すぐ再起動」ボタンを押せば再起動するのでしょう。このポップアップ内で、ボタン以外の場所をクリックすると、アクティブ時間の案内が含まれる設定画面が開きました。

デバイスは、アクティブ時間以外の時間に再起動するようにスケジュールされています。

アクティブ時間は、黄色矢印の先に記載されています。デフォルトでは8:00~17:00に設定されているようです。
この時間帯であれば、強制再起動は実行されないみたいですね。
さすがに17時は早すぎるので、設定を変更しておく方が良いとは思いますが。緑色矢印の先にある「アクティブ時間の変更」リンクから変更できました。
アクティブ時間は最長12時間にしか設定できないようなので、もし8:00を起点にするなら20:00までしか設定できません。
私はとりあえず、9:00~21:00に設定してみました。

再起動のスケジュールから除外できるアクティブ時間

この強制再起動の除外時間帯として機能する「アクティブ時間」を設定するには、以下の手順で操作します。

  1. スタートメニューから「設定」を選択
  2. 設定画面のメニューから「更新とセキュリティ」を選択
  3. 「更新プログラムの設定」区画にある『アクティブ時間の変更』リンクをクリック
  4. 下図のような画面になるので、開始時刻と終了時刻を入力して「保存」をクリック

Windows10設定「アクティブ時間」

12時間を超える時間帯を指定すると、「アクティブ時間は1~12時間の間で設定できます」と表示されて、保存ボタンが押せなくなります。(^_^;;;
ただ、この制限は短いということはMicrosoftも分かったようで、次の大規模更新のときにはもうちょっと範囲が拡大されるというニュース記事も出ていましたが。

この設定画面には以下のように書かれています。

アクティブ時間によって、このデバイスを通常使用する時間がわかります。更新プログラムのインストールを完了するために再起動が必要な場合でも、アクティブ時間にデバイスが自動的に再起動されることはありません。
注意:再起動を試みる前に、ユーザーによってこのデバイスが使用されているかどうか確認します。

アクティブ時間外であっても、問答無用で再起動が始まるわけではなく、一応は使用中かどうかを判別してくれるみたいですね。
CPU使用率とかから判断するんでしょうか? PCに触れずにボーッとしていると再起動されるのかも知れません。(^_^;;;

まあとりあえず、せっかくこのアクティブ時間という設定項目があるわけですから、12時間が足りる足りないはともかく、「この時間帯だけは絶対に強制再起動されない」と安心できる時間帯を設定しておくと良いと思います。

関連日記:
Windows10で外出モバイル通信時にUpdateのダウンロードが自動実行されるのを防ぐ「従量制課金ネットワーク」の設定方法(2016年3月27日)

FTPで数百・数千ファイルをウェブサーバ上へ高速にアップロードする方法

WordPressやMovable TypeのようなCMSツールをウェブ上にセットアップする際、それらを構成する数百~数千ファイルをウェブサーバ上にアップロードする必要があります。FTPソフトを使って、それらの膨大なファイルを1つ1つアップロードすると非常に時間が掛かってしまいますし、アップロード途中に転送エラーが発生すると作業をやり直さなければならないなどの面倒な問題も起こります。

実はそんな無駄な方法を使わなくても、ファイル数が数百・数千・数万個でも楽にウェブサーバへアップロードでき、かつ、転送エラーも発生しない(発生しても簡単に対処できる)方法があります。
その高速アップロード方法とは、とても簡単で、

  • ZIPに圧縮した状態のままウェブサーバへアップロードして、
  • ウェブサーバ上でZIPを展開する

という方法です。

これなら、ZIP内に含まれるファイル数が数百・数千個であったとしても、アップロードするファイルは1つだけで済みます。ファイルを1つ1つ転送するわけではないので、サーバとの無駄な通信回数を削減でき、合計の処理時間も短くできます。しかも、1ファイルしかアップロードしないので転送エラーも発生しにくく、たとえ発生してもその1ファイルの転送を再度やり直せば良いだけです。
しかも、圧縮されてデータサイズが縮まっていますから、総データ転送量も低く抑えられます。

大量ファイルをアップロードするならZIPのままで。ローカルで展開しちゃダメ

大量のファイルが含まれるシステムなどをウェブサーバ上にアップロードしたいとき、「×:やってはいけない方法(時間が掛かりすぎる方法)」と「○:望ましい方法(高速に済む方法)」は下図に示すとおりです。

ZIPに圧縮された状態のままをアップロードして、ウェブサーバ上でZIPを展開する方法が望ましい。

  • [×]の方法は、「ローカルでZIPファイルの中身を展開してから、FTPソフトで全ファイルをアップロードする」という方法です。これだと、ファイルの転送に激しく時間がかかるので、待ち時間が長くなりますし、転送エラーが発生したときに面倒なことになります。
  • [○]の方法は、「ZIP形式に圧縮された状態そのままをアップロードして、ウェブサーバ上でZIPファイルを展開する」という方法です。この方が高速で済む理由は下記に記します。

▼ZIPのままアップロードして、サーバ上で展開する方が速い

上図で、[○]の方が望ましいのは、以下の3点からです。

  • 大量のファイルをアップロードするには、データを転送する時間以外にも、ファイルの転送をリクエストする処理(サーバとの通信処理)自体にも膨大な時間が掛かってしまいます。
  • しかし、1ファイルだけの転送なら無駄な処理がなく速くアップロードできます。(しかもZIPで圧縮も効いているので転送するデータ総量も少なくて済みます。)
  • ローカルPC上だろうとサーバ上だろうと、ZIPファイルの中身を展開するのには大して時間は掛かりません。

というわけで、大量のファイルを高速にアップロードするには、ZIPファイルに圧縮された1ファイルの状態でアップロードするのが望ましいわけです。

ウェブサーバ上でZIPファイルを展開する方法

上記の手順で問題になるのは、ウェブサーバ上にアップロードしたZIPファイルをどうやって展開するのか、という点でしょうね。
WindowsなどのPC上であれば、ZIPファイルをダブルクリックするなり右クリックするなりで展開できますが、ウェブサーバ上ではそうはいきません。
しかし、ウェブサーバ上でunzipコマンドが使用可能であれば、簡単に展開が可能です。

以下に、ウェブサーバ上でunzipコマンドを実行する2通りの方法を紹介しておきます。

▼TELNET(SSH)でシェルにログインしてunzipコマンドを使って展開する方法

例えば、TELNET(SSH)でウェブサーバのシェルにログインして、下記のようにunzipコマンドを実行すれば、任意のZIPファイルをサーバ上で展開できます。下図はTeraTermを使って「archive.zip」ファイルをunzipコマンドで展開する場合の操作例です。ZIPファイル内の9ファイルが展開されていることが分かります。

unzipコマンドを使ってZIPファイルをウェブサーバ上で展開

unzipコマンドは、以下の書式で使います。とても簡単です。

unzip (ファイル名)

例えば、カレントディレクトリに存在する「archive.zip」ファイルを展開したいなら、以下のように入力して実行するだけです。

unzip archive.zip

しかし、そもそもウェブサーバ上のシェルにログインできるサービスを提供していないレンタルサーバもあり、上記の方法が常に使えるわけではありません。その場合でも、ウェブサーバ上でunzipコマンドが使用可能であるなら、次の方法でも展開が可能です。

▼unzipコマンドを使ってZIPファイルを展開するCGIを作って実行する方法

要はウェブサーバ上でunzipコマンドが実行できれば良いのですから、以下のようなシンプルなCGIを作ってアップロードし、ウェブサーバ上で実行(=ブラウザでCGIにアクセス)する方法でも任意のZIPファイルを展開できます。

#!/usr/bin/perl
print "Content-type: text/html\n\n";
`/usr/local/bin/unzip archive.zip`;
print "Unzip Complete.";

上記は、Perlで記述した「unzipコマンドを実行するだけ」の簡単なCGIです。

  1. まず、上記の4行をテキストエディタに入力します。「archive.zip」の部分は実際に展開したいZIPファイル名に修正して下さい。
  2. 記述できたら、例えば「unzip.cgi」のような名称で保存します。
  3. 対象のZIPファイルをアップロードした場所と同じ場所に、上記のCGIもアップロードします。
  4. あとはブラウザでこのCGIにアクセスするだけで、ZIPファイルの展開ができます。
  5. 展開作業が無事に終わったらCGIファイルは削除しておきましょう。

※上記ソースの2行目と4行目はなくても構いません。(ただ、これがないとブラウザ上からCGIを実行したときにエラーが表示されてしまいますし、ZIPの展開処理が終わったのかどうかも判断できないので、まあ書いておく方が良いとは思います。)
※3行目の「/usr/local/bin/unzip」部分は、実際にunzipコマンドの存在する場所を指定する必要があります。単にunzipと書くだけで良いかも知れませんが。
※わざわざCGIにしなくても、シェルスクリプトとかでも良いとは思います。(^_^;)

ウェブサーバ上の数百・数千ファイルを一括ダウンロードした場合にも有効

この方法は、もちろん高速アップロードだけではなく高速ダウンロードにも使えます。
ウェブサーバ上にあるシステムをローカルにバックアップしておきたい場合など、ウェブ上の数百・数千ファイルを一気にダウンロードしたいケースがあります。
そんなときは、

  • ウェブサーバ上で対象ファイルを1つのZIPファイルに圧縮する
  • そのZIPファイルをFTPでダウンロードする

という方法なら、たった1つのZIPファイルをダウンロードするだけで済みますから、とても高速にダウンロード作業が完了します。
ウェブ上でZIPに圧縮するには、zipコマンドを実行すれば良いだけです。
先程と同じように、TELNET(SSH)でシェルにログインしてコマンドを打つか、zipコマンドを実行するCGIを書いてウェブ上で実行すれば良いでしょう。

アップロードもダウンロードもZIPファイルを対象にすると楽

というわけで、数百・数千ファイルをローカルとウェブサーバ間で転送したい場合は、アップロードであってもダウンロードであっても、ZIPファイルの状態で転送すれば、高速に作業が済みます、という話でした。
ぜひ、この方法で無駄な時間と手間を省いてみて下さい!

書き仕事のデータ喪失防止対策として、EmEditorの自動保存・自動バックアップ機能を使う方法

PCを使って書き仕事をする際には、とにかく不慮の事故でデータを失ってしまわないようにすることがとても重要です。フリーズなどのトラブルによってせっかく書いた文章なりソースコードなりが失われてしまったら、同じ物を再度書くのは精神的に非常にしんどいですから……。
そういった不慮のデータ喪失を防ぐ最も基本的な方法は、言うまでもなく頻繁にデータを保存することですよね。
私は、上書き保存のショートカットキー[Ctrl]+[S]を無意識のうちに頻繁に押しています。正確な記録はありませんが、だいたい1文を書き終えるよりも短い頻度で押している気がします。

とはいえ、無意識の上書き保存操作だけに頼るのはちょっと危険でもあるので、テキストエディタ側の自動保存・自動バックアップ機能にも頼っておく方がより安心です。

自動保存機能とは、必ずしも上書き保存ではなく、バックアップコピーの自動保存でもある

自動保存というと「勝手に上書きされるのか」と思われる方も多いような気がしますが、必ずしもそうとは限りません。

  • 自動的に上書き保存する「自動保存」機能もあれば、
  • バックアップ専用フォルダへコピーを自動保存する「自動バックアップ」機能もあります。

[Ctrl]+[S]キーを頻繁に押す癖が付いているなら前者(上書き保存)は自分の好きなタイミングで実施できるので、後者(バックアップ保存)を自動処理に頼っておくのがお勧めです。そうすることで、たまたま保存できていなかった際にトラブルに遭っても、データの喪失は防げます。

私が長年愛用しているテキストエディタ「EmEditor」には、指定時間間隔で自動的にバックアップコピーを取ってくれる自動保存機能などがあります。以下にその設定方法を紹介しておきます。

EmEditorで自動保存機能を使う方法

EmEditorでは、メニューから[ツール]→[すべての設定のプロパティ]を選択した上で「自動保存」タブを開くと、以下のように自動保存に関する設定ができます。

EmEditor「自動保存」タブ

●まず、「自動保存」欄にチェックを入れると、何分ごとに自動保存処理を実行するかを指定できます。(緑色矢印部分)
私は最短の1分に設定しています。
こうしておけば、たとえPCのフリーズなどでデータが失われてしまうとしても、被害は1分未満のデータだけで済みます。デフォルトでは10分だったような気がしますが、さすがに10分は長すぎると思います。特に処理が重たくなるわけでもないので、1分がお勧めです。(^_^;)

●次に、「自動保存フォルダに保存」欄にチェックを入れています。
ここにチェックがあれば、EmEditor側の自動保存処理は「上書き保存」ではなく「指定のフォルダへバックアップコピーを保存する」ようになります。勝手に上書きされるわけではなくなるので便利です。

●保存先のフォルダはこの画面の下部にある「自動保存フォルダ」欄で指定できます。(黄色矢印部分)
この自動保存フォルダにはバックアップコピーがどんどん溜まっていくので、適宜フォルダの中身を削除する必要はありますが。(私はローカルドライブ内のフォルダを指定していますが、ここをクラウド同期フォルダに設定することで、クラウドへの自動バックアップを実現する使い方も可能だとは思います。)

上記の設定によって、「1分ごとに、自動保存フォルダへ、編集中のファイルのバックアップコピーを保存する」という自動処理ができます。これでデータ喪失防止対策としての安心度が高まります。
なお、1分ごとに保存するといっても、過去の1分間に一切編集しなかった場合には何もしないので、同時に多数のファイルを開いている場合でも、無駄に保存処理が実行されることはありません。

▼無題のまま編集している場合であっても自動保存される

なお、まだ名前を付けて保存する前の段階であっても、「無題1」のようなファイル名でちゃんとバックアップ保存されるので安心です。

ちなみにですが、「まだファイル名を付けていない段階」で保存操作を実行すると、「名前を付けて保存」ダイアログが表示されますよね。このダイアログが表示される寸前には(まだ1分が経っていなくても)自動保存処理が1回実行される仕様になっています。なので、Windows側のトラブルで「名前を付けて保存」ダイアログ表示時にフリーズしてしまうようなことがあっても、データは完全に無事です。この機能は個人的にはたいへんありがたかったです。(Windows10で「名前を付けて保存」ダイアログがフリーズするケースが何度かあったので。)

EmEditorで前版のバックアップ機能を使う方法

もう一つ、EmEditorには「バックアップ」という機能もあります。こちらは、先のような「一定時間ごとの自動保存処理」ではなく、「上書き保存した際に前のバージョンを残しておく機能」です。
先程と同様に、メニューから[ツール]→[すべての設定のプロパティ]を選択した上で「バックアップ」タブを開くと、以下のようにバックアップ保存に関する設定ができます。

EmEditor「バックアップ」タブ

ここで、「バックアップをバックアップフォルダに保存」欄にチェックを入れておくと、ユーザが自らの操作でファイルを上書き保存した際に、指定したバックアップフォルダに対して前のバージョンがバックアップ保存されます。
私は、先の自動保存フォルダと同じフォルダを指定してこの機能を使っています。
が、まあ、この機能はあってもなくても良いかな、という気はしますが。(^_^;)
編集操作にはUndo機能もありますから、あまり「前のバージョンに戻したい」という状況には遭遇しませんし。まあ、あって困ることもないので設定だけはしています。

ちなみに、オリジナルファイルと同じ場所に保存したり、ゴミ箱に直接保存するような使い方も可能です。

書き仕事をする際のデータ喪失防止対策として自動保存機能は必須!

というわけで、私が長年愛用しているEmEditor(エムエディタ)の自動保存機能の話でした。
(他の有名テキストエディタにも同様の機能はあると思いますけどもね。)

PCって、いつフリーズなどのトラブルに見舞われるか分かりませんからね。仕事のやる気を喪失しないためにも、データを喪失してしまう可能性はしっかりと潰しておくことが重要です。(^_^;)
1分ごとにバックアップ専用フォルダに自動保存する方法なら、「上書き」処理ではないので安心できる上に、最大でも1分間分のデータしか喪失しないので大変便利です。

ぜひ、しっかり対策してみて下さい!

自動保存機能が存在しないソフトウェアでも、定期的な自動保存を実現するフリーソフトも

[Ctrl]+[S]キー自動押下ツールSafety Saver(仮)ちなみに、世の中には自動保存機能が存在しないソフトウェアも当然あるでしょう。そんな場合でも、定期的な自動保存を実行するフリーソフトがあります。
探せば多数ありますが、拙作のフリーソフトも公開していますので、ぜひご活用下さい。(^_^;)

[Ctrl]+[S]キー自動押下ツール Safety Saver(仮)

これは、指定した時間ごとに(そのときアクティブなウインドウに対して)、[Ctrl]+[S]キーコードを送出することで自動保存を可能にするソフトウェアです。これを使えば、[Ctrl]+[S]キーで保存可能なソフトなら何でも自動保存が可能です。(もっとも、可能なのは「上書き保存」だけですが。)
もしよろしければご活用下さい。^^;

独自ドメイン+レンタルサーバでも大した費用は掛からない

これまでニフティ提供のスペースでウェブサイトを運営していた友人が、ニフティ側のサービス廃止に合わせて移転作業をする過程で「独自ドメインを取っておけば良かったな」と言ったので、大手プロバイダ側の独自ドメイン取得サービスを使うくらいなら自力で独自ドメインを取得してレンタルサーバを契約した方がよほど安くて済むよ、という話をしました。

他の人にも役に立つかな、と思って、以下にその独自ドメイン取得とレンタルサーバ契約の話をまとめて記しておきます。

【目次】

プロバイダ提供サービスでの独自ドメイン取得料金は高い!

ニフティ側が新たに提供するウェブスペースでは、「ドメイン@nifty」というサービスを使って独自ドメインを取得して運営することも可能ですが、料金が高すぎます。
なんと、.comドメインでも年額3,800円!
強気すぎる料金です。(^_^;)
相場の2.5倍以上している感じですね。

これなら「ニフティで独自ドメインを維持する料金」だけの分で、「レンタルサーバ会社を使って独自ドメインとウェブサーバを維持する料金」におつりが来ます。(^_^;)

というわけで、この機会にニフティ側スペースを放棄して(移転案内だけ置いといて)、レンタルサーバ会社を使って独自ドメインで運営することを提案しました。それなら、以下のようなメリットが得られる上に、安く済みますから。

  • メリット1: 運営会社側の都合でウェブサイトの引っ越しを余儀なくされることがなくなる。
    →ウェブサーバ会社がサービスを停止しても、独自ドメインの権利は自分にあるので、サーバを変更することになってもURLは変えずに済みます。
  • メリット2:独自ドメインを使ったメールアドレスが手に入る。
    →プロバイダを乗り換えるたびにメールアドレス変更をアナウンスする必要がなくなります。

たいていメールアドレスは複数作成可能ですから、メイン用途以外に捨てアドレスを用意するのも簡単ですしね。

独自ドメイン+格安レンタルサーバの契約にかかる費用の相場

さて、だいたいここ最近の独自ドメイン維持費や格安ウェブサーバ利用料金の相場は以下のような感じだと思います。

  • .comドメイン維持費: 年額1,280~1,900円くらい
  • レンタルサーバ費用: 年額1,200~1,600円くらい

独自ドメインを取得して、レンタルサーバを契約しても、年額で合計2,480~3,500円くらいで済みます。月額換算だと、207円~292円くらいですね。ニフティで「独自ドメインだけの料金として」年額3,800円払うよりも安いです。(^_^;)

もっとも、この価格帯で利用できるウェブサーバには本当に最低限の機能しかありません。
しかし、ニフティのウェブスペースの詳細を見てもやはり最低限の機能しかないので、ほぼ同じです。^^;(むしろ、細かく見ればニフティスペースよりも多少機能は高いと言えます。ディスク容量も。)

レンタルサーバ:さくらインターネット、ロリポップ

私は個人的には以下のレンタルサーバをお勧めしています。

さくらインターネット
最安のライトコースは、1,543円/年
私が個人的に16年くらい使い続けているレンタルサーバ会社です。

ロリポップ!
最安のエコノミーコースは、1,200円/年
業界最安クラスのレンタルサーバ会社ではないでしょうか。

どちらのレンタルサーバでも、最安コースでもウェブスペースの容量は10GBあります。(ニフティは2GB)
10GBもあれば容量は十分です。
WordPressなどのCMSツールを使いたい場合にはもう1つランク上のコースを契約する必要がありますが、自力でHTMLを書いてファイルをアップロードしているだけなら最安コースで充分です。

※なお、どちらのサーバでも初回加入時の手数料が1,000円~1,500円程度かかるので、初年度だけはもう少し負担が必要です。

▼余ったサーバ容量をストレージとして使える「さくらポケット」

さくらポケットなお、さくらインターネットでは「さくらポケット」というiOS/Androidアプリを公開していて、余ったサーバ容量をスマートフォンやタブレットでのネットストレージ空間として活用できるサービスもあるので便利です。「タブレット-PC」間でファイルのやりとりをするのになかなか重宝しています。(PC側ではFTPソフトを使ってファイルを転送します。)

※注:この「さくらポケット」を使うにはスタンダードコース以上が必要なので、最安のライトコースでは使えません。私はスタンダードコースを2つ契約しているので、全体で容量は200GBほどありまして、とても使い切れません。^^;

▼ドメインが複数でも、ウェブサーバは1つで良い

ちなみに、1つのレンタルサーバ契約に対して複数のドメインを割り当てることで、1つのサーバ契約だけで複数のウェブサイトを運営可能です。複数のドメインを使って複数のウェブサイトを運営したいからと言って、レンタルサーバを複数契約する必要はありません。(よほど容量やスペックが足りないという状況にならない限りは、ですが。)

※1つのサーバ契約で何個のドメインを割り当てられるかは、レンタルサーバ会社や契約コースによって異なります。もし、複数のドメインを使って複数サイトを運営したい場合には、制限個数を事前に調べておきましょう。

独自ドメインの維持は、レンタルサーバ会社と異なっていても良い

独自ドメインを利用してウェブサイトを運営するためにもウェブサーバが必要なので(当たり前ですが)、「独自ドメインの取得・維持」と「レンタルサーバの契約」はセットで語られることもありますが、それぞれ異なる会社を使っても問題ありません。同じ会社を使っておけば各種設定が楽だというメリットくらいはありますが、基本的には最初に1度設定すればあとは放置して構わないので、ドメインとサーバを同じ会社にしておく大きなメリットはないと思います。(必要に応じてサブドメインを作って複数サイトを運営したい場合は、同じ会社の方が設定が楽で良いかも知れませんが。)

独自ドメインの取得・維持料金は、ドメインの種類(=「.com」とか「.jp」とか)によって大きく異なります。
最もスタンダードな「.com」・「.net」・「.org」あたりなら、だいたい年額1,280円くらいでしょうか。数年前は980円くらいで維持できていましたが、ちょっと円安が進行したせいか高くなりましたね。(^_^;)

  • 「.com」や「.jp」など、ドメインの最後の部分のことをTLD(トップレベルドメイン)と呼びます。
    • 「.jp」や「.uk」など国別に割り当てられているTLDは、特にccTLD(カントリーコード・トップレベルドメイン)と呼び、
    • 「.com」や「.info」などジャンル別に割り当てられているTLDは、gTLD(ジェネリック・トップレベルドメイン)と呼びます。

gTLDはどんどん新設されていますが、マニアックな新興ドメインは本当にずっと運営が続くのかどうか分かんないので(^_^;)、比較的長く使われているTLDを採用する方が安心できて良いんじゃないかな、とはちょっと思います。^^;
だいたい以下の3社で検索してみれば良いと思います。3社とも私が個人的に使っている(or使っていた)会社です。

日本の「.jp」は卸値が高いためか、どの会社でも維持費が比較的高いですね。
日本語サイトだと分かりやすい上に、TLDが2文字なので短くて済むメリットはありますが。^^;(※ccTLDはみんな2文字です。)

というわけで

というわけで、独自ドメインとレンタルサーバの話でした。
「ちょうど良い機会ではないか? 大した額ではないし。おーすすめよー。」と友人に宛てて送ったところ、彼は 0g-tl.com を取得して無事に引っ越せたようです。
めでたし、めでたし。^^;

ニフティのホームページスペース提供サービスが閉鎖される際に、アクセス者を自動移動(転送)させる方法

ニフティ提供のホームページスペース「@homepage」が閉鎖されることになりましたが、データの自動移行は一切行われずユーザが自力で作業する必要があります。ニフティ提供の案内機能では検索エンジンからの評価値を維持できなさげなので、評価値を維持したまま新サイトへ自動転送する方法を解説してみます。

nifty.comドメイン上に約17万サイト存在するユーザサイトがもうすぐ閉鎖されてしまう

@homepage サービス終了のお知らせ大手プロバイダのニフティが17年前から会員向けに提供していたホームページスペースサービス「@homepage」が終了し、閉鎖されることになりました。利用者向けには代わりの無料スペースが提供されるとはいえ、アップロードされているデータの自動移行などは一切行われず、ユーザが自力で作業する必要があります。そのためか、閉鎖期限が迫っても8割以上が放置されている点がニュースになっていました。

ニフティ、個人などのホームページ14万件が1カ月後に自動消滅、サービス終了の「@homepage」、8割以上が放置されたまま(@INTERNET Watch)

ニフティはパソコン通信サービス時代からの超大手プロバイダでユーザ数も莫大ですから、そこで提供されているウェブサイトも相当数で、記事によると約17万サイトあるようです。
たとえ製作者には既に更新の意思がないウェブサイトであっても、そこに掲載されている情報は有益であって今でも参照者が多数居る……というサイトもあるはずです。そういうウェブサイトがごっそり消滅してしまうのは、かなりの(公共の)損害だと思うんですけどもね……。

ニフティほどの大手プロバイダで、かつ、新しい無料ウェブスペースサービスを提供するというのであれば、自動的にデータを移行するくらいのことはしてくれても良いのではないかと思うんですけども。

▼ユーザによる移行作業が進まないので閉鎖期限を延期したが……

あまりにもユーザによる移行作業が進まないためか、閉鎖期限を延長するという決定が下されたというニュースも出ていました。

「@homepage」終了を11月に延期 移行進まず、8割が“放置”状態(@ITMedia)

が、根本的な解決にはならないでしょう。
このまま有益なサイトも含めて、ごっそりネット上から失われてしまうのは大変もったいないと思います。
まあ、Internet Archiveとかのアーカイブサイトには残るでしょうから、Wayback Machineを使えば参照は可能かも知れませんが。(ただ、HTMLや画像以外のファイルはアーカイブされなさげなので、フリーソフトなどのデータは手に入らなくなるんじゃないかと思います。)

ニフティには、ユーザに移行作業を投げるのではなく、自動移行する仕組みを用意して実行して欲しいなあ、と思います。

新サイトへ自動移動させたいが、ニフティ提供の機能では検索エンジンからの評価値を維持できなさげ

さて、ニフティ側は新スペースを用意してはいますが、それを利用して移転させても、URLは変わります。従来は http://homepageX.nifty.com/***/ のような感じのURLでしたが、ニフティ側が用意するいくつかのドメインを選択して引っ越せるようです。

URLが変わってしまうと、そのままではこれまで得ていた検索エンジンからの評価値を捨てることになってしまうので、検索サイトからのアクセスは激減してしまいます。それを防ぐには、検索エンジン側に「ウェブサイトを引っ越した」事実を適切に伝えておく必要があります。

▼最も手軽で簡単かつ確実な引っ越し方法は「ウェブサーバ側の機能でリダイレクトすること」だが、使えない

ページのURLの変更と301リダイレクトの使用最も簡単でGoogleも推奨している方法は、ウェブサーバ側の機能(.htaccessファイルなど)を使ってウェブサイト全体を新サイトへリダイレクトすることです。
方法は簡単で、「.htaccess」という特殊なテキストファイルを作成して、そこに移転先URLを書いておくだけです。旧サイトへの全アクセスを、ディレクトリ構造などをすべて維持したまま新サイトへ自動転送できるので、アクセス者にとっても便利ですし、検索エンジンにも引っ越しの事実を伝えられます。

しかーし!

今回閉鎖されるニフティの「@homepage」サービスでは、.htaccessファイルの設置は許可されていないのですよね……。
なので、残念ながらこの手軽で望ましい方法での自動移動機能は用意できません。

▼ニフティ側は移転メッセージを表示する機能を提供してはいるが、検索エンジン対策にはならない

移転通知機能の設定ニフティ側は、新サイトへの移転メッセージを表示する機能を提供していますが、その方法は「移転しましたよ」というメッセージを表示した上で、10秒後に移転先のトップページに自動移動するという、かなり望ましくない方法です。なぜ望ましくないかは、主に下記の2点です。

  • 0秒での瞬間移動ではない(しかもmeta要素での自動移動)。
    →検索エンジンは「引っ越した」とは(おそらく)解釈しない。
  • ディレクトリ構造を一切無視して新サイトのトップページに自動移動させてしまう。
    →ディレクトリ構造を無視して移転先のトップページに自動移動する方法は、Googleは推奨していない。

というわけで、ニフティ側の機能に頼るのは、検索エンジン対策という観点からは非常に望ましくなさそうです。
そもそも、ニフティ側の機能で自動移動できる先は、「ニフティ側が提供する新ホームページスペースサービス」だけに限られていて、今回の閉鎖に併せてニフティ以外のサービスに移転することを決めた場合(レンタルサーバを利用するなど)は使えません。

私の友人がこの問題に直面したので、.htaccessファイルが使えないニフティ上で、なんとか検索エンジンからの評価値を維持したまま引っ越せる方法を以下に解説してみました。

検索エンジンからの評価値を維持したまま、新サイトへ自動移動させるには、ディレクトリ構造を維持したまま転送する必要がある

まず、検索エンジンからのを維持したまま新サイトへ自動移動させるには、以下のような点が重要です。

このような自動転送設定ができれば、検索エンジンは「ウェブサイトが引っ越した」と認識してくれるでしょうから、旧サイトの評価値をそのまま新サイトに移行してくれます。なので、検索エンジンのクローラーがサイト内全体をクロールするのに十分な期間だけ自動転送設定が維持されていれば、検索ではあまり不利にはならないでしょう。(※リンクしてくれている外部サイトのリンクが書き換えられないままの状態だと、最終的に旧サイトが閉鎖されて自動転送処理が行われなくなった後は、やはり不利になってしまうでしょうけども。)

▼ディレクトリ構造を維持したまま転送する

「ディレクトリ構造を維持したまま」というのは、例えば、下記のような転送のことです。
旧サイトが http://homepage2.nifty.com/***/ で、新サイトが http://newsite.example.com/ の場合、

  • http://homepage2.nifty.com/***/ にアクセスされたら、その瞬間に http://newsite.example.com/ へ転送。
  • http://homepage2.nifty.com/***/orange/ にアクセスされたら、その瞬間に http://newsite.example.com/orange/ へ転送。
  • http://homepage2.nifty.com/***/banana/yellow.html にアクセスされたら、その瞬間に http://newsite.example.com/banana/yellow.html へ転送。

このように、旧URLと新URLがすべて1対1で対応している転送です。

▼HTTPステータスコードで301を返して転送する

HTTPステータスコードで頻繁に目撃するのは「404 Not Found」でしょう。ページが見つからなかった際に表示されます。このステータスコードには多数の種類があって、自動転送に関しては「301」・「302」・「303」・「307」などがあります。そのうち301は「Moved Permanently(恒久的な移動)」を表し、ウェブページが別の場所へ移転したことを示します。

この「301 Moved Permanently」返してから、移転先URLを伝えられれば完璧です。

しかし、これを実現するにはウェブサーバ側の設定が必要で、たいていは「.htaccess」ファイルの設置が必要です。なので、残念ながらニフティの「@homepage」サービスでは使えません。

そこで、次善の策として、次の方法を使います。

▼アクセス後、0秒で転送する

HTMLソース内に下記のような指定のmeta要素を1行書いておくことで、自動移動させることができます。

<meta http-equiv="refresh" content="秒数;URL=移転先URL">

この方法では、自動転送処理が実行までにかかる秒数を指定できるのですが、この秒数を「0」に設定します。
0秒で自動移転する処理になっている場合は、検索エンジンは「301 Moved Permanently」の場合と同じ解釈をしてくれる可能性があります。絶対とは限りませんが。まあそう期待したい、くらいですけども。(^_^;)

というわけで、ニフティの「@homepage」サービスで引っ越し先へ自動移動させるには、

  • ディレクトリ構造を維持したまま転送する
  • アクセス後、0秒で転送する

という2点を実現する方法が必要でしょうかね。
それを以下に解説します。

ニフティ側の旧サイト上で、1ページずつ自動転送ページを用意する方法

.htaccessファイルを使えば、たった1ファイル用意するだけでサイト内の全ページで自動移動させられるわけですが、まあ使えないものは仕方がありません。そうすると、「自動移動用HTML」ファイルを用意して、サイト内の全ページと置き換える(=1ページずつ個別に自動移動させる)くらいしか手がなさそうに思います。

今、旧サイト上に存在しているすべてのHTMLファイルの中身を、以下のHTMLソース(12行)をベースにしたものに書き換えます。

<!DOCTYPE html>
<html lang="ja">
<head>
   <meta http-equiv="Content-Type" content="text/html; charset=shift_jis">
   <title>■■■ここにタイトル■■■</title>  <!-- ★1 --->
   <meta http-equiv="refresh" content="0;URL=http://newsite.example.com/"> <!-- ★2 --->
   <link rel="canonical" href="http://newsite.example.com/"> <!-- ★3 --->
</head>
<body>
   <p>Redirect to <a href="http://newsite.example.com/">http://newsite.example.com/</a>.</p>  <!-- ★4 --->
</body>
</html>

上記は、移転先URLが「http://newsite.example.com/」である場合の記述例です。下記の注意点に従って修正して下さい。

注意点は以下の通りです。

  • 注1:上記のファイルを1つだけ設置すれば良いのではなく、サイト内に存在するすべてのHTMLファイル1つ1つと同じファイル名で、上記のHTMLファイルを設置します。例えばサイト内にページが50あるなら、上記のHTMLファイルも50個必要です。
  • 注2:移転用HTMLファイル名は、元々のページのHTMLファイル名とまったく同じにする必要があります(=既存ページに上書きして設置するということ)。例えば元がgallary.htmlなら、移転用HTMLファイル名もgallary.htmlとして公開する必要があります。
  • 注3:上記のHTMLソースは、そのままコピーしてはダメで、★1~4の部分を1つ1つ正しく書き換える必要があります。(そうしないと、ディレクトリ構造を維持した状態での自動転送にならないので意味がありません。)

「★1」で示した<title>~</title>内には、元々のページタイトルをそのまま書いておきます。念のために。
「★2~4」の各所には、移転先のページのURLを書きます。上記のサンプルソースでは単に http://newsite.example.com/ と書いていますが、このようにトップページのURLを書くのではダメで、必ず旧ページと1対1で対応するURLを書きます。例えば下記のように。

  • http://homepage2.nifty.com/***/index.html の位置に置く場合の記述は、
    上記の通り http://newsite.example.com/ で構わないが、
  • http://homepage2.nifty.com/***/orange/gallary.htm の位置に置く場合の記述は、
    http://newsite.example.com/orange/gallary.htm でないとダメ。
  • http://homepage2.nifty.com/***/banana/paint.htm の位置に置く場合の記述は、
    http://newsite.example.com/banana/paint.htm と書く必要がある。

この1対1の対応が崩れていると、そのページの評価値を移転先に引き継いでくれないので、検索エンジン対策の意味がありません

※補足:★3と★4は省略しても問題はないだろうけども

★2~4の位置には、同じ移転先URLを合計4つ書く必要があるので、修正漏れのないよう何度か確認しましょう。(^_^;)
ただ、★3と★4に関しては「まあ念のために書いておこう」という程度の意味なので、書くのが面倒なら省略して「★2」だけを書いておく方法でも良いかも知れません。
なお、★2~4それぞれの役割は以下の通りです。

  • 一番重要なのは「★2」に書くURLです。ここに書いたURLを参照してブラウザは自動的にページを移動しますので。これは必須です。
  • 「★3」は、検索エンジンに対して「今見ているこのページの本来のURLはこっちですよ」という情報を知らせる目的です。あくまでも情報を知らせるだけなので、これだけを書いても自動移動はしません。「★2」の記述がある以上、「★3」は省略しても構わない気もしますが、まあ念のために書いておく方が良いかな、くらいの感じです。(^_^;)
  • 「★4」は、何らかの都合で自動転送が実施されなかった場合にブラウザの画面上に表示されるリンクです。これも省略しても良いですが、リンクの形で存在している方が、人間にも検索エンジンにも伝わるので、一応書いた方が良いかと思います。

というわけで、「★2」だけが必須で、あとは省略しても構いません。ただし、省略する場合には行ごと削除して下さい。上記のサンプルソースにあるデフォルトの記述のまま残してはいけません。

※自動移動用HTMLファイルは、置いておける限りずっと置いておくのが望ましい

というわけで、サイト内の全ページを上記の転送用HTML(をベースにして修正したページ)に置き換えれば、引っ越し作業は完了です。
サイト内のページが多ければ多いほど、ファイル作成の面倒さが増してしまいますが。(-_-)
あとは、検索エンジンが旧サイト内をクロールしてページの情報を拾ってくれれば、引っ越した事実を認識してくれるでしょう。

なお、これらの転送用HTMLは、旧サーバが存続している限りずっと置いておくのが望ましいです。理由は以下の2点で。

  • いつのタイミングで検索エンジンが「引っ越しの事実」を認識してくれるかが分からない。
  • リンクしてくれている人が、リンク先URLを新ドメインへ書き換えてくれるかどうかが分からない。

さすがに、1ページずつこの方法で自動転送させるのは面倒なので、何らかの方法を使って楽にファイルを作成できれば良いんですが。(^_^;)
最も望ましいのは、ニフティ側が「ディレクトリ構造を維持したまま新サイトへ自動転送してくれる」ことですけどもね……。
せめてそれくらいしてくれても良いんじゃないかと思うんですけどもね。(-_-)

Google Search Consoleを使って引っ越し先を伝えておく

自動移動のための設定がすべて完了して、実際にリダイレクト処理がうまく動作していることを確認したら、Google Search Consoleの「アドレス変更ツール」を使って引っ越し先URLを登録しておくと、なお望ましいでしょう。Googleに対してしか有効ではありませんが、もはや検索の大部分はGoogleによるでしょうから。(^_^;)

■参考:アドレス変更ツールの使用(@Google Search Console ヘルプ)

上記の手続きが、果たしてmeta要素でリダイレクトしている場合にも適用可能なのかどうかはよく分かりませんが、まあ、何もしないでいるよりは、とりあえずやっておく方が良いのではないかと思います。(^_^;;;

検索エンジン対策はどうでもいいから、とにかく自動転送したい場合

移転先へ自動移動(転送/リダイレクト)させる方法検索エンジンからの評価値はどうでもいいからもっと楽にディレクトリ構造を維持したまま自動転送したい、という場合は、JavaScriptを使って転送する方法もあります。全ページで共通のJavaScriptを読み込ませる必要がありますが、既に全ページで読み込んでいる共通のJavaScriptファイルが存在するのであれば、そこに書き足すだけで済みます。

その辺の方法については、過去にAll Aboutで記事にしてありますので、下記の記事をご参照下さい。(^_^;)

移転先へ自動移動(転送/リダイレクト)させる方法(@All About ホームページ作成)

上記の記事では、

  • .htaccessファイルを作って一括転送する方法
  • HTMLにmeta要素(タグ)を書いて自動転送する方法
  • JavaScriptを使って自動転送する方法

……のそれぞれについて、メリット・デメリットを紹介した上で、具体的な実現方法(記述方法)を解説しています。

ニフティ側の対処がもう少し良くなってくれると望ましいんだけど

しかしまあ、上記のような解説をしたところで、ウェブサイト保持者が自力で作業しないとサーバ閉鎖後にウェブサイトは消滅してしまうことに変わりはありません。
移転の意思がなかったり、移転が必要だと気付いていなかったり、移転したくても作業時間が取れないといった事情がある人々も多いでしょう。なんせ17万サイトもあるんですから。
そういった事情に対処するには、ニフティ側がウェブサイトのデータを強制的に新サービスへ自動移転する、とか「ウェブサイト保持者側が何も作業しなくても済む」方法を用意してくれるしかないでしょう。

会員数の多い超大手プロバイダなんですから、その辺はもうちょっとなんとかして欲しいなーと思います。

とりあえず現時点では、2016年11月10日(木)の15時に閉鎖されてしまうようです。

ラジオボタンを応用して、HTML+CSSだけでアコーディオンメニューUIを作る方法

スマホ対応も!アコーディオンメニューの簡単な作り方input要素で作るラジオボタンの動作を応用すれば、アコーディオンメニューの動作がスクリプトなしで実現できる……などというアクロバットな裏技を最初に発見した人って誰なんでしょうかね?(^_^;)
画期的なアイデアだと思うんですが。(^_^;) よく気付いたもんです。

HTML側でラジオボタン(またはチェックボックス)とラベルを用意しておき、それをCSSで装飾することで、スクリプトを一切使うことなくアコーディオンメニューができあがります。アニメーション効果もCSSだけで実現できます。
最初にこの方法を知ったときには、「うまく考えたなあ!」といたく感心しました。

アコーディオンメニューUIの作成方法を解説

というわけで、ラジオボタンやチェックボックスの仕組みを使うことで、スクリプトを使わずにHTML+CSSだけでアコーディオンメニューUIを作成する方法の解説記事を、All Aboutで公開しました。

スマホ対応も!アコーディオンメニューの簡単な作り方(@All About ホームページ作成)

この記事で解説したアコーディオンメニュー作成方法のポイントは以下の通りです。

  • HTML+CSSだけで作れる。
    →ソースの記述量が短くて済みます。
  • スクリプト不要。
    →jQueryなどのライブラリが不要なだけでなく、そもそもJavaScriptを使いません。
  • アコーディオンメニューとしての動作は、HTMLのinput要素を活用することで実現。
    →ラジオボタンやチェックボックスの動作そのものが、アコーディオンメニューの動作になります。
  • アコーディオンメニューのアニメーション効果は、CSSをほんの数行記述するだけで実現。
    →2つの状態が切り替わる際にアニメーション効果を付加できるtransitionプロパティを1つ記述するだけ。

記事では、「なぜ、ラジオボタンでアコーディオンメニューの動作になるのか?」についても、図を使って解説しています。
また、サンプルページを用意していますから、ソースをコピー&ペーストすることで簡単に試せます。
ぜひ、覗いてみて下さい!

放棄した独自ドメインが広告サイト化してしまうダメージに注意

独自ドメインは誰でも自由に取得できますが、年間の維持費を支払い続けなければ権利を維持できません。もはや利用しない独自ドメインが出てしまった場合には、取得したドメインの権利を放棄する(=ドメインの使用を廃止して維持するのをやめる)選択もあり得るでしょう。しかし、その際には、放棄したドメインが望ましくない活用方法をされてしまう可能性がある点に注意が必要です。

独自ドメインを放棄すると、第三者によって広告サイト化されてしまう可能性がある

最近のウェブでは、誰かが使用権を放棄したドメイン名はすぐに広告会社などが買い取って、広告スペースとして活用されることが多々あります。なぜなら、一定期間以上利用されていたドメインは様々な場所からリンクされている可能性があるので、何もしなくても一定の閲覧数が見込めるため、広告掲載場所として適しているからです。

今まで自分(自社)のブランドを使って運営してきたウェブサイトの独自ドメインを廃止した結果、そのドメイン名が第三者によって再取得され、いかがわしい広告サイトに使われてしまった場合、従来の顧客はどう感じるでしょうか。
顧客側の視点から見ると、今まで自分が利用してきたウェブサイトにアクセスしようとしたら、突然いかがわしい広告サイトが現れるわけです。「この会社、とうとうこんな商売に手を染めたのかな?」などと、マイナスイメージを持たれてしまう危険もありそうです。

放棄ドメインの広告サイト化問題は既に多々ある

この問題は各所で起きていて、例えば衆院選の立候補者が利用していた独自ドメインが(落選後に放棄された後)、カードローンや美用系広告サイトに使われてしまっている例もあります。その一例は、「2012年衆院選落選候補の元公式サイトが順調にSEO業者等のサテライトサイトに化けつつある」でも紹介されています。
「あのときの立候補者は今どうしているのかな?」と思って覗きに行ったかつての支援者が、元立候補者の独自ドメインでいかがわしげな広告サイトが運営されている状況を見ると、ずいぶんと悪いイメージを持ってしまうかもしれません。

放棄されたドメイン名は、誰でも再取得可能だという点を忘れずに

ドメイン名とは現実世界での「住所」のようなものなので、元の持ち主がその住所を放棄すれば、その跡地をどう使うかは新しく購入した人の自由です。一度広告スペースとして使われてしまえば、他者にはどうにもできません。(今の持ち主が手放すことがあれば、再度使用権を手に入れることは可能ですが。)

例えば、2009年に実施された衆議院議員総選挙では、総務省が 2009senkyo.jp というドメインを使って告知サイトを運営していました。しかし、選挙終了後にあっさり手放してしまったため、その後、とある学習塾のウェブサイトに利用されてちょっと話題になりました。
選挙の公式告知サイトなら多数のウェブサイト(ニュース記事など)からリンクされていたでしょうから、検索対策的にはおいしいドメインだったでしょうね。
その学習塾がその後どうなったのかは知りませんが、今ではまた別のサイトに転用されているようです。(^_^;)

さすがに総務省も学習したのか、現在では選挙のような特別サイトであっても、soumu.go.jpという行政専用のドメインを使ってサイトを運営するようになったようです。例えば http://www.soumu.go.jp/2014senkyo/ などのように。(※今はこのページはありません)

一度取得して運営に使った独自ドメインは、極力放棄しないことが重要

自身が放棄したドメイン名が広告サイトに使われてしまうのを防ぐには、一度取得して運営に使った独自ドメインは決して手放さないことです。(^_^;) 一度ドメイン名を放棄してしまえば、誰でもその名称を取得可能になってしまいますから、その後どう使用されるのかを決めることはできません。

一度取得したドメイン名は、極力手放さないことが重要です。

ウェブサイトを運営するにはドメイン名以外にウェブサーバも必要ですが、使用を停止したドメイン名にはウェブサーバを割り当てる必要はありません。使っていたウェブサーバは解約しても構わないので、ドメイン名の権利だけを維持し続ければ問題ありません。ドメイン名の維持費は掛かり続けますが、サーバ代は必要ありませんから多少の費用削減はできます。
もし、他のウェブサイトを運営しているのであれば、そちらのウェブサーバを指すように設定を変更することで、自分(自社)でドメインを使い続ける方法もあるでしょう。

クライアントの独自ドメインが広告サイトに変貌していた……

廃棄したドメインが広告サイトに使われてしまうケースなぜこの話を書いたかというと、私がウェブ製作を担当していた某社がこの目に遭ったからです。(-_-)

先方が所有していた複数の独自ドメインのうちの1つ(長らく更新がなかったサイトのドメイン)を、先方が私に相談なく廃止してしまい、その結果、その独自ドメインにアクセスすると広告サイトが表示されるようになってしまいました。

まあ、「直前まで利用されていたウェブサイトの内容に近い広告を自動表示することで広告料を稼ごう」というタイプの広告サイト(※広告リンクが列挙されるだけのサイト)なのか、表示されている単語は今のところは元の運営題材に近く、「いかがわしい」という使われ方ではなかったので、ダメージはさほど大きくはなかったのですが。でも、このドメインが今後も同じように使われ続けるとは限りませんから、ずっと大丈夫だとは誰にも言えません。

ドメイン廃止を検討していることを事前に聞いていれば止められたのですけども。残念でした。

新たに専用ドメインを用意したい場合は、サブドメインを使う手もある

新たにウェブサイトを立ち上げる際には、それ専用の独自ドメインを用意したい、と思う場合もあるでしょう。
しかし、完全に新しいドメインでなくても、今使っているドメインのサブドメインを使うという選択肢もあります。
例えば、 www.example.com がメインサイトだとすると、 newsite.example.com というサブドメインを用意して新しいサイトを運営するなどです。
この方法なら、そのサイトを閉鎖する際でもドメインそのものを廃止することにはなりませんから、第三者に取られる心配はありません。また、サブドメインなら作成費用はタダなので、余計なドメイン維持費用がかからないメリットもあります。

というわけで、

  • 一度取得した独自ドメイン名は、放棄(廃止)しないことが重要。
  • 新たに専用ドメインを用意したい場合は、既存ドメインのサブドメインを使う手を検討しても良いのでは。

という話でした。

関連日記:
ウェブサイトを閉鎖するときはSEO的価値を消滅させてから(@2022年4月22日)

2016年10月
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          

他の月

--- 当サイト内を検索 ---