マルチ文字セット環境で作業する場合、文字セット変換の問題が発生すると、その問題がどこで発生したかの特定が困難である可能性があります。クライアント API で文字セット変換の問題が発生した場合は、文字セット変換を制御するデータベースと接続のオプションやプロパティを確認してください。
変換の問題が発生する可能性がある箇所は、2 つのカテゴリに分けられます。1 つ目のカテゴリは、誤ったフォーマットのデータをクライアント API に送信したことに関係します。このカテゴリの問題は、Unicode API では発生しませんが、他のすべてのクライアント API で発生する可能性があり、データは無効になります。
問題の 2 つ目のカテゴリは、最終的な文字セットまたはいずれかの中間文字セットに対応するものがない文字に関係します。この場合、置換文字が使用されます。これは損失を伴う変換と呼ばれ、どのクライアント API でも発生する可能性があります。データベース文字セットに UTF-8 を使用するようにデータベースを設定すると、損失を伴う変換を回避できます。損失を伴う変換および置換文字を参照してください。
文字セット変換に影響するオプションとプロパティの設定 参照 クライアント API と文字セット変換のポイント次の図は、クライアント API がデータベースサーバと対話するときに文字セット変換が行われる可能性がある場所を示しています。
図の黒い星印は、文字セット変換が行われる可能性がある場所を示しています。図の数字は、図の後にある詳細な説明の番号に対応しています。
1 - DBLIB デフォルトで DBLIB CHAR 文字セットと NCHAR 文字セットがクライアントのオペレーティングシステムの文字セットになります。CHAR 文字セットは、BINARY と NCHAR を除くすべての文字列データに使用されます。NCHAR 文字セットは、NCHAR 型のホスト変数とホストパラメータ (これらは DBTools または DBCAPI インタフェースでは使用できません) に使用されます。データベースサーバでは、すべての文字セット変換が実行されます。
CHAR 文字セットと NCHAR 文字セットは、それぞれ CharSet 接続パラメータと db_change_nchar_charset 関数を使用して設定できます。CharSet (CS) 接続パラメータとdb_change_nchar_charset 関数を参照してください。
2 - Unicode API Unicode API を使用すると、ドライバは文字データに Unicode UTF-16 エンコードを使用し、Unicode データとデータベース文字セット間の変換を行います。ドライバは Unicode ホストパラメータを NCHAR 文字セット (UTF-8) に変換してからデータベースサーバに送信します。NCHAR として記述された結果セットのカラムは、NCHAR 文字セット (UTF-8) でフェッチされ、受信後に Unicode に変換されます。CharSet 接続パラメータを設定すると損失を伴う変換が発生する可能性があるため、このパラメータの設定はおすすめしません。損失を伴う変換および置換文字を参照してください。
3 - HTTP/HTTPS 「HTTP サービス (サーバとしての SQL Anywhere)：」HTTP サービスの場合、URL コード化された要求または multipart/form-data 要求の 2 つのタイプの要求があります。
URL コード化要求 要求は application/x-www-form-urlencoded の形式であり、変数はキーと値のペアで渡されます。データベースサーバは % でコード化されたデータ (UTF-8 またはデータベース文字セット) をデコードし、キーと値のペアをデータベース文字セットに変換します。処理された値は HTTP_VARIABLE 関数を使用して抽出できます。この関数で @BINARY または @TRANSPORT 属性を使用すると、% でデコードされ、文字セットが変換されていない値または未加工の HTTP (transport) 値をそれぞれ返すことができます。
Multipart/form-data 要求 要求はバイナリと見なされます。つまり、@BINARY または @TRANSPORT 属性を使用すると、同じ値が返されます。
HTTP サービス要求の文字セット変換は、sa_set_http_option システムプロシージャを使用して設定できる HTTP オプション CharsetConversion と AcceptCharset によって制御されます。sa_set_http_option システムプロシージャを参照してください。
要求や応答の文字セット変換に影響する可能性があるその他の設定には、優先文字セットの指定に使用される Accept-Charset ヘッダとコンテンツの文字セットの指定に使用される Content-Type ヘッダがあります。
「HTTP ストアドプロシージャ (クライアントとしての SQL Anywhere)：」HTTP ストアドプロシージャの場合、CHAR データはデータベース文字セット内で送信されます。パラメータが NCHAR 型の場合、すべてのデータは UTF-8 として送信されます (すべての CHAR パラメータは UTF-8 に変換されます)。要求によって、優先文字セットとしてデータベース文字セットを指定する Accept-Charset HTTP ヘッダが送信されます。優先文字セットのリストには、常に UTF-8 が含まれます。応答の Content-Type ヘッダにデータベース文字セットではない文字セットが指定されている場合、応答はクライアントによってデータベース文字セットに変換されます。
4a - Unicode エントリポイントを使用する ODBC ODBC アプリケーションは Unicode エントリポイントを使用する場合、Unicode クライアント API と見なされます。WCHAR データは Unicode API の場合と同じ方法で処理されます。ODBC アプリケーションが Unicode エントリポイントと CHAR (ANSI) データを使用する場合、データはデータベース文字セットであると見なされます。1 つのアプリケーションで CHAR データと WCHAR データを混在させることはおすすめしません。
4b - ANSI エントリポイントを使用する ODBC ODBC アプリケーションは ANSI エントリポイントを使用する場合、ANSI クライアント API と見なされます。デフォルトで CHAR 文字セットがクライアントオペレーティングシステムの文字セットになります。CHAR 文字セットは CharSet 接続パラメータを使用して変更できます。CharSet (CS) 接続パラメータを参照してください。
ANSI データの変換は、データベースサーバによって実行されます。WCHAR ホスト変数にフェッチすると、データベースサーバで CHAR データの損失を伴う変換が発生する可能性があります。1 つのアプリケーションで CHAR データと WCHAR データを混在させることはおすすめしません。
4c - ODBC ドライバマネージャ 一部の ODBC ドライバマネージャは、すべての CHAR データを WCHAR データに変換してから Unicode エントリ ポイントを呼び出します。
5 - SQL Anywhere JDBC ドライバ SQL Anywhere JDBC ドライバは、文字セット変換を実行せず、ODBC ドライバの Unicode エントリポイントと WCHAR 型を使用します。これは、Unicode エントリポイントを使用する ODBC で説明した内容と同じです。
6 - Embarcadero dbExpress Embarcadero dbExpress ドライバは、ODBC を ANSI クライアント API として使用します。デフォルトで CHAR 文字セットがクライアントオペレーティングシステムの文字セットになります。CharSet 接続パラメータを使用してこれを変更できますが、データが正しくなくなる可能性があるためおすすめしません。
7 - TDS クライアント Sybase Open Client や jConnect などの TDS クライアントは、接続時にデータベースサーバとネゴシエートし、クライアントで文字セット変換を実行することを選択します。ネゴシエーション中、データベースサーバは文字セット変換を実行しないよう指示されます。
参照 |
DocCommentXchange で意見交換できます
|
Copyright © 2013, SAP AG or an SAP affiliate company. - SAP Sybase SQL Anywhere 16.0 |