エレクトロニクス

　はてなフォトライフの謎仕様は昨日書いただけでなく、以下の記事によると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(?)で検索スクリプトでチェックしてもほとんど無かったのは思い違いでした。

はてなダイアリーからエクスポートした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>

　”はてなダイアリー”のパフォーマンスがかなり悪化してきました。対策として以前から検討していたレンタルサーバー＋WordPressへの移行を開始しました。記事を再確認しながら一度に移行するには厳しい量(記事1400以上、画像2000以上)があるため古い記事から順番に移行します。改行コードや誤字脱字など移行の際のチェックで見つけたミスは出来る限り修正していきます。10年以上前の記事は削除しようかとも思いましたが読んでいるうちにもったいない気がしましたので2005年以降の記事については公開を続けます。
また、はてなブログとは異なり301リダイレクトなどSEOを考慮した移行はできそうにないため移したデータから削除してソフト404になるようにします。
この週末だけではまだ100%デザインなどが詰められていないため急な変更、記事の増減などがあるかもしれませんが移行途中でも読んでいただけるならば、https://kadono.xsrv.jp/のあたごやまにっき(WordPress版)をよろしくお願いします。HTTP/2など最新技術の恩恵により、サーバーのレスポンスは非常に速くなっていると思います。
RSSなどの更新チェックをフィードしていただいている方はお手数おかけしますが、https://kadono.xsrv.jp/feedへの変更をお願いします。新規記事の投稿は原則として新サイトでのみ行います。

　たぶん5年以上ぶりに記事の表示について以下の微調整を行いました。
1ページの表示日数：5ページ→10ページへ増量。まとめて読みやすくしています。回線容量の激増により画像が多少入っても大して遅くならないと思います。

キーワードの自動リンク設定のスコアの閾値：30?(忘れましたが確か初期値)→100(非表示)。私の独断と偏見ですが全く役に立たないと思うので無効にしました。

こういった記録も残しておかなければ忘れます。というか、以前どこを変えたかもう覚えていません。

　Panasonicの配布ページCF-LX3シリーズ　BIOS アップデートプログラム(http://faq.askpc.panasonic.co.jp/faq/docs/004718?no=7&trn_org=3)から更新プログラムと手順書をダウンロードして作業を行いました。同じ機種でも更新前のバージョンによって更新ファイルが異なるので確認してからダウンロードした方が効率がいいです。
BIOS更新画面
更新後
更新前(L17でした)
更新内容は

下記の脆弱性に対応しました。
・Side Channnel Analysisに対する脆弱性(Intel-SA-00088)

だそうです。ついでに累積使用時間を調べたところ6520時間になっていました。