Java + MySQL41 で文字化け対策

Java, MySQL 間の通信を MySQL の文字コードにあわせてやる必要がある。
具体的には, JDBC での接続時に characterEncoding=utf8 など MySQL の
文字コードを指定したクエリをつけてやる。

jdbc:mysql:localhost:3306/foo?useUnicode=true&characterEncoding=utf8

Tomcat なら server.xml などの設定ファイルの 該当 JDBC 接続の Resource で
設定すればよい。

File (URL Scheme)

file:// という URI スキーマを使う事でブラウザ, OS に極力非依存な形で
ファイルアクセスができる。表し方は次の通り。
– ローカルのファイルパス

c:\windows\notepad.exe

file:///c:/WINDOWS/notepad.exe

になり、

/var/log/messages

file:///var/log/messages

になる。
– Windows ネットワーク(WINS)を使ったファイルパス
PC 名 “foo” の共有ディレクトリ “work” を表す

\\foo\work

file://///foo/work

になる。

キーイベント処理中に時間のかかる処理をすると Canvas.processEvent が呼ばれなくなる

たとえば Canvas の子クラスで processEvent(int,int) を次のような実装をしたとする

public void processEvent(int type, int param){
    System.out.println(“processing…”);
    for(;;){// forever
        try {
            Thread.sleep(1000); // メイン処理。1秒待つのを繰り返すだけ
        } catch( InterruptedException e ) {
            IApplication.getCurrentAPp().terminate(); // 割り込みで終了
        }
    }
    System.out.println(“end of process”);
}

実行結果は一見、キーを押した数だけ processing… とだけ表示されるように思われるが、実際は processing…

マウントしているファイルシステムのタイプを調べる

df -T

でOK. 結果は次の通り

Filesystem Type 1K-blocks Used Available Use% Mounted on
/dev/hda1 ext3 36867308 3663864 31330672 11% /
tmpfs tmpfs 452704 0 452704 0% /dev/shm

FreeBSD 4.10 付属のものにはないオプションだけど、FreeBSD ではどう調べるのだろう。

lsvfs
df -t nullfs,ufs

とかしていくしかないのかな。

ミリ秒単位の時間の取得をする

古いメモにあったものを整理のため写した。

// 時間をミリ秒で返す
// (clockid_tにより動作が変わる/CLOCK_REALTIMEの場合システムの実時間時計)
// time.h
int clock_gettime(
    clockid_t clock_id,
        struct timespec *tp
);
clockid_tはCLOCK_REALTIME,CLOCK_VIRTUALなど定数で指定する。
struct timespec{
time_t tv_sec; /* seconds */
long tv_nsec; /* nanoseconds */
};
tv_nsec の値は 0 〜 999,999,999 の範囲になければならない。
参照: http://docs.hp.com/ja/B2355-60104-05/rn04re25.html

この関数はCygwinでは実装されておらず、Windowsでは次の関数を使う。
// 起動してからの時間をミリ秒で返す
// windows.h
DWORD GetTickCount(void);

– ミリ秒以下のスリープ

// req で指定した時間、ナノ秒(1000ナノ秒 = 1ミリ秒)単位で処理をスリープさせる.
// rem はsignalによって停止した場合に残りの時間を格納するためのものでNULLでも
// よい。signalで停止した場合-1を返す。
// time.h
int nanosleep(const struct timespec *req, struct timespec *rem);

参照: <http://www.linux.or.jp/JM/html/LDP_man-pages/man2/nanosleep.2.html>
この関数はCygwinでは実装されていないが、WindowsではSleepがあるから不要ですね。

// windows.h
void Sleep(DWORD dwMilliseconds);

dwMilliseconds=0のとき、優先順位が等しく実行準備のできた他のスレッドに処理を譲
る。該当するスレッドがない場合は即制御を返す。

メール添付ファイルのデコード

– base64 エンコードされて改行区切りになったデータを受けてデコードして出力する。

$ php -r ‘ $buf = “”; while(!feof(STDIN)) $buf.= fgets(STDI
N); $buf = str_replace(“\r”,””,str_replace(“\n”,””,$buf)); echo base64_decode($buf); ‘ < /tmp/input.txt > /tmp/output.rtf

jsp の動的 include について

いつも 静的 include (<%@ include path="foo.jsp"%>)だったが、初めて動的 include (<jsp:include /> を試してみた。
– 静的なものと違い, ローカル変数, メソッド定義, import 構文はそれぞれに独立
– page スコープの属性は互いに参照できない(pageContext の attribute など)
– request スコープ以降のものは参照可能。
なので影響範囲を最小にしつつ参照するには request スコープを使うとよい。
– jsp:param (ex. <jsp:param name=”foo” value=”123″ />)はリクエストパラメータ(request.getParameter(String))になる。
– jsp:include 呼び出しと通常のリクエストとを区別するには request スコープでやり取りするとよさそう。

Tomcat 5.x + JNDI の基本設定メモ

毎回なぜかつまづいていた JNDI の設定が今回はすんなりいったのでメモ。
 
– foo という Web アプリケーション(ex. “TOMCAT_HOME/webapps/foo”)の中に, jdbc/privateDB という JNDI リソース名を, MySQL 公式で手に入る JDBC コネクタを使ってローカルの MySQL サーバの, foo_db というデータベースに, ユーザ user_foo, パスワード booboo で接続するリソースを割り当てるには, META-INF/context.xml をたとえば次のように設定する。

<Context path=”/foo” docBase=”foo”
                        debug=”5″ reloadable=”true” crossContext=”true”>
        <Resource name=”jdbc/privateDB” auth=”Container”
        type=”javax.sql.DataSource” driverClassName=”com.mysql.jdbc.Driver”
        url=”jdbc:mysql://localhost:3306/foo_db”
        username=”user_foo” password=”booboo” maxActive=”20″ maxIdle=”10″ maxWait=”-1″/>
</Context>

このとき server.xml では一切このリソースについて触れていない。server.xml とか conf/Catalina/localhost/foo.xml とかで複数の箇所で記述してしまうとうまく動かないのかも。

5.x でポートは開いているのに何も応答がない

作業用ディレクトリ(work)への書き込み権限がないと処理待ちでこうなる。
管理者と一般ユーザを分離して使っているWindows 環境(Windows XP + Cygwin) でなって, はまってしまった。
 
UNIX 系列な OS と Windows では管理者権限の扱いが微妙に違うので気を付けないとすぐこうなる..
 
全ての親ディレクトリについてフルコントロール権限を管理者に与え、Tomcat インストールディレクトリ以下の所有者を管理者にし、管理者の状態で実行しなおして解決。
あまりよくなさそう。