Behavior of Encoding > Convert to ANSI has changed since version 6.4.x

2014-02-19
2014-07-23
  • I perform the same task at the start of every month. I retrieve a file which was created on a remote server and emailed to me, and then I convert it to a more usable format with Notepad++.

    Using a fresh install of Np++ v. 6.4.3, this file reports as UCS-2 Little Endian and shows LF as the EOL character (although the Edit menu shows EOL as being Windows Format, or at least that is greyed out). When I convert this file to ANSI, by going to Encoding in the menu bar and clicking on Convert to ANSI, the Encoding changes to ANSI and the EOL to CRLF. The Edit menu still shows EOL as being Windows Format.

    In the last few weeks, I allowed Np++ to update me to v. 6.5.2. The same file when viewed with this version reports as UCS-2 Little Endian and shows LF as the EOL character (and the Edit menu EOL Conversion shows UNIX/OSX Format greyed out). When I convert this file to ANSI, using the same method as described above, the Encoding changes to ANSI but the EOL does not change to CRLF. The Edit menu still shows EOL as being UNIX/OSX Format.

    I have been able to replicate the latter behavior with a fresh install of v. 6.5.4. I don't know which is correct, but I thought the change should be noted in case it is a bug.

     
  • Another tidbit I failed to notice the first time... I followed this procedure with v. 6.5.2, and when I reopened the files, Np++ reported them as being encoded in UTF-8 without BOM.

    I will try with a fresh install of v. 6.5.4, but it would seem that Np++ is not performing the requested conversion.

     
  • I was able to replicate this behavior with v. 6.5.4. The file reports as UCS-2 Little Endian and shows LF as the EOL character (and the Edit menu EOL Conversion shows UNIX/OSX Format greyed out). When I convert this file to ANSI, using the same method as described above, the Encoding initially reports that it is ANSI but the EOL does not change to CRLF. The Edit menu still shows EOL as being UNIX/OSX Format. Once saved and reopened, the Encoding reports that it is UTF-8 without BOM.

    So it would seem that Np++ v. 6.5.2 and v. 6.5.4 are both failing to perform the requested conversion.

    Besides reverting to 6.4.3, is there anything else I can/should do?

     
  • I reverted to v. 6.4.3 and performed the conversion, then saved and reopened the file.

    It reports that it is UTF-8 without BOM, just like the newer versions. The only difference is that the EOL is CRLF. So what is Convert to ANSI supposed to do, if not convert to ANSI?

    Thoroughly confused as to what is correct, here... I guess I'll just see if the file as converted with 6.5.4 will work for my purposes. If not, I'll stay at 6.4.3.

     
  • I am not sure to what you refer, since that link no longer works.

    But this is still a problem in the latest version of Notepad++ (6.6.7). I suspect that Notepad++ is reporting the encoding incorrectly as well as doing the conversion incorrectly.

    I can accomplish my task with a combination of Notepad (to change encoding) and Notepad++ (to change EOL), so I'm not desperate for a solution...