Windows-ANSI(Windowsコードページ1252)としてエンコードされたDBFファイルがあります。私はODBCドライバを使用して、このファイルをテーブルとしてSQL Serverデータベースにインポートしています。私がすると、いくつかの文字情報が失われます。Windows-Ansi DBFをSQL Serverにインポートすると文字データが失われる
最初に、DBFファイルが期待どおりにエンコードされていることを確認するために、ファイルを16進エディタで開き、問題の文字を検索しました。これはコードページ1252の「小文字」であり、ファイル内の0x95に格納されていたので、少なくともその文字については、エンコードが期待どおりであるように見えます。
私は検索して、varcharカラムではなくnvarcharにインポートすると違いがあると言っている人がいるので、問題のある文字を含むカラムをnvarcharに再マップしました。
それはにインポートされたデータベースは、「順序SQL_Latin1_General_CP1_CI_AS」との照合を持っている私は、インポートを行うと、これはWindowsコードページ1252
に相当する必要があることを示し、「CP1」MSDNに読んページから0xf2または0x5625としてインポートされています。私はなぜこの点まで様々な輸入があるのかについて何らかの理由を見いださなかった。
誰かがこのような問題に遭遇しましたか?あなたはそれを解決するために何をしましたか?私が探しているべきことや、私がまだ行っていないことを試してみるべきことは何ですか?
私はこれをさらに掘り下げて、0xB7の値が0x5625に変換されていることを発見しました。 ODBCドライバをさまざまなソース(ExcelとVBアプリケーション)に接続し、同じ問題が発生したので、これはODBCのものと仮定しています。また、0x5625、2 + 5 = 7および5 + 6 = Bの値については注意が必要です。 – Andrew
もう一度コメントしてください。 B7の0x5625の値はちょうど偶然かもしれません。これは、SQLサーバーのnvarcharにデータをインポートする場合にのみ発生します。 ODBC接続の他のアクセスは0x2Bを生成します。私は0から255までのすべての値を調べ、ODBCが0x80以上の値を間違って報告しているようです。 – Andrew