Gestion des caractères spéciaux dans les recherches

Support
1

Request description

----description of the request----
Nous constatons que si un caractère spécial est stocké dans un champ texte d’une table, alors cela perturbe le bon fonctionnement de l’application. Deux cas d’usage identifiés :
=> soit la recherche plante l’IHM et seule un rafraichissement de la page peut rétablir la situation mais la recherche reste impossible
=> soit la recherche peut se faire mais tous les enregistrements dont au moins un champ contient un caractère spécial n’apparaissent pas dans le résultat de la recherche.

Y a-t-il un contournement ou une piste de solution ?

Steps to reproduce

chaine de caractère qui peut poser un pb MSCTOTO si elle est stockée dans un champ d’une table

Nota : le caractère peut ne pas être vu à l’oeil nu entre MSC et TOTO en mode graphique

Technical information

Instance /health

[Platform]
Status=OK
Version=4.0.P24
BuiltOn=2020-03-09 21:18 (revision 52f72387225102f2eaa20dad7acd604e2792760d)
Encoding=UTF-8
EndpointIP=172.18.0.2
EndpointURL=http://e2951d995dd7:8080
TimeZone=GMT+01:00
SystemDate=2022-03-18 16:06:58

[Application]
ApplicationVersion=4.0
ContextPath=
ContextURL=http://istdsimp.ansm-intra.fr:8080
ActiveSessions=89
TotalUsers=747
EnabledUsers=572
LastLoginDate=

[Server]
ServerInfo=Apache Tomcat/9.0.31
ServerType=WEB
User=root

[OS]
Name=Linux
Architecture=amd64
Version=5.3.18-24.52-default
SystemEncoding=UTF-8

[Disk]
DiskFree=199409
DiskUsable=197421
DiskTotal=255989

[JavaVM]
Version=13.0.2
Vendor=N/A
VMName=OpenJDK 64-Bit Server VM
VMVersion=13.0.2+8
ScriptEngine=rhino
ScriptEngineVersion=Rhino 1.7.11 2019 05 30
HeapFree=2615226
HeapSize=5169152
HeapMaxSize=8388608
TotalFreeSize=5834682

[Cache]
GrantCache=4127
GrantCacheMax=0
GrantCacheRatio=0
ObjectCache=2996
ObjectCacheMax=10000
ObjectCacheRatio=29
ProcessCache=2
ProcessCacheMax=10000
ProcessCacheRatio=0

[Database]
Vendor=4
ProductName=Oracle
ProductVersion=Oracle Database 18c Standard Edition 2 Release 18.0.0.0.0 - Production
Version 18.3.0.0.0
DriverName=Oracle JDBC driver
DriverVersion=19.3.0.0.0
DBDate=2022-03-18 16:06:58
DBDateOffset=0
DBPatchLevel=P24;52f72387225102f2eaa20dad7acd604e2792760d
UsingBLOBs=true

[Healthcheck]
Date=2022-03-18 16:06:58
ElapsedTime=32

Simplicité logs

N/A => Rien dans les logs

Browser logs

N/A => Rien dans les logs

Other relevant information

N/A

2

Bonjour Hafid,

Pour information la version de Simplicité que vous utilisez a plus de 500 commits de retard dont de nombreuses corrections de bugs critiques, il faudrait en premier lieu vous mettre à jour, sans quoi il sera difficile pour nous d’essayer de reproduire votre cas.

Ensuite, sans savoir de quel caractère il s’agit il est impossible pour nous de vous aider. Saurais-tu me fournir le code ASCII du caractère en question ?

Merci

3

Bonjour Alistair,

Il s’agit de : 2 STX (Start of Text)

PI, nous nous préparons pour passer à Simplicité 5.x sous peu

Merci

Cordialement,

4

Hafid,

D’où proviennent ces données ? Ce caractère de contrôle ne devrait pas se retrouver dans une chaine de caractères et sa présence n’est pas gérée par Simplicité.

5

Alistair,

Il arrive que des utilisateurs fassent des copier / coller d’autres applications (ie OTES) ou autres sources portail EMA, … vers des champs comme des commentaires / Description / …Ce qui pose problème pour les recherches.
L’idée est voir la possibilité de pouvoir parser ces champs avant enregistrement de l’objet et d’éviter d’avoir ces caractères en BDD soit par construction soit via outil.
Le souci est que je n’ai pas la liste exhaustive de ces caractères

7

Bonjour Hafid,

Dans ce cas il faudra implémenter dans un hook de validation des données une fonction qui retire ces caractères de contrôle. Par exemple : regex - How to remove control characters from java string? - Stack Overflow

8

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.