コンテンツの構成要素

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 式は次の構文になっています。

注意: 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 で示します。したがって、次の指定は

{curl 1.0 applet}

下記と同じです。

{curl 1.0.0+ applet}

ヘラルドでの複数の API バージョン番号の指定

ヘラルドでは、複数の API バージョン番号をカンマで区切って指定することができます。次に例を示します。

{curl 1.1.4+, 1.2, 1.3 applet}

当然のことですが、ディプロイメントの前にすべての指定 API バージョンを使ってアプレットをテストしてください。

コンポーネント宣言

コンポーネント宣言とはそれぞれのファイルの種類に固有の式で、各ファイルの種類に応じた役割を果たします。applet、package、manifest および script が各ファイルの種類に対応する宣言です。詳細は、API ドキュメントと以下のセクションで各ファイルの種類の説明を参照してください。

プリプロセスされた Curl 言語ソースファイル

Curl 言語を使ってアプレットを作成してそのアプレットとサポートファイルを配布できるようにします。 Curl アプレットには拡張子 .curl が付き、アプレットのサポートファイルには .scurl が付きます。これらのファイルは、ロード時に Curl RTE によって解析および評価されます。

配布前にファイルをプリプロセスすることで、パッケージのロード時間を短縮できます。ファイルのプリプロセスでは、事前に処理タスクを実行し、その結果を .pcurl 拡張子の付く新しいファイルに保存します。 pcurl-file プロシージャを使ってソースファイルをプリプロセスすることができます。 IDE のディプロイメント処理でさらにプリプロセスするよう設定することもできます。

.pcurl 形式のパッケージのみが配布可能であることに注意してください。アプレットを .pcurl 形式で配布することはできません。ファイルのプリプロセスの詳細に関しては「pcurl-file」を、を参照してください。

パッケージのプリプロセスには、コードを隠すという利点もあります。 .curl ファイルのコンテンツは通常のテキストエディタで表示できます。しかし、プリプロセスされたパッケージはそのエンコーディングにより、プリプロセスされていない Curl アプレットやパッケージに比べて判読がきわめて難しくなります。

注意: .pcurl ファイルの作成時にデバッグ情報を含める場合は、人間が判読できるソースコードが結果として生じるファイルに含まれます。

文字エンコーディング

ファイルの文字エンコーディングは、バイトオーダーマーカーまたは Curl 言語の curl-file-attributes 宣言を使用して指定します。

バイトオーダーマーカー

バイトオーダーマーカーは、ファイルの初頭にある 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

Curl 言語ソースファイルでは、curl-file-attributes 宣言を使って文字エンコーディングを指定します。この宣言で、文字エンコーディングを含むファイルのいくつかの属性を定義します。ファイル内で、ファイルのヘラルド (使用の場合) の後、その他の式の前に curl-file-attributes を指定します。これは、既定のテキストエンコーディングと互換性のない文字を含む、すべてのトップレベルのテキストの前にも必ず指定する必要があります。curl-file-attributes はすべてのアプレット、インクルードファイル、ソースパッケージ内で使用できます。

curl-file-attributes 宣言内で、character-encoding を使って Curl RTE のファイル読み込み時に使用する文字エンコーディングを定義します。RTE が curl-file-attributes 宣言を読み込むと、指定の文字エンコーディングを使ってファイルの残りのテキストがデコードされます。たとえば、次のコードは、iso-latin-1 文字エンコーディングを使用してファイル内の Curl ソースを解釈するように指定しています。

ファイルは 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 によるソースファイルテキストの正しいエンコーディング処理が確保されます。