二度目の投稿です。
森山様が丁寧にもレス下さったにもかかわらず、
忙しさにかまけて返答を怠った馬鹿ものです。
せめてもの罪滅ぼしに、Javaコンポーネント開発中に、
起こった障害を、報告いたします。
せめてもの参考になれば幸いです。
Javaですので文字のエンコードについて、あまり意図はせず、
送られてきた文字コードを、UTF-8に変換するロジックを、
そのまま使用しており、出力時に適宜書き換えて使用しています。
今回、特定のパターンではありますが、
以下のように障害が発生いたしました。
JDK1.3*では、問題が発生しないロジックが、
JDK1.4*では、Stringのコンストラクタを生成する時点で、
java.lang.IllegalArgumentExceptionをThrowしてしまう
事象がLinuxでのみ発生いたしました。
Linuxのディストリビューションは、
RedHatAS2.1
MiracleAPserver2.1
SuSEKernel2.4*
TourboLinux8(Kernel2.6*)
VineLinuxなどほぼすべてのディストリビューションで確認いたしました。
読み込む文字は、JIS系の文字で￥'(0x5c) が含まれていると、
エスケープシーケンスと誤認されているようなものでした。
(EUC→UTF-8では発生しない障害でした。)
コンポーネント内で、システムプロパティからLOCALEを
取得している関係上、LOCALE=JP,eucJPを、eucjpと
小文字にして回避を行いましたが・・・glibc内の実装が怪しい気がします。
このときglibcのバージョンは、RedHatにおいてRHNで
最新のパッチを当てた状態ですので、
いまだ報告されていない問題なのかな？
といった感じです。
もう少し追ってみますので、後ほど報告差し上げます。
森山様・・・本当に・・・本当に申し訳ございませんでした。
| No.121 | 投稿日時: | 2003/11/05(水) 21:13 <↑親記事:No.119> |
| 投稿者: | 森山 将之 |
glibc の sjis/euc-jp/iso-2022-jp は問題がある事は認識していますが、信頼できる公的なマッピングテーブルが存在しないので手を出しづらい状況です。
| No.123 | 投稿日時: | 2003/11/08(土) 17:01 <↑親記事:No.121> |
| 投稿者: | 小林 裕幸 <E-Mail> |
なかなか忙しくて返信ができなくて申し訳ございません。
おまけに質問のタイトルが意味の無いものになってしまいました。
重ね重ねまことに申し訳ございません。
> glibc の sjis/euc-jp/iso-2022-jp は問題がある事は認識していますが、信頼できる公的なマッピングテーブルが存在しないので手を出しづらい状況です。
これ以上追っていくパワーが無いので、
glibc+JDKの問題と判断しています。
(glibcの中ではコードポイントは違えど同様の問題があるようですね。)
ただし・・・この時JDKを1.3台にすると問題は発生しません。
こちらのコンポーネント内でも、LOCALE変数を使用し、
依存した実装があるのですが、その部分以前では
JDKの実装の違いに焦点を当てるしかなさそうです。
（聞いたところによると、jdk1.2+1.4と、jdk1.3で
実装のアーキテクチャが変わっているそうです。）
結局、コンポーネント側で、LOCALEを判断する実装に変更しました。
eucjpと、eucJPで現象が変わり、eucjpの方が望ましく、
ほぼすべてのディストリビューションで初期設定、
eucJPとなっていることを考えると、リファレンス実装のほうに、
初期設定の問題があるのかな・・・というところです。
glibcの根本的な問題とは捉えていません。
（しょ〜もない問題かも・・・）
たいした回答でなくて申し訳ございませんが、
いったんこれを報告といたします。
今は、COM用DLLを、.NETで動かすとスレッドの廃棄された時点で、
ExitProcesを吐く…件を調査中です。
COMdllの中でAPLタイプでスレッドを実装していたのですが、
.NETのCOMオブジェクトは以前のものとは
スレッドに関して互換性が無いそうです。(MSプレミアムサポートより)
ここのようにレベルの高い掲示板ですと、
ひとつ情報になりますかね・・・。
以上報告でした。