エレクトロニクス

 本日レンタルーサーバーを運営しているエックスサーバー社より連絡があり表題の通り2018/6/12よりTLS 1.0/1.1 を無効化するとのことです。このサイト(https://kadono.xsrv.jp以下)も影響を受けます。詳細は下記公式ページを御覧ください。
【重要】「ファイルマネージャ」「(旧)WEBメール」「phpMyAdmin」「お客様が運用中のWebサイト」における TLS1.0/1.1 の無効化について(https://www.xserver.ne.jp/news_detail.php?view_id=4435)

 既にTLS1.2以降を利用可能なブラウザを使っている方が大半だと思いますので大きな影響は無いと思います。TLSへの移行で思い出したのが2015年のJR東海によるご利用の携帯電話の機種等をご確認ください/SSL3.0脆弱性への対応としてのアクセス遮断(4/11更新)(https://expy.jp/topics/detail/?id=191)ですけどこのときはTLS1.0に【未対応】な多くのi-mode端末が接続不可になりました。

 後日追記)6/22に確認を行いました。確認方法はXSERVER TLS1.0, 1.1無効化確認、TLS1.2のみ作動中(https://kadono.xsrv.jp/2018/06/22/5604)を参照してください。

エレクトロニクス

 特に考えずにhttps://kadono.xsrv.jp/feedの最後に”/”(スラッシュ)を付けて掲載していましたけど、無い方が極わずかながら無駄が減らせるようです。
 レンタルサーバへ移行したのでhttp server (nginx)のログが15年+ぶりに見られるようになりました。それを見ていて気づきました。以下、一部カラムの抜粋です。

"GET /feed/ HTTP/1.1" 301 0 "https://kadono.xsrv.jp/"
"GET /feed HTTP/1.1" 200 11022 "https://kadono.xsrv.jp/"

というようにfeed/からfeedへ301リダイレクトでの転送が行われてからfeedで実データ(このときは11022bytes)を取得しているからです。初めから/無しならば無意味な転送が発生しないため、このサイトでは/無しを推奨することにします(跡地を含めた移行ページの表記を更新しました)。この設定が一般的なものかどうかは分かりませんけどrssとかrss2の後に/は付けないことが多いので同様の扱いかと思います。たかが1リクエストの転送(1hごとの巡回として24/day)だけですのでここのような辺境サイトではあまり大きな影響はないとは思います。それでも、無駄は無駄ですので低減する方向に設定します。
 私のinoreaderの設定(統計情報→iマーク→XMLのアドレスで確認できます)は/付きを削除して無しへ差し替えました。

エレクトロニクス

 はてなダイアリーというよりもはてなフォトライフの変な(はてなな?)仕様により公開していた写真データ中の位置情報がダダ漏れになっていた点についてタイトルの方法にて対応を行いました。
 このサイトへの移行ついでに支障があると独断と偏見で判断した2000+中114ファイルだけ位置情報データのみの削除を行いました。その他のカメラデータや撮影時刻・条件などはオリジナルのまま残しています。100以上の対象ファイルをGUI手動で変更するのは面倒すぎるので簡単なスクリプトを見つけてきて使用しました。
 元にしたのはstackoverflowという英文サイトに掲載されたRemoving GPS data using from an image using Pillow and Piexif(https://stackoverflow.com/questions/38483074/removing-gps-data-using-from-an-image-using-pillow-and-piexif
)
というほぼそのままの記事と一緒に投稿されたプログラムです。ただ、目的が異なるためこの問題点再現プログラムをそのまま使うにはいくつか課題があります。

一つ目はGPSデータが削除できているかを確認していません(.clear後に.getを再度実行)。

二つ目はEXIFの処理後にimg.saveでjpegデータを書き戻すと画像データの再圧縮処理が行われ画像データ本体が元と一致しないばかりか劣化します。

 一つ目の問題はpiexifのドキュメントを読みながら適当に作れば比較的簡単なので省略します。私はこのチェックに加えて再度問題ファイル抽出用の緯度経度計算スクリプトを掛けてダブルチェック後に再公開しました。

 二つ目の問題が少し悩みまして(データ移行が遅くなってすみません)、例によって寄り道していました。jpeg再圧縮時のパラメータをいじってquality=98, optimize=Trueぐらいで見た目はほぼ同じにできましたけどファイル容量がかなり増えてしまいました。そこから新規格のWebPやらJPEG2000やらも試してみましたが全くだめ(容量が増える、非対応ブラウザが多すぎる、処理が重いなどなど)でした。
# img.save(output_filename, ‘JPEG’, quality=98, optimize=True, exif=exif_copy_nogps)
# img.save(output_dir+”/”+file_base+”_nogps.webp”, ‘WebP’, lossless=True, quality=100, exif=exif_copy_nogps)
# img.save(output_dir+”/”+file_base+”_nogps.webp”, ‘WebP’, quality=100, exif=exif_copy_nogps)
# img.save(output_dir+”/”+file_base+”_nogps.j2p”, ‘JPEG2000’) shutil.copyfile(file, output_filename)
piexif.remove(output_filename)
piexif.insert(exif_copy_nogps, output_filename)
 結局最後の2行で解決しました。出力先ファイルをshutil.copyfileでコピーしておき一旦exif情報を削除してそれからGPSデータを消したexifを書き込みます。やり直しが嫌だったので上書きができるかどうかまでは試していません。
 スクリプト全部を晒すことも考えましたけど、フォトライフの二の舞いになる(削除したつもりができていなかった)では困る可能性もあるため要点のメモだけ公開します。
 基本は位置情報が残ったら困る場所では撮影前にカメラや携帯の測位情報付加機能を無効にしておくべきだと思います。が、後処理でもなんとかならんこともなかったというお話です。

エレクトロニクス

 色々試して結局以下の形式にしました。
まず日記なので年・月・日ごとに検索できた方が便利です。
 以下の使い方がWordPress的にアリなのかはよく知りません(よって再変更の可能性もあります)けど、
https://kadono.xsrv.jp/2018で2018年分の記事を表示します。
https://kadono.xsrv.jp/2018/05で2018年5月分の記事を表示します。
https://kadono.xsrv.jp/2018/05/27で2018年5月27日分の記事を表示します。
この機能は大変便利です。ただ、これだけですと同じ日に複数の記事があるとかぶってしまうので個別に識別できる必要があります。色々迷いましたけど連番は不都合もあるため、飛び飛びになるpost_idを採用することにしました。
https://kadono.xsrv.jp/%year%/%monthnum%/%day%/%post_id%
一例:https://kadono.xsrv.jp/2018/05/27/3685
 基本は日付設定までで対応できると思います。post_idを間違えてもその日のデータは表示される仕様のようです。
https://kadono.xsrv.jp/2018/05/01/0000000
でも5/1分が表示されます。ただし、000000の部分が数字以外(hogefuga等)の場合は404でエラーとなります。

 時刻6桁(235959)を提案するページも見ましたけどはてなダイアリーからの移行時に時刻データは削除したため全て000000で重複したためこの案は採用できませんでした。

 このサイトはあくまでも自分を含めた”人”が読むために書いています。決して検索ロボット向けでは無いためSEOを無視してでも使いやすい方に設定します。

エレクトロニクス

一応、旧サイトからの全データを一通り移しました。ただし、以下の点はまだ未対応です。

同一日付に複数の投稿がある場合にパーマリンクが重複(?)何かおかしいですがなぜ一部のみ重複したかは未確認。→パーマリンク設定を変更しました(詳細別記事予定)。関連してカテゴリーのスラッグも英文小文字へ更新しました(日本語入力不可能/困難な環境に対応するためです)。
上記に関連してサイト内リンクが切れている可能性が高い。
PNG画像またはjpegのキャプチャ画像(EXIFデータに日付なし)などでのリンク切れの可能性。
Youtubeの動画へのリンク切れ。(6/24までに修正しました)
縦長で撮影した画像が極端に大きく表示される(横幅で制限のみのため)。→サイズ指定に変更予定。

確認しながら直していきますけど古い記事までは時間がかかると思います。

エレクトロニクス

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

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

エレクトロニクス

昨日(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枚程度)だけとさっぱりでした。