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

Question

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

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

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

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

EDIT: Добавлен из моего ответа на Pax ниже:

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

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

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

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

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

Answer 1

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

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

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

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

Update:

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

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

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

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