What an encoding actually does
A computer never stores letters directly. It stores numbers, and an encoding is the lookup table that says which number means which character. The plain letter "A" is byte 65 in almost every encoding in common use, which is why English text without accents tends to look fine regardless of which encoding a program assumes. The trouble starts with anything outside that narrow range: an accented letter, a curly quote, an emoji, a character from a non-Latin script, since different encodings assign those to different byte sequences, or do not include them at all.
ANSI, the legacy default
"ANSI" in a Windows editor's encoding menu almost always means the system's current code page, a single-byte encoding that covers roughly 256 characters, enough for one language or a small family of related ones, but not for mixing scripts or covering the full range of accented characters used worldwide. It is a holdover from before Unicode existed, kept around because huge amounts of older software and older files still use it, not because it is a good general choice for a new file today.
UTF-8, the modern default
UTF-8 encodes every character defined in Unicode, which covers essentially every script in use, using a variable number of bytes per character: one byte for plain ASCII text, up to four for less common characters. Because its one-byte range matches ASCII exactly, a plain English UTF-8 file and a plain English ASCII file are byte-for-byte identical, which is part of why UTF-8 became the near-universal default: it costs nothing for the common case and scales to everything else. Web pages, modern source code and most software built in the last fifteen years assume UTF-8 unless told otherwise.
The Byte Order Mark, and why it causes its own problems
A BOM is a short, invisible sequence of bytes written at the very start of a file, before any actual content, whose only job is to declare which encoding the rest of the file uses. It solves a real problem: a program with no other clue can look at those first bytes and know it is reading UTF-8 rather than guessing. The problem is that plenty of tools, shell scripts, older parsers and command-line utilities among them, do not expect it and read those bytes as literal, unexpected characters glued onto the start of the file, which can break a script that looks completely correct when read by a human.
Diagnosing a garbled file
Question marks, boxes, or strings like "é" where a single accented letter should be are the classic signs of an encoding mismatch: the file's actual bytes are fine, but whatever opened it guessed the wrong encoding to interpret them with. The fix is rarely to retype the text; it is to reopen the file specifying the correct encoding, or to explicitly convert it once the right encoding is known, rather than repeatedly saving and reopening on a guess.
Handling it directly
The code editor on this site shows and lets you change both the encoding and the presence of a UTF-8 BOM from the status bar, so a file that opens garbled can be re-read with the correct encoding, and one destined for a script or config file that specifically rejects a BOM can have it removed before saving, without guessing or a separate conversion tool.