J'ai une application .NET qui essaie de ftp un fichier mais je me retrouve avec 1 octet supplémentaire par ligne. Mon séparateur de ligne est Environment.NewLine, qui, je crois, se traduit par \ n \ r. Combien d'octets est-ce?Combien d'octets est n r?
est de 2 octets.
Deux octets. Un pour \ n et un pour \ r.
Il est 2 octets, mais il devrait être \r\n pas \n\r sur les fenêtres OSs
Cela dépend de l'encodage. Dans les codages 8 bits ainsi que UTF-8, il s'agit de 2 octets. Dans UCS-2 ou UTF-16, il s'agit de 4 octets. Dans UCS-4 ou UTF-32, il s'agit de 8 octets.
Mais le problème est que vous êtes probablement FTP en mode ASCII au lieu du mode IMAGE.
En codage ASCII, \ n est le caractère Newline 0x0A (décimal 10), \ r est le caractère Carriage Return 0x0D (décimal 13). Comme Jack l'a déjà dit, la séquence correcte est CR-LF, et non l'inverse.
FTP ajoute probablement des caractères LF à votre flux s'ils ne sont pas placés correctement et que vous transmettez le fichier sous forme de texte.
Les logiciels FTP offrent généralement un mode de transfert binaire et texte. En mode texte, la traduction de la nouvelle ligne se produit pendant le transfert. Cela peut être une information valide, en fonction de votre problème et de la raison pour laquelle vous avez posé la question.
Pour répondre à la question implicite:
Pour utiliser transfert binaire plutôt que ascii-transfert en C#, utilisez
FtpWebRequest reqFTP = (FtpWebRequest)FtpWebRequest.Create(new Uri("ftp://example.com"));
reqFTP.UseBinary = true;
+1 pour mentionner encodages – Amber
Ne sont pas UCS-4 et UTF-32 la même chose? –
@ BlueRaja-DannyPflughoeft: Pour l'instant. Mais ce n'est pas obligatoire d'être toujours vrai. –