la direction de concaténation change de direction lors de l'utilisation de texte arabechers membres de la communauté,
j'ai trois colonnes - un caractère et deux numériques - que j'aimerais concaténer en une longue chaîne comme dans l'image et la pièce jointe.
pour une raison quelconque, lorsque le caractère est écrit en arabe, les résultats de la concaténation sont dans le mauvais ordre.
"('" || :word || "', " || Char( :abc ) || ", " || Char( :def ) || ")"

ce n'est pas bon pour mon application puisque j'exporte la colonne sous forme de matrice lors de l'étape suivante pour l'utiliser dans SQL et que l'ensemble du processus échoue.
merci beaucoup pour votre contribution.
Automatisation et scriptsles fenêtresRe : La direction de la concaténation change de direction lors de l'utilisation de texte arabeTrès intéressant.Je suis sûr que cela a à voir avec la langue arabe qui écrit de droite à gauche.Par conséquent, concaténer quelque chose après un mot arabe reviendrait à le placer à gauche du mot.Je vous suggère d'accéder au support JMP pour obtenir de l'aide.
Re : La direction de la concaténation change de direction lors de l'utilisation de texte arabeOui. Je ne connais pas les règles, mais
x="واتساب ويب";
write("a"||x||",b")
/*:
aواتساب ويب,b
comparer aux
x="واتساب ويب";
write("a"||x||",3")
/*:
aواتساب ويب,3
Personnage 3 contre personnage b.
Re : La direction de la concaténation change de direction lors de l'utilisation de texte arabeIl semble donc que la chaîne concaténée (en interne) corresponde à ce que vous attendez, mais la présentation est différente de ce à quoi vous vous attendez.

Je n'ai pas de réponse, peut-être que quelqu'un d'autre connaît les comportements attendus de droite à gauche.
Re : La direction de la concaténation change de direction lors de l'utilisation de texte arabePas certain. Vous n’aurez peut-être pas besoin de changer quoi que ce soit. Ou vous devrez peut-être utiliser
https://en.wikipedia.org/wiki/Left-to-right_mark
et peut-être https://en.wikipedia.org/wiki/Right-to-left_mark (mais je ne pense pas.)
Par exemple
write(x);
write("\!n");
write("1",x,"\!U200E2");
/*:
واتساب ويب
1واتساب ويب2
\!U200E est la représentation JMP de la marque Unicode de gauche à droite. Vous ajouteriez ce caractère à la chaîne pour la faire imprimer comme prévu, mais cela gâcherait les comparaisons de chaînes plus tard (peut-être... qui sait sans tester...)
Je ne connais toujours pas les règles. Intéressé de connaître la réponse aussi!
edit : quand j'ai dit "vous n'aurez peut-être rien à changer", je voulais dire que certains analyseurs pourraient être parfaitement satisfaits du texte, qui est probablement disposé exactement dans l'ordre des caractères dont vous avez besoin en mémoire. Je sais qu'il semble dans le désordre lorsqu'il est affiché, mais ce n'est peut-être pas ainsi que l'analyseur SQL le voit.
plus de https://en.wikipedia.org/wiki/Bidirectionnel_text --
Prise en charge des bidis Unicode
La norme Unicode exige que les caractères soient ordonnés « logiquement », c'est-à-dire dans l'ordre dans lequel ils sont censés être interprétés, par opposition à « visuellement », l'ordre dans lequel ils apparaissent. Cette distinction est pertinente pour le support bidi car à toute transition bidi, la présentation visuelle cesse d'être la présentation « logique ». Ainsi, afin d'offrir la prise en charge du bidi, Unicode prescrit un algorithme permettant de convertir la séquence logique de caractères en une présentation visuelle correcte. À cette fin, la norme de codage Unicode divise tous ses caractères en quatre types : « fort », « faible », « neutre » et « formatage explicite ».
Re : La direction de la concaténation change de direction lors de l'utilisation de texte arabej'ai écrit au support comme @txnelson suggéré. j'espère avoir de leurs nouvelles bientôt.
quoi @Craige_Hales a écrit m'a fait penser que l'erreur dans mon cas dépend de l'ordre, j'ai donc essayé de changer l'ordre de concaténation comme suit et il semble que cela fonctionne, mais je ne sais toujours pas pourquoi et s'il est robuste.

Re : La direction de la concaténation change de direction lors de l'utilisation de texte arabeCe problème persiste également lorsque j'essaie d'obtenir la colonne sous forme de liste, dans ce cas, la chaîne est tordue d'une manière différente.

Re : La direction de la concaténation change de direction lors de l'utilisation de texte arabeVeuillez jeter un œil aux colonnes supplémentaires du tableau ci-joint et aux formules qui les créent.
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 stringTableau avec des formules pour analyser la chaîne de droite à gauche
Les quatre premières colonnes sont les originaux. quotes_and_parens utilise substitut() pour changer l'apostrophe en guillemets et les parenthèses en accolades. La colonne d'analyse affiche le résultat de l'analyse de quotes_and_parens. À ce stade, cela semble toujours désespéré, mais regardez l'analyse 1,2,3 : ils extraient les éléments 1, 2 et 3 de l'analyse de liste produite, dans l'ordre qui a du sens .
Votre solution, en plaçant la chaîne RtoL en dernier, fonctionnera de la même manière, est tout aussi robuste et présente l'avantage de s'afficher correctement.
Le résultat mal affiché est dû aux règles Unicode pour mélanger et faire correspondre les chaînes RtoL et LtoR. L'erreur ne se produit que lorsque la chaîne est affichée. La chaîne interne est correcte et son analyse est probablement correcte. Si SQL ne peut pas l'analyser, cela semble étrange et difficile à expliquer, en supposant que SQL prenne autrement en charge Unicode.
J'ai également trouvé cela déroutant, en particulier lorsque j'essayais de sélectionner du texte dont des parties de la sélection étaient inversées par rapport à d'autres parties. Une fois que j’ai compris que l’inversion était effectuée au moment de la présentation, cela avait plus de sens.
Re : La direction de la concaténation change de direction lors de l'utilisation de texte arabeMerci beaucoup @Craige_Hales
Ne pas être WYSIWYG est très contre-intuitif. Obtenir la colonne sous forme de liste était également une tentative de confirmer que la chaîne finale serait analysable dans SQL de la manière nécessaire pour l'acceptation. Visuellement, cela ne semblait pas fonctionner, mais c'est le cas !
Re : La direction de la concaténation change de direction lors de l'utilisation de texte arabej'ai reçu le message suivant du support JMP :
début de citation "
Salut Ron,
J'ai discuté de votre problème avec le développeur responsable de la concaténation des chaînes.Si vous examinez les caractères Unicode qui définissent la chaîne concaténée, ils sont concaténés dans l'ordre que vous avez spécifié.Cependant, il existe des règles de texte bidirectionnel Unicode pour l'affichage des chaînes.C'est l'affichage des chaînes qui indique votre direction inattendue.En interne, la chaîne est stockée comme prévu.Voici un court exemple JSL fourni par le développeur pour illustrer.
x = "?";
y = "0";
xy = x || y;
Show(xy, Hex(xy, "utf-16be"));
// xy = "?0";
// Hex(xy, "utf-16be") = "06280030";
U+0030 est le chiffre zéro et vient en deuxième position.
J'ai également vérifié en enregistrant la chaîne en tant que fichier texte et en l'ouvrant dans un éditeur de texte tiers doté d'un convertisseur ASCII -> HEX.Une capture d'écran des résultats est ci-dessous.Après la conversion en Hex, j'ai à nouveau remplacé les codes d'espace, de virgule et de parenthèses par leurs caractères afin qu'ils soient plus faciles à suivre.Notez les codes pour 0 à la fin de la représentation hexadécimale, comme vous vous en doutez.

Le développeur a également fourni un lien vers un blog cela peut vous aider à résoudre ce problème dans votre requête de base de données.
" fin de citation
Par conséquent, je pense que nous disposons désormais d'une réponse globale qui correspond à ce que @Craige_Hales suggéré.