php で書いたトラックバック受信用のプログラムが、ping リクエストの内容を文字化けして吐き出すようになった。別サーバではバッチリ動いているのに、なぜ。

$charset = $_POST['charset'];
if (empty($charset)) {
    $charset = "utf-8";
}
$excerpt = mb_convert_encoding($_POST['excerpt'], "euc-jp", $charset);

リクエストに charset の指定が無い場合は、デフォルトで「utf-8」を使用することにしていたのだけれど、どうもこれがいけないらしい。この処理を省いたら、文字化けしなくなった。

それでも別サーバでは正常稼動していたのだ。どうも釈然としないなあ。

続きを読む "トラックバックが文字化けする"

smtpとかimapとか特定のポートを使用しているプロセスを表示する方法は無いもんかと思って探したら、便利なのがありましたよ。しっかりプロセスIDまで示してくれる。

# lsof -i:25
# lsof -c smtp

psを横目にnetstatを眺め、それでも悶々とした青春の日々よ、さようなら。今後はこいつを徹底的かつスマートに使って、大人の階段を上ります。(意味不明)

FTPクライアントでサーバに接続したら、日付のところが、実際の更新日時より9時間遅れて表示されるわけですよ。SSHでログインする場合は、問題ナッシング。

まあ、ぴったり9時間と言ったら、いつものアレなわけです。何がグリニッジだ。ファイルのくせに、イギリス気取りかよ。ここは日本だよ、東京だよ、新宿区だよ！

どうもFTPデーモン側で、ちゃんと設定しないといけないらしい。
(以下、vsftpd の場合。)

# vsftpd.conf
use_localtime = YES

これが NO になっていたり、そもそも use_localtime の指定が無いと、標準時で表示されてしまう。デフォルトが逆じゃないのかと思うんだけど…。

IE7 RC1日本語版がリリースされてから数日。いろいろイジくって思ったことなど。

リリース候補版なので、そろそろこれを使って動作検証をしないとなーと思い、過去の案件にさかのぼって手がけたサイトを見ていった。どうしようもないほど致命的な表示崩れとかは無かったし、動かなくなるものもほとんど無かった。でも、逆に言えば、少なからず意図しないデザインになった箇所もあったわけで、対応はしなくちゃいけない。このブログ含めて。ううう。

表示崩れを起こした全てに共通するのは、クロスブラウザ対応のため、やむなくCSSハックを使ったところ。DOCTYPEスイッチとか、child selecterハックとか。

そういった表示崩れを修正するために、わずかとは言え、作業をすることになるのだけれども、これが全くビジネスにならない。

クライアントにとって、どのブラウザでも同じように見えることは当然で、その対処のため予算を割くのに前向きになるはずがない。むしろ、IE7で表示崩れすることは、クレームになる可能性が高い。クレーム付けられてもなあ。わずかな作業で、顧客と友好な関係を保てるのなら、その方が長期的にはメリットがある。泣き寝入りするところが、多そうだ。

そもそも、クロスブラウザのために、CSSハックなんかを駆使する努力は、ビジネスの毒に思える。そうしたノウハウを溜め込んで、ビジネスを展開する者もいるかもしれないけれども、そんなネガティブな仕事していて嬉しいのか。そんなところに予算を割くくらいなら、サイト構築の本来の目的にダイレクトに効果がある仕事をした方が、良いに決まっているじゃないか。

Web制作のビジネスを歪ませるクロスブラウザの仕事なんぞ、早く無くなってしまえば良いのに。そして、そんなところじゃないところで、みんなが競い合って、もっと素敵なサイトが増えることを願うばかり。ふぅ。

J2SE 5.0 から StringBuilder クラスが導入された。

このクラスは、ほとんどの実装で高速に実行されるので、可能な場合は、StringBuffer よりも優先して使用することをお勧めします。

ということで、実際のところどんなもんか試してみた。

続きを読む "StringBuffer 対 StringBuilder"

eclipse3.2 + EclipseHTMLEditor2.0.2 の組み合わせで JSTL1.1 を使用すると、「"c"に対応するtaglibディレクティブが存在しないかTLDファイルが見つかりません。」と怒られて、エディターが真っ赤に染まってしまう。

実際にアプリケーションを動作させることは可能なので、単にエディタが URI から TLDファイルを解決できないんだろう。でも、設定を見る限りは、URI も定義されていて大丈夫っぽいんだけどなー。

JSTLタグの補完機能が使えないのは痛いので、解決法が見つかるまでは、3.1にダウングレードして開発することに。何か情報をお持ちの方は、ご一報くださいまし。

遅ればせながら、ようやくeclipse3.2を導入した。

しかし、エディタでJSPファイルを開いたら、とんでもなく文字化けしていらっしゃる。なんだこれは。3.1まではこんなことなかったのに。そこでファイルのプロパティを見てみると、文字コード設定が「ISO-8859-1」になっているではないか。

エクリプス氏曰く、「デフォルト(内容から判別する: ISO-8859-1)」だと。

いやいや、内容から判別できていないから。こっちはMS932で書いているんだよ、遊びじゃないんだよ、本気と書いてマジなんだよ。なんだそれ。

ファイルごとにプロパティを開いて正しいエンコードを設定するのもだるいので、どうにか一括して設定できないかと思って探索したら、見つけました。

[ウィンドウ]＞[設定]＞[一般]＞[コンテンツ・タイプ] で、ファイルタイプごとにデフォルト・エンコードの設定を行える仕様だった。うげー、分かりづらいッス。

ただし、プロジェクトごとに設定したりはできないんで、文字コードの異なるプロジェクトが並行して走っているときは、面倒くさい。.settingファイルを直接イジったりすれば、いけるのかな？

つーか、プロジェクトごとに文字コードが異なるってのが、ダメだろ。ううう。

「リソースファイルを WEB-INF/classes 以外の場所に配置できないもんか」の続き。

クラスローダーから見えない properties ファイルは参照できないんだなー、残念だなー、今日の雨は秋の訪れを予感させるなー、おでん食べたいなー、とか思っていたのだけど、実は相対パスで上の階層まで見れることが判明！

ClassLoader loader;
InputStream inputStream = null;


String path = "../../hoge/test.properties";
Properties properties = new Properties();


try {
    loader = Thread.currentThread().getContextClassLoader();
    inputStream = new BufferedInputStream(loader.getResourceAsStream(path));
    properties.load(inputStream);
} catch (IOException e) {
    e.printStackTrace();
} finally {
    if (inputStream != null) {
        try {
            inputStream.close();
        } catch (Exception e) {
            //
        }
    }
}

こんなことができるとは知らなんだ。頭は柔軟じゃないとダメっすね。