extendedchars option of the
listings package is relevant if you want to typeset source code that includes non-ASCII characters using a TeX engine without native Unicode support such as pdfTeX. Obviously, the
listings package has to deal a lot with category codes and, specifically, the
extendedchars option addresses collaboration with the
inputenc package which traditionally enables non-ASCII encoding of LaTeX input files via character activation.
By current design, the collaboration of the
listings package with the
inputenc package is restricted to single-byte encodings such as ISO-8859-1 and ISO-8859-15. As a consequence, the default value of the
extendedchars option (i.e.
true) is no use when the source code to be typeset is encoded in UTF-8, independently of whether the
utf8 or the
utf8x module is loaded by the
inputenc package. In either case, you get errors and faulty output.
extendedchars option is set to
\documentclass etc. ;-) ) the
listings package doesn’t attempt to collaborate with the
inputenc package. Depending on the combination of active input encoding and UTF-8 character, this may accidentally result in pseudo-correct output (as is the case with the combination
utf8x + BOM). In general, however, you get errors and/or faulty output once again.
To sum up: When the source code to be typeset is encoded in UTF-8 playing around with the
extendedchars option doesn’t make sense. But there are two other possibilities:
Resort to the
literate option as suggested by Ulrike Fischer.
Instead of the
listings package, use the
listingsutf8 package in conjunction with the extended
listingsutf8 package is only capable of handling UTF-8 characters that can be translated to some single-byte encoding. UTF-8 characters such as the BOM that can’t be translated to any single-byte encoding are silently ignored. This may or may not be desirable. In case of the BOM, it fortunately is.