TC adds BOM after saving file edited with compare tool

[Nux]

Steps to reproduce:

1. Create a file without BOM
2. Compare the file with some file
3. Change compare mode to UTF8<>UTF8
4. Edit the file without BOM
5. Save
6. Check for BOM

BOM is added to the file, but it shouldn't as this can be a cause of some really nasty bugs!

E.g. if you have a PHP library and some program will add BOM without your knowledge, then you will get "Headers already sent" error or something like that and you will spend hours searching for this (if you don't know about this BOM)... I got the same with Notepad some time ago.

BTW. Programmers Notepad 2 uses some algorithm to check if a file is in UTF-8 or not (if BOM is not present). It works more or less fine, but you can always change the encoding, plus you can use some tricks for it to work (add some non-ANSI characters near the beginning of the file).

One more thing - it's get even stranger if you compare two files which are almost exact copies: At first you will start with ANSI<>ANSI; change one so the files become the same; compare again and you get ANSI<>UTF8 and the files seems different at first (but you just synch. them, right?).

[ghisler(Author)]

I don't consider adding the BOM a bug, it's intentional because it's the only reliable way to detect Unicode files. Maybe I can add an option which allows the user to save the BOM or not, but I don't feel comfortable about that. The user must know somehow whether a BOM will be written or not, and currently he knows that TC will always write a BOM...

[ND]

will always write a BOM...

This is the main reason why I am not using Notepad, and why I will avoid the Edit capabilities of TC's compare-by-contents...

[Hacker]

Christian,

I don't consider adding the BOM a bug, it's intentional because it's the only reliable way to detect Unicode files. Maybe I can add an option which allows the user to save the BOM or not, but I don't feel comfortable about that. The user must know somehow whether a BOM will be written or not, and currently he knows that TC will always write a BOM...

I think TC should not change files except for what the user explicitly wants to change.

Roman

[ado]

Christian,
I agree with Roman, for example I am often using TC to compare unix scripts or config files. Adding BOM will make those files unusable.

ado

[sas2000]

 
I agree with Hacker, Tc should not modify files, we have enough with the .bak files that creates when comparing files .
 

[Nux]

I don't consider adding the BOM a bug, it's intentional because it's the only reliable way to detect Unicode files. Maybe I can add an option which allows the user to save the BOM or not, but I don't feel comfortable about that. The user must know somehow whether a BOM will be written or not, and currently he knows that TC will always write a BOM...

I agree that "it's the only reliable way to detect Unicode files", but the user should decide to add it or not.

I think the best way would be to have an option in preferences like "Save with BOM by default" and then in the save dialog add a checkbox "Save with BOM" (which would be selected or not in accordance to the preference option).

[siealex]

COMPARE files must mean READ them, but not WRITE!

[sqa_wizard]

COMPARE files must mean READ them, but not WRITE!

If you save it like in the first post, it has to write ...

[Clo]

2ghisler(Author)

Good evening,

• Since that's an issue I could encounter (more and more…), I follow the majority
- for once- and would be in favour of an option…

 VG
Claude
Clo

[Nux]

19.05.09 Added: Compare by content: wincmd.ini [Configuration] CompareAlwaysSaveWithBom=1 forces compare tool to always add byte order marker when saving Unicode or UTF-8 files
19.05.09 Added: Compare by content: When saving a file in Unicode or UTF-8 mode, add a byte order marker (BOM) only when the original file had one too

Thanks!

[ghisler(Author)]

Thanks for trying it! Please let me know if you encounter any problems with it.