3

私はSybaseSQLAnywhere 12をPython（およびTwisted）と一緒に数週間戦っていますが、自分のものも機能するようになりました。

煩わしさは1つだけ残っています。デプロイメントプラットフォームであるカスタムPython2.7.1を使用してCentOS5でスクリプトを実行すると、UTF-8として結果が得られます。

Ubuntuボックス（Natty Narwhal）で実行すると、latin1で取得できます。

言うまでもなく、すべてのデータをUnicodeで取得したいのですが、それはこの質問のポイントではありません。:)

どちらも64ビットボックスで、どちらにもカスタムPython2.7.1があります。UCS4とカスタムビルドのunixODBC2.3.0を使用します。

私はここで途方に暮れています。そのドキュメントが見つかりません。pyodbcまたはunixODBCが2つのボックスで異なる動作をする理由は何ですか？

難しい事実：

  • Python：2.7.1
  • DB：SQL Anywhere 12
  • unixODBC：2.3.0（2.2.14は同じように動作しました）、同一のフラグで自己コンパイル
  • ODBCドライバー：Sybaseからのオリジナル。
  • CentOS 5はUTF-8を提供し、UbuntuNattyNarwhalはlatin1を提供します。

私のodbc.iniは次のようになります。

[sybase]
Uid             = user
Pwd             = password
Driver          = /opt/sqlanywhere/lib64/libdbodbc12_r.so
Threading       = True
ServerName      = dbname
CommLinks       = tcpip(host=the-host;DoBroadcast=None)

DNS='sybase'を使用して接続します。

TIA！

4

2 に答える 2

4

なぜ違うのかはわかりませんが、DSNに「Charset = utf-8」を追加すると、両方のマシンで希望する結果が得られるはずです。

免責事項：私はSQLAnywhereエンジニアリングのSybaseで働いています。

于 2011-05-04T17:00:57.637 に答える
4

pyodbcは、2つのエンコーディングのみをサポートするODBC仕様を使用します。'W'で終わるすべてのODBC関数は、SQLWCHARを使用するワイド文字バージョンです。これはODBCヘッダーによって定義され、通常はUCS2ですが、UCS4の場合もあります。非ワイドバージョンはSQLCHARを使用し、常に（？）シングルバイトANSI/ASCIIです。

ODBCでは、UTF8などの可変幅エンコーディングはまったくサポートされていません。ODBCドライバーがそれを提供する場合、それは絶対に正しくありません。データがUTF8に格納されている場合でも、ドライバーによってANSIまたはUCS2に変換する必要があります。残念ながら、ほとんどのODBCドライバーは完全に正しくありません。

pyodbcは、ドライバーに送信するときに、データが「str」オブジェクトの場合はANSIを使用し、データが「unicode」オブジェクトの場合はUCS2 / UCS4（プラットフォーム上に定義されているSQLWCHAR）を使用します。ドライバーは、データを返すときにデータがSQLCHARであるかSQLWCHARであるかを判別し、pyodbcは問題について何も言いません。SQLCHARの場合は「str」オブジェクトに変換され、SQLWCHARの場合は「unicode」オブジェクトに変換されます。

これは、デフォルトでSQLCHARとSQLWCHARの両方をUnicodeに変換する3.xバージョンではわずかに異なります。

于 2011-07-05T18:52:19.260 に答える