Salut,
 
j'utilise les commons file upload du projet jakarta pour faire de l'upload de fichier.
Lorsque je teste sur mon WAS local (4.1 sur Win 2000), ça marche sans problème.
Mais lorsque je teste sur le WAS de préprod, ça ne marche pas; la servlet ne reçoit rien.  
 
Dans mon formulaire j'ai un champ de type file et un checkbox; aucun des deux n'est "reçus" dans la servlet. (la liste d'items pour reprendre le code donné par le site jakarta a une taille de 0).
 
Le WAS de préprod est installé sur OS390.
 
Ce n'est pas un problème de droit ni de path du répertoire de stockage temporaire (j'ai vérifié) : le parsing de la requête ne retourne aucun champ de formulaire.
 
Merci de votre aide.
Nestor.

Nestor,
 
c'est un problème au niveau du common-fileupload de Struts que j'ai remonté y'a quelques temps (j'ai eu exactement le même problème que toi sur le même environnement) :
http://www.mail-archive.com/common [...] 33928.html
Pour l'instant, il va falloir que tu patches manuellement la classe "FileUploadBase" comme c'est écrit et que tu reconstruises le jar. Il faudra alors que tu ajoutes un appel à la méthode setHeaderEncoding("8859_1" ) par exemple avant de récupérer les données du DiskFileUpload.
Le bug est en cours de résolution pour la prochaine release, à ce que j'en sais.

Ok ben merci pour l'info.  
 
Je vais essayer ta méthode mais après avoir lu ta déclaration de bug je peux te dire que dans l'en-tête http tu as bien l'encoding de la requête.
 
Je bricole tout ça demain.
 
Extrait de la javadoc :
 
getCharacterEncoding
 
public java.lang.String getCharacterEncoding()
 
    Returns the name of the character encoding used in the body of this request. This method returns null if the request does not specify a character encoding

    Returns:
        a String containing the name of the chararacter encoding, or null if the request does not specify a character encoding
 

Je viens de tester ta solution et ça marche : merci beaucoup.
 
Nestor.

Je ne suis pas sur à 100% de ce que je vais dire, mais ça retourne (éventuellement ... certains "vieux" browsers ne le renseignent pas donc retour null) l'encodage du body. L'encodage du header (dont tu as besoin pour le boundary) peut être différent de celui du body.  
 
C'est pour ça que j'avais écrit qu'on ne pouvait déterminer cet encodage de façon certaine, et donc qu'il fallait utiliser une méthode "empirique".
 
Un autre truc : imagine un header encodé en coréen (ISO-2022). Comment je fais pour "décoder" ce header (et donc récupérer la valeur "ISO-2022" en faisant un getCharacterEncoding()) si je ne connais pas l'encodage ?  
 
Je risque de ne jamais "voir" le tag du header d'ailleurs ...  
 
Je n'ai pas fouillé les RFC, mais il y a certainement une phrase quelque part qui dit que l'encodage du header doit être quelque chose de "standard", ie toutes les variantes de l'US-ASCII.
 
J'ai le même "problème" d'ailleurs avec XML ...
 
Mais je suis peut être à côté de la plaque ...
Benou peut être ?    
 
Edit : plein de retour charriot en plus ...

Il me semble bien que les headers doivent entre en US-ASCII ...  
 
c'était bien ca ta question ?
 
 
Par contre je vois pas le rapport avec le XML

Euh ... là je viens de me rendre compte de ma bêêtise je crois ...
 

Est-ce que ça veut pas dire que tout le document est encodé comme ça, ou seulement le "contenu" à l'intérieur des balises  
Je suis tout perdu d'un coup ...  
 
Edit : et oui, c'était bien là ma question ...

C'est une bonne question ca ...
moi je dirais que tout ce qui suit le header XML est encodé en ISO-2022

Ca me parait plus logique aussi.
Mais le header ? Toujours en US-ASCII ou équivalent ?
Je trouve ça bizarre d'avoir 2 encodages différents dans un fichier ... Non ?
Et s'il y a un seul encodage, comment "décoder" ce header ?
Il doit y avoir un truc qui m'échappe ...

En XML, le header est forcément en US-ASCII et n'utilise que les 126 premiers caractères : ca permet à un parser de lire l'encoding et ensuite de savoir quel charset utiliser pour le reste du fichier.
 
Donc il y a effectivement 2 encoding différents pour le même fichier. Mais de toute façon, dans la plupart (tous ?) des charset, les 126 premiers chars sont codés sur un octet, donc ca ne change rien ...