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

Question

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

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

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

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

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

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

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

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

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

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

Answer 1

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

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

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

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

Обновление:

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

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

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

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