Gestion des caractères spéciaux dans les exports

Feature request
1

Bonjour,

Dans mon projet, j’écris des descriptions qui contiennent parfois des caractères spéciaux (éàèç…) dans la description, on voit bien le caractère normalement
Lors de l’export de ces champs, il a été remarqué que ces caractères spéciaux était mal encodé
Existe-t-il un méthode Simplicité pour changer l’encodage ou indiquer qu’il peut y avoir des caractère spéciaux dans le champ et donc récupérer le texte tel quel

Cordialement,
KWu

2

L’encoding par défaut est UTF-8 qui supporte nativement tous les caractères du monde.
Vers quel format exportez vous vos données ? XML, CSV, PDF, Excel… ?

Ensuite avec quel client vous ouvrez ces données ? Il faut que le client qui reçoit vos données exportées supporte cet encoding, ou il faut lui indiquer quelque part.

3

En fait, c’est plutot les logiciels qui vont importer qui ne sont pas forcément en UTF-8, la plupart étant assez ancien, ils n’ont pas la possibilité de se mettre à jour pour changer l’encodage

Mais par choix d’avoir un export universelle, ceci permettant de pouvoir lire le fichier quelque soit l’encodage de l’appli qui importe, on voudrait faire en sorte que l’export (fait par Simplicité) puisse soit changer d’encodage, soit avoir une méthode qui va modifier tous les caractères spéciaux pour qu’ils soient lisible partout, existe-t-il une méthode de ce genre ?

Cordialement,
KWu

4

L’intégration de données par export/import manuel n’est jamais une bonne approche. L’intégration d’interface entre systèmes doit être automatisée par des flux sans action manuelle (au risque d’importer n’importe quoi par copier/coller avec des encodings non prévu, via word ou autre…).

Par la UI, l’utilisateur ne peut pas choisir l’encoding d’export, ça pourrait être une évolution pour les exports textuel (à priori que CSV, car pour les PDF ou Excel, ça n’a pas de sens).

En l’état, il faudra donc changer d’encoding (via notepad++ par exemple) avant d’importer les données ailleurs, si votre processus est manuel.

Sinon il faudra développer une Publication ou une Action d’export sur mesure, qui utilise les mêmes verbes que les actions standard (ou des search de base) et transforme l’encoding avec les verbes java élémentaires de la classe String ou autre Writer.

5

Je passe le post en feature request en V5.

  • Pour configurer une liste d’encoding disponibles pour l’utilisateur (via un paramètre système)
  • Proposer cette liste dans l’export standard, avec un champ libre si l’utilisateur veut en spécifier un autre

Par ailleurs vous n’avez pas dit quels encodings supporte votre système cible ?

6

Il y a plusieurs systeme cible, dont beaucoup sont des anciens systèmes qui n’ont pas la possibilité de mettre à jours les encodings supportés mais qui ont besoin de ces imports, c’est pour cela que je voudrais viser large et faire en sorte que lors de l’export, le champ description (et d’autres champs si nécessaire) soit encodé dans des encodages plus ancien, notamment en enlevant la plupart des caractères spéciaux soit en les modifiants (é => e, à => a) soit en les retirants

7

Dans ce cas il y a toujours le hook postExport qui permet de modifier les contenus après le “select” et avant export en fichier.
Mais c’est assez limitant de retirer des accents pour tous ceux qui ont besoin de l’export avec accents (pdf, excel…).

Voilà comment j’adresserai ce besoin :

  • Laisser l’export standard pour les usages normaux sur l’objet métier (si j’exporte dans Excel je veux tous les caractères)
  • Créer un héritier de cet objet en lecture seule et dédié à ces exports re-formattés avec le hook postExport implémenté (pour retirer les accents…) + accès dans un menu séparé de cet objet dédié aux systèmes legacy.

Autre possibilité : créer votre Publication spécifique, accessible depuis la liste de l’objet métier.

Ce ne sera jamais une fonction standard de Simplicité mais plutôt d’un ETL de transformation de données dans votre SI.