Discussion :

[master_och]

Bonjour

Bon sans trop dire voici un code source qui illustre le problème:

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
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
import java.awt.HeadlessException;
import java.awt.Toolkit;
import java.awt.datatransfer.DataFlavor;
import java.awt.datatransfer.StringSelection;
import java.awt.datatransfer.UnsupportedFlavorException;
import java.io.IOException;
 
 
public class ClipBoardTest {
	private static final String chaine="abc"+(char)0xFFFF+(char)0xFFEE+(char)0xFFFE;
 
	public static void main(String[] args) {
 
		try {
			//recuperation du contenu du Clipboard, qui provient de l'execution precedante
			String chaine_execution_precedente=null;
			if(Toolkit.getDefaultToolkit().getSystemClipboard().isDataFlavorAvailable(DataFlavor.stringFlavor))
				chaine_execution_precedente=
					(String)Toolkit.getDefaultToolkit().getSystemClipboard().getData(DataFlavor.stringFlavor);
			//******************************************************************************************
 
			//chaine et chaine_execution_precedante sont ils egaux ?
			if(chaine_execution_precedente!=null)
				System.out.println(chaine.equals(chaine_execution_precedente));
			//*********************************************************
 
 
			//exportation de la chaine
			StringSelection ss=new StringSelection(chaine);
			Toolkit.getDefaultToolkit().getSystemClipboard().setContents(ss, ss);
			//******************************************************
 
			//importation de ce qu'on vient d'exporter
			String chaine_execution_courante=null;
			if(Toolkit.getDefaultToolkit().getSystemClipboard().isDataFlavorAvailable(DataFlavor.stringFlavor))
				chaine_execution_courante=
					(String)Toolkit.getDefaultToolkit().getSystemClipboard().getData(DataFlavor.stringFlavor);
 
			//chaine et chaine_execution_courante sont il egaux ?
			if(chaine_execution_courante!=null){
				System.out.println(chaine.equals(chaine_execution_courante));
			}
			//***********************************************************
 
		} catch (HeadlessException e) {
			e.printStackTrace();
		} catch (UnsupportedFlavorException e) {
			e.printStackTrace();
		} catch (IOException e) {
			e.printStackTrace();
		}
 
	}
 
}

Si vous executer ce code 2 fois successives, vous remarquerez que le String chaine qui a été exporté vers le SystemClipBoard, a été récupéré correctement dans chaine_execution_courante lors de la premiere execution, mais lorsqu'on est passé a la deuxieme exéccution et on a essayé de le récupéré dans chaine_execution_precedante on a pas obtenu le même resultat !

Quelqu'un connait-il la cause ?!
__________________________________________________________

Maintenant au cas où vous vous dites : mais pourquoi il teste un truc pareil ce c...
Et bah c'est que je souhaite faire communiquer des applications JAVA differentes sous forme de messages, que j'ai codé suivant un algorithme un peu particulier, et qui seront decodés a la reception. Ces messages sont de type String, et il faut que je les communique a traver le SystemClipBoard.

Voilà le probleme c'est que le message codé change lorsqu'il provient d'une autre application.
________________________________________________________________

Y a-t-il un moyen de recuperer le version originale du message, a partir d'une application n'etant pas le ClipBoardOwner et sans qu'il soit modfié?

Merci d'avance!

[thelvin]

Je suis pas spécialiste de ce genre de choses, mais il semble que Java n'aime pas du tout le caractère 0xfffe quand il importe des données d'un presse-papier qu'il ne contrôle pas.
Pour des raisons qui m'échappent, il le transforme en 0xfffd, et, ben, je ne vois rien du tout à y faire.

Vu que 0xfffe et 0xffff sont des non-caractères c'est une limitation acceptable de ne pas les gérer en tant que caractères.
Si c'est nécessaire quand même, je ne vois pas de workaround. À part les encoder, genre mettre  à la place, et gérer soi-même l'encodage et le décodage.

[master_och]

Le problème c'est que 0xfffe et 0xffff ne sont pas les seuls caracteres que JAVA n'aime pas, j'ai fait beaucoup de testes en prenant a chaque fois une plage de caractereS allant de 0 jusqu'à une valeur que j'ai fait varié, j'y suis arrivé jusqu'à 97(dec) et ca n'a pas encore voulu fonctionné.

J'ai posté dans le Forum de Sun (même s'il fait partie d'ORACLE désormé), et là ils m'ont donné une petite intuition qui m'a conduit à coder mes characteres dans une plage allant de 33(dec) jusqu'à 127(dec) et là ca a enfin marché même si c'est pas très satisfaisant niveau consommation mémoire.
Mais bon pour me satisfaire un peu j'ai utilisé le codage de 0 a 0xffff lorsqu'il s'agit d'un enregistrement dans la base de données (Derby n'a aucun problème avec ces caractères spéciaux), et je n'ai utilisé la plage allant de 33(dec) à 127(dec) que pour la communication avec le presse papier.

En tout cas merci bien pour ton intervention.

[thelvin]

N'exagérons rien. D'après mes tests, tout ce qui est un vrai caractère dont Unicode ne déconseille pas l'emploi dans un flux de caractère, marche très bien. Ceux du BMP, du moins, je n'ai pas testé au-delà.

D'aucuns pourraient dire qu'il n'y a pas qu'Unicode dans la vie et que certains vieux trucs utilisant les caractères de contrôle Unicode existent toujours. Oui, bon, mais avec le presse-papier ?

[master_och]

N'exagérons rien. D'après mes tests, tout ce qui est un vrai caractère dont Unicode ne déconseille pas l'emploi dans un flux de caractère, marche très bien

Ta tout à fait raison en fait, ton dernier poste m'a mener à revérifier en elliminant le character 0, et il s'est avéré que c'était lui le provoqueur de problèmes.
Apparament tous les caractères de de 1 à 0xFFFD sont fonctionnels.

Merci beacooup mon ami, ton aide m'a été d'une grande utilité.