PTEX_IN_FILTERの話．Windows上のptexには実装されていないので，それ以外のOSに限定した話．

Kpathseaの変数PTEX_IN_FILTERが定義されていると，ptexはそのプログラムを実行し，出力を受け取りそれを入力と見なす．より正確には，三条件*1

• PTEX_IN_FILTERが定義されていて，値が空でもnoではない．
• 環境変数PTEX_KANJI_ENCが定義されていない．
• -kanjiオプションが渡されていない．

を満たすとき，

$PTEX_IN_FILTER < [ファイル名]

というコマンドを内部で実行し，その出力をptexへの入力と見なす．内部文字コードは必ずUTF-8となる（BOMは処理される）．*2たとえば

PTEX_IN_FILTER="nkf -w"

とでも設定しておけば，文字コード推定がされるのと同じ効果を発揮する（というかまさにこれが想定された使い方だろう）．

ところで\epTeXinputencoding

新しく入れてもらった\epTeXinputencodingは，ファイルの文字コードの変更を行う．なので，たとえばShift_JISで書かれたファイルの先頭に

\epTeXinputencoding sjis

とでも入れておけば，必ずShift_JISとして読み込もうとする．ところで，ここでPTEX_IN_FILTER="nkf -w"なんて定義されていたとすると，もともとのファイルがなんであろうと，eptexにはnkfが変換した結果であるUTF-8の文字列が渡されて，結果化けてしまう．

まぁ\epTeXinputencodingのせいというか，PTEX_IN_FILTERが何でもありなので，本当に完全にはどうしようもない気がする．

*1

ソースから読んだのと実験してみた結果からなので，正確ではないかもしれない．実験はUbuntu上のTeX Live 2013．

*2

正確にはファイルから読む場合と同じなのだが，2/3/4が起こりえないのでUTF-8に確定する．