2006-07-31 [長年日記]
_ 登録日を指定したメモ一覧取得API
メモ情報取得APIに、ユーザーと登録日を指定し、特定のユーザーが特定の日に登録したメモ一覧を取得するAPIを追加しました。
登録日指定メモ一覧取得
- URL - http://1470.net/api/memo/daily
- パラメータ(QUERY_STRING)
- userName - 1470.netユーザーID(省略可)。指定すると、そのユーザーのメモ情報のみが対象となる。
- day - 登録日(YYYY/mm/dd形式推奨。省略可)。省略すると当日(APIを呼び出した日)となる。
- リクエストメソッド - GET
- 戻り値
- データ形式 - JSON
- 例 {"result": [{"id" : 998, "updt" : "2006-06-30 02:16:20"}, {"id" : 999, "updt" : "2006-06-30 02:16:21"}, ...]}
- result.* - 各項目
- id - メモID。メモにつけられたユニークなID。
- updt - メモの更新日時(JST)
- ソートオーダー
- rgdt asc, id asc。
- 例
- 呼び出し: http://1470.net/api/memo/daily?userName=ishinao&day=2006/7/30
- 結果: {"result" : [{"id" : 67803, "updt" : "2006-07-30 08:29:57"}, {"id" : 67804, "updt" : "2006-07-30 08:31:41"}, {"id" : 67862, "updt" : "2006-07-30 22:46:56"}]}
_ W-ZERO3[es]買った
ビックカメラに行ってみたら機種変で黒の在庫があるというんで、W-ZERO3初代から機種変更。まだ最低限のセットアップをしただけで、全然使ってないけど、ひとまず持ちやすくなったってだけでも、初代よりずいぶんましな感じ。ただ、持ちやすくなった反面、サイドのボタンの誤爆が増えそう。
契約を変更してみた
今まではつなぎ放題+A/B割+年間契約(3年超)だったんだけど、今度はウィルコム定額+データ定額にしてみた。これでひとまずどのくらいパケット通信を使っているのか数字を見てみることにしよう。つなぎ放題契約だと、結局月にどのくらいパケット通信(W-ZERO3単体+PCとつないで)しているのかの数字がよく分からないから、ベンチマーク用の契約として。
_ 文字コード自動判別がなかなか安定しない
URI情報を取得する際に、そのURIで示されるドキュメントの文字コードを判別して処理を行いたいわけだ。ほとんどはHTMLかXHTMLなんで、
- HTTPレスポンスヘッダのcontent-type: text/???; charset=****の部分から取得する
- HTMLヘッダ中の<meta http-equiv="content-type" content="text/html; charset=****">から取得する
- XMLドキュメント先頭の<?xml version="1.0" encoding="*****" ?>から取得する
- 上記すべてが取得できず、なおかつcontent-typeがtext系だった場合は、mb_detect_encodingで文字コード自動判別を試みる
といった感じの処理をしているんだけど、
- content-typeに本来の文字コードとは異なる適当な(たぶんhttpdデフォルト設定のまま)charsetをつけてくる場合は結構ある
- 実際の文字コードと、HTMLヘッダやXMLヘッダの文字コード宣言とが違っている場合が結構ある(文字コードの設定を変えたけど、テンプレートは直してない、とかかなー)
- 文字コードとして無効な内容(各種typo、SHIFT_JISじゃなくてSHIFT-JISになっている、無指定のつもりでnoneという文字列が指定されている、など)がセットされている
なんて場合があって、なかなか文字化けを根絶することができない。最初のうちはできるだけまっとうなロジックの範囲で、そういう場合にもそれなりの結果が得られるような対応をしていたんだけど、限界を感じてきたんで、微妙にアドホックな手段が混ざりはじめてきた。
というわけで、そのあたりを自分で設定可能なみなさま、設定が正しいかどうかを見直していただけるといろいろと助かります。
そういや、おそらく複数のhttpdで分散処理をしていて、リクエストを投げるたびに違ったヘッダが返される(外れを引くと文字化けする)という例もあったなー。



> 最初のうちはできるだけまっとうなロジックの範囲で、そういう場合にもそれなりの結果が得られるような対応をしていたんだけど、
がそうかもしれませんが,取得したHTMLなりをまるごとmb_convert_encoding()で同じ文字エンコードで変換して壊れないか? ということはされましたでしょうか?
foreach ( array( "UTF-8", ...") as $charset) { if ( $string == mb_convert_encoding( $string, $charset, $charset)) {
// ビンゴ
}
これも99%位の精度かもしれないこと(同一ではない可能性もある?)でかいファイルは重い,SJIS-WINとかも入れないとだめとかありますけど.
なるほど、そういうアプローチは試していませんでした。
ただ、部分的に文字エンコーディングが壊れているHTMLドキュメントは、実は結構多い(トラックバックなどで文字コードが異なるテキストをそのまま表示しようとしていたり、マルチバイト非対応の文字列切りつめをした結果ゴミが残っていたり)んで、取得したHTMLドキュメント全体にそれを適用すると、そういうものを弾いてしまいそうですね。
ASCII範囲のテキストを目印にバイナリセーフなパターンマッチを行って、タイトルや概要などの部分を切り出した後にそういうロジックを通せば、精度が上がるかなー。今度試してみます。