一般的に、データベース・マネージャーはアプリケーションで使用できる文字セットを制約しません。 DB2 でサポートされているマルチバイト文字セット (MBCS) について詳しくは、 アプリケーション開発の手引き を参照してください。
データベース名の中で使用できる基本文字セットは、 単一バイトの大文字および小文字のローマ字 (A...Z、a...z)、 アラビア数字 (0...9) および下線文字 (_) から構成されます。 ホストのデータベース製品との互換性を保つために、 3 つの特殊文字 (#、@、および $) がこのリストに加えられています。 しかし、これらの特殊文字は、 NLS ホスト (EBCDIC) の不変の文字セットには含まれていないので、 NLS 環境で使用するときには注意してください。
データベース・オブジェクト (表や視点など) に命名するときは、 プログラム・ラベル、ホスト変数、カーソル、 および拡張文字セットからの要素 (たとえば、 区別的発音符付きの文字) も使用することができます。 厳密にどの文字を使用できるかは、使用しているコード・ページによって異なります。 複数のコード・ページ環境でデータベースを使用する場合には、 すべてのコード・ページが、使用を計画している拡張文字セットからの要素を すべてサポートするようにする必要があります。 拡張文字セット以外の文字を含むにもかかわらず SQL ステートメントで 使用できる区切り識別子については、 SQL 解説書 を参照してください。
DBCS 環境では、拡張文字セットは、基本文字セットにあるすべての文字、 および次のような文字から構成されます。
SQL ステートメントのコーディングは、言語によって異なることはありません。 SQL キーワードは、大文字、小文字、または大文字小文字混合のいずれでも入力できます。 データベース・オブジェクトやホスト変数の名前、 および SQL ステートメント内のプログラム・ラベルの名前には、上記のように、 拡張文字セット以外の文字を含めることはできません。
以下の 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 に送られたデータは 正しく表示されない可能性があります。
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 リガチャーは保たれており、 構成の中では壊れていません。 |
両方向レイアウト変換は、新しい 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 コネクトで両方向レイアウト変換を実行するには、 サーバー・データベースの両方向 (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 コネクトに指示します。 このオーバーライド作業には、以下の処理が含まれています。
注: | 場合によっては、両方向 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 の NLS 情報を、データ・ソースの NLS 情報と比較してください。
データ・ソースによっては、 大文字小文字を区別しない照合順序で作成されるものもありますが、その場合、 順序依存の操作をすると、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 にリストされています。
それぞれの形式は名前で識別され、省略形と使用例も含めてあります。
形式名 | 省略形 | 日付形式 | 例 |
---|---|---|---|
国際標準化機構 | 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.30 は 13.30.00 に相当します。
時刻の有効なストリング形式が表 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 | アプリケーションの国別コードによる | -- |
注:
タイム・スタンプのストリング表示は、数字で始まり、 最低 16 文字の長さをもつ文字ストリングです。 タイム・スタンプの完全なストリング表示は、 yyyy-mm-dd-hh.mm.ss.nnnnnn という形式です。 後書きブランクを含めることもできます。また、タイム・スタンプの月、日、 および時刻の部分の先行ゼロを省略することができます。 さらに、マイクロ秒を切り捨てるか、または全体を省略することができます。 マイクロ秒の部分を省略するよう選択すると、0 が指定されたものと暗黙に想定されます。 したがって、1991-3-2-8.30.00 は 1991-03-02-08.30.00.000000 に相当します。
日付およびタイム・スタンプのストリングの内容は、 単一バイトの文字および数字でなければなりません。
日時の形式に関する文字ストリングの表示は、 アプリケーションの国別コードに関連する日時の値の省略時の形式です。 この省略時の形式は、 プログラムが事前コンパイルされるかデータベースにバインドされるときに、 F 形式オプションの指定によって指定変更することができます。
次に、日時の入力および出力形式について説明します。
国別コード | ローカル 日付形式 | ローカル 時刻形式 | 省略時の 出力の 日付形式 | 入力日付形式 |
---|---|---|---|---|
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 |
注:
|