あたごやまにっき

WordPressへの移行を開始して既に1週間経ちましたけどまだ2016年分(1200件+)までしか移せていません、お目当ての記事が見られない方にはすみません。この土日で追い込むつもりです。

だいぶ移行の手順は決まってきて効率は上がっているとは思います。しかし、2013年(たぶん現状年次での投稿データ量ピーク)分の写真だけで1GB超あったりでサーバーにも結構な負荷を掛けています。

新たに見つけたポイントとしては2013年11月購入のOLYMPUS STYLUS TG-2で撮った写真に入っているEXIF GPS位置情報が大きくズレている点です。どうやら電源を入れて新たに測位できるまでに直前に電源OFFした時点で有効な位置情報があるとそれを新しい写真の撮影位置として書き込んでいたようです。AW100の0よりもたちが悪い仕様になっています。どの写真で不整合が起きているのか絵とデータを突き合わせるしかありません。プリウスなど自動車の移動中ですと最悪は1km超ズレている恐れもあります。このサイトにアップロードしている画像で見つけた誤差最大は今のところ、直線距離で約1.12kmズレです。WiFiで測位したほうがマシだったかもしれないレベルです。この写真1枚については測位情報の公開は不適当と判断してEXIFデータ内のGPS項目だけ削除してアップロードし直しました。

ついでに(こんなことしているから移行が進みません)、緯度0度・経度0度を調べるとギニア湾の海上になります。日本国内と言わずとも陸上で撮影した画像に対しては明らかに位置情報エラーというのが分かるため未測位や補足衛星数が不足して誤差100m超過の状態では北緯ゼロ度・東経ゼロ度で記録してくれたほうが後処理しやすいです。

このサイトのWordPress用テーマLuxeritas 3.0.2へのアップデートを実施しました。不要なテーマを根こそぎ削除していたため一旦デフォルトのテーマへ戻した上で古い3.0.0(3.0.1はスキップ)を削除してから3.0.2をインストールしました。特に変わったところは無さそうです。

ソフト404では中々旧サイトのURLが消えないためGoogle Search ConsoleのGoogleインデックス→URLの削除を申請してみました。

2012年分までデータを移しましたが文字列自動置換だけでは取りこぼす場合があるようなのでところどころリンク切れが徐々に直していきます。画像データが巨大化してきてレンタルサーバーの一日あたり転送量が1GBを超えました。表示確認のためアップロード→ダウンロードを繰り返しているためサーバー上で消費する容量の2倍以上の転送が必要になります。

　はてなフォトライフの謎仕様は昨日書いただけでなく、以下の記事によるとPNGのフォーマットもなぜか64bit RGBAになるそうです。はてなフォトライフに PNG をアップロードすると 64bit RGBA に変換されて無駄にファイルサイズが増える話(http://blog.shibayan.jp/entry/20170705/1499256812)
　移行のためにダウンロードしたデータを調べてみると、fを日付ベースのファイル名と仮定して、

• f_original.pngは24bitまたは32bit(ファイル名以外はたぶん元のまま←バイナリレベルでは未検証)
• f.pngそれに加えて確かにビット深さが64bitになりファイルサイズが激増します。
• f_120.jpgとf_m.jpgは24bit固定(オリジナルが32bitでも24bit)なのでわざわざ64bitに変換する意味が分かりません。(＋少なくともはてなダイアリーから2017年6月以降にPNGファイルをアップロードすると中身PNGフォーマットのまま_120と_mは拡張子.jpgに変わる、2017年5月以前はPNG->JPEG変換していたらしい)

　参考にした記事のタイトル通り”無駄にファイルサイズが増える”状態になっていました。私がはてなダイアリーとフォトライフを使い始めたのが2009年7月頃ですのでこの頃には既にこの誰得な仕様になっていたようです(しかも2018年5月現在もそのまま)。
　あまり画像データの謎仕様について深追いすると記事の移行が進まないためメモしておきます。ただ、"はてなダイアリー"はともかく"はてなフォトライフ"は現役サービスのはずでこんなんでいいのでしょうか？かなり疑問に思いました。

後日補足)※なぜ画像データのファイル容量が増えるのが問題なのか？を書いておきますと、サーバー上で処理してサムネイルなどと呼ばれる縮小した画像を作るのは元画像のデータが大きいと表示に時間がかかるからです。わざわざ"縮小のための処理"をして画像の解像度(品質)は落ちているのに転送するファイルサイズが大きくなっていては逆効果になります(見る人も見せる人も端末もサーバーも回線も損します)。かえって何もせずに元のデータをそのまま転送したほうが良くなります。また、縮小処理自体毎回同じ処理をサーバーで行うと負荷がかかる(=遅くなる)ため、アップロード時に必要なサイズのデータを複数作成して参照する方式が一般的です。

はてなフォトライフの謎仕様(後述)やらNIKON COOLPIX AW100のGPS未測位時の"0″データなどに悩まされ移行のペースが落ちています。移行元のデータが存在していると旧URLへのリンクが残っていてもエラーにならないため少し早いですが先行してはてなフォトライフの2017年以前のデータを削除しました。削除の主な目的はこれですけど昨日・今日でわかっただけで以下の謎仕様があります。

1. データの内部はPNGなのに拡張子".jpg"でサイズを縮小した画像を保存している。元のオリジナルデータのみ.pngを保持。これは.jpgデータを自動処理しようとしてはまりました。具体的にはPython3向けのPillowライブラリが以下のエラーで処理を停止します。

AttributeError: 'PngImageFile' object has no attribute '_getexif'

何度ファイル読み取り部分を確認してもファイル名をダンプしても中身と拡張子が不一致というのに中々気づきませんでした。
はてなフォトライフから落としてきた画像のプロパティ：
赤線のファイル名(拡張子.jpg)とファイル形式(PNG)に注目。どうしてこうなった？

2. これは以前はてなブログ方面だったかで問題になっていたと思いますけど、はてなフォトライフの設定画面上は測位情報を"非公開"と設定していても実際の.jpgファイルには測位情報が残っていてかつ測位情報付きでダウンロードできました。測位情報を残しているとは明記していますが非公開なのに公開している点には触れていません。この点については元から問題になりそうな場所(知人宅、会社周辺)での写真は公開していませんしGPSの測位精度が悪かった時代のデータが多いため平気で写真に写っている場所から数100m位ずれていたりします。

ただ、急遽作った自作スクリプトでスキャンした結果、意図せず測位情報付きで公開になっていた画像も見つかったためEXIF内のGPS項目だけ削除する処理を行ってから再度公開しようかと考えています。一方で公共施設(道の駅、高速PA/SA)、山頂、社寺周辺など写真を見ただけで一目で何処か分かるような写真の測位情報はいまさら削除するだけ無駄なので残す方針です。

3. これも最近の話では無いですけど、はてなフォトライフの動作がメチャメチャ遅い・重い。削除するだけでもえらい時間がかかりましたし、なぜかキャッシュのクリアすら非常に遅いのか１日近く経ってもまだ読めるデータもあったりします。これだけでも手間やお金を掛けてでも高速なレンタルサーバーへ移行する甲斐があるというものです。

…というわけで思ったよりも苦戦中です。

昨日(5/21)は写真データの確認のためほとんど移行は進みませんでした。N905imyu, P-01BもGPSに対応していたようでEXIFに位置情報が載っている可能性があるため写真のアップロード手前で止めています。一方で意図せず最新のZenfone3が位置情報記録OFFだったため新規記事(5/20分)の写真は追加しました。

昨日から旧サイトにここへのリンクを置いたので、このサイトへぼちぼちアクセスがありました。HTTP/2が動いているか若干不安でしたけど、サーバーのログを見ると"GET / HTTP/2.0″でアクセスできていて問題なさそうです。

検索サイトによるクロールブロック(robots.txt)やインデックス化拒否(noindex, nofollow)を解除しました。昨日夜ごろからはGoogleでの検索対象に載ったようです。

心配していたEXIFデータ中のGPS情報は2010年分には一つも入っていませんでした。ただ、2013年前後で読み出そうとするとゼロ除算エラーでスクリプトが止まるファイルがありました。2014年以後の画像は問題ないので特定の期間のカメラ(携帯？)がおかしな座標を書き込んでいたようです。未測位状態でゼロフィルか何かのようです。解析に少し時間が要ります。

また、はてなダイアリーからエクスポートしたデータ(2010-01-04, 2010-01-05)のタイトルに”＆”(オリジナルは半角)が入っていて”＆ａｍｐ；"(わざと全角)にエスケープされていた部分をWordPressのインポーターが取り込めずしばらく悩みました。結局、UTF-8全角＆(U+FF06)に置き換えて解決しました。

このため本日の進捗は3件(+画像120枚程度)だけとさっぱりでした。

昨日(5/20)一日で160件のデータ(〜2009年)を移行しました。2009年までのOCNブログ人で公開していた頃のデータは写真の解像度も低く容量も小さいのですけど、はてなダイアリーに移行後はどんどんデータが増えていきリンクなども複雑になるため移行の難易度も上がります。

移行データについて日付は維持できるようですが時刻はうまく取り込めない(時刻を移行しようとすると日付が1970-01-01になる場合がある)ので削除することにします。

まぁ、元々SEOガン無視で運用していましたし、はてなダイアリー側での対応はどうしようも無さそうなので今回の移行もデータを移動するだけでリダイレクトなどといった自動処理はできないですし今更する気もしません。(一応調べましたけど…)

Luxeritasでサイトマップをつくる方法と固定ページの投稿日時を非表示にする方法(https://martto.net/luxeritas-theme/howto/7310/)を参考にサイトマップ(https://kadono.xsrv.jp/sitemap/)を追加しました。後日追記)2週間以上経ってもアクセスゼロのため削除しました。

エックスサーバーX10プランの料金を支払いました。

画像データのWordpress経由でのアップロード・一般ユーザーのHTTP/2でのダウンロードによるデータ損失が無いことをバイナリコンペアで確認しました。このサイトhttps://kadono.xsrv.jp以下ではブログサービスやサーバーサイド圧縮機能(現在無効設定)による劣化はありません。高解像度データも元のまま(EXIF情報付き)で公開します。携帯電話キャリアやブラウザでの圧縮設定などユーザー側での圧縮については分かりません(この手のはサーバーの設定では対応できません)。

はてなフォトライフでは全画像一律でしか設定できなかった位置情報(EXIF内のGPSデータ、非公開にしていました)も画像ごとに判断します。が、測位した位置情報を含んで撮れていると思っていたZenfone3の画像がデフォルトOFF(?)で検索スクリプトでチェックしてもほとんど無かったのは思い違いでした。

　あっという間に前回交換から5000km走行したので朝一で京都トヨペット七条本店へ行きエンジンオイル交換とタイヤのローテーションを依頼しました。朝一(10:00)で予約していたつもりでしたけど実際の予約は11時だったらしく、私が寝ぼけていたようでしばらく待ちました。
　待っている間にやたらボロボロになった雑誌を読もうかな…とパラパラ見てキンドル版を検索している間に出来上がったので雑誌は別途キンドル版を購入して読むことにしました。

※これがWordPress 4.9.6 (Luxeritas Child Theme テーマ)でプリウスについての最初の記事です。
近況、整備上がりで高速走行。

Prius ODD Meter 465060km. (入庫時)

はてなダイアリーからエクスポートしたMovable Type形式のテキストデータをWordPressにインポートすると日付が1970-01-01になる問題はAM/PMだけが原因では無い模様(削除しても発生)。→日付だけ残して時刻(HH:MM:SS [AP]M)をすべて削除するとこの問題は発生しなくなる？ようです。

エックスサーバー設定初日の昨日(5/19)一日で280件のデータを移行しました。１０年以上前の記事に含まれていたOCNブログ人時代の画像ファイルがすぐには見つからなかったので後日探します。あと、ブログ人→はてなダイアリーの移行時に改行がおかしくなっている記事も散見されます。以下の文字列置換で一律直せる部分は直していますけど個別対応が必要な部分はまだです。

なぜかp,/pが２重になる記事が放置されていました。
置換前：<p><p>　→　置換後：<p>
置換前：</p></p>　→　置換後：</p>

この記事の右側のアーカイブ下端になぜか0年というのが表示されるようになりましたけど、最新の記事へのリンクになっているだけで実害は無さそうなので当面放置します。

はてなダイアリー側はJavaScriptを利用した301リダイレクトもcanonicalの設定もできないため、どこかのタイミングで一気に移行する必要がありそうです。はてなブログは301リダイレクトができるようなのですけど２段階で転送するのもどうかと思いますので移行して削除する方向になります。それでも、確実に1970-01-01を防止できる方法が見つけられないと厳しいです、あと1200件ぐらいか。

WordPressの記事エディタにだいぶ慣れてきました。極端に違うわけでは無いのですけどリビジョンがきちんと管理されて差分をひと目で確認できたり自動保存がきちんとできたり気の利いた機能が使えるのははてな記法が使えなくなるデメリットを上回りそうです。

はてなダイアリー側で削除したページを見てもサーバからは404が返らない。(Googleでチェックするとソフト404扱い→Search Console ヘルプ | ソフト 404 エラー(https://support.google.com/webmasters/answer/181708?hl=ja))新しいWordPressで試したところきちんと404で返していました。移行するメリットが増えました。

はてなダイアリー(旧アドレス：d.hatena.ne.jp/tnakada/)からの移行作業を行っています。

設定作業中につき、突然デザインなどが変更になったり、記事が増えたり減ったりする可能性があります。内容や運営方針ついては大きく変更するつもりはありません。

ただし、テーマはこのLuxeritas 3 (https://thk.kanzae.net/wp/)にします。このテーマを見つけたことで移行する気になりました。

WordPressへの移行のついでに常時SSL化などはてなダイアリーでは対応を投げられた新技術投入も行います。

RSSのフィードはhttps://kadono.xsrv.jp/feed/などから取得できます。(ボタンなどは特に置きません)

Amazon.co.jpアフィリエイトURL登録済
Google Analytics (gtag.js)登録済み
常時SSL化(+HTTP/2対応)済←.htaccessへの追記でつまずきあり
https://www.xserver.ne.jp/manual/man_server_fullssl.phpの説明では.htaccessに以下の３行を追加とあるがどこにかが書いていない。先頭にただ追加すると期待した動作をしませんでした。非公式の解説サイトを検索して以下の赤太字のように括ってやると動きました。マニュアルによると常時SSL化とともにHTTP/2に対応しているらしいのですが確認はまだです。
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} !on
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</IfModule>

　ここ数年以上同メーカーの業務用スタンダード(-22℃まで)の20L入りを購入していました。しかし、保管場所を取って邪魔なのと厳冬期に一気に消費して夏場は徹底的に水道水で薄めるためAmazonで安売りしている2L入りも購入してみることにしました。なぜか配送料込みでも1L当たりの単価が20L入よりも安かったです。たまにオートバックスなどでも見かける在庫処分品でしょうか？。裏面ラベル記載の品番は12-007でMADE IN JAPAN表記入りです。

　スタンダードではなくエクセレントということで油膜取りが配合になります。その代わりに凍結温度が-6℃となっているため私が通行する厳冬期の山岳路では確実に凍結しますので夏季限定仕様になります。天候にもよりますけど、経験上2Lなら2〜3ヶ月で使い切ると思います。
早速補充して少しだけ使ってみました(洗剤は左端の青色の液が入ったタンクです)。
薄めに薄めたスタンダードに比べて虫の残骸などが落ちやすくなったような気がします。単に洗剤の濃度が上がったからかエクセレント版だからかは不明です。空き容器もラベルを張り替えればスタンダード(20L容器からの移し替え用)に使えそうです。

↓今後はこのタイプのAmazonアリフィエイトリンクにしようかと思います。ボチボチ差し替えます。