EBCDIC при распаковке данных comp-3 возвращает 40404 ** в Java
Я использовал логику распаковки данных, приведенную в приведенной ниже ссылке для java. Как распаковать цифры COMP-3 с помощью Java? Но для нулевых данных в исходном коде он возвращает 404040404, как в коде распаковки Java. Я понимаю, что это был пробел в ebcdic, но как распаковать, обработав этот пробел или избежать его.
я пробовал, он также заменяет числовое значение 4. char[] NON_PRINTABLE_EBCDIC_CHARS = новый char[] {0x00, 0x40}; for (int currentByteIndex = 0; currentByteIndex < PackedData.length; currentByteIndex++) { //добавлено для проблем с типами данных comp и comp3 с нулевым символом int = PackedData[currentByteIndex]; логическое значение isBlank = ложь; for (char nonPrintableChar : NON_PRINTABLE_EBCDIC_CHARS) { if (nonPrintableChar == (char) символ) { isBlank=true; } } если(!пусто) {
если исходное значение 444. Будет ли правильно декодировать? он не заменит на ноль?
Если вы видите пробелы, скорее всего, у вас ошибка или несовпадение входных данных. Ни одна хорошо разработанная программа COBOL никогда не поместит пробелы в поле COMP-3.
Я бы не стал проверять каждый байт, а просто посмотрел бы последний байт. Если он содержит допустимый знаковый фрагмент, я бы попытался распаковать поле и придумать какую-то стратегию для всех других случаев (вернуть 0, выдать ошибку,...?).
Ответы 1
Есть две проблемы, которые нам предстоит решить. Во-первых, являются ли данные действительными данными comp-3, а во-вторых, являются ли данные, которые считаются «действительными» в более старых языковых реализациях, таких как COBOL, с тех пор, как был упомянут Comp-3.
Если смещения не смещены, может показаться, что пробелы интерпретируются существующими программами как 0 вместо пробелов. Это было бы неправильно, но могло быть артефактом старых программ, которые были спроектированы так, чтобы допускать такое плохое поведение.
Подход, который я бы использовал в устаревшем магазине (при условии отсутствия смещения), заключается в том, чтобы считать «пробелы» (которые представляют собой последовательности 0x404040404040) равными нулю. Это будет устаревшая проверка, чтобы сравнить поле с пробелами, а затем предположить, что 0x00000000000f является фактическим значением по умолчанию. Это то, что должен определить отдельный магазин, и это не считается общим подходом к программированию.
С точки зрения Java, нужно помнить, что байты «подписаны», поэтому сравнения могут быть сложными в зависимости от того, как написан код. Единственный «беззнаковый» тип данных I вспомните, что в java есть char, который на самом деле состоит из двух байтов (единица 16).
Это не столько проблема программирования, сколько признание исторической терпимости и исправления.
Вы можете просто сравнить поле с 0x40 в каждом символе, затем заменить его на 0x00 для всех, кроме последнего символа, и сделать это 0x0f. Итак, если это 3-байтовое поле, вы должны искать 0x40 в [0], [1] и [2], и если это 0x40 в каждом, то замените поля на [0] = 0x00 [1] = 0x00 [2] = 0x0f и это распакуется в 0