pTeX/upTeX の日本語ファイル名

[aminophen]

• https://twitter.com/zr_tex8r/status/954376620264931329
• https://twitter.com/zr_tex8r/status/954583283488075776

「アレ.tex」がカレントにある時に：
・「ptex アレ」はそのファイルを見つける （←チョット意外）
・他のソースファイル内で「\input アレ」した場合は見つけられない
※OSはDebian、ロカールはen_US.UTF-8、pTeXの漢字コードは(utf8.euc)。

Windows ではこのようなヤヤコシイことが起きないように対処されているはずなのですが，この“対処”が W32TeX では成功しているのに，TeX Live では upTeX で失敗するケースがあるという報告があります。私もまだ試せていないのですが，Windows で再現する方はいらっしゃいますか？

[t-tk]

私の経験上、
Windows上でminGWなどでコンパイルした場合、通常libtoolとやらが使われるらしく、その場合Unicodeファイル名をコマンドラインを通じて渡す方法が上手く動かないようです。
minGWでコンパイルする場合でもlibtoolを使わないように、直にリンクする形にしてバイナリを生成すると期待通りに動きます。
ソースコードの問題では無いと考えています。

[h-kitagawa]

e-pTeX 側で，関係しそうなチケットが作られたので貼っておきます：https://ja.osdn.net/projects/eptex/ticket/38246 （eptex #38246: 日本語ファイル名でエラー）

[aminophen]

本質的な解決にはなりませんが，「名称未設定-1.tex」なる名前を付けているのは“統合環境”である可能性が高いです。多分新しいファイルを作るとデフォルトでそうなるんだと思いますが，そこは日本語化しなくていいと思います。改修してもらうことはできないでしょうか？

TeXworks は untitled-1.tex ですが，TeXShop とか，TeXstudio とかはよく知りません。

[doraTeX]

標準的なmacOSのマルチドキュメントアプリは，英語環境で起動すれば Untitled-1，日本語環境で起動すれば 名称未設定-1 というように，各言語環境に応じた既定のファイル名が割り当てられます。これは，意識的にそのようにローカライズしているというより，新規ドキュメントウィンドウを作成する際にOSの側から勝手に割り当てられます。

[lemniscati]

　コマンドライン引数のエンコーディングと処理されるファイルのエンコーディングが違う場合に困ったことになるということでしょうか？
　そうだとすれば，単純にそれぞれのエンコーディングを個別に指定する方法があればよいのではないでしょうか？
　見当違いでしたらすみません．

[t-tk]

手元にmacOSは無いので、現象から想像してコメントします。

コマンドライン引数のエンコーディングと処理されるファイルのエンコーディングが違う場合に困ったことになる

おそらくこの理解で合っていると思います。
macOSの場合、コマンドラインはUTF-8前提になっていると思います。
pTeX の (utf8.euc) の場合、内部コードはEUCです。
macOSかつpTeXの場合、コマンドライン引数は特段の手当てをしておらず文字コード変換もしていないので、文字化けで処理が止まっても不思議ではありません。

WindowsかつpTeXの場合、コマンドライン引数は Shift_JIS 決め打ち、内部コードも Shift_JIS 決め打ち、テキスト入力は (utf8.sjis) ならコード変換して内部処理に回ります。

Unix/Linux系でも同様の機構を入れれば、本質的な解決になると思います。
ロケールを見て自動的に切り替えられると美しいかもしれません。
あるいは、Windows のように texmf.cnf の command_line_encoding で変換するコードを決めてもいいかもしれません。
あるいは、pTeXの (utf8.euc) の場合にはコマンドライン引数も UTF-8 → EUC-JP の変換をするようにしてもいいかもしれません。

[t-tk]

「アレ.tex」がカレントにある時に：
・「ptex アレ」はそのファイルを見つける （←チョット意外）

これは、Unix系では、kpsewitch のファイル検索とオープンはただのバイト列と見做して行うので
pTeXの内部コードにかかわらず、バイト列の照合・オープンが成功するためだと思います。

[hackn-in-github]

私なぞがここに書き込んでいいのか悩みましたが解決の糸口になればと…
Linux Mint 上で TeX Live 2018 を使っています(apt ではなく install-tl-unx.tar.gz を用いてのインストール)
名称未設定-1.tex を platex で処理した場合にエラーとなるのは

区 点 jis sjis euc utf-8 utf-16
30 46 3E4E 8FCC BECE E7A7B0 79F0 称
という文字が原因のようです
周辺の漢字を調べてみると

30 40 3E48 8FC6 BEC8 E785A7 7167 照
30 41 3E49 8FC7 BEC9 E79787 75C7 症
30 42 3E4A 8FC8 BECA E79C81 7701 省
---------↑エラー出ず----↓エラー------
30 43 3E4B 8FC9 BECB E7A19D 785D 硝
30 44 3E4C 8FCA BECC E7A481 7901 礁
30 45 3E4D 8FCB BECD E7A5A5 7965 祥

という結果になりました

[lemniscati]

@t-tk 「texmf.cnf の command_line_encoding」は，この記事のことでしょうか？
https://oku.edu.mie-u.ac.jp/tex/mod/forum/discuss.php?d=397&parent=6867

[t-tk]

@t-tk 「texmf.cnf の command_line_encoding」は，この記事のことでしょうか？

そうです。
それと似たような方法で実現可能だと思います。
コードの修正案があれば、ここにプルリクエストを出していただいてもよいと思います。

[t-tk]

ロケールを見て文字コードを判別するやり方について、↓のような記事を見つけました。
ファイル名の文字コード

個々のプロセスがどういうlocaleで動くかは自由です。プロセスがオンメモリでファイル名をどんな文字コードで持つか(LC_CTYPE)や、どんな順序で見せるか(LC_COLLATE)などは、ファイルシステム上のファイル名がutf-8であることとは独立です。

そうすると、ファイルシステム上のファイル名がどの文字コードであるか、自動的に判定する方法は無いという事になります。うーむ。
似たような要求がある場合他のソフトではどうしているのでしょうか?

以前私の書いた

あるいは、pTeXの (utf8.euc) の場合にはコマンドライン引数も UTF-8 → EUC-JP の変換をするようにしてもいいかもしれません。

も問題で、「入出力ファイルの中身がUTF-8であること」と「ファイルシステム上のファイル名の文字コード」とは必ずしも同じではないので、良い方法ではなかったです。

「正しい仕様」についてご意見ありましたらお願いします。

[t-tk]

最近 TeX Live ML で pdfTeX, Windows でnon-asciiのファイル名の話題が出ています。
角藤さんがupTeX, XeTeXと同じ方法で対応してくれたそうです。 [tex-live] TL2018: Problems with filenames
欧文(La)TeXの場合、今後
「ソースはUTF-8で書く。TeX独自の8bitエンコーディングは従来通りの扱い。」という方向でしょうから好ましい方向だと思います。
ソースファイル内で8bitの一部がアクティヴ文字化されている場合なども上手く動くのかなど、興味があります。動向を見守りたいと思います。

p(La)TeX + ptexencの場合、ソース上はUTF-8でもpTeXエンジンに渡るときにはSJIS/EUCに変換済みなので、そっくり同じには出来ないと思います。

[t-tk]

pTeX + ロケールが utf8 で日本語ファイル名の対応について、手元でソースをいじりつつ実験しています。
大体動くところまでは来ましたが、所詮弥縫策の感は拭えません。
仕様について以下のように考えています。ソースはもう少し整理したらご紹介します。

• 当面実験的機能とし、今後の仕様変更や廃止の可能性も残す。
• 完璧を目指さない。大体動くところまででよしとする。
  • 動くのはJIS第1,2水準の文字集合まで。
  • ただし、Unicode←→JISの変換表のゆらぎ問題にかかわる10字(波ダッシュ等)は動作保証しない。
  • それ以上を望む場合はupTeXを推奨する
• 簡明な実装で、ソースの理解のしやすさ、メンテナンスしやすさを優先する。
• 目標は、「pTeX(内部コードがEUC/SJIS)」,「ロケールがUTF8」、「Windows以外(Unix系)」、
  「non-ascii-filename.tex がコンパイルできる」まで。
  それ以上は、メンテナンスの負荷がかからない範囲までしか対応しない。
  • ロケールと内部コードの組合せは沢山考えられるが、今回の件以外には対応せず従来通り(素通し)とする
  • メッセージの文字化けは、出来る範囲しか対応しない。
  • specialの中のファイル名、画像ファイル名などは、対応しない。
    もし、簡明な実装で実現するようならば追加検討する。
• 内部実装としては、ptexenc と web2c/lib の改造で実現
  • ロケールは ptexencの内部変数terminal_encと一致していることを仮定する。
    設定用のスイッチは今回の改造のためには用意しない。
    大多数の通常のケースでは通用するはず。

結局、Unicode→JIS→Unicodeの変換をすることになるので、変換表のゆらぎ問題の影響がもろに出ます。
完璧な仕様を作ること自体難しく、それなりの仕様にしたとしても実装はややこしくなりそうです。
Windowsで採用しているcommand_line_encodingの機能では Windowsが持っている関数を用いてkpathseachの奥深くでコード変換しています。
kpathseachは文字コード変換にかかわるコードは含んでおらず、今回同じ手は使えません。

[zr-tex8r]

何となくですが、

1. pTeX系の和文文字の内部表現の問題（昔からある問題）
2. TL2018で導入された「UTF-8既定化」の副作用

がゴッチャになっている気がします。

https://ja.osdn.net/projects/eptex/ticket/38246 （eptex #38246: 日本語ファイル名でエラー）

ここで挙げられているのは純粋に 2 の問題であるような気がしますが、それで合ってるでしょうか？

つまり、macOS／Linuxにおいて、以下の言明は成り立つでしょうか？

• TL2017で、platex 名称未設定-1.tex は期待通りの動作をする。

• TL2018でも、アクティブ化を回避すれば期待通りの動作をする。

  platex "\UseRawInputEncoding\input 名称未設定-1"
  platex "\input\detokenize{名称未設定-1}"
  

[h-kitagawa]

https://ja.osdn.net/projects/eptex/ticket/38246 （eptex #38246: 日本語ファイル名でエラー）でもコメントしていますが，そこでの元々の話は

TL2018で導入された「UTF-8既定化」の副作用

によるものだと思います．手元の Linux で調べてみました：

$ platex "名称未設定-1.tex" 
This is e-pTeX, Version 3.14159265-p3.8.1-180226-2.6 (utf8.euc) (TeX Live 2018) (preloaded format=platex)
 restricted \write18 enabled.
entering extended mode
! I can't find file `�^^90^^8d腱井'.
<to be read again>
                   \protect
<*> �^^90^^8d腱井^^9c
                     ┃絎^^9a-1.tex
(Press Enter to retry, or Control-D to exit)
Please type another input file name: x
(/opt/texlive/2018/texmf-dist/tex/latex/tools/x.tex
pLaTeX2e <2018-05-20> (based on LaTeX2e <2018-04-01> patch level 4)

$ platex "\UseRawInputEncoding\input 名称未設定-1"
This is e-pTeX, Version 3.14159265-p3.8.1-180226-2.6 (utf8.euc) (TeX Live 2018) (preloaded format=platex)
 restricted \write18 enabled.
entering extended mode
pLaTeX2e <2018-05-20> (based on LaTeX2e <2018-04-01> patch level 4)
(./�^^90^^8d腱井^^9c┃絎^^9a-1.tex
(/opt/texlive/2018/texmf-dist/tex/platex/base/jarticle.cls
Document Class: jarticle 2018/02/04 v1.7h Standard pLaTeX class
(/opt/texlive/2018/texmf-dist/tex/platex/base/jsize10.clo))
(./�^^90^^8d腱井^^9c┃絎^^9a-1.aux) [1] (./�^^90^^8d腱井^^9c┃絎^^9a-1.aux)
 )
Output written on �^^90^^8d腱井^^9c┃絎^^9a-1.dvi (1 page, 292 bytes).
Transcript written on �^^90^^8d腱井^^9c┃絎^^9a-1.log.

$ platex "\input\detokenize{名称未設定-1}"
This is e-pTeX, Version 3.14159265-p3.8.1-180226-2.6 (utf8.euc) (TeX Live 2018) (preloaded format=platex)
 restricted \write18 enabled.
entering extended mode
pLaTeX2e <2018-05-20> (based on LaTeX2e <2018-04-01> patch level 4)
(./�^^90^^8d腱井^^9c┃絎^^9a-1.tex
(/opt/texlive/2018/texmf-dist/tex/platex/base/jarticle.cls
Document Class: jarticle 2018/02/04 v1.7h Standard pLaTeX class
(/opt/texlive/2018/texmf-dist/tex/platex/base/jsize10.clo))
(./�^^90^^8d腱井^^9c┃絎^^9a-1.aux) [1] (./�^^90^^8d腱井^^9c┃絎^^9a-1.aux)
 )
Output written on �^^90^^8d腱井^^9c┃絎^^9a-1.dvi (1 page, 292 bytes).
Transcript written on �^^90^^8d腱井^^9c┃絎^^9a-1.log.

（pTeX の内部コードが EUC なので「名称未設定-1」が「�^^90^^8d腱井^^9c┃絎^^9a-1」に化けるのは仕方がないことだとは分かっていますが，この文字列はバイト列としてそのまま端末に出力する」みたいなフラグを導入すれば良い??）

[t-tk]

1. pTeX系の和文文字の内部表現の問題（昔からある問題）
2. TL2018で導入された「UTF-8既定化」の副作用

なるほど。今まで 1 がさほど問題にならなかったのは 2 がなければ顕在化しないケースが多かったからでしょうね。
しかし、

    platex "\UseRawInputEncoding\input 名称未設定-1"
    platex "\input\detokenize{名称未設定-1}"

は、出来れば

    platex 名称未設定-1.tex

の方が分かりやすいでしょうし、platexのソースコード内で \input{日本語ファイル名.tex} が使えたほうが良いでしょうし、 1 の改良をすれば自然と 2 が解決するはずなのでその方が良いでしょう。
ブランチ https://github.com/texjporg/tex-jp-build/tree/ptex-filename に試作品を示します。
ptexenc の中で terminal_enc がUTF-8の時に以下を実行します。

• コマンドライン変数の argc, argv を乗っ取り UTF-8→内部コード(EUC/SJIS)変換
• web2c/lib/openclose.c に現れるファイル名文字列(nameoffile+1) をコード変換
  1. kpathseach に渡る前に内部コード→UTF-8変換
  2. nameoffile+1に再格納する前にUTF-8変換→内部コード変換

メッセージやログなどに文字化けが残っていますが、見掛けだけの話で動作に支障は無いと思います。
画像ファイル名は対策できていません。
コマンドライン変数の乗っ取りは-kanji-internal の切り替えに対応していません。(順序の問題)
いかがでしょうか。

[zr-tex8r]

＞h-kitagawa さん

手元の Linux で調べてみました：

ありがとうございます。

＞t-tk さん

platexのソースコード内で \input{日本語ファイル名.tex} が使えたほうが良いでしょうし、 1 の改良をすれば自然と 2 が解決するはずなのでその方が良いでしょう。

これはその通りだと思います。

あと、2 の方の問題はpTeX系に限った話ではなくて、世界中のWindows（コマンドラインがUTF-8でない）で同様の問題が起こる（参考）ので、そちらはLaTeXチームにより対処が行われることが期待されます。

• non ascii filenames on commandline
  これを見ると、「バイト列を素通しする」（TL2017と同じ動作になる）ことを目指しているようです。

[zr-tex8r]

2の問題に関して、気になっているのは次のようなケースです。

% pdflatex; Linux; UTF-8
%\UseRawInputEncoding %←これがないとエラー
\documentclass{article}
\begin{document}
\input{Begrüßung}
\end{document}

% uplatex; Linux; UTF-8
%\UseRawInputEncoding %←これがないとエラー
\documentclass{article}
\begin{document}
% <ü><ß>は欧文扱い
\input{ドイツ語-Begrüßung}
\end{document}

これも、pTeX系に限らない話であるため、近いうちにLaTeXチームによって対処される可能性が高そうです。

[t-tk]

欧文LaTeX と UTF-8規定化問題でも、問題点がごっちゃに語られているように思います。

1. コマンドラインの文字コードと内部コードの不整合の影響
2. 「UTF-8既定化」により8bit文字の一部が規定でactive化されたことによる影響

世界中のWindows（コマンドラインがUTF-8でない）で同様の問題が起こる

これは、1の方の問題で、pdfTeX に角藤さんが command_line_encodingの機能を導入してくださったので、解決済みと思います。
(command_line_encoding=utf-8でコードページにかかわらずファイル操作でUnicodeの関数を直接使うようになる)
レガシーエンコーディング志向の人がロケールUTF-8のLinux/MacOS上でpdfTeXを使ったら依然解決していないと思います。

2 の問題は、upLaTeX + ロケールUTF-8のLinux/MacOS でも発生するのですね。「近いうちにLaTeXチームによって対処される」のに期待したいと思います。

[t-tk]

「pLaTeXで画像ファイル名」の方はどうしましょう。
W32TeX では角藤さんが最近 pdvipdfmx, pdvips などを追加したり、dviwareの改造を試みたりされているようです。
別解として、pLaTeXがdviに書き込むファイル名自体を UTF-8 にすることは出来ないのでしょうか。

[zr-tex8r]

別解として、pLaTeXがdviに書き込むファイル名自体を UTF-8 にすることは出来ないのでしょうか。

specialの中のファイル名がUTF-8だったら、「command_line_encoding=utf8なWindows」でも「UTF-8ロケールのLinux/macOS」でも、dvps／dvipdfmxがファイルを見つけられる、ということでしょうか。

だとすれば、「ソースをUTF-8で書く場合の欧文(pdf)LaTeX」と解決を共有できそうなんで好ましそうです。

[zr-tex8r]

（今更ですが）

このIssueの発端となっている

W32TeX では成功しているのに，TeX Live では upTeX で失敗するケースがあるという報告があります。

という現象の原因は、単に

• command_line_encodingの設定が両者で異なる。W32TeXはutf8が設定されていて、TeX Liveは未設定。TeX Lvieでもutf8を設定するとW32TeXと同じ挙動になる。

ということでした。

自分が調べた限りだと、「command_line_encoding=utf8を設定していて害になる」パターンは、「欧文(pdf)LaTeXでソースをレガシー8ビットな文字コードで書いている」場合しかなさそうです。TeX Liveも「UTF-8既定化」に踏み切ったくらいなんだから、command_line_encoding=utf8を既定にしてもよいのかも知れません。

[t-tk]

W32TeX では成功しているのに，TeX Live では upTeX で失敗するケース

command_line_encodingの設定の差異によると判明したのこと、了解しました。
想定通りの動作で安心しました。

「command_line_encoding=utf8を設定していて害になる」パターン

「Windows, ShitJISでp(La)TeXを使う人がdvips, dvipdfmxにcommand_line_encoding=utf8を与えると、8bitの画像ファイル名が読み込めなくなる」
というのがあったと思います。

command_line_encoding=utf8を既定にしてもよいのかも知れません。

角藤さんが最近 pdvipdfmx, pdvips などを追加したり、dviwareの改造を試みたりされているのは、command_line_encoding=utf8を既定にする方向を考えておられると想像しています。
というか、もうすでになっている?

specialの中のファイル名がUTF-8だったら、「command_line_encoding=utf8なWindows」でも「UTF-8ロケールのLinux/macOS」でも、dvps／dvipdfmxがファイルを見つけられる、ということでしょうか。

私の予想ですが、そういう意図です。

欧文TeX の場合、レガシーエンコーディングの時代の多数派は「エンジンの内部コードはT1などのTeX独自8bitエンコーディング、入出力ファイルはLatin-1、コマンド行など外部はLatin-1、specialの文字列はTeX 8bitエンコーディング」だったと思います。
従来でも「TeX 8bit→Latin-1」のコード変換が必要な場面はあったし、最近の環境向けには「TeX 8bit→UTF-8」のコード変換が必要な場面がありそうに思えるのですが、どうなっているのでしょうか?
pTeXの場合は、そこが「EUC/SJIS→UTF-8」に置き換わるのだと予想しています。

「ソースをUTF-8で書く場合の欧文(pdf)LaTeX」と解決を共有できそう

似ている点とpTeX独自な点がありそうで、調べた方が良さそうです。(ややこしそう…)

[t-tk]

LANG=ja_JP.utf8のLinuxで簡単なテストをしました。
弌丐丕.eps ("弌丐丕"はEUCで D0 A1 D0 A2 D0 A3) と
СТУ.eps ("СТУ"はUTF-8で D0 A1 D0 A2 D0 A3) をカレントディレクトリに置き
下記のplatexソースを先日の改造版 https://github.com/texjporg/tex-jp-build/tree/ptex-filename で試してみました。

% platex (utf8.euc), Linux, LANG=ja_JP.utf8 でテスト
\documentclass{article}
\usepackage{graphics}
\begin{document}
\includegraphics{弌丐丕.eps}
\end{document}

結果はこうなりました。

1. BoundingBoxの値を拾うため最初にepsファイルを探しに行くときは弌丐丕.epsを読みに行く
2. dviファイルへは"弌丐丕"の EUC表現 "D0 A1 D0 A2 D0 A3" のバイト列で記録される
3. dvipdfmxは弌丐丕.epsではなくСТУ.epsを取り込もうとする

1は先日の改造の効果が現れています。
Master/texmf-dist/source/latex/graphics のソースをざざっと眺めた感じでは
drivers.dtx の中の \Ginclude@eps を改造しファイル名の EUC→UTF-8のコード変換をした後\specialに渡すようにすれば直感的な動作になるような気がします。
ファイル名のみを選択的にコード変換することが出来るのでpTeXエンジンやdviware側を改造するよりも筋が良さそうに思います。
Windows, dvipdfmxでのダメ字問題も同時に回避できるはずです。

「\specialを受けてからdviに書き込むまでの間で pTeX エンジンがコード変換する」という案もありそうですが、\special の文字コードを決め打ちすると副作用が出るような気がします。あるいは、逆に好都合なことも起きたりするのでしょうか?

[t-tk]

WindowsのpdfTeX への command_line_encoding の導入は、角藤さんから撤回するとの連絡をいただきました。

以前の議論の続き。
問題の切り分けについて、2個ではなく3個に分けて考えた方が分かりやすいと考え直しました。

1. LaTeXのUTF-8デフォルト化とそれに伴う8bit文字のアクティヴ化の影響
2. TeXの内部文字コードとOS側の文字コード間など、文字コードの不整合
3. WindowsがPOSIX関数を使うかぎりANSI文字コードしか扱えない件

1は、LaTeXチームの対策待ちです。
2は、「ロケールutf8のLinux/MacOS」とWindowsで共通の課題のはずです。
3は、command_line_encodingで解決しようとしている点です。

2は、pdfTeXとpTeXで仕様上似ている点とそうでない点があり、
pdfTeXで過去どこまで出来て今何が出来ないのかなどよくよく理解しないと先に進めそうにありません。さてどうするか。

[h-kitagawa]

「UTF-8→EUCの変換に失敗する場合は^^ab化する」

今回の場合とは逆方向の ptenc_from_utf8_string_to_internal_enc や input_line2 ですね．

ゴミがEUCでの正規の文字列になり、結果として文字化けしたまま気付かずに処理が進行してしまう

例えば，ptex 俲俲.tex (「俲」は UTF-8 で [e4][bf][b2]）では 篆俄寝.tex を読みに行きますが，篆俄寝.tex を作ってみたときのログは

ptex 俲俲.tex
This is pTeX, Version 3.14159265-p3.8.3 (utf8.euc) (TeX Live 2020) (preloaded format=ptex)
 restricted \write18 enabled.
(./膀^^86篆^^84絲^^9d.tex)

となり，もうぐちゃぐちゃです．
（edit: ……膀^^86篆^^84絲^^9d は UTF-8 での 篆俄寝 ([e7][af][86][e4][bf][84][e5][af][9d]) をEUC-JP で解釈したものですね）

あきらめて「明示的にエラーを起こした方が」良いのかもしれません．

[zr-tex8r]

確認ですけど、内部漢字コード=eucのpTeXでaあ①.texというファイルを開く場合、件のnameoffilee+1の中身はどうなるのでしょうか？ これが
61 a4 a2 e2 91 a0
（※a4a2はあのeuc、e291a0は①のutf8）
みたいに「eucとutf8が混在」した状態になってると、もうどうしようもないですよね。

[h-kitagawa]

aあ①.texというファイルを開く場合、件のnameoffilee+1の中身はどうなるのでしょうか？ これが
61 a4 a2 e2 91 a0

まさしくそのようになっています．
（#81 で EUC 由来と EUC に変換されなかった部分が区別されればなんとかなるかもしれませんが，そこまでやる気力は今はありません）

[t-tk]

UTF-8→EUCに変換できない場合にどうするのか、ブレインストーミングを兼ねて仕様案です。

1. その場でエラー終了
2. 下駄記号 〓 2区14点, EUC-JP:0x81ad, U+3013 に変換する。
   ちなみに、レガシーエンコーディング→Unicodeで変換出来ない場合、変換先を � "REPLACEMENT CHARACTER" U+FFFD にすると変換不能文字であることを明示できる。
3. ^^ab 形式に変換する。
   ptexencでレガシーエンコーディング→Unicodeで変換出来ない場合に実施している方法を適用。

1 は気乗りしません。ptexenc がライブラリーという立場なので、fallbackして進める方針の方がよいと思います。

2 は慣習としてやっていいような気もします。本当に下駄記号を意図して使おうとしている場合と区別が困難なのをどう考えるか。
下駄記号 Wikipedia

3 は本当にその文字列を意図して使おうとしている場合は稀で、一番安全かもしれません。それに、変換できなかったバイト列の情報が保存されるのでデバッグしやすい利点、ptexencの内部動作を知らないユーザーもエラーに気づきやすい利点もあると思います。文字列が長くなるのが実装上面倒かも知れません。

私としては、2 か 3 を支持します。

[aminophen]

個人的には \input{①} と ptex ①.tex が同じファイルを探して欲しいです。（edit: 探されるファイルが「システム上で "①.tex" と表示されるファイル」かどうかは問いません。）

TL2018 以前では文字コード変換していなかったのを TL2019 で変換するようになったのは，「ソース中に書かれた \input{日本語ファイル名} から 日本語ファイル名.tex を探すために 内部コード→UTF-8 への逆変換が必要だから」だと理解しています。その結果，TL2019 では \input{日本語} と ptex 日本語.tex が同じファイルを探すのですから，同様であればいいなと思います。「\jobname が何になるのか」という観点でも。

[t-tk]

\input{文字列ほげ} と hogetex 文字列ほげ.tex が同じファイルを探すという仕様に対しおそらく現状(TL 2019,2020)では「Unix/Linux系 かつ ロケールUTF-8 」でもWindowsでも

• pTeX では「文字列ほげ」がJIS X 0208 の範囲で実現
• LuaTeX, XeTeX, upTeX では「文字列ほげ」がUnicodeの範囲で実現
• pdfTeX (欧文TeX) ではソースコードをUTF-8で書いていれば「文字列ほげ」がUnicodeの範囲で実現

と思います。私としては充分だと思います。
pTeX では「文字列ほげ」がUnicodeの範囲で実現できるようにする、というのは新規の開発項目になりますが、そこに開発資源を投資する価値は無いと思います。

[aminophen]

non-windows での仕様を理解したいので，お手数ですが確認させてください。

\input{文字列ほげ} と hogetex 文字列ほげ.tex が同じファイルを探すという仕様

を実現するために ptexenc が行なっているのは，

• \input の引数：トークン化の時点で内部コードに変換された状態（変換できなかったバイト列は…）。ファイルを開く時には，内部コードから UTF-8 に変換する（残されたバイト列は…）。
• コマンドライン引数：UTF-8 から一度内部コードに変換し（変換できなかったバイト列は…），ファイルを開く時に内部コードから UTF-8 に変換する（残されたバイト列は…）

各「変換」がどの関数に対応しているか，また … の部分が TL2019/2020 でどう扱われているのか埋めて頂けると有り難いです。

[t-tk]

記憶を元に書くと non-windows かつロケール UTF-8かつ pTeX かつソースコードが UTF-8 では

1. \input{文字列ほげ} をptexencが入力バッファに取り込む際にUTF-8→EUC変換
   変換できなかったバイト列は ^^ab に変換
2. 入力バッファからpTeXの内部コードに取り込む際にEUC→16bit JISに変換、トークン化
   変換できなかったバイト列は ^^ab のASCII 文字列で8bit欧文TeXの処理へ。
3. ファイル 文字列ほげ.tex にアクセスしようとする際、lib/openclose.c のopen_input()かどこかで16bit JIS→UTF-8変換

そして

1. コマンドライン引数UTF-8をptexencが入力バッファに取り込む際にUTF-8→EUC変換
   変換できなかったバイト列は ^^ab に変換
2. 以下同文

3 は TeX Live svn r47967, r47972 あたりで触った場所です。
バイト列と和文文字の区別 #81 とも関連が有ったはず。間違っていたら訂正お願いします。

[t-tk]

ちなみに、日本語WindowsかつpTeXでは、たしか、
コマンドラインがCP932(Shift_JIS)であることを前提に入力バッファにそのまま渡す(CP932のまま)ので、コマンドラインのUnicodeはpTeXの入力バッファに渡らない(^^ab化されない)ようになっていたと思います。ただし、CP932なので"①"は機種依存文字として日本語のトークンになると思います。
ファイル入力(\input{文字列ほげ}など )の場合はnon-windowsと動作は同じです。

[aminophen]

記憶を元に書くと

ありがとうございます。しかし，

\input{文字列ほげ} をptexencが入力バッファに取り込む際にUTF-8→EUC変換
変換できなかったバイト列は ^^ab に変換

のところは， 入力バッファの時点ではまだバイト列のまま（^^ab が出てくるのはもっと後）だと思います。現に ①.tex の内部表現に EUC で解釈できないバイト列が残っていて，それがファイルアクセス時の関数 ptenc_from_internal_enc_string_to_utf8 でヌル文字になっているようですので。 そこに至るまでの過程を知りたいです。（ソース読めと言われそうな話ですが，構造が複雑でよくわからず…。）

→ edit: 少しわかりました。入力バッファの時点で ^^ab に変換が済んでいて，それが欧文の 8bit 処理に回った結果としてそれがバイト列と同一視されるということを仰っているのですね。

[aminophen]

#45 (comment) を私が正しく理解できていればですが

UTF-8→EUCに変換できない場合にどうするのか

の『仕様案3「^^ab 形式に変換する」を実現すること』と，

「\input{文字列ほげ} と hogetex 文字列ほげ.tex が同じファイルを探す」

を『non-windows の pTeX で Unicode の範囲で実現すること』は同値ではないでしょうか。

実現に労力がかかるのであれば推進する意図はありませんが，\input でファイルオープンに使われている関数を流用するだけで実現できるのであれば進めたいとも思います。

[h-kitagawa]

仕様案3「^^ab 形式に変換する」を実現すること』

printkanji_16bit ブランチ上で行った変更ですが， h-kitagawa@02484d8 みたいな感じでしょうか．

\input{a①ſ.tex} も eptex a①ſ.tex も 実際にはファイル a^^e2^^91[a0][e9][a1][9b].tex （つまり，a^^e2^^91顛.tex） を探しにいきます．

[t-tk]

入力バッファの時点で ^^ab に変換が済んでいて，それが欧文の 8bit 処理に回った結果としてそれがバイト列と同一視される

分かりにくい表現だったかも知れません。
私の記憶が正しければ
「入力バッファはUnix/Linux系 かつ内部コードEUCの場合、8bit多バイトのEUCの文字列である。UTF-8→EUCに変換出来ない文字列は入力バッファに入れるとき '^' '^' 'a' 'b' の形式でUTF-8のhex表現のバイト列をASCIIの文字列で表現したものに変換される。」
ptexenc.c の関数 write_hex() を使っているところ、つまり ptenc_from_utf8_string_to_internal_enc(), get_utf8() だと思います。

\input{a①ſ.tex} も eptex a①ſ.tex も 実際にはファイル a^^e2^^91[a0][e9][a1][9b].tex を探しにいきます．

何がどう化けたのか理解できません。UTF-8で [e2][91][a0]は「① U+2460」, [e9][a1][9b] は「U+985B 顛」だとして, "ſ" はどこに行ったのでしょう?

[h-kitagawa]

"ſ" はどこに行ったのでしょう?

結論から言うと，[e9][a1][9b]「顛」に化けています（texjporg/platex#84 などと同様）．例が悪かったですね．

1. "ſ" は UTF-8 で [c5][bf] なので，入力バッファには '^' '^' 'c' '5' '^' '^' 'b' 'f' と ^^ 形式で入る
2. 入力バッファの内容を元にしてファイルを読み取る処理は，トークン単位で行われる．上記からは ^^c5, ^^bf という 2 つの欧文文字トークンが得られるため，ファイル名 (name_of_file+1) には [c5][bf] というバイト列で格納される
3. open_input (lib/openclose.c) で name_of_file+1 が UTF-8 に変換される際に，この 2 バイトは EUC [c5][bf] （= U+985B 顛）とみなされ，[e9][a1][9b] となる

[aminophen]

a^^e2^^91[a0][e9][a1][9b].tex

e2 91 だけが ASCII の ^^ 記法になり，a0 が単一バイトなのはどうしてでしょうか。

[h-kitagawa]

e2 91 だけが ASCII の ^^ 記法になり，a0 が単一バイトなのはどうしてでしょうか。

[a0] は EUC の第一バイトでない (multibytelen(0xa0)=1) ので，ASCII の場合の処理に割り振られるからですが，あまりにも処理が大雑把でしたね．また考えます．

[t-tk]

現状の \input{顛.tex} の期待される動作は、non-Windows, ロケールUTF-8, 内部コードEUCのpTeXでは、 name_of_file+1 で [c5][bf].tex となった上で open_input で UTF-8 の[e9][a1][9b].tex となって顛.texをopen出来ているんですよね? (現在期待通りの動作)
\input{ſ.tex} が一旦 ^^c5^^bf になったとして、name_of_file+1 で [c5][bf].tex となってしまうのなら \input{顛.tex} と区別できないのでは????

[aminophen]

現状の \input{顛.tex} の期待される動作 …

私の理解もその通りです。

\input{ſ.tex} が … \input{顛.tex} と区別できない

そこは #81 が絡んでくる話だと思います。

[h20y6m]

printkanji_16bit とは関係なさそうなのでこちらに書きます。

UTF-8 な Linux 上の pTeX で pdfTeX 由来のファイル名をとるプリミティブ \pdffiledump, \pdffilemoddate, \pdffilesize, \pdfmdfivesum が日本語ファイル名を見つけられないようです。

texmfmp.c の find_input_file で文字コード変換すればよい？

[aminophen]

UTF-8 な Linux 上の pTeX で pdfTeX 由来のファイル名をとるプリミティブ \pdffiledump, \pdffilemoddate, \pdffilesize, \pdfmdfivesum が日本語ファイル名を見つけられないようです。
texmfmp.c の find_input_file で文字コード変換すればよい？

texmfmp.c: convert filename to UTF-8 in find_input_fie

79641be を r62514 でコミットしました。

[t-tk]

upTeX で内部コードが euc/sjis の場合の日本語ファイル名 #136 、
特に #136 (comment) で見たように、r65330 でサポート対象と思っていた範囲では動いていると思います。

『non-windows の pTeX で Unicode の範囲でファイル名を扱えるようにする』『windows の pTeX で Unicode の範囲でファイル名を扱えるようにする』について
p(La)TeX で非JIS X 0208のutf8のファイル名は、現状、もろもろの障害があって動きませんが #147 とか #149 とかをごちゃごちゃやれば実現可能と思います。私としては、pLaTeX 向けに非JIS X 0208のutf8を頑張るのは割に合わない気がして意欲が湧かなかったのですが、pLaTeX on npTeX 向けならばリソースを割いてもいいかな、と思い始めています。

[tueda]

少し違う話かもしれないので恐縮ですが、TeX Live 2022/dev/Debian、LANG=C.UTF-8において、ptex --recorder アレを実行すると、.dvi、.logファイルは期待通りの名前で生成されますが、.flsファイルの名前はおかしくなりました。

$ ls
''$'\245\242\245\354''.fls'   アレ.dvi   アレ.log   アレ.tex

[h20y6m]

少し違う話かもしれないので恐縮ですが、TeX Live 2022/dev/Debian、LANG=C.UTF-8において、ptex --recorder アレを実行すると、.dvi、.logファイルは期待通りの名前で生成されますが、.flsファイルの名前はおかしくなりました。

$ ls
''$'\245\242\245\354''.fls'   アレ.dvi   アレ.log   アレ.tex

【メモ】recorder file は lib/openclose.c の recorder_start で プログラム名＋PID で作成された後、recorder_change_filename で実際のファイル名にリネームされる。

以下の new_name の文字コードを変換すればよさそう？

tex-jp-build/source/texk/web2c/lib/openclose.c

Lines 142 to 158 in 0d227bf

	recorder_change_filename (string new_name)
	{
	string temp = NULL;
	if (!recorder_file)
	return;
	/* On windows, an opened file cannot be renamed. */
	#if defined(_WIN32)
	fclose (recorder_file);
	#endif /* _WIN32 */
	/* If an output directory was specified, use it. */
	if (output_directory) {
	temp = concat3(output_directory, DIR_SEP_STRING, new_name);
	new_name = temp;
	}

---

これを調べていてたら -output-directory で日本語ディレクトリを指定すると .log ファイルが書き込めなくなることに気付きました。

$ mkdir アレ
$ platex -outout-directory=アレ sample2e
This is e-upTeX, Version 3.141592653-p4.1.0-u1.29-230214-2.6 (utf8.euc) (TeX Live 2023) (preloaded format=platex)
 restricted \write18 enabled.
entering extended mode
! I can't write on file `sample2e.log'.
(Press Enter to retry, or Control-D to exit; default file extension is `.log')
Please type another transcript file name:

output_directory を連結する 前 に文字コード変換をする必要がありそう？（open_input のほうはそうなっている）
（output_directory は UTF-8 な Linux なら UTF-8 になっているはず？）

tex-jp-build/source/texk/web2c/lib/openclose.c

Lines 415 to 427 in 0d227bf

	/* If we have an explicit output directory, use it. */
	if (output_directory && !absolute) {
	fname = concat3(output_directory, DIR_SEP_STRING, nameoffile + 1);
	} else {
	fname = nameoffile + 1;
	}
	#if defined(PTEX) && !defined(WIN32)
	fname0 = ptenc_from_internal_enc_string_to_utf8(fname);
	if (fname0) {
	if (fname != nameoffile + 1) free(fname);
	fname = fname0;
	}
	#endif

[t-tk]

*tex --recorder オプションと出力の .fls ファイルのテストを TeX Live svn r68965 に入れました。
ptex --recorder , eptex --recorder , uptex --recorder --kanji-internal={euc,sjis} , euptex --recorder --kanji-internal={euc,sjis} で問題が再現します。文字化けの仕方もエンジンにかかわらず同様です。
予想通り uptex, euptex, pdftex, xetex では問題が発現しません。

ptex --recorder と uptex --recorder --kanji-internal={euc,sjis} の差分が出る場合は、 #32 の方の関わりを気にする必要がありますが、そうではないと確認しました。#32 の方はこちらを気にせずに進めます。

私個人としては
(e)pTeX のレガシーエンコーディング(euc,sjis)のファイル名関連のメンテナンスについては頑張る元気がありません。
「known issueのまま放置になってもやむをえない、(e)upTeX 推奨、(e)pTeX 非推奨」でよいと思っております。
( もちろん、この件を解決に向けて努力する方々の活動を妨げる意図はありません )

ご参考、pTeX を obsolete にするかどうかの TeX Forum での話題 ::
https://okumuralab.org/tex/mod/forum/discuss.php?d=3654#p22720
https://okumuralab.org/tex/mod/forum/discuss.php?d=3654#p22721
https://okumuralab.org/tex/mod/forum/discuss.php?d=3654#p22727
https://okumuralab.org/tex/mod/forum/discuss.php?d=3654#p22731
https://okumuralab.org/tex/mod/forum/discuss.php?d=3654#p22732