concatenate direction cambia direzione quando si usa il testo arabocari membri della comunità,
ho tre colonne - un carattere e due numeriche - che vorrei concatenare in una lunga stringa come nell'immagine e nell'allegato.
per qualche motivo, quando il carattere è scritto in arabo, i risultati del concatenamento sono nell'ordine sbagliato.
"('" || :word || "', " || Char( :abc ) || ", " || Char( :def ) || ")"
questo non va bene per la mia applicazione poiché esporto la colonna come matrice nella fase successiva da utilizzare in SQL e l'intero processo fallisce.
molte grazie per il tuo contributo.
Automazione e scriptingfinestreRe: concatenare la direzione cambia direzione quando si utilizza il testo araboMolto interessante.Sono sicuro che abbia a che fare con la lingua araba che scrive da destra a sinistra.Pertanto, concatenare qualcosa dopo una parola araba, sarebbe metterlo a sinistra della parola.Ti suggerisco di rivolgerti al supporto JMP per ricevere assistenza.
Re: concatenare la direzione cambia direzione quando si utilizza il testo araboSÌ. Non conosco le regole, ma...
x="واتساب ويب";
write("a"||x||",b")
/*:
aواتساب ويب,b
Paragonare a
x="واتساب ويب";
write("a"||x||",3")
/*:
aواتساب ويب,3
Personaggio 3 vs personaggio b.
Re: concatenare la direzione cambia direzione quando si utilizza il testo araboQuindi sembra che la stringa concatenata (internamente) sia ciò che ti aspetti, ma la presentazione è diversa da ciò che ti aspetti.
Non ho una risposta, forse qualcun altro ha familiarità con i comportamenti previsti da destra a sinistra.
Re: concatenare la direzione cambia direzione quando si utilizza il testo araboNon è sicuro. Potrebbe non essere necessario modificare nulla. Oppure potrebbe essere necessario utilizzare
https://en.wikipedia.org/wiki/Left-to-right_mark
e forse https://en.wikipedia.org/wiki/Right-to-left_mark (ma credo di no.)
Per esempio
write(x);
write("\!n");
write("1",x,"\!U200E2");
/*:
واتساب ويب
1واتساب ويب2
\!U200E è la rappresentazione di JMP del marchio Unicode da sinistra a destra. Aggiungeresti quel carattere alla stringa per farlo stampare come ti aspetti, ma in seguito rovinerà i confronti delle stringhe (forse ... chissà senza test ...)
Ancora non conosco le regole. Interessato anche a conoscere la risposta!
modifica: quando ho detto "potresti non dover cambiare nulla" intendevo dire che alcuni parser potrebbero essere perfettamente soddisfatti del testo, che probabilmente è disposto esattamente nell'ordine dei caratteri di cui hai bisogno in memoria. So che sembra fuori servizio quando viene visualizzato, ma potrebbe non essere così che lo vede il parser SQL.
di più da https://en.wikipedia.org/wiki/Bidirectional_text --
Supporto bidi Unicode
Lo standard Unicode richiede che i caratteri siano ordinati 'logicamente', cioè nella sequenza in cui devono essere interpretati, invece che 'visivamente', la sequenza in cui appaiono. Questa distinzione è rilevante per il supporto bidi perché ad ogni transizione bidi, la presentazione visiva cessa di essere quella "logica". Pertanto, per offrire il supporto bidi, Unicode prescrive un algoritmo su come convertire la sequenza logica di caratteri nella corretta presentazione visiva. A tale scopo, lo standard di codifica Unicode divide tutti i suoi caratteri in uno dei quattro tipi: "forte", "debole", "neutro" e "formattazione esplicita".
Re: la direzione di concatenazione cambia direzione quando si utilizza il testo araboho scritto al supporto come @txnelson suggerito. spero di sentirli presto.
Che cosa @Craige_Hales ha scritto mi ha fatto pensare che l'errore nel mio caso dipenda dall'ordine, quindi ho provato a modificare l'ordine di concatenazione come segue e sembra che funzioni, ma non sono ancora sicuro del perché e se sia robusto.
Re: la direzione di concatenazione cambia direzione quando si utilizza il testo araboQuesto problema persiste anche quando provo a ottenere la colonna come elenco, in questo caso la stringa è attorcigliata in modo diverso.
Re: la direzione di concatenazione cambia direzione quando si utilizza il testo araboDai un'occhiata alle colonne extra della tabella allegata e alle formule che le creano.
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 stringTabella con le formule per analizzare la stringa da destra a sinistra
Le prime quattro colonne sono gli originali. quotes_and_parens utilizza replace() per trasformare l'apostrofo in virgolette e le parentesi in parentesi graffe. La colonna parse mostra l'output dell'analisi quotes_and_parens. A questo punto sembra ancora senza speranza, ma guarda l'analisi 1,2,3: stanno estraendo gli elementi 1, 2 e 3 dall'elenco analizzato prodotto, nell'ordine che ha senso .
La tua soluzione, posizionando la stringa RtoL per ultima, funzionerà allo stesso modo, è altrettanto robusta e ha il vantaggio di essere visualizzata correttamente.
Il risultato visualizzato in modo errato è dovuto alle regole Unicode per la combinazione e la corrispondenza delle stringhe RtoL e LtoR. L'errore si verifica solo quando viene visualizzata la stringa. La stringa interna è corretta e probabilmente la sua analisi va bene. Se SQL non è in grado di analizzarlo, sembra strano e difficile da spiegare, presupponendo altrimenti che SQL supporti Unicode.
Ho trovato anche questo motivo di confusione, soprattutto quando si tenta di selezionare un testo con parti della selezione invertite rispetto ad altre parti. Una volta capito che l'inversione veniva eseguita al momento della presentazione, aveva più senso.
Re: la direzione di concatenazione cambia direzione quando si utilizza il testo araboGrazie molto @Craige_Hales
Essere NON WYSIWYG è molto controintuitivo. Ottenere la colonna come elenco è stato anche un tentativo di confermare che la stringa finale sarà analizzabile in SQL nel modo necessario per l'accettazione. Visivamente, non sembrava che avrebbe funzionato, ma è stato così!
Re: la direzione di concatenazione cambia direzione quando si utilizza il testo araboho ricevuto il seguente messaggio dal supporto JMP:
inizio citazione"
Ciao Ron,
Ho discusso il tuo problema con lo sviluppatore responsabile della concatenazione di stringhe.Se osservi i caratteri Unicode che definiscono la stringa concatenata, vengono concatenati nell'ordine specificato.Tuttavia, esistono regole di testo bidirezionale Unicode per la visualizzazione delle stringhe.È la visualizzazione delle corde che indica la tua direzione inaspettata.Internamente, la stringa viene archiviata come previsto.Ecco un breve esempio JSL fornito dallo sviluppatore per illustrare.
x = "?";
y = "0";
xy = x || y;
Show(xy, Hex(xy, "utf-16be"));
// xy = "?0";
// Hex(xy, "utf-16be") = "06280030";
U+0030 è la cifra zero e viene per seconda.
Ho anche verificato salvando la stringa come file di testo e aprendola in un editor di testo di terze parti dotato di un convertitore ASCII -> HEX.Di seguito è riportato uno screenshot dei risultati.Dopo la conversione in esadecimale, ho sostituito nuovamente i codici di spazio, virgola e parentesi con i relativi caratteri in modo che siano più facili da seguire.Nota i codici per 0 alla fine della rappresentazione esadecimale come ti aspetteresti.
Lo sviluppatore ha anche fornito a collegamento a un blog che potrebbe aiutarti a gestire questo problema nella query del database.
"fine della citazione
Pertanto, penso che ora abbiamo una risposta completa che è in linea con cosa @Craige_Hales suggerito.
