Какую кодовую страницу / кодировку следует использовать для интерпретации данных, поступающих из системы MVS, в среду Java?

Я столкнулся с интересной проблемой (как это часто бывает при взаимодействии с устаревшими системами). Я работаю над приложением (которое в настоящее время работает в системе x86 Linux или Windows), которое может получать запросы от различных систем, одна из которых является системой MVS.

Я пытаюсь определить, какую кодовую страницу / кодировку я должен использовать для интерпретации данных запроса, поступающих из системы MVS.

Раньше я использовал cp500 (IBM-500) для интерпретации байтовой даты, поступающей для систем z / OS, однако я опасаюсь, что, поскольку MVS - это немного устаревшая система, и что, поскольку IBM, похоже, передумала в соответствии с тем, какую кодировку использовать (должны быть десятки кодировок EBCDIC), то cp500 может быть неправильной кодировкой.

Лучший ресурс, который я нашел по наборам символов в Java: http://mindprod.com/jgloss/encoding < / а>. Однако на этом сайте и в Инфоцентрах IBM я не смог получить четкого ответа.

РЕДАКТИРОВАТЬ: Добавлено из моего ответа на Pax ниже:

В моем вопросе была явная дыра в происхождении данных запроса. В этом случае источник данных - через интерфейс Websphere MQ. Websphere MQ имеет средства для преобразования в правильную кодировку, однако это только для чтения данных с помощью MQMessage.readString (), которая с тех пор устарела. Я бы предпочел использовать это, однако я использую проприетарный интерфейс, в котором я не могу изменить способ считывания сообщения из MQQueue, который считывает байты непосредственно из очереди, и, таким образом, я остаюсь обработчиком перевода.

Окончательный ответ: я хотел продолжить это. Оказывается, правильный набор символов действительно был cp500 (IBM-500). Однако у меня сложилось впечатление, что результаты могут отличаться. Несколько советов для тех, у кого такая же проблема:

Используйте Charset.availableCharsets () ;. Это даст вам карту поддерживаемых наборов символов во время выполнения. Я прошел через эти наборы и распечатал свои байтовые данные, переведенные в этот набор символов. Хотя это не дало мне ответа, который я хотел (в основном потому, что я не мог читать данные по мере их поступления), я полагаю, что это может быть полезно для других.

Обратитесь к: http://mindprod.com/jgloss/encoding для получения списка поддерживаемых наборов символов.

Наконец, хотя я не подтвердил это, но убедитесь, что вы используете правильную JRE. Я думаю, что IBM Runtime поддерживает больше наборов символов EBCDIC, чем OpenJDK или Sun Runtime.


java encoding character-encoding zos codepages
person user100645    schedule 04.05.2009    source источник
comment
Эндрю, availableCharsets () сообщит вам, что вы можете обработать, но не укажет, какой из них вы должны использовать для определенного набора данных. Вам все равно нужно это выяснить, иначе ваша конверсия вернет мусор. Но насчет IBM JRE вы правы - в нем есть дополнительные возможности для z / OS.   -  person paxdiablo    schedule 04.05.2009

Ответы (1)


arrow_upward
3
arrow_downward

«MVS - это немного устаревшая система»? Ха! Это по-прежнему предпочтительная ОС для приложений, в которых надежность является проблемой номер один. Теперь к вашему вопросу :-)

Это полностью зависит от того, что генерирует данные. Например, если вы просто загружаете файлы с хоста, согласование FTP может обработать это. Но поскольку вы упомянули Java, он, вероятно, подключается через JDBC к DB2 / z, и драйверы JDBC справятся с этим довольно хорошо (гораздо лучше, если вы используете собственную JRE от IBM, а не версию Sun).

Сам EBCDIC на хосте имеет довольно много разных кодировок, поэтому вам нужно хотя бы сообщить нам, откуда поступают данные. В последних версиях DB2 нет проблем с хранением Unicode в базе данных, что избавит вас от всех ваших опасений.

Первая задача - выяснить, откуда берутся данные, и получить кодировку из вашего SysProg (если она не обрабатывается автоматически).

Обновление:

Эндрю, основываясь на добавленном вами тексте, в котором вы заявляете, что не можете использовать предоставленные переводы, вам придется использовать ручной метод. Вам необходимо определить источник данных и получить от него CCSID. Затем выполните перевод в Юникод и обратно (или любую другую кодовую страницу, которую вы используете, если не Юникод) вручную.

CCSID 500 - это кодовая страница по умолчанию для EBCDIC International (без евро), но эти машины используются по всей планете. Службы преобразования z / OS - это то, как вы обычно выполняете преобразование на мэйнфрейме.

Хотя это страница iSeries, на ней огромное количество CCSID и их глифов, применимых в том числе и к мэйнфреймам.

Вероятно, вам просто нужно выяснить, используете ли вы CCSID 500 или 37 (или одну из версий на иностранном языке), и разработать сопоставление с Unicode CCSID 1208. Ваш SysProg сможет сказать вам, какой из них. Если вы работаете в американской компании, это вероятно 500 или 37, но IBM прилагает много усилий для поддержки нескольких кодовых страниц. Я буду рад, когда все их программное обеспечение для мэйнфреймов будет хранить и использовать Unicode по умолчанию, это значительно упростит задачу.

person paxdiablo    schedule 04.05.2009
comment
Пакс, вы были совершенно правы, CCSID 500 (IBM-500, cp500) была правильной кодовой страницей, еще раз спасибо за вашу поддержку. - person user100645; 04.05.2009