Thanks :-)

This issue has been added to the tracker:
https://winscp.net/tracker/888

martin wrote:

Those three characters are UTB-8 BOM. It's perfectly correct to be in the file. Though many *nix program cannot handle them. For this reason WinSCP removes them during ASCII/text mode upload with SFTP and SCP. Not with FTP. So I suppose you are using FTP, right?

Yes. I'm using FTP. However, it is a problem when the internal editor saving files on a server wich the server can't handle.
This problem serves only at files after saving with the internal editor at utf-8.
Attached the file and here the error-message from my webserver: <invalid hyperlink removed by admin>

Those three characters are UTB-8 BOM. It's perfectly correct to be in the file. Though many *nix program cannot handle them. For this reason WinSCP removes them during ASCII/text mode upload with SFTP and SCP. Not with FTP. So I suppose you are using FTP, right?

Hi,

i've created an new file (.htaccess) on my ftp via WinSCP Beta 5.0.7 on Windows 7 Professional Client.
Then i edited this file with the WinSCP internal Editor at UTF-8 Encoding with his content "Options -Indexes".

After saving this file, my webserver can't interpret this file correctly.
I switched the encoding-view on the internal editor to ANSI and get this content "Options -Indexes".

Now i've deleted the first symbols "" and saved the file again with the internal editor on ANSI encoding and it works fine.

So the problem is only on saving a file in the utf-8 encoding mode.

greetz
Armin

WinSCP internal editor indeed does not support binary files. What you file with 0x00 qualify as.

WinSCP 2.3.8 build 1771 on windows 7

I use internal editor for view files, but I have a little problem when, inside a file, there are 0x00 byte sequence.
For example .. see this text

------
LockFile: /tmp/DemoneEmail.prop.lock

24/07/2012 15:56:04 [66284000] MAIN TOT(161306) sleep queue: 392
24/07/2012 15:56:09 [68495512] MAIN TOT(161306) sleep queue: 374
24/07/2012 15:56:14 [58976368] MAIN TOT(161306) sleep queue: 352
24/07/2012 15:56:19 [63015808] MAIN TOT(161306) sleep queue: 319
-------

between "lock" and "24/07/2012" there is a 0x00 sequence, see the exadecimal flow

-------------
4C 6F 63 6B 46 69 6C 65 │ 3A 20 2F 74 6D 70 2F 44 LockFile: /tmp/D
65 6D 6F 6E 65 45 6D 61 │ 69 6C 2E 70 72 6F 70 2E emoneEmail.prop.
6C 6F 63 6B 0D 0A 00 00 │ 00 00 00 00 00 00 00 00 lock♪◙
00 00 00 00 00 00 00 00 │ 00 00 00 00 00 00 00 00
32 34 2F 30 37 2F 32 30 │ 31 32 20 31 35 3A 35 36 24/07/2012 15:56
3A 30 34 20 5B 36 36 32 │ 38 34 30 30 30 5D 20 4D :04 [66284000] M
41 49 4E 20 54 4F 54 28 │ 31 36 31 33 30 36 29 20 AIN TOT(161306)
73 6C 65 65 70 20 71 75 │ 65 75 65 3A 20 33 39 32 sleep queue: 392
0D 0A 32 34 2F 30 37 2F │ 32 30 31 32 20 31 35 3A ♪◙24/07/2012 15:
35 36 3A 30 39 20 5B 36 │ 38 34 39 35 35 31 32 5D 56:09 [68495512]
20 4D 41 49 4E 20 54 4F │ 54 28 31 36 31 33 30 36 MAIN TOT(161306
-------------

in this situation .. the internal editor stop to view the file at the first 0x00 character, so I have a view truncated of the file

The file downloaded in temp directory it's correct.
I use the commander interface

At the moment I use an external editor to solve this problem and see all the file