使用阿拉伯文本時,連接方向會改變方向親愛的社區成員,
我有三列 - 一個字符和兩個數字 - 我想將其連接成一個長字符串,如圖和附件所示。
由於某種原因,當字符用阿拉伯語書寫時,連接結果的順序錯誤。
"('" || :word || "', " || Char( :abc ) || ", " || Char( :def ) || ")"

這對我的應用程序不利,因為我在下一階段將列導出為矩陣以在 SQL 中使用,並且整個過程失敗。
非常感謝您的投入。
自動化和腳本編寫視窗回复:使用阿拉伯文本時連接方向會改變方向很有意思。我確信這與阿拉伯語從右到左書寫有關。因此,在阿拉伯語單詞之後連接某些內容,會將其放置在該單詞的左側。我建議您前往 JMP 支持尋求幫助。
回复:使用阿拉伯文本時連接方向會改變方向是的。 我不知道規則,但是
x="واتساب ويب";
write("a"||x||",b")
/*:
aواتساب ويب,b
相比於
x="واتساب ويب";
write("a"||x||",3")
/*:
aواتساب ويب,3
角色 3 與角色 b。
回复:使用阿拉伯文本時連接方向會改變方向因此,連接的字符串(內部)似乎是您所期望的,但表示方式與您所期望的不同。

我沒有答案,也許其他人熟悉從右到左的預期行為。
回复:使用阿拉伯文本時連接方向會改變方向沒有把握。 您可能不需要改變任何東西。 或者你可能需要使用
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 是 JMP 的 Unicode 從左到右標記表示形式。 您可以將該字符添加到字符串中,使其按照您期望的方式打印,但它會弄亂稍後的字符串比較(也許......誰知道不測試......)
我還是不知道規則。 也有興趣知道答案!
編輯:當我說“你可能不需要改變任何東西”時,我的意思是一些解析器可能對文本非常滿意,它可能完全按照你在內存中需要的字符順序排列。 我知道它在顯示時看起來是亂序的,但這可能不是 SQL 解析器所看到的。
更多:來自https://en.wikipedia.org/wiki/Bi Direction_text --
Unicode 雙向支持
Unicode 標準要求字符按“邏輯”排序,即按照它們要解釋的順序,而不是“視覺上”按它們出現的順序排序。 這一區別與 Bidi 支持相關,因為在任何 Bidi 轉換中,視覺呈現都不再是“邏輯”呈現。 因此,為了提供雙向支持,Unicode 規定了一種算法,用於將字符的邏輯序列轉換為正確的視覺呈現。 為此,Unicode 編碼標準將其所有字符分為四種類型之一:“強”、“弱”、“中性”和“顯式格式”。
回复:使用阿拉伯文本時連接方向會改變方向我確實寫信給支持人員@tx尼爾森建議。希望盡快收到他們的消息。
什麼@Craige_Hales所寫的內容讓我認為我的情況下的錯誤與順序相關,因此我嘗試按如下方式更改串聯順序,它看起來有效,但我仍然不確定為什麼以及它是否穩健。

回复:使用阿拉伯文本時連接方向會改變方向當我嘗試將列作為列表獲取時,這個問題仍然存在,在這種情況下,字符串以不同的方式扭曲。

回复:使用阿拉伯文本時連接方向會改變方向請查看附表的額外列以及創建它們的公式。
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 stringTable with formulas to parse the Right to Left string包含用於解析從右到左字符串的公式的表
前四列是原件。 quotes_and_parens 使用 Replace() 將撇號更改為引號,將括號更改為大括號。 解析列顯示解析quotes_and_parens 的輸出。 此時看起來仍然沒有希望,但是看看解析 1、2、3:它們正在從解析生成的列表中提取項目 1、2 和 3,按照有意義的順序。
您的解決方案將 RtoL 字符串放在最後,其工作方式相同,同樣穩健,並且具有正確顯示的優點。
顯示錯誤的結果是由於混合和匹配 RtoL 和 LtoR 字符串的 Unicode 規則造成的。 僅當顯示字符串時才會發生該錯誤。 內部字符串是正確的,解析它可能沒問題。 如果 SQL 無法解析它,這看起來很奇怪並且很難解釋,假設 SQL 支持 Unicode。
我還發現這令人困惑,特別是當嘗試選擇部分選擇與其他部分相反的文本時。 一旦我明白反轉是在演示時完成的,它就更有意義了。
回复:使用阿拉伯文本時連接方向會改變方向非常感謝@Craige_Hales
不所見即所得是非常違反直覺的。 將列作為列表也是為了確認最終字符串可以按照接受所需的方式解析為 SQL。 從視覺上看,它看起來不像會起作用,但它確實起作用了!
回复:使用阿拉伯文本時連接方向會改變方向我收到了來自 JMP 支持的以下消息:
引用的開頭“
嗨羅恩,
我與負責字符串連接的開發人員討論了您的問題。如果您查看定義連接字符串的 Unicode 字符,您會發現它們按照您指定的順序連接。但是,有用於顯示字符串的 Unicode 雙向文本規則。正是字符串的顯示表明了您意想不到的方向。在內部,字符串按預期存儲。這是開發人員提供的一個簡短的 JSL 示例來進行說明。
x = "?";
y = "0";
xy = x || y;
Show(xy, Hex(xy, "utf-16be"));
// xy = "?0";
// Hex(xy, "utf-16be") = "06280030";
U+0030 是零數字,排在第二位。
我還通過將字符串保存為文本文件並在具有 ASCII -> HEX 轉換器的第三方文本編輯器中打開它來進行驗證。結果的屏幕截圖如下。轉換為十六進制後,我再次用它們的字符替換了空格、逗號和括號代碼,這樣更容易理解。如您所料,請注意十六進製表示形式末尾的 0 代碼。

開發商還提供了鏈接到博客這可以幫助您在數據庫查詢中處理這個問題。
" 引用結束
因此,我認為我們現在有了一個全面的答案,該答案符合@Craige_Hales建議。