THE INFORMATION IN THIS ARTICLE APPLIES TO:
- EFT Server, v6.x and later
When I offload (upload) a text (.txt) file with Unicode contents using the EFT built-in client to another server, the contents of the file get corrupted. Why?
When transferring files in ASCII mode (TYPE A), EFT will examine the file for Line Feeds (LFs) and insert Carriage Returns (CRs) before line feeds if those are missing, in accordance with RFC 959 §18.104.22.168. Text files with Unicode contents saved in Unicode or Unicode big endian format will contain extra NULL characters between the CR and LF sequences, and may contain the same hex value as LF (0x0a) in place of other Unicode characters throughout the file’s contents. EFT Server detects those isolated LFs or those LFs with preceding NULL characters and inserts CRs in front of each one, resulting in corrupted file contents and line endings.
The workaround is to choose UTF-8 as the encoding rather than Unicode when saving the file. This will preserve the contents and the correct CRLF sequence resulting in zero changes by EFT prior to offload.
Another solution is to force EFT to transfer the file in image or binary format (TYPE I), which can be done by removing the particular extension (.txt in this example) from the EFT ASCII file list in the Copy/Move Action wizard in the Advanced Options dialog box. Refer to Copy/Move (Push) File to Host Action for the procedure.
Optionally provide private feedback to help us improve this article...
Thank you for your feedback!