Curl® 言語でプログラミングを行う開発者は、ほとんどの場合アプレットを作成してインターネット ブラウザで提供することになります。作成するアプレットによっては、高度な API が要求されます。この章では、Curl ソース コードをさまざまなファイルに整理する方法について説明します。この章は次のセクションに分かれています。
- 「ファイルの種類」ではさまざまなファイルの種類の概要とその構造を示し、これらを編成してアプレットを作成する方法について説明します。
- 「アプレット」では、アプレット ファイルについて、そのソース コードを含めて説明します。
- 「独立型アプレット」では、独立型アプレットについて説明します。
- 「セキュリティ」では、Curl 言語についてセキュリティの面から説明します。
- 「パッケージ」では、パッケージとスーパーパッケージの構造について説明します。
- 「マニフェスト」では、マニフェスト ファイルを使って 1 つまたは複数の関連 Curl アプリケーションのリソースを管理する方法について説明します。
- 「 キャッシュと同期化」では、キャッシュおよび同期化がどのように各種の Curl コンテンツに影響するかについて説明しています。
- 「コンパイラ ディレクティブ」では、アプレットを効果的に実行するために compiler-directives を使ってコンパイラの動作を変更する方法について説明します。
Curl® 言語のソース コードを保存するファイルは、次のいずれかの種類に属すると考えることができます。
- アプレット ファイル。インターネット ブラウザに直接ロードして実行できます。
- パッケージ ファイル (load.scurl という名前がよく付けられます)。論理的に関連する API の Curl パッケージを定義します。API は通常パッケージ ファイルにインクルードします。
- マニフェスト ファイル。Curl パッケージと他のリソースのロケーションおよびメタデータを指定します。
- コード フラグメント ファイル。パッケージ ファイルまたはアプレット ファイルに include される予定のソース コードが含まれています。インクルード先のファイルの種類に適合するコードである限り、コード フラグメント ファイルには任意のソース コード (テキスト、クラス定義、クラス インスタンスなど) を含めることができます。
- スクリプト ファイル。
これらのファイルはそれぞれ 1 つのコンポーネントを表し、定義により、ソース コードに以下の項目を含めなければなりません。
- コードの先頭行で (コメントおよび空白行を除く) コンポーネント タイプを指定する Curl ヘラルド。
- Curl ヘラルド指定に一致するコンポーネント宣言 (オプションの場合もある)。
次のテーブルでは各種のファイルの種類をまとめています。
ファイルの種類 | アプレット | パッケージ | マニフェスト | スクリプト | コード フラグメント |
ファイル拡張子 | .curl/.dcurl | .scurl | .mcurl | .xcurl | .scurl |
ヘラルド | Y | Y | Y | Y | N |
コンポーネント宣言 | オプション | Y | オプション | オプション | N |
上記の種類に加えて、さらに 2 種類のファイルがあります。
- プリプロセス パッケージ ファイル (.pcurl)。 「プリプロセスされた Curl 言語ソースファイル」 を参照してください。
- プロジェクト ファイル (.cprj) は、Curl 言語プロジェクトに関連する多様なソース ファイルや他のリソースを管理する目的で Curl 統合開発環境が生成するファイルです。
アプレット、パッケージ、マニフェスト、スクリプト ファイルの一般的な構造は、ヘラルドで始まり、宣言が挿入され (必須またはオプションの場合があります)、その後に各ファイルの種類に固有の式が続きます。パッケージ ファイルを例にして、その部分的なコンテンツを次に示します。
|| curl herald specifying "package"
{curl 8.0 package}
|| component declaration specifying "package"
{package RELO.EQUIPMENT.BIG}
|| include implementation from other files
{include "GiantCarton.scurl"}
{include "UltraCarton.scurl"}
要約: | Curl ヘラルドでは :
- Curl ファイルの種類を指定します。
- 必要な 適切な API バージョン (複数可) を指定します。
- ファイルで最初に指定しなければならない式です。
|
ヘラルドには三つの目的があります。
- ファイル コンテンツの種類 (applet、package、manifest または script) を指定します。
この種類はコンポーネントとも呼ばれます。
- 必要な API バージョン (複数可) を指定します。
- Curl 言語およびコンテンツの種類に対応する、指定バージョンの標準パッケージ セットを暗黙的にインポートします。
ヘラルドを指定するには、先頭行で (コメントまたは空白行を除く)
curl 式を使用します。コード フラグメント ファイルではヘラルドの指定がないものもあります。
curl 式は次の構文になっています。
構文: | {curl api-version-list component-type}
|
|
api-version-list | ページを解析するのに使われる API バージョンのリスト。バージョン番号の区切りにはカンマを使用します。 ユーザーが Curl 実行環境 (RTE) でページをロードすると、インストールされている RTE が api-version-list のリストにある API バージョンの少なくとも 1 つをサポートしているかどうかが調べられます。インストレーションに互換性があればファイルはロードされ、なければエラーがスローされます。 |
component-type | Curl コンテンツの種類を表します。アプレットには applet、パッケージには package、スクリプトには script を指定します。 |
|
注意: Curl 実行環境のバージョン 1.2 は、Curl 言語の API バージョン 1.7 をサポートしています。同じマシンに Curl 実行環境の複数のバージョンをインストールして、複数の API バージョンをサポートすることができます。
以下のように API バージョン を指定することができます。
フォーマット 1: major-api-version.minor-api-version
フォーマット 2: major-api-version.minor-api-version.patch-number+
フォーマット 1 は、指定 API バージョンとそのバージョンのすべてのパッチ API バージョンを実行するアプレットであることを示します。たとえば、API バージョン 1.7 または 1.7.1 を使って実行するアプレットの場合、フォーマット 1 を使用します。フォーマット 2 は、指定したパッチ API バージョンとそれ以降のパッチ バージョンを実行するアプレットであることを示します。たとえば、API バージョン 1.7.1 以降 (つまり、API バージョン 1.8 を除く、そこまでのすべてのパッチ API バージョン) を使って実行するアプレットの場合、フォーマット 2 を使用します。
2 つの API バージョンの major-api-version と minor-api-version が同じでパッチ番号が異なる場合、高いパッチ番号の API バージョンは前のバージョンと下位互換性を持ちます。つまり、API バージョン 1.7.1 を使って実行するアプレットは、API バージョン 1.7.2 でも実行できることを意味します。
注意: パッチ レベルのない API バージョンはパッチ番号 0 で示します。したがって、次の指定は
下記と同じです。
ヘラルドでは、複数の API バージョン番号をカンマで区切って指定することができます。次に例を示します。
{curl 1.1.4+, 1.2, 1.3 applet}
当然のことですが、ディプロイメントの前にすべての指定 API バージョンを使ってアプレットをテストしてください。
コンポーネント宣言とはそれぞれのファイルの種類に固有の式で、各ファイルの種類に応じた役割を果たします。
applet、
package、
manifest および
script が各ファイルの種類に対応する宣言です。
詳細は、API ドキュメントと以下のセクションで各ファイルの種類の説明を参照してください。
要約: | - プリプロセスされた .curl ファイルには拡張子 .pcurl が付きます。
- ファイルをプリプロセスすると、パッケージのロード時間が短縮します。
- プリプロセスにより、送られるコードのサイズが縮小します。
- プリプロセスによりソース コードを隠すことができます。
|
Curl 言語を使ってアプレットを作成してそのアプレットとサポート ファイルを配布できるようにします。
Curl アプレットには拡張子 .curl が付き、アプレットのサポートファイルには .scurl が付きます。
これらのファイルは、ロード時に Curl RTE によって解析および評価されます。
配布前にファイルをプリプロセスすることで、パッケージのロード時間を短縮できます。
ファイルのプリプロセスでは、事前に処理タスクを実行し、
その結果を
.pcurl 拡張子の付く新しいファイルに保存します。
pcurl-file プロシージャを使ってソースファイルをプリプロセスすることができます。
IDE のディプロイメント処理でさらにプリプロセスするよう設定することもできます。
.pcurl 形式のパッケージのみが配布可能であることに注意してください。
アプレットを
.pcurl 形式で配布することはできません。
ファイルのプリプロセスの詳細に関しては 「
pcurl-file」 を、
を参照してください。
パッケージのプリプロセスには、コードを隠すという利点もあります。
.curl ファイルのコンテンツは通常のテキスト エディタで表示できます。
しかし、プリプロセスされたパッケージはそのエンコーディングにより、
プリプロセスされていない Curl アプレットやパッケージに比べて判読がきわめて難しくなります。
注意: .pcurl ファイルの作成時にデバッグ情報を含める場合は、人間が判読できるソースコードが結果として生じるファイルに含まれます。
バイト オーダー マーカーは、ファイルの初頭にある 2 バイトまたは 3 バイトのデータで、ファイルに使用されている文字エンコーディングを Curl RTE に認識させる役割を果たします。Curl RTE が認識可能なバイト マーカーは次のとおりです。
バイト マーカー | 文字エンコーディング |
0xFE 0xFF | ucs2-big-endian |
0xFF 0xFE | ucs2-little-endian |
0xEF 0xBB 0xBF | utf8 |
読み込まれたテキストの属性が設定された後、バイト マーカーはバックグラウンドで削除されます。このため、Curl ソース ファイルのコンパイル時と実行表示時にはバイト マーカーは表示されません。また、ファイルを読み込むアプレットにも、上の文字エンコーディングが含まれたファイルの場合は読み込み時にバイトは受信されません。上記のいずれかの文字エンコーディングでファイルを作成する場合は、Curl RTE によって自動的に適切なバイト マーカーが追加されます。
curl-file-attributes 宣言内で、
character-encoding を使って Curl RTE のファイル読み込み時に使用する文字エンコーディングを定義します。RTE が
curl-file-attributes 宣言を読み込むと、指定の文字エンコーディングを使ってファイルの残りのテキストがデコードされます。たとえば、次のコードは、
iso-latin-1 文字エンコーディングを使用してファイル内の Curl ソースを解釈するように指定しています。
{curl 8.0 applet}
{curl-file-attributes
character-encoding="iso-latin-1"
}
|| The rest of your file goes here.
ファイルは
curl-file-attributes 宣言までまず読み込まれることが必要なので、すでに読み込まれたコンテンツと矛盾する文字エンコーディングは指定できないことに注意してください。 たとえば、ソース ファイルに
ucs2-big-endian バイト マーカーがある場合、
curl-file-attributes を使って
utf8 文字エンコーディングに切り替えることはできません。なぜなら、読み込まれた部分のコンテンツは新しいエンコーディングと矛盾するからです。一方、
curl-file-attributes を使って Web サーバーで認識される
utf8 のファイルを
windows-latin-1 にエンコードすること(またはその逆) は可能です。
HTTP ヘッダーに適切に設定された
Content-Type charset パラメータがある Web サイトから提供されたソース ファイルでも、文字エンコーディング指定に
curl-file-attributes を有効に使用することができます。
curl-file-attributes を使って、開発中にローカル ディスクからファイルをロードする際に、文字エンコーディングを設定することもできます。Curl IDE も
curl-file-attributes を認識するため、この宣言を含めることで Curl IDE によるソース ファイル テキストの正しいエンコーディング処理が確保されます。
Copyright © 1998-2019 SCSK Corporation.
All rights reserved.
Curl, the Curl logo, Surge, and the Surge logo are trademarks of SCSK Corporation.
that are registered in the United States. Surge
Lab, the Surge Lab logo, and the Surge Lab Visual Layout Editor (VLE)
logo are trademarks of SCSK Corporation.