Open aminophen opened 6 years ago
t-tk
commented
4 years ago ちなみに、日本語WindowsかつpTeXでは、たしか、
コマンドラインがCP932(Shift_JIS)であることを前提に入力バッファにそのまま渡す(CP932のまま)ので、コマンドラインのUnicodeはpTeXの入力バッファに渡らない(^^ab化されない)ようになっていたと思います。ただし、CP932なので"①"は機種依存文字として日本語のトークンになると思います。
ファイル入力(\input{文字列ほげ}など )の場合はnon-windowsと動作は同じです。
aminophen
commented
4 years ago 記憶を元に書くと
ありがとうございます。しかし，
\input{文字列ほげ} をptexencが入力バッファに取り込む際にUTF-8→EUC変換 変換できなかったバイト列は ^^ab に変換
のところは， ~入力バッファの時点ではまだバイト列のまま（^^ab が出てくるのはもっと後）だと思います。現に ①.tex の内部表現に EUC で解釈できないバイト列が残っていて，それがファイルアクセス時の関数 ptenc_from_internal_enc_string_to_utf8 でヌル文字になっているようですので。~ そこに至るまでの過程を知りたいです。（ソース読めと言われそうな話ですが，構造が複雑でよくわからず…。）
→ edit: 少しわかりました。入力バッファの時点で ^^ab に変換が済んでいて，それが欧文の 8bit 処理に回った結果としてそれがバイト列と同一視されるということを仰っているのですね。
aminophen
commented
4 years ago https://github.com/texjporg/tex-jp-build/issues/45#issuecomment-619474440 を私が正しく理解できていればですが
UTF-8→EUCに変換できない場合にどうするのか
の『仕様案3「^^ab 形式に変換する」を実現すること』と，
「\input{文字列ほげ} と hogetex 文字列ほげ.tex が同じファイルを探す」
を『non-windows の pTeX で Unicode の範囲で実現すること』は同値ではないでしょうか。
実現に労力がかかるのであれば推進する意図はありませんが，\input でファイルオープンに使われている関数を流用するだけで実現できるのであれば進めたいとも思います。
h-kitagawa
commented
4 years ago 仕様案3「^^ab 形式に変換する」を実現すること』
printkanji_16bit ブランチ上で行った変更ですが， https://github.com/h-kitagawa/tex-jp-build/commit/02484d883de65c64311e7909f1e1191b4ca4293b みたいな感じでしょうか．
\input{a①ſ.tex} も eptex a①ſ.tex も 実際にはファイル a^^e2^^91[a0][e9][a1][9b].tex （つまり， を探しにいきます．a^^e2^^91顛.tex）
t-tk
commented
4 years ago 入力バッファの時点で ^^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
commented
4 years ago "ſ" はどこに行ったのでしょう?
結論から言うと，[e9][a1][9b]「顛」に化けています（texjporg/platex#84 などと同様）．例が悪かったですね．
name_of_file+1) には [c5][bf] というバイト列で格納されるopen_input (lib/openclose.c) で name_of_file+1 が UTF-8 に変換される際に，この 2 バイトは EUC [c5][bf] （= U+985B 顛）とみなされ，[e9][a1][9b] となるaminophen
commented
4 years ago
a^^e2^^91[a0][e9][a1][9b].tex
e2 91 だけが ASCII の ^^ 記法になり，a0 が単一バイトなのはどうしてでしょうか。
h-kitagawa
commented
4 years ago e2 91 だけが ASCII の ^^ 記法になり，a0 が単一バイトなのはどうしてでしょうか。
[a0] は EUC の第一バイトでない (multibytelen(0xa0)=1) ので，ASCII の場合の処理に割り振られるからですが，あまりにも処理が大雑把でしたね．また考えます．
t-tk
commented
4 years ago 現状の \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
commented
4 years ago 現状の \input{顛.tex} の期待される動作 …
私の理解もその通りです。
\input{ſ.tex} が … \input{顛.tex} と区別できない
そこは #81 が絡んでくる話だと思います。
h20y6m
commented
2 years ago printkanji_16bit とは関係なさそうなのでこちらに書きます。
UTF-8 な Linux 上の pTeX で pdfTeX 由来のファイル名をとるプリミティブ \pdffiledump, \pdffilemoddate, \pdffilesize, \pdfmdfivesum が日本語ファイル名を見つけられないようです。
texmfmp.c の find_input_file で文字コード変換すればよい？
aminophen
commented
2 years ago 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
https://github.com/texjporg/tex-jp-build/commit/79641befbe06dad66fe5523f323610c6e212355e を r62514 でコミットしました。
t-tk
commented
1 year ago upTeX で内部コードが euc/sjis の場合の日本語ファイル名 https://github.com/texjporg/tex-jp-build/issues/136 、 特に https://github.com/texjporg/tex-jp-build/issues/136#issuecomment-1359496733 で見たように、r65330 でサポート対象と思っていた範囲では動いていると思います。
『non-windows の pTeX で Unicode の範囲でファイル名を扱えるようにする』『windows の pTeX で Unicode の範囲でファイル名を扱えるようにする』について p(La)TeX で非JIS X 0208のutf8のファイル名は、現状、もろもろの障害があって動きませんが https://github.com/texjporg/tex-jp-build/issues/147 とか https://github.com/texjporg/tex-jp-build/issues/149 とかをごちゃごちゃやれば実現可能と思います。私としては、pLaTeX 向けに非JIS X 0208のutf8を頑張るのは割に合わない気がして意欲が湧かなかったのですが、pLaTeX on npTeX 向けならばリソースを割いてもいいかな、と思い始めています。
tueda
commented
1 year ago 少し違う話かもしれないので恐縮ですが、TeX Live 2022/dev/Debian、LANG=C.UTF-8において、ptex --recorder アレを実行すると、.dvi、.logファイルは期待通りの名前で生成されますが、.flsファイルの名前はおかしくなりました。
$ ls
''$'\245\242\245\354''.fls' アレ.dvi アレ.log アレ.tex少し違う話かもしれないので恐縮ですが、
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 の文字コードを変換すればよさそう？
これを調べていてたら -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 になっているはず？）
t-tk
commented
10 months ago *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} の差分が出る場合は、 https://github.com/texjporg/tex-jp-build/issues/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
Windows ではこのようなヤヤコシイことが起きないように対処されているはずなのですが，この“対処”が W32TeX では成功しているのに，TeX Live では upTeX で失敗するケースがあるという報告があります。私もまだ試せていないのですが，Windows で再現する方はいらっしゃいますか？