How to save a file as UTF-8 without breaking it
FTP by Zaweba saves files with their original bytes intact, and lets you choose Save as UTF-8, UTF-8 with BOM, UTF-16 LE or ANSI when you mean to change.
Pick the encoding from the status bar's encoding menu in FTP by Zaweba: UTF-8, UTF-8 with BOM, UTF-16 LE or ANSI. Saving in the usual way keeps the file's encoding and line endings exactly as they were, byte for byte, so files you don't mean to convert are never changed behind your back.
That second point is what keeps files from breaking. Most encoding problems come from an editor changing something nobody asked it to.
What usually goes wrong
A file's encoding is how its characters are stored as bytes. Plain English letters look the same in nearly every encoding, so a file can seem fine until it contains a pound sign, an accented name or a curly quote. Then, if the file was saved in one encoding and read as another, those characters turn into strange symbols on the page.
The classic cause is an editor that opens a file, guesses its encoding, and saves it back in a different one. Another is the byte order mark (BOM), a few invisible bytes at the start of a UTF-8 file. Browsers handle it, but some PHP files misbehave with it, because those bytes are sent before anything else.
Changing the encoding safely
Open the file. The status bar shows its current encoding alongside the language and line endings.
Decide whether to change it. If the page already displays correctly, the safest thing is often to leave it alone. FTP by Zaweba will save it with the original bytes.
If you do need UTF-8, open the encoding menu on the status bar and choose UTF-8. For PHP and most web files, plain UTF-8 without a BOM is the usual choice. Choose UTF-8 with BOM only if something you use needs one.
Save, then check the page. If characters that looked right before now look wrong, the file wasn't in the encoding you thought. Every save that overwrites a file keeps the previous version in local version history first, so restore it and try again.
Converting an older site
Older sites are often in ANSI, a Windows encoding from before UTF-8 was common. Converting them is worthwhile, but do it carefully. Save one file as UTF-8, look at it in a browser, and only then move on. Watch for pages that declare their own character set in the HTML; the declaration and the file's actual encoding should agree.
Find in Files, which searches across all the site's files with match case, whole word and regular expression options, helps find those declarations so you can update them together.
Why byte-exact saving matters
Keeping the original bytes is a quiet feature that prevents a lot of trouble. Edit one line in a file and only that line changes. Comparisons with the server stay clean, because nothing else in the file has moved. Upload on Save sends exactly what you edited.
Line endings follow the same rule. The editor keeps CRLF or LF as it was unless you choose Convert to LF (Unix / web servers) or Convert to CRLF (Windows).
A last check
Compare with Server Copy on the right-click menu shows line by line how your file differs from the one on the server. After a conversion, it's a useful way to confirm the text itself still matches and only the encoding has changed. FTP by Zaweba then lets you upload with confidence that the page will read the same way it did before.
