17.05 - 日本語文字のソート順序の考慮事項 - Advanced SQL Engine - Teradata Database

Teradata Vantage™ - SQLデータ操作言語

Product
Advanced SQL Engine
Teradata Database
Release Number
17.05
Release Date
2021年1月
Content Type
プログラミング リファレンス
Publication ID
B035-1146-175K-JPN
Language
日本語 (日本)

文字列がNOT CASESPECIFICでソートされる場合、比較またはソートの操作を実行する前に単純な小文字(例えば、ローマ字のa~z)は大文字に変換されます。 Teradataセッション モードのデフォルトはNOT CASESPECIFICです。 Teradata Vantage™ - SQLデータ定義言語-構文規則および例、B035-1144のSET SESSION COLLATIONを参照してください。

NOT CASESPECIFIC照合では大文字小文字の違いは無視されます。大文字であるか小文字であるかは、NOT CASESPECIFIC照合にとって重要ではありません。

非ローマ字の1バイト文字、マルチバイト文字、および1バイト文字とマルチバイト文字の間の変換を指示するバイトは、すべて、この変換から除外されます。

文字列がCASESPECIFIC (これは、ANSIセッション モードのデフォルト)でソートされる場合、大文字であるか小文字であるかは、照合にとって重要です。

CASESPECIFICモードのKanji1文字データの場合、ラテン文字、ギリシャ文字、キリル文字など大文字小文字を区別するローマ字は、同じ文字で大文字と小文字の区別が一致しているときだけ同一であるとみなされます。

CASESPECIFICモードでもNOT CASESPECIFICモードでも、全角文字と半角文字は同一であるとみなされません。

Vantageは、4つのサーバー文字セットのうちの1つを使用して日本語に対応します。
  • Unicode
  • KanjiSJIS
  • KANJI1[廃止]
  • Graphic
KANJI1のサポートは廃止されました。 KANJI1をデフォルトの文字セットとして使用することはできません。 システムはデフォルトのKANJI1文字セットをUNICODE文字セットに変更します。 KANJI1の新規オブジェクトの作成は、高度に制限されています。 KANJI1を使用する問合わせやアプリケーションの多くは、従来通り動作しますが、KANJI1を使用するサイトはできるだけ早く別の文字セットに変換する必要があります。
日本語文字のサイトでは、次のようにセッション照合を設定できます。
  • 文字データがKanjiSJISまたはUnicodeとしてVantageプラットフォームに格納されている場合、セッション文字セットを順序付けるのに最適な方法は、CHARSET_COLL照合を使用することです。

    文字データがKanjiSJISまたはUnicodeとしてVantageプラットフォームに格納されている場合、CHARSET_COLL照合によってクライアントのソート順序に最も近い照合を実行できます。

  • JIS_COLL照合でも適切な照合を実行できます。また、セッション文字セットに関係なく同じ照合が提供されます。
  • CHARSET_COLLとJIS_COLLの照合順序は、Kanji1文字データをサポートしません。

    Kanji1文字データの場合、ASCII照合によってクライアントの照合に類似した照合を実行できます。ただし、セッション文字セットがKanjiSJIS_0S、KanjiEUC_0U、またはこれと非常に似ている文字セットである場合に限ります。ただし、ASCII照合は、ShiftJISまたはUnicodeサーバー文字セットを使用しているVantageプラットフォームにデータが格納されている場合、クライアントのようにソートを実行しません。

  • KATAKANAEBCDIC、KANJIEBCDIC5026_0I、またはKANJIEBCDIC5035_0I文字セットを使用しているユーザーで、文字データをKanji1としてVantageプラットフォームに格納する場合、セッション文字セットで照合を実行する場合は、始動時に、それぞれKATAKANAEBCDIC、KANJIEBCDIC5026_0I、KANJIEBCDIC5035_0Iをインストールし、MULTINATIONAL照合を使用する必要があります。

    各文字セットは、適切に総合するためMULTINATIONAL照合用に異なる定義が必要です。

Vantageは、異なる日本語サーバー文字セット用に、以下のように文字データ照合を処理します。
  • KanjiEUC文字セット下では、ss3 0x8Fは0xFFに変換されます。これは、ユーザー定義のKanjiEUCコードセット3は、他のKanjiEUCコードセットに関しては正しく整列されないことを意味します。他のKanjiEUCコード セットの整列順序、すなわち、整列は、クライアント システムでのバイナリの整列と同じ順序になります。

    ASCII照合では、Kanji1データは2進数整列順序で照合されますが、1バイトまたは半角のローマ字の大文字小文字の区別が実行されます。<International Character Set Support>を参照してください。これは、KanjiSJIS_0Sセッションのクライアントでの照合に適しています。KanjiEUC_0Uに似ていて、KanjiEBCDICセッションの2バイト データに適度に似ています。KanjiEUC_0Uは、KanjiEBCDICと同様に、コード セット1の前でなくコード セット1の後ろにコード セット3を置きます。

  • Kanji1データの場合、マルチバイト文字として識別される文字は、クライアントのエンコーディング方式のままであり、その2進数値に基づいて照合されます。これは、ASCII照合がKanjiEBCDICセッションの2バイト文字に対して機能する理由を表わしています。

    マルチバイトKanji1文字は、KanjiEUC_0Uセッションのクライアント エンコーディングには残りません。

詳細については、<Teradata Vantage™ - Advanced SQL Engine国際文字セット サポート、B035-1125>および<Teradata Vantage™ - データ タイプおよびリテラル、B035-1143>を参照してください。