Here are some examples to make explicit some detail (implicit in the other answers), which may help clear up any remaining confusion.
Consider the following Unicode text añ©ⱥ
which consists of:
A byte is a number from 0 to 255 in decimal, or 00
to FF
in hexadecimal. So when encoded with UTF-8, the above "four-character" string corresponds to, in the file, the 8 bytes 61 C3 B1 C2 A9 E2 B1 A5
.
tex/pdftex WITHOUT inputenc
The engine sees the input as a stream of bytes (8 bytes in the above example). It considers each of them as as a character, and decides to typeset the corresponding character from either the T1 (Cork) encoding or OT1 encoding (the default) or whatever is set up. Examples:
Above, OT1 has no characters for those bytes so nothing gets typeset.
I hope you can see what's happening: each of the 8 bytes is treated as a character and output: e.g. the byte C3
is “Ô in T1.
tex/pdftex WITH inputenc
With \usepackage[utf8]{inputenc}
, TeX correctly sees every sequence of UTF-8 bytes as a Unicode character. For example, when TeX sees the byte sequence C3 B1
, it understands that you mean the Unicode character U+00F1. (The way this is done is that bytes larger than 127 (80
to FF
in hexadecimal) are set up to be active characters that expect further input — this is possible because of a useful design of UTF-8. See texdoc utf8ienc
for details.)
TeX still needs to know what to do with that Unicode character. A big bunch of definitions (such as \DeclareUnicodeCharacter{00F1}{\~n}
saying what to do with the character U+00F1) are included in the TeX distribution (file texmf-dist/tex/latex/base/utf8.def
on TeX Live). So using \usepackage[utf8]{inputenc}
will help if your characters have such definitions (again, see texdoc utf8ienc
for the full list), or if you're willing to define them yourself.
With a Unicode-aware engine (XeTeX or LuaTeX)
You don't need inputenc. The engine will expect UTF-8 (by default), and understand the input simply as Unicode characters, and for each of them it simply typesets that character from the currently selected font.
What about BOM?
With UTF-8 the BOM (byte order mark) isn't needed (it was meant for non-byte-oriented encodings, like UTF-16 and UTF-32), and is strongly discouraged. Typical “good” editors won't include it. Just forget about it; you aren't likely to encounter it in practice.
But if somehow your file does end up including it, then it's just a sequence of bytes EF BB BF
(the UTF-8 encoding of U+FEFF), and I think you have enough information above to work out what would happen if those bytes were present in the file at what place.
What if my file contains only "normal" characters?
If you mean Latin-script characters without accents, then UTF-8 has the property that it coincides with ASCII on the range 0 to 127 (00
to 7F
). So a file containing only those characters, encoded in UTF-8, is indistinguishable from one encoded in ASCII. Naturally, the output is identical too.
ä
orß
...