Hello!

Есть DBF в котором одна колонка на корейском языке в 949-ой кодовой странице и нужно эту табличку со всеми колонками залить в SQL 2005. Пробовал в SSIS через OLE DB провайдеры для Foxpro и Jet 4, CP везде проставил 949, но конвертируется колонка одинаково неправильно. Тот же результат при импорте в Access и Excel: └╧╣▌┴Ў┐к.

Jet 4 оказался гораздо резвее и он сразу выдавал WSTR вместо STR, Поэтому я остановился в итоге на нём.
Выставил конекшн стринг с указанием корейской CP: "Data Source=C:\Work\Data\CATALOG_TEXT\;Provider=Microsoft.Jet.OLEDB.4.0;Extended Properties=dBASE IV;Locale Identifier=949;"

Проблема лечится, если в виндовой панели управления в "Regional and Language options" on Advanced tabstrip: "language version of the non-Unicode programs" поставить корейскую CP и перегрузить винды (у меня Win2003 Server). Тогда Access, Excel и SSIS правильно конвертируют корейское поле в юникод и всё OK.

Неужели никак нельзя настроить OLE DB провайдер, чтобы он правильно конвертил 949-ю CP в юникод?

Thanks and good luck!

Спасибо!

Понять-то не сложно. При открытии этого DBF в Foxpro колонка рендерится неправильно, но если в виндовой панели управления выставить карейскую кодовую страницу для non-unicode applications и перегрузить винды (WIn srv. 2003), то Foxpro показывается там корейские иероглифы. Правильность я проверил скопировав образцы в http://www.google.ru/language_tools?hl=ru
и подсунув их переводчику Корейский-->английский.
Однако напрямую оно через клипбоард не копируется: сначала это добро надо вставить в Notepad, а из него уже в переводчик.

Кстати: Foxpro у меня 6-ой (от 6-ой студии), и на нём стоит SP5 для студии.

Я не понимаю почему сам Fox использует неправильную CP. Ведь она же прописана в DBF.

рендерится = показывается

показывается она правильно только если виндам поставить Корейскую non-unicode CP

Settings. COntrol Panel. Regional and Language Options. Advanced

Тесть - сам-то DBF содержит property с 949 CP, но все: Foxpro 6, OLE DB prov. для Fox 9, OLE DB prov. для Jet 4 - игнорируют его. Они перекодируют расширенные символы ASCII используя системную CP для non-unicode приложений.

И я не нашёл способа заставить их использовать нужную мне CP.

Короче, мне надо правильно прочитать эти данные из DBF и заимпортить в MS SQL 2005 в поле типа NVARCAHR, поэтому я решил проблему следующим образом:

законнектился к DBF через OLE DB Provider for Jet 4.0 при помощи следующей строки:

connectionString="Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\Work\CATALOG_TEXT\;Persist Security Info=False;Extended Properties=dBASE 5.0;"

Прочитав данные в DataTable при помощи TableAdapter (.Net 2.0 / C#; WInForms app) я выполнил следующую процедуру конверсии:

private void Form1_Load(object sender, EventArgs e)
{
this.bi02ctlvTableAdapter.Fill( this.xxxDs.bi02ctlv );


//HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engines\Xbase\DataCodePage = ANSI
//1251

//HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engines\Xbase\DataCodePage = OEM
//866
ConvertAsciiToUnicode( xxxDs.bi02ctlv, "area_name", 1251, 949 );
}

static private void ConvertAsciiToUnicode( DataTable tbl, String fieldName, Int32 rawEnc, Int32 unicodeEnc )
{
Encoding srcEnc = ASCIIEncoding.GetEncoding( rawEnc );
Encoding dstEnc = ASCIIEncoding.GetEncoding( unicodeEnc );
Int32 idx = tbl.Columns.IndexOf( fieldName );

foreach( DataRow row in tbl.Rows )
{
Byte[] mbcs = srcEnc.GetBytes( (String)row[idx] );
String res = dstEnc.GetString( mbcs );
row[ idx ] = res;
}
}

При этом в реестре я выставил HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engines\Xbase\DataCodePage = ANSI

И всё стало OK! Я получил правильный Unicode.