記事のカテゴリー表示の仕方を変更 2018-12-13 (木) 22:37:00+09:00

 ソフトウェア

これまで、当サイトの記事の右上には、

＞「[ソフトウェア]」

のように、記事のカテゴリーが表示されていた。

今回、

＞ソフトウェア

のように見た目を変更した。

変更点は：

style-sites.css 


.key a, .category a {
    padding:3px;
    background-color: #f0f0f0;
    border: 1px solid #a0a0a0;
    text-decoration: none;
}

html_item.skin 


<div class="category">
<a href="<%=$site_base%>rnote.php?u=<%=$Category_Dir%>"><%=$Category%></a>
</div>

この変更で、外見に関してはOK。（置換命令 Category_Dir はサブカテゴリのカテゴリキーを表示させるためにrnote.php にコードを追加する。詳細は後述。）

続けて、サブカテゴリの場合の表示の修正を行う。

例えば、 works/software/ というディレクトリを掘り、 works/software/ のカテゴリ名を「冬星のソフトウェア」とするために、 rnote_config.php に、

＞$category_name['works/software'] = '冬星のソフトウェア';

と書いても、オリジナルの rNote では、カテゴリ名に、「works/software/」としか表示されない。これを、「冬星のソフトウェア」と表示されるように変更を加える。

// ITEM用スキン処理・本体
function GetContentsEach($fname,$skin,$bSingle) の中の、 

    while($tagstr=SkinTagChk('Category',$a,$opt)){
        $dd = explode("/",$dir);
        $cn = '';
        if(sizeof($dd)>1){
            foreach($dd as $dd) if($dd){
                if(isset($category_name[$dd])) $dd=$category_name[$dd];
                $cn .= '/'.$dd;//カテゴリ名がなければカテゴリキーを使用する。
            }
        }else{
            if(isset($category_name[''])) $cn=$category_name['']; else $cn='Home';
        }
        $a=str_replace($tagstr,preg_replace('/^\//','',$cn),$a);
    }

の部分を、下のように変更する。 

    while($tagstr=SkinTagChk('Category',$a,$opt)){
        $cn = '';
        $cd = preg_replace('/^\//','',$dir);
        $cd = preg_replace('/\/$/','',$cd);
        if(isset($category_name[$cd])) {
            $cn=$category_name[$cd];
        } else {
            $cn=$dir;//カテゴリ名がなければカテゴリキーを使用する。
        }
        $a=str_replace($tagstr,preg_replace('/^\//','',$cn),$a);
    }

また、 SkinTagChk(‘Category’,$a,$opt) の while ループの直前に、下を追加する。 

    while($tagstr=SkinTagChk('Category_Dir',$a,$opt)){
        $cn = '';
        if(isset($category_name[$dir])) {
            $cn=$category_name[$dir];
        } else {
            $cn=$dir;//カテゴリ名がなければカテゴリキーを使用する。
        }
        $a=str_replace($tagstr,$cn,$a);
    }

これで、サブカテゴリ works/software/ が「冬星のソフトウェア」と表示され、リンクも貼られるようになる。

[コメントの受付は終了しています ]
この記事のリンク元 | 14 |

キーワード: rNote カテゴリー

キーワードの表示の仕方を変更 2018-12-13 (木) 22:00:02+09:00

 ソフトウェア

これまでは、当サイトの記事の下部には、

＞「この記事に属するキー: [rNote] [XML-RPC]」

のように、その記事に設定されたキーワードの一覧を表示していた。

今回、

＞「キーワード: rNote XML-RPC」

のように見た目を変更した。

変更点は：

style-sites.css 

.key a, .category a {
    padding:3px;
    background-color: #f0f0f0;
    border: 1px solid #a0a0a0;
    text-decoration: none;
}

html_item.skin 

<if def_tag="Keys">
< div class="keys">
< p style="text-align: right">キーワード:
<?php
  $string = '<%=$Keys%>';
  $tkn = strtok($string,",");
  while ($tkn !== false) {
    echo " <span class=\"key\"><a href=\"<%=$site_base%>rnote.php?m=search&cache=off&q=$tkn&u=&cmt=1&and=1\">$tkn</a></span>";
    $tkn = strtok(",");
  }
?>
</div>
</if>

キーワード: rNote キーワード keys

記事中のソースコード表示を見やすくした 2018-12-11 (火) 02:49:00+09:00

 ソフトウェア

いろんなブログで見やすい表示をしているのでやってみたかったソースコード表示をやってみた。

などを参考に、Google code-prettify を使ってみた。

rNote への導入手順：

（１）上のページから「 Clone or download 」の「 Download ZIP 」を選び、アーカイブをダウンロードする。

（２） prettify.js, node_prettify.js, run_prettify.js, lang-*.js をサーバにアップロード。

（３） styles の中にある css ファイルをサーバにアップロード。

（４） html_head.skin の <head> </head> 内の </head> 直前に、

<link rel="stylesheet" href="code-prettify/styles/sons-of-obsidian.css">

を追加。

（５） html_body.skin の </body> 直前に、

<script src="code-prettify/js/prettify.js"></script> 
<script src="code-prettify/js/lang-css.js"></script>

を追加。（ lang*.js は、言語ごとの色付けの処理なので、必要なものをここで追加しておく。）

（６）記事の中にソースコードを表示させたい場合、ソースコードの直前に、

<pre><code class="prettyprint linenums">

を記述し、ソースコードの直後に、

</code></pre>

を記述する。

今は Open Live Writer を使用しているので、「Source」タブで直接タグを埋め込んでいる。これでなんとかなっているが、本来、 <pre> </pre> タグで囲んだ部分は、改行がそのまま反映されるのだが、 Open Live Writer がこの部分も改行を削除しだらだらと行をつなげてしまうので、やむを得ず、 <br /> タグを手打ちしている。

まだカスタマイズがあまり分かっていないので（例えば、行番号の部分だけ記事の背景色のままになっているのを、ソースコードの背景と同じ色にしたいが、どうすればいいか分からない、など）、あとで調べておこう。

キーワード: rNote Google Code-Prettify ソースコード表示

ISO 8601 の時刻について考察してみた 2018-12-11 (火) 00:45:28+09:00

 ソフトウェア

PHP による XML-RPC API 利用メソッドの実装に関わって、 ISO 8601 の日本版規格であるJISX0301から、時刻の表記について考えてみた。

この規格では、時刻にどのような値が取り得るのか、どのような値は不正なのか。

JISX0301 規格を読むと、夜の１２時についての説明があり、

  • a)基本形式[000000]拡張形式[00:00:00]を一日の始まり
  • b)基本形式[240000]拡張形式[24:00:00]を一日の終わり
  • 一日の終わりは、次の日の始まりと同一とする

とされていた。

時刻について、２５時とか２６時という表記が許されるのか、また、24:00:00を超えた時刻表記、例えば、24:15:30などが許されるのかについて考えてみた：

５－３ 時刻 この規格は、普通使われている２４時制を基としており、時は[00]～[24]、分は[00]～[59]、秒は[00]～[60]の２けたの数字でそれぞれ表記する。一般的用途では時刻は、４けたの数字[hhmm]で表す。

[24]という時の表記は、夜の１２時を表記する場合にだけ許される（５．３．２参照）。

[60]という秒の表記は、正のうるう秒又はその秒内の時点を支持する場合にだけ許される。

という説明があった。「夜の１２時」とは、ジャスト１２時のことだと考えられるので、２４時という表記が許されるのは、一日の終わりである[24:00:00]を表記する場合のみ、と考えられる。[24:00:01]すら許されないということだ。

また、この説明中の「…秒は[00]～[60]の２けたの数字でそれぞれ表記する」を読んで、「あれ？」と思った。普通に考えると、「…秒は[00]～[59]の２けたの数字でそれぞれ表記する」となるはずでは？現に、「分は[00]～[59]の２けたの数字で表記する」とされている、秒も同じと考えるのが自然な思考だ。おそらく、説明中に出てくる「正のうるう秒」という部分がカギになっているだろうと考え検索してみたら見つかった。

国立天文台の「うるう秒」の説明によると、

  • 古くは、地球の自転を基準にして「１日」の長さが決められ、その２４分の１を１時間、さらにその６０分の１を１分、その６０分の１を１秒としていた。
  • 原子時計で正確な時間が測定できるようになると、実は地球の回転速度にはムラがあり、常に等速で回転しているわけではないことが分かった。
  • 地球の自転が遅い状態が続いたり、速い状態が続いたりすると、地球の自転で決まる時刻と原子時計で決まる時計のずれが大きくなる。
  • そのようなとき、時刻のずれを修正するために「うるう秒」を実施する。
  • 地球の自転速度は、原子時計と比較されながら観測が続けられていて、地球の自転と原子時計によって決まる時刻の差が±０．９秒の範囲に入るように、うるう秒による調整が行われている。
  • 地球の自転と原子時計の時刻の差が１秒に達するような場合に、うるう秒として１秒を挿入することによって、時刻の調整を行う。
  • うるう秒による調整は、６月か１２月の末日の最後の秒（世界時）で行われる。
  • それでも調整しきれない場合、３月か９月の末日の最後の秒（世界時）でも行われる。
  • 地球の自転が遅い（１回転にかかる時間が長い）場合には、２３時５９分５９秒の後に２３時５９分６０秒として１秒を挿入し、その次の秒が００時００分００秒となる。
  • 地球の自転が速い（１回転にかかる時間が短い）場合は、２３時５９分５８秒の次の５９秒をとばし、００時００分００秒にすることにより、１秒減らす。
  • ただし、日本の地方時は、世界時より９時間進んでいるため、日本では７月か１月の初日（それでも調整しきれない場合、４月か１０月の初日）の午前８時５９分の最後の秒で調整が行われる。

ということだそうだ。実際、１９７２年にうるう秒による調整が開始され、それ以来、２０１４年までに２５回のうるう秒（いずれも挿入）が実施されているようだ。（余談だが、うるう秒については、この説明よりさらに深い説明が国立天文台に掲載されており、それを読むと、なぜ、現在までのところ、正のうるう秒だけが実施されているのかなどが分かる。（地球の自転が徐々に遅くなってきているため。）

ただし、うるう秒の実施については、うるう年のように計算で求められるものではなく、地球の自転速度の変化を長期にわたって予測ができないため、将来の実施時期は不明だそうだ。

前振りが長くなったが、うるう秒についてのバリデーションが可能かどうかについて考察すると、うるう秒がいつ挿入されるかは、UTCにおいては５月または１２月または３月または９月の末日の一日の終わりの最後の秒と決まっているので、 XML-RPC での実装を考えると、サーバの規定するローカル時刻のUTCからの時差を考慮し、その時差分を差し引けば、サーバの規定するローカル時刻での、うるう秒が実施される可能性のある日時を決定することは可能だが、実際にうるう秒が実施された時刻かどうかの判定は、過去に実施されたすべてのうるう秒のデータベースでも持たない限り不可能だし、未来に関しては決定不可能だ。あくまで「うるう秒が来る可能性のある日時」しか分からない。

考えてみれば、 UNIX time はうるう秒なんぞ考慮に入れていない。未来の日時が、うるう秒の追加でいつ１秒ずれるかなんて分かるわけもないし、過去にうるう秒が追加されるたびに、 UNIX time の値と経過時刻との関係をずらす処理をOSどころか全アプリケーション、既存の全日時データをアップデートして更新する、なんて馬鹿げたことをするわけもない。

そもそも PHP の日付・時刻に関する標準関数に、うるう秒を表記した日時を渡した場合どうなるかについて調べてみた：

function validateDate($date, $format = 'Y-m-d H:i:s')
{
     $d = DateTime::createFromFormat($format, $date);
     return $d && $d->format($format) == $date;
}
     $v = '2018-12-08 23:59:60';
     print 'validateDate('.$v.')='.(validateDate($v)?'true':'false').'<br />';

は、 false となった。「 DateTime クラスの createFromFormat() に渡す ‘s’ は[00]～[59] 」と、 php.net のマニュアルにも明記されている。うるう秒なぞ秒として認めない、ということだ。一方で、与えられたパラメータを元に UNIX time を返す mktime() は、引数 second に 60 以上の値を渡してもエラーにはせず、 59 より多い秒数分時刻を加算する動作をする。 「 60 秒」をエラーにするかしないかは関数によってまちまちだが、「うるう秒を考慮したものではない」ということは共通している。

要するに、うるう秒についての ISO 8601 の規定は、規定通りに処理することが現実的に無理なのだ。だが、それでも稀に XML-RPC を利用したメソッドに対し、うるう秒の時刻が送られて来ることは考えられる。そのときのことを考慮すると、「エラーにはせず、１秒ずれた時刻として扱われる」という形にする必要があるが、 DateTime クラスの例のように、「60秒はエラー」として false を返したり例外を投げたりするクラスや関数があるだろうことを考えると、コードの全体を注意深く確認して修正しないといけないだろうし、便利に使用していた標準クラスや関数が「使えなく」なるかも知れない。うるう秒対策って、結構面倒な問題なのではなかろうか。

キーワード: ISO 8601 JISX0301 時刻 うるう秒

rn_xmlrpc.php を修正 2018-12-10 (月) 02:43:56+09:00

 ソフトウェア

日時指定での投稿時の動作の修正をした。

これまでは、 XML-RPC の規格に沿って、 metaWeblog API newPost, editPost の dateCreated （ ISO 8601 形式）に UTC 、タイムゾーンが付加されずに送信されることを前提に、送信されてきた dateCreated に無条件で “Z” を付加し UTC であることを明示していた。

しかし、

そこで、 ISO 8601 形式のバリデーションの方法を参考にしながら、 rn_xmlrpc.php を対応させた。

現在の動作は、

ISO 8601 形式（基本形式、拡張形式、混在形式）（ UTC 、タイムゾーンなし）⇒UTC形式として処理し表示。

ISO 8601 形式（基本形式、拡張形式、混在形式）（ UTC またはタイムゾーンあり）⇒タイムゾーンを処理し表示。

となった。

Windows/Open Live Writer が dateCreated に ISO 8601 規約違反の形式（YYYYMMDDThh:mm:ss）で日時を送ってくるので、やむを得ずその形式（混在形式）にも対応させた。

キーワード: XML-RPC Windows Live Writer Open Live Writer ISO 8601 rn_xmlrpc.php metaWeblog::newPost metaWeblog::editPost dateCreated