デフォルトエンコーディングは廃止すべき!?

Javaでの開発が当たり前になり,Javaプログラマの数も豊富になってきた。しかし,それもここ2,3年のこと。つまり,大多数のJavaプログラマのJava経験年数も2,3年,長くても5,6年といったところだろう。このことは,多くのJavaプログラマがWebアプリケーションしか書いたことがないことも表している。 JDK1.0.2やJDK1.1を身をもって体験している「ベテラン(僕を含む)」が常識と思うことも,現在の多くのJavaプログラマは持ち合わせていない。「全く今の若者は・・・」とつい言ってしまう状況。 JDK1.0.2の頃は,国際化もJavaでは無いに等しかった。唯一の救いは,「どのプラットフォームでも内部表現はUnicodeで統一されていること」だった。今で言うWriter&Reader系は登場前だったため,自前で文字コード変換をしてあげないと,テキストファイルも扱えない。いやでも国際化について気にしなければならなかった。 JDK1.0.2からJDK1.1までの頃に盛んに作られたJavaアプレットは,自分で作ったプログラムが「どこで動くかわからない」のが当たり前だった。動作環境を予測できないことが当然であり,そのために「どこで動いてもいいように」配慮してプログラムを作成することが常識。AWT回りはそれこそOS固有の問題にすぐにぶち当たる。そして署名付きJavaアプレットによるファイル読み込みに関しては,それこそJavaアプレットがどのOSで動いてもいいように,文字コードについて気にしなければならなかった。 Javaは「 Write once, Run anywhere」である。 この精神は昔も今も変わらない。このポータビリティ性こそが,Javaの命であり,普及した最も大きな要因である。アプリケーションコード(=クラスファイル)を一切変更することなく,ハードウェアに限らず,OSまでもスケールアップのために変更することが可能。そして,開発時と運用時のプラットフォームを異なるものとすることができるのも,この精神があってこそだ。 Javaに携わるための最も重要なこの精神を,最近の多くのJavaプログラマは知らない。いや,「自分のところで動けば,他のところでも動く」という間違った捉え方をしているJavaプログラマもいるかもしれない。 Javaプログラマは「Write once, Run anywhere.」について,「どう書いても,どこでも動くようになる」と理解するのではなく,「どこでも動くように,常に気を配れ!」と理解するのが正しい。 では何を気にすればいいかというと,先にも述べたが,文字コードについては特に気にしていなければならない。現在主流のWebアプリケーションでは,サーブレットコンテナなどが文字コードについて暗黙的に自動変換をしてくれたりしているので,昔よりも気にしなければならない箇所は減っている。しかし,テキストファイルを扱ったり,データベースを扱ったり,何らかの通信を行ったりする局面は,どのシステムにもあるはずである。それに対してJavaプログラマは,

  • あ,このファイルは何の文字コードで書かれているんだろうか?

  • 通信相手はどの文字コードであれば理解してくれるのだろうか?

  • マルチバイト文字が含まれていた場合はどうバイト数をカウントすればいいのだろうか? というようなことを当たり前に気にするようでなければならないのだ。 ReaderやWriter系のI/Oクラスや,String#getBytes()系のメソッドでは,文字コードを指定するAPIが存在する。つまり,国際化を常に気にしてプログラムを行うJavaプログラマがこれらのAPIを使用するときには,ほぼ必ず何らかの文字コードを指定して使用する。 Javaには一見便利そうな「デフォルトエンコーディング」という仕掛けも存在する。これは,文字コード指定を省略したAPIを使用したときには,動作しているプラットフォームの文字コードを採用するというものだ。Windowsで動作させればShift_JISが指定されたことと見なし,Redhat Linuxで動作させればUTF-8が指定されたと見なされる。 しかし,デフォルトエンコーディングで大丈夫な局面に,個人的には遭遇した記憶は数回しかない。それも,個人的にちょこっとテスト用に書いたプログラムのときだけの話であり,何らかのシステムを構成するJavaプログラムを書いたときには,一度もデフォルトエンコーディングで良かった場面など遭遇していない。特に最近は,開発はWindowsで,本番稼働はLinuxで,といった形態がほとんどだ。「自分のところでは動いたんですけどねぇ」と平気で言うJavaプログラマが,現場では本当に多くなってしまった。はっきり言って,デフォルトエンコーディングはバグの温床でしかないのだ。 一番期待するのは,世間の大多数のJavaプログラマが,正しい認識を持ってプログラミングを行うことである。しかし,ソフトウェア的に文字コードについて指定を強制してもいいと思うので,いっそのことデフォルトエンコーディングが採用されるAPIは,廃止あるいは非推奨としてしまった方がいいのではないだろうか。最近ますますそう感じてならない。 あ, Javaってオープンソースになったんだっけ。デフォルトエンコーディングが採用されるAPIに片っ端から@deprecated指定を追記して,今後の案件に適用していけばいいのかな。。。

このエントリーをはてなブックマークに追加

関連記事

40%キーボードに慣れるためにやったこと

Lunakey PicoでQMK Firmwareを動かしてみました

Googleアシスタント向け会話型アクションが1年後にシャットダウンされます

Google I/O 2022でのGoogleアシスタント関連のセッション

Remap Organizations feature has been released