クライアント環境の違い？
こんにちは。
謎のトラブルに見舞われ、困り果てております・・
また、もし板違いなら、指摘してください。
VB6.0にてActiveXコントロールの開発を行い、
HTML埋め込み型『CODEBASE="XXXXXXX.ocx"』を作成しました。
また、表示用HTMLを用意して、どちらもWebサーバにアップロードしてあります。
日本からアクセスした場合、正常にActiveXのインストール及び実行が可能なのですが、
中国からアクセスした場合、ActiveXのインストールができないそうです。
(<Object>タグ内の<PARAM>タグ以外の部分が表示される。)
考えられる要因は、
・インターネットオプションのセキュリティ設定。
・ユーザ権限
・クライアントPCファイアーウォールとクライアント側サーバのファイアーウォール
の三点だと思うのですが、どれもこちらの提示した設定（インストール可能）だそうです。
また、ＯＳはWindowsXP or Windows2000、ブラウザはIE5.5 or IE6.0に限定しています。
他に、何か原因があるのでしょうか？？
VBに他国との互換性を設定する項目があるとか？？
日本語圏外だと実行不可能とか？？
「・・・だろう」「・・・かも」でも構いませんので、よろしくお願いします。
・各国語版固有のdll(*jp.dll,*fr.dll等)
・ロケールの違い
あたりも気になります。
ひろ様、回答ありがとうございます。
>・各国語版固有のdll(*jp.dll,*fr.dll等)
プログラムソース上で使用しているDLLは、
『USER32.dll』『kernel32.dll』『shdoclc.dll』＋VB6.0開発に最低限必要な物
です。
プロパティでは確かに、言語が日本語になっていました。
クライアント側DLLを日本語版に置き換える事で検証可能ですね。
>・ロケールの違い
これの検証は・・・。
日本のPCを中国に持っていって・・・は、検証できません。
仮に、どちらかが原因だとして、
回避方法はあるのでしょうか？
ちなみに、クライアントは不特定多数です。(中国だけとは限らない)
別ロケールでの実行を考慮するならば、codebaseには、
ocxを指定するのではなく、infファイル入りのcabファイルを
指定した方が良いのでは。
「インタ−ネットオプション」−「全般」−
「設定」−「オブジェクトの表示」で
ＯＣＸがダウンロードできているか確かめてみてください。
以前、CODEBASE="XXXXXXX.CAB"としてテストを行った時に、
PCによって実行されない場合がありました。
その原因は、CAB解凍DLLがWindows標準でないこと。
この時点でCAB形式での配布を断念したのですが、
他国での実行の場合、INFファイルも配布する必要があるのでしょうか？
>ＯＣＸがダウンロードできているか確かめてみてください。
以前、中国側のクライアントに、
『Downloaded Program Files』及び『Temporary Internet Files』
を確認するよう求めたのですが、忙しいらしく、未だ返答がない状態です。
今は、原因となる可能性、検証方法、対処方法を検討しています。
他にも、気になる（確認したい）部分がありましたら、お願いします。
>> 中国からアクセスした場合、ActiveXのインストールができないそうです。
過去の失敗談から。
1. キャッシュ用のディスクの空きが少なかった。
2. PCの時刻がずれていて、インストール時の認証に失敗していた。
3. Domain Usersとしてログインしていて、ローカルPCへの権限が低かった。
4. ダウンロード失敗したバイナリがキャッシュに残っていて、阻害されていた。
>> (<Object>タグ内の<PARAM>タグ以外の部分が表示される。)
文字コードの判定に失敗すると、稀にタグの中身が丸見えになる事がありますね。
1. Content-Type で、charsetを指定しているか?
2. HTTP応答のContent-Typeと、metaタグのcharset、そして
実際の文字コードとの間に、食い違いは無いか?
3. クライアント環境は、その文字コードをサポートしているか?
>> 他に、何か原因があるのでしょうか？？
Webサーバのアクセスログは確認されてます?
中国からアクセスされた時に、そのファイルへのGET要求が
来ているのかどうかを見ておいた方が良いと思います。
> その原因は、CAB解凍DLLがWindows標準でないこと。
え??
中文版のWindowsではどうだか知りませんが、日本語版の場合、
IE4等のインストーラでさえ、cabファイルが使われていますよね…?
CAB解凍DLLというのが CABINET.DLL の事なら、IE5.0にも付属している
ファイルなので、普通はインストール済みかと思っていたんですけど、
中文版のWindowsでは、事情が異なるのでしょうか。(無知ですみません)
>他国での実行の場合、INFファイルも配布する必要があるのでしょうか？
inf入りcabにすれば、バージョン管理やロケーション別のインストールにも
対応できますし、言語固有のライブラリが必要になった場合でも、
CABDefaultURLキーでのオンデマンドインストールができるという理由で、
自分は cab を使う事が多いです。が、ただそれだけ。必須かと言われれば否です。
なので嫌なら、inf付き cab 以外の方法もありますけど(msiとか)、少なくとも、
不特定多数を相手にするなら、VB6ランタイム(のサテライトファイル)の
インストールチェックが必要なので、ocx単体ではなく、パッケージで
配布した方が安全かなーという気はします。
>>・ロケールの違い
>これの検証は・・・。
>日本のPCを中国に持っていって・・・は、検証できません。
中国で日本語版の検証をするのではなく、その逆の検証はどうですかね。
たとえば、MSDN Subscriber Download から、Microsoft VirtualPC と
中文版Windowsをダウンロードしてきて、それを使って検証するとか。
>他にも、気になる（確認したい）部分がありましたら、お願いします。
1. ocxへの電子署名の有無。(使っている場合はcabの署名も)
2. Webから自動インストールさせるのではなく、インストーラを使って
組み込んだ場合に動作するかどうか。
Dental様、沢山の懸案ありがとうございます。
>1. キャッシュ用のディスクの空きが少なかった。
中国側への調査依頼の案件に追加します。
>2. PCの時刻がずれていて、インストール時の認証に失敗していた。
中国側への調査依頼の案件に追加します。
>3. Domain Usersとしてログインしていて、ローカルPCへの権限が低かった。
Administrator権限でアクセスしているので、大丈夫だと思います。
>4. ダウンロード失敗したバイナリがキャッシュに残っていて、阻害されていた。
中国側への調査依頼の案件に追加します。
>文字コードの判定に失敗すると、稀にタグの中身が丸見えになる事がありますね。
言葉下手で申し訳ありません。
ソースが見えるのではなく、
<OBJECT><PARAM>〜〜</OBJECT>の”〜〜”がHTML解釈されて表示されます。
（<OBJECT><PARAM><IMG></OBJECT>ならば画像が表示される）
>Webサーバのアクセスログは確認されてます?
サーバ管理者への調査依頼の案件に追加します。
>> その原因は、CAB解凍DLLがWindows標準でないこと。
>え??
日本のWindows2000のPCを倉庫出荷状態に戻してテストを行ったところ、
インストールできなく、「cabinet.dll」がローカルに存在しなかったので、
標準DLLではないと判断したのですが、
むしろこれがレアケースだったのでしょうか？
>自分は cab を使う事が多いです。が、ただそれだけ。必須かと言われれば否です。
CAB解凍DLLがWindows標準ならば、CAB形式で配布でもOKです。
それでロケール問題が解決するなら、そちらの方が確実ですしね。
>たとえば、MSDN Subscriber Download から、Microsoft VirtualPC と
>中文版Windowsをダウンロードしてきて、それを使って検証するとか。
知らない単語がいっぱい出てきたので、少し調べてみようと思います^^;
>1. ocxへの電子署名の有無。(使っている場合はcabの署名も)
署名はしていません。
が、インターネットセキュリティは未署名もOKにしてもらっています。
>2. Webから自動インストールさせるのではなく、インストーラを使って
組み込んだ場合に動作するかどうか。
中国への調査依頼の案件に追加します。
だんだん、ロケールが原因で、INFがあればOKな気がしてきました。。
調査依頼の第一陣にそのテストをお願いしようかな・・
CABファイルを作ってから、
cabinet.dllの有無を確認してもらってアクセス！
バシッと起動しそうな気がします。
> ソースが見えるのではなく、
> <OBJECT><PARAM>〜〜</OBJECT>の”〜〜”がHTML解釈されて表示されます。
> （<OBJECT><PARAM><IMG></OBJECT>ならば画像が表示される）
多分ですけど、指定したclsidのオブジェクトがロードできず、
codebaseからのダウンロードも失敗してる状態じゃないですかね。それ。
HTMLの仕様的には、objectタグを解釈できない場合、その中に
書かれた記述がそのまま処理される事になっているので、
objectの内容次第では、<IMG>が処理される事もあるかと。
===================
<p>ただの画像
<img src="http://www.google.co.jp/images/logo_sm.gif" alt="a"
width=150 height=55 alt="Google" border="0">
</p>
<p>
存在するclsid (Windows Media Player)
<object classid="clsid:22D6F312-B0F6-11D0-94AB-0080C74C7E95"
style="width:200px; height:200px; border:1px solid red">
<img src="http://www.google.co.jp/images/logo_sm.gif" alt="b"
width=150 height=55 alt="Google" border="0">
</object>
</p>
<p>
存在しないclsid
<object classid="clsid:00000000-0000-0000-0000-000000000000"
style="width:200px; height:200px; border:1px solid red">
<img src="http://www.google.co.jp/images/logo_sm.gif" alt="c"
width=150 height=55 alt="Google" border="0">
</object>
</p>
===================
> 日本のWindows2000のPCを倉庫出荷状態に戻してテストを行ったところ、
> 「cabinet.dll」がローカルに存在しなかったので、
DLLを非表示に設定していたわけでは無いのですよね?
> 標準DLLではないと判断したのですが、
> むしろこれがレアケースだったのでしょうか？
近くにあるWin2000機は、いずれもシステムフォルダにcabinet.dllがありました。
素のWin2000についてはわかりません。
ただ、Win2000 のインストールディスクを見ると、I386フォルダに
更新日=1999/12/17 21:00:00 ver=5.0.2147.1 の物があるようです。
WinXPにも含まれるようで。
http://support.microsoft.com/dllhelp/
> だんだん、ロケールが原因で、INFがあればOKな気がしてきました。。
infって、要するにインストーラ情報に過ぎないので、とりあえず、
Visual Studio Installer か ディストリビューションウィザードで
ocxのインストーラを作ってしまい、それをインストールしておいてみては?
今のままだと、「ocxがインストールできない」状態なのか、
「インストールはできたけど、htmlにロードされない」のかさえ不明ですし。
ＯＣＸのダウンロードインストールログが
みれるツールがＭＳから提供されてるから
それ使えばいいよ
それ以上は協力的じゃないから
教える気になれない・・
あん様，Dental様 ありがとうございます。
忙しくてレスが遅くなって申し訳ありませんでした。。
>協力的じゃないから教える気になれない・・
実は、Webサーバは、お客様の会社の管理部署の所有の為、
容易に手が出せない現状です。
また、海外からテストアクセスをする人は、お客様のお客さんで、
これも容易に手が出せません。
すべてお客様経由で、調査懸案を基に作業をする(させる)事になります。
そういう理由で、積極的になれない面がありまして、
非協力的な文面になってしまったのかもしれませんね・・^^;
今までのレスから言える事は、どこまで正常に行われているのか。ですね。
１．サーバへアクセス(ActiveXダウンロード要求)
２．クライアントにダウンロード
３．インストール
４．HTMLにロード
先輩のツテを得まして、海外にいる人(韓国)から、テスト接続をしてもらえる事になりそうです。
内々のテストなので、本番用Webサーバは使えない為、フリーのWebサーバを用います。
結果、本番と少し環境が変わってしまいますが、ある程度特定できるでしょう。
不具合の場所が特定され次第、また質問する事もあるかもしれませんが、
よろしくお願いします。
| ツイート |  |