2010/02/11(木)chrome のHTTP非同期通信・コールバック

ウチでβ版運用中のBCLサーチ。
https://www.basekernel.co.jp/pc/elec/BCLlib.html

上記で検索条件設定の上で検索すると、検索結果が一覧表示され、「詳細表示」の部分をクリックすると、さらに細かい情報が以下のような感じで表示できる仕組みにしてあります。
20100211.png

Firefox だと正しく機能するものの、Chrome だと同じ内容が2回表示される問題があったが、やはり javascript の仕様が違うことによるもの。
要点を以下に示します。
  getdata = new XMLHttpRequest() ;
これは、非同期HTTP通信を行うときのオブジェクト設定。ここは Firefox も Chrome もたぶん同じ。
  getdata.onreadystatechange = function() {
    if (getdata.readyState == 4) { setsdata(rownum,getdata) ; }
  }

  if (navigator.userAgent.indexOf('Firefox') > -1) {
    getdata.onload = function() {
      if (getdata.readyState == 4) { setsdata(rownum,getdata) ; }
    }
  }
ここは、ちょっと注意しなければいけません。
上3行は IE と Chrome では有効ですが、Firefox では上手くいきません。
下の5行は、navigator.appName で、 Netscape とすると、Firefox でも Chrome でも有効になります。
javascript において、navigator.appName は、Firefox でも Chrome でも Netscape を返します。
上記のようにしたところ、Chrome でも表示は正しくできるようになったのですが、他の Gecko エンジン使うブラウザでは、逆に動作に問題起きるかもしれません。

2009/05/18(月)PDFJ が Perl 5.10 で動作しない状況を打破

PDFJ というのは、perl 上で動作する日本語対応の PDF 生成モジュールです。
作者のサイトは こちら 〔中嶋 靖 さん〕

某所サイトで PDF 出力機能をつけていたりするのだが、何故か「ファイルが壊れています」的なエラーになって、Acrovat Reader で表示できなくなった。。

最近、環境上で手を入れたこととして、
・FreeBSD を 7.2R にした
・Apache を 2.2 系にした
・PostgreSQL を 8.3.7 にした
・PHP を 5.2.9 にした
・Perl を 5.10.0 にし、mod_perl も 2.0.4 にした

という感じだが、最初の4つはどうみても関係無いなと。。
最初は何がなんだか判らなかった訳ですが、Perl 5.10 での PDFJ はどうなのか調査すると。。。

「動かない」

そうだ。。orz
ここ → 〔PDFJ を perl5.10 で動かす〕 でパッチを入手し、どうにかパッ チ当ててみると、目出度く元のように表示されました。
利用者がそれなりに広がりがあるはずなのに、情報が少ないことは同感。

2008/09/02(火)PC-BSD 1.5.1 amd64版の日本語環境

3週間くらい前に今まで使っていたPCが逝ってしまい、今あるものを活用するために、中古品で代替を用意したのですが、、

当方は消費電力が小さい AMD cpu ものにこだわっており、そうなると、現行で入手できるものは 64bit ものな Athron64 に事実上限られています。32bit な AthronXP はCPU 本体は流通していますが、肝心な対応マザーボードを探すほうが大変な状況になっています。ここ4年くらいでこんな状況に変わってしまっています。

PC-BSD の 32bit 版には、http://www.ofug.net/~yamajun/files/  などで公開されている日本語入力API の pbi ファイルがあり、これを使うと簡単に使えるようになるのですが、amd64 版には対応するpbi はないです。
 試しに 32bit 版のpbi を強引にインストール試みましたが、全く反応なし。。
 仕方がないので、ports から入れることにしました。
 以下、備忘録的なものです。初心者向けではありません。

1. コンソールを起動し、root になる
2. sysinstall で ports を導入(デフォルトでは入っていない)
3. 以下を root で順番に実行

cd /usr/ports/japanese/anthy
make install
cd /usr/ports/japanese/uim-anthy
make install
cd /usr/ports/textproc/uim-gtk
make install

4.ログインユーザに戻り、ログインユーザのホームディレクトリに移動
5 ~/.xprofile を下記のように編集
export LANG=ja_JP.eucJP
export XMODIFIERS='@im=uim'
export GTK_IM_MODULE=uim

6. ~/.kde/Autostart ディレクトリに 適当なファイル名で以下の内容の起動スクリプト生成。パーミッションを 755 にしておくのを忘れないこと。

#!/bin/sh
uim-xim &
uim-toolbar-gtk-systray &

7. ~/.qt/qtrc ファイル中の[General] セクションに以下の1行を追記

XIMInputStyle=Over The Spot


PC-BSD では、日本語入力は、uim+Anthy の組み合わせがデファクトスタンダートになっています。Shift+スペースキーで日本語入力の on/off を切り替えます。

2008/07/29(火)analog 6.0 の FireFox3対応

Firefox3 になってから、デフォルト設定では表示される文字サイズが大きくてお困りの諸氏も多いかと思います。
ベースカーネルの技術者としては、デフォルト設定であっても Firefox2 や IE6 などと同じようなイメージで表示させたいし、出来る限りその方向で対応しています。
通常は、スタイルシートにて文字フォントサイズを指定することで回避できるのですが、analog6.0 ではスタイルシートの設定がCプログラムでハードコーディングされているようなので、直接ソースコードをいじらなければ対応できないと思われます。

以下の修正で対応しました:
src/outxhtml.c の 58 行目あたりに、赤字の部分追加
57 else { /* default style sheet inline if no external style sheet specified */
58  fprintf(outf, "<style type=\"text/css\" id=\"internalStyle\">\n");
59  fprintf(outf, \"body {\n\tfont-family: Osaka,monospace,sans-serif;\n\t\";
60     "font-size: 9pt;\n\tfont-size-adjust: none ;\n}\n") ;
61  fprintf(outf, "h2 {\n\tbackground-color: #A0C0F0;\n\twidth: 98%%;\n\t"
62     "padding: 3px 6px;\n}\n");
ソースコード修正後、コンパイルして対応完了です。

2008/06/03(火)shoutcast の ID3タグ表示

長らく悩んでいたのですが、解決を見たので・・・
200806031.jpg

これは、Tristate社 開発の Shoutcast 再生専用モジュール BB-SHOUT です。
液晶表示の下の行に  アーティスト名 - 曲名 のように流れてくる曲の簡単な情報が表示されます。

shoutcast は、基本的に mp3 形式のファイルを HTTP を独自拡張したストリーミングプロトコルで流れてきます。
アーティスト名や曲名は、mp3 形式ファイルの中に含まれる ID3 タグ情報を拾って取得するような仕組みになっています。

アーティスト名と曲名を表示させるためには、ID3 タグを設定すれば良いのですが、ID3タグを設定したのに拾ってくれない・・・と悩んでいた方も結構おられるように思います。

FreeBSD 6.xや 7.0で shoutcast をsc_trans で流すことを検討している場合、先ずは sc_trans を捨てること を考えましょう。 sc_trans は基本的な部分は機能しますが、ID3タ グを活用する場合、 FreeBSD では使い物になりません。(Linux 用の sc_trans も駄目っぽいです)
sc_trans の代わりに ices0.4 を使ってください。FreeBSD の場合は、Packages になっています。カテゴリは audio です。
また、ID3 タグは v3.2 で設定する必要があります。
ID3 タグには 互換性が高いと言われる v1.0 から v1.1/v2.2/v2.3/v2.4/v3.2 と6種類あるようです。
ところがこの世に出回っている ID3タグ設定ソフトウェアは v2.4 までの対応で、 v3.2 に対応しているものはなかなか見られません。
v3.2 に対応しているのは audacity 程度しか見当たりません。(要 lame ライブラリ)

200806032.jpg

sc_trans を ices0.4 に変更し、ID3 タグを v3.2 で定義しなおすことで、このようにめでたく ID3タグを拾ってくれるようになります。

2008/03/29(土)2038年問題

遠い未来の話かと思ったら、ついに当方が設計開発したシステムで発生したようで。。orz
Webブラウザである操作をすると、'500 Internal Server Error' で以後の操作が不能になるというので、どこでそうなるか追いかけている最中に、「ある操作」をすると、

Day too big - 47482 > 24855
Sec too big - 47482 > 44047

のメッセージを吐いて Internal Server Error になる、というものでした。
メッセージからして時刻や日付に関する部分であることが類推できるので、それを中心に検証していたら、、
データベース上に 2100年x月x日 のデータを発見。これが原因です。

2038年問題は、どういう問題かというと、現在多用されている Unix / Linux のシステムクロックが 1970年1月1日 AM 0:00:00 からの累積秒数で表現されており、これが 32bit 長のため、このまま何も対策しないと、2038年1月19日 AM 03:47:07 でフルカウントになり、次の1秒で桁溢れになるため、あらゆる誤動作を引き起こす、という問題。2000年問題より深刻とも言われます。
#ちなみにMacOS ではファイルシステムについて同様の問題である 2040年問題があります。

該当システムは、日付部分だけが問題だったので、Unix のシステムクロック(しばしば epoch とも言う)を使わずに、西暦元年1月1日を起算日とする日付(これはユリウス日と呼ばれる)に変換した上で処理することで回避。
ただ、最近のOSは、Unix のシステムクロックを 64bit 長にしているものも出てきているので、流通しているUnix系OSが64bit 長システムクロックになれば、オーバフローは更に2900億年ほど先になるので、その方向で対策はされる模様。
少なくとも FreeBSD 6.x においては システムクロックは 32bit 長表現みたいです。(gcc のバージョンも 3.4 だし。。)
gcc のバージョンがあがった FreeBSD 7.0R ではどうでしょうか。(gcc のバージョンは 4.2.1)


※追記:
簡単に確認できるようなので、早速試してみることに・・・
FreeBSD 7.0R i386版

[1]% date -u -r 2147483647
2038年 1月19日 火曜日 03時14分07秒 UTC
[2]% date -u -r 2147483648
1901年 12月13日 金曜日 20時45分52秒 UTC

FreeBSD 7.0R amd64 版

[1]% date -u -r 2147483647
2038年 1月19日 火曜日 03時14分07秒 UTC
[2]% date -u -r 2147483648
2038年 1月19日 火曜日 03時14分08秒 UTC

少なくともプラットフォームが 64bit だと64bit長システムクロックに対応している模様。。

2006/07/09(日)Vodafone のログイン不能の件は解決らしい

 6/236/24 と、Vodafone のC型端末(V3/V4 シリーズなど) で、
 REP310 が出てログイン不能になる現象で難儀している件を記述しました。
 どうやっても解決しない状態で、一旦サポート端末から外そうと決めましたが、
 状況証拠の保全資料作成に取り掛かった直後....
 エミュレータでC型端末判定ルートの動作検証が出来ていない....あれ.....orz
... 旧J-PHONE 端末におけるユーザエージェント解析処理が壊れとるorz...

 早速、エミュレータソフトで確認....
 REP310 が出るどころか、エミュレータソフトそのものが丸ごと変なメモリアクセス異常が起きてお亡くなりになる...
 おそらく実機での REP310エラーが再現したのだろう、と見て、
 ユーザエージェント判定周りみたら、かなり大間抜けなコーディングミスがあったのでした....orz
 早速、修正かけてエミュレータでの動作を確認し、翌日依頼元がアクセス。(確認依頼を某氏経由で行う)
 アクセスログからは、ログインに成功したっぽい感じ。
 しかし、実際に画面の様子が判るような霊視能力は持ち合わせていないので、どうなのか知りたいところ。
 そうこうしていると「ログイン出来ても、そこから先へ進むとエラーになる」とのこと。
 これは原因がはっきりしているので、即座に対応したら、この問題がクリアできたと見えて、怒涛のアクセス...(爆)
 しかし、今度は画像サイズが大きすぎてダウンロードできない場合があるらしいとのこと。
 これも原因は確定しているが、対処方法はちょっと検討を要する問題。
 といっても JPEG の Quality 係数を小さくするか、画像サイズをもう少し小さくするくらいしかないが...

2006/06/24(土)昨日の続き....

 なんと、非セキュアな環境でアクセスしてもらってもログイン不能なのでしたorz

 エラーコード REP310。
 これが何を意味するのか判ればもう少し何とでもできそうですが、全くこの手の情報がありません。
 各種技術情報を読み直す・考えるを何回も繰りかえし、以下かもしれないということで一応対処。
 月曜日にはチェックしてもらえるんだろうか・・

  ○ <input type="submit" ~ > で、value 属性はあるが、name 属性が未定義:技術仕様書には「省略するな」とある...
  ○クエリ値に半角カナは基本的に使えない:submit の場合
 現状、C型端末では、送られるフォームデータがおかしいようだ、ということが何と無く判ったに過ぎません。

2006/06/23(金)やっぱり駄目か? Vodafone V3/V4 シリーズでSSL

 某社のシステム開発は、一般サービス部分の安定化フェーズに入ってはいるが、Vodafoneの一部携帯機種でログインすら出来ない不具合が...orz
 更に SSL接続時に新しい機種全般で文字化け...orz
 某所巨大掲示板の書き込みみると、総じて開発サイドのvodafone評価はかなり悪い。
 確かに出来ることなら関わりたくないくらい、技術資料に不明点や偽りがある。
 更に明らかにバグ(不具合と見受けられる)だが「仕様です」と言い張っているという始末。
 問題となっているのは、C型と呼ばれる古いタイプの携帯端末における SSL 接続。
 技術資料には、C型もSSL 対応とあるが、現在の Vodafone サイトには、「SSL対応はパケット対応端末のみ」とある。

 「パケット対応端末」とは、C型(V3/V4 シリーズ)以降にリリースされたP型(V5/V6シリーズ)、W型(V7シリーズの一部)、3GC型(V7/V8/V9 シリーズ)。
 Web サーバのアクセスログ見ると、P型とW型はアクセスが無いので判らないが、
 V302SH と V402SH はログイン不能で、これらはC型。
アクセスのあった、V705SH,V804SS,V904SH は問題なしだが、これらは3GC型。
 提起のC型端末は、いろいろやってみたが、どうもフォームデータがごっそり送られてこない/無視されるような挙動。
 しかもリクエストURLが http:// にリダイレクトさせるようなとても変なリクエストで、mod_rewrite なんぞ有効にして、URL書き換えなどやって見たが全く効果なし。
 やっぱりパケット非対応端末=SSL非対応なのだろうか。
 V302SH の取り扱い説明書を Web から拾ってきて読んでは見たが、特別特殊な設定は載っていないのです。うーむ。。