2018年の抱負の進捗状況 (6月1日時点)

Life

この記事は自分向けの記事です

もうちょっと頻繁にblogを更新する

5月28日にWindows 10 April 2018 Updateで追加された和暦のレジストリィの話を更新しましたが、本当はゴールデンウィーク中に書こうと思っていた記事で、何とか5月中に間に合わせで書いて公開したような感じになってしまいました

書きたいことがあったのに書かずに放っておいて、公開するのを目的かして公開するという自分としてはよくないblogの書き方をしているので改善したいところです

体重を60kgまで落とす

の朝が67.15kgでの朝が64.85kgでした

日々多少の増減はあるものの、最近はBMIがコンスタントに24程度、体脂肪率は12%程度になっており、BMIや体脂肪から見た状態では脱肥満となりました

この調子でいけば10月には目標が達成できそうなのでこの調子で続けたい次第です

HTML5.2の仕様書を一通り読む

5月はほぼ進みませんでした

読めたのは数段落で、2.7. Common DOM interfaces (共通DOMインタフェース) で完全に詰まっている状態です

興味が薄くてやる気が出ない、英文が難解で理解するための邦訳作業に時間がかかるが要因となっており、2.7. についてはいったん飛ばして興味があったり、楽に読める箇所までいったん読み飛ばしてしまうことを検討しています

応用情報技術者試験に合格する

合格発表はなのでそれまではモラトリアム期間です

Windows 10 April 2018 Updateで追加された和暦のレジストリィの話

Windows

追記 (2019/4/2)

次の元号として令和が発表されましたので、令和のレジストリィを追加するPowerShell Scriptを書きました

Windowsに令和のレジストリィを追加するPowerShell - 木俣ロバート久の覚書 - Hatena Blog

追記 (2018/6/25)

.NET Framework の新元号対応予定について – Japan New Era Name Support Blogにて.NETの仕様変更が発表されました

アメリカ時間のからupdateが提供が開始され.NETの挙動が変わるため、本記事の内容と異なる状態となる見込みですのでご注意ください

各所既報の通り Windows 10 のWindows 10 April 2018 Update (1803) で元号のレジストリィに、に改元予定の仮データが入りました

例によってPowerShellで取ってみます

PS >Get-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\Nls\Calendars\Japanese\Eras';



Hive: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\Calendars\Japanese




Name                           Property






Eras                           1868 01 01 : 明治_明_Meiji_M
                               1912 07 30 : 大正_大_Taisho_T
                               1926 12 25 : 昭和_昭_Showa_S
                               1989 01 08 : 平成_平_Heisei_H
                               2019 05 01 : ？？_？_??????_?

ちなみに、"?" や "？" は文字化けの類ではなく、Unicode でいう 'QUESTION MARK' (U+003F) や 'FULLWIDTH QUESTION MARK' (U+FF1F) の文字が仮データとして入っています

あくまで仮データではあるのですが "必ず漢字かアルファベット" だと思い込んでレジストリィから取得した値をエスケープせずに正規表現に突っ込むと本番では起こらない筈のエラーが出たり意図しない挙動になります (なった)

また、例えばファイルを和暦の文字列で "H30.05.28" のようにしているシステム場合、現時点でレジストリィから値を取得してファイル名を作ると 2019年5月1日のファイルの名前が "?1.05.01" となりファイル名として "?" が使えないためエラーになったりするかも知れないので仮データならではの注意も必要になります

更に、平成31までの日付の文字列は DateTime型に変換できていますが、平成32年以降の日付は変換できなくなっています

PS >'平成31年12月31日' -AS [DateTime];
2019年12月31日 0:00:00



PS >('平成32年1月1日' -AS [DateTime]) -Eq $null; # -AS で変換しているので変換できなかった場合はNullになる
True

また、明治を1、大正を2として明治以降のその時の元号のカウントを返すGetEraも2019年5月1日以降は5を返すようになっています

JapaneseCalendar.GetEra メソッド (DateTime) (System.Globalization).aspx)

PS >[System.Globalization.JapaneseCalendar]::New().GetEra([DateTime]'2019/4/30');
4



PS >[System.Globalization.JapaneseCalendar]::New().GetEra([DateTime]'2019/5/1');
5

以上は.NETの話で、独自実装されたものは勿論それぞれがレジストリィを参照しているかどうかの実装次第ですし、例えばExcelのVBAの場合、 では新元号には対応しておらず、平成32年以降の日付も使えている状態です

例えばセル内のデータを 2030/5/1としてセルの書式設定で元号表記にすればH42.5.1となります

以下のようなマクロで処理した場合も平成のまま処理が行われます

Function ChangeJapanese(ByVal DateString As String) As String
    ChangeJapanese = Format(DateString, "ggge年m月d日")
End Function



Function ChangeChristian(ByVal DateString As String) As String
    ChangeChristian = CDate(DateString)
End Function

セル内の式: =ChangeJapanese("2020/5/1")
セルに返却される値: 平成32年5月1日
セル内の式: =ChangeChristian("H40/1/1")
セルに返却される値: 2028/01/01

というわけでプログラマ各位としては和暦文字列と日付データの変換個所やGetEraの結果が5でも問題ないか (例えばSwichに入れた結果 Default で未知の元号扱いにしていないか……実際現時点では未知の元号なので正しいといえば正しいのですが) などを確認しておいた方が無難かもしれません

もし改元が江戸以前のように数年に1回程度発生してればシステム側としてももっとノウハウがたまっているかと思うのですが、今回は30年ぶり、次回はいつになるか分からないので今回できるだけ記録を残したいなあ、と思っている次第です (改元の契機を考えるなら次の元号も長く続いた方が嬉しいのですが)

そもそも次の改元の時にWindowsや.NETが残っているのかどうか分かりませんが

2018年の抱負の進捗状況 (5月1日時点)

Life

この記事は自分向けの記事です

もうちょっと頻繁にblogを更新する

内容は兎に角、進捗状況報告以外に2本記事を書いたので良しとする、くらいの感じです

もっと内容をとか言っていると書かなくなるので、チラシの裏レベルでもとりあえず更新する癖を付けましょう、位の緩い感じで

体重を60kgまで落とす

の朝が69.4kgでの朝が67.15kgでした

私の身長が165cmなのでBMI が25未満 (67.15/1.652 ≒ 24.7) になり、BMI基準で標準になりました

引き続き60kgを目指しますが、生活習慣を見直して健康になるという目標は今の所、達成できているようです

HTML5.2の仕様書を一通り読む

3月中旬から4月中旬まで忙しくて仕様を読めていなかったのですが、そのまま4月下旬になっても再開できていません

この手の作業はやる気の問題云々ではなく、単に習慣づけて「空いた時間に自然にやる」位の所に持っていくのがベストだと思うので、「暇になったらtwitterみる」ではなく「暇になったらHTML5.2の仕様を読む」位に持っていきたい所

あまり気張ると疲れちゃうので今後ともだらだら続ける心算です

応用情報処理試験に合格する

4月15日に受験しました

合格発表はです

午前、午後とも回答欄を埋めることは出来 (午前はマークシートなので埋められて当たり前なのですが)、それなりの手ごたえはありましたので秋には受かるんじゃないでしょうか (駄目じゃねぇか)

今どきの安全なパスワードについて

Security

2008年にサーヴィスごとに異なるパスワードの生成法と言う記事を書いていたのですが、この内容が (当時から、あるいは現在の基準だと) 間違っている為、内容を更新します

結論: サーヴィスごとに十分な長さのパスワード (パスフレーズ)を使う、漏洩の疑いがある時は迅速に変更し、定期的な変更は不要

パスワード (単語レベル) ではなく、パスフレーズ (単語の集まり) を使い、長い文字列を使うべきです

例えば英数字と記号をランダムに組み合わせた '2v9s!nQ%' よりも 'petbottlecrystalfacility' (PET bottle, Crystal, Facility) の方が安全です

また、サーヴィスごとに異なるパスワード (パスフレーズ) を使うべきです

パスワード (パスフレーズ) が漏れた疑いがある時は迅速に変更する必要がありますが、定期的な変更をするよりも長いパスワード (パスフレーズ) を使った方が安全です

(以降、この記事ではパスワードとパスフレーズを統一してパスワード書きますが、推奨するのはパスフレーズです)

サーヴィスごとに異なるパスワードを使う

サーヴィスごとに異なるパスワードを使うべきなのは今も変わりません

十分複雑なパスワードを使っていても全てのサーヴィスで同じパスワードを使っていれば何かの拍子に漏れた時にあらゆるサーヴィスのパスワードが漏れたのと同じことになってしまいます

サーヴィスごとに別なパスワードにした場合に問題になるのは管理方法ですがサーヴィスからパスフレーズを生成するか、OSやブラウザのパスワード管理機能やパスワード管理ツールを使うのがお勧めです

管理が面倒だからと簡単なパスワードを設定したり、同じパスワードを使いまわすより、普段はOSやブラウザのパスワード管理機能やパスワード管理ツールに任せ、何かの拍子に必要になったが思い出せない時はパスワードの再設定をした方が良いでしょう

長いパスワードを使えば定期的なパスワードの変更は要らない

仮にアルファベット小文字のみ8桁のパスワードが30日で突破される恐れがあるとします

ならばそのパスワードを1桁増やして9桁にすれば26倍の複雑さになり、突破されるまでの期間は 26×30日 = 780日となり、5桁増やせば265×30日 = 3億5644万1280 日、つまり約97万5910年となります

突破されれる恐れがある短いパスワードを定期的に変更するより、突破されにくい長いパスワードを使うべきです

使用する文字の種類を増やすよりも長いパスワードにする

パスワードの組み合わせは使用する文字種のパスワード桁数乗になります

パスワードの桁数の上限が8桁程度と少なかった場合、使用する文字種を増やすとパスワードの組み合わせが増えるため良いことでした

アルファベット小文字のみ8桁の場合の組み合わせ
268 = 2088億2706万4576通り
アルファベット大文字小文字、数字、記号10種の (計72) の8桁の場合の組み合わせ
728 = 722兆2041億3630万8736通り

しかし、パスワードの桁数を増やせば使用する文字種が少なくても十分複雑なパスワードを作ることが出来ます

アルファベット小文字のみ11桁の場合の組み合わせ
2611 = 3670兆3444億8698万7776通り

アルファベット小文字のみ文字26種類のパスワードでも11桁あれば文字72種8桁のパスワードの約5倍複雑なパスワードを作ることが出来ます

ですので8文字のパスワード、例えば 'babymaze' を8文字のまま 'a' を '@' に 'e' を '3' にして 'b@bym@z3' と言うもパスワードを作るよりも、覚えやすい単語、例えば "fish" を足して "babymazefish" にした方が、より複雑で人間にも覚えやすいものになります

なお、前述の 'a' を '@' に変えるような変換や、キィボードを隣にずらすようなノウハウは攻撃者側も十分の承知しているため、安全性を高めることになりません

ありがちなパスワードは駄目

一般的にパスワードは入力を受ける側はハッシュ値で保存しています

ハッシュ値とはある値を別の値に不可逆的に変換した値で、例えば 'cat' が 'WNS'、'dog' が 'HYB' になったりします (あくまで例です)

暗号化と違ってハッシュ値は変換後の値から変換前の値に復号するのが非常に困難ですが (基本的に総当たりで計算することになる)、予め 'cat' が 'WNS'、'dog' が 'HYB' になることが分かっていれば逆引き辞書を作り、'WNS' なら 'cat'、'dog' なら 'HYB' と知ることが出来ます

このような攻撃者の逆引き辞書でパスワードが突破されないために「辞書に載っている文字をパスワードにしてはいけない」と言われています

この場合の「辞書」とは攻撃者が用意する逆引き用の辞書の事なので、一般の辞書には乗っていなくても 'aaaaaaaa' や 'p@ssw0rd '、'abcd1234 '、'qwertyui' あるいは日付になる様な8桁の数字などありがちなパスワードは使ってはいけません

そして前述のように 'Password' のようなありがちな単語を 'a' を '@' に変えて 'P@ssword' にしてもパスワードとしてやはりありがちな単語のままであり、安全性を高めることになりません

部分的に辞書に載っている単語でも問題ない (全体はだめ)

前述のように一般的にパスワードは入力を受ける側はハッシュ値で保存しています

しかし、先の例のように 'cat' が 'WNS'、'dog' が 'HYB' になる場合でも 'cat' と 'dog' を連結した 'catdog' は 'WNS' と 'HYB' を連結した 'WNSHYB' にはならず、全く別な値になります

このため、パスワードの一部分が辞書に載っている単語でも全体として辞書には載っておらず十分複雑なパスワードなら問題ありません

(パスワードの一部が予め攻撃者に知られてしまっているのは話が別です、念のため)

NHK受信料ゥァア゛ーッ (NHKは悪くないです)

Life

NHKは悪くなく、この記事は私が踏ん切りをつけるために書かれました

私は2012年9月に結婚の為に実家を離れ今の住居に引越しし、世帯も独立させ、電気ガス水道などと共にNHKとも新規に契約しました

地上契約のみで

しかし、私の入居している集合住宅は衛星放送も受信できており、(入居直後の契約申し込み時点の認識は覚えていないのですが) その後NHKのBS1やBSプレミアムも見てました

契約してないので、契約を促すメッセージでますが

メッセージは出ていますが、なぜか自分は契約しているものと誤認した上で「メッセージの消し方わからないけど、面倒だからまあいいや」と思って放置してました

今に至るまで5年7か月

衛星契約への変更に伴う契約変更差額
月数 1か月分 2か月分 3か月分 4か月分 5か月分 6か月分
契約変更差額 970円 1,940円 2,910円 3,880円 4,850円 5,540円
月数 7か月分 8か月分 9か月分 10か月分 11か月分 12か月分
契約変更差額 6,510円 7,480円 8,450円 9,420円 10,390円 10,775円
※口座・クレジット払いの場合10,780円
(沖縄県を除く)

NHK受信料の窓口-衛星契約への変更のお手続き

1年を超えた場合はどうなるかわかっていませんが、単純に前述の表から12か月分×5+7か月分とすると10,780円×5+6,510円で未払いの残額は60,410円になるようです

NHK受信料については思うところは色々ありますが、それはそれとしてこの金額は本来払うべきものであるため、ちゃんと申告して払いますけどね

払いますけど、6万円あったら、PC用のゲーミング4Kモニターとかその他色々買える訳じゃないですか、払いますけどね

NHK受信料ゥァア゛ーッ (NHKは悪くないです)

2018年の抱負の進捗状況 (4月1日時点)

Life

この記事は自分向けの記事です

もうちょっと頻繁にblogを更新する

書くことないのに更新を目的にして書いてもしょうがないので3月の更新はなしかな、と思っていたらHTML4.01が正式に終了となったので飛び込みで3月31日に記事を一本書きました

そんな感じでまったりと

体重を60kgまで落とす

の朝が71.3kgでの朝が69.4kgでした

1か月で1.9kgとなかなかの減り具合ですが、時点の体重が便秘気味でたまたま重かっただけなので、グラフで見ると余り減っていません

むしろ直近1週間くらい69.3kgから69.9kgの間で減らずに停滞している状態なのでそろそろ新しい減量法が必要かと思案を始めている所です

に68.0kgくらいになっていると嬉しいのですがどうなりますやら

HTML5.2の仕様書を一通り読む

元々色々多忙になるので3月中旬から4月中旬はいったんお休みとしておりました

4月中旬あたりからまた読み始めて5月の連休前後で記事にできればいいな、と思っています

あと、無職になりでもしないとHTML5.3の勧告に間に合わないのが確実なので、HTML5.3勧告後の方針も決めておかないといけません

うーん

応用情報技術者試験に合格する

秋にご期待ください (今やれ)

さようなら、HTML 4.01

HTML

最新版以外のHTMLをすべて廃止しようという提案がなされていましたが (Proposal to Republish Previous Versions of HTML and XHTML as Obsolete Recommendations (Wide Review until 2017-09-07) from Xueyuan on 2017-08-11 (public-review-announce@w3.org from August 2017) ) これが実行され、最新のHTML5.2以外のW3CのHTMLはSuperseded Specificationと明示されました

私のような未だにHTML4.01やXHTML1.1を書いている人からするとこれはHTML5への移行猶予期間の終了のお知らせで、待ったなしの状況です

今後は単にHTMLまたはXHTMLと言った場合、それは最新のHTML5.xを意味することに成るでしょう

さようなら、HTML 4.01

所で、Superseded Specification (直訳すると、代替された仕様) って何よと言う事なのですが、これは World Wide Web Consortium Process Documentの2018年2月1日改訂版で追加された物です

An Obsolete Recommendation is a specification that the W3C has determined lacks sufficient market relevance to continue recommending it for implementation, but which does not have fundamental problems that would require it to be Rescinded. If an Obsolete specification gains sufficient market relevance, the W3C may decide to restore it to Recommendation status.

A Superseded Recommendation is a specification that has been replaced by a newer version that the W3C recommends for new adoption. An Obsolete or Superseded Specification has the same status as a W3C Recommendation with regards to W3C Royalty-Free IPR Licenses granted under the Patent Policy.

従来から存在した廃止された勧告仕様 (Obsolete Recommendation) は実装のための推奨を辞めるのに対し、代替された勧告仕様 (Superseded Recommendation) は新しい仕様があるのでそちらの実装をしてくださいと言う事のようです

Web上には過去に書かれて更新されていない前世代のHTML文書が多量にあり今回superseded recommendationになったからと言って一斉にHTML5にはならないでしょうから、各ブラウザが直ちにサポート対象外にするとは思っていないのですが、今後とも参照されることを望む文書のオーナーは最新のHTML5.xへ変換するのが望ましいでしょう (私はやる気があんまりありませんが)

それでは最後に今回Superseded Specificationになった仕様の一覧です (私の知る限り)

ちなみに、HTML4.01を参照しているISO-HTMLも実質終了かと思われます (実質の話をするなら始まってもないような……)

また、それぞれの仕様の最新でないバージョン (例えばHTML4.0、HTML5、HTML5.1、HTML5.1 2nd) はSuperseded Specificationとは明示されていませんが、恐らくこれは前提として Latest version を見ろと言う事かと思います

それぞれの仕様の最新でないバージョン (例えば[HTML4.0](http://www.w3.org/TR/REC-html40-971218/)、[HTML5](http://www.w3.org/TR/2014/REC-html5-20141028/)、[HTML5.1](https://www.w3.org/TR/2016/REC-html51-20161101/)、[HTML5.1 2nd](http://www.w3.org/TR/2017/REC-html51-20171003/)) はSuperseded Specificationとは明示されていませんが

と書いていましたが、従来とは別アドレスでSupersededと書かれた文書がありました

HTMLの5.1のSupersededと明示されたアドレスを未だ見つけられていませんが、見つけたら後日追記します