2
4

4 に答える 4

6

私の場合、CODEPAGE オプションを使用してエンコードの問題を修正できます。

BULK
INSERT #CSV
FROM 'D:\XY\xy.csv'
WITH
(
   CODEPAGE = 'ACP',
   DATAFILETYPE ='char',
   FIELDTERMINATOR = ',',
   ROWTERMINATOR = '\n',
   FIRSTROW = 2
)

可能な値: CODEPAGE = { 'ACP' | 'OEM' | '生' | 'code_page' } ]

オプションの詳細については、こちらを参照してください: BULK INSERT

于 2016-03-03T10:00:24.067 に答える
3

コメントで答えました。やってみましたか？

http://msdn.microsoft.com/en-us/library/ms189941.aspx

オプションDATAFILETYPE='widenative'

Esailigaからのコメントに基づいて、一括インポートの前または後にテキストが切り捨てられましたか。CSVファイル自体が1バイトのように聞こえることに同意します。Unicodeには、オプションDATAFILETYPE='widenative'が必要です。CSVファイルが1バイトの場合、マジックトランスレーションバックではありません。

残念なことに、éは拡張ASCIIであり、SQL文字でサポートされているため、問題がCSVにあるという証拠が増えています。
SELECT CAST（'é'ASchar（1））
これは拡張ASCII（<255）として機能することに注意してください

ソースに戻る必要があるようです。

？SQLでは不明です。メモ帳の�と同じです。

于 2012-12-19T16:18:07.043 に答える
1

何年もの間、Microsoft がこの明らかなバグを修正していないことが、今でも信じられません。èéêë などはすべて ascii(<255) なので問題ないはずです。このクエストは多くのサイトで何度も何度も提起されており、その質問はまだ答えられていません

私のデータはExcelのテーブルにあります。ステートメントへの挿入を生成すると、テーブルが 2 回目に解析され、asccii > 'z' が検索され、テーブル セット列ステートメントが生成および更新され、インポートされたデータが上書きされます。面倒だが実行可能

于 2015-07-06T13:54:43.027 に答える
1

やりました！何年もの間、私たちは皆、間違った場所を探していました。作業は必要ありません。スクリプトを書き直す必要はありません...

問題はSSMSにあります...「クエリ」を右クリックして「新しいクエリ」を実行すると、ファイルの名前を変更できますが、作成することはできません...

しかし...「Ctrl + N」を押すと、編集する新しいクエリウィンドウが表示されますが、ファイルは作成されません...したがって、自分で保存し、保存ボタンでエンコードを選択します...リストの一番下に向かってUTF-8 (署名なし) コードページ 65001 を見つけます

そして、それだけです...

スクリプトを次々と実行し、"ctrl+N" を使用して新しいクエリ ウィンドウを開き、既存のクエリからコピー アンド ペーストして、上記の手順に従って保存します。そしてまるで魔法のように

私のようにExcelにテーブルがある場合...テーブルを解析して、出力を1シートの新しいワークブックの1列目に書き込み、次に保存してutf-8エンコーディングを選択します

「-- utf-8」などのコメントを含むテンプレート ファイルを使用して処理を高速化します。utf-8 として保存し、Excel に貼り付けられた *.sql のファイル リストを使用して、b1 で =concatenate("ren templatefile.txt ", char(34), a1, char(34)) のリストを連結し、ドロップします。下

何年にもわたって手動で解決してきた結果、私は文字通り、発見に興奮して汗をかきました。私をとても動揺させてくれてありがとう

于 2015-07-06T15:18:42.173 に答える