problème de génération de requête XML avec le protocole XML-RPC en objective-c

2»

Réponses

  • AliGatorAliGator Membre, Modérateur
    11:04 modifié #32
    dans 1229615391:

    Pardon je me suis trompé je voulais dire NSData car je doit passer dans la requête XML un type <base64> pour passer mes données codées en base64.

    Merci

    aaaah ouais je comprends mieux parce que là  je me disais ça part en vrille là  à  encoder des NSDate en base64 ^^
  • AliGatorAliGator Membre, Modérateur
    11:04 modifié #33
    dans 1229611600:

    Merci pour vos conseils, le code correspond correctement à  ce que je voulais faire.

    Par contre NO je n'arrive pas à  déclarer un NSDate encoder en base 64 comme j'avais pu le faire pour   le nombre en NSNumber.

    Tu veux dire que si tu crées ton [tt]NSData* d[/tt] dans un coin (genre [tt]NSData* d = [NSData dataWithBytes:"toto" length:4];[/tt]), puis que tu fais, pour reprendre le code de No, [tt][member setObject:d forKey:@mesdata];[/tt], après ça fait quoi...? Il plante quand il essaye de créer la requête XML-RPC ? ou te met un message particulier ? Ou il crée la requête mais il n'encode pas tes données de ton NSData en base64 (tu vois "toto" et pas sa version encodée en base64 "dG90bw==") ? Ou bien...?
  • JijoJijo Membre
    11:04 modifié #34
    Merci tu as parfaitement répondu a ma question AliGator.
  • JijoJijo Membre
    11:04 modifié #35
    J'ai encoder un fichier en base 64 en utiisant la fonction  dataWithContentsOfFile que j'ai trouvé ici :

    http://developer.apple.com/DOCUMENTATION/Cocoa/Conceptual/BinaryData/Tasks/WorkingBinaryData.html#//apple_ref/doc/uid/20000717

    NSString * thePath = @/Users/nomUser/Desktop/test.png;
    NSData * myData = [NSData dataWithContentsOfFile:thePath];
    [member setObject:myData forKey:@data];

    Cependant le serveur qui reçoit la requête avec les données en base 64 ne reconnaà®t pas le fichier et me signale un fichier vide.

    codage en base 64 par le site http://www.motobit.com/util/base64-decoder-encoder.asp :
    iVBORw0KGgoAAAANSUhEUgAAAAYAAAAGCAIAAABvrngfAAAPS2lDQ1BJQ0MgUHJvZml
    ...
    ...
    ...
    ufdaGWk04iRUxB9NQymTaVXxLQAAAABJRU5ErkJggg==

    codage en base 64 que j'envoie dans la requête :
    <base64>
    \n\n\t\t\t\tiVBORw0KGgoAAAANSUhEUgAAAAYAAAAGCAIAAABvrngf\n\t\t\t\tAAAPS2lDQ1BJQ0MgUHJvZml
    ...
    ...
    ...
    \n\n\t\t\t\tufdaGWk04iRUxB9NQymTaVXxLQAAAABJRU5ErkJggg==\n\n
    </base64>


    Je ne sais pas pourquoi  des \n et \t apparraissent. Sinon la séquence de code est identique dans les 2 cas.

    Merci

  • JijoJijo Membre
    11:04 modifié #36
    Personne n'aurai une petite idée?


    Sinon quelle alternative aurai-je pour contourner ce problème ?
  • NoNo Membre
    décembre 2008 modifié #37
    dans 1229768522:

    Je ne sais pas pourquoi  des \n et \t apparraissent. Sinon la séquence de code est identique dans les 2 cas.

    Les \n et \t n'apparaissent que dans la log. Ce n'est pas transmis au service web.
    Pour ton problème, difficile de t'aider.
    L'erreur peut aussi provenir du service lui même (est ce le bon format d'image qu'il attend - un png ici- ).
    Essai avec un jpg ou un gif pour voir.
    As tu vérifié que la <base64> est correctement transmis avec le bon nom de paramètre ?
    Mais sans documentation des paramètres d'appel du service, je ne peux pas aller plus loin.
  • AliGatorAliGator Membre, Modérateur
    11:04 modifié #38
    Pareil, il semble que le codage base64 est le bon, de toute façon les \t et \n sont ignorés dans un XML et même dans un codage base64, donc même s'ils sont transmis (et à  moins que le service web de l'autre côté soit mal codé) ça ne pose pas de soucis...
  • JijoJijo Membre
    11:04 modifié #39
    Encore une fois vous aviez raison.



    Merci.
Connectez-vous ou Inscrivez-vous pour répondre.