[String]comparaison de différence

Version imprimable

Voir 40 message(s) de cette discussion en une page

31/10/2005, 13h37
Regis.C
Bon alors les nouvelles du front :
Code:

1 2 3 4 String test = "k9\u0000"; System.out.println(test);
En console j'obtient enfin :

Code:

k9

Reste à savoir comment remplacer tous les caractère de ce type par le code "U0000" coresspondant sachant que replaceAll() ne fonctionne pas avec ce genre de cas apparement...

Il s'agit de Unicode 4.1 qui contient ce genre de caractère :
http://www.unicode.org/versions/Unicode4.1.0/

Le problème est que je ne sais pas du tout comment utiliser ce genre de chose dans mon cas.
Quelqu'un a-t-il déjà eu à utiliser ce processus ?
31/10/2005, 15h02
Debernad
En faite, la plupart de tes soucis provienne du fait que tu utilise une String pour récupérer une image ...
Et cela produit plein de complications !
Car c'est un peu comme si tu voulais qu'une banane se transforme en carrote ...
Ca a la même forme et pourtant l'un est un fruit, l'autre un légume ...

L'objet String va partir en vrille avec les différents encodages car tu essaie de traiter des caractéres qui sont incompréhensible et lui il essaye tout bonnement de leur trouver une signification logique...
Résultat, les caractéres de contrôle (ou autres) qui ne sont pas affichable graphiquement vont être tranformé par des ?, ce qui fausse tout ton affichage !

Le mieux dans ton cas et d'utiliser le tableau d'octet => byte[]
Afin de traiter ton image en tant que suite d'octet et non en tant que chaine de caractére...
Et normalement, tous tes problémes se résolveront.

Ainsi au lieu d'afficher une String, affiche la suite d'octet :
Code:

1 2 3 4 5 6 7 8 9 byte[] b = ...; System.out.print("Suite d'octet : "); for(int i=0;i<b.length;i++) { if(i!=0) System.out.print(","); System.out.print(b[i]); } System.out.println();
Ce code va affiche la valeur numérique de chaque octet séparé par des virgules. Tu peux aussi l'afficher sous forme hexadécimal si tu le souhaites ...
Et ensuite tu fais tes comparaisons sur les 2 suites d'octet issue de tes 2 sources de données.

PS : Ha oui, j'allais oublié de préciser que tu a crié tellement fort lors de ton précédent post que l'on t'entends jusqu'au bout du forum :P Donc relax ;)
31/10/2005, 15h26
Regis.C

Citation:

Envoyé par Debernad

En faite, la plupart de tes soucis provienne du fait que tu utilise une String pour récupérer une image ...
Et cela produit plein de complications !
Car c'est un peu comme si tu voulais qu'une banane se transforme en carrote ...
Ca a la même forme et pourtant l'un est un fruit, l'autre un légume ...

L'objet String va partir en vrille avec les différents encodages car tu essaie de traiter des caractéres qui sont incompréhensible et lui il essaye tout bonnement de leur trouver une signification logique...
Résultat, les caractéres de contrôle (ou autres) qui ne sont pas affichable graphiquement vont être tranformé par des ?, ce qui fausse tout ton affichage !

Enfin quelqu'un qui me comprend ! :cry: :D

Citation:

Envoyé par Debernad

Le mieux dans ton cas et d'utiliser le tableau d'octet => byte[]
Afin de traiter ton image en tant que suite d'octet et non en tant que chaine de caractére...
Et normalement, tous tes problémes se résolveront.

He bien pas vraiment... :cry: :cry:
Mon appli utilise des String pour le traitement...et je ne crois pas que je puisse transformer mon code pour qu'il puisse gerer des octets de façon triviale... :cry:

Citation:

Envoyé par Debernad

PS : Ha oui, j'allais oublié de préciser que tu a crié tellement fort lors de ton précédent post que l'on t'entends jusqu'au bout du forum :P Donc relax ;)

:lol: :lol: :lol:
C'est que j'imaginais qu'il suffisait de télecharger l'Unicode 4.1 et de le considerer comme une api et j'étais pressé de savoir, croyant avoir découvert mon saint Graal... :cry:
31/10/2005, 15h48
Regis.C

Admettons que je puisse utiliser les suites d'octets.
Puis-je réecrire les octets directement dans un fichier ensuite, qui pourra- être relu normalement ?
31/10/2005, 15h53
Debernad
Biensur !
Code:

1 2 3 4 5 byte[] b = ...; FileOutputStream outfile = new FileOutputStream(...); outfile.write(b); outfile.close();
Tant que tu n'utilise pas des filtres tel que BufferedWrite ou BufferedRead mais uniquement FileInputStream et FileOutputStream, il n'y aura pas de transformation ou altération de ta suite d'octet ...
31/10/2005, 16h04
Regis.C

Houlla, ça me parait chaud...
Il faut que j'arrive à stocker d'un un seul objet chaque octet traité...
Il va falloir que je mette en route la machine à méninges !!! :roll:

Pas forcément ... tu peux écrire plusieurs fois des paquets de byte[] les uns a la suite des autres
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 FileOutputStream outfile = new FileOutputStream(...); byte[] b = ... ; outfile.write(b); b = ... ; // affecte une nouvelle suite d'octect (nouveau paquet) outfile.write(b); b = ... ; // affecte une nouvelle suite d'octect (nouveau paquet) outfile.write(b); b = ... ; // affecte une nouvelle suite d'octect (nouveau paquet) outfile.write(b); outfile.close();
A toi aprés de faire le découpage qui te convient pour traiter tes données sans occuper trop d'espace mémoire à in instant t !

31/10/2005, 16h14
Regis.C

Haaaa!
Je n'arrive pas à transformer un byte en quelque chose d'utilisable genre int, ou String.... :cry:

Code:

1
2
3
4
5
6
7
 
byte[] b = ... ;
for(int i=0;i<b.length;i++)
{
       int entier = (int)b[i];
       System.out.println("Entier = "+entier);
}

31/10/2005, 20h49
Regis.C

Le problème avec le choix d'utiliser les octets, c'est que je me retrouve à devoir enregistrer un fichier beaucoup plus lourd de plusieurs dizaines de kilos (voir centaines!) par rapport au fichier d'origine.

En utilisant le code fournis au départ (source = Gfx) j'obtiens un fichier de 5 ou 10 Ko de plus avec mon traitement car je garde la forme du texte d'origine. Bon, ok, avec cette methode, j'ai le fameux problème des caractères Unicodes 4.1...

Mais j'avoue être surprit que pour quelques caractères non-prit en compte par l'Unicode je doivent changer l'architecture et lire mes fichiers par les octets... :roll:

N'y a-t-il pas la possibilité d'upgradé le standard Unicode utilisé par la JRE de manière à ce que tous les caractères soient pris en compte ?
(sachant que c'est cette JRE qui sera utilisée par le logiciel)

Je suis perplexe... :roll:

Je suis d'autant plus perplexe qu'au boulot sous win98 je vois parfaitement les cractères qui me posent problème (ainsi que le ce forum) et que chez moi en win XP je ne vois pas les caractères affichés sur le forum...à la place il y a un blanc...
Ce doit être assez difficile à comprendre pour ceux qui ne voient pas le caractère sur leurs ecrans !!! :lol:

Voir 40 message(s) de cette discussion en une page