SQL Server 2008 заменяет символы Unicode

Я только что завершил проект, в котором я объединил данные из 34 ненормализованных источников данных в одну нормализованную базу данных SQL Server 2008.

Единственная проблема заключается в том, что текстовые поля большего размера из этих источников данных потеряли некоторую достоверность и теперь везде отображают управляющие символы Unicode (многие из них).

Это код, который я использовал для импорта данных из одного из файлов *.txt с разделителями табуляции:

BULK INSERT MyTabeNameHere
        FROM 'C:\FILE\PATH\HERE\FileNameHere.txt'       
        WITH
        (
            FIELDTERMINATOR = '\t',
            ROWTERMINATOR = '\n',
            FIRSTROW = 2
        )

Примерные данные могут быть:

Lorem ipsum ò dolor sit amet
ááá Lorem ipsum dolor sit amet
Lorem ipsum dolor sit amet
Lorem ipsumû dolor sit amet
Lorem ipsum dolor sit aÆmet

Я хотел бы запустить эти данные через функцию SQL и вывести это...

Желаемый результат:

Lorem ipsum dolor sit amet
Lorem ipsum dolor sit amet
Lorem ipsum dolor sit amet    
Lorem ipsum dolor sit amet
Lorem ipsum dolor sit amet

Заранее спасибо!


sql sql-server tsql sql-server-2008
person s15199d    schedule 20.09.2012    source источник
comment
текстовые файлы «потеряли точность»? Если вы изобретаете свои собственные термины, как мы должны понять, что вы имеете в виду?   -  person Remus Rusanu    schedule 20.09.2012
comment
Ремус синонимом «верности» является «точность». tinyurl.com/bu5yxbb   -  person s15199d    schedule 20.09.2012
comment
Может быть полезно привести примеры вашего ввода и неправильного вывода.   -  person Tim Lehner    schedule 20.09.2012
comment
вопрос: файл поврежден или вы его читаете с неправильной кодировкой? Ваша терминология не делает его более ясным.   -  person Remus Rusanu    schedule 20.09.2012
comment
Проверить проблемные файлы? Используют ли они только \n (не \r\n)? Массовая вставка может стать симпатичной и добавить в \r\n. Попробуйте символ (10).   -  person paparazzo    schedule 20.09.2012
comment
Это не управляющие символы Unicode. 'a' и 'á' являются символами Unicode. Под потерянной точностью вы подразумеваете, что BULK INSERT вставляет эти дополнительные символы, а их нет в файле? Я не куплюсь на это.   -  person paparazzo    schedule 21.09.2012

Ответы (1)


arrow_upward
0
arrow_downward

Существуют и другие параметры массовой вставки, которые могут помочь в этой ситуации, например в виде:

DATAFILETYPE = 'widechar' -- and others

or

CODEPAGE = 'ACP' -- and others

Когда перенося свои массовые операции с SQL 2000 на 2008, мне пришлось отказаться от использования файла форматирования и включить широкоформатные символы в качестве опции, чтобы получить правильный вывод. Однако я недостаточно знаком с вашим затруднительным положением, чтобы знать, сработает ли это для вас.

[...] 34 ненормализованных источника данных [...]

Как упоминается в объемной документации, важно знать типы файлов, которые вы читаете (ascii, ansi и т. д.).

person Tim Lehner    schedule 20.09.2012
comment
Я уже прошел точку повторного импорта данных. Что я хочу сделать, так это обновить данные, уже находящиеся в базе данных. Даже если это заменяет управляющие символы Unicode на ''. Я бы предпочел заменить их предполагаемым символом, но заменить на '' - это вариант B. - person s15199d; 20.09.2012
comment
Если вы не будете повторно импортировать данные, используя правильную кодировку, вам, вероятно, придется угадывать символы замены, вручную сверяя часть данных с источником, а затем выполняя специальные запросы replace с использованием ascii, char, nchar и unicode, пока не будет довольный. @Blam может быть прав в поиске символов новой строки. - person Tim Lehner; 20.09.2012
comment
@TimLehner Я подозреваю, что кодировка была правильной, поскольку это обычные символы иностранного языка. Я имею дело с этим все время, и в .NET есть простое преобразование, но он настаивает на функции SQL, и МАССОВЫЙ ИМПОРТ каким-то образом вызвал эту потерю точности. - person paparazzo; 21.09.2012