Введение

Продукт IBM InfoSphere Federation Server, входящий в состав инфраструктуры интеграции информации, представляет собой гибкое решение для интеграции большого числа гетерогенных источников данных и единообразного представления доступа к данным в виде сервиса.

Преобразование кодовой страницы может произойти в любом звене цепочки от дистанционно расположенного источника данных до базы данных IBM DB2® и от базы данных до конкретного приложения DB2. Высокая сложность системной среды, в которой установлены гетерогенные источники данных, приводит к тому, что обертки Federation Server используют различные стратегии и реализации, соответствующие специфике задействованных источников данных. Таким образом, вам необходимо сконфигурировать преобразование кодовых страниц в соответствии со своей реальной средой. Кроме того, в отличие от европейских и американских клиентов, восточно-азиатские клиенты обычно используют Unicode или другие многобайтовые наборы символов, что усложняет конфигурирование преобразования кодовых страниц.

В предлагаемой статье сначала излагается применяемая в продукте Federation Server концепция преобразования кодовых страниц в среде с несколькими наборами символов. Затем описываются различные конфигурации преобразования кодовых страниц, соответствующие различным оберткам и источникам данных (таким как DRDA, Oracle, ODBC и т.д.). И, наконец, статья отвечает на некоторые общие вопросы о преобразовании кодовых страниц при использовании продукта Federation Server.

В начало

Понятие о преобразовании кодовых страниц в продукте InfoSphere Federation Server

Продукт InfoSphere Federation Server имеет дело со следующими категориями кодовых страниц: кодовая страница, заданная в локали (региональных настройках) операционной системы (ОС), кодовая страница клиентского приложения DB2, кодовая страница базы данных DB2, кодовая страница клиента дистанционно расположенного источника данных и кодовая страница дистанционно расположенной базы данных.

• OS locale (локаль ОС): Параметр уровня ОС, который задает кодовую страницу по умолчанию для системы управления базами данных и для приложений.
• DB2CODEPAGE (кодовая страница СУБД DB2): Переменная реестра на клиентской машине, которая задает кодовую страницу на уровне экземпляра СУБД; влияет на все приложения, исполняющиеся на этой клиентской машине.
• Database codepage (кодовая страница базы данных): Кодовая страница на уровне базы данных. Для DB2 версии 9.5 (и выше) по умолчанию используется кодовая страница 1208, однако при создании базы данных вы можете в явном виде задать кодовую страницу (с помощью выражения USING CODESET). После успешного создания базы данных ее кодовая страница никогда не меняется. Например, для создания базы данных с кодовой страницей GBK можно использовать следующее SQL-выражение:

  CREATE DATABASE <database_name> USING CODESET GBK TERRITORY CN

  
  

В качестве центрального элемента распределенной архитектуры гетерогенных источников данных продукт Federation Server обеспечивает более гибкие функции преобразования кодовых страниц. На рис. 1 показана вся инфраструктура преобразования кодовых страниц в продукте InfoSphere Federation Server.

На рис. 1 показан поток данных от дистанционно расположенной базы данных до клиентского приложения. Каждая двунаправленная стрелка представляет собой возможный процесс преобразования кодовой страницы, на который оказывают влияние различные параметры. Обычно преобразование кодовой страницы происходит в получателе данных. Например, если клиентское приложение DB2 запрашивает данные у Federation Server, то ответственность за преобразование кодовой страницы несет клиент. Обратное также справедливо.

Преобразование кодовой страницы зависит от клиента/сервера дистанционно расположенного источника данных

Для осуществления преобразований кодовых страниц в источнике данных (что может обеспечить более мощные возможности) в продукте Federation Server проводятся следующие два принципа:

• С точки зрения источника данных продукт Federation Server действует как клиентское приложение источника данных. Обертки связывают Federation Server и дистанционно расположенный источник данных посредством вызова клиентских API-интерфейсов источника данных.
• Соблюдение правил преобразования кодовой страницы дистанционно расположенного источника данных реализуется посредством установки определенных параметров файла db2dj.ini для соответствующих оберток.

В качестве примера рассмотрим обертку для Oracle.

Процесс преобразования набора символов оберткой Oracle определяется источником данных Oracle. Для установки определяемого локалью поведения на стороне клиента и на стороне сервера Oracle используются т.н. «NLS-параметры». Имеется около 20 NLS-параметров, описывающих различные области NLS (поддержка национальных языков), в том числе NLS_LANG, NLS_DATE_FORMAT, NLS_TIMESTAMP_FORMAT, and NLS_CURRENCY.

Специфицирование NLS-параметров может осуществляться следующими способами (в порядке старшинства):

• С помощью инициализационного параметра на сервере
• С помощью переменной среды на клиенте
• С помощью утверждения ALTER SESSION
• В SQL-функциях

Самым важным NLS-параметром, используемым в Federation Server, является параметр NLS_LANG, который задается как переменная среды на клиенте Oracle. В параметре NLS_LANG для специфицирования языка, территории и набора символов применяется следующий синтаксис:

NLS_LANG = language_territory.charset

С точки зрения Oracle продукт IBM Federation Server функционирует как клиентское приложение Oracle. Вследствие этого присвоение значения параметру NLS_LANG, который представляет собой переменную среды Oracle-клиента, является обязательным условием – оно гарантирует, что Oracle выполнит необходимое преобразование кодовой страницы между базой данных Federation Server и сервером Oracle.

Oracle-обертка продукта Federation Server имеет необязательный параметр NLS_LANG, который находится в его конфигурационном файле db2dj.ini. Параметр NLS_LANG имеет такой же формат, как было описано выше. Значение этого параметра должно быть установлено в соответствии с такими настройками базы данных Federation Server, как набор символов, язык и территория. Если параметр NLS_LANG не будет указан в файле db2dj.ini явным образом, то Oracle-обертка продукта Federation Server настроит эту переменную среды согласно значениям кодовой страницы базы данных Federation Server (в процессе настройки соединения с сервером Oracle).

Например, если база данных Federation Server имеет кодовую страницу GBK, а база данных Oracle Server имеет кодовую страницу UTF8, то для территории «cn» значение параметру NLS_LANG может быть присвоено следующим образом:

NLS_LANG=Simplified Chinese_China.ZHS16GBK.

Компоненты параметра NLS_LANG, отвечающие за язык и территорию, определяют значения по умолчанию и для других детализирующих NLS-параметров, таких как формат даты, числовые символы и т.д. Кроме того, эти детализирующие переменные NLS-среды могут быть установлены в файле db2dj.ini, при этом они будут иметь преимущество над значениями по умолчанию параметра NLS_LANG.

Продукт Federation Server использует только одну разновидность формата date/timestamp (дата/метка времени) и устанавливает переменные среды следующим образом (в процессе настройки удаленного соединения):

NLS_TIMESTAMP_FORMAT=YYYY-MM-DD HH24:MI:SS.FF
NLS_DATE_FORMAT=YYYY-MM-DD HH24:MI:SS

По указанной причине значения date/timestamp в других форматах (например, в формате 20-MAY-2009) будут обрабатываться некорректно.

Преобразование кодовой страницы зависит от оберток продукта InfoShpere Federation Server

Продукт InfoSphere Federation Server помогает осуществлять преобразование кодовых страниц между локальной базой данных и некоторыми источниками данных, которые не в состоянии сами осуществить такое преобразование или имеют ограничения на это преобразование. Например, если вы хотите федерировать структурированный в виде таблиц файл, то вы должны осознавать, что этот файл не имеет никаких возможностей для осуществления преобразований кодовых страниц. К счастью, это может сделать обертка файла – посредством задания необязательного псевдонима CODEPAGE для номера кодовой страницы дистанционно расположенного файла.

Преобразование кодовых страниц в сложных ситуациях

Некоторые обертки, например, ODBC-обертка InfoSphere Federation Server, способны осуществлять гибкое преобразование кодовых страниц между федерированной базой данных и дистанционными источниками данных. В качестве примера рассмотрим обертку для Oracle.

Эта обертка способна поддерживать все источники данных, соответствующие стандарту ODBC 3.0. Поэтому она может использоваться для федерирования некоторых мощных реляционных источников данных, таких как PostgreSQL, и некоторых нереляционных источников данных, таких как текстовые файлы. Таким образом, преобразование кодовой страницы может быть осуществлено оберткой ODBC, менеджером ODBC-драйверов, ODBC-драйвером дистанционно расположенного источника данных, клиентом или сервером дистанционно расположенного источника данных.

Предположим, что клиентское приложение DB2 запрашивает данные из дистанционно расположенного источника данных. Необходимо рассмотреть следующие четыре этапа этого потока данных:

• От дистанционно расположенного сервера источника данных до клиента: Например, в PostgreSQL преобразование кодовых страниц между клиентом и сервером можно сконфигурировать посредством настройки параметра PostgreSQL на стороне сервера.
• От клиента дистанционно расположенного источника данных до ODBC-драйвера: Например, в Classic Federation Server кодовую страницу клиента и сервера можно установить в соответствующем файле конфигурации ODBC на стороне клиента.
• От ODBC-драйвера до менеджера драйверов: Например, разработанный IBM менеджер ODBC-драйверов под названием DataDirect способен сам осуществлять преобразование кодовых страниц между менеджером драйверов и собственно ODBC-драйвером – посредством использования Unicode- приложения с не-Unicode драйвером или не-Unicode приложения с Unicode- драйвером. Более подробная информация по настройке параметра IANAAppCodePage при использовании разработанного IBM менеджера ODBC-драйверов DataDirect приведена на Web-сайте DataDirect (см. раздел Ресурсы).
• От менеджера драйверов до ODBC-обертки: ODBC-обертка компенсирует недостаточные возможности менеджера драйверов или драйвера, неспособного осуществить необходимое преобразование.

Преобразование кодовых страниц зависит от клиентского приложения DB2

Продукт InfoSphere Federation Server способен обеспечить прозрачный доступ к гетерогенным источникам данных, поэтому клиентскому приложению нет необходимости учитывать, сколько преобразований кодовых страниц было осуществлено всей системой Federation Server. Обычно для клиентского приложения DB2 кодовая страница по умолчанию определяется локалью (региональными настройками) клиентской ОС. Однако в некоторых случаях кодовая страница необходимого пользователям клиентского приложения не соответствует локали ОС. Для изменения кодовой страницы пользователи могут настроить переменную реестра DB2CODEPAGE. Кроме того, существуют специальные настройки для клиентских приложений Java™. В качестве примера рассмотрим приложение DB2 Control Center.

Во многих случаях графический интерфейс пользователя DB2 сообщает, что Control Center не в состоянии отобразить некоторые Unicode-символы (например, китайские и японские), хотя кодовая страница источника данных на стороне клиента и на стороне сервера, а также кодовая страница Federation Wrapper были настроены корректно. Эти символы могут быть корректно отображены в командном окне, но не в приложении Control Center. Чтобы лучше понять эту разновидность проблем, сначала рассмотрим некоторые соответствующие настройки кодировки в Java-приложении.

Кодировка по умолчанию в JVM

Каждый экземпляр JVM (виртуальная машина Java) имеет кодировку файлов по умолчанию, которая устанавливается в момент запуска JVM в соответствии с локалью и кодовой страницей операционной системы. Сведения о кодировке JVM по умолчанию можете получить с помощью следующей команды:
encoding=System.getProperty("file.encoding");

Компилятор Javac способен прочитать исходный файл в соответствии с кодировкой по умолчанию и затем обработать его с использованием Unicode. Unicode также используется в процессе исполнения Java-приложения, а кодировка JVM по умолчанию используется для чтения входных и записи выходных данных этого приложения.

Если входные/выходные данные этого Java-приложения должны быть прочитаны/записаны в иной кодировке (отличающейся от соответствующего значения параметра file.encoding), можно использовать какой-либо Java-класс ввода/вывода, например, java.io.InputStreamReader, java.io.FileReader, java.io.OutputStreamReader, java.io.FileWriter, java.lang.String. Эти классы поддерживают использование значения кодировки, которое имеет преимущество над кодировкой JVM по умолчанию (см. рис. 1).

public static final String TEST_STRING = "北京";
     public static void testEncoding() {
          try {
               byte[] bytes = TEST_STRING.getBytes("GB18030");
               String result = new String(bytes, "GB18030");
               System.out.println("Receive value: [" + result + "].");
          } catch (UnsupportedEncodingException e) {
               // TODO Auto-generated catch block
               e.pringStackTrace();
          }
}

В выражении new String(bytes,encode) чтение и трансляция байтов осуществляется согласно значению encode, а выражение new String(bytes) будет использовать кодировку JVM по умолчанию для побайтового чтения данных. При обработке в Java-приложении все эти данные должны быть переведены в Unicode. Таким образом, имеет место преобразование «байты-кодирование-Unicode», а в выражении String.getBytes(encode) данные преобразуются в поток «Unicode-кодирование-байты».

Java-приложение и база данных

В листинге 2 показан пример использования технологии Java для доступа к базе данных.

System.out.println("File.encoding"=System.getProperty("file.encoding"));
stmt = conn.createStatement(); 
ResultSet resultSet = stmt.executeQuery("SELECT * FROM my_table"); 
 while (resultSet.next()) { 
    String s = resultSet.getString(1); 
    System.out.println(s);
    
    //the hex value of s
    String hexs=";
    byte[] bytes = s.getBytes(); 
    for (int i = 0; i < bytes.length; i++) {
      	String hex = Integer.toHexString(bytes[i] & 0xFF);
      	if (hex.length() == 1) {
        hex = '0' + hex;
      	}
      	hexs += hex.toUpperCase();
    }//for
    System.out.println(hexs);        
 } //while  

В таблице 1 показана выходная информация, получаемая пользователем после исполнения вышеуказанной программы при различных кодировках JVM.

Если в JVM по умолчанию применяется кодировка GB18030, то полученные из базы данных данные будут прочитаны Java-программой в кодировке GBK. Если в JVM по умолчанию применяется кодировка ISO8859-1, то передача данных приложению будет осуществляться побайтно в кодировке ISO8859-1, после чего они будут транслироваться из ISO8859-1 в Unicode с помощью внутреннего Java-класса. Однако кодовая страница ISO8859-1 не имеет символов для китайского языка, поэтому в результате вы получите символ Chaos («хаос»).

Как известно, если в операционной системе применяется кодовая страница ISO8859-1, то полученный из базы данных китайский символ не может быть транслирован в байтовую кодировку с помощью формата кодировки операционной системы, в результате чего в командном окне будет отображен символ Chaos. Решение этой проблемы состоит в установке кодовой страницы GBK для клиента DB2 с помощью команды db2set.

Однако попытка использовать задаваемые с помощью команды db2set переменные для решения проблемы символов Chaos в Java-приложении показала свою непрактичность. Преобразование кодовых страниц в Java-приложении зависит только от применяемых кодировок. Таким образом, необходимо рассмотреть факторы, которые могли бы повлиять на кодировку JVM при попытке решения этой проблемы.

В общем случае для решения этой проблемы существует два способа. Первый способ состоит в том, чтобы изменить кодировку JVM по умолчанию на кодировку с поддержкой китайского или японского языка, такую как GB18030. Кодировка JVM по умолчанию зависит от кодировки операционной системы, поэтому если Вы хотите отображать китайские символы, вам нужно будет изменить локаль операционной системы на китайскую. Второй метод предполагает, что вы не будете изменять локаль операционной системы. В этом случае вам нужно «преодолеть» кодировку по умолчанию посредством добавления опций кодировки на этапе компиляции и исполнения своего приложения.

Применительно к вышеупомянутой программе, у которой в JVM по умолчанию применялась кодировка ISO8859-1, компиляцию и исполнение можно осуществить следующим образом:

javac -encoding GB18030 testEncoding3.java
java -Dfile.encoding=GB18030 testEncoding3.class

Теперь проверьте выходную информацию этой программы. Вы увидите, что кодировка в этой программе была заменена установленной вами.

File.encoding=GB18030
北京
B1B1BEA9
中国
D6D0B9FA

Java-приложение и федерированная база данных

У вас может возникнуть вопрос: В чем заключается различие между непосредственным обращением к данным в дистанционном источнике данных и доступом к этим же данным по их псевдонимам в федерированной базе данных? Для ответа на этот вопрос мы выполнили несколько тестов с использованием программного кода, показанного в листинге 4.

System.out.println(System.getProperty("file.encoding"));
stmt = conn.createStatement(); 
ResultSet resultSet = stmt.executeQuery("SELECT * FROM my_table"); 
while (resultSet.next()) { 
    String s = resultSet.getString(1); 
    System.out.println(s);
    
    //the hex value of s
    String hexs=";
    byte[] bytes = s.getBytes(); 
    for (int i = 0; i < bytes.length; i++) {
      	String hex = Integer.toHexString(bytes[i] & 0xFF);
      	if (hex.length() == 1) {
        hex = '0' + hex;
      	}
      	hexs += hex.toUpperCase();
    }//for
    System.out.println(hexs);        
 } //while  

Предположим, что кодовая страница федерированной базы данных – GBK, кодовая страница дистанционного источника данных – UTF8, и что в федерированной базе данных создан псевдоним «my_nick» для таблицы «my_table» в дистанционно расположенной базе данных.

Использование тестового программного кода позволяет увидеть, что байтовые данные, читаемые с помощью псевдонима, представлены в кодировке GBK, а эти же данные, читаемые непосредственно из дистанционной базы данных, представлены в кодировке UTF8. Таким образом, если Java-приложение посещает дистанционную базу данных с помощью Federation Server, ему не нужно беспокоиться о кодовой странице дистанционной базы данных. В этом сценарии сначала это приложение транслирует данные из кодировки GBK в кодировку машины JVM, а затем JVM выполняет перевод из кодировки GBK в кодировку Unicode.

Символ Chaos в Java-приложении на базе Swing

В отличие от обычных Java-приложений, показанных выше, пакет Swing обеспечивает улучшенную поддержку символов Unicode. Он не требует ни перестройки локали операционной системы на китайский или японский язык, ни «переписывания» кодировки JVM в процессе исполнения. Он способен отображать эти символы при условии, что в системе установлены и корректно настроены все необходимые шрифты. Приложение Control Center базируется на Swing. Это позволяет отображать символы Unicode (включая DBCS) в DB2 Control Center при работе в англоязычной среде.

Несмотря на улучшенную поддержку символов Unicode, таких как китайские, проблема «хаоса» может возникнуть и в приложениях на базе Swing. Существует двухступенчатое решение этой проблемы:

• Проверьте файл <installpath>\SQLLIB\java\jdk\jre\lib\ font.properties, который содержит отображение логических Java-шрифтов на физические, и убедитесь в том, что это отображение настроено корректно.
• Убедитесь в существовании физических шрифтов. Как правило, они должны быть установлены в каталоге шрифтов операционной системы, в каталоге Java 2 SDK с именем jre/lib/fonts или в каталоге JRE с именем lib/fonts. Если физические шрифты отсутствуют, их необходимо вручную установить их в систему.

Сводная информация по всем оберткам и источникам данных

В таблице 2 приведена сводная информация по различным оберткам и источникам данных.

В начало

Выявление проблем с преобразованием кодовых страниц при использовании продукта Federation Server

Причины получения ошибки SQL0332N при использовании DB2 CLP для подключения к базе данных GBK

Причина этой ошибки состоит в том, что клиентское приложение DB2 использует кодовую страницу ISO8859-1(819), а федерированная база данных использует кодовую страницу GBK (1386). Для решения этой проблемы существуют следующие два способа.

• Присвоить переменной DB2COPDEAGE такую же кодовую страницу (1386), как у федерированной базы данных.
• Не настраивать переменную DB2CODEPAGE, но изменить локаль ОС с целью введения поддержки китайских символов.

Почему приложение DB2 Control Center отображает аномальные шрифты?

Причина состоит в том, что пользователь неправильно настроил отображение логических шрифтов Java в физические шрифты, или в том, что соответствующие физические шрифты не установлены в операционной системе. Для получения дополнительной информации обратитесь к разделу Ресурсы.

Причины получения символа Chaos при подключении к серверу Oracle с кодовой страницей UTF8 со стороны базы данных Federation Server с кодовой страницей GBK

В отличие от Oracle Server в базе данных Federation Server используется кодовая страница GBK.

Таблица T1 (C1 varchar(10)) определена в продукте Oracle Server и содержит две строки китайских символов в кодировке UTF8, которые означают China и Beijing соответственно. В листинге 5 показано содержимое таблицы t1 и UTF8- кодировка двух китайских слов.

SQL> select * from t1;

C1
----------
中国
北京

SQL> select dump(C1,16) from t1;

DUMP (C1,16)
---------------------------------------
Typ=1 Len=6: e4,b8,ad,e5,9b,bd
Typ=1 Len=6: e5,8c,97,e4,ba,ac

Вы должны настроить NLS-параметр NLS_LANG следующим образом: NLS_LANG=Simplified Chinese_China.UTF8. Для получения значения NLS-параметра Oracle воспользуйтесь командой select userenv('language') from dual, после чего установите его значение в файле db2dj.ini в виде NLS_LANG=Simplified Chinese_China.UTF8.

SQL> select userenv('language') from dual;

USERENV('LANGUAGE')
----------------------------------------------
SIMPLIFIED CHINESE_CHINA.UTF8

Выберите в продукте Federation Server псевдоним N1 для дистанционно расположенной таблицы t1 в Oracle. Вы получите некорректную кодировку для UTF8-данных. Параметру NLS_LANG в файле db2dj.ini была присвоена кодовая страница UTF8, поэтому никакого преобразования кодовых страниц между Oracle-клиентом и Oracle-сервером не происходит. Таким образом, получение китайских слов в кодировке UTF8 на стороне Federation Server осуществляется без изменения кодовой страницы, в результате чего они отображаются некорректно, поскольку фактически ожидается поступление GBK-символов.

=> db2 "select * from N1"

C1
----------
涓浗
鍖椾含

  2 record(s) selected.

=> db2 "select hex(C1) from N1"

1
--------------------
E4B8ADE59BBD
E58C97E4BAAC

  2 record(s) selected.

После изменения параметра NLS_LANG в файле db2dj.ini, как показано на рис. 8, и перезапуска DB2 поступающие от сервера Oracle символы в кодировке UTF8 будут корректно преобразовываться в GBK-символы.

=> db2 "select * from N1"

C1
----------
中国
北京

  2 record(s) selected.

=> db2 "select hex(C1) from N1"

1
--------------------
D6D0B9FA
B1B1BEA9

  2 record(s) selected.

Таким образом, параметр NLS_LANG в файле sqllib/cfg/db2dj.ini должен быть установлен в соответствии с форматом параметра Oracle NLS_LANG – по существу, этот параметр является переменной среды Oracle; Oracle рассматривает его в качестве значения кодовой страницы на стороне Oracle-клиента при преобразовании кодовой страницы. Однако содержимое параметра NLS_LANG определяется настройкой кодовой страницы базы данных Federation Server.

В начало

Заключение

Преобразование кодовых страниц в продукте InfoSphere Federation Server при работе с гетерогенными источниками данных зависит от нескольких конфигурационных настроек – в DB2, в Federation Server, в клиенте источника данных и в сервере источника данных. Продукт Federation Server поддерживает различные методы для конфигурирования этих настроек в соответствии с требованиями источника данных. Статья объясняет, как продукт InfoSphere Federation Server работает в многоязычной среде, и предлагает практические способы решения проблем, часто встречающихся при использовании этого продукта. Располагая этой информацией, вы сможете легко получать доступ к данным, находящихся в источниках данных с разными кодовыми страницами.

Ресурсы

Научиться

• Оригинал статьи Understanding InfoSphere Federation Server codepage conversion (EN).
  
  
• IBM Federated Database Technology (EN) (Технология федерированных баз данных IBM), developerWorks, март 2002 г. Дополнительные сведения о технологии IBM, которая позволяет клиентам механизма федерирования баз данных получать и интегрировать нужные данные, а также пользоваться специализированными вычислительными возможностями разнообразных реляционных и нереляционных источников данных.
  
  
• Understanding DB2 Universal Database character conversion (EN) (Преобразование символов в DB2 Universal Database), developerWorks, июнь 2005 г. Реализация преобразования символов в продукте DB2 for Linux, UNIX, and Windows.
  
  
• A brief introduction to code pages and Unicode (EN) (Краткое введение в кодовые страницы и Unicode), developerWorks, март 2000 г. Связь Unicode с кодовыми страницами, наборами символов и кодировками.
  
  
• How to display unicode characters (including DBCS) in DB2 Control Center on an English Windows environment (EN) (Как отобразить Unicode-символы (в т.ч. DBCS) в приложении DB2 Control Center при работе в англоязычной Windows-среде), IBM, ноябрь 2006 г. Техническая статья по отображению Unicode-символов.
  
  
• Web-сайт Data Direct (EN): Более подробная информация по настройке параметра IANAAppCodePage.
  
  
• Следите за мероприятиями и трансляциями по техническим вопросам на Web-сайте developerWorks (EN).
  
  

Получить продукты и технологии

• Используйте в своем следующем проекте по разработке Ознакомительное программное обеспечение IBM, которое можно загрузить непосредственно с сайта developerWorks.
  
  

Обсудить

• Примите участие в обсуждении материала на форуме.
  
  
• Читайте Блоги developerWorks (EN) и принимайте участие в жизни сообщества My developerWorks (EN) – используя личный профиль и настраиваемую начальную страницу, вы можете настроить ресурс developerWorks в соответствии со своими интересами и взаимодействовать с другими пользователями developerWorks.
  
  

Об авторах

Чэнь Ван (Chen Wang) является инженером по программному обеспечению в лаборатории IBM China Software Development Lab в Пекине. В настоящее время он работает в составе группы по совершенствованию продукта IBM InfoSphere Federation Server. Он обладает большим опытом по разработке и конфигурированию оберток.

Чжо Шао (Zhuo Shao) является инженером по программному обеспечению в лаборатории IBM China Software Development Lab в Пекине. В настоящее время он работает в составе группы по совершенствованию продукта IBM InfoSphere Federation Server. Он обладает большим опытом по разработке и конфигурированию оберток.

Фэн Фэн Лян (Feng Feng Liang) является инженером по программному обеспечению в лаборатории IBM China Software Development Lab в Пекине. В настоящее время она работает в составе группы по совершенствованию продукта IBM InfoSphere Federation Server. Она обладает большим опытом по разработке и конфигурированию оберток.

Оценить эту статью

Комментарии

В начало

Содержание

• Введение
• Понятие о преобразовании кодовых страниц в продукте InfoSphere Federation Server
• Выявление проблем с преобразованием кодовых страниц при использовании продукта Federation Server
• Заключение
• Ресурсы
• Об авторах
• Комментарии