管理の手引き


文字セット

一般的に、データベース・マネージャーはアプリケーションで使用できる文字セットを制約しません。 DB2 でサポートされているマルチバイト文字セット (MBCS) について詳しくは、 アプリケーション開発の手引き を参照してください。

識別子用の文字セット

データベース名の中で使用できる基本文字セットは、 単一バイトの大文字および小文字のローマ字 (A...Z、a...z)、 アラビア数字 (0...9) および下線文字 (_) から構成されます。 ホストのデータベース製品との互換性を保つために、 3 つの特殊文字 (#、@、および $) がこのリストに加えられています。 しかし、これらの特殊文字は、 NLS ホスト (EBCDIC) の不変の文字セットには含まれていないので、 NLS 環境で使用するときには注意してください。

データベース・オブジェクト (表や視点など) に命名するときは、 プログラム・ラベル、ホスト変数、カーソル、 および拡張文字セットからの要素 (たとえば、 区別的発音符付きの文字) も使用することができます。 厳密にどの文字を使用できるかは、使用しているコード・ページによって異なります。 複数のコード・ページ環境でデータベースを使用する場合には、 すべてのコード・ページが、使用を計画している拡張文字セットからの要素を すべてサポートするようにする必要があります。 拡張文字セット以外の文字を含むにもかかわらず SQL ステートメントで 使用できる区切り識別子については、 SQL 解説書 を参照してください。

DBCS 識別子用の拡張文字セットの定義

DBCS 環境では、拡張文字セットは、基本文字セットにあるすべての文字、 および次のような文字から構成されます。

SQL ステートメントのコーディング

SQL ステートメントのコーディングは、言語によって異なることはありません。 SQL キーワードは、大文字、小文字、または大文字小文字混合のいずれでも入力できます。 データベース・オブジェクトやホスト変数の名前、 および SQL ステートメント内のプログラム・ラベルの名前には、上記のように、 拡張文字セット以外の文字を含めることはできません。

両方向 CCSID サポート

以下の BiDi 属性は、異なるプラットフォーム上で両方向データの正しい処理を行うために必要です。

   - Text type (LOGICAL or VISUAL)
   - Shaping (SHAPED or UNSHAPED)
   - Orientation (RIGHT-TO-LEFT or LEFT-TO-RIGHT)
   - Numeral shape (ARABIC or HINDI)
   - Symmetric swapping (YES or NO)

プラットフォームごとに省略時値が異なるため、 DB2 データをあるプラットフォームから別のプラットフォームに移すと問題が生じる可能性があります。 たとえば、 Windows オペレーティング・システムは LOGICAL UNSHAPED データを使用しますが、 OS/390 は通常 SHAPED VISUAL データを使用します。 したがって、両方向属性がサポートされていない場合、 DB2 ユニバーサル・データベース for OS/390 から Windows 32 ビット オペレーティング・システム上の DB2 UDB に送られたデータは 正しく表示されない可能性があります。

両方向特定の CCSID

DB2 は、特別な両方向コード化文字セット識別子 (CCSID) を介して、 両方向データ属性をサポートします。 以下の両方向 CCSID はすでに定義されており、DB2 UDB で実装されます。

          CCSID |  CCSID | コード | ストリング
          (dec) |  (hex) | ページ |   タイプ
         -------+--------+--------+--------
           00420   x'01A4'   420      4
           00424   x'01A8'   424      4
           08612   x'21A4'   420      5
           08616   x'21A8'   424     10
           00856   x'0358'   856      5
           00862   x'035E'   862      4
           00864   x'0360'   864      5
           00916   x'0394'   916      5
           01046   x'0416'  1046      5
           01089   x'0441'  1089      5
           01255   x'04E7'  1255      5
           01256   x'04E8'  1256      5
           62208   x'F300'   856      4
           62209   x'F301'   862     10
           62210   x'F302'   916      4
           62211   x'F303'   424      5
           62213   x'F305'   862      5
           62215   x'F307'  1255      4
           62218   x'F30A'   864      4
           62220   x'F30C'   856      6
           62221   x'F30D'   862      6
           62222   x'F30E'   916      6
           62223   x'F30F'  1255      6
           62224   x'F310'   420      6
           62225   x'F311'   864      6
           62226   x'F312'  1046      6
           62227   x'F313'  1089      6
           62228   x'F314'  1256      6
           62229   x'F315'   424      8
           62230   x'F316'   856      8
           62231   x'F317'   862      8
           62232   x'F318'   916      8
           62233   x'F319'   420      8
           62234   x'F31A'   420      9
           62235   x'F31B'   424      6
           62236   x'F31C'   856     10
           62237   x'F31D'  1255      8
           62238   x'F31E'   916     10
           62239   x'F31F'  1255     10
           62240   x'F320'   424     11
           62241   x'F321'   856     11
           62242   x'F322'   862     11
           62243   x'F323'   916     11
           62244   x'F324'  1255     11
           62245   x'F325'   424     10
           62246   x'F326'  1046      8
           62247   x'F327'  1046      9
           62248   x'F328'  1046      4
           62249   x'F329'  1046     12
           62250   x'F32A'   420     12

CDRA ストリング・タイプは以下のように定義されます。

 ストリング・| テキスト・|   数値   |   方向     |     型        |    対称
   タイプ    |  タイプ   |    型    |            |               |    交換
   --------+-------+------------+-------------+-----------+-------------
      4     Visual    Passthru        LTR       Shaped         OFF
      5     Implicit   Arabic         LTR       Unshaped       ON
      6     Implicit   Arabic         RTL       Unshaped       ON
      7(*)  Visual     Arabic    Contextual(*)  Unshaped-Lig   OFF
      8     Visual     Arabic         RTL       Shaped         OFF
      9     Visual    Passthru        RTL       Shaped         ON
     10     Implicit  Passthru   Contextual-L   Unshaped       ON
     11     Implicit  Passthru   Contextual-R   Unshaped       ON
     12     Implicit   Arabic         RTL       Shaped         ON
注:(*) 最初のアルファベット文字がローマ字なら、 フィールドの方向は左から右 (left-to-right (LTR)) になります。 両方向 (RTL) 文字の場合は、右から左 (right-to-left (RTL)) になります。 文字が Unshaped になっていても、LamAlef リガチャーは保たれており、 構成の中では壊れていません。

DB2 ユニバーサル・データベースにおける両方向サポートの実装

両方向レイアウト変換は、新しい CCSID 定義を使って DB2 ユニバーサル・データベースで実装されます。 新しい BiDi 特定の CCSID の場合、レイアウト変換はコード・ページ変換の代わりに、 あるいはコード・ページ変換に加えて実行されます。 このサポートを使用するためには、DB2BIDI レジストリー変数を YES に設定しなければなりません。 省略時の設定では、この値は設定されていません。 この変数はサーバーによってすべての変換で使用され、 サーバーが開始したときにのみ設定できます。 DB2BIDI を YES に設定すると、変換の追加チェックとレイアウトが原因で、 パフォーマンスにいくらかの悪影響を与える可能性があります。

非 DRDA 環境で特定の両方向 CCSID を指定するには、 クライアントの特性と一致する CCSID を (上記の表から) 選んで、 DB2CODEPAGE をその値に設定します。 データベースにすでに接続している場合は、TERMINATE コマンドを発行し、 さらに DB2CODEPAGE の新しい設定を有効にするために接続しなおす必要があります。 クライアント・プラットフォームのコード・ページまたはストリング・タイプに 適切でない CCSID を選択すると、予期しない結果が発生する可能性があります。 非互換の CCSID を選択した場合 (たとえば、 アラビア語データベースへの接続にヘブライ語 CCSID を選択した場合)、 または DB2BIDI がサーバーに設定されていない場合には、 接続しようとするとエラー・メッセージを受け取ります。

DRDA 環境では、 HOST EBCDIC プラットフォームがこれらの両方向 CCSID をもサポートしていれば、 DB2CODEPAGE を設定するだけで済みます。 しかし、HOST プラットフォームがこれらの CCSID をサポートしていない場合、 接続している HOST データベース・サーバー用の CCSID オーバーライドを指定しなければなりません。 これは必須です。DRDA 環境では、 コード・ページ変換とレイアウト変換はデータの受信側で実行されるからです。 しかし、HOST サーバーがこれらの両方向 CCSID をサポートしない場合、 DB2 UDB から受信するデータ上のレイアウト変換は実行されません。 CCSID オーバーライドを使用しているなら、 DB2 UDB クライアントはアウトバウンド・データ上でレイアウト変換も実行します。 CCSID オーバーライドの設定について詳しくは、DB2 コネクト 使用者の手引き を参照してください。

CCSID オーバーライドは、HOST EBCDIC プラットフォームがクライアントで、 かつ DB2 UDB がサーバーの場合にはサポートされません。

両方向の DB2 コネクト実装のサポート

DB2 コネクトとサーバー上のデータベースとの間でデータを交換する場合、 着信データの変換を実行するのは、通常は受信側です。 この同じ規則は、通常のコード・ページ変換の規則とともに、 両方向レイアウト変換にも当てはまります。 DB2 コネクトは、サーバー・データベースから受け取るデータだけでなく、 サーバー・データベースへ送るデータに対して、両方向レイアウト変換を実行するための任意選択機能を備えています。

サーバー・データベースへの発信データに対して、 DB2 コネクトで両方向レイアウト変換を実行するには、 サーバー・データベースの両方向 (CCSID) をオーバーライドする必要があります。 これを行うには、 サーバー・データベースの DCS データベース・ディレクトリーの PARMS フィールドで BIDI パラメーターを使います。
注:DB2 ホスト・データベースに送る予定のデータに対して、 DB2 コネクトでレイアウト変換を実行するのであれば、 CCSID をオーバーライドする必要がなくても、 DCS データベース・ディレクトリーの PARMS フィールドに BIDI パラメーターを追加する必要があります。 その場合、指定する CCSID は、省略時の DB2 ホスト・データベース CCSID になります。

省略時のサーバー・データベース両方向 CCSID をオーバーライドするときに 使う両方向 CCSID とともに、 BIDI パラメーターを PARMS フィールドの 9 番目のパラメーターとして 以下のように指定します。

   ",,,,,,,,BIDI=xyz"

xyz には CCSID のオーバーライドが入ります。
注:レジストリー変数 DB2BIDI は YES にセットして、BIDI パラメーターを有効にしなければなりません。

サポートされている両方向 CCSID とそのストリング・タイプのリストは、 両方向特定の CCSID にあります。

この機能の使用方法について、わかりやすい例をあげましょう。

CCSID 62213 (両方向ストリング・タイプ 5) を実行するヘブライ語の DB2 クライアントを使っていて、 CCSID 00424 (両方向ストリング・タイプ 4) を実行する DB2 ホスト・データベースにアクセスしたいとします。 しかし、DB2 ホスト・データベースに含まれているデータは、 CCSID 08616 (両方向ストリング・タイプ 6) をベースにしたものであることが分かっています。

ここでは 2 つの問題があります。 最初の問題は、DB2 ホスト・データベース側では、 CCSID 00424 と 08616 での両方向ストリング・タイプの違いを認識していないということです。 2 番目の問題は、DB2 ホスト・データベースは、 DB2 クライアント CCSID (62213) を認識しないということです。 サポートされているのは CCSID 00862 だけであり、 CCSID 62213 と同じコード・ページをベースにしているものです。

まず DB2 ホスト・データベースに送るデータが、両方向ストリング・タイプ 6 形式であることを確認してから、 DB2 ホスト・データベースから受け取るデータに対して両方項変換を実行しなければならないことを、 DB2 コネクトに指示する必要があります。 DB2 ホスト・データベースに次のカタログ・コマンドを使用する必要があります。

   db2 catalog dcs database nydb1 as telaviv parms ",,,,,,,,BIDI=08616"

このコマンドは、 DB2 ホスト・データベースの CCSID 00424 を 08616 で オーバーライドするよう DB2 コネクトに指示します。 このオーバーライド作業には、以下の処理が含まれています。

  1. DB2 コネクトは CCSID 00862 を使用して DB2 ホスト・データベースへ接続します。
  2. DB2 コネクトは、DB2 ホスト・データベースに送る 予定のデータに対して、 両方向レイアウト変換を実行します。 この変換は、CCSID 62213 (両方向ストリング・タイプ 5) から CCSID 62221 (両方向ストリング・タイプ 6) への変換です。
  3. DB2 コネクトは、DB2 ホスト・データベースから受け取る データに対して、 両方向レイアウト変換を実行します。 この変換は、 CCSID 08616 (両方向ストリング・タイプ 6) から CCSID 62213 (両方向ストリング・タイプ 5) への変換です。
注:場合によっては、両方向 CCSID を使用すると、 SQL 照会そのものが変更されてしまい、 DB2 サーバーによって認識されなくなることがあります。 特に、異なるストリング・タイプが使われる可能性のあるときは、 IMPLICIT CONTEXTUAL と IMPLICIT RIGHT-TO=LEFT CCSID の使用を避けてください。 CONTEXTUAL CCSID を使うと、SQL 照会に引用符付きストリングが含まれる場合に、 予期しない結果を生じる可能性があります。 SQL ステートメントでは引用符付きストリングを使わないようにし、 その代わりにできる限りホスト変数を使用してください。

特定の両方向 CCSID が問題を引き起こしていて、 前述の方法では修正できない場合には、DB2BIDI を NO に設定してください。

照合順序

データベース・マネージャーは、照合順序 を使用して、文字データを比較します。 これは、ある文字がほかの文字とくらべて、高いか、低いか、 または同じかを判別するための文字セットの順序付けです。 たとえば、照合順序を使用して、ある文字についての大文字・小文字のバージョンは、 同じものとして分類されます。

照合順序はデータベース作成の時点で指定します。 あとでこれを変更することはできません。

データベース・マネージャーでは、 アプリケーション・プログラミング・インターフェース (API) を使用して、 カスタムの照合順序でデータベースを作成することができます。 カスタムの照合順序表の実装については、アプリケーション開発の手引き を参照してください。
注:FOR BIT DATA 属性で定義された文字ストリング・データ、 および BLOB データは、2 進数の分類順序を用いて分類されます。

一般的な問題

いったん照合順序が定義されると、 そのデータベースに対するその後の文字の比較はすべて、その照合順序で行われます。 FOR BIT DATA または BLOB データとして定義された文字データの場合を除いて、 すべての SQL 比較および ORDER BY 文節についても、また索引や統計の設定においても、 この照合順序が使用されます。 データベースの照合順序の使用方法についての詳細は、 SQL 解説書 の『ストリングの比較』を参照してください。

以下のような場合には、問題が起こる可能性があります。

最後に、文字コード・ポイントの直接比較にもとづく分類の結果が一致するのは、 一致照合順序を用いて順序づけられた照会の結果だけであることに注意してください。

連合データベースでの問題

データベース照合順序の選択は、連合システムのパフォーマンスに影響することがあります。 あるデータ・ソースが、 DB2 連合データベースと同じ 照合順序を使う場合、 DB2 は、文字データが関係する順序依存の処理を、 そのデータ・ソースにプッシュダウンすることができます。 データ・ソース照合順序が DB2 の照合順序と一致しない場合、 データが取り出され、文字データについてのすべての順序依存の処理が ローカルに行われます (パフォーマンスが低下することがあります)。

データ・ソースと DB2 の照合順序が同じかどうかを判別するには、 以下の要因を考慮してください。

DB2 連合データベースからアクセスするさまざまなデータ・ソースを考慮した上で、 そのデータベースに適した照合順序を選択してください。 次に例を示します。

MVS の照合順序のセットアップ方法については、 管理 API 解説書sqlecrea (データベース作成) API の説明に記載されている例を参照してください。 この例には、EBCIDIC 500、37、および 5026/5035 コード・ページの照合表が載せられています。

DB2 データベースに照合順序を設定したら、データ・ソースのサーバーごとに、 collating_sequence サーバー・オプションを 設定してください。 このオプションは、所定のデータ・ソース・サーバーの 照合順序が DB2 データベースの照合順序と一致するかどうかを指定します。

照合順序が一致する場合は、collating_sequence オプションを 「Y」にセットしてください。 このように設定すると、DB2 最適化プログラムは、 データ・ソースでの順序依存の処理を選ぶことができます。 これにより、パフォーマンスが改善されます。 しかし、データ・ソースの照合順序が DB2 データベースの照合順序と同じでないと、正しくない結果を受け取ることがあります。 たとえば、マージ結合を使う計画の場合、DB2 最適化プログラムは、順序付けの操作をできる限りデータ・ソースへプッシュダウンします。 データ・ソースの照合順序が同じでなければ、 結合の結果セットが正しくない可能性があります。

照合順序が一致しない場合は、collating_sequence オプションを「N」にセットしてください。 この値は、データ・ソースの照合順序が DB2 とは異なるとき、あるいはデータ・ソースの照合順序が大文字小文字を区別しないときに使用します。 たとえば、英語のコード・ページでの大文字小文字を区別しないデータ・ソースでは、 TOLLESON、ToLLeSoN、および tolleson はすべて同じものであるとみなされます。 データ・ソースでの照合順序が DB2 の照合順序と同じかどうか分からないときには、この collating_sequence オプションを 「N」 にセットしてください。

日時値

日時値のデータ・タイプを次に説明します。 日時値は、特定の算術計算やストリング演算に使用することができ、特定のストリングとも互換性がありますが、この値はストリングでも数字でもありません。

日付

日付 は、3 つの部分の値 (年、月、および日) です。 年の部分の範囲は 0001 から 9999 です。 月の部分の範囲は、1 から 12 です。 日の部分の範囲は、1 から x で、x は、月によって決まります。

日付の内部表記は 4 バイトのストリングです。 それぞれのバイトは、2 つのパック 10 進数から構成されます。 最初の 2 バイトは年を表し、3 番目のバイトは月、最後のバイトは日を表します。

DATE 列の長さは、SQLDA に記述されているように 10 バイトですが、 これは、この値の文字ストリング表示として適切な長さです。

時刻

時刻 は、3 つの部分の値 (時、分、および秒) で、 24 時間時計の時刻を示します。 時間の部分の範囲は 0 から 24 で、 他の部分の範囲は、0 から 59 です。 時間が 24 の場合は、分と秒の指定はゼロになります。

時刻の内部表記は 3 バイトのストリングです。 それぞれのバイトは、2 つのパック 10 進数です。 最初のバイトは時間を表し、2 番目のバイトは分を、最後のバイトは秒を表します。

TIME 列の長さは、SQLDA に記述されているように 8 バイトですが、これは、 この値の文字ストリングとして適切な長さです。

タイム・スタンプ

タイム・スタンプ とは、 7 つの部分からなる値 (年、月、日、時、分、秒、 およびマイクロ秒) で上と同じように日時を指定するものですが、 上記との違いは、時刻にマイクロ秒の指定が含まれる点です。

タイム・スタンプの内部表記は 10 バイトのストリングです。 それぞれのバイトは、2 つのパック 10 進数です。 最初の 4 バイトは日付を表し、 次の 3 バイトは時刻を表し、最後の 3 バイトはマイクロ秒を表します。

TIMESTAMP 列の長さは、SQLDA に記述されているように 26 バイトですが、 これは、この値の文字ストリング表示として適切な長さです。

日時値のストリング表示

データ・タイプが DATE、TIME、または TIMESTAMP である値は、 SQL ユーザーにとって透過であるような内部形式で表示されます。 しかし、日付、時刻、およびタイム・スタンプは、文字ストリングでも表示でき、 そのような表示は SQL ユーザーに直接かかわってきます。 データ・タイプが DATE、TIME、または TIMESTAMP であるような定数や変数はないからです。 したがって、検索をするときは、日時値を文字ストリング変数に割り当てる必要があります。 文字ストリング表示は、通常、 クライアントの国別コードと関連づけられた日時値の省略時形式になりますが、 プログラムが事前にコンパイルされたか、データベースにバインドされたときに、 "F" 形式オプションの指定によって指定変更することもできます。 各種の国別コードのストリング形式のリストは、 表 94 を参照してください。

日時値の有効なストリング表示が内部的な日時値を用いる演算に使用されるときは、 ストリング表示は、演算が行われる前に日付、時刻、 またはタイム・スタンプの内部形式に変換されます。 次のセクションで、日時値の有効なストリング表示を定義します。

日付ストリング

日付のストリング表示は、数字で始まり、最低 8 文字の長さをもつ文字ストリングです。 後書きブランクを含めることもできます。 また、日付の月および日の部分の先行ゼロを省略することができます。

日付の有効なストリング形式が表 92 にリストされています。 それぞれの形式は名前で識別され、省略形と使用例も含めてあります。

表 92. 日付のストリング表示の形式
形式名 省略形 日付形式
国際標準化機構 ISO yyyy-mm-dd 1991-10-27
IBM USA 標準規格 USA mm/dd/yyyy 10/27/1991
IBM 欧州標準規格 EUR dd.mm.yyyy 27.10.1991
日本工業規格 (JIS) JIS yyyy-mm-dd 1991-10-27
地域別定義 (ローカル) LOC データベース国別コードによる --

時刻ストリング

時刻のストリング表示は、数字で始まり、最低 4 文字の長さをもつ文字ストリングです。 後書きブランクを含めることができます。また、時刻の時間の部分の先行ゼロを省略したり、秒全体を省略することができます。 秒を省略するよう選択すると、0 秒が指定されたものと暗黙に想定されます。 したがって、13.3013.30.00 に相当します。

時刻の有効なストリング形式が表 93 にリストされています。 それぞれの形式は名前で識別され、省略形と使用例も含めてあります。

表 93. 時刻のストリング表示の形式
形式名 省略形 時刻形式
国際標準化機構 ISO hh.mm.ss 13.30.05
IBM USA 標準規格 USA hh:mm AM または PM 1:30 PM
IBM 欧州標準規格 EUR hh.mm.ss 13.30.05
日本工業規格 (JIS) JIS hh:mm:ss 13:30:05
地域別定義 (ローカル) LOC アプリケーションの国別コードによる --

注:

  1. ISO、EUR または JIS 時刻ストリング形式では、 .ss (または :ss) は任意選択です。

  2. USA 時刻ストリング形式の場合は、 分の指定を省略することができます (00 分を暗黙に指定したことになります)。 したがって、1 PM は 1:00 PM に相当します。

  3. USA 時刻形式では、時間指定は 12 より大きくすることはできません。 また、00:00 AM という特殊な場合を除いて、0 にすることはできません。 24 時間時計の ISO 形式を使用する場合は、USA 形式と 24 時間時計の対応は、 次のようになります。

タイム・スタンプ・ストリング

タイム・スタンプのストリング表示は、数字で始まり、 最低 16 文字の長さをもつ文字ストリングです。 タイム・スタンプの完全なストリング表示は、 yyyy-mm-dd-hh.mm.ss.nnnnnn という形式です。 後書きブランクを含めることもできます。また、タイム・スタンプの月、日、 および時刻の部分の先行ゼロを省略することができます。 さらに、マイクロ秒を切り捨てるか、または全体を省略することができます。 マイクロ秒の部分を省略するよう選択すると、0 が指定されたものと暗黙に想定されます。 したがって、1991-3-2-8.30.001991-03-02-08.30.00.000000 に相当します。

MBCS に関する考慮事項

日付およびタイム・スタンプのストリングの内容は、 単一バイトの文字および数字でなければなりません。

日時の形式

日時の形式に関する文字ストリングの表示は、 アプリケーションの国別コードに関連する日時の値の省略時の形式です。 この省略時の形式は、 プログラムが事前コンパイルされるかデータベースにバインドされるときに、 F 形式オプションの指定によって指定変更することができます。

次に、日時の入力および出力形式について説明します。


表 94. 国別コードによる日時の形式
国別コード ローカル 日付形式 ローカル 時刻形式 省略時の 出力の 日付形式 入力日付形式
355 アルバニア yyyy-mm-dd JIS LOC LOC、 USA、 EUR、 ISO
785 アラブ dd/mm/yyyy JIS LOC LOC、 EUR、 ISO
001 オーストラリア (1) mm-dd-yyyy JIS LOC LOC、 USA、 EUR、 ISO
061 オーストラリア dd-mm-yyyy JIS LOC LOC、 USA、 EUR、 ISO
032 ベルギー dd/mm/yyyy JIS LOC LOC、 EUR、 ISO
055 ブラジル dd.mm.yyyy JIS LOC LOC、 EUR、 ISO
359 ブルガリア dd.mm.yyyy JIS EUR LOC、 USA、 EUR、 ISO
001 カナダ mm-dd-yyyy JIS USA LOC、 USA、 EUR、 ISO
002 カナダ (フランス語圏) dd-mm-yyyy ISO ISO LOC、 USA、 EUR、 ISO
385 クロアチア yyyy-mm-dd JIS ISO LOC、 USA、 EUR、 ISO
042 チェコ共和国 yyyy-mm-dd JIS ISO LOC、 USA、 EUR、 ISO
045 デンマーク dd-mm-yyyy ISO ISO LOC、 USA、 EUR、 ISO
358 フィンランド dd/mm/yyyy ISO EUR LOC、 EUR、 ISO
389 FYR マケドニア dd.mm.yyyy JIS EUR LOC、 USA、 EUR、 ISO
033 フランス dd/mm/yyyy JIS EUR LOC、 EUR、 ISO
049 ドイツ dd/mm/yyyy ISO ISO LOC、 EUR、 ISO
030 ギリシャ dd/mm/yyyy JIS LOC LOC、 EUR、 ISO
036 ハンガリー yyyy-mm-dd JIS ISO LOC、 USA、 EUR、 ISO
354 アイスランド dd-mm-yyyy JIS LOC LOC、 USA、 EUR、 ISO
091 インド dd/mm/yyyy JIS LOC LOC、 EUR、 ISO
972 イスラエル dd/mm/yyyy JIS LOC LOC、 EUR、 ISO
039 イタリア dd/mm/yyyy JIS LOC LOC、 EUR、 ISO
081 日本 mm/dd/yyyy JIS ISO LOC、 USA、 EUR、 ISO
082 韓国 mm/dd/yyyy JIS ISO LOC、 USA、 EUR、 ISO
001 ラテンアメリカ (1) mm-dd-yyyy JIS LOC LOC、 USA、 EUR、 ISO
003 ラテンアメリカ dd-mm-yyyy JIS LOC LOC、 EUR、 ISO
031 オランダ dd-mm-yyyy JIS LOC LOC、 USA、 EUR、 ISO
047 ノルウェー dd/mm/yyyy ISO EUR LOC、 EUR、 ISO
048 ポーランド yyyy-mm-dd JIS ISO LOC、 USA、 EUR、 ISO
351 ポルトガル dd/mm/yyyy JIS LOC LOC、 EUR、 ISO
086 中華人民共和国 mm/dd/yyyy JIS ISO LOC、 USA、 EUR、 ISO
040 ルーマニア yyyy-mm-dd JIS ISO LOC、 USA、 EUR、 ISO
007 ロシア dd/mm/yyyy ISO LOC LOC、 EUR、 ISO
381 セルビア/ モンテネグロ yyyy-mm-dd JIS ISO LOC、 USA、 EUR、 ISO
042 スロバキア yyyy-mm-dd JIS ISO LOC、 USA、 EUR、 ISO
386 スロベニア yyyy-mm-dd JIS ISO LOC、 USA、 EUR、 ISO
034 スペイン dd/mm/yyyy JIS LOC LOC、 EUR、 ISO
046 スウェーデン dd/mm/yyyy ISO ISO LOC、 EUR、 ISO
041 スイス dd/mm/yyyy ISO EUR LOC、 EUR、 ISO
088 台湾 mm-dd-yyyy JIS ISO LOC、 USA、 EUR、 ISO
066 タイ (2) dd/mm/yyyy JIS LOC LOC、 EUR、 ISO
090 トルコ dd/mm/yyyy JIS LOC LOC、 EUR、 ISO
044 英国 dd/mm/yyyy JIS LOC LOC、 EUR、 ISO
001 米国 mm-dd-yyyy JIS USA LOC、 USA、 EUR、 ISO
084 ベトナム dd/mm/yyyy JIS LOC LOC、 EUR、 ISO

注:

  1. 省略時解釈の C ロケールを使用する国には、国別コード 001 が割り当てられます。

  2. 仏教暦 yyyy は、グレゴリオ暦 + 543 年にあたります (タイのみで適用)。


[ ページのトップ | 前ページ | 次ページ | 目次 | 索引 ]