Discussion :

[oni13]

Bonjour,

je cherche à comprendre comment transformer un caractère encodé autre que UTF-8 dans son équivalent UTF-8

Mon exemple:

Je souhaite transformer cette chaîne
Info – changement d’adresse ==> Info - changement d'adresse

Le tiret et l'apostrophe sont encodés en WINDOWS-1252 (à priori) et si je les stocke ainsi, il ne seront pas reconnus pour une utilisation future puisque je gère uniquement de l'UTF-8

J'ai utilisé l'API juniversalchardet pour reconnaître l'encodage des caractères (ce n'est pas du 100% je suis d'accord, mais c'est toujours ça).

J'ai ensuite tenté cette manip consistant à manipulet des byte pour transformer en UTF-8:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
//c = un caractère String
//encoding = encodage trouvé par juniversalchardet
String newString = new String(decodeUtf8(c.getBytes(),encoding), "UTF-8");

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
private static byte[] decodeUtf8(byte[] bytes, String sourceCharset){
    Charset srcCharset = Charset.forName(sourceCharset);
    Charset utf8charset = Charset.forName("UTF-8");
 
    ByteBuffer inputBuffer = ByteBuffer.wrap(bytes);
 
    // decoder selon l'encodage en parametre
    CharBuffer data = srcCharset.decode(inputBuffer);
 
    // encoder en utf-8
    ByteBuffer outputBuffer = utf8charset.encode(data);
    byte[] outputData = outputBuffer.array();
 
    return outputData;
}

Or voici ce que j'obtiens pour le tiret et l'apostrophe:
–
Â’

Ce ne sont pas les caractères - et ' souhaités.

Avez vous une idée de comment effectuer cette manip svp?

Merci

[adiGuba]

Salut,



Ta méthode decodeUtf8() n'a pas trop de sens.
Et vu comment tu l'utilises tu risques même des problèmes si l'encodage par défaut du système. ne correspond pas à celui que tu utilises

Si tu veux encoder une String en utf8 il suffit de faire ceci : s.getBytes("utf8") ...



Mais cela ne répond pas à ton problème : tu n'as pas de problème d'encodage !
Les caractères – et ’ correspondent tout simplement à des caractères distinct de - et '


Si tu veux remplacer ces caractères il faut faire un replace...


a++

[tchize_]

Bonjour,

je cherche à comprendre comment transformer un caractère encodé autre que UTF-8 dans son équivalent UTF-8

L'encodage concerne les fichier, pas les caractères. C'est la manière dont un caractère, par exemple "tiret large" est transformé en un flux de bits pour le stockage.


Mon exemple:

Je souhaite transformer cette chaîne
Info – changement d’adresse ==> Info - changement d'adresse

Comme dis par adiguba, c'est la méthode String.replace qui sert à remplacer des caractères. Ca n'a rien à voir avec l'encodage.

Le tiret et l'apostrophe sont encodés en WINDOWS-1252 (à priori) et si je les stocke ainsi, il ne seront pas reconnus pour une utilisation future puisque je gère uniquement de l'UTF-8

L'UTF-8 gère tout le champ unicode. Donc il n'y a aucun problème à y mettre un tiret large et une apostrophe inclinée. C'est quoi ton soucis in fine? Tu as une exception à la lecture du fichier? Tu as un autre caractère à la place? Ta console est incapable d'afficher ces caractères? ....

[oni13]

Salut,

Ces caractères ne sont pas reconnus par mon appli web, et sont remplacés par une chaîne vide.
La console eclipse ne sait également pas afficher ces caractères mais ce n'est pas gênant.

Contexte:
Je lis un fichier CSV que je manipule pour y stocker des données en BDD (je ne stocke pas le fichier mais certaines de ses lignes en tant que varchar)
==> La chaîne est correctement stockée en BDD avec le tiret long et apostrophe incliné.
A la restitution des données, j'observe des "carrés" dans le retour de mon WS indiquant que les caractères ne sont pas reconnus, et le navigateur ne les affiche pas (remplace par chaîne vide)

Il arrive que dans ce fichier se trouvent certains caractères illisibles par mon appli, je ne sais pas pourquoi ni comment les reconnaître, je ne peux pas me permettre de mettre en place un .replace() sur une liste non exhaustive de caractères, je cherche un moyen de transformer tout caractère "illisible" en son équivalent "standard"

Ca ne semble pas possible?

[adiGuba]

==> La chaîne est correctement stockée en BDD avec le tiret long et apostrophe incliné.
A la restitution des données, j'observe des "carrés" dans le retour de mon WS indiquant que les caractères ne sont pas reconnus, et le navigateur ne les affiche pas (remplace par chaîne vide)

Comment s'effectue la "restitution des données" ?


a++

[oni13]

Pour faire simple, il s'agit de lire une donnée en BDD et de restituer le résultat sous forme de String.
Pas de traitement particulier sur la chaîne si ce n'est une "JSONification"

Mon serveur expose un WS retournant du application/json; charset=utf-8 géré avec les WS Spring

En debugg sur mon serveur (eclipse), j'observe déjà que les caractères sont remplacés par une chaine vide directement après la lecture en base, mais les caractères sont bien présents, je le sais si je lis byte/byte.
Une fois transmis au client, il y a des "carrés" à la place

Edit: J'ai pu noter sur le caractère "tiret long" était un couple de byte négatifs (je dis au hasard disons -60 et -102) pour un seul caractère, alors que tous les autres sont des byte positifs seuls(au hasard encore A = 32). C'est pour ça que je pensais à un problème d'encodage ou autre... je pense que c'est ça qui bloque quelque part

[adiGuba]

Si tu obtiens des "carrés" c'est que tu as bien un problème d'encodage quelque part, donc il faut revoir toutes tes créations/lectures de chaine de caractères.

Cela apparait sur ces caractères car ce sont des caractères spéciaux dont l'encodage varie selon le charset (contrairement aux caractères ASCII qui sont quasiment toujours encodé de la même manière).



J'espère que tu n'utilises pas ta méthode decodeUtf8() car c'est le genre de truc qui peut poser ce genre de problème.



a++

[oni13]

Est-il possible que certains caractères soient encodés différemment que le fichier?

je pense à excel, qui pourrait considérer son fichier ISO_8859_1, et suite à un malencontreux copier coller insère des "mauvais caractères".
Du coup de mon côté je lis un fichier en ISO_8859_1 et je ne reconnais pas ces caractères:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

final Reader reader = new InputStreamReader(new FileInputStream(tempFile), Charsets.ISO_8859_1);

Pour info, si je lis mon CSV en UTF-8 j'obtiens des � qui sont affichés tel quel sur le navigateur : Info � changement d�adresse ==> je vois aussi ces � en BDD
Si je lis mon fichier en ISO_8859_1 j'obtiens ces fameux "carrés" qui ne sont même pas affichés sur le navigateur : Info changement dadresse ==> Mais dans ce cas, tout est OK en BDD

Ce dont je vous parle depuis le départ est issu d'une lecture en ISO_8859_1. Je n'utilise pas ma méthode decodeUtf8, je l'ai mise en place pour tenter de résoudre le problème, sans succès


Je ne sais pas si cela vous donne plus d'idées, sinon probablement que cela vient du fichier en entrée lui même et que je n'y peux rien côté serveur?

Merci en tout cas

[adiGuba]

Il faut connaitre le traitement dans sa globalité.

L'encodage doit être spécifié à chaque fois qu'il y a une conversion byte=>String ou inversement, sous peine d'avoir ce genre de problème.


Tu dis que les données sont correcte dans la BD ?
Comment les récupères-tu ?
As-tu loggé juste après pour voir si c'était ok ou pas ?


a++

[oni13]

Les données sont récupérées via hibernate, avec rien de plus qu'une query sur une propriété String/varchar2
En regardant la BDD avec d'autres outils je vois que la chaîne est bien complète (SQLdevelopper)

La BDD et le serveur d'appli sont en UTF-8
Effectivement le fichier est en ISO mais je pensais qu'il n'y aurait pas de souci

Bon du coup je ne vois pas, je vais en effet tenter de logger partout mais c'est étrange

[thelvin]

Tu te rends bien compte que si tu attachais tout simplement ce fichier ici nous pourrions dire avec certitude ce qu'il contient, comment le lire et faire en sorte que son contenu arrive dans une String Java sans que tu aies besoin de réfléchir aux encodages après cette étape ?

[oni13]

Voici le fichier (le site n'autorise pas d'attacher des fichier .csv , j'ai mis l'extension en txt mais je l'utilise en tant que .csv)

Je n'y ai pas pensé car je ne pensais pas que ça viendrait du fichier mais des caractères... mais en effet

[thelvin]

Voilà.

Donc ce fichier n'est pas du tout en ISO, mais dans un charset dit "windows-1252".

Je n'ai pas la moindre idée d'où peut venir Charsets.ISO_8859_1 mais je suggère de remplacer par Charset.forName("windows-1252") .

À partir de là tu liras ton fichier sous forme de String qui sont parfaitement formées, et tu n'auras plus à te demander quoi faire pour l'encodage.
... À moins bien sûr qu'il y ait aussi des problèmes d'encodage plus loin dans le traitement, genre ce n'est pas vraiment de l'utf-8 ou ça ne marche pas avec les accents...

[oni13]

Cela fonctionne en effet en le lisant ainsi... merci

Cependant, comment faire pour savoir dans quel encodage lire un fichier?
Je dois accepter n'importe quel fichier csv et le lire sur le serveur.

J'avais opté pour l'utilisation de la librairie org.codehaus.guessencoding qui prend un fichier et "devine" son encodage, j'utilisais donc ce résultat (j'ai quand même testé avec plusieurs charset manuellement).

Y a-t-il un moyen de gérer le contenu de fichiers quel que soit l'encodage?

Autre question:
Comment as tu obtenu que le fichier était en windows-1252 ?
(hors sujet mais sait-on jamais) Y a-t-il une manipulation facile pour transformer l'encodage d'un fichier? Accessible pour un utilisateur lambda (je pense sur excel)

[adiGuba]

Y a-t-il un moyen de gérer le contenu de fichiers quel que soit l'encodage?

Il n'y a pas de moyen facile et sûr, car un même codage peut représenter des caractères différents selon le charset.


Et c'est typiquement ton cas : les charsets windows-1252 et ISO-8859-1 sont identique, mis à part une plage de caractères.
En windows-1252 cette plage contient des caractères spéciaux (contenant entre autre les 2 caractères posant problèmes ici)
En ISO-8859-1 cette même plage contient des codes de contrôles... bref des caractères non-imprimable (d'où les carrés ou point d'interrogation)



a++

[oni13]

Ok je tombe donc sur un cas particulier mais j'aurais toujours de potentiels problèmes.

Je ne peut donc proposer que la prise en compte de fichiers csv encodés sur un format unique et défini (exemple UTF-8).
==> De toutes façons ma librairie semble ne pas avoir reconnu l'encodage de ce fichier..

Or si jamais l'un d'entre eux arrive avec un fichier windows-1252 j'ai l'impression que je(le serveur) ne pourrai pas lui crier dessus, étant donné que java arrivera quand même à lire le fichier et stockera des caractères qu'il considère légitimes même si à nos eux ils sont dégeux.

C'est bien un problème que je ne peux pas résoudre?

Sauriez vous m'expliquer pourquoi Excel (par exemple) arrive à s'y retrouver à l'affichage quel que soit l'encodage? idem notepad
java n'est-il pas encore assez au point pour gérer cela? Je suppose que je ne comprend toujours rien à l'encodage mais justement...

[adiGuba]

Excel et notepad ne font pas mieux.
C'est juste que "windows-1252" est l'encodage par défaut de nos Windows européens, et qu'ils doivent le prendre en priorité sur l'ISO-8859-1...
Par exemple si tu as un fichier ISO-8859-15 avec le caractère EURO ($), il y a de forte chance qu'il ne soit pas lu correctement sous notepad ou excel...


Pour l'UTF on peut à peut prêt détecter l'encodage car il y a des séquences incorrectes, mais pour tous les charsets 8bits c'est très difficile car toutes les codes sont associé à une valeur.


Si tes clients sont sous Windows tu devrais utiliser du windows-1252 par défaut pour éviter un max d'erreur, mais cela ne réglera pas tout.


a++

[tchize_]

Je ne peut donc proposer que la prise en compte de fichiers csv encodés sur un format unique et défini (exemple UTF-8).

Ou demander à l'utilisateur de préciser quel encodage a été utilisé

Or si jamais l'un d'entre eux arrive avec un fichier windows-1252 j'ai l'impression que je(le serveur) ne pourrai pas lui crier dessus, étant donné que java arrivera quand même à lire le fichier et stockera des caractères qu'il considère légitimes même si à nos eux ils sont dégeux.

D'où l'intérêt dans ce genre de cas de présenter les données après décodage à l'utilisateur pour confirmation.

C'est bien un problème que je ne peux pas résoudre?

Difficile. Il existe plusieurs formules pour essayer de deviner l'encodage. Mais sérieusement, entre les différents code page 125x de windows, il est déjà impossible de distinguer. Ici on a supposé que c'était du 1252 puisque: 1 on a rien de "bizarre" quand on lit, 2 tu est francophone donc ce n'est probablement pas un code page turc ou grec qui a été utilisé.
En fait, entre les différents iso 8859-x et les code page windows ou l'ascii, il y a peu de différences. Suffisamment pour sortir du caca, pas assez pour détecter automatiquement. C'est un problème que tu peux résoudre dans un domaine restreint, mais pas globablement. Par exemple, si tu sais qu'on est face à un public francophone, tu peux tenter tous les encodage typiques d'un francophone et rejeter dès que tu as un caractère hors norme. A toi de définir alors ce que tu accepte comme caractères.

Sauriez vous m'expliquer pourquoi Excel (par exemple) arrive à s'y retrouver à l'affichage quel que soit l'encodage? idem notepad

Il n'y arrive pas. Sur certains fichiers il devine bien, parfois il est à coté de la plaque.
https://blogs.msdn.microsoft.com/old...17-00/?p=27223

java n'est-il pas encore assez au point pour gérer cela? Je suppose que je ne comprend toujours rien à l'encodage mais justement...

Si tu découvre un algorithme qui a bon dans 100% des cas, tu deviendras riche ^^

[oni13]

Merci à vous pour les explications.

Je pars donc vers une solution de lire en priorité le windows-1252 pour lire les CSV reçus.
Vu que dans mon cas certains fichiers ne sont pas générés sous windows il faudra probablement le lire autrement, pour ce cas, je pars sur le "présenter le résultat à l'utilisateur" et proposer de tenter un autre encodage si cela ne lui convient pas.

A+

[dimanche2003]

Avec Lazarus (1.6.2), la solution est simple : l'outil Convertir le codage identifie les fichiers qui ne sont pas au format (ici CP1252).
Un clic sur le bouton Convertir suffit pour rétablir la situation, et... l'affichage devient correct, sans manipulation supplémentaire.
Sans Lazarus, c'est simple également : NotePad++ identifie également les codages et permet la conversion en UTF8 sans problème.