1

さて、これが私の設定です。LinuxOS上にあるPHPアプリケーションに取り組んでいます。データをWindowsOS、SQLServerデータベースに渡そうとしています。私はFreetdsをプロバイダーとして使用しています。これは、LinuxマシンからSQLServerと通信するために誰もが使用しているように見えるためです。PHP用のデータベース抽象化ライブラリであるADODBを使用しています。

また、ユーザーが存在する数百の国のいずれかを選択し、その国の州または県を入力できるチェックアウトシステムを開発しています。このデータをすべて取得し、サードパーティのシステムに渡す必要があります。サードパーティのシステムは、前に説明したSQLServerインスタンスです。

問題は、ユーザーがöなどの州/国の特殊文字を使用してデータを入力していることです。adodbメソッドでストアドプロシージャパラメータに渡されたものをデバッグする場合でも、プロセスのすべてのポイントで特殊文字としてのPHP、アプリケーション、コードが正しく出力されないことを見つけるのに何時間もかかりました。freetds.confに次の行を追加する必要があることがわかったため、FreeTDSに問題がありました。

client charset = UTF-8

これは機能しているように見えますが、実際には自分のコードではなく、構成ファイルの1行だけであることに非常に満足しています。Jiraでタスクが終了した後、さらにテストを行ったところ、これについてもう心配する必要はないと思ったのですが、ルーマニアの州では機能していないというメールが届きました。したがって、すべての特殊文字が正しく渡されているわけではないようです。

私はキャラクターセットにそれほど精通していません。すべての開発者が知っておくべきJoelsAbsoluteMinimumを読みました。

ルーマニアで機能しない状態の例は、問題となっているのはキャラクターȘi la o răspântie cu statuiだと思うところです。ȘSQLサーバーでクエリを実行すると、それがSに変換されます。phpで実行してfreetdsを送信すると、このエラーメッセージが返されます。

The incoming tabular data stream (TDS) remote procedure call (RPC) protocol stream is incorrect. Parameter 9 ("@in_state_name"): Data type 0xA7 has an invalid data length or metadata length.

クエリを実行する前に設定SET names UTF8と他のいくつかを試しましたが、クエリに到達する前にfreetdsが正しい文字を渡していないことが問題だと思います。

4

1 に答える 1

1

問題は、現在のデータベースがvarcharのみを受け入れ、nvarcharを受け入れないことです。そのため、サードパーティにnvarcharをサポートさせるか、ASCIIを取得するために何らかのマッピングを行う必要があります。

于 2011-09-07T11:59:43.563 に答える