Comment coder HTTP paramètres POST (client C#, PHP Serveur)?

Je vais avoir de la difficulté à déterminer la meilleure façon d'encoder les paramètres POST à un serveur d'appel. J'ai écrit un client C# qui sera servi par un serveur PHP. Je veux permettre une grande souplesse dans les paramètres, donc mon plan actuel est d'avoir un seul paramètre que j'utilise JSON pour l'encodage. Par exemple:

params = {"object":"Main","function":"doecho","params":["echothis...."]}

Je suis en utilisant le C# objet WebRequest et contentType "application/x-www-form-urlencoded; charset=UTF-8". Les données sont sur le serveur et tout fonctionne comme prévu jusqu'à ce que je ajouter illégale JSON caractères dans les données.

Par exemple, si j'utilise les données suivantes, alors je ne peux pas faire un json_decode sur elle sur le côté serveur. Le serveur s'affiche automatiquement l' %40 dans un guillemet double (") quand je l'ai lu avec $this->getRequest()->getParams(); (zend framework).

params = {"object":"Main","function":"doecho","params":["echothis%25%5d%22%40%3d%26...."]}

Quelle est la meilleure pratique ici? Dois-je en base64 encode les données? Est-il quelque chose d'évident qui me manque avec le type de contenu ou un php?

J'ai le plein contrôle sur le client et le serveur, donc je voudrais savoir quelle est la bonne/meilleure chose à faire.

OriginalL'auteur Jeff | 2011-10-26

  1. 11

    Bien que potentiellement tout type de contenu peut être utilisé pour télécharger des HTTP, il y a trois utilisés dans la pratique:

    1. Spécifiquement définie par un service donné de la documentation.
    2. application/x-www-form-urlencoded - la valeur par défaut utilisée par les formulaires HTML.
    3. multipart/form-data - autre forme utilisée par les formulaires HTML, nécessaire lorsqu'il comprend le formulaire de téléchargement.

    En raison de 2 et 3 étant alors couramment utilisés (comme ils sont pris en charge par tous les navigateurs pour l'envoi de formulaires), à peu près tous les côté serveur tech a des choses à gérer. Donc, à moins que la partie PHP n'quelque chose d'étrange, vous devriez être en mesure d'utiliser.

    application/x-www-form-urlencoded n'est pas approprié pour certaines données, mais est le plus simple pour ce qu'il est utilisé pour. C'est à peu près la même que la façon de requête-chaînes sont créées pour OBTENIR le formulaire de demande, mais aussi de publier du contenu.

    Où vous voulez que votre contenu à être:

    "params=" + Uri.EscapeDataString(paramData)

    Le premier devient:

    params=%7B%22object%22%3A%22Main%22%2C%22function%22%3A%22doecho%22%2C%22params%22%3A%5B%22echothis....%22%5D%7D

    Et la deuxième:

    params=%7B%22object%22%3A%22Ccmes_Main%22%2C%22function%22%3A%22doecho%22%2C%22params%22%3A%5B%22echothis%2525%255d%2522%2540%253d%2526....%22%5D%7D

    Deux de PHP-ins vont retourner dans les formulaires dans votre question.

    Oui, cela a du sens pour moi. Merci!
    Parce que nit-picking peut empêcher les insectes, note que "params" (mais pas le "=") doit également être URI-codées. Parce que je sais que "params" quand URI codé est toujours "params", je n'ai pas comme un raccourci, mais si c'était "párams" ou "params", alors il devrait être.

    OriginalL'auteur Jon Hanna

  2. 1

    Ma première pensée a été l'encodage en base64. Je pense que cela devrait être le simplie.

    De arcanecode.com: 

    static public string EncodeTo64(string toEncode)
{
  byte[] toEncodeAsBytes = System.Text.ASCIIEncoding.ASCII.GetBytes(toEncode);
  string returnValue = System.Convert.ToBase64String(toEncodeAsBytes);
  return returnValue;
}
    Si le premier exemple travaillé, alors ce ne peut pas être correcte, car le premier exemple n'est pas en Base 64.
    Jon Hanna, la EncodeTo64 fonction (réponse du hichaeretaqua), c'est juste pour encoder la chaîne dans un Heximal représentation des Octets ASCII.

    OriginalL'auteur 0xBADF00D