RPG 프로그램에서 Java 프로그램으로 히브리어 데이터를 보내고 일부 데이터가 예상대로 들어오지 않습니다. RPG 프로그램은 CCSID 65535가있는 iSeries 시스템에서 실행 중입니다. Java는 원격 메소드 호출을 통해 액세스됩니다.
대부분의 히브리어는 논리적 순서로 Java 프로그램에 의해 수신됩니다. 그런 다음 Java Bidi 클래스로 처리하여 시각적 순서로 가져와 결국 PDF로 쓰게됩니다. 방정식 인 몇 줄을 제외하고 거의 모든 데이터가 정상입니다.
대문자 H는 히브리어 데이터라고 가정합니다. 이것은 라인이 어떻게 보일 것인가입니다 : 300 X 250 X 500 :HHHH
나는 다음과 같은 라인을 받았습니다 : HHHH: 500 250 X 300 X
500은 기대 한 순서가 아니며 Bidi 클래스가 올바르게 처리하지 못합니다. 이러한 몇 줄이 있으며 Bidi 클래스가 작동하지 않는 유일한 줄입니다. 나는 그 라인이 다음과 같이 올 것으로 가정 할 것이다 : 나는 그것이 논리적 인 순서라고 믿는 것처럼 HHHH: 300 X 250 X 500
이다. RTL 세그먼트에 500을 유지 한 다음 X에 도달하면 LTR로 넘기는 것입니다. 왜 그런지에 대한 아이디어가 있습니까?
도움 주셔서 감사합니다.
편집 : 자바는 실제로 RMI가 아니라 JNI를 통해 호출됩니다.RPG 프로그램에서 Java 프로그램으로의 히브리 데이터가 잘못 주문되었습니다.
답변
그래서 나는 여기에서 무슨 일이 일어나고 있는지 알아 내고 결국 다른 사람이 비슷한 문제에 부딪 힐 경우 내 자신의 질문에 대답하고 있습니다.
히브리어가 코드 페이지 424의 iSeries에 저장되었습니다. 이것은 히브리어 코드 페이지이므로 모든 것이 iSeries에 저장하는 것이 낫습니다. 우리는 iSeries에서 히브리어 데이터를 올바르게 처리하고있는 일부 인쇄 드라이버를 가지고 있기 때문에 iSeries와 Java 간의 전송 중이거나 Java에서 데이터 문자열을 만들 때 문제가 발생한다는 것을 알고있었습니다.
iSeries가 히브리를 인쇄 명령으로 저장하고 있었기 때문에 이미 PDF에 쓰기 위해 필요한 순서대로 저장되어있었습니다. Java 프로그램으로 전송할 때 우리는 RPG 문자 바이트 배열을 사용하고있었습니다. 이 문자 바이트 배열은 Java 메소드로 전송 될 때 유니 코드로 변환됩니다. 이 유니 코드 변환은 이미 올바른 순서로 존재하고 데이터를 순서대로 이동시키는 bidi 데이터를 처리하려고 시도합니다. 해결 방법은이 변환을 수행하지 않을 RPG 정수 바이트 배열로 전환하는 것이 었습니다. 그런 다음 Java에서 바이트 배열을 수신하면 AS400 오브젝트에서 작업의 CCSID를 가져 와서 새 문자열을 작성합니다.
작업의 CCSID가 문자 세트로 리턴됩니다. 그래서 미국 기반의 시스템에서는 Cp037을 반환 할 것이고 new String(byte[] source, String charsetName)
생성자에서 그것을 사용할 수 있으며 EBCDIC 코드 페이지에있는 바이트 배열을 Java 인코딩으로 변환합니다. 히브리어 기반 시스템에서 이것은 Cp424를 반환 할 것입니다. 나는 그것을 변환하기 위해 똑같은 일을 할 수 있습니다.
확실히 RMI 문제가 아닙니다. – EJP
그게 무슨 뜻이야? 우리가 RPG 프로그램에서 데이터를 처리하는 방식에 문제가 있다고 생각합니다. 어느 것이 RMI 문제가 아니며 RMI가 여기에서 문제가되어서는 안된다는 것에 동의합니다. 히브리어 데이터를 처리 할 수 있어야합니다. –
오, 알았습니다. 태그를 제거한 것을 봅니다. 태그를 잠재적 인 문제로 생각하지 않고 사용중인 기술로 생각했습니다. 잠재적 인 문제를 태그하는 것이 더 합리적이라고 생각합니다. –