< | >

Unixタイムで表示される日付
  • (2009-05-30 09:31:36)
tksqliteでSQLiteからテキストデータを落とすも日付がおかしい

-------------------------------

tksqliteを試している。世の中には凄い人々がいるものである。感謝したい。問題は一気に解決。データベースの記事内容のテキスト変換は可能となった。

文字コードも、PHPで日本語処理する際、標準的に使用されるUTF-8だけでなく、Shit_JISが使える。PC上で操作する際はやはり、Shit_JISが便利。

しかし、日付がおかしい。たとえば「2005/10/24」とあるべきところが「1234567890」となる。

これは「Unixタイム」や「Unix時間」と呼ばれる表記方法。「エポック秒」とも言うらしい。1970年からの秒数で表現されている。PHPでは日時のデータ型がないのでストリングで表現とのこと。日時と秒総数の変換はdateとStrToTime関数で行うらしい。

Excelで変換する場合:

・Unix時間->Excel

=TEXT(A1/86400+("1970/1/2"*1-"1900/1/1"*1+"9:0"*1),"yyyy/mm/dd hh:mm:ss")

・Excel->Unix時間

=(A1-25569)*86400

Unix時間変換関数:

date("Y/m/d H:i:s",1234567890)

strtotime("2005/10/24 07:00:35")

<?php

print <<<eof

<HTML><BODY>

// 1970/01/01 00:00:00 GMTからの秒数<br>

//※「Unix epoch(1970年1月1日 00:00:00 GMT))からの通算秒」<br>

// タイムスタンプから YYYY/MM/DD hh:mm:ss 書式化にする<br>

// http://www.php.net/manual/ja/function.date.php<br>

<hr>

・1130104835の変換<br>

・1217300258の変換<br>

・1218054938の変換<br>

<br>

eof;

//-------------------------------

$a = date("Y/m/d H:i:s",1130104835);

$b = date("Y/m/d H:i:s",1217300258);

$c = date("Y/m/d H:i:s",1218054938);

echo ($a."<br>");

echo ($b."<br>");

echo ($c."<br>");

echo ("<br><br><br>");

// 日付の文字列からタイムスタンプにする

echo strtotime("2005/10/24 07:00:35")."<br>\n";

echo strtotime("2008/07/29 11:57:38")."<br>\n";

echo strtotime("2008/08/07 05:35:38")."<br>\n";

//-------------------------------

print <<<eof

<hr>

</BODY></HTML>

eof;

?>






< | >

SQLite2データのインポート&エクスポート
  • (2009-05-29 11:10:23)
SQLiteのデータをExcelで操作。一括変換も楽勝(にしたい)

-------------------------------

MySQLはハードルが高い。その点、SQLiteは軽くてローカルで動かせてログインの必要もなく愛用者が今後増えそうなデータベースエンジンに見える。

お手軽なデータベースなのでブログのデータベースエンジンとしてさりげなく使われている場合がある。このサイトもSQLiteにお世話になっている。

手軽なのに人の欲望はさらに手軽に扱いたいと思うようになる。ブログデータをブラウザー上からだけやっていると非効率的。特に過去のホームページのデータの移行時や一括変換には不向きである。

そのため、csvファイルなどで自由にインポート&エクスポート可能であれば、置換や修正など一気に一括変換などのテキスト処理した上で、データをデータベースに戻せたらどんなによかろう。

SQLiteのデータベースファイルをローカル上で、しかも簡単なアプリ上で読み書きできるようにしたい。csvファイルに落としてExcelで操作する方法やAccessのようにローカルで手軽に操作できるアプリケーションはないかと探し回る。

WindowsにSQLiteの環境を構築すれば、SQL文で操作できそうだが、これは時間が掛かる。GUIベースのツールを捜す。

・SQLite Database Browser

sqlitebrowser-1.3-win.zip

残念ながらSQLite3の対応。SQLite2は読めない。

・PupSQLite

pupsqlite.zip

残念ながらSQLite3の対応。SQLite2は読めない。

・TkSQLite

tksqlite-0.5.7-win32-bin.zip

http://reddog.s35.xrea.com/wiki/TkSQLite.html#download

行けそう。

-------------------------------

tksqlite操作手順

-------------------------------

(ブログデータをダウンロードし、tksqliteで開く。csvファイル(テキストファイル)でエクスポートし一括編集してインポート。そのデータを再度アップロードする)

・データベースのデータをダウンロード(blog.sqlite1)

・データベースをtksqliteで開く

・エクスポート:

main->テーブル->entryダブルクリック->ファイル->書き出し->テーブルentryを選択->

コンマ、出力先文字コードshiftjis->テキストファイル完成

 

・インポート:

テキスト編集->読み込み->入力元文字コードshiftjis






< | >

CTIの顧客データは作り込む時代
  • (2009-05-26 10:24:29)
CTIソフトのデータベースと自前データベースの統合は少し先

-------------------------------

昔、電話帳という凄い本があった。日本中の企業から個人宅をかなり広範囲に網羅していた番号案内。タウンページは住所まで載っているのでアドレスデータベースである。「ザ・イエローページ」や「市街案内帳」という感じだ。

紙媒体という点が惜しかったがCD版も出たしインターネット版もある。しかし、今時、企業や会社、商店、施設などは除いて個人が電話帳に自分の電話番号を掲載したい人は少ないだろう。

市販されている安価なCTIソフトウェアにデフォルトで搭載されている顧客データは昔のNTT電話帳をベースにしたもののようだ(ソフトハウスさんはNTTからデータをもらえないだろうから、手書きでコピーしたのだろうか?)。

携帯電話の電話番号、インターネットのIP電話の番号などは当然掲載されていない。そして、携帯電話とIPフォンは猛烈な勢いで増加中ながら、昔ながらの固定電話・有線電話はむしろ減少中である。新規顧客が電話をしてきたときそのフォンナンバーから検索ヒット率はもはや10%もないのではないだろうか。

(それに加え発信者ナンバー通知をしないオプションを選択されているお客様も多い・・・これはCTI泣かせ。発信者番号の非通知はプライバシーを守る一方犯罪に利用されがち。政治的に曲がりくねった制度)

市販のCTIソフトに対する不満はデータベースの柔軟性のなさ。この種のソフトのデータベースはおまけ程度に認識されているのだろう。期待しないほうがよいかもしれない。理想は自社の顧客データベースをそのままCTIのデータベースとして利用することだと思うが、開発する時間も能力も不足している。

ナンバーディスプレイ機能のあるTAやナンバーディスプレイアダプタは受信データに含まれる相手の電話番号を拾い出してくれる。その番号をシリアルポート(RS232やUSB)経由で顧客データベースに渡して検索をかけるだけのシステムなので苦労すれば自分でもそれらしきものが作れそう気がしないでもない。

しかし、プライオリティは高くない。当面CTIソフトに付随するデータベースと自社の顧客データベースの定期的な整合性をマニュアルで行う運用がよかろう。






< | >

ケータイ以外からのメール受信拒否
  • (2009-05-25 07:18:39)
購入時の初期設定でメール受信拒否になっているケータイが増加中

-------------------------------

ケータイからのお客様は増加する傾向にある。昔からPCを使っている人間にはケータイでインターネットを巡回することは想像しにくいが意識改革をしたほうがいいようだ。現実に顧客の3割程度はケータイユーザー。当社のWEBサイトがケータイユーザーに不親切な構造になっていることを考える驚くべき現象と言える。

これらケータイユーザーに対して、どういうWEBサイトを構築すべきか、目下抱えている問題も明確ではなく、また将来のあるべき姿への具体的なプランも描けていない。自分達のモバイルECに対する構想の弱さを感じている。勉強して当社なりのプランなりポリシーなりを早急に打ち立てべきである。

差し当たりケータイユーザーへのメールが届かない問題はなんとかしないとECの基本である「コミュニケーションリンクの確率」ができない。

近年のケータイは購入時の初期設定でケータイ以外からのメールの受信を拒否する設定になっている機種が多いようだ。顧客が注文した結果の明細は届かず、当社からの発送通知も、連絡事項も届かない。顧客はその事実さえ知らないケースが大半である。

かといってゴリ押し的に個別に電話をかけるのも顧客にとっては迷惑に感じる人も多かろうし、当社にとっては負担が大きい。

対策案として次の対策を施した:

・WEBサイトの目立つところに受信拒否設定になっているケータイが多い事実を告知する

・受信拒否設定になっていると推測される顧客には商品とともにメールが届かない事実をお知らせするメッセージカードを同梱

・メール連絡の必要がある場合はPCからではなく当社のケータイから送信する






< | >

cblog 自動PINGを送信
  • (2009-05-21 06:58:09)
デフォルトでは手動になっているPING送信を自動でオンにする

-------------------------------

「更新情報を通知する」方が検索エンジンは認識してくれる。

・/commonの「ping_servers.txt」でリスト作成。

・/admin/templateの「entry.html」内のコード

<input type="checkbox" name="ping_url[]" value="{ping_url}" />

に「checked」を入れる。




search
layout
admin

[▲page top]