CSVファイルからインポートする文字変換の問題
CSVファイルのロードを実行した後、データベースに誤って「書き込まれた」さまざまな単語があります。
いくつかの例：
Diã¡riaはDiáriaCrã©ditoはCréditoLigaã§ãµesはLigaçõesUsuã¡rioはUsuárioNãºmerosはNúmeros
シンボルを正しい文字に変換する方法はありますか？
インターネットを検索できるcollationsとfunctionsを使っていくつかのテストを行いましたが、成功しませんでした。
データベースに誤って「書き込まれる」さまざまな単語があります。
いいえ、文字は read が誤って読み取られています。それらは正しく書かれています。または、これを確認する別の方法は、文字が data file に誤って書き込まれていることです。どちらの方法でも、SQL Serverは要求されたとおりのことを実行しています。
これは単純なエンコーディングの問題です。データは元々UTF-8としてエクスポートされていましたが、そのUTF-8でエンコードされたファイルは、コードページ1252を使用して拡張ASCIIファイルであるかのようにSQL Serverに読み込まれました。これが問題であることを示します。
- ほとんどのキャラクターは正しく通り抜けます。ないのはアクセント文字です。
- 正しくない文字は、1文字ではなく2文字として表示されます。
- 「ASCII」ファイルへのエクスポートは機能するとのことですが、.
UTF-8は マルチバイトエンコーディング です：エンコードされる文字に応じて異なるバイト数を使用します。米国英語のアルファベットを含む最初の128コードポイント（U + 0000-U + 007F）はすべて1バイトを使用します。この範囲を超えるコードポイントには2〜4バイトかかります。これが、システム間で期待どおりに一部の文字が転送される理由です：N（大文字のラテン語「N」）は、UTF-8および/で0x4Eです。コードページ1252（実際には、SQL Serverでサポートされているすべての8ビットコードページ全体で0x4Eです）。これは、UTF-8が非常に人気がある理由の1つです。ただし、アクセント付き文字はUTF-8では1バイトではありません。
_
á_（U + 00E1）は、UTF-8で2バイトとしてエンコードされます：0xC3および0xA1。これらの2バイトがコードページ1252を期待する何かによって読み取られると、それらは_Ã_（0xC3on Code Page 1252）および_¡_として解釈されます（0xA1（コードページ1252））。次に、あなたまたはあなたのインポートプロセスのいずれかが、_Ã_を小文字にしました（おそらくそれがWordの途中にあったためです）。これは、_Usuã¡rio_で終わった方法です。_
ú_（U + 00FA）は、UTF-8で2バイトとしてエンコードされます：0xC3および0xBA。これらの2バイトがコードページ1252を期待する何かによって読み取られると、それらは_Ã_（0xC3on Code Page 1252）および_º_として解釈されます（0xBA（コードページ1252））。次に、あなたまたはあなたのインポートプロセスのいずれかが、_Ã_を小文字にしました（おそらくそれがWordの途中にあったためです）。これは、_Nãºmero_で終わった方法です。
選択肢は次のとおりです。
（拡張）ASCIIとしてコードページ1252を使用して（エクスポートされたとおりに）ファイルをエンコードし、SQL Serverへの読み取り方法を変更しないでください（既にこれを実行しているようです） ）。
UTF-8エンコードを使用してファイルのエクスポートを続行しますが、ファイルがUTF-8としてエンコードされるように指定することにより、SQL Serverへのファイルの読み取り方法を変更します。 BCP.exe、_
BULK INSERT_、またはOPENROWSET(BULK...)を使用するすべてのユーザーがこのオプションを使用できるようになったのは、SQL Server 2016以降であることに注意してください。使用するコードページは_65001_（通常、UTF-8 とバイトオーダーマークを意味します）ですが、SQL Serverがこれらのケースでバイトオーダーマークを必要とするかどうかはわかりません）。
ファイルをASCIIにエクスポートすると、問題なく動作しました。