Donc, j'essaie de poster quelque chose à un serveur WebServer.
System.Net.HttpWebRequest EventReq = (System.Net.HttpWebRequest)System.Net.HttpWebRequest.Create("url");
System.String Content = "id=" + Id;
EventReq.ContentLength = System.Text.Encoding.UTF8.GetByteCount(Content);
EventReq.Method = "POST";
EventReq.ContentType = "application/x-www-form-urlencoded";
System.IO.StreamWriter sw = new System.IO.StreamWriter(EventReq.GetRequestStream(), System.Text.Encoding.UTF8);
sw.Write(Content);
sw.Flush();
sw.Close();
3 Réponses :
peut-être faire comme plus facile: ou voir ici pour une discussion permettant une utilisation comme:
Vous n'avez pas besoin de définir le contenuLength explicitement, car il sera défini automatiquement sur la taille des données écrites dans le flux de demande lorsque vous le fermez.
Vous êtes vraiment correct; Cela corrige ce problème particulier. Mais utiliser Wireshark pour regarder le paquet qui est envoyé montre que StreamWriter est en train de préparer quelque chose aux données postales ... \ 357 \ 273 \ 277ID = 301RBU Où sont ces 3 octets provenant de ??? La longueur de contenu est définie sur 12 dans ce paquet.
@Jon Skeet a décrit ce puits (comme d'habitude =)) - Ceci est appelé Unicode octet-ordre de commande qui identifie si le texte est UTF-8, UTF-16 Big-16 Big-endian, UTF-16 Little -endien etc. En savoir plus ici en.wikipedia.org/wiki/byte-order_mark
D'autres réponses ont expliqué comment éviter cela, mais je pensais que je répondrais pourquoi cela se passe: vous finissez par un Mark d'octet avant votre contenu réel.
Vous pouvez l'éviter en appelant nouveau utf8encoding (faux) au lieu d'utiliser coding.utf8 . Voici un programme court pour démontrer la différence:
Bon endroit. Je pensa sur la creuse, mais ...
Vous êtes correct :) explique que l'observation sur \ 357 \ 273 \ 277 de Wireshark I fait dans l'autre commentaire. Merci beaucoup!