CSVファイルのロードを実行した後、データベースに誤って「書き込まれた」さまざまな単語があります。
いくつかの例:
Diã¡ria
はDiária
Crã©dito
はCrédito
Ligaã§ãµes
はLigações
Usuã¡rio
はUsuário
Nãºmeros
はNúmeros
シンボルを正しい文字に変換する方法はありますか?
インターネットを検索できるcollations
とfunctions
を使っていくつかのテストを行いましたが、成功しませんでした。
データベースに誤って「書き込まれる」さまざまな単語があります。
いいえ、文字は read が誤って読み取られています。それらは正しく書かれています。または、これを確認する別の方法は、文字が data file に誤って書き込まれていることです。どちらの方法でも、SQL Serverは要求されたとおりのことを実行しています。
これは単純なエンコーディングの問題です。データは元々UTF-8としてエクスポートされていましたが、そのUTF-8でエンコードされたファイルは、コードページ1252を使用して拡張ASCIIファイルであるかのようにSQL Serverに読み込まれました。これが問題であることを示します。
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
にエクスポートすると、問題なく動作しました。