使用阿拉伯文本时，连接方向会改变方向亲爱的社区成员，
我有三列 - 一个字符和两个数字 - 我想将其连接成一个长字符串，如图和附件所示。
由于某种原因，当字符用阿拉伯语书写时，连接结果的顺序错误。
"('" || :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 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建议。
