Discussion :

[enzostar]

Bonjour, je reçois via le protocole http une chaine formatée en json dans mon appli.
Seulement les caractère spéciaux comme {}"sont encodés par http en %22, %7B...
Le sachant, j'aimerais remplacer ces caractères. J'utilise la fonction replace mais ça ne marche pas pour ces séquences de caractères alors que ça marche pour tous les autres.

Quelqu'un aurait une idée ?

[Alkhan]

bonjour

Cela ne pose aucun problème de remplacer %22 par un caractère !!

Ton code serait le bien venu !

[enzostar]

le voila:

Code :

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

1
2
String fax = (String) this.getRequestAttributes().get("fax");
fax.replaceAll("-"," ");

autant pour moi, j'ai compris mon erreur. Etant donné que replaceAll() retourne une String, je dois affecter une variable de ce type pour la réuitiliser.

Code :

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

1
2
String fax = (String) this.getRequestAttributes().get("fax");
String fax_modif=fax.replaceAll("-"," ");

[thelvin]

Bon à savoir : une String ne peut pas être modifiée.

Toute méthode de traitement de String doit donc obligatoirement en retourner une nouvelle, qui sera le résultat du traitement. La String d'origine ne sera pas modifiée, car on ne peut pas modifier une String.

[Dont-x]

Sinon, on peut utiliser StringBuffer qui est modifiable. (gain de perfs)
Voir aussi StringBuilder (encore + rapide mais pas syncro /!\ aux erreurs)

[thelvin]

Sinon, on peut utiliser StringBuffer qui est modifiable. (gain de perfs)

Oui enfin, replaceAll() utilise déjà un StringBuffer, donc dans le cas présent, on ne peut pas dire qu'il y ait gain de perf. C'est bon à utiliser quand on construit soi-même la String.
Enfin bon, le problème dont on nous parle là, devrait être résolu avec URLEncoder.encode() (qui s'en sert lui aussi.)

Voir aussi StringBuilder (encore + rapide mais pas syncro /!\ aux erreurs

Les erreurs sont très peu probables. Il y a un risque si plusieurs threads doivent accéder en même temps au StringBuilder. Dans ce cas-là il vaut mieux synchroniser et utiliser un StringBuffer.
Mais quand est-ce qu'on a plusieurs threads qui accèdent à ça ? En réalité on ne programme jamais ça.

replaceAll() utilise StringBuffer parce qu'il est basé sur Matcher. Matcher ne devrait pas utiliser StringBuffer vu qu'on ne devrait pas s'en servir avec plusieurs threads. Mais il date de l'époque où StringBuilder n'existait pas et seul StringBuffer existait. Aujourd'hui, il est trop tard pour changer, car il existe peut-être des programmes qui comptent sur le fait que Matcher utilise StringBuffer. Si StringBuilder avait existé dès le début, ce serait lui.