2018 年以降の LaTeX なら、café の é も señor の ñ も Gauß の ß も、ソースにそのまま打ち込むだけで組めます。ところが、そうやって作った PDF を開いて「café」を検索しても 一件もヒットしない ことがあります。原因はアクセント記号そのものではなく、プリアンブルのたった一行——fontenc の設定です。このページでは、アクセント付きの欧文を「入力」から「PDF の中身」まで一本の流れとして追いかけます。入力エンコーディング、babel による言語宣言、.bib の著者名、そして hyperref のしおりまで、事故が起きるのはいつも端のほうです。アクセント命令そのものの一覧は関連ページに譲ります。
\usepackage[utf8]{inputenc} はもう書かなくていい
UTF-8 は 2018 年から LaTeX の既定の入力エンコーディング です。inputenc をまったく読み込まずに Un café à Montréal, señor Gauß, Kovář, Łódź. と書いた文書は、TeX Live 2024 の pdfLaTeX で警告ひとつ出さずに通ります。LaTeX News 28（2018 年）は、既定を「素通し」から UTF-8 に変えたこと、そのため \usepackage[utf8]{inputenc} はもう必須ではなく、書いてあっても害はないことを述べています。つまり inputenc utf8 を検索して出てくる古い解説の多くは、もう解くべき問題が存在しない 状態を説明していることになります。
XeLaTeX と LuaLaTeX ではもともと UTF-8 が唯一の入力エンコーディングなので、inputenc は最初から仕事がありません。ただしエラーにはなりません。 TeX Live 2024 同梱の inputenc.sty（2021/02/14 v1.3d）でこの二つのエンジンに inputenc を渡すと、返ってくるのは Package inputenc Warning: inputenc package ignored with utf8 based engines. という 警告 で、コンパイルはそのまま完走します。古いプリアンブルを LuaLaTeX に持ち込んでも止まらないのはこのためで、逆に言えば「エラーが出ないから正しい」とは限りません。プリアンブルの掃除のときに消しておくのが素直です。
ついでに一つ。UTF-8 という符号化方式そのものは 1992 年に ケン・トンプソン と ロブ・パイク が考案したもので、LaTeX News 28 もその経緯に触れています。TeX が生まれた 1970 年代末には 7 ビット ASCII しかなく、é を出すには命令を書くほかありませんでした。いま é をそのまま打てるのは、その 40 年ぶんの回り道が終わったからです。
pdfLaTeX なら \usepackage[T1]{fontenc} を必ず入れる
inputenc が「ソースのバイト列をどう読むか」を決めるのに対し、fontenc は「フォントの何番目の位置に何の字があるか」を決めます。既定の OT1 は 128 文字ぶんしかなく、アクセント付きの字を 一つの字として持っていません。だから é は「e の上に鋭アクセントを重ねて描く」合成として出力されます。見た目はほぼ同じでも、TeX から見れば「字が 1 つ」ではなく「字と記号の重ね合わせ」なので、その語はハイフネーションの対象から外れます（どの命令がどの符号化で使えるかは関連ページの一覧に整理されています）。T1 は 256 文字ぶんあり、é も ř も ł も 一つの字 として持っています。
「T1 にすると Computer Modern がビットマップになって PDF が汚くなる」という助言を見かけたら、それは古い情報です。TeX Live 2024 で \usepackage[T1]{fontenc} だけを足した PDF を pdffonts で調べると、埋め込まれているのは cm-super 由来の SFRM1000、種別は Type 1——ビットマップ（Type 3）ではありません。それでも lmodern を足す価値はあります。埋め込まれるフォントが LMRoman10-Regular に変わり、Latin Modern は Computer Modern の設計を Unicode 時代向けに引き直したものなので、字種の網羅もフォントファイルの素性も素直だからです。
XeLaTeX と LuaLaTeX では fontenc の出番はありません。 これらは OS のフォントを Unicode のまま扱うので、fontspec で書体を選べばアクセント付きの字はそのまま出ます。つまり判断は単純で、pdfLaTeX なら T1（できれば lmodern も）、Xe/LuaLaTeX なら fontspec ——この二択です。なお近年の LaTeX カーネルは Unicode の対応表をかなり広く持つようになり、pdfLaTeX ＋ T1 でも €・→・–・“ ” は警告なしにそのまま組めます。ただし全角の記号は別で、そちらは「欧文の書き方」で扱います。
% pdfLaTeX: the two lines that matter
\documentclass{article}
\usepackage[T1]{fontenc}
\usepackage{lmodern} % optional, but cleaner glyph coverage
% (no inputenc: UTF-8 has been the default since 2018)
\begin{document}
Un café à Montréal, señor Gauß, Kovář, Łódź.
\end{document}
% XeLaTeX / LuaLaTeX: no fontenc at all
% \usepackage{fontspec}
% \setmainfont{Latin Modern Roman}PDF で「café」が検索できない——文字が 2 つに分かれている
同じソース Un café à Montréal, señor Gauß, Kovář, Łódź. を、fontenc なし（既定の OT1）と [T1]{fontenc} ありの二通りでコンパイルし、pdftotext で中身を取り出して符号位置まで見ると差は決定的です。OT1 版では é が「e」＋ U+0301（結合用アクセント）の 2 文字 として格納されています。だから PDF ビューアで「café」（é は U+00E9）と入力しても一致しません。実際に café・Montréal・Łódź を検索すると 3 語とも 0 件。T1 版では同じ位置に U+00E9・U+00E1・U+0159・U+0141・U+017A といった 合成済みの 1 文字 が入っており、3 語とも見つかります。
もっと分かりやすい壊れ方もあります。ポーランド語の Ł（斜線つき L）は OT1 に字がないので、LaTeX は L に線を重ねて描きます。目で見れば Ł ですが、PDF から取り出した文字列は Łódź ではなく Lódź——斜線が消えて素の L になっている。著者名や地名がこの状態のまま出版されると、本文は正しく見えているのに、検索でも引用管理ソフトへのコピーでも綴りが違う、という厄介なずれが残ります。同じ理由で OT1 ではアクセント付きの語がハイフネーションされません（その実測は関連ページの「アクセント記号」にあります）。
# extract the text layer and inspect the code points
pdftotext paper.pdf - | head -1
# default OT1 -> e is followed by U+0301, a separate combining acute,
# and the bar of L is lost entirely:
# searching for "café" / "Montréal" / "Łódź" gives 0 hits
# with T1 -> precomposed U+00E9 U+00E1 U+0159 U+0141 U+017A:
# all three words are found
# and check what font actually got embedded
pdffonts paper.pdfbabel と polyglossia で言語を宣言すると入力まで変わる
babel に言語を渡すと、その言語の 入力の近道（ショートハンド） が有効になります。\usepackage[ngerman]{babel} を入れた文書では、"a "o "u "s がそれぞれ ä ö ü ß になり、" と "' はドイツ語の下付き・上付き引用符 „ と “ を出します。さらに "- は「ここで割ってよい」という追加のハイフネーション位置で、Zucker"-dose と書いても出力は Zuckerdose のまま——印は紙に出ません。ドイツ語キーボードのない環境でドイツ語を書くとき、あるいは ASCII だけで原稿を保ちたいときに効きます。
XeLaTeX・LuaLaTeX では polyglossia が同じ役割を担い、\setmainlanguage{german} のように宣言します。どちらを使う場合も注意が要るのは ショートハンドが " の意味を書き換える ことで、URL やコード片、verbatim の外でそのまま " を打つと思わぬ字が出ることがあります。長い引用符や外部ファイル名を扱う節では、\shorthandoff{"} で一時的に切るのが確実です。なお、babel は入力だけでなくハイフネーションと言語ごとの組版慣習も変えますが、そちらは「欧文の書き方」の担当です。
\usepackage[T1]{fontenc}
\usepackage[ngerman]{babel}
% "a "o "u "s -> a-umlaut, o-umlaut, u-umlaut, eszett
% "- -> an extra hyphenation point, invisible in the output
% Zucker"-dose still prints as one word
\shorthandoff{"} % turn the shorthands off around URLs and code.bib の著者名——BibTeX は É を Z より後ろに並べる
アクセントの事故がいちばん目立つのは本文ではなく 文献リスト です。実験してみましょう。Alpha・Ore・Zola・Zulu の 4 件を .bib に入れ、Émile Zola と Øystein Ore は UTF-8 のまま書きます。plain.bst で BibTeX を通すと、出てくる順は Alpha、Zulu、Zola、Ore ——É と Ø で始まる 2 件が Z より後ろに落ちます。BibTeX は名前をバイト列として比較するので、UTF-8 の É の先頭バイトが z より大きいというだけの理由です。警告もエラーも一切出ません。 同じ .bib で著者名だけ {\'E}mile・{\O}ystein と命令表記に書き換えると、順序は Alpha、Ore、Zola、Zulu と正しくなります。
この癖には理由があります。TeX Live 2024 に入っている BibTeX は起動時に Version 0.99d と名乗ります——1980 年代に Oren Patashnik が書いたプログラムが、40 年ちかく 1.0 に到達しないまま現役なのです。7 ビット時代の設計をそのまま引きずっているので、Unicode の照合順序は持っていません。対して biblatex ＋ biber は Unicode を理解し、同じ UTF-8 の .bib を 書き換えずに 正しく並べます（biber 2.19 で確認）。したがって実務の判断は二択です——biber を使える投稿先なら UTF-8 のまま書く。BibTeX を強制されるなら .bib 側だけ命令表記に統一する。 どちらを選ぶにせよ、混在させないことが肝心です。混在した .bib では重複検出も並べ替えも当てになりません。
% BibTeX 0.99d + plain.bst sorts these as Alpha, Zulu, Zola, Ore
@article{a1, author = {Émile Zola}, title = {Un titre}, journal = {J}, year = {2001}}
@article{a3, author = {Øystein Ore}, title = {Another}, journal = {J}, year = {2003}}
% ...and these as Alpha, Ore, Zola, Zulu -- correct
@article{a1, author = {{\'E}mile Zola}, title = {Un titre}, journal = {J}, year = {2001}}
@article{a3, author = {{\O}ystein Ore}, title = {Another}, journal = {J}, year = {2003}}
% biblatex + biber sorts the UTF-8 form correctly with no rewriting:
% \usepackage[backend=biber]{biblatex}しおりと PDF 文字列——hyperref はアクセントを通す
PDF のしおり（bookmark）や文書情報は、本文とは別の「PDF 文字列」として書き込まれます。かつてはここでアクセントが落ちるのが定番の事故でしたが、いまは既定で Unicode です。TeX Live 2024 の hyperref 7.01h で \section{Le café de Montréal} を組むと、生成される .out ファイルには UTF-16 の BOM に続いて é（U+00E9）がそのまま入っており、しおりにも正しく出ます。unicode オプションを手で足す必要はもうありません。
ただし PDF 文字列は 本文の命令をすべて受け付けるわけではありません。見出しに数式を入れると、コンパイルログに Package hyperref Warning: Token not allowed in a PDF string (Unicode): removing 'math shift' が並び、しおり側からは静かに取り除かれます。本文は正しいのにしおりだけ意味不明、という状態はここで生まれます。直し方は \texorpdfstring{}{} で、第一引数に組版用、第二引数にしおり用の平文を渡します。アクセント付きの語はそのまま第二引数に書けます——PDF 文字列が Unicode である以上、café は café のままで通ります。
\usepackage{hyperref}
% the log fills with "Token not allowed in a PDF string"
\section{Le café de Montréal $x^2$}
% typeset form on the left, bookmark text on the right
\section{Le café de Montréal \texorpdfstring{$x^2$}{x2}}共同執筆で先に決めておくこと
アクセントの入力方針は、原稿が大きくなってからでは直しにくい種類の決定 です。同じ人名が Gödel と G\"{o}del の両方で書かれた原稿は、どちらも正しく組めるのに、検索・一括置換・重複チェックがすべて二度手間になります。しかも一貫していないことに気づくのは、たいてい提出直前に文献リストを眺めたときです。エンジン、fontenc、.bib の表記、この三つを最初のコミットで決めてしまうのがいちばん安上がりです。
- 本文は UTF-8 の直接入力に統一する。
inputencは書かない。Xe/LuaLaTeX ならfontspec、pdfLaTeX なら\usepackage[T1]{fontenc}を 1 行。 - 受け入れテストを 1 回だけ通す。 ビルドした PDF で
caféと著者名を検索し、ヒットすることを確かめる。ヒットしなければfontencが抜けています。 .bibは提出先の処理系に合わせる。 biber が使えるなら UTF-8 のまま、BibTeX 強制なら著者名を{\'E}形式に統一し、二つを混ぜない。- 見出しに数式を入れたら
\texorpdfstringを添える。Token not allowed in a PDF stringの警告はしおりが壊れた合図です。 babelのショートハンドを使うなら、URL とコードの周りで\shorthandoff{"}する。 引用符の意味が書き換わっていることを忘れがちです。