UTF-8 BOM only

If just and only the UTF-8 BOM mark is present in the file (it means it is precisely 3 bytes long), the PSPad editor doesn't detect it like UTF-8 file and displays these strange characters with default codepage even if the UTF-8 is chosen in the Format menu.

--
Vany
(PSPad 5.5.1.812 x32, W10h/p x64 en/cs)

Edited 1 time(s). Last edit at 2017-05-09 15:33 by Vany.

Use PSpad 5 from developer forum. It's near ready to be released and it has much better code page handling.

I'm using version 5.0.0 (235), but still the same

--
Vany
(PSPad 5.5.1.812 x32, W10h/p x64 en/cs)

Hello

Do you want to say you have UTF-8 document with BOM and PSPad doesn't detect it as UTF-8?

It can be caused for only one reason. Your document isn't correct, it means it contains non UTF-8 chars in it. Decoding as UTF-8 will cause lost of non UTF-8 chars. It's typically export of the database.

Can you send me any example? Than smaller than better.

As I wrote in the topmost message - if it is completely empty, but has the BOM present, so the file is 3 bytes in length, then it is not detected as an empty UTF-8 file, but PSPad opens it as standard text file with these bytes shown with ANSI Central European (1250) CP.

Code Page Autodetect is ON.

--
Vany
(PSPad 5.5.1.812 x32, W10h/p x64 en/cs)

Edited 2 time(s). Last edit at 2017-08-01 09:20 by Vany.

Empty file with UTF-8 encoding was special case.
I tested if file size > 0B and after loading editor is empty. In this case I open file as ANSI. I will handle files with BOM only.

thanks for correction, from 241 it is okay now

--
Vany
(PSPad 5.5.1.812 x32, W10h/p x64 en/cs)

I am using version 5.0.0 (251) and found bug when changing multiple files encoding.
If I choose utf-8 NO BOM, files are always converted to utf-8 WITH BOM.

Hello, I will fix it

Fixed, availble in the next build