マルチ文字セット環境で作業する場合、文字セット変換の問題が発生すると、その問題がどこで発生したかの特定が困難である可能性があります。クライアント 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 サービスの場合、2 つのタイプの要求 (URL コード化された要求と multipart/form-data 要求) があります。
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 - Borland DBExpress Borland DBExpress ドライバーは、ODBC を ANSI クライアント API として使用します。デフォルトで CHAR 文字セットがクライアントオペレーティングシステムの文字セットになります。CharSet 接続パラメーターを使用してこれを変更できますが、データが正しくなくなる可能性があるためおすすめしません。
7 - TDS クライアント Sybase Open Client や jConnect などの TDS クライアントは、接続時にデータベースサーバーとネゴシエートし、クライアントで文字セット変換を実行することを選択します。ネゴシエーション中、データベースサーバーは文字セット変換を実行しないよう指示されます。
参照 |
DocCommentXchange で意見交換できます
|
Copyright © 2012, iAnywhere Solutions, Inc. - SQL Anywhere 12.0.1 |