「Curlの動作・振る舞いについて」カテゴリーアーカイブ

Curlの仕様に関して、過去にお問い合わせの多かった事例を紹介いたします。記載日時点での状況(最新or問い合わせ時指定バージョンにおける仕様)を元に回答したものです。
 

マルチランゲージについて

【ご質問】
複数言語の文字が混在する文字列の表示のために  font-familyに複数のフォントを指定し、
文字によって使用されるフォントを切り替えることは可能でしょうか?

例えば、font-familyに
 MS ゴシック,
 NSimSun(中国語フォント),
 GungsuhChe(韓国語フォント)
とした場合はどのような挙動をしますでしょうか?

【回答】
font-familyに複数のフォントを指定することはできますが、これはシステム(OS)に
該当フォントがインストールされていない場合における振る舞いを想定したものであり、
マルチランゲージを表示するためではございません。

font-familyの指定に対して、Curl実行環境は、システムで使用可能なフォント書体が
見つかるまでフォントリストを検索します。
最初に見つかったシステムで使用できるフォントが複数言語が混在する文字列に対しても使用されます。

複数言語が混在する文字列を正しく表示できないことがありえますが
文字種によってはCurl実行環境が代替のフォントで表示する場合があります。
この代替フォントはfont-familyの記述によらないもので、
韓国語以外のフォントを第一番目に指定した場合に
ハングルがいつも同じフォントで表示されるのはこのためです。

上記例ですと、
 ・MS ゴシックがシステムで使用可能(基本的にWindows環境であればこのフォントは
  通常インストールされています)ですので、このフォントが使用されます。
 ・中国語:MS ゴシックは中国語を完全に表示できるフォントではありませんので
  読める形で表示されるとは限りません。
 ・韓国語:MS ゴシックは韓国語が表示できませんが、  font-familyによらない
  代替フォントが使用されて表示されます。

Curlに限った話ではありませんが、これらを解決するために、マルチランゲージを表示するために、
世間では、ユニバーサルフォント「Arial Unicode MS」のようなフォントが用意されているようです。

 

choose-fileプロシージャとCurlのDialogの挙動の違いについて

【ご質問】
別々のViewからchoose-fileプロシージャとDialogにてダイアログ表示を行っています。

choose-fileプロシージャで選択を行った場合、
片方のDialogが閉じられるまでモーダル状態になります。

しかし、別々のViewからモーダルのDialogを表示させた場合は、
上記動作とは違い、片方のウィンドウが閉じられてもそのウインドウを表示した
Viewは操作出来ます(モーダル状態になっていません)。

なぜこのような違いが生じるのでしょうか。

【回答】
choose-fileプロシージャとCurlのDialogの挙動の違いについてですが、
choose-fileプロシージャは”WindowsAPI”の機能を使い、
“Winodws”のファイル選択ダイアログを表示して値を取得しています。

つまり、
choose-fileプロシージャで表示されているファイル選択ダイアログは
Curlが生成して表示しているのではなくWindowsが表示しております。

このためCurlのモーダルの考え方(実装の仕方)とWindowsのファイル選択ダイアログ
の考え方の違いが今回の現象を発生させています。

EmbeddedBrowserGraphicのHTTPリクエストについて

◆ご質問◆
EmbeddedBrowserGraphic内のHTMLコンテンツから発信されたHTTPリクエストについて
 ①事前にCurlで実装された通信により付与されたCookieは、当該リクエストにも付与されますか?
 ②Curlの実装から、当該リクエスト内容を参照可能でしょうか?
 ③Curlの実装から、当該リクエストに対するレスポンス内容を参照可能でしょうか?
 ④Curlの実装から、当該リクエストに対するレスポンスに付与されたCookieの参照・操作が可能でしょうか?

◆回答◆
EmbeddedBrowserGraphicの内部的には、
ActiveXを使用しCurl内部にブラウザを埋め込んで
表示するという実装となっています。
ですので、CurlのプロセスとEmbeddedBrowserGraphicを
利用して表示しているブラウザのプロセスは全くの別物となります。

①C/S間に、中間サーバを介すということですので
 そのサーバのアドレスは別ドメインとなっているということでしょうか。
 その場合、Curlに付与されたクッキーはEmbeddedBrowserGraphic内で
 表示されているHTMLでは読み取ることができません。
 また、CurlからクッキーをHTMLに付与するAPIもございません。
 勿論、EmbeddedBrowserGraphicを使用しているからといって自動的にCurlのクッキーを
 EmbeddedBrowserGraphic内で表示されているHTMLに付与することはありません。
②残念ながら不可能です。
③残念ながら不可能です。
④残念ながら不可能です。

“curl-access.txt”にアクセスできない

◆ご質問◆
一度、不正な curl-access.txtを受信した場合は二度とそのcurl-access.txtにはアクセスをしないのでしょうか?
再度 curl-access.txtにアクセスさせる方法は、あるのでしょうか?

◆回答◆
ブラウザのキャッシュに不正なcurl-access.txtが保存されてしまい、
ブラウザキャッシュから読み込まれてしまうという可能性は考えられます。

再度、アクセスをする場合はブラウザのキャッシュを削除することで行えます。

“curl-access.txt”の有効期限について

◆ご質問◆
curl-access.txtには有効期限のようなものが存在するのでしょうか?

◆回答◆
有効期限の指定はできません。

curl-access.txtの詳細については
 「Curl開発者ガイド」→「Webサーバの構成」→
 「アプレットがWebサイトのファイルへアクセスする許可」の項を
ご参照ください。

キャッシュの最終更新日付がサーバ上の更新日付より新しい場合の同期について

◆ご質問◆
キャッシュの最終更新日付がWebサーバー上の
更新日より新しい場合は再同期はされるのでしょうか?

◆回答◆
クライアントPCにキャッシュされているファイルの最終更新日付が
webサーバー上のファイルの最終更新日付より新しい場合は、再同期は行われません。

基本的に、クライアントPCにキャッシュされているファイルの最終更新日付は
同期元となるwebサーバー上のファイルの最終更新日付より
古い日付もしくは同じ日付であるという前提があるため、
クライアントPCにキャッシュされているファイルが
webサーバーのファイルの最終更新日付より新しい最終更新日付となる場合は
再同期が行われないように実装されております。

pacファイルを使用してのプロキシ設定について

【ご質問】
InternetExplorerの「インターネットオプション」にてプロキシ設定を行い、
プロキシーサーバを介して接続を行っている端末があるのですが、この端末から

 1.ネットワーク上に存在する独立型アプレットにcurl://launch/~を使用してアクセスする場合
 2.独立型アプレット内で別のネットワークに対して、通信処理を実施する場合

のどちらについてもプロキシ設定が有効になっておらず、直接アクセスを行ってしまいます。
独立型アプレットにてプロキシ設定を有効にするにはどのようにすればよいのでしょうか?

※pacファイルを利用して自動的にプロキシサーバの設定をしています。

【回答】
IEでプロキシの設定を行った場合、その設定された値はレジストリに保存されます。
しかし、pacファイルで動的に指定される場合は、
レジストリにプロキシサーバのアドレスが保存されません。
(pacファイルのパスは保存されています。)

Curlは通信時にこのレジストリの値を参照しますので、
何らかの理由で読み取れていない可能性があります。

プロキシサーバの指定をpacファイル等で動的に指定するのではなく、
プロキシサーバのアドレスを直接指定して
(設定の自動検出、自動構成スクリプトの使用をやめ
「LANにプロキシサーバを使用する」にチェックをいれて指定する)
確認を行ってください。

Active Directory環境下でのセキュリティ引き継ぎについて

◆ご質問◆
Active Directory環境にて、ユーザが一度RTEインストールしたら、
他のPCに移動しても、CURLのセキュリティは引き継がれることは可能でしょうか?

◆回答◆
ユーザのプロファイルをローカルにもつローカルプロファイルにするのではなく、
ファイルサーバなどのネットワーク上に保存する移動プロファイルを使用することで
Curlのセキュリティ設定(特権ディレクトリやホストの設定)を別のPCでも共有することは可能です。

ブラウザからCurlへのCookieの引き継ぎについて

2022年6月15日にIEがサポート終了の予定です。ブラウザ内で実行するアプレットはEdgeのIEモードサポート終了に伴い、利用できなくなります。そのため、まだブラウザ内で実行する.curlアプレットをご利用中の場合、早めに独立型アプレットへ移行することをお勧めします。

【ご質問】
ブラウザが持っているCookieの内容は、Curl側のCookieには引き継がれるのでしょうか。

【回答】
通常セッションクッキーは、ブラウザのCookieを引き継がず、Curl独自でCookieを持つことになります。
ただし、Internet Explorer(※)に限って、有効期限を持ったCookie(つまりファイル保存されたCookie)の場合と
request-browser-resident-httpプロシージャを利用した場合はブラウザのCookieを引き継ぐことが可能です。

詳細は、Curl開発者ガイドの
[外部リソースとの対話]-[Web サイトとの対話]-[ブラウザ常駐 HTTP]
の項をご参照ください。 

クッキー情報の引継ぎについて、次のページもご参照ください。

Cookieを引き継ぐ方法

Curlが行っているHTTP通信プロセスについて

【ご質問】
ブラウザが行っているHTTP通信と
Curlアプレットが行っているHTTP通信のプロセスは
別のものとなるのでしょうか。

【回答】
基本的には、ブラウザが行っているHTTP通信と
Curlアプレットが行っているHTTP通信のプロセスは別になります。

ブラウザはiexplore.exeプロセスが持つWinInetで通信を行い、
Curlではsurge.exeプロセスが持つWinInetで通信を行います。

ただし、request-browser-resident-httpを使用している場合には
Curlもiexplore.exeプロセスが持つWinInetで通信を行います。

詳細は、APIリファレンスの
[CURL.IO.HTTP]-[request-browser-resident-http]
の項をご参照ください。

includeとdelegate-toの違いについて

【ご質問】
include と delegate-to の違いについて教えてください。

【回答】
includeとは、
include文を書いた箇所に指定したファイルの
内容をそのまま”挿入(貼り付け)”するイメージになります。

delegate-toとは、
外部のパッケージを利用するためにそのリソースを管理しているマニフェストファイルへの”参照”を行います。
このように”参照”のかたちをとることで外部パッケージの独立性を高めることができます。

includeの詳細については、Curl開発者ガイドの
[コンテンツの構成要素]-[アプレット]-[アプレットファイルのソースコード]
の項をご参照ください。 

また、delegate-toの詳細については、Curl開発者ガイドの
[コンテンツの構成要素]-[マニフェスト]-[マニフェストファイルの構造]-[マニフェストのデリゲート(委譲)]
の項をご参照ください。

全てのアプレットの再同期を強制する

◆ご質問◆
resync-as-ofを設定している状況でもCurlの全般オプションタブの強制再同期設定を
「全てのアプレットの再同期を強制する」に設定しているとresync-as-ofが無視されて
毎回同期されるのでしょうか?

◆回答◆
ご推察の通り、「全てのアプレットの再同期を強制する」に設定した場合、
resync-as-ofの設定によらず毎回同期される事になります。

resync-as-ofの記述するファイルについて

◆ご質問◆
resync-as-ofの推奨される設定はstart.dcurlへ記述するとされていますが、
ライブラリ類などの場合はmanifest.mcurlへ記述することは問題ないでしょうか?
また、その場合Webサーバーへのコンテンツ有効期限の設定は必要ないでしょうか?

◆回答◆
resync-as-ofの設定はstart.dcurlのみにして頂く事を推奨致しております。
ライブラリやmanifest.mcurlファイルについてもstart.dcurlの設定が反映されますので、
これらにresync-as-ofの設定は必要ありません。

また、Webサーバのコンテンツの有効期限も同様にstart.dcurlファイルのみ
(ライブラリやmanifest.mcurlの有効期限の設定は必要ありません)に
設定することを推奨致しております。

複数バージョンのアプリ起動時におけるRTEのプロセスについて

【ご質問】
Curlはバージョンアッドとありますが、CurlRTEのプロセスは複数バージョンの
アプリケーションを起動してもRTEのプロセスは1つなのでしょうか?
それとも複数起動されるのでしょうか?

【回答】
バージョンの違うCurlアプレットが起動する場合の動作について説明します。
メインのバージョンのアプレットが動く場合はsurge.exeで処理されます。
それ以外のバージョンのアプレットが動き出すと、curl-eng.exeが起動し処理されます。

例えば、バージョン4、5、6のRTEがインストールされている場合、
6のアプレットが動くとsurge.exeで処理され、
5のアプレットが動くとcurl-eng.exeで処理されます。
また、この状態で4のアプレットが起動すると、
5で使用されているcurl-eng.exeとは別のcurl-eng.exeが使われます。

このときsurge.exe、curl-eng.exeが2つ起動していることになります。 

以下のFAQもご参照ください。
http://developers.curlap.com/faq/49-faq-operation/343-curl.html

入力文字が正しく表示されない

◆ご質問◆
Curlで生成したTextFieldに、特定のUTF-8で表現できる文字を入力(貼り付け)したいのですが、
入力すると”・・”のような文字に変わってしまいます。
そもそもCurlで、そのような言語の入力、表示は可能でしょうか?(TextFieldに限らず全般的に)

◆回答◆
まずその言語に対応しているフォントの種類をfont-familyに指定することが必要になりますが、
対応しているフォントを指定しても 誠に残念ながら言語の種類によって正しく入力/表示ができません。

特に南アジア言語(インド、スリランカ、ネパールなど)やヘブライ語、アラビア語、
右から左へ記述する言語は正しく表示がされない可能性が高く、サポートも行っておりません。

Curlが正式サポートしている言語は日本語と英語のみになります。

強制的に全てのCookieを削除することは可能か?

◆ご質問◆
強制的に全てのCurl RTEのメモリ上のCookieをクリアする方法はありますか?

◆回答◆
surgeプロセスが保持しているcookieを全て強制的にクリアする方法は残念ながらございません。
Curlアプリが複数起動していた場合に、surgeプロセスが保持しているcookieを全て削除してしまうと、
他の全てのアプリが保持しているcookieも削除してしまいます。
これにより他のアプリが正常に動作しなくなる可能性があるため実現は不可能となります。

DateTimeにおけるタイムゾーンの仕様など

◆ご質問◆
 DateTimeについてCurlドキュメントを拝見したのですが、
 記載されている仕様について、
 以下、いろいろ書きますが認識に誤りなどありましたら
 ご指摘ください。
 ①ローカルタイムゾーンにおける制約について
  DateTimeのzoneを指定しない場合、
  ローカルタイムゾーンがデフォルトとなるようですが、
  この時、日付範囲の制約が発生する仕様になっているようです。
  ※1970-01-01 00:00:00.000000 +0000 から
   2038-01-19 03:14:07.000000 +0000
  ローカルタイムゾーン以外に設定すると、
  この制約が無くなることは確認しました。
  Curlでは無限の範囲と制度で日付と時刻を表すことができるにも
  関わらず、こういった制限があるのはなぜでしょうか。

 ②ゾーン指定をすることによる影響について
  上記①のことから、
  zoneを指定して回避しようと考えました。
  この時、ゾーンに「UTC」を設定するとすると、
  日本時間を扱っている上では、正しい時間とはならないので、
  日付を表す文字列に「+0900」を追加するか等も考えています。
  このゾーンについて、UTCまたはその他のゾーンが設定されていると、
  ローカルタイムゾーンと比べて、
  DateTime周辺のAPIの結果に大きな違いが出るのでしょうか。
  例えば、
   DateTimeのコンストラクタに日付とUTCでゾーン設定した時、
   その後のAPIで日付取得した時に自動的に日本時間(+9時間)として
   取得されるなどあるとUTCは使えないと判断します。

 ③まとめ
  上記①②を踏まえ、
  Curlでシステム開発をする際、
  DateTimeは通常どのように扱ってらっしゃるのでしょうか。
  <1> 1970年~2038年の範囲を超えた日付を扱ったことが無いので
      ローカルタイムゾーンのまま。
  <2> システム導入先の国に合わせてタイムゾーンを指定。
  <3> UTCで決め打ち。
      いずれかになるかと思うのですが。

◆回答◆
①について
Curlは時刻を内部的に「UNIX時間」として扱っています。
また、その値を32ビットで扱っており、その最大値が2147483647となります。
(これが2038年1月19日3時14分7秒となります。)
この値を超えるとオーバーフローし誤作動する可能性があります。
このようなことから制約があります。

②について
{DateTime
    year   = 2009,
    month  = 6,
    day    = 3,
    hour   = 14,
    minute = 8,
    second = 14,
    zone = {DateTimeZone mode = DateTimeZoneMode.utc, utc-offset-minutes = 540} }
としてDateTimeを設定すれば
2009-06-03 14:08:14.000000 +0900
として取得できます。

③について
アプリケーションの用途によって扱い方が
変わるかと思います。
例えば、
<1>ならばタイムゾーンが一つであるような国で完結するようなシステム。
(日本国内のみで使用される)
<2>なら韓国で国内で使用されるようなシステム。
<3>複数のタイムゾーンの国で使用され、その使用国間でコミュニケーションするようなシステム。
(日本、米国、中国で使用される)

encode-charactersプロシージャ

【ご質問】
encode-characters プロシージャの
内部で扱っている Shift-JIS とはどの範囲でしょうか。

【回答】
Microsoftコードページ932で規定された
文字コードをサポートしています。

詳細は、APIリファレンスの
[CURL.LANGUAGE.STRINGS]-[CharEncoding]
の項をご参照ください。 

外部ライブラリ呼び出しに使うC構造体

【ご質問】
Curlの外部ライブラリ呼び出しですが、使用するC構造体のなかに固定長配列が
ある場合でも使えるのでしょうか?

Curlのdefine-C-structで作る場合、固定長配列である
AdapterNameなどはどのように書けばよいのでしょう?

【回答】
残念ながら、今回のように固定長配列に対応するCurlの構文はございません。
ですが、メモリ内の値を読み取ることで値を取得することは可能です。

例えば、以下のようなCの構造体がありこれをDLLを介して読み取るとします。

typedef struct foo {
  char *name;
  int age;
  char *date[3];
} Foo;

これに対応するCurlの定義は以下のようになります。 

{define-C-struct public FooStruct
    {defaults
        calling-convention = stdcall,
        string-rep = CString }
    field public name :String
    field public age  :int
    {getter public  {date}:{CArray-of char8}
        {return {unsafe-memory-get {CArray-of char8}, self._raw + 8}}
    }
}

dateゲッターの中でunsafe-memory-getマクロを使用し、メモリから直接読み取ります。
ここで指定するアドレスですが、+8としているのはこの構造体の
先頭のポインタからのオフセットとなります。
なお、1オフセットは4バイトとなりますのでご注意ください。

choose-file プロシージャと Dialog について

【ご質問】
choose-file プロシージャと Dialog について
別々の View から choose-file プロシージャの実行と
Dialog の起動を行っている場合に choose-file プロシージャが
Dialog が終了するまで結果を返却しない場合があります。
別々の View から実行している場合でも choose-file プロシージャは
Dialog の終了を待つのが仕様なのでしょうか?

【回答】
仕様となります。

モーダルの管理は一つのアプレットに対し一箇所で管理されています。
つまり、2つのViewを表示した場合、モーダル時に
止められる処理は、それぞれのViewで管理されるのではなく、
一箇所で一緒に管理されることになります。

”モーダル” Dialogの目的は、ユーザーの応答を得ることですので、
応答が得られるまでは処理が停止します。
このことを踏まえると、一つのアプリケーション上で
同時に二つ以上のモーダルDialogが表示されるのは好ましくありません。

これを回避するには以下が考えられます。
①View1とView2を別アプレットにする
 別アプレットにすることで、それぞれ別々に管理されることになります。
②Dialogをモーダルにしない
 呼び出し元の画面を触れないようにしなければならないといった場合は、
 呼び出し元画面の工夫をしていただく必要があります。