아랍어 텍스트를 사용할 때 연결 방향 변경 방향친애하는 커뮤니티 회원 여러분,
나는 그림과 첨부 파일에서와 같이 긴 문자열로 연결하고 싶은 세 개의 열 (하나의 문자와 두 개의 숫자)이 있습니다.
어떤 이유로 문자가 아랍어로 작성되면 연결 결과가 잘못된 순서로 표시됩니다.
"('" || :word || "', " || Char( :abc ) || ", " || Char( :def ) || ")"
SQL에서 사용하기 위해 다음 단계에서 열을 행렬로 내보내고 전체 프로세스가 실패하기 때문에 이것은 내 응용 프로그램에 좋지 않습니다.
입력해 주셔서 감사합니다.
자동화 및 스크립팅윈도우Re: 아랍어 텍스트를 사용할 때 연결 방향이 방향을 바꿉니다.매우 흥미로운.오른쪽에서 왼쪽으로 쓰는 아랍어와 관련이 있다고 확신합니다.따라서 아랍어 단어 뒤에 무언가를 연결하면 단어의 왼쪽에 배치됩니다.도움이 필요하면 JMP 지원으로 이동하는 것이 좋습니다.
Re: 아랍어 텍스트를 사용할 때 연결 방향이 방향을 바꿉니다.예. 룰은 잘 모르지만
x="واتساب ويب";
write("a"||x||",b")
/*:
aواتساب ويب,b
비교하다
x="واتساب ويب";
write("a"||x||",3")
/*:
aواتساب ويب,3
캐릭터 3 대 캐릭터 b.
Re: 아랍어 텍스트를 사용할 때 연결 방향이 방향을 바꿉니다.따라서 연결된 문자열(내부적으로)이 예상한 대로 표시되지만 프레젠테이션은 예상한 것과 다릅니다.
답이 없습니다. 아마도 다른 사람이 오른쪽에서 왼쪽으로 예상되는 동작에 익숙할 것입니다.
Re: 아랍어 텍스트를 사용할 때 연결 방향이 방향을 바꿉니다.확실하지 않다. 아무 것도 변경할 필요가 없을 수도 있습니다. 아니면 사용해야 할 수도 있습니다.
https://en.wikipedia.org/wiki/Left-to-right_mark
그리고 아마도 https://en.wikipedia.org/wiki/Right-to-left_mark (그러나 나는 아니라고 생각한다.)
예를 들어
write(x);
write("\!n");
write("1",x,"\!U200E2");
/*:
واتساب ويب
1واتساب ويب2
\!U200E는 Unicode Left-to-Right 마크의 JMP 표현입니다. 문자열에 해당 문자를 추가하여 예상한 대로 인쇄할 수 있지만 나중에 문자열 비교를 엉망으로 만들 것입니다(아마도... 테스트 없이 누가 알겠습니까...)
나는 아직도 규칙을 모른다. 답도 알고 싶습니다!
편집: 내가 "아무것도 변경할 필요가 없을 수도 있습니다"라고 말했을 때 일부 파서가 텍스트에 완벽하게 만족할 수 있음을 의미했습니다. 텍스트는 아마도 메모리에 필요한 문자 순서로 정확하게 배치되었을 것입니다. 표시될 때 순서가 맞지 않는 것처럼 보이지만 SQL 구문 분석기에서는 그렇지 않을 수 있습니다.
더:에서 https://en.wikipedia.org/wiki/Bidirectional_text --
유니코드 양방향 지원
유니코드 표준은 문자가 '논리적으로' 정렬되도록 요구합니다. 즉, 문자가 나타나는 순서인 '시각적으로'가 아니라 해석하려는 순서로 정렬되어야 합니다. 이러한 구분은 bidi 지원과 관련이 있습니다. 왜냐하면 모든 bidi 전환에서 시각적 표현이 '논리적' 표현이 아니기 때문입니다. 따라서 Bidi 지원을 제공하기 위해 유니코드는 문자의 논리적 시퀀스를 올바른 시각적 표현으로 변환하는 방법에 대한 알고리즘을 규정합니다. 이를 위해 유니코드 인코딩 표준은 모든 문자를 '강함', '약함', '중립' 및 '명시적 서식 지정'의 네 가지 유형 중 하나로 나눕니다.
Re: 아랍어 텍스트를 사용할 때 연결 방향이 방향을 바꿉니다.나는 지원에 다음과 같이 썼다 @txnelson 제안. 그들로부터 곧 소식을 듣기를 바랍니다.
무엇 @Craige_Hales 필자의 경우 오류가 순서에 따라 다르다고 생각하게 하여 다음과 같이 연결 순서를 변경해 보았는데 제대로 작동하는 것처럼 보이지만 여전히 왜 그리고 그것이 견고한지 확실하지 않습니다.
Re: 아랍어 텍스트를 사용할 때 연결 방향이 방향을 바꿉니다.이 문제는 열을 목록으로 가져오려고 할 때도 지속됩니다. 이 경우 문자열이 다른 방식으로 꼬여 있습니다.
Re: 아랍어 텍스트를 사용할 때 연결 방향이 방향을 바꿉니다.첨부된 테이블의 추가 열과 이를 생성하는 수식을 살펴보십시오.
Table with formulas to parse the Right to Left stringTable with formulas to parse the Right to Left stringTable with formulas to parse the Right to Left stringTable with formulas to parse the Right to Left stringTable with formulas to parse the Right to Left stringTable with formulas to parse the Right to Left stringTable with formulas to parse the Right to Left stringTable with formulas to parse the Right to Left stringTable with formulas to parse the Right to Left stringTable with formulas to parse the Right to Left stringTable with formulas to parse the Right to Left stringTable with formulas to parse the Right to Left stringTable with formulas to parse the Right to Left stringTable with formulas to parse the Right to Left stringTable with formulas to parse the Right to Left stringTable with formulas to parse the Right to Left string오른쪽에서 왼쪽 문자열을 구문 분석하는 수식이 포함된 테이블
처음 네 열은 원본입니다. quotes_and_parens는 alternate()를 사용하여 아포스트로피를 인용 부호로, 괄호를 중괄호로 변경합니다. 구문 분석 열은 quotes_and_parens 구문 분석 결과를 보여줍니다. 이 시점에서 여전히 절망적으로 보이지만 구문 분석 1,2,3을 살펴보십시오. 생성된 목록 구문 분석에서 항목 1, 2 및 3을 추출하고 있습니다. 의미 있는 순서대로 .
RtoL 문자열을 마지막에 배치하는 솔루션은 동일하게 작동하고 똑같이 강력하며 올바르게 표시되는 이점이 있습니다.
잘못 표시된 결과는 RtoL 및 LtoR 문자열을 혼합하고 일치시키는 유니코드 규칙 때문입니다. 오류는 문자열이 표시될 때만 발생합니다. 내부 문자열이 올바르고 구문 분석해도 괜찮을 것입니다. SQL이 그것을 구문 분석할 수 없다면 SQL이 유니코드를 지원한다고 가정할 때 이상하고 설명하기 어려운 것 같습니다.
또한 특히 다른 부분에서 반전된 선택 부분이 있는 텍스트를 선택하려고 할 때 이것이 혼란스러웠습니다. 반전이 프레젠테이션 시간에 수행된다는 것을 이해하고 나니 더 이해가 되었습니다.
Re: 아랍어 텍스트를 사용할 때 연결 방향이 방향을 바꿉니다.많은 감사 @Craige_Hales
WYSIWYG가 아닌 것은 매우 직관적이지 않습니다. 열을 목록으로 가져오는 것은 승인에 필요한 방식으로 최종 문자열을 SQL로 구문 분석할 수 있는지 확인하려는 시도이기도 했습니다. 시각적으로 작동하지 않는 것처럼 보였지만 실제로 작동했습니다!
Re: 아랍어 텍스트를 사용할 때 방향을 연결하면 방향이 변경됩니다.JMP 지원팀으로부터 다음 메시지를 받았습니다.
인용문 시작 "
안녕하세요 론,
문자열 연결을 담당하는 개발자와 귀하의 문제에 대해 논의했습니다.연결된 문자열을 정의하는 유니코드 문자를 살펴보면 지정한 순서대로 연결되어 있습니다.그러나 문자열을 표시하기 위한 유니코드 양방향 텍스트 규칙이 있습니다.예상치 못한 방향을 나타내는 문자열의 표시입니다.내부적으로 문자열은 예상대로 저장됩니다.다음은 개발자가 설명하기 위해 제공한 짧은 JSL 예제입니다.
x = "?";
y = "0";
xy = x || y;
Show(xy, Hex(xy, "utf-16be"));
// xy = "?0";
// Hex(xy, "utf-16be") = "06280030";
U+0030은 숫자 0이고 두 번째입니다.
또한 문자열을 텍스트 파일로 저장하고 ASCII -> HEX 변환기가 있는 타사 텍스트 편집기에서 열어 확인했습니다.결과 스크린샷은 아래와 같습니다.Hex로 변환한 후 공백, 쉼표, 괄호 코드를 다시 해당 문자로 대체하여 따라가기 쉽도록 했습니다.예상대로 16진수 표현 끝에 0에 대한 코드가 표시됩니다.
개발자는 또한 블로그 링크 이는 데이터베이스 쿼리에서 이를 처리하는 데 도움이 될 수 있습니다.
" 인용 끝
그러므로 나는 이제 우리가 무엇을 의미하는지에 부합하는 포괄적인 대답을 가지고 있다고 생각합니다. @Craige_Hales 제안했습니다.
