アラビア語テキストを使用すると、連結方向が方向を変更しますコミュニティの親愛なるメンバーの皆様、
画像と添付ファイルにあるように、3つの列（1つの文字と2つの数値）があり、それらを連結して長い文字列にしたいと考えています。
何らかの理由で、文字がアラビア語で書かれている場合、連結結果の順序が間違っています。
"('" || :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 --
Unicode 双方向サポート
Unicode 標準では、文字が「視覚的に」表示される順序ではなく、「論理的に」、つまり解釈されることを意図した順序で順序付けされることが求められます。 この区別は、双方向の移行時に視覚的プレゼンテーションが「論理的」なものではなくなるため、双方向サポートに関連します。 したがって、Bidi サポートを提供するために、Unicode は文字の論理シーケンスを正しい視覚的表現に変換する方法のアルゴリズムを規定しています。 この目的のために、Unicode エンコード標準はすべての文字を「強い」、「弱い」、「中立」、および「明示的な書式設定」の 4 つのタイプのいずれかに分類します。
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右から左への文字列を解析するための式を含む表
最初の 4 列はオリジナルです。 quotes_and_parens は、substitute() を使用して、アポストロフィを引用符に、括弧を中括弧に変更します。 parse 列には、quotes_and_parens を解析した出力が表示されます。 この時点ではまだ絶望的に見えますが、解析 1、2、3 を見てください。解析で生成されたリストから項目 1、2、3 が抽出されています。理にかなった順序で。
RtoL 文字列を最後に配置するソリューションは、同様に機能し、同様に堅牢であり、正しく表示されるという利点があります。
結果が誤って表示されるのは、RtoL 文字列と LtoR 文字列の混合と一致に関する Unicode ルールが原因です。 エラーは文字列が表示されている場合にのみ発生します。 内部文字列は正しいので、おそらく解析しても問題ありません。 SQL が解析できない場合、SQL が Unicode をサポートしていると仮定すると、それは奇妙で説明が難しいと思われます。
また、特に選択範囲の一部が他の部分と反転しているテキストを選択しようとする場合、これが混乱することもわかりました。 プレゼンテーション時に反転が行われることを理解すると、より理解できました。
Re: アラビア語テキストを使用すると、連結方向が方向を変えるどうもありがとう@Craige_Hales
WYSIWYG ではないということは、非常に直観に反します。 列をリストとして取得することは、最終的な文字列が受け入れに必要な方法で SQL に解析可能であることを確認する試みでもありました。 見た目にはうまくいかないように見えましたが、うまくいきました。
Re: アラビア語テキストを使用すると、連結方向が方向を変える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 は 0 桁で 2 番目になります。
また、文字列をテキスト ファイルとして保存し、ASCII -> HEX コンバータを備えたサードパーティのテキスト エディタで開いて検証しました。結果のスクリーンショットは以下のとおりです。16 進数に変換した後、わかりやすくするために、スペース、カンマ、括弧のコードを再びその文字に置き換えました。ご想像のとおり、16 進表現の末尾に 0 のコードがあることに注目してください。
開発者はまた、ブログへのリンクこれは、データベース クエリでこれに対処するのに役立つ場合があります。
"引用終わり
したがって、私たちは今、次の内容に沿った包括的な答えを持っていると思います。 @Craige_Halesと提案した。
