Turgenev's Wiki - 利用者の投稿記録 [ja]

デュアルブート

2025-10-02T06:09:16Z

Turgenev: Notion-MW

{{Outdated}}

WindowsとLinuxのデュアルブートにおいて役に立つ情報を記述する。古いメモを多く含む。[[Linuxのインストール|Linuxのインストール]]も参照。


== Windowsのプロダクトキー関連 ==

{{UnderConstruction|デュアルブート}}


== Bitlocker ==

とにかく前もって回復キーを保存しておくこと！！逆に回復キーさえあればBitlockerで大きなトラブルになることは多くない。

* [https://www.pcdock24.com/blog/?p=53931 BitLockerとは【BitLockerの要件と自動有効化の問題点】｜パソコン修理パソコンドック24] によるとローカルアカウントでBitlockerの有効/無効を確認するときはdiskmgmtから行かなきゃいけないらしい。
* Bitlockerを有効にしたあとにwinを起動すると再起動ループにハマることがある。解決法(Manage-bdeを使う)→[https://community.spiceworks.com/how_to/124388-stop-a-bitlocker-boot-loop Stop a BitLocker boot loop - Windows Forum - Spiceworks]


== Windowsパーティション（NTFS）のマウント ==

{{Outdated}}

==== remove_hiberfileについて ====

マウントが成功するにはWindowsが完全シャットダウンされている必要がある（またはそれが望ましい）。ただ、[https://unix.stackexchange.com/questions/107978/cant-access-windows-drive-windows-is-hibernated-refused-to-mount https://unix.stackexchange.com/questions/107978/cant-access-windows-drive-windows-is-hibernated-refused-to-mount]にある通り、windowsを正しくシャットダウンしてもなぜか「ハイバーネートされててマウントできません」的なのが出ることがあるので、マウントオプションにremove_hiberfileを追加するとよい。

* 高速スタートアップを無効にしているにもかかわらず完全シャットダウンされていないことがある気がしたので、Windowsでシャットダウン時に実行するスクリプトとして完全シャットダウンコマンドを追加したりした
* デスクトップPCではだいたい不要？


=== Bitlocker無し ===

普通にntfs-3gを使う。数字など適宜読み替えること。主にWindowsのDドライブ想定。

<ul>
<li>コマンド例
<syntaxhighlight lang="javascript">ntfs-3g -o remove_hiberfile /dev/nvme0n1p5 /media/win</syntaxhighlight></li>
<li>fstabの例
<syntaxhighlight lang="javascript">/dev/sda2 /media/ddrive ntfs-3g noauto,rw,nofail 0 0</syntaxhighlight></li></ul>


=== Bitlocker有り ===

ntfs-3gの前にDislockerで暗号化を解除する。参考→[http://www7390uo.sakura.ne.jp/wordpress/archives/270 http://www7390uo.sakura.ne.jp/wordpress/archives/2]

dislocker-fileの方式だと一旦復号したのをファイルに書き出して静的にマウントするので、（事実上）readonlyとなる。よってdislocker-fuseを使う→[https://www.systutorials.com/docs/linux/man/1-dislocker-fuse/ https://www.systutorials.com/docs/linux/man/1-dislocker-fuse/]

<ul>
<li>コマンド例
<syntaxhighlight lang="vb.net">$ sudo dislocker-fuse -V /dev/nvme0n1p3 --recovery-password=xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx -- /media/dl-fuse
$ sudo mount -o loop,rw /media/dl-fuse/dislocker-file /media/win/</syntaxhighlight></li>
<li>fstab例
<syntaxhighlight lang="vb.net">/dev/nvme0n1p3 /media/bitlocker fuse.dislocker recovery-password=xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx 0 0
/media/bitlocker/dislocker-file /media/win10 ntfs-3g rw,nofail,remove_hiberfile,permissions 0 2</syntaxhighlight>
と、二行に分けて記載する。
<ul>
<li>permissions については後述</li></ul>
</li></ul>

==== セキュリティ問題 ====

recovery-passwordを暗号化されていないパーティションに書いてしまうと結局Bitlockerの意味が全くなくなってしまうので、Linux側でもBitlockerのような暗号化パーティション（LUKSとか？）やユーザーログイン時に復号される暗号化フォルダ（ecryptfsとか）といったディスク上で暗号化される領域に書いておく必要がある（もちろん毎回パスワードの類を打ち込むのでよければそれでもいい）。


=== permissions, inheritについて ===

[https://github.com/tuxera/ntfs-3g/wiki/File-Ownership-and-Permissions https://github.com/tuxera/ntfs-3g/wiki/File-Ownership-and-Permissions] 詳しくはこちらも参照。

まず、マウントオプションとしてpermissionsを指定しない限り、ntfs-3gでマウントしたファイルは全てパーミッション・所有者が固定（uid, gid, umaskなどで指定）となり、個別のファイルについて変更することはできない。

そして、この場合、ntfs-3g経由で作成したファイルはWindows側で見るとすべてAdministratorの所有となり、さらにEveryoneにフルコントロール権限が付与される（この動作を変更するのは筆者の知る限り不可能）。

Linuxではフォルダの実行権限（x）が無ければその中に含まれたファイルにはアクセスが通らず、パスを推測することも不可能だが、Windowsではたとえ一切権限のないフォルダであっても中にあるファイル・フォルダのパスがわかれば直接パスを打つことでアクセスが通ってしまうようである（試した限り）。そのため、permissions無しでntfs-3gで作成したファイルはパスさえわかればWindows上の全ユーザーが閲覧・編集・削除できる状態ということになる。

従って、Gitを使用する場合や複数ユーザーで使用したい場合などパーミッション管理が必要なデータを扱う場合はもちろん、単に中にあるデータを保護したいという場合でもpermissionsオプションを指定することが必須になる。

次に、permissionsを指定して、かつUserMappingを指定しない場合、Linux上でrootが所有するファイルをWindows側で見ると、全てAdministratorsの所有物になり（ここはpermissionsがない場合と同じ）、そのアクセス権はLinux上での見え方と概ね一致するように設定されるようである。他のユーザーが所有するファイルにはS-1-5-21-3141592653-589793238-462643383-10000というような上位桁が円周率に由来する（この部分はハードコードされている）SIDが割り当てられ、こちらもアクセス権が適切に設定される。UserMappingを指定することで、このSIDの部分の割り当てを変更することができる。

Windowsに挙動を近づけるための他のオプションとしてはinheritというのもあり、これは新規作成時に上位フォルダの権限を継承するものである。しかし、これは所有者を継承するオプションではない（そして、所有者が違えばまともに継承もされない）。

* [https://github.com/tuxera/ntfs-3g/issues/90 https://github.com/tuxera/ntfs-3g/issues/90] では、UserMappingがなくても所有者が継承されるようになるパッチが示されているが、これを使うとpermissionsは動かなくなる（chmodなどが使えない）。自力で変えようとしてみたが、うまくいかなかった。

以上のことから、Windowsの一般ユーザーフォルダの内容などをLinuxから良い感じに（Windows側の権限設定を汚染せずに）使えるようにするには、明示的なUserMappingが事実上必須であることがわかる。

一方で、Administrator所有・全ユーザー閲覧可能（あるいは不可能）、といった、Windows側の全ての一般ユーザーに対して共通のアクセス権を適用する設定であれば、UserMappingを使用しなくても簡単に設定が可能である。個人用PCかつ、画像・動画などのメディアファイルやLinuxでしか使用しない大きめのソフトウェアを入れておく用途であれば、こちらで問題ないだろう。

Linux側で別ユーザーの所有に見せたい場合は、上記のS-1-5-21-3141592653-589793238-462643383-10000のようなSIDが見えてしまう状態でもよければ（かつ、権限設定にも問題がなければ）それでもいいし、下記のbindfsと併用する方法もある。いずれにしても、Linux側で全員が読み取り・書き込み・実行が可能なファイルは、Linux側での親フォルダの権限によらず、Windows側では（パスさえわかれば）対応する権限でアクセスができてしまうということに注意が必要である。一応、パス名をランダムなものにするという対策は考えられそうではある。

また、Windowsではファイルの新規作成時には必ず実行権限が付加されるので、Linux側でそれを見た場合も実行可能になる（実行権限を外すと.exeなどが実行できなくなる）。従って、GitのレポジトリのフォルダをWindows/Linux間で共用するようなことをすると、Windows側では実行権限無しで（これがデフォルトであるため）コミットされたファイルがLinux側では実行権限有りに見えるため差分が出てしまうといったことが発生する。これはUserMappingでも解決はできないので、Gitリポジトリのあるフォルダを共用するのは不可能である。

結局、後述のbindfsと組み合わせると、以下のようにするのが良さそう。

<ul>
<li>大元のntfsパーティションは、permissionsでマウント。UserMappingを使ってもよい。</li>
<li>Linux側でパーミッションを変更できる必要がなく、Windows側と共用したいものについては、bindfsで再マウントし、create-with-perms=a+rwxによってWindows側でアクセスに制約が出ないようにする。
<ul>
<li>より完全なオプションとしては、以下のような感じ？
<syntaxhighlight lang="javascript">map=root/myname:@root/@myname,perms=a+rwx,create-with-perms=a+rwx,chown-ignore,chgrp-ignore,chmod-ignore</syntaxhighlight></li></ul>
</li>
<li>Gitのようにパーミッションを変更できる必要があるものは、改めてこれも別のbindfsとして再マウントする。この場合、Windows側からはアクセスの問題が生じる可能性があるので、とりあえず内容だけ確認したいときに見られればいいという状況で使うのがいいだろう。</li>
<li>あるいはbindfsを1つにまとめてcreate-with-perms=+rw（xは指定しない）にするのもいけるかもしれないが、本当にうまくいくかどうか…</li>
<li>設定例</li></ul>

<syntaxhighlight lang="javascript">UUID=109B0ED0109B0ED0 /media/localdisk ntfs-3g permissions,nofail 0 0
UUID=040CAEB80CAEA460 /media/cdrive ntfs-3g permissions,nofail,remove_hiberfile 0 0
/media/localdisk /home/useruser/.mnt/localdisk2 fuse.bindfs nofail,map=root/useruser:@root/@useruser,create-with-perms=g-w 0 0
/media/localdisk /home/useruser/.mnt/localdisk fuse.bindfs nofail,map=root/useruser:@root/@useruser,perms=a+rwx,create-with-perms=a+rwx,chown-ignore,chgrp-ignore,chmod-ignore 0 0
/media/cdrive /home/useruser/.mnt/cdrive2 fuse.bindfs nofail,map=root/useruser:@root/@useruser,create-with-perms=g-w 0 0
/media/cdrive /home/useruser/.mnt/cdrive fuse.bindfs nofail,map=root/useruser:@root/@useruser,perms=a+rwx,create-with-perms=a+rwx,chown-ignore,chgrp-ignore,chmod-ignore 0 0</syntaxhighlight>
==== bindfs ====

既存のディレクトリを、所有ユーザーやパーミッションを変更してマウントしてくれる。

<syntaxhighlight lang="python">sudo bindfs --mirror=myname --force-group=myname /media/win ~/.mnt_win/</syntaxhighlight>
または

<syntaxhighlight lang="python">sudo bindfs --force-user=myname --force-group=myname /media/win ~/.mnt_win/</syntaxhighlight>
この2つの違いは不明

作成した

sudoがないと<code>fusermount: option allow_other only allowed if 'user_allow_other' is set in /etc/fuse.conf</code>とか言われたりする

fstabの例

<syntaxhighlight lang="python">/media/win /home/myname/.mnt_win fuse.bindfs nofail,map=root/myname:@root/@myname,create-with-perms=g-w 0 0</syntaxhighlight>
Linuxだとrootのデフォルトのumaskが022で一般ユーザーが002なせいで一般ユーザーが作ったファイルが775とか664になってしまったりするがg-wをつけることによって755とか644になる（もちろんchmodすれば変えられる


== Minecraft ==

.minecraftフォルダをWindowsとLinuxで共有したはいいが、（それ自体.minecraftの中にある）ゲームディレクトリの指定も共有することを考えると、両OSでパスの仕様がやや異なるのが問題になる。

例えば以下ではWindowsのルートが/media/winにマウントされているとする。

まずLinuxのランチャーは相対パスどころかシンボリックリンクすら変換して普通の絶対パスにしてしまう（設定を書き換えてしまう）っぽいので、linuxでは絶対パス指定で/media/win/Users/pathのようにする。で、この書き方をするとWindowsでは相対パスと解釈されるのだが、基準となるフォルダが謎で、「PLAY」を押した時のチェック時は.minecraftが基準なのだが、実際に見られるのはランチャーがあるフォルダが基準（＝こっちになかった場合ゲームディレクトリが新たに作られる）

* ストアアプリ版の（新しい方の？）Minecraftランチャーでは、この「ランチャーがあるフォルダ」は<code>AppData\Local\Packages\Microsoft.4297127D64EC6_8wekyb3d8bbwe\LocalCache\Local</code> あたりである。

従って、ランチャーのフォルダと.minecraft内の両方にmediaというフォルダを作って中にwinという名前でC:\へのジャンクション置くとうまくいく。

ちゃんと設定されていれば、実体フォルダは必ずしもRoaming以下の階層になければならないわけではない。

.minecraftの中にはゲームディレクトリ専用のフォルダを作り、その中にmain, snapshotなど用途に応じたフォルダを作っておくとよい

== google-drive-ocamlfuse ==

labelを使うと複数アカウントをマウントできる。デフォルトのラベル名はdefault

しばらく使っていないと起動時におそらく認証の失敗が原因でマウントポイントのあるフォルダに対するlsがしばらく一切反応しなくなる（~/.gdfuse内の該当ラベル名のフォルダを削除して最初からやり直せば治る）。よってマウントポイントをホームディレクトリ直下に作るのは避けたほうがよい（gdfというフォルダを作っている）。


== MEGA ==

Winが完全にはシャットダウンされていない状態でLinuxを起動するとCドライブ上のMEGAのフォルダが読めずに同期が無効になってしまう。MEGA自身のかわりに、Cが読める状態でのみMEGAを起動するシェルスクリプト（mega-mounted.sh）をスタートアップに登録しておく。Cが読めなかった場合にはdialogコマンドで通知ダイアログを表示する。（このスクリプトではC自身のかわりにC:\Windowsをみている）（gdialogは一部のディストリにしか入っていないかもしれない。実際にコマンド打ってみてどんな表示になるかも含めて確かめておいたほうがよい）

<syntaxhighlight lang="shell">#!/bin/sh
if [ -d /media/win-rw/Windows ]; then
megasync
else
gdialog --title "Warning" --infobox "MEGAsync is not started because Windows partition is not mounted" 0 0
fi</syntaxhighlight>

== Bluetooth機器 ==

同じBluetooth機器を同じPCのWindowsとLinux双方にペアリングするというもの。自分はマウスでしかやったことがない。意外と難しいが何とかなる。

==== 参考 ====

* [https://orumin.blogspot.com/2019/02/bluetooth.html https://orumin.blogspot.com/2019/02/bluetooth.html]
* [https://qiita.com/yoko-yan/items/9b0235678fd804b4fe0d https://qiita.com/yoko-yan/items/9b0235678fd804b4fe0d]
* Bluetooth Low Energyという仕様もあるらしく、自分のマウスはこっちだった。これに関しては[http://aimingoff.way-nifty.com/blog/2018/09/windows-linux-b.html http://aimingoff.way-nifty.com/blog/2018/09/windows-linux-b.html]を参照。割と情報が少ないので感謝。
** <code>HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTHPORT\Parameters\Keys\xxxxxxxxxxxx</code>を見るためにpstoolsをダウンロードして<code>PsExec64 -s -i regedit</code>とする必要があることに注意。なお、セキュリティソフトによってPsexecが脅威と見なされ強制削除されてしまうときは代わりにフリーソフトのAdvancedRunを使うとよい。
** まとめ
*** CSRKをLocalSignatureKey
*** LTKをLongTermKey
*** EDIVをEdiv（16進→10進に変換）
*** ERandをRandに（バイト(2文字のかたまり)をすべて逆順にしてから10進変換）。ちなみにこれを間違えた結果、マウスを動かすたびにbluetoothアイコンが白↔黒と高速で切り替わる謎のバグっぽい現象が起こったことがあった。
*** 小文字を大文字に変える必要はない。また、IRKをIdentityResolvingKeyに書くのも不要。


==== マルチデバイス対応マウス（Logicool） ====

マルチデバイス対応（切り替えボタンがあるやつ）のマウス（LogicoolのM595）を使ったら、登録情報を一旦削除して再接続するごとにMacアドレスがひとつインクリメントされて困った。Linuxで接続→Winで接続→Linuxで上記の書き換え、とやったあと、フォルダ名を変更（1を足せばよいはずだが正確にはWinの情報を見るのがよい）するとうまくいった。[https://twitter.com/e9g/status/1381111849664409600 自分のツイート]にも記録あり
[[Category:IT]][[Category:Windows]]{{#seo:|title={{FULLPAGENAME}} - Turgenev's Wiki}}

AFDKOによるOpenTypeフォントの作成

2025-10-02T06:09:09Z

Turgenev: Notion-MW

筆者は[https://github.com/adobe-type-tools/afdko Adobe Font Development Kit for OpenType (AFDKO)]を用いて、[https://github.com/ge9/NazonoMincho 謎乃明朝]というフォントを作成し公開している。謎乃明朝は[http://fonts.jp/hanazono/ 花園フォント]と同じく[https://glyphwiki.org/wiki/GlyphWiki:%e3%83%a1%e3%82%a4%e3%83%b3%e3%83%9a%e3%83%bc%e3%82%b8 GlyphWiki]のデータをもとにしている完全フリーのフォントであるが、GlyphWikiデータからの漢字のパスデータの生成においてオリジナルの[https://github.com/kamichikoichi/kage-engine KAGEエンジン]を[https://github.com/ge9/kage-engine-2 改変したもの]を使用している。

改変エンジンのget_sub_path_svg_fontという関数を使用すると、[0 -120 1000 880]をバウンディングボックスとしたときに適切に表示されるようなパスがSVG形式で出力される。この記事ではそこから先のプロセスについて解説する。

他に全体を通して参考になるサイトとしては以下がある。

<ul>
<li>[https://shiromoji.hatenablog.jp/entry/20111206/1323270030 AFDKO入門《CIDキー方式のOpenTypeフォントの作り方》前篇：AFDKOのインストールとmergeFonts - しろもじメモランダム]
一通りのことが書いてある読みやすい日本語の記事はこれくらいである。筆者もこれを参考にした。</li>
<li>[https://ccjktype.fonts.adobe.com/wp-content/uploads/2012/06/afdko-lunde-20120625.pdf https://ccjktype.fonts.adobe.com/wp-content/uploads/2012/06/afdko-lunde-20120625.pdf]
ワークショップで使用した講義資料なので単体だとやや読みづらいが、ヒント情報の付加に関して唯一まともに書いてあった。</li>
<li>[https://aznote.jakou.com/prog/opentype/index.html OpenType フォント・フォーマット]
OpenTypeの仕様が日本語で記述されている。</li></ul>


== パスの統合・単純化 ==

これはAFDKOには関係ないが割と役に立つ話なのでついでに記載する。


=== Inkscapeによる統合 ===

改造エンジンで生成した漢字パスデータはそれぞれの画が別々のサブパスで表現されており、互いに重複する部分がある。これをそのままフォントに使うこともできるが、画が交差する場所（「田」の中央とか）で白い抜けが表示されてしまうなど不具合が生じる場合がある。そこで、重複がなくなるようにパス同士のUnionを取る（統合する）必要がある。

この目的で本家の花園明朝では[https://github.com/AngusJohnson/Clipper2 Clipper]が使われているが、こちらはどうやら直線のみ対応で、ベジェ曲線は扱えないようである。ベジェ曲線にも使えるフリーのものはFontforgeとInkscapeがあるがFontforgeは色々と不安定なのでInkscapeを使う。

* Fontforgeは一応試したが、閉じていないパスが発生する不具合が頻発するのと、GUIだと途中で落ちる。ところで、謎乃明朝にissue([https://github.com/ge9/NazonoMincho/issues/2 https://github.com/ge9/NazonoMincho/issues/2])が立ったが、KAGEデータの「曲げ」ストロークにおいてInkscapeの統合によって図形が消えるバグが発生していた（[https://gitlab.com/inkscape/inbox/-/issues/6886 https://gitlab.com/inkscape/inbox/-/issues/6886] に報告済）（謎乃明朝側ではストロークの図形をあらかじめ統合された状態で生成することで回避して対応済）。Inkscapeも完璧ではないようである。

コマンドとしては

<syntaxhighlight lang="vb.net">inkscape --actions="select-all;path-union" --export-type=svg input.svg</syntaxhighlight>
などとすると、input_out.svgが出力される。

ワイルドカード<code>*.svg</code>も使えるが、謎乃明朝のビルド時はかなり大量のファイルを処理するために「コマンドライン引数が長すぎる」的なことを言われてしまうのでxargsを使った（自動で分割してくれる）。

個々のsvgファイルとして処理する（出力ファイルを逐一新規作成する）ためIOが頻発して効率はあまりよくない（謎乃明朝の数万グリフに対して実行すると数十分かかる）のだが、入力ファイル単位で分ける以外で複数のパスデータをバッチ処理で統合する（例えばsvgの”path”タグごと処理するなど）方法があるのかどうかはわからなかった。分かったら誰か教えてください。


=== Fontforgeによる単純化 ===

統合を行うと、（KAGEエンジン側のデザインの都合もあり）完全な直線になるべき部分が微妙な誤差のせいでほぼ直線と変わらない微妙な折れ線になってしまうことがある。また、極めて短く直線に近似できるのにベジェ曲線で表現されてしまう場合もある。こうした箇所はデータ削減やヒント（後述）の品質向上のために制御点を除いて単純化（simplify）したい。

Inkscapeにも単純化はあるのだが、やってみたところ、単純化を行うと逆に曲線部分では無駄な制御点が挿入されてしまうというバグ（[https://gitlab.com/inkscape/inbox/-/issues/8096 報告済み]→[https://gitlab.com/inkscape/inkscape/-/issues/4419 こちら]に移動）があったので今回はスキップ。単純化に関してはFontforgeのほうが良さそうである。

FontforgeはSVGフォント（＝単一ファイルに複数のパスを入れられる）に対応しているので、先ほどInkscapeが出力したファイルを一つにまとめてからFontforgeに入力して全グリフをSimplifyするという流れになる。あとFontforgeのGUIは割と不安定（特にWindows版）なので、対象が1000個を超えるような場合はスクリプトを組んでCUIで実行することを強く推奨する。

例:

<syntaxhighlight lang="python">Open($argv[1])
SelectAll()
Simplify(128+32+8, 1.1)
Generate($argv[2])</syntaxhighlight>
* 手元では「NaN value in spline creation」というエラーが漢字10000字につき1.5文字くらいの割合で出るのだが、該当文字を見ても特に問題はなさそうだったので放置している。


== AFDKOでのフォント作成 - 基本 ==

基本的には

素材フォント→（適宜txなどで変換した上でmergefonts）→ヒント情報無しのCIDフォント→（[https://github.com/adobe-type-tools/perl-scripts/blob/master/hintcidfont.pl perl-scripts/hintcidfont.pl at master · adobe-type-tools/perl-scripts] と psautohintによるヒント情報の付加）→ヒント情報付きのCIDフォント→（makeotf）→完成品の（CIDキー方式の）OpenTypeフォント

という流れになる。

「CIDフォント」「PostScriptフォント」「CFFフォント」「Type1フォント」「OpenTypeフォント」など様々な用語があるが、いずれも正確な定義が難しいものばかりであり筆者も正確に理解しているわけではないのでそこは注意して読み進めていただきたい。今回作るものは「CIDキー方式のOpenTypeフォント（CID-keyed OpenType Font）」だが、おそらくCFFフォントでもあり、PostScriptフォントでもあるのではないかと思われる。


== txで使えるSVGデータ ==

{{Valuable}}

<s>まず、単体のSVGではフォントとして正しくtxに認識されないので、SVGフォントの形にする必要がある。具体的には、</s><s>タグが最も外側にある状態</s><s>にする。「SVGフォント」といったときには（例えばFontforgeでフォントとして開く場合）さらに外側に</s><s><code><svg><defs>…</defs></svg></code></s><s>のようなタグが必要になる場合もあるが、これだとtxには弾かれるので注意が必要である。</s>

<ul>
<li>（2023/12/21追記）改めて試したところ、<code><svg><defs>...</defs></svg></code>で囲っても問題なく動いた。ただ、FontForgeが出力するSVGフォントのヘッダーの
<syntaxhighlight lang="shell"><?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd" ></syntaxhighlight>
があると動かなかったので、上記の内容はおそらくそれを勘違いしたものと思われる。なお、このヘッダがなくてもFontForgeは正しくSVGフォントを開けるが、<code><svg><defs>...</defs></svg></code>がないと開けないので、<code><svg><defs>...</defs></svg></code>は付けてヘッダーは無しで保存しておくのが最も良さそうである。</li>
<li>txのエラーメッセージは全体的にあまり丁寧ではなく、例えば入力のsvgに何かおかしい点（※ただしtxによる主観的評価）がある場合は<code>(svr)</code>などとしか表示してくれない。デバッグモードもなさそうなので、根気強く原因を探すしかない。
<ul>
<li><code>(svr)</code>のような形式の出力については、おそらく最初の二文字（ここでは<code>sv</code>=svgだが、<code>cf</code>=cffなどもある）がフォーマットを表し、最後の一文字は<code>r</code>がerror、<code>w</code>がwarningを表すようである。</li></ul>
</li>
<li>そもそもAFDKO自体に「Adobe社内の業務用ツールが形だけ一般公開されている」ような雰囲気を感じなくもないような…</li></ul>

例えば以下は正しくtxに認識される入力のsvgである。

<syntaxhighlight style="margin-bottom:0.2em;" lang="xml">
<font-face
font-family="Untitled1"
font-weight="400"
font-stretch="normal"
units-per-em="1000"
ascent="880"
descent="-120"
bbox="0 0 1000 1000"
underline-thickness="50"
underline-position="-100"
/>
<missing-glyph horiz-adv-x="1000" d="M500 300l150 -300l-300 0zM650 760l-150 -300l-150 300l300 0zM730 760l0 -760l-190 380zM270 760l190 -380l-190 -380l0 760zM200 830l0 -900l600 0l0 900l-600 0z"/>
<glyph unicode="0" horiz-adv-x="1000" d="m-100,-100l100,0L0,100C0,200 200,0 200,200 m100,200 c 300,0 0,300 300,300 Zm-150,-150 c 200,100 -100,0 0,100 l-300,-200 l100,200 z"/>
<glyph unicode="S" horiz-adv-x="500"/>
<glyph unicode="D" horiz-adv-x="1000"/>
</syntaxhighlight>
<div style='text-align: center;'>system.svg</div>

今回はsvgを素材としてのみ使用する（フォント名などは後で設定する）のでfont-faceタグの中身はあまり気にしなくてよいと思うが、フォントの高さ範囲を決める<code>ascent</code>と<code>descent</code>は一応正しい値を入力してある。OpenTypeでは通常このようにフォントの高さは1000とする。

以降がフォント本体のデータで、パス（d属性）と水平方向の幅（horiz-adv-x属性）をそれぞれ指定する。

<code>missing-glyph</code>は普通のフォント用語でいうと<code>.notdef</code>にあたるもので、文字が無かった時に表示されるいわゆる「豆腐」のことである。他のフォント形式に変換するとこのグリフが<code>.notdef</code>に割り当てられることになる。このsvgではU+303F（〿、□の中に×が入った形）のような図形が入っている。

それ以降のglyphタグではunicode属性によりどの文字を使用するかを設定している。<code>S</code>や<code>D</code>のようにd属性がない場合は空白（スペース）を表すことになる（逆にd=””などと書くとエラーになったはず）。幅を見ればわかる通り、Sが半角スペース、Dが全角スペースである。

==== d属性の解釈について ====

{{Valuable}}

txによるd属性の解釈はものすごく行儀が悪く、エラーメッセージを出さない割に明らかに仕様を満たさない挙動を連発する。

* txの挙動を迅速に確かめるには、<code>tx -pdf input.svg > output.pdf</code>とpdfに変換して見るのがよい。
* 以下の不具合に関する具体的な報告はなさそうであるが、[https://github.com/adobe-type-tools/afdko/issues/1567 [tx/SVG] Replace homemade XML parser with LibXML2 for SVG parsing · Issue #1567 · adobe-type-tools/afdko]は関係がありそうなのでこれがfixされれば治る可能性がある。

txの1.3.0（2023年1月現在で多分最新）に関して挙動をまとめる。

まず、正しく解釈できると思われるのは以下の命令である。

* M（絶対座標によるパス開始点の指定）
* L（絶対座標による直線描画）
* l（相対座標による直線描画）
* C（絶対座標による3次ベジェ曲線描画）
* z, Z（パスを閉じる）

問題なのはc（相対座標による3次ベジェ曲線）で、本来は現在の点が(x, y)であるときに<code>c x1,y1 x2,y2 x3,y3</code>とすると(x, y)→(x+x1, y+y1)→(x+x2, y+y2)→(x+x3, y+y3)という3次ベジェ曲線が描画されるべきであるが、txでは(x,y) → (x+x1, y+y1) → (x+x1+x2, y+y1+y2) → (x+x1+x2+x3, y+y1+y2+y3) という意味に解釈される。

似たような問題として、パスの開始点（最初やzの直後で使用する）でm（相対座標指定）を使用する場合は、本来は絶対座標として解釈されるべきであるが、txでは直前の座標（zの直前）からの相対位置で計算される。なお、フォントの描画においては必ず閉じたパスを使用する（多分）のでパスの描画途中でMやmを使用することはありえないが、仮に使用した場合、（txでは）その直前にzを付加したのと同じ挙動をするようである。

そして、以下には対応していない。

* V, v, H, h（絶対/相対座標による垂直/水平な直線の描画）
* Q, q（絶対/相対座標による2次ベジェ曲線描画）

これらはそれぞれL, lとC, cに容易に変換できるので、そのようにしてから渡すべきである。

さらに、svgではデータ量の圧縮のため直前と同じ命令を使用する場合は<code>l 100,100 l 200,200</code>と書くかわりに<code>l 100,100 200,200</code>などと略することができるがこれにも対応していない（余ったパラメータは余計なものとして無視される）。

また、svgの仕様では座標データの数字において指数表現（1.2345e-6のような）が許容されているが、これにも対応していない（<code>(svr)</code>となる）。

謎乃明朝で使用したsvgに関しては、元データでM,C,Lのみ使っていたおかげかinkscapeの出力でもそれら以外が入ることはないようだったが、指数表現に関してはごく稀に（謎乃明朝全体でも10個以下程度）紛れ込んでいたので<code>sed -r "s/ -?[0-9]\.[0-9]*e-[0-9]+ / 0 /g"</code>で0に変えた。小数に直すのが筋かもしれないが、OpenTypeではそもそも座標が整数に丸められる気がするのでこれでいいはず。

* Inkscapeが相対座標を使用するかどうかは設定で変えられるらしい。参考: [https://stackoverflow.com/questions/6890685/is-there-a-tool-to-convert-svg-line-paths-from-absolute-to-relative Is there a tool to convert SVG line paths from absolute to relative? - Stack Overflow]


==== FontForgeの出力の修正 ====

FontForgeで出力されるsvgには<code>l</code>や<code>c</code>に加えて<code>h</code>や<code>v</code>なども（元データになくても）入ることがあり、これはtxが読めないので修正する。あとtxには関係ないが、PostScriptアウトラインの向きはFontForgeが出力するSVGのアウトラインの向き（＝TrueTypeのアウトラインの向き）と逆なので、この段階で修正しておくとよい。この2点の修正は謎乃明朝の生成スクリプトでは[https://github.com/thednp/svg-path-commander https://github.com/thednp/svg-path-commander]にやらせている。

== txによる変換 ==

この次で使用するmergefontsは、複数のフォントをマージするコマンドであるが、より正確には「親」となるフォントに「子」となるフォントを統合するコマンドである（ヘルプにも書いてある）。上記のようなsvg形式のフォントは「子」にはなれるが「親」にはなれない。

そこでtxコマンド（fonttoolsのttxと名前が似ているが全く異なるものなので注意）を用いてsvgを「親」として使えるフォーマットに変換する。この際の出力は、<code>-ps</code>(PostScript形式)、<code>-cff</code>(CFF形式）、<code>-t1</code>(Type1形式)などいくつかのオプションが選べるが、psautohintでヒントを付ける方法を筆者が発見できたのは<code>-t1</code>を使った場合のみであった。ヒントを付けないのであれば-cffでも問題なくこの記事の最後まで進むことができる。-psも-cffと同じだったと思う。

ちなみにmergefontsは子としてsvgが指定された場合にはそれを読むために内部的にtxを使用するため、子にしても親にしてもtxが読めるsvgを指定する必要がある。

謎乃明朝では、.notdefや空白など一部のシステムグリフ的なものだけを含むsvg（上記のsystem.svg）を親フォントとしてまずType1形式に変換したあと、子フォントとして漢字グリフを統合することにしている。

従ってコマンドとしては以下のようになる。

<syntaxhighlight lang="vb.net">tx -t1 system.svg > system.pfa</syntaxhighlight>
参考までに、system.pfaの最初のほうは以下のようになっている。

<syntaxhighlight lang="vb.net">%!FontType1-1.1: Untitled1
%ADOt1write: (1.0.35)
%%Copyright: Copyright 2023 Adobe System Incorporated. All rights reserved.
%%BeginResource: font Untitled1
12 dict dup begin
/FontType 1 def
/FontName /Untitled1 def
/FontInfo 4 dict dup begin
/FullName (Untitled1) def
end def
/PaintType 0 def
/FontMatrix [0.001 0 0 0.001 0 0] def
/Encoding 256 array
0 1 255 {1 index exch /.notdef put} for
def
/FontBBox {-100 -100 950 1050} def
end
currentfile eexec BAB431EA06BB0A1031E1AA11919E714AC6968FC4C8AFEB
5F1C717DAFACA48FA00303519D5ACA187D3A7A07245E6211EF0746489B63BDB8
0250FD69171FFE98581843A94F9CCED81A25205CD6D774793B21300079565F0A
...</syntaxhighlight>
== mergefonts ==

次にmergefontsを使ってCIDフォントを作る。CIDフォントを作る場合は、コマンドの構文は以下のようになる。

<syntaxhighlight lang="vb.net">mergeFonts -cid [cidfontinfo] [output] [font1.map] [font1] [font2.map] [font2] ...</syntaxhighlight>
cidfontinfoはフォントに関していくつかの情報を設定するファイルで、今回は以下のものを使用する。

<syntaxhighlight lang="vb.net">FontName (NazoMin)
FullName (NazoMin Unknown)
FamilyName (NazoMin)
Weight (Unknown)
version (1.000)
Registry (Adobe)
Ordering (Identity)
Supplement 0
AdobeCopyright (Public Domain)</syntaxhighlight>
細かい部分の効果はわからないが（詳しくは[https://shiromoji.hatenablog.jp/entry/20111206/1323270030 AFDKO入門《CIDキー方式のOpenTypeフォントの作り方》前篇：AFDKOのインストールとmergeFonts - しろもじメモランダム]）、とりあえずこれで問題なく先に進めるだろう。FontName（Postscript名）の「NazoMin」の部分は後で使用するので覚えておくこと。FullNameとFamilyNameについては最終的にどのように反映されるのかよくわかっていない。

* Postscript名は、フォントの名前の一種であるが、あまりユーザーが目にすることはない。Postscript名では、空白を使用してはいけない。たとえば[https://github.com/adobe-fonts/source-han-code-jp/blob/master/Normal/cidfontinfo source-han-code-jp/cidfontinfo at master · adobe-fonts/source-han-code-jp]のようにハイフンに置き換えられていることが多い。また、「+」は禁止ではないようだが、今回使用するhintcidfont.plは対応していない。フォント名に「+」が入っている代表的なフォントである「M+フォント」の一種[https://fonts2u.com/m-2m-regular.font M+ 2m regular font]においても、Postscript名は「mplus」となっているようである。

outputで指定するファイル名は何でもいいが、そのままではまだ使えない「生」のCIDフォントということで「.raw」という拡張子を使う場合もあるようである。今回であればType 1が出力されるので.pfaとしてもよいだろう。

==== mapファイルと素材フォント ====

{{Valuable}}

では、残るmapファイルと素材フォントの部分について解説する。三点リーダ<code>...</code>で示した通り、この<code>[font1.map] [font1]</code>のペアはいくらでも多く指定してよい。この部分がフォントの本体部分を形作ることになる。

最初のペアとして指定されたものが前述の「親フォント」ということになる。ここにType1フォントを指定すれば出力もType1になるし、CFFフォントを指定すればCFFになる。

今回は親フォントとして先ほどのsystem.pfaを使用する。

以下がそれに対応するmapファイルの例（system.map）である。

<syntaxhighlight style="margin-bottom:0.2em;" lang="vb.net">mergeFonts NazoMin-System
0 .notdef
1 S
633 D
8720 S</syntaxhighlight>
<div style='text-align: center;'>system.map</div>

ファイルの最初にはこのようにmergeFontsという語が必要であり、その後にFDArray要素（この用語は後のヒント情報付加のところでまた出てくる）の名前を書く。ここではcidfontinfoで使用した<code>NazoMin</code>という（任意の）識別子にハイフンを付加してさらに別の（後でも使用する任意の）識別子である<code>System</code>を追加した<code>NazoMin-System</code>という名前を指定している。このようにしないと、ヒント情報を付加するスクリプトである[https://github.com/adobe-type-tools/perl-scripts/blob/master/hintcidfont.pl https://github.com/adobe-type-tools/perl-scripts/blob/master/hintcidfont.pl]が正しく使えない。これはどこを見てもあまりはっきりとは書かれおらず、最終的にスクリプトのソースを読んでわかったことなので注意が必要である（スクリプトの説明をよく読むと一応「the CIDFontName plus a unique identifier」などと書いてあるのだが、ハイフンを間に入れるという説明は全くない）。ただし、これはそうしないとこのスクリプトが使えないというだけであって、CIDフォントの仕様上必要というわけではない（多分）。ただ実際、多くのCIDフォント（例えば源ノ角ゴシックなど）ではこのような命名がされている気がする。

2行目以降が、CIDからグリフへの対応を記述したものである。

* 以下のように、x番目のCIDという意味で「CID+x」と書くことが多い

まず2行目で、CID+0に先ほどのSVGのmissing-glyphが割り当てられる。CIDフォント（少なくともCID形式のOpenTypeフォント？）ではCID+0は必ず含める必要があり、これが「豆腐」グリフとなる。

3-5行目により、CID+1とCID+8720には半角スペース（ただし後者は縦書き用として使用する。後のmakeotfの節も参照）、CID+633に全角スペースが割り当てられる。これは[https://github.com/adobe-type-tools/Adobe-Japan1 Adobe-Japan1]に従ったものであるが、Adobe-Japan1準拠のフォントを作るのでなければ（CID+0とは違って）必ずしもこのようにする必要はないはず。ただ、（現在はリンク切れとなっているのでweb archiveのURLを貼るが）[http://web.archive.org/web/20130225051414/http://d.hatena.ne.jp/mashabow/20120306/1331028598 花園明朝OTを0.510に更新、IVD 2012-03-02版に対応 - しろもじメモランダム]において、「Windowsでは、CFFアウトラインのOpenTypeフォントのGSUBテーブルにvrt2 featureが定義されていないのにvhea/vmtxテーブルがあると、OSに不正なフォントして弾かれます。」との情報があり、[http://web.archive.org/web/20161115085209/http://shiromoji.net/font/HanaMinOT/ 花園明朝OT]ではこれに対応するためにこの3グリフを追加したとされている。そこで謎乃明朝でも一応この通りにしている（ただし謎乃明朝+では漢字と範囲を分けるためにCIDの割り当てを1, 633, 8720からそれぞれ1, 100, 101に変えている）。

このファイルを見てわかる通り、ソースフォントの同じ文字を複数のCIDで使用しても構わない（その分データは増えるはず）（[https://github.com/adobe-type-tools/Adobe-Japan1/blob/master/README-JP.md Adobe-Japan1/README-JP.md at master · adobe-type-tools/Adobe-Japan1] の「重複した漢字グリフ」もその一例）。CIDの部分は0000,00001のように先頭にいくつか0が付いていても構わない。

次に、「子」として使用するmapファイルとSVGファイル（今回は子は1つだけなので1つずつ）をそれぞれ見てみよう。謎乃明朝には数万文字の漢字が収録されているが、ここでは解説に適した6グリフのみ収録したサンプルを使用する。

<syntaxhighlight style="margin-bottom:0.2em;" lang="vb.net">mergeFonts NazoMin-Ideographs
14197 u8279-j
14198 ufa5e
14199 ufa5d
24000 u20000-jv
24001 u20000-ue0101
24002 u20000-ue0102</syntaxhighlight>
<div style='text-align: center;'>kanjisample.map</div>

<syntaxhighlight style="margin-bottom:0.2em;" lang="xml">
<font-face
font-family="Untitled1"
font-weight="400"
font-stretch="normal"
units-per-em="1000"
ascent="880"
descent="-120"
bbox="0 0 1000 1000"
underline-thickness="50"
underline-position="-100"
/>
<missing-glyph horiz-adv-x="1000" d="M50,0l900,0l0,533l-900,0 z M100,50l0,433l800,0l0,-433z"/>

<glyph glyph-name="u8279-j" d="M 321.5 247.15039 L 321.5 411.21289 L 43.25 411.21289 L 43.25 436.41211 L 321.5 436.41211 L 321.5 562.9375 L 321.5 578.6875 L 321.5 600.38867 L 383.93359 588.48633 C 415.96232 582.32437 417.82989 565.93743 384.5 555.52148 L 384.5 436.41211 L 615.5 436.41211 L 615.5 562.9375 L 615.5 578.6875 L 615.5 600.38867 L 677.93359 588.48633 C 709.96232 582.32437 711.82989 565.93743 678.5 555.52148 L 678.5 436.41211 L 843.34961 436.41211 L 893.75 486.8125 L 956.75 436.41211 L 956.75 411.21289 L 678.5 411.21289 L 678.5 272.34961 L 615.5 247.15039 L 615.5 411.21289 L 384.5 411.21289 L 384.5 272.34961 L 321.5 247.15039 z"/>
<glyph glyph-name="ufa5e" d="M 279.5 247.15039 L 279.5 411.21289 L 43.25 411.21289 L 43.25 436.41211 L 279.5 436.41211 L 279.5 562.9375 L 279.5 578.6875 L 279.5 600.38867 L 341.93359 588.48633 C 373.96232 582.32437 375.82989 565.93743 342.5 555.52148 L 342.5 436.41211 L 360.34961 436.41211 L 410.75 486.8125 L 473.75 436.41211 L 473.75 411.21289 L 342.5 411.21289 L 342.5 272.34961 L 279.5 247.15039 z M 657.5 247.15039 L 657.5 411.21289 L 526.25 411.21289 L 526.25 436.41211 L 657.5 436.41211 L 657.5 562.9375 L 657.5 578.6875 L 657.5 600.38867 L 719.93359 588.48633 C 751.96232 582.32437 753.82989 565.93743 720.5 555.52148 L 720.5 436.41211 L 843.34961 436.41211 L 893.75 486.8125 L 956.75 436.41211 L 956.75 411.21289 L 720.5 411.21289 L 720.5 272.34961 L 657.5 247.15039 z"/>
<glyph glyph-name="ufa5d" d="M 342.5 247.15039 L 342.5 415.15039 L 43.25 415.15039 L 43.25 440.34961 L 342.5 440.34961 L 342.5 564.25 L 342.5 580 L 342.5 601.70117 L 404.93359 589.79883 C 436.96232 583.63687 438.82989 567.24993 405.5 556.83398 L 405.5 272.34961 L 342.5 247.15039 z M 594.5 247.15039 L 594.5 564.25 L 594.5 580 L 594.5 601.70117 L 656.93359 589.79883 C 688.96232 583.63687 690.82989 567.24993 657.5 556.83398 L 657.5 440.34961 L 843.34961 440.34961 L 893.75 490.75 L 956.75 440.34961 L 956.75 415.15039 L 657.5 415.15039 L 657.5 272.34961 L 594.5 247.15039 z"/>
<glyph glyph-name="u20000-jv" d="M 143 -31.099609 L 143 480.25 L 201.80078 450.84961 L 473.75 450.84961 L 473.75 756.40039 L 80 756.40039 L 80 781.59961 L 806.59961 781.59961 L 857 832 L 920 781.59961 L 920 756.40039 L 536.75 756.40039 L 536.75 385.75 L 473.75 360.55078 L 473.75 425.65039 L 206 425.65039 L 206 57.099609 L 775.09961 57.099609 L 825.5 107.5 L 888.5 57.099609 L 888.5 31.900391 L 206 31.900391 L 206 -5.9003906 L 143 -31.099609 z"/>
<glyph glyph-name="u20000-ue0101" d="M 143 -36.349609 L 143 417.25 L 201.80078 387.84961 L 468.5 387.84961 L 468.5 640.90039 L 80 640.90039 L 80 666.09961 L 468.5 666.09961 L 468.5 805.75 L 468.5 821.5 L 468.5 843.20117 L 530.93359 831.29883 C 562.86375 825.15583 564.51051 808.89709 531.5 798.47656 L 531.5 666.09961 L 806.59961 666.09961 L 857 716.5 L 920 666.09961 L 920 640.90039 L 531.5 640.90039 L 531.5 322.75 L 468.5 297.55078 L 468.5 362.65039 L 206 362.65039 L 206 51.849609 L 780.34961 51.849609 L 830.75 102.25 L 893.75 51.849609 L 893.75 26.650391 L 206 26.650391 L 206 -11.150391 L 143 -36.349609 z"/>
<glyph glyph-name="u20000-ue0102" d="M 143 -43.123047 L 143 395.38281 L 201.79688 365.98438 L 473.75 365.98438 L 473.75 601.78711 L 95.75 601.78711 L 95.75 626.98828 L 817.10156 626.98828 L 867.5 677.38672 L 930.5 626.98828 L 930.5 601.78711 L 536.75 601.78711 L 536.75 300.88281 L 473.75 275.68359 L 473.75 340.7832 L 206 340.7832 L 206 45.078125 L 775.10156 45.078125 L 825.5 95.476562 L 888.5 45.078125 L 888.5 19.876953 L 206 19.876953 L 206 -17.921875 L 143 -43.123047 z M 500 706 C 469.39653 706.23029 444.875 730.37828 444.875 761.125 C 444.875 791.87172 469.39653 816.01971 500 816.25 C 530.60347 816.01971 555.125 791.87172 555.125 761.125 C 555.125 730.37828 530.60347 706.23029 500 706 z"/>
</syntaxhighlight>
<div style='text-align: center;'>kanjisample.svg</div>

先ほどと違ってsvgにおいて各グリフにunicode属性ではなくglyph-name属性を指定していることに注意。system.svgではType1への変換を経由しているのでunicodeを指定してそれをグリフ名として使う必要があったが、svgフォントを直接指定する場合はglyph-nameがかわりに使えるようである（unicodeでも探してくれるかもしれないが確かめていない）。「glyph-00001」のようにunicodeとは全く無関係の識別子でも自由に使えるので便利である。ここではglyph-nameとしてGlyphWikiでのグリフ名を使用している（例えばu8279-jは[https://glyphwiki.org/wiki/u8279-j?view=all u8279-j (艹) - GlyphWiki]の字形である）。

またmapファイルのFDArray要素の名前としては<code>NazoMin-Ideographs</code>と、先ほどの<code>System</code>とは異なり<code>Ideographs</code>という識別子を使っている。これも後で使う。

今後の説明でも必要になるので上記で例として使用している字について一通り説明しておこう。以下が<code>tx -pdf kanjisample.svg > kanjisample.pdf</code>で出力されるpdfである。

<div class="res-img">https://turgenev.cloudfree.jp/mw1/imgs/kanjisample.pdf.jpg</div>

見ての通り、最初の3文字は「くさかんむり」であるが、微妙に字形が異なる。

この3グリフは（記事執筆時点の）GlyphWikiにおいてそれぞれ以下のUnicodeコードポイントや異体字シーケンスが割り当てられている。（ここでは異体字について詳しく解説はしないが、以下の意味がすんなり理解できるようになれば異体字マスターといっても過言ではない（？）。「異体字セレクタ」「Adobe-Japan1」「CJK部首補助」などの語で適宜検索すること。）

# つながった字形…CJK部首補助<code>U+2EBE</code>（⺾）、CJK統合漢字<code>U+8279</code>（艹）、Adobe-Japan1コレクションのIVS<code>U+8279 U+E0100</code>（艹󠄀）、Moji_Joho及びHanyo-DenshiコレクションのIVS<code>U+8279 U+E0105</code>（艹󠄅）
# 「十」が2つの字形…CJK部首補助<code>U+2EBF</code>（⺿）、CJK互換漢字<code>U+FA5E</code>（艹）、それに対応するSVSである<code>U+8279 U+FE01</code>（艹︁）、Adobe-Japan1コレクションのIVS<code>U+8279 U+E0102</code>（艹󠄂）、Moji_Joho及びHanyo-DenshiコレクションのIVS<code>U+8279 U+E0104</code>（艹󠄄）
# 「T」が背中合わせの字形…CJK部首補助<code>U+2EC0</code>（⻀）、CJK互換漢字<code>U+FA5D</code>（艹）、それに対応するSVSである<code>U+8279 U+FE00</code>（艹︀）、Adobe-Japan1コレクションのIVS<code>U+8279 U+E0101</code>（艹󠄁）、Moji_Joho及びHanyo-DenshiコレクションのIVS<code>U+8279 U+E0103</code>（艹󠄃）

以上の通りこれらは全てAdobe-Japan1コレクションに含まれている字であるため、游明朝などAdobe-Japan1準拠のフォントでは、上記のうち「Moji_Joho及びHanyo-DenshiコレクションのIVS」となっているもの以外は全て正しく表示できるはずである。カッコ内をコピペして試してみるとよい。

謎乃明朝では、現時点では（2フォントに分ける前提で）グリフ数に多少余裕があるので、一応Adobe-Japan1に従ってCID+14197, CID+14198, CID+14199をそれぞれ割り当てているが、Adobe-Japan1準拠のフォントを作るのでなければこうする必要はなく、CID+1から順に漢字で埋めても構わないはず。

その次の3文字は、U+20000（𠀀）の異体字である。Unicodeの20000-2FFFFは「追加漢字面」（SIP）と呼ばれ、日本で普段使われることはない漢字が大半である（「𩸽（ほっけ）」など例外もある）。この範囲の文字を例に含めたのは、BMP外のUnicode文字はサポートが不十分なソフトも多い中で、AFDKOを使えばきちんと対応できる、ということを示すためである。

こちらの割り当ては先ほどよりはずいぶん単純である。GlyphWikiでは、最初のu20000-jvが<code>U+20000</code>と<code>U+20000 U+E0100</code>、次のu20000-ue0101が<code>U+20000 U+E0101</code>、その次のu20000-ue0102が<code>U+20000 U+E0102</code>で使われている（後の2つは名前からして当然であるが）。これらは全てMoji_JohoコレクションのIVS異体字であり、U+20000自体もAdobe-Japan1には含まれていないので、正しく表示するには謎乃明朝、花園明朝あるいはIPAmj明朝などが必要だろう。ここでは一応、Adobe-Japan1のCID（現在23059まで定義されている）と被らないよう、24000以降を割り当てている（もちろんそうする必要はない。）

なお、ここではSVS・IVSに対応したフォントを作成するが、Variation Selectorは特殊文字なので、それ自体にグリフを割り当てる必要はない。

==== 出力 ====

ここまで理解したら、以下のようにコマンドを実際に実行してみよう。

<syntaxhighlight lang="vb.net">$ mergefonts -cid cidfontinfo merged.pfa system.map system.pfa kanjisample.map kanjisample.svg
mergefonts: --- system.pfa
mergefonts: (cfw) unhinted <cid-0>
Adding font dict 0 from system.pfa.
mergefonts: --- kanjisample.svg
mergefonts: (cfw) unhinted <cid-14197>
mergefonts: (cfw) unhinted <cid-14198>
mergefonts: (cfw) unhinted <cid-14199>
mergefonts: (cfw) unhinted <cid-24000>
Adding font dict 1 from kanjisample.svg.
mergefonts: (cfw) There are 2 additional reports of 'unhinted'.

mergefonts: --- merged.pfa
mergefonts: (cfr) /BlueValues missing: FD[1]</syntaxhighlight>
<code>unhinted</code>や<code>/BlueValues missing: FD[1]</code>などとwarning/errorが出ているが、あとでヒントを追加するので無視でよい（多分）（SVGに直接BlueValuesを追加する方法があってもおかしくはないと思うが見つけられなかった）。

生成されたmerged.pfaを再びtxでpdfにしてみると以下のようになる。

<div class="res-img">https://turgenev.cloudfree.jp/mw1/imgs/merged.pdf.jpg</div>

このように、各CIDに意図した字形が割り当てられていることがわかるだろう。しかし、それらのCIDがどの文字に対応するものなのかという情報は全く含まれていないので、これはまだ実際に使用できるフォントではない。

== ヒントの付加 ==

次に、このフォントにヒントを付加する。ヒントというのは、フォントをラスタライズ（実際にピクセルに変換して描画）する際に、線の太さなどを調節して見やすくするための機能であり、特に小さいサイズで表示したときの見た目に大きく影響する。日本語情報はあまりないが、Fontforge関連でいくつか見つけることができる。またBlueValuesやStdHWなど個々の値の仕様に関しては[https://kikakurui.com/x4/X4163-1994-01.html https://kikakurui.com/x4/X4163-1994-01.html]で日本語で読める。個人的にもあまりヒントの動作についてはよくわかっていないので、ここでは最低限のやり方だけ述べる。

ちなみにこの記事では扱わないがAFDKOにはrotatefontというグリフを（ヒント情報含めて）自動で回転させてくれるコマンドがあり、これを使った場合にもその後で改めてpsautohintを実行するのが望ましいようである（参考 :[https://aznote.jakou.com/afdko/anti02.html アンチックフォントを作る: グリフの変形と合成]）。


==== hitcidfont.plを使う ====

{{Valuable}}

ヒントの付加はpsautohintというプログラムで行うが、psautohintが動作するためには、BlueValuesという値だけは最低限手動で設定しなければいけないようである。そこで、[https://github.com/adobe-type-tools/perl-scripts/blob/master/hintcidfont.pl perl-scripts/hintcidfont.pl at master · adobe-type-tools/perl-scripts]を用いて、先ほど生成したmerged.pfaにBlueValues（やその他、必須ではないパラメータ）を付加する。

このスクリプトは（今回であれば）以下のように使用する。

<syntaxhighlight lang="vb.net">hintcidfont.pl hintparam.txt < merged.pfa > merged_out.pfa</syntaxhighlight>
前述の通りpfaフォント（ファイルの先頭がああいう感じのやつ）以外には使えないようである。この<code>hintparam.txt</code>がBlueValuesなどを指定するファイルで、ここで先ほどFDArray要素の名前で使用した<code>System</code>や<code>Ideographs</code>を使用する。

<syntaxhighlight style="margin-bottom:0.2em;" lang="vb.net">System
/BlueValues [-250 -250 1100 1100] def
/StdHW [100] def
/StdVW [100] def

Ideographs
/BlueValues [-100 -200 1100 1100] def
/StdHW [70] def
/StdVW [100] def
/StemSnapH [70 80 60 90 50 40] def
/StemSnapV [80 70 90 60 100 50 110] def</syntaxhighlight>
<div style='text-align: center;'>hintparams.txt</div>

このように、FDArray要素ごとに自動ヒント付けのための情報を付加できる。

前述のようにBlueValuesは最低限必要で、これは確かフォントがラスタ化されるときの最大のバウンディングボックスを指定するものなので、該当のFDArrayに含まれるグリフのバウンディングボックスより大きければ大丈夫だと思う。今回のように1000x1000で漢字のみ入れるような場合は適当に<code>[-250 -250 1100 1100]</code>などとしておけばよいはず。

StdHWとStdVWは水平方向のステムの（垂直方向の）幅と垂直方向のステムの（水平方向の）幅の目安（？）をそれぞれ指定するものである。明朝なら横線のほうが細いということで、ここでは何となくStdHWを70、StdVWを100としているが、効果がどうなのかはよくわかっていない。StemSnapHとStemSnapVは、StdHWとStdVWと似ているが、より細かい精度でガイドラインを設定するような感じのやつである。あまり情報がなくてよくわからないので、かなり適当に設定していて、本当は小さい順に並べる必要があったりするのかもしれない。

まあ言ってしまえば、見た目を追求するなら本来は手動でヒント付けを行うべきである（多分）。他の設定例は[https://ccjktype.fonts.adobe.com/wp-content/uploads/2012/06/afdko-lunde-20120625.pdf https://ccjktype.fonts.adobe.com/wp-content/uploads/2012/06/afdko-lunde-20120625.pdf] なども参照。

上手くいけば、以下のような出力とともにこれらの値が付加されたpfaファイルが生成される。テキストエディタで開いてみると、pfaファイルの上の方に<code>/BlueValues [-250 -250 1100 1100] def</code>などと書きこまれているのがわかる。

<syntaxhighlight lang="vb.net">$ hintcidfont.pl hintparam.txt < merged.pfa > merged_out.pfa
Detected CIDFontName: NazoMin
Modifying System hinting parameters...
Modifying Ideographs hinting parameters...</syntaxhighlight>
ここまでの記事に従っていれば大丈夫かと思うが、何も出なかったらおそらくどこかが間違っているのでpfaファイルの中身やスクリプトのソースを読んでみるなどして確認すること。

==== psautohintの実行 ====

では次にpsautohintを実行する。オプションなどは筆者がよくわかっていないので、今回は以下を実行するだけである。

<syntaxhighlight lang="vb.net">psautohint merged_out.pfa -o hinted.pfa</syntaxhighlight>
今回はグリフ数が少ないのですぐに終わるが、数万グリフあるとなると数分ほどかかる処理である。

手元ではたまに<code>ERROR: cid51649: Possible loop in element that goes from 109 46 to 109 47. Please check.</code>（あるいは稀に<code>ERROR: cid45515: Check for duplicate subpath at 128 758</code>）などと出る字もあるのだが特に見た目は問題無さそうなので無視している。

== makeotfの準備 ==

ここまででグリフのデータは完成したので、実際に使えるフォントにするためのmakeotfの実行に向けて準備を行う。

基本的には、それぞれの文字（Unicode符号位置）でどのCIDを使用するかというCMapが最も重要で、これさえあれば一通り使えるフォントにはなるが、ここでは（先ほど説明した）異体字セレクタも使えるようにSequenceファイルも使用する。OpenType featureに関しては（自分があまりよくわかっていないので）フォントの高さなど最低限の設定のみ行う。他にもGSUB・GPOSをはじめ様々な面白いfeatureがあるので調べてみてほしい。また、フォント名の設定のためFontMenuNameDBというファイルも使用する。

これらについては[https://shiromoji.hatenablog.jp/entry/20111210/1323520587 AFDKO入門《CIDキー方式のOpenTypeフォントの作り方》後篇：makeotf - しろもじメモランダム]も参考になる。また[https://github.com/adobe-fonts/source-han-sans https://github.com/adobe-fonts/source-han-sans]や[https://github.com/adobe-type-tools/Adobe-Japan1 https://github.com/adobe-type-tools/Adobe-Japan1]にも例がある。


==== FontMenuNameDB ====

<syntaxhighlight style="margin-bottom:0.2em;" lang="vb.net">[NazoMin]
f=NazonoMincho
s=Regular
l=NazonoMincho Regular

f=3,1,0x411,\8B0E\4E43\660E\671D
s=3,1,0x411,Regular
l=3,1,0x411,\8B0E\4E43\660E\671D Regular

f=1,1,11,\93\E4\94\54\96\BE\92\A9
s=1,1,11,Regular
l=1,1,11,\93\E4\94\54\96\BE\92\A9 Regular</syntaxhighlight>
<div style='text-align: center;'>FontMenuNameDB</div>

このように、先ほど使用したPostScript名である<code>NazoMin</code>を先頭に書き、フォント名を設定する。

<code>\8B0E\4E43\660E\671D</code>と<code>\93\E4\94\54\96\BE\92\A9</code>はそれぞれWinとMacのエンコーディングで「謎乃明朝」を表す。少なくともWindowsに関しては、UTF-16のサロゲートペアを用いればBMP外文字でも指定できるようである（例えば先ほどのU+20000なら<code>\D840\DC00</code>）が、やめておいた方が無難だろう。


==== CMap ====

CMapは、各UnicodeのためにどのCIDを使用するかを指定するもので、フォントの根幹部分を決める重要なファイルである。日本語の「、。」のような縦と横で字形（位置）が異なる文字のために縦書き用CMapが必要なこともあるが、今回は漢字だけなので、とりあえず横書きだけ指定しておけばあとはmakeotfがやってくれる。

<syntaxhighlight style="margin-bottom:0.2em;" lang="vb.net">%!PS-Adobe-3.0 Resource-CMap
%%DocumentNeededResources: ProcSet (CIDInit)
%%IncludeResource: ProcSet (CIDInit)
%%BeginResource: CMap (NazoMinCMAP-UTF32-H)
%%Title: (NazoMinCMAP-UTF32-H Adobe Identity 0)
%%Version: 2.004
%%Copyright: -----------------------------------------------------------
%%Copyright: (省略)
%%Copyright: -----------------------------------------------------------
%%EndComments

/CIDInit /ProcSet findresource begin

12 dict begin

begincmap

/CIDSystemInfo 3 dict dup begin
/Registry (Adobe) def
/Ordering (Identity) def
/Supplement 0 def
end def

/CMapName /NazoMinCMAP-UTF32-H def
/CMapVersion 2.004 def
/CMapType 1 def

/WMode 0 def

1 begincodespacerange
<00000000> <0010FFFF>
endcodespacerange

1 beginnotdefrange
<00000000> <0000001f> 1
endnotdefrange

6 begincidchar
<00000020> 1
<00003000> 633
<00008279> 14197
<0000fa5d> 14199
<0000fa5e> 14198
<00020000> 24000
endcidchar

1 begincidrange
<00002ebe> <00002ec0> 14197
endcidrange

endcmap
CMapName currentdict /CMap defineresource pop
end
end

%%EndResource
%%EOF</syntaxhighlight>
<div style='text-align: center;'>NazoMinCMAP-UTF32-H</div>

このような感じで、unicode位置（このファイルはUTF32版である）からCIDへの対応関係を記述する。

なお、begincidrangeはbegincidcharがCID・Unicode位置ともに連続しているときに楽に指定するためのものである。また、begincidcharやbegincidrangeによる1つのブロックまでには最大100個（上記では1や6になっている）までしか情報を入れられない。従って、機械的にCMapを生成するときは、以下のように全て<code>1 begincidchar ... endcidchar</code>で指定してしまうのが楽である。

<syntaxhighlight lang="vb.net">...
1 begincidchar
<00008279> 14197
endcidchar
1 begincidchar
<00002ebe> 14197
endcidchar
...</syntaxhighlight>
その上で、サイズを削減したいときは、[https://github.com/adobe-type-tools/perl-scripts/blob/master/cmap-tool.pl perl-scripts/cmap-tool.pl at master · adobe-type-tools/perl-scripts]を使うと良い感じにbegincidrangeにした上で100個ずつにまとめてくれる。


==== Sequenceファイル ====

今回は以下のものを使用する。先ほど解説した通りに「CJK統合漢字+異体字セレクタ」の組が該当CIDを参照していることを確認せよ。

ちなみに、異体字セレクタが付けられている元の字（以下ならU+8279とU+20000）自体がフォントに含まれていないとたしか異体字も使えないはずなのでそこは注意。

<syntaxhighlight style="margin-bottom:0.2em;" lang="vb.net">8279 E0100; AJ1; CID+14197
8279 E0105; AJ1; CID+14197
8279 E0104; AJ1; CID+14198
8279 FE01; AJ1; CID+14198
8279 E0102; AJ1; CID+14198
8279 E0101; AJ1; CID+14199
8279 E0103; AJ1; CID+14199
8279 FE00; AJ1; CID+14199
20000 E0100; AJ1; CID+24000
20000 E0101; AJ1; CID+24001
20000 E0102; AJ1; CID+24002</syntaxhighlight>
<div style='text-align: center;'>sequences.txt</div>

このファイル形式はAFDKOやOpenTypeフォント自体に由来するものであるというよりは多分Unicodeの[https://www.unicode.org/ivd/data/ IVD]に含まれるSequenceファイルに由来するものであるように思われる。SourceHanSansやAdobe-Japan1のリポジトリにある例ではそれに従って中央の列に<code>Adobe-Japan1</code>や<code>Standardized_Variants</code>などと律儀に書いてあるが、AFDKOが読むのは実際には第1のシーケンスと第3列のCID番号だけと思われるので、このように適当に<code>AJ1</code>などと書いてファイル容量をケチっておいても問題はなさそうだった。

==== featureファイル ====

このファイルによって完成品のフォント名などが決められる。

ほぼ[https://shiromoji.hatenablog.jp/entry/20111210/1323520587 AFDKO入門《CIDキー方式のOpenTypeフォントの作り方》後篇：makeotf - しろもじメモランダム]を参考に、最低限の内容だけ入れている。

<syntaxhighlight style="margin-bottom:0.2em;" lang="vb.net">table head {
FontRevision 0.004;
} head;

table hhea {
CaretOffset 0;
Ascender 880;
Descender -120;
LineGap 1000;
} hhea;

table OS/2 {
FSType 0;
Panose 2 # Latin, Text
11 # Normal Sans
4 # Thin
9 # Monospaced
0 0 0 0 0 0; # Any
UnicodeRange
0 1 2 5 6 7 9
31
32 33 34 35 36 37 38 39
42 43 44 45 46 47
48
49 # Hiragana
50 # Katakana
54 55 57
59 # CJK Unified Ideographs
61 # CJK Strokes, CJK Compatibility Ideographs (Supplement)
65 68
91 # Variation Selectors
;
CodePageRange
1252 # Latin 1
1250 # Latin 2
932 # JIS/Japan
936 # Chinese: Simplified chars—PRC and Singapore
949 # Korean Wansung
950 # Chinese: Traditional chars—Taiwan and Hong Kong
1361 # Korean Johab
;
TypoAscender 880;
TypoDescender -120;
TypoLineGap 1000;
winAscent 1000;
winDescent 100;
XHeight 0;
CapHeight 0;
WeightClass 400;
WidthClass 5; # Full width
Vendor "YHVH";
} OS/2;

table vhea {
VertTypoAscender 500;
VertTypoDescender -500;
VertTypoLineGap 1000;
} vhea;

feature vrt2 {
sub \1 by \8720;
} vrt2;

feature vert {
sub \1 by \8720;
} vert;</syntaxhighlight>
<div style='text-align: center;'>features</div>

詳しくは他サイトに譲る。Ascender/Descenderによりフォントの高さ・深さを指定している（880-(-120)でちょうど1000になっていることを確認せよ）。winAscentとwinDescentはWindows限定のようだが、少なくともこれを変えると手元ではWordでのフォント高さが変わるので重要そうである（この設定例はかなり小さめである）。FontRevisionは好きに設定してよい。わからないときは、ttx（txではない）で既存フォントのテーブルを見てみるのもよいだろう。

UnicodeRangeやCodePageRangeは、フォントがどのような言語・文字集合に対応しているかの参考にされるのだと思うが、少なくともフォント名を自分で指定してこのフォントを使う分にはあまり影響しない部分かと思われる。<s>実際には一文字も収録していないUnicode範囲をこんな大量に指定するのはやめた方がよさそうである。</s>

vrt2の部分は前述の[http://web.archive.org/web/20130225051414/http://d.hatena.ne.jp/mashabow/20120306/1331028598 花園明朝OTを0.510に更新、IVD 2012-03-02版に対応 - しろもじメモランダム]を参考にしたものである。vertは勝手に同じ内容でつけてみた。

== makeotfの実行 ==

ここまでできたら

<syntaxhighlight lang="vb.net">makeotf -f hinted.pfa -ff features -o final.otf -ch NazoMinCMAP-UTF32-H -ci sequences.txt -mf FontMenuNameDB</syntaxhighlight>
としてフォントをビルドしてみよう。なお、<code>FontMenuNameDB</code>と<code>features</code>はそれぞれAFDKOが探すデフォルトの名前なので、別の名前を使わない限りは指定しなくてもよい。<code>Built development mode font "…./final.otf"</code>などと出ればめでたく成功である。ちなみに-rオプションを付けるとreleaseモードになり、”Built release mode font”と出る。多少時間がかかるもののサイズが減るなどする。

あとはインストールしてちゃんと文字が出るか確かめればよい。Wordで確かめているとインストール直後はフォントの色々な情報（特に高さなど）がうまく読み込まれない場合があるので、何かおかしいと思ったらOffice系のソフトを一旦全て終了するなどしてからまた起動するのがよい。


== TrueTypeへの変換 ==

AFDKOが生成するのはPostScriptアウトラインのOpenTypeフォントであるから、曲線データには3次ベジェ曲線が用いられる。TrueTypeでは2次ベジェ曲線しか使えないので、3次ベジェ曲線→2次ベジェ曲線の変換が必要である。これは自明な変換ではなく近似が必要であるが、AFDKOにはこれをやってくれるotf2ttfというコマンドがある。シンプルに<code>otf2ttf final.otf</code>とすれば<code>final.ttf</code>というTrueTypeフォントが出力される。

== その他参考 ==

その他、フォントに関連する記事としては、[[Webブラウザ（Chrome）|Webブラウザ（Chrome）]]と[[Wordの「検索と置換」について|Wordの「検索と置換」について]]も参考になるだろう。


== CSSで謎乃明朝 ==

IVSなどがあるので（body:{}などに書く）font-family:のところではNazoMinを先に指定すること。

<syntaxhighlight lang="css">@font-face {
font-family: "NazoMin";
src: local("謎乃明朝 Regular");
unicode-range: U+3400-U+4DFF, U+2F800-2FFFF, U+30000-3FFFF;
}

@font-face {
font-family: "NazoMin+";
src: local("謎乃明朝+ Regular");
unicode-range: U+20000-2F7FF;
}</syntaxhighlight>
[[Category:IT]]{{#seo:|title={{FULLPAGENAME}} - Turgenev's Wiki}}

Windowsでのターミナル環境

2025-10-02T06:09:03Z

Turgenev: Notion-MW

WindowsはLinuxに比べるとライトユーザー向けのOSで、端末エミュレータで文字を打ってコマンドを実行するというCUIのスタイルで使いやすいようにデザインされているとは言い難い。それでも、ある程度工夫すれば不満点を改善することはできる。


== C:\Users\USERNAME\.pathにPATHを通す ==

ユーザーフォルダ（C:\Users\USERNAME）の直下などわかりやすいところに.path（もちろん名前は好きに決めてよい）というフォルダを作り、これをユーザー環境変数のPATH（の先頭がいいかな？）に追加しておく（他ユーザーから見えないフォルダなのでシステム環境変数に追加するのは不適切）。するとPATHをいちいち書き換えなくてもこの中に入れた実行ファイルやバッチファイルはファイル名だけで呼び出せる状態になる。

これは、インストール不要（圧縮ファイル解凍のみ）、あるいはPATHを自動で通さないようなソフトウェアを使いやすくするのに有用である。実行ファイル単体で動作するならファイルを直接入れてもいいし、依存ファイルがあるなら本体の位置はそのままでそれを呼び出すプログラムを入れればいい（バッチファイルでもいいが、欠点がある。詳しくは後述）。

筆者はrclone（ファイル同期ソフト）やmpv（メディアプレイヤー）などをこの.path経由で起動できるようにしている。またLinuxでも同様の設定をしている。

== 他のコマンドを呼び出すプログラム ==

前項の目的を達するため、「自身に渡されたコマンドライン引数を（場合により多少の処理をした上で）ほぼそのまま使って他のコマンドを実行する」ようなプログラムを作成した。

[https://github.com/ge9/win-console-delegator https://github.com/ge9/win-console-delegator]

このプログラムは、「自分自身のファイル名の最後の文字と最後から3番目の文字を<code>t</code>に変更したファイル（主にexe→txtを想定しているが、com→totなどでもよい）を読み込み、その内容と自分に与えられたコマンドライン引数をつなげた文字列をコマンドとして実行する」という挙動をする。すなわち、実行ファイルは（コンパイルし直さず）そのままコピーした上で、ペアとなる.txtファイルに適切な内容を書くことで、以下のようなプログラムが実現できる。

==== 他のプログラムをそのまま実行 ====

たとえばテキストファイルに以下のように書いておけば、mpvが起動される。末尾の半角スペースも入れること。

<syntaxhighlight lang="vb.net">"C:\Users\username\Softwares\mpv\mpv.exe"</syntaxhighlight>
Windows版のmpvは、設定ファイル（mpv.conf）やプラグインなどを自身が存在するディレクトリから読み込むが、それらの動作を維持したままで、.pathにはmpv.exeという呼び出し専用のファイルだけを配置することができる。

==== 指定フォルダにあるプログラムを実行 ====

<code>myprogram somecommand arg1 arg2 ...</code>と呼び出されたときに、<code>C:\path\to\somecommand arg1 arg2 ...</code>をかわりに実行したい、ということがある。例えば複数の実行ファイルがまとまって提供されるような場合である。このときは以下のようなmycommand.txtをペアにすればよい。この場合はパスを直接引数につなげるため、末尾に半角スペースを入れてはいけない。

<syntaxhighlight lang="python">C:\path\to\</syntaxhighlight>
ところで、<code>C:\path\to\</code>の部分に空白文字が含まれている場合、このままではパスが正しく認識されない。通常はパス全体をダブルクォーテーションで囲うことでこれを回避するが、今回は与えられた引数のどこにダブルクォーテーションを挿入するかが自明ではない（<code>myprogram someprogram"</code>と入力させるという方法もあるが美しくない）ため、半角スペースを含まない別名（8.3形式）を使うのがよいだろう（短い名前については[[Windowsのパス長さ制限に関して|Windowsのパス長さ制限に関して]]も参照）。例えばProgram Filesなら普通は「PROGRA~1」になっているはずである。以下はGit Bashでのtxtファイルの例である。

<syntaxhighlight lang="vb.net">C:\PROGRA~1\Git\usr\bin\</syntaxhighlight>
これにより、PATHを変更せずとも、例えば<code>gb grep</code>などとするだけでGit Bashの<code>grep</code>を呼び出すことができるようになる。gitやnpmやbusyboxやmagick（ImageMagick）のようにサブコマンドを指定して使うプログラムは多くあるが、これと同じような使用感になる。プレフィックスを設けることでそれぞれの名前の集合を別々に管理して衝突を防ぐ、という意味では、多くのプログラム言語で採用されている名前空間（namespace）に近い発想かもしれない。（コマンドにおけるこのような手法に特に名前は付いていないと思う。）

==== pathなどの環境変数を変更して実行 ====

上記と若干似ているが、PATHをはじめとした環境変数を変えることでプログラムがうまく実行されるようにしたい、という場合もある。この場合は、テキストファイルを以下のようにすればよい（Git Bashのフォルダをパスに追加し、<code>MYVAR</code>に<code>value1</code>をセットする例）。末尾の半角スペースはあってもなくてもいい。

<syntaxhighlight lang="bash">cmd /c path C:\Program Files\Git\usr\bin;%PATH% & set MYVAR=value1 &</syntaxhighlight>
こちらは、先ほどと違って、内部でGit Bashのコマンドを使用する（Git Bashとは無関係な）プログラムを実行する際などに有用である。

また、これに類似のケースとして、環境変数の設定などを行うバッチファイルが既に用意されていてそれを使いたいという場合もある。例えば以下のようなテキストファイルを用いれば、実質的にVisual Studioの開発者コマンドプロンプト（Developer Command Prompt for VS 2022）の内部で与えられたコマンドを実行してくれるプログラムが作れる。

<syntaxhighlight lang="python">cmd /c C:\PROGRA~1\MIB055~1\2022\Community\Common7\Tools\VsDevCmd.bat &</syntaxhighlight>
* ここでも短いパスを使用している。長いパスでも引用符で囲めばある程度うまく動作するが、<code>&</code>の後にくるコマンドに引用符が含まれている場合にうまくいかない。

Linuxでも、例えば特定のvenv仮想環境の中で与えられたコマンドを実行するシェルスクリプトを全く同じ発想で作ることができる。

=== 実装について ===

* 言語はC++を使った。これはWindows APIのGetCommandLineから生のコマンドライン文字列が得られるからである。予め分割されたコマンドラインでは情報量が減ってしまう。WinMainが使えればlpCmdLineで楽にできたが、今回はコンソールアプリケーションで実装したかったので、[https://stackoverflow.com/questions/14150374/how-to-get-the-raw-command-line-arguments c++ - How to get the raw command line arguments - Stack Overflow]のようにして自身のファイルパスだけ取り除いた。
* コンソールイベント（Ctrl+Cなど）の転送に関しては、CreateProcessにCREATE_NEW_PROCESS_GROUPを指定した上で、SetConsoleCtrlHandlerによって全てのコンソールイベントを転送する方式とした。CREATE_NEW_PROCESS_GROUPを指定しない場合よりもこのほうが安定して動いている気がする。
* cmdの対話シェルには、実行するアプリケーションがコンソールアプリケーションではなくGUIアプリケーションである場合は実行終了を待たずに即座に制御を返すという仕様がある。これを模倣するため、自作プログラムにはGUIアプリケーションにしたバージョンも同梱している。

=== batとの比較 ===

上記の例は、いずれもバッチファイルを使って似たようなことが実現できる。例えばGit Bashならそれぞれ

<syntaxhighlight lang="prolog">@C:\path\to\directory\%*</syntaxhighlight>
や

<syntaxhighlight lang="vb.net">@cmd /c "path C:\path\to\directory;%PATH% & %*"</syntaxhighlight>
のようにする（<code>@</code>は、echo offを一時的に行うために必要である）。

しかし、cmd.exeには、バッチファイルの実行中にCtrl+Cを送信すると「バッチジョブを終了しますか (Y/N)?」というプロンプトを表示するという厄介な仕様がある。また、<code>%</code>で挟まれた環境変数（<code>%PATH%</code>など）が文字列として含まれていた場合に展開されてしまう。そのため、先ほどの自作プログラムを使用するほうがスマートである。


== Cygwin, MSYS/MinGW, Git Bashの違い ==

これらはいずれもWindows上でUnixライクなコマンドライン環境を整備してくれるツールだが、違いもある。

個人的な印象としては

* Cygwinは起動に若干タイムラグがあるが、最も信頼できる動作をするので、例えばシェルスクリプトを実行させるときなどはまずCygwinで試した方がいい。
* MSYS系は、C++でWindows向けに何かをコンパイルしたい時に使う。
* Git Bashは、最も手軽だが、Cygwinに比べると意外とWindowsとの互換性というか、動作が怪しいことがある。
** Git Bashからだと、cmdを起動したときに入力カーソルの位置がおかしい、Windowsのアプリケーションに<code>/</code>を引数として渡したいときは<code>//</code>と書かなければいけない、xargsの並列実行の挙動がおかしい（[https://github.com/ge9/ExecuteCommand-Pipe/issues/3 With "h" option, ][https://github.com/ge9/ExecuteCommand-Pipe/issues/3 <code>xargs -n1</code>][https://github.com/ge9/ExecuteCommand-Pipe/issues/3 creates only one process · Issue #3 · ge9/ExecuteCommand-Pipe]）という例があった。

==== 参考サイト ====

<ul>
<li>[https://www.glamenv-septzen.net/view/1422 https://www.glamenv-septzen.net/view/1422]これを見た限り（2017年のやつだけど）、MSYS2って意外と大したことなくない？という。</li>
<li>呼び方の違いがわかりやすい表[https://gist.github.com/rz7d/4e699498d339a5837f016b3108631a2b https://gist.github.com/rz7d/4e699498d339a5837f016b3108631a2b]</li>
<li>[https://opcdiary.net/%E6%B7%B7%E3%81%9C%E3%82%8B%E3%81%AA%E5%8D%B1%E9%99%BA-msys2%E3%81%A8cygwin%E3%81%A8git-for-windows%E3%82%92%E4%B8%80%E7%B7%92%E3%81%AB%E4%BD%BF%E3%81%A3%E3%81%A6%E3%81%AF%E3%81%84%E3%81%91%E3%81%BE/ 混ぜるな危険 (msys2とCygwinとGit For Windowsを一緒に使ってはいけません) | OPCDiary]
<ul>
<li>これがあるので、当サイトのように呼び出し用のコマンドを整備するのが割とおすすめ。</li></ul>
</li>
<li>[https://sites.google.com/site/toriaezuzakki/msys2?tmpl=%2Fsystem%2Fapp%2Ftemplates%2Fprint%2F https://sites.google.com/site/toriaezuzakki/msys2?tmpl=%2Fsystem%2Fapp%2Ftemplates%2Fprint%2F]
<ul>
<li>MSYS2をインストールしたときに出る複数のシェルはパスの設定が違う（だけ？）らしい:
「これらの違いはパスの設定です。MSYS2 Shellを基本として、MinGW-w64 Win32 Shellはそれに/mingw32/binが追加されており、MinGW-w64 Win64 Shellは/mingw64/binが追加されています。」</li>
<li>詳しくは、「msys2_shell.cmd」を読んでみると良さそうである。MSYSTEM環境変数というのが重要そう。</li></ul>
</li>
<li>[https://m-hiyama.hatenablog.com/entry/20151013/1444704189 Mingw-w64/MSYS2 を入れなくても Git for Windows で間に合うみたい - 檜山正幸のキマイラ飼育記 (はてなBlog)] Git BashはMinGW/MSYSベースなので、そちらと同様に、MSYSTEM環境変数を<code>MINGW64</code>に設定すると/mingw64/binがパスに入る。ここにはgit.exeが入っているが、git.exe自体は実は/cmdに入っているので、そのことによる実効的な違いはあまりない。ということらしい。
<ul>
<li>ただgit以外にもxzコマンドとか/mingw64/binにしかないものもいくつかあるので、違いが全くないわけでもない。（なぜxzがこっちに入っているんだろう？）</li>
<li>MSYSTEMに何も設定せずusr/binにあるbashに<code>--login</code>を付けて実行したところ、MSYSTEMはMSYSに設定され、パスには/mingw64/binがないかわりに/opt/binが追加されている。しかし実際には/optフォルダはGit Bashのインストール時には存在しておらず、無意味である。</li></ul>
</li></ul>

== アプリ実行エイリアスの扱い ==

wt.exeやmspaint.exeなどストアアプリ系の実行ファイルは「アプリ実行エイリアス」というやや特殊な仕組みで管理されており（例えばエクスプローラーで見るとこれらのファイルサイズは0バイトである）、Cygwin系と相性が悪い。Git BashではPermission Deniedでこれらのファイルの実行ができないという問題があった。最新リリースでは修正されている。

[https://github.com/git-for-windows/git/issues/2675 Permission Error on all App Execution Aliases in git-bash · Issue #2675 · git-for-windows/git]

Cygwinでは、実行は問題ないがwhich wtとすると見つからないと言われる（Git Bashでは大丈夫そう）（2023/08時点）。


== Cygwinのforkに関するエラーを直す ==

setupを再実行してバイナリがアップデートされた後に、以下のようなエラーが頻発するようになることがある。毎回出るわけではなく、確率的に生じるので厄介である。

<syntaxhighlight lang="shell">child -1 – forked process 9272 died unexpectedly, retry 0, exit code 0xC0000142, errno 11</syntaxhighlight>
<syntaxhighlight lang="shell">40 [main] bash 3348 fork: child -1 - forked process 4248 died unexpectedly, retry 0, exit code -1073741819, errno 11</syntaxhighlight>
解決方法はいくつかある（単に再起動などで治る場合もある？）らしいが、自分の場合は以下のようにrebaseallというのをやることで治った。

[https://stackoverflow.com/questions/9300722/cygwin-error-bash-fork-retry-resource-temporarily-unavailable/14509551#14509551 Cygwin error: "-bash: fork: retry: Resource temporarily unavailable" - Stack Overflow]（元記事は[https://cygwin.fandom.com/wiki/Rebaseall https://cygwin.fandom.com/wiki/Rebaseall]らしい）

ここには<code>rebaseall -v</code>と書いてあるが、手元ではそのようなオプションがなさそうだったので単純にrebaseallとしたら、それでうまく行ったようである。

<ul>
<li>まとめると、手順は以下。
<ul>
<li>Cygwin関連のプロセスをすべて終了させる。</li>
<li>/usr/binにあるdash.exeを管理者権限で起動させる（おそらく軽量で依存関係が少ないから？）</li>
<li><code>./rebaseall</code>を実行</li></ul>
</li>
<li>他には以下のようにWindowsのセキュリティ設定をいじる方法もあるようだが、ちょっと不安。
[https://oni-gili.org/archives/290 https://oni-gili.org/archives/290]
[https://umateku.com/archives/462 https://umateku.com/archives/462]</li></ul>


== Cygwinでcmdに<code>"</code>を出力させる ==

[https://cygwin.com/pipermail/cygwin/2020-June/245226.html change in handling quotes in cygwin package from 3.1.4-1 to 3.1.5-1]にある通り、Cygwinでcmd（を含むWindowsネイティブのプログラム？）にダブルクォーテーション単体（あるいはダブルクォーテーションを途中に含む任意の文字列など）を渡すのは難しい（難しくなった？）。環境変数に<code>"</code>を入れておいて渡すという手はあるが、衝突する可能性も考えられる。一番確実なのは、与えられた引数に含まれる指定された文字列を全て<code>"</code>に置き換えて実行するようなプログラムを別途書くことだろう（気が向いたらやるかも）。

* [https://twitter.com/e9g/status/1660590434429865984 https://twitter.com/e9g/status/1660590434429865984]も参照。


== Git Bash/Cygwinなどでbatやvbsを拡張子無しで呼ぶ ==

Windows上では、実行ファイルの拡張子（の主流）である.exe以外にもバッチファイル（.bat）やVBScript（.vbs）などが環境変数<code>PATHEXT</code>に登録され、拡張子無しで呼び出すことができる。しかし、Git Bash/Cygwinでは、exeのみが省略でき、他は明示的に付けないと呼び出せない。これは[https://qiita.com/snipsnipsnip/items/03b3bb9149954cb44bea Git Bashで.batや.lnkを使うとき拡張子を省く - Qiita]のようにbash側で設定すると解決できる（が、あまり綺麗な方法とはいえない気がする）（なおCygwinでは未確認）。また、よく使う操作をコマンド一発で呼び出したい時は、batではなくシェルスクリプトや前述のようにexeファイルを使う手もある。


== conhost.exeで文字選択中に出力がブロックされる ==

Windows コンソールホスト（conhost.exe）というのは、Windowsで従来ずっと使われてきたターミナルのことであり、この上でコマンドプロンプト（cmd.exe）やPowerShellやその他のコンソールアプリケーションが動く。conhost.exeに代わるものとして最近出てきたのがWindows Terminal（wt.exe）である。

この2つは以下の画像の通り、概ね見た目で区別できる。（Windows11以降でWindows Terminalをデフォルトにする機能が追加されるようであるが、そうしていない場合は、）cmdやPowerShell、あるいはpythonやnode.jsなどの対話コンソールを普通に開いた際にはこの上側のような感じのウインドウが表示されるはずである。

<div class="res-img">https://turgenev.cloudfree.jp/mw1/imgs/conhost.jpg</div>

<div style='text-align: center;'>conhost.exeの見た目</div>

<div class="res-img">https://turgenev.cloudfree.jp/mw1/imgs/wt.jpg</div>

<div style='text-align: center;'>Windows Terminalの見た目</div>

しかし、あまり知られていないようだが、このconhost.exeには「文字を選択した状態（ウインドウタイトルに「選択」と出る）だと一切の出力がブロックされる」という仕様があるようである（文字選択を容易にするため？参考: [https://github.com/microsoft/terminal/issues/34 https://github.com/microsoft/terminal/issues/34]）。例えば<code>ping -t localhost</code>を実行して文字を選択してみるといいだろう。方向キーや文字を入力するなどして選択状態を解除すると出力は再開する。

この仕様により、[https://stackoverflow.com/questions/8140804/how-can-i-stop-my-server-from-freezing-when-powershell-is-in-select-mode ruby on rails - how can I stop my server from freezing when powershell is in 'select' mode? - Stack Overflow] などにあるように、サーバーアプリケーションの実行が出力の際に意図せずブロックされるといった問題が起こる（筆者は[[error_private_page|error_private_page]]のサーバーを使っている際にこの問題に気付いた）。また、詳しい条件はわからないが、筆者の経験では、単にそのコンソールウインドウを長時間使わず放置するだけでも同じ現象が発生することがあり、文字選択をしないように気を付けるだけでは不十分なようである。

解決策としては、conhost.exe以外のターミナルを使えばよい。比較的新しいWindowsであればWindows Terminal、それが無理ならCygwinやGit Bashのターミナル（mintty.exeだっけ？）などでもよい（ただGit BashはCygwinと比べてWindowsアプリケーションとの互換性が微妙な気もする。例えばcmd.exeを開いて方向キーを押すと不自然な動作をする）。また、あくまでブロックされるのは出力に際してであるため、<code>> nul</code>などで出力を全て捨てればブロックはされない（ただしそれでは不便という場合も多いだろう）。

== cmd ==

あまり知られていないが、cmdでもbashなどと同じように<code>PROMPT</code>変数にエスケープ文字を入れることでプロンプト（<code>C:\Users></code>みたいなやつ）の色やスタイル（太字など）を変えられる。

[https://qiita.com/nanagami1369/items/9f6894b0759f74519f1e コマンドプロンプトのプロンプトに色をつける方法 - Qiita]

[https://chiyosuke.blogspot.com/2018/05/blog-post_7.html ちよぶろ。: コマンドプロンプトの色を変える。]

例えば黄色（<code>33</code>）+太字（<code>01</code>）+末尾空白（<code>$S</code>）なら

<syntaxhighlight lang="shell">$E[33;01m$P$E[0m$G$S</syntaxhighlight>
ただしVista以降～Windows 10の途中（1607より前？）ではcmd+conhostという組み合わせ（といっても多分cmdを使うとしたら事実上conhostが必要となる）だとエスケープ文字がそのまま表示されてしまい色がつかない。これは[https://github.com/adoxa/ansicon ansicon]で解決できる。

* 参考: [https://qiita.com/TsuneoNakanishi/items/a86f52a406b99d202c06 WindowsコマンドプロンプトでのANSIエスケープシーケンスの使用 - Qiita]など


== Windows Terminal ==

プロファイルを自分で追加できるなどの仕様は、Windowsにしてはなかなか偉い感じがする。

フォントは、GUIからではなく設定ファイルを変更する必要はあるが、変えられる。デフォルトのCascadia CodeよりConsolasのほうが英数字が日本語のちょうど半分のサイズになるので読みやすい。

<syntaxhighlight style="margin-bottom:0.2em;" lang="vb.net">"defaults": {
"font":{ "face": "Consolas",
"size": 12
}
},</syntaxhighlight>
<div style='text-align: center;'>設定例</div>

CSSのように複数のフォントを指定することはまだできないようである。[https://github.com/microsoft/terminal/issues/2664 https://github.com/microsoft/terminal/issues/2664] まあこれはしょうがないだろう。

==== 太字 ====

[https://github.com/microsoft/terminal/issues/109 https://github.com/microsoft/terminal/issues/109]の通り、反映されない不具合があった。そこに書いてある通り、Windows Terminalの設定画面から開ける（下部にボタンあり）JSONファイルの”profiles”にある<code>"defaults": {}</code>またはその下の”list”の各プロファイルの中身に<code>"intenseTextStyle": "bold"</code>と書くことで治った。

<syntaxhighlight lang="javascript">{
....//省略

"profiles":
{
"defaults": {
"intenseTextStyle": "bold" //ここ
},
"list":
[
....
{
"commandline": "%SystemRoot%\\System32\\cmd.exe",
"font":
{
"face": "Consolas"
},
"guid": "{00000000-4444-3333-2222-111111111111}",
"hidden": false,
"name": "name",
"intenseTextStyle": "bold" //またはここ
},
....
]
},
}</syntaxhighlight>
== コマンドライン引数をめぐる仕様 ==

{{UnderConstruction|Windowsでのターミナル環境}}
[[Category:IT]][[Category:Windows]]{{#seo:|title={{FULLPAGENAME}} - Turgenev's Wiki}}

Zotero

2025-10-02T06:09:00Z

Turgenev: Notion-MW

文献管理ソフト。Firefox界隈由来のOSSで、割と自由に何でも設定できるので、そういうのが好きな人にはおすすめ。

== 初期設定 ==

Zoteroが提供するストレージは300MBとかしかないので外部のクラウドストレージで論文ファイルを管理するのがおすすめ。これに関しては [https://note.com/sdeso/n/n013952313c1b 【令和最新版】文献管理ソフト Zoteroのすゝめ｜SD｜note] が大変詳しく、これでほぼ十分であるが、いくつか追加しておく。

* Zotero自体がもともとFirefoxのアドオンに由来している関係で、Zoteroの拡張機能の拡張子.xpiはFirefoxのアドオンのものと同一であるため、FirefoxからZoteroの拡張機能をダウンロードしようとしてクリックすると（アドオンと混同されて）「ファイルが壊れています」などと出ることがある。なので右クリックから保存を選ぶ。
* ファイルの自動命名は日本人だと苗字がLast Nameと判断されてしまうなど微妙であったが、うまく直せなさそうなのでデフォルト設定のままでよさそう。
* コレクションごとにフォルダ分けしたい場合は、”Use subfolder defined by”を\%c(linuxでもこれで大丈夫だが/%cでもよい)にする（この場合は、複数のコレクションに属するアイテムが発生しないよう気を付ける）。参考:[https://dr-kayai.hatenablog.com/entry/2020/02/09/234427 Zoteroの使い方（我流、逐次更新） - Bag of ML Words]など

=== ブラウザ拡張の使い方など ===

ブラウザ拡張はZotero起動時のみ使える。Zoteroのウインドウで論文を入れたい対象のコレクションを開いておいてからブラウザで拡張機能アイコンをクリックするとそこに入れてくれる。普通に左クリックしたときにEmbedded Metadataを使用しろみたいなエラーがでることがあるので、そういうときは右クリックしてそれっぽいのを選ぶ。

ブラウザ拡張を経由せずに（ローカルにあるpdfを）入れるときは、ZoteroのウインドウにD&D（このとき元の場所にファイルを残しておく必要がなければshiftを押せば削除される（移動になる））して取り込む。日本語論文などで文献情報がうまく読まれない場合は、Manual Entryを作成するしかない場合もあるが、J-STAGEなどから取ってきたものであれば、改めてWebでその論文を探してブラウザ拡張で入れるとうまくいくこともある（pdfエディタで注釈などを記入済みならファイルだけ後で差し替えればよい）。

ブラウザ拡張を経由しない場合、ZotFileのフォルダ内の適切なコレクションには分類されないので、適宜アイテムを選択してRename Attachmentsをする必要がある。なお（最初のサイトで推奨されている通り）”サブコレクションからアイテムを表示”がonだと特定コレクションの中身（サブコレクション内部を含め）すべてに対してRename Attachmentできて便利だが、実はonでしなくてもマイ・ライブラリを押したときは全アイテムが表示されるのでそれで十分だと思う（あと、サブコレクションから表示されてるアイテムを別コレクションに移動しようとしても正しく元の場所から削除されずコピー扱いになってしまうデメリットもこれで解決できる）。なお、前述のようにクラウドストレージのフォルダをLocation of Filesに指定して同期している場合、Rename Attachmentsすることで初めてファイルが同期されることになるので、できるだけ早めにやっておくべし。

また、Zotero内のゴミ箱に移動してもファイルは自動で移動されないし、完全に削除してもファイルは消えない。今のところの筆者の運用としては、一旦DELETEという名前のコレクションに移動してからRename and moveを実行し、適宜ゴミ箱に移動して（アイテムを）削除し、DELETEフォルダの中身も定期的に削除する、とやっている。

== dateデータのフォーマットについて ==

Zotero Connectorはサイトやpdfから論文の投稿（掲載？）日時を自動で取得してくれるが、結果の文字列はブラウザ本体の言語設定によって変わる。具体的には、日本語であれば「4月 22 , 2011」、英語であれば「April 22, 2011」のようになる。なお、そもそも日付が取得できず年と月だけあるいは年だけの論文、また日付まで取れても「2011-04-22」のような書式になる論文もあり、これはどのサイトから取得するかなどによって異なるとみられるが詳細不明。

本来はこんな言語依存の単一文字列ではなく年、月、日それぞれ明示的に別のデータとして管理するのが筋だろう。実際、この仕様のせいで、Better BibTeXの使用時に問題が発生していた（後述）。


== [https://retorque.re/zotero-better-bibtex/ Better BibTeX for Zotero] ==

まずは普通に[https://retorque.re/zotero-better-bibtex/ Better BibTeX for Zotero]からxpiをインストール、再起動すると再びdrag-and-dropを有効にするため再起動しろと言われるので再起動する。Citation keyが追加されている。設定はZotfileのような別メニューではなくZoteroの設定画面に追加されている。[https://qiita.com/skrb_hs/items/73061b7a8e39f1e73e0d Zotero+BibTeXで参考文献の出力を自動化&論文の引用で出てきた順にソートする]の通り、export→fieldsのfields to omit from exportにabstract,file,doiと書く。[https://plaza.umin.ac.jp/shoei05/wp/index.php/2020/10/31/206/ Zotero で citation keys を設定する ( zotero-better-bibtex ) - shoei05]の通りCitation keysを[auth:lower][year][shorttitle1_1]に変更する。

Citation keyは「情報」タブに表示されているほか、メイン画面に表示することもできる。また検索でも使える（これは設定で無効にできる）


==== 日本語文献のCitation Keyについて ====

[https://qiita.com/shiro_takeda/items/dfb857e69aa8ed2cc977 https://qiita.com/shiro_takeda/items/dfb857e69aa8ed2cc977]


==== yearデータの不具合(6.7.60で修正済) ====

参考文献には出版年を書く必要があり、BibTeXではyearというフィールドに書かれる。このデータはZoteroの文献情報のdateのところから取得されており、「April 22, 2011」「2011-04-22」のようなdateのデータからは正しく「2011」だけを抽出してくれるが、dateが前述の「4月 22 , 2011」のような書式になっていた場合はうまくいかず、この文字列全てがBibTeX（.bib）に出力されてしまう（報告済み: [https://github.com/retorquere/zotero-better-bibtex/issues/2449 [Bug]: Japanese date format is not parsed correctly · Issue #2449 · retorquere/zotero-better-bibtex]、6.7.61あたりで修正済み）。←の通り、Better BibTeXのエクスポート時に適用されるscript（Export → postscript）のところにデータを置換するための以下のようなコードを書いておくとよい。

<syntaxhighlight lang="vb.net">if (tex.has.year) {
tex.add({name: 'year', replace: true, value: tex.has.year.value.replace(/.* /, '')})
}</syntaxhighlight>
設定箇所はこんな感じ↓

<div class="res-img">https://turgenev.cloudfree.jp/mw1/imgs/zot-settings.jpg</div>

* 今は治っているかもしれないが、デバッグ出力を有効化して再起動してからスクリプトを一度編集しないとスクリプトが読み込まれないバグがあった（[https://github.com/retorquere/zotero-better-bibtex/issues/2447 https://github.com/retorquere/zotero-better-bibtex/issues/2447]）。


== Zotero Protocolを使用した操作 ==

{{Valuable}}

ZoteroはGUIのソフトであるが、コマンドラインからも一定の操作が可能である。具体的には、<code>zotero://</code>という形式のURL（URIスキーム）を以下のように指定してZoteroを起動することができる（既に起動していた場合は、画面に変化が起こる）。

<syntaxhighlight lang="python">zotero.exe -url "zotero://url/here"</syntaxhighlight>
URLについては、明確にAPIとして仕様が定められたものではなさそうで、全体的にあまりドキュメントは充実していない。

一例として、特定のコレクション内のアイテムが選択された状態にするということができる。コメントが不親切でわかりづらいが [https://github.com/zotero/zotero/blob/master/components/zotero-protocol-handler.js zotero/zotero-protocol-handler.js at master · zotero/zotero] の<code>scopeObject</code>などと書いてあるあたりをよく読むと、<code>zotero://select/library/collections/{collection_key}/items/{item_key}</code>という形式で指定すればよいことがわかる（groupIDなどと書いてある部分もあって紛らわしいが、groupというのはcollectionとは別の概念で、複数ユーザー間での共有のライブラリのようなものを指すようである）。<code>collection_key</code>と<code>item_key</code>はどちらも<code>1A2B3C4D</code>のような英数字による8文字の識別子である。ちなみにcollectionとitemにはそれぞれIDも割り当てられているがこちらは1～3桁くらいの数字でありkeyとは別なので注意。


== 指定されたCitation keyのアイテムをZoteroで開く ==

前述の方法を応用して実装してみる。ここではCitation keyとしてBetter BibTeXのものを使うことを仮定する。

まず、Citation keyからアイテムのキーを取得する部分を作る。Citation keyはBetter BibTeXが管理しているので（ここではデフォルトの~/Zoteroに各種データがあると仮定して）~/Zotero/better-bibtex.sqliteを読めばアイテムのkeyとの対応がわかる。次にアイテムが所属するコレクション（複数ある場合は最初のもの）のkeyをzotero.sqliteから取得する。ここではIDを一旦経由する必要がある。

Zoteroの起動中はデータベースファイルがロックされているが、[https://sqlite.org/forum/info/a2e9387b8ea1c919b2ad1ecafb417cebb15c48634c55b3abd6a9acbb2fabf797 SQLite Forum: Option to open a database as read-only despite locked.]にある通り、（Windowsなら）<code>sqlite3 "file:Zotero\\zotero.sqlite?mode=ro&nolock=1"</code>のようにしてやると読み取り専用で開くことはできる（書き込まないのでこれで充分）。今回はpythonで実装するが、pythonのsqliteでもこのパラメータが同じく使える。

コード例:

<syntaxhighlight style="margin-bottom:0.2em;" lang="python">import sqlite3
import sys
import json
import subprocess
db = sqlite3.connect('file:'+sys.argv[1]+'?mode=ro&nolock=1', uri=True)
cur = db.cursor()
cur.execute('SELECT data FROM "better-bibtex" where name="better-bibtex.citekey"')
d = json.loads(cur.fetchone()[0])
mydict = {}
for item in d["data"]:
mydict[item["citekey"]] = item["itemKey"]
myKey = mydict[sys.argv[3]]

db2 = sqlite3.connect('file:'+sys.argv[2]+'?mode=ro&nolock=1', uri=True)
cur2 = db2.cursor()
cur2.execute("SELECT itemID FROM items WHERE key=?", (myKey, ))
item_id = cur2.fetchone()[0]
cur2.execute("SELECT collectionID FROM collectionItems WHERE itemID=?", (item_id, ))
# 所属する最初のコレクションIDを取得
collection_id = cur2.fetchone()[0]
# collectionIDからcollectionKeyを取得
cur2.execute("SELECT key FROM collections WHERE collectionID=?", (collection_id,))
collection_key =cur2.fetchone()[0]
print(collection_key)
subprocess.run(f'"C:\Program Files (x86)\Zotero\zotero.exe" -url "zotero://select/library/collections/{collection_key}/items/{myKey}')
db.close()
db2.close()</syntaxhighlight>
<div style='text-align: center;'>zoto.py</div>

上記コードは以下のように起動できる。

<syntaxhighlight lang="c#">python "path\to\zoto.py" "%USERPROFILE%\Zotero\better-bibtex.sqlite" "%USERPROFILE%\Zotero\zotero.sqlite" %1</syntaxhighlight>
* [[Windowsのクリップボードを用いた選択コンテンツの取得|Windowsのクリップボードを用いた選択コンテンツの取得]]と組み合わせれば、選択文字列をCitation keyとするアイテムを一発で開くことも可能。

== その他 ==

アイテムが入っているコレクションを知りたいときはアイテムが選択された状態でCtrlキーを押すとよい。
[[Category:IT]]{{#seo:|title={{FULLPAGENAME}} - Turgenev's Wiki}}

Windowsにおける仮想的ディスプレイ

2025-10-02T06:08:58Z

Turgenev: Notion-MW

例えばZoomでプレゼンテーションをするときに、PowerPointの「発表者ツール」を使いたければ、普通は2つのディスプレイが必要である。しかしディスプレイが常に2つあるとは限らないので、画面共有に使用するだけの「仮想的なサブディスプレイ」があればいいのではないか、という発想がうまれる。他には、リモートのみで使用するPCや、ゲーム画面の配信などにおいても需要があるようである。


== 解決策1 - ダミープラグ ==

そこそこ普及している、ハードウェア的な解決策である。端子に差し込むとディスプレイが接続しているものと誤認させることができる。EDIDエミュレータとも呼ぶ？価格は500-1000円程度。4K対応かどうかなどスペックにより値段に多少の差はあるだろう。近年はHDMIが主流と思われるが、VGAのものもある（こちらは自作が可能との情報も）。

金はかかるが、後者の解決策にないメリットとして、一気に複数のOSに対応できる（製品による？）というのがある。


== 解決策2 - ソフトウェア的に ==

しかしPCを騙すためだけの虚構的な存在に金を払うのも考えれば面白くない話である。ソフトウェア的に解決できないだろうか。ということでこの記事ではWindowsに対するソフトウェア的解決策を紹介する。なおLinuxについてはxvfb?だとか、そういうのを使えばできそうな気がしたが今のところ手元ではできていない。できたら記事を書くかも。Macは持っていないので試せないが、[https://github.com/tSoniq/displayx https://github.com/tSoniq/displayx]とか、betterdisplayとかがあるらしい。PowerPointやゲーム実況という用途を考えるとWindowsが一番需要が大きそうではある。

ソフトウェア的解決策が欲しいといってすぐソフトが出てくればいいが、調べてもあまり出てこない。比較的それっぽくて怪しくなさそうだったのが

[https://www.amyuni.com/forum/viewtopic.php?t=3030 https://www.amyuni.com/forum/viewtopic.php?t=3030]

だが、それでもやはりちょっと素性が知れない。もう少し調べていくと、Indirect Display Driver (IDD)という技術を使うとそういうソフトウェアが書けるというMicrosoftのドキュメントが出てきた。そこからさらに調べてみるとこんなものがあった。

[https://github.com/roshkins/IddSampleDriver https://github.com/roshkins/IddSampleDriver]

これを試したら無事動いたので、ついでに解像度を変えてみたら、普通に8Kくらいまで動いた（ただしその分重くなる）。↑のレポジトリでも解像度増やしてというissueがあったので、forkして公開した。さらにver0.0.1.2では"C:\IddSampleDriver\option.txt”というファイルを設定することで解像度オプションやディスプレイの個数をユーザーが設定できるように変更した。

[https://github.com/ge9/IddSampleDriver https://github.com/ge9/IddSampleDriver]

本家のreadmeで紹介された結果、どうやらゲーム配信関係のRedditとかに載ったみたいで、実質的にはほぼ何もしていないのに800以上のstarを獲得している。

また、さらにこれをforkしたものとして[https://github.com/VirtualDrivers/Virtual-Display-Driver https://github.com/VirtualDrivers/Virtual-Display-Driver]が作られ、これはすでに5000starを超える大きなプロジェクトになっている。

* こちらはHDRにも対応していて積極的に開発されているので、今は基本的にはこちらを使ったほうがいいだろう。（以下の情報はIddSampleDriverなので古いかもしれない）

{{Outdated}}

以下、このソフトの話を主にしていく。

== インストール手順 ==

Scoopを使う方法と使わない方法の2種類がある。いずれもリポジトリのREADME.mdに書いてある通りで、それほど難しくはない。


==== Scoopを使う ====

筆者がかかわったものではないが、Scoopを用いてインストールができるようにしてくれた方がいるようである。インストールを行うスクリプトのソースコードは[https://github.com/ScoopInstaller/Nonportable/blob/master/bucket/iddsampledriver-ge9-np.json https://github.com/ScoopInstaller/Nonportable/blob/master/bucket/iddsampledriver-ge9-np.json]にある。

==== 通常のインストール ====

途中で、バッチファイルを用いて証明書（.cerという拡張子のファイル）をローカルコンピューターの「信頼されたルート証明機関」に登録する必要がある。そのバッチファイルではcertutilが使用されている（ちなみに以前のリリースではcertmgrが使用されていた）が、証明書を開いて表示される画面からの操作などによっても可能である。

登録を行わないと、デバイスマネージャで「このドライバーはデジタル署名されていません。」と警告が出て、最終的に「デバイスをインストール中にエラーが発生しました。」「ストアへドライバーを追加する際に問題が発生しました。」と言われて失敗する。

<ul>
<li>参考
[https://docs.microsoft.com/ja-jp/windows-hardware/drivers/install/installing-test-certificates https://docs.microsoft.com/ja-jp/windows-hardware/drivers/install/installing-test-certificates]
[https://garafu.blogspot.com/2014/04/blog-post.html https://garafu.blogspot.com/2014/04/blog-post.html]</li></ul>

== 開発者向け情報 ==

Indirect Display DriverについてはMicrosoft公式のドキュメントや公式サンプル[https://github.com/microsoft/windows-driver-samples/tree/master/video/IndirectDisplay https://github.com/microsoft/windows-driver-samples/tree/master/video/IndirectDisplay] を参照（IddSampleDriverはこれを編集してできたようである）。前述の通り自分は解像度を増やしただけなので技術的なことについては何もわかっていない。

公式サンプルはなんといっても公式のものであるから、まずはこれをビルドできる状態にするのが確実だろう。以下の説明は2021年8月頃にWindows10で試したときのものである。ビルドしようとするとWindowsUserModeDriver10.0がないと言われるので、[https://docs.microsoft.com/ja-jp/windows-hardware/drivers/download-the-wdk https://docs.microsoft.com/ja-jp/windows-hardware/drivers/download-the-wdk] を入れる。

すると次は「Spectre軽減策」（セキュリティ関係？）に関するエラーが出た。そこでVisual Studioのインストール時の「個別のコンポーネント」→「コンパイラ、ビルドツール、およびランタイム」のところから「最新」「（ARMではなく）x86とx64」と書いてある「Spectre軽減ライブラリ」を入れる（細かい表示は正確に記録していないかもしれないor変わっているかもしれない）。「SDK、ライブラリ、およびフレームワーク」にあるMFCとかATLみたいなやつは要らなさそうっぽい。

これでビルドが通った。exeを管理者権限で起動するとBluetoothのところのその他のデバイスとかに表示されるところまではいった。tmhがないとかSpectre関連のエラーとかwdfのエラーとか色々出ていたが全部大丈夫になった。

* [https://learn.microsoft.com/ja-jp/windows/win32/api/swdevice/nf-swdevice-swdevicecreate https://learn.microsoft.com/ja-jp/windows/win32/api/swdevice/nf-swdevice-swdevicecreate]に書いてあるように、SwDeviceCreateを呼びだすには管理者権限が必要である。従って、IddSampleDriverのようなソフトウェアをインストールするには管理者権限が事実上必須ということになる。ただし、インストールされたIddSampleDriverというデバイス自体は一般ユーザーでも使用可能である。

では次に本題のIddSampleDriverをビルドする。公式サンプルがビルドできている状況ならこちらも通るものと期待できる。少なくとも手元ではそうなった。逆にIddSampleDriverから始めてみても同様に、WindowsUserModeDriver10.0のエラー→Spectreのエラー、などとなった。

以下、当時の元リポジトリをビルドした際のメモ

* ソースコードに赤線は出ていたがコンパイルは通る。署名に関するエラー（file digestがなんとか）が出るのでプロジェクトのプロパティの下のほうのDriver SigningのFile Digest Algorithmに SHA256 と書く。
* 解像度やリフレッシュレートの設定が不適切だと、デバイスマネージャで何度か再読み込みされる感じの動作をしたあと自動的に停止され警告アイコンが表示される。
* 日付を超えるとタイムゾーン（筆者はJST=UTC+9）の関係でInf2Catが失敗する。プロジェクトのプロパティからInf2Catのメニューに行き、General → Use Local Time を「はい (/uselocaltime)」に設定する。参考: [https://monoist.atmarkit.co.jp/mn/articles/1307/26/news003_3.html https://monoist.atmarkit.co.jp/mn/articles/1307/26/news003_3.html]
** さらに、これを設定してもなぜか現地時間の21:00～24:00の間にビルドしたものは正常動作しなかった（ビルドは通るしデバイスマネージャでの警告アイコンも出ないのにサブディスプレイが出ない）ので、ビルド時はその範囲外になるようにPCの時計設定を適宜変更する（報告済み [https://github.com/roshkins/IddSampleDriver/issues/5 https://github.com/roshkins/IddSampleDriver/issues/5]）

自分でビルドしたやつのインストール時は、（おそらく自分のユーザー名を用いて署名が作られているため？）最初の一回のみ改めて.cerを登録する必要がある。二回目以降は、サブフォルダに生成されてるcat, dll, infをもってきて置き換えたあとデバイスマネージャから「ドライバーの更新」をすればよい。デバイスマネージャーは使ったフォルダをちゃんと覚えているようなので、頻繁に移動しなくていい安定した場所でビルドを行うのがいいだろう。


== HDR対応について ==

Virtual-Display-DriverのほうではHDRに対応している。

[https://github.com/VirtualDrivers/Virtual-Display-Driver/issues/32 https://github.com/VirtualDrivers/Virtual-Display-Driver/issues/32]や[https://github.com/roshkins/IddSampleDriver/issues/23 https://github.com/roshkins/IddSampleDriver/issues/23]で話題になっている通り、Windows 10ではHDRは動作しない。

* HDRの基本についてはここがよさそう？ [https://zenn.dev/okuoku/scraps/ca346768627367 https://zenn.dev/okuoku/scraps/ca346768627367]

=== その他参考情報 ===

このIDDというのはUser-modeで動作するやつなのだがKernel-modeで動作するKMDODとかいうものもあるらしく、そっちの方が多くのことができるのかもしれない。前述の両リポジトリのHDR関連issueでも言及されている。ただし調べた感じ、ただちに使えそうなものは見つからなかった。まあWindowsのディスプレイドライバなんか趣味でそうそう書くもんではないのでしょうがない。

一応適当に調べて出てきた参考リンクなど

* IDDとKMDODに関する議論（2019年） 
[https://community.osr.com/discussion/291368/wddm-display-only-driver-to-create-a-virtual-display-monitor https://community.osr.com/discussion/291368/wddm-display-only-driver-to-create-a-virtual-display-monitor]
* KMDODで仮想ディスプレイを作れるかどうかについて(2017年) 
[https://community.osr.com/discussion/286843/how-to-implement-virtual-display-adapter https://community.osr.com/discussion/286843/how-to-implement-virtual-display-adapter]
** そこで言及されているLin JiaBang氏のソフト（動作未確認） 
[https://github.com/LinJiabang/virtual-display https://github.com/LinJiabang/virtual-display]
* WDDMで仮想ディスプレイを作れるかどうかについて（2016年） 
[https://social.msdn.microsoft.com/Forums/vstudio/ja-JP/2d60c1c2-5198-47e2-b5d9-2ba28461e72e/how-to-implement-virtual-display-adapter-driver-on-windows-10?forum=wdk https://social.msdn.microsoft.com/Forums/vstudio/ja-JP/2d60c1c2-5198-47e2-b5d9-2ba28461e72e/how-to-implement-virtual-display-adapter-driver-on-windows-10?forum=wdk]

== 課題 ==

あくまで仮想的なディスプレイであるからその中身を目視で確認することはできない（ただし別途その内容をウインドウに表示するソフトなどは作れそう）。従って例えば、これを使って共有している間にZoomのミーティングコントロールが非表示になってミュートのon/offなどができなくなるなどの不便さはある。

ちなみに、Windowsでのマルチモニター管理を切り替えるメニューのショートカットはWin+Pであるが、ここで「セカンドスクリーンのみ」を選ぶなどして仮想でないほうのディスプレイが真っ暗になってしまったときはWin+Pを押せば復帰できる。

== 変更記録 ==

もともとディスプレイは5個追加されるが、重過ぎるのでNUM_VIRTUAL_DISPLAYSを1に変更。

解像度を大きくしたいのでソースコードを「1920」で検索し、3840x2160と2560x1440を追加する。

まず s_KnownMonitorModes のところ。この際リフレッシュレートが60HzになるようにPixel Clock Rateをちゃんと計算する必要がある。

<syntaxhighlight lang="c++">{
229008 * KHZ, // pixel clock rate [Hz]
{ 229008 * KHZ, 2560 + 40 }, // fractional horizontal refresh rate [Hz]
{ 229008 * KHZ, (2560 + 40) * (1440 + 28) }, // fractional vertical refresh rate [Hz]
{ 2560, 1440 }, // (horizontal, vertical) active pixel resolution
{ 2560 + 40, 1440 + 28 }, // (horizontal, vertical) total pixel resolution
{ { 255, 0 }}, // video standard and vsync divider
DISPLAYCONFIG_SCANLINE_ORDERING_PROGRESSIVE
},
{
509366 * KHZ, // pixel clock rate [Hz]
{ 509366 * KHZ, 3840 + 40 }, // fractional horizontal refresh rate [Hz]
{ 509366 * KHZ, (3840 + 40) * (2160 + 28) }, // fractional vertical refresh rate [Hz]
{ 3840, 2160 }, // (horizontal, vertical) active pixel resolution
{ 3840 + 40, 2160 + 28 }, // (horizontal, vertical) total pixel resolution
{ { 255, 0 }}, // video standard and vsync divider
DISPLAYCONFIG_SCANLINE_ORDERING_PROGRESSIVE
},</syntaxhighlight>
のようにする。Pixel Clock Rateの数値は多少のズレがあってもいいみたい？だけど気分的に少しだけ大きめに設定してある。

そのすぐ下のEDIDのところはそのままでよさげ。

そして、一番下のほうのTargetModesのところを変える。配列サイズの変更も忘れずに。いやvectorだから関係ないか。

ちなみにs_KnownMonitorModesがノータッチだとここには1920x1280までしか書けないっぽい。


== EDID編集に関して（メモ） ==

HDR機能の追加に使えるかと思ったが結局効果はなかった。

Deltacast E-EDID Editorがふつうに有能。ここに書いてあった: [https://ameblo.jp/holycater/entry-12467348533.html https://ameblo.jp/holycater/entry-12467348533.html]

[https://www.ninshoshiken.com/about-ajsc1-edid-editor/ https://www.ninshoshiken.com/about-ajsc1-edid-editor/]

[http://blawat2015.no-ip.com/~mieki256/diary/201602063.html http://blawat2015.no-ip.com/~mieki256/diary/201602063.html]

[http://www.edidreader.com/ http://www.edidreader.com/]
[[Category:IT]][[Category:Windows]]{{#seo:|title={{FULLPAGENAME}} - Turgenev's Wiki}}

HTTP・SOCKS・透過プロキシ・UDP

2025-10-02T06:08:55Z

Turgenev: Notion-MW

SOCKS・透過プロキシ・UDP-over-TCPなどを中心に、ネットワークの変更に使えるプロキシ関連の各種技術を雑にまとめた。

近年はGo製のものが多い。また検閲に対抗するためか、中国系（中国語でissueが投稿されているなど）のものが多い。gost, go-proxy, hysteria, txthinking/socks5, things-go/socks5などはいずれもその2つに当てはまる。たまにロシア系もある。


== 大規模・多機能系 ==

以下のものは機能が多くて分類できないのでソフトウェアごとに紹介する。

==== gost ====

GO Simple Tunnelの略らしい。安定版のv2系（[https://github.com/ginuerzh/gost https://github.com/ginuerzh/gost], [https://v2.gost.run/ https://v2.gost.run/]）と開発中のv3系（[https://github.com/go-gost https://github.com/go-gost], [https://gost.run/ https://gost.run/]）で大きく仕様が異なる。v3は開発中と言いつつv2系のページを見るとかなりv3推しに見える。

starはバージョン2が16k、バージョン3が5kほど。

イメージとしては、TCPによるシンプルなトンネルプロトコル（これがgost）（暗号化無し）と他の大量のプロトコルの間の相互変換を実装しているような感じと思われる。

非常に多機能で、このページで紹介している多くソフトウェアの基本機能をカバーしていると言ってもいいくらい。UDP-over-TCP系は基本これ1つで十分。機能の豊富さに比して明らかにドキュメントが不足しており、エラーメッセージも親切ではない（起動時ではなく実際にパケットが来てからエラーが出るような感じ）。

<ul>
<li>connectorとしてはsocks5も用意されているが、相手がgostでない限りUDP Associateは動かない模様。具体的には
<syntaxhighlight lang="javascript">gost -L "auto://:8480?udp=true&relay=udp" -F socks5://192.168.1.13:3129</syntaxhighlight>
などとしても、 05f3 0001 0000 0000 0000みたいなよくわからんリクエストが送られてしまう。このf3のところは下記の独自拡張っぽい。
[https://github.com/go-gost/x/blob/04d1587a77964636d8e50f5cce475ee8621bece7/internal/util/socks/socks.go#L17 https://github.com/go-gost/x/blob/04d1587a77964636d8e50f5cce475ee8621bece7/internal/util/socks/socks.go#L17]</li></ul>

==== go-proxy ====

[https://github.com/snail007/goproxy https://github.com/snail007/goproxy]

これも見た感じgostと同じくらいか一部では上回るくらい多機能に見えるが、この雰囲気にしては珍しく有料版があり、無料版だと一部機能が制限されているようなので、あまり使ったことはない。


== GFW回避 ==

中国政府の検閲システムであるグレート・ファイアウォール（GFW）に対抗することを主な目的とするもの。

==== shadowsocks ====

SOCKSに暗号化を施した独自プロトコルで、いくつかの実装がある。[https://github.com/shadowsocks/shadowsocks-rust https://github.com/shadowsocks/shadowsocks-rust]などが主流とみられる。

VPN以外のGFW回避ソフトウェアだとおそらくもっともメジャー。

サーバーとクライアントに分かれていて、クライアント側では透過プロキシにも対応している。


==== Hysteria ====

通信路がHTTP/3に偽装した形で暗号化される。shadowsocksの次世代に位置付けられるソフトウェアのように見える。

SOCKS5サーバー部分にはtxthinking/socks5を使っている。


== SNI Proxy ==

HTTP・HTTPSのリバースプロキシで、host（HTTPの場合）あるいはsni（HTTPSの場合）に基づいてアクセスを振り分けるものをSNI Proxyと呼ぶことがあるらしい。ドメイン→IPを決め打ちする場合は多くのソフトウェアでできそうだが、任意ドメインに対してDNSで解決しつつ振り分けるのは対応していない場合もある。gostはこれにも対応している。Nginxは対応しているが、ngx_stream_ssl_preread_moduleとかが必要なので、環境によっては動かしづらいかもしれない。HAProxyは自分が試した限りでは動かせなかった。これらの汎用のプロキシサーバーの他に、これを専門とするソフトウェアもある。

* Nginxでの使用例（自分の記事）→ [https://turgenev.hatenablog.com/entry/2025/03/21/020550 【Android】NextDNSをアプリごとに有効無効切り替え+Tailscale経由の自宅鯖を使ってControl D風のトラフィック転送 - turgenev’s blog]とか[https://turgenev.hatenablog.com/entry/2025/04/27/215220 【広告ブロックDNS】特定ドメインへのTCP接続を途中で切断してAd-Shield対策 - turgenev’s blog]


==== dlundquist/sniproxy ====

[https://github.com/dlundquist/sniproxy https://github.com/dlundquist/sniproxy]　starは2.6kほど。2024年に更新あり。非推奨である理由（HTTP/2とかQUICでうまくいかないとか）も書いてある。

==== tcpproxy ====

[https://github.com/inetaf/tcpproxy https://github.com/inetaf/tcpproxy]　starは1.3kほど。ライブラリ用途がメインか。


==== ameshkov/sniproxy ====

[https://github.com/ameshkov/sniproxy https://github.com/ameshkov/sniproxy]　starは70ほど。上流のSOCKS5, HTTPプロキシへの転送機能がある。


==== puxxustc/sniproxy ====

[https://github.com/puxxustc/sniproxy https://github.com/puxxustc/sniproxy]　starもほぼなく更新も9年前。


== SOCKSプロキシサーバー ==

ここにあげたものは特に注記がなければUDP（ただし筆者が念頭に置いているのはAssociateのみで、Bindに関してはほぼ調べていない）に対応している。


==== Dante ====

[https://www.inet.no/dante/index.html Dante - A free SOCKS server]

企業（Inferno Nettverk A/S）によるオープンソースなSOCKS5実装で、有償サポートまであるらしい。見るからに古臭いHPで、メンテされているかどうか不安になるが、つい最近2024年末にもアップデートがあり、次期バージョンの計画についても記載されている。

Cで書かれていて、おそらく最も正確なSOCKS5実装だろう。コメントも親切で、リファレンス実装のような雰囲気がある。他の透過プロキシクライアントなどをテストする際はDanteでテストして動けば安心感がある。

Cで書かれていて、おそらく最も正確なSOCKS5実装だろう。コメントも親切で、リファレンス実装のような雰囲気がある。他の透過プロキシクライアントなどをテストする際はDanteでテストして動けば安心感がある。


==== OpenSSH ====

現実的に最もよく使われているSOCKSサーバーは間違いなくOpenSSHだろう。しかし、UDP-over-TCPの問題があるため、UDPはサポートされていない。

ssh -Dでforward方向のプロキシを建てるのが有名だが、OpenSSH 7.6からは-Rでreverse方向にも建てられるようになった。クライアント側が7.6以上であればよい。

* 参考: [https://www.openssh.com/txt/release-7.6 OpenSSH 7.6] （<code>ssh(1): add support for reverse dynamic forwarding</code>）

==== socks-with-udp-over-ssh ====

[https://github.com/ge9/socks-with-udp-over-ssh https://github.com/ge9/socks-with-udp-over-ssh]

これ自体はSOCKS5サーバーではなく、TCP接続（あるいは任意のバイトストリーム）の上にUDP付きのSOCKS5を通すために自分が実装したツール。サーバー側とクライアント側に分かれている。しかし実装した後にgostで同じことができることに気付いた。

経緯・使い方などは[https://turgenev.hatenablog.com/entry/2024/05/12/231208 root権限のないssh上にUDPを通す方法について（ポートフォワード、SOCKS5プロキシなど） - turgenev’s blog]に書いてある。

* このツールでは、DNSリクエストを解釈してサーバー側（サーバー側から見えている外部のDNSを指定してもよい）で解決を行う機能も実装してある。この機能は”fake dns”と名付けているが、shadowsocks-rustのfake dnsやtun2proxyのvirtual dnsはこれとは異なる機能のようである。

==== 3proxy ====

[https://3proxy.ru/ 3proxy tiny free proxy server for Windows, Linux, Unix: SOCKS, HTTP, FTP proxy]

[https://github.com/3proxy/3proxy https://github.com/3proxy/3proxy]

ロシア系。SOCKS・HTTP・POP3・SMTPなどいくつかのプロキシを含む。エラーメッセージなどがかなり不親切だが、結構多機能で、ちゃんと動くソフト。<code>3proxy</code>というメインの実行ファイルとあわせて、各プロキシに対応した<code>socks</code>や<code>proxy</code>といった検索性の低い名前の実行ファイルがいくつか含まれているちょっと謎の構成。

==== fast-socks5 ====

[https://github.com/dizda/fast-socks5 https://github.com/dizda/fast-socks5] Rust製では最も有名か。starは500ほど。使ったことなし


==== txthinking/socks5 ====

[https://github.com/txthinking/socks5 https://github.com/txthinking/socks5]

starは700前後。hysteriaやtrojan-goなどいくつかの大きなプロジェクトで使われており、現在もメンテされているgo製のSOCKS5関連ライブラリでは一番メジャーか。

クライアントもある。

自分のfork（[https://github.com/ge9/socks5 https://github.com/ge9/socks5]）ではFull Cone NATを追加した


==== armon/go-socks5 ====

[https://github.com/armon/go-socks5 https://github.com/armon/go-socks5]

starは2kだが、最終更新2016年でUDP Associateも無し。Wireproxyで以前使われていたが使われなくなった（[https://github.com/whyvl/wireproxy/issues/15 https://github.com/whyvl/wireproxy/issues/15]）。

ここからフォークされたものが複数ある。


==== things-go/go-socks5 ====

[https://github.com/things-go/go-socks5 https://github.com/things-go/go-socks5]

armon/go-socks5からのフォーク（GitHub上ではfork扱いではない）。starは400個ほど。UDP Associateはサポートしているがバグあり（自分のPRが採用されるかどうかで揉めてる[https://github.com/things-go/go-socks5/pull/63 https://github.com/things-go/go-socks5/pull/63]）。

Wireproxyで使われている。

自分のフォーク [https://github.com/ge9/go-socks5 https://github.com/ge9/go-socks5] ではFull Cone NATを追加した


==== haxii/socks5 ====

[https://github.com/haxii/socks5 https://github.com/haxii/socks5]

armon/go-socks5からのfork。UDP Associate対応。starは50個前後。最終更新2019年。


==== wzshiming/socks5 ====

[https://github.com/wzshiming/socks5 https://github.com/wzshiming/socks5]

クライアントもある。

starは90個ほど。最終更新2024年。

とりあえずredsocksと組み合わせでUDP透過プロキシ動作確認済。

Wireproxyで使用が検討された（[https://github.com/whyvl/wireproxy/issues/15 https://github.com/whyvl/wireproxy/issues/15]）が結局使用されず。


==== haochen233/socks5 ====

[https://github.com/haochen233/socks5 https://github.com/haochen233/socks5]

クライアントもある。

UDP Associateはサポートしているが、starは49とさらに少なく、最終更新も2021年。

同じくWireproxyで使用が検討された（[https://github.com/whyvl/wireproxy/issues/15 https://github.com/whyvl/wireproxy/issues/15]）が結局使用されず。


== 透過SOCKSプロキシクライアント ==

[https://turgenev.hatenablog.com/entry/2024/03/25/160556 透過プロキシを用いて特定アプリケーションのTCP・UDP通信をSOCKS5経由にする方法（Windows・Linux（iptables TPROXY）・Androidなど） - turgenev’s blog]で扱った内容。

バックにSOCKS(SOCKS5)プロキシを用いてTCP・UDPのレイヤで透過プロキシを行うもの。VPNと同等の動作で、基本的には管理者権限（Linuxの場合、最低でもCAP_NET_ADMIN）が必要。

以下のいずれも、ドメイン解決にはプロキシが適用されない（Linux向けの2つはできなくはないかもしれないが、しづらい）ことに注意。

==== redsocks ====

[https://github.com/semigodking/redsocks semigodking/redsocks] （fork元の[https://github.com/darkk/redsocks darkk/redsocks]はメンテされておらず、TCPのTPROXYに非対応）

*nix対応。BSD系で動かすことができたという話は[https://turgenev.hatenablog.com/entry/2024/06/10/134017 FreeBSD/OpenBSD/NetBSDで透過プロキシのredsocksを動かしてみる - turgenev’s blog]に書いた。

==== hev-socks5-tproxy ====

[https://github.com/heiher/hev-socks5-tproxy https://github.com/heiher/hev-socks5-tproxy] Linux向け。redsocksより若干知名度は下がるものの、きちんとメンテされている。


==== ProxiFyre ====

[https://github.com/wiresock/proxifyre https://github.com/wiresock/proxifyre] Windows用の透過SOCKSクライアント。管理者権限必要。TCP/UDP両方対応。インストールも簡単で、よくできている。


==== Proxifier ====

[https://www.proxifier.com/ https://www.proxifier.com/] 見た感じ機能は十分そうだが、有料なので試していない。


== VPN(tun) ==

上記と似ているが、VPNとして動作するもの。プロセスが特定しづらい場合・特定のIPアドレス範囲だけで十分な場合などに効果を発揮する。

以下は特筆しない限りUDP Associateに対応。もちろん、pingなどは通らない。

==== tun2proxy ====

[https://github.com/tun2proxy/tun2proxy https://github.com/tun2proxy/tun2proxy]

Rust製。starは700ほど。SOCKSとHTTPをtunにしてくれる。

==== hev-socks5-tunnel ====

[https://github.com/heiher/hev-socks5-tunnel https://github.com/heiher/hev-socks5-tunnel]

hev-socks5-tproxyの作者による。Androidアプリの[https://github.com/heiher/sockstun https://github.com/heiher/sockstun]もここから。

== ライブラリ関数ハック系 ==

ライブラリ関数レベルでの置き換えになるため厳密性・安定性に欠ける（異常終了する場合もある）ものの、root権限がない場合に有効な手法。


=== Linux（LD_PRELOAD） ===

libc依存でないプログラム（Go製のものなど）には効かない。

==== socksify ====

後述のDanteの一部。UDP/TCP両対応。唯一のUDP対応のものである。

<syntaxhighlight lang="go">route {
from: 0.0.0.0/0 to: 0.0.0.0/0 via: 192.168.1.1 port = 1080
}</syntaxhighlight>
こんな感じの<code>/etc/socks.conf</code>を作るか、<code>SOCKS5_SERVER=192.168.1.1:1080 socksify curl http://ipv4.icanhazip.com</code> とかでもよい。

Macでも動くはずだが、筆者が唯一試したMac環境ではcurlに対してさえうまく動作しなかった（socksifyを使わないのと全く同様に動作するだけだった）（<code>DYLD_FORCE_FLAT_NAMESPACE=1</code>は指定している）。


==== proxychains-ng(proxychains) ====

ngはnew generationの略で、proxychainsの後継である。ただしコマンド名はproxychains4である。

多段プロキシを構成するためのソフトウェア。

UDP非対応（[https://github.com/rofl0r/proxychains-ng/issues/336 https://github.com/rofl0r/proxychains-ng/issues/336]）。ただしDNSに対応したproxy_dnsというオプションがあり、これを有効にするとDNS以外のUDP通信が正常に機能しなくなる副作用がある（[https://github.com/rofl0r/proxychains-ng/issues/103 https://github.com/rofl0r/proxychains-ng/issues/103]）。


==== torsocks(tsocks) ====

多分、メンテされていないtsocksがTorに取り込まれてtorsocksになったような感じ。tsocksは非常に古く、多分2010年以降には更新されていないが、知名度は高く、今でも多分そこそこ使われてそう。

torsocksはアクティブなはず。ただし、Torでない普通のSOCKS5を指定しても動かないようである（やり方が悪いかも）。

tsocksはUDPには対応していない。torsocksもそうだが、まずそもそもTor自体がUDPに対応していない。


=== Windows（DLL Hijacking） ===

どのDLLを置き換えたらいいか自明ではなさそうなので、LD_PRELOADと違って対象とするソフトウェアごとに実装が必要そう。そもそも不可能なソフトウェアもLD_PRELOADの場合より多そう。よく見かけるのはDiscordを対象にしたもので、ロシア系のものが多い。筆者は使ったことがない。

==== discord-drover ====

[https://github.com/hdrover/discord-drover https://github.com/hdrover/discord-drover]

==== discord-voice-proxy ====

[https://github.com/runetfreedom/discord-voice-proxy https://github.com/runetfreedom/discord-voice-proxy]


== HTTPプロキシ ==

Squid, Privoxyなどが有名。

Squidには透過プロキシ機能があるが、redsocksなどとは動作の細かい部分が異なる。[https://turgenev.hatenablog.com/entry/2025/03/25/171736 squidで透過プロキシ（intercept, tproxy）を動かす - turgenev’s blog]に書いた。


== localhost・LANなどへのアクセス制限 ==

典型的な設定例として、localhostやプライベートIPへのアクセスを制限する設定をSquid・Dante・3proxyそれぞれに関して紹介しておく。

プロキシ側で設定せず、cgroupなどを使ってファイアウォール側で制御する方法もある。

==== squid ====

<code>to_localhost</code>はbuilt-inとして定義されていて、<code>localnet</code>（=srcがlocalnet）についてもUbuntuパッケージで提供されるsquid.confには入っているのだが、localnetがdstであるものとなるとACLが定義されていない。

<code>deny to_localhost</code>と<code>deny to_linklocal</code>は定義済みという前提で、以下のように書くとよい。

<syntaxhighlight lang="go">acl to_localnet dst 0.0.0.1-0.255.255.255
acl to_localnet dst 10.0.0.0/8
acl to_localnet dst 100.64.0.0/10
acl to_localnet dst 172.16.0.0/12
acl to_localnet dst 192.168.0.0/16
acl to_localnet dst fc00::/7

http_access deny to_localnet</syntaxhighlight>

==== 3proxy ====

IPv4のみ対応。

<syntaxhighlight lang="go">deny * * 127.0.0.0/8,0.0.0.1-0.255.255.255,10.0.0.0/8,100.64.0.0/10,169.254.0.0/16,172.16.0.0/12,192.168.0.0/16 * * * *
allow *</syntaxhighlight>

==== dante ====

IPv4のみ対応。squid・3proxyの場合と違って0.0.0.0もblockしてしまっているが、そもそも使わないので問題ないはず。

<syntaxhighlight lang="go">client pass {
from: 0/0 to: 0/0
}

socks block {
from: 0/0 to: 127.0.0.0/8 # localhost
protocol: tcp udp
command: bind connect udpassociate bindreply udpreply
}
socks block {
from: 0/0 to: 0.0.0.0/8 # RFC 1122 "this" network (LAN)
protocol: tcp udp
command: bind connect udpassociate bindreply udpreply
}
socks block {
from: 0/0 to: 10.0.0.0/8 # RFC 1918 local private network (LAN)
protocol: tcp udp
command: bind connect udpassociate bindreply udpreply
}
socks block {
from: 0/0 to: 100.64.0.0/10 # RFC 6598 shared address space (CGN)
protocol: tcp udp
command: bind connect udpassociate bindreply udpreply
}
socks block {
from: 0/0 to: 169.254.0.0/16 # RFC 3927 link-local (directly plugged) machines
protocol: tcp udp
command: bind connect udpassociate bindreply udpreply
}
socks block {
from: 0/0 to: 172.16.0.0/12 # RFC 1918 local private network (LAN)
protocol: tcp udp
command: bind connect udpassociate bindreply udpreply
}
socks block {
from: 0/0 to: 192.168.0.0/16 # RFC 1918 local private network (LAN)
protocol: tcp udp
command: bind connect udpassociate bindreply udpreply
}

socks pass {
from: 0/0 to: 0.0.0.0/0
protocol: tcp udp
command: bind connect udpassociate bindreply udpreply
}</syntaxhighlight>

== SOCKS関連の話題 ==


==== NATが介在する場合などのUDP Associateの動作 ====

OpenSSHの項目でも関連することを述べたが、UDP-over-TCPの性能劣化を避けるため、UDP Associateは「サーバー側がクライアント側に対してUDP通信で使うための中継ポートを通知する」という動作を伴う。この際、ネットワーク上でクライアント側からサーバーが直接見えていればよいが、NATを介している場合、クライアントから見たときのサーバーのIPとサーバー自身から見たときのサーバーのIP（中継ポート通知に含まれるのはこれ）が異なることがあり、通信が成立しなくなってしまう（SSHのポート転送を普通に使うだけではUDP Associateが使えないのも直接にはこれが原因）。

ただし、[https://turgenev.hatenablog.com/entry/2024/03/25/160556 透過プロキシを用いて特定アプリケーションのTCP・UDP通信をSOCKS5経由にする方法（Windows・Linux（iptables TPROXY）・Androidなど） - turgenev’s blog]にも書いた通り、Proxifyreやhev-socks5-tproxyなどは中継ポート通知のIP部分を無視するため、ポート番号が変わらないNATであれば問題なく動作する（redsocksはダメ）。


==== SOCKS5によるドメイン解決 ====

SOCKS5（SOCKS4aも？）では、クライアントがCONNECTなどの要求をする際、接続先をIPアドレスではなくホスト名（ドメイン名）で指定することができる仕様になっている。これによりクライアント側ではなくSOCKS5サーバー側でドメイン解決が行われる。

透過SOCKSプロキシの場合、TCP/UDPレイヤでのプロキシとなるので、この機能が使われることはない（[https://turgenev.hatenablog.com/entry/2024/03/25/160556 透過プロキシを用いて特定アプリケーションのTCP・UDP通信をSOCKS5経由にする方法（Windows・Linux（iptables TPROXY）・Androidなど） - turgenev’s blog]）（さらに、繰り返しになるが付け加えておくと、普通にセットアップした場合はDNSにプロキシは使われない）。一方、HTTPのレイヤで動作するWebブラウザでは、この機能が使われる場合がある。2018年時点での[https://github.com/FelisCatus/SwitchyOmega/issues/1379 https://github.com/FelisCatus/SwitchyOmega/issues/1379]によれば、Chromeでは必ずSOCKS5サーバー側でドメイン解決が行われる（これは[https://github.com/FelisCatus/SwitchyOmega/wiki/FAQ FAQ]にも書いてある）一方、Firefoxではそうでなかったようである。現在のFirefoxでは「SOCKS v5 を使用するときは DNS もプロキシーを使用する（Proxy DNS when using SOCKS v5）」（v4についても同様のオプションがあるが、SOCKS4aではないSOCKS4でどうなるかは未検証）というオプションがあってデフォルトで有効になっているため、やはり基本的にはSOCKSサーバー側でドメイン解決が行われる。AndroidのFirefox（この設定項目がない）にProxy SwitchyOmegaを入れた場合もそのように動作した。

なお、HTTPプロキシについても、ブラウザで普通に使う分には、（HTTP/HTTPS共に）ドメイン解決は基本的にプロキシサーバー側で行われる。

* 拡張機能などではうまく動作しない場合がある模様。 [https://github.com/FelisCatus/SwitchyOmega/issues/2304 https://github.com/FelisCatus/SwitchyOmega/issues/2304]


==== ブラウザのSOCKS5プロキシのWebRTC対応 ====

基本的に現在主流のブラウザ（Firefox, Chrome）のSOCKS5プロキシ機能（拡張機能で設定する場合を含む）はUDPには対応していないため、Discordの通話などWebRTC関係の機能を使うと生IPが漏洩する（またはそれを防ごうとすると単にその機能が使えない）。これは原理的に実装が不可能なわけではなく、単に需要が少ないから実装されていないだけである。

* Chromeではどれが最新か不明（最近の物は少ない）。このへんとか？[https://issues.chromium.org/issues/41180783 Chromium]
* torのバグ報告 [https://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/151 https://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/151]
* firefoxの [https://bugzilla.mozilla.org/show_bug.cgi?id=1808692 https://bugzilla.mozilla.org/show_bug.cgi?id=1808692]
** QUIC関連 [https://bugzilla.mozilla.org/show_bug.cgi?id=1882071 https://bugzilla.mozilla.org/show_bug.cgi?id=1882071]
** 新しめの包括的なバグレポート [https://bugzilla.mozilla.org/show_bug.cgi?id=1947229 https://bugzilla.mozilla.org/show_bug.cgi?id=1947229]

従って、ブラウザのWebRTCをプロキシさせたい場合はVPNや透過プロキシなどroot/管理者権限が必要な手法を使うことが多くなるだろう。ただしLinux+Firefoxの場合はsocksifyが使えるのでrootが無くても可能。


==== UDP AssociateリクエストのDST.ADDRとDST.PORT ====

クライアントがサーバー側にUDP Associateリクエストをするとき、この2フィールドには通信したい宛先ではなく（←というかそもそもそれが複数ある場合もある）、クライアント側がUDP Associateに使用する予定のポートを入れる。指定しない場合（例えばNATがある場合、これを予測するのは難しくなる）は、全ビットを0に設定する必要がある。

これによってサーバー側は、UDPパケットが送られてきたタイミングでそれが事前に通知されたものと一致するかどうか確認できるというわけである。

この部分に誤ってクライアント側が通信したい宛先ポートを入れるよう実装していたSOCKS5クライアントがいくつかある。

* semigodking/redsocks…自分の[https://github.com/semigodking/redsocks/issues/210 https://github.com/semigodking/redsocks/issues/210]で修正済み。
* gost…[https://github.com/ginuerzh/gost/issues/96 https://github.com/ginuerzh/gost/issues/96]で修正済み。
* txthinking/socks5…[https://github.com/txthinking/socks5/issues/15 https://github.com/txthinking/socks5/issues/15]で修正済み。
* things-go/go-socks5…これはサーバー側。[https://github.com/things-go/go-socks5/issues/29 https://github.com/things-go/go-socks5/issues/29]の通り、クライアントが必ずアドレス・ポートを通知してくれる（ゼロ埋めしない）と仮定していたが、修正された。

== プロキシプロトコル間の変換 ==

==== socks-to-http-proxy ====

[https://github.com/KaranGauswami/socks-to-http-proxy https://github.com/KaranGauswami/socks-to-http-proxy]

名前の通り、socksをhttpにしてくれる。starは250ほど。

==== privoxy ====

基本的にはHTTPプロキシソフトウェア。socksプロキシをhttpプロキシとして使えるようにする機能はあるが、より大がかり（一般ユーザーでの実行がしづらい）


== UDP・Wireguard関連 ==


==== UDPでサーバー→クライアントにデータ送信 ====

[https://github.com/prof7bit/udp-reverse-tunnel https://github.com/prof7bit/udp-reverse-tunnel]

これを使うと、サーバー側だけでポートが開けられるとしても事実上クライアント側で開けられるのと同等になるのでreverseをするのが楽になる

* [https://superuser.com/questions/1737943/how-to-create-a-reverse-udp-tunnel https://superuser.com/questions/1737943/how-to-create-a-reverse-udp-tunnel]
* どっちも開放できない場合、UDPホールパンチングで何とかするしかない

==== wgslirpy ====

[https://github.com/vi/wgslirpy https://github.com/vi/wgslirpy]

Slirp（ユーザーランドで動くPPPサーバーのようなもの）のような形で実装されたWireguardサーバー。rootなしでWireguardサーバーとして動作する。

==== wireproxy ====

[https://github.com/whyvl/wireproxy https://github.com/whyvl/wireproxy]

wgslirpyの逆のような（？）ツール。Wireguardクライアントであるが、SOCKSサーバーとして動作する。

依存ライブラリのUDP Associate対応が不完全（自分がプルリクを送っている）だが、クライアントによってはうまくUDP Associateが動く（[https://github.com/whyvl/wireproxy/issues/30 https://github.com/whyvl/wireproxy/issues/30]）。

<ul>
<li>自分でカスタマイズしてCone NATを加えたthings-go/go-socks5を使えば（<code>go.mod</code>で<code>replace github.com/things-go/go-socks5 => ../../go-socks5</code>などとする）、以下のようなコードをroutine.goのsocks5.Optionのところに追加することでCone NATにできる。
<syntaxhighlight lang="go">socks5.WithDialUDP(func(laddr, raddr *net.UDPAddr) (net.PacketConn, error) { return vt.Tnet.DialUDP(laddr, raddr) }),</syntaxhighlight></li></ul>


=== Wireguard通信の確立: 各パターンでのやり方 ===

各状況に応じて、2端末間でUDPの暗号化された通信路を確立するための方法を書いた。

* forwardは「クライアント→サーバー」、reverseは「サーバー→クライアント」という意味。「サーバー」は、「ポートが開放できる方」という意味合い。

==== どっちもrootあり ====

普通にWireguardを使う

==== サーバーのみrootあり ====

forward

サーバーはWireguard、クライアントは普通にWireproxyでいける

reverse

udp-reverse-tunnelで頑張って逆にする（あるいはホールパンチング）。

その上で、wgslirpyを使うか、Hysteriaを使うか

==== クライアントのみrootあり ====

↑さっきと逆

forward

wgslirpyを使うか、Hysteriaを使うか

reverse

udp-reverse-tunnelで頑張ったうえで普通にWireguardとWireproxy

==== どっちもrootなし ====

この場合そもそもWireguardを使うメリットはあまりないかも。というのとrootがないならポート開放も無理そう

forward

Hysteriaでいけそう。

reverse

udp-reverse-tunnelしてHysteria？かな

== その他の話題 ==

==== ドメインごとにプロキシを変更できるブラウザ拡張のiframeにおける動作 ====

FoxyProxyやSwitchyOmega(ZeroOmega)など、ドメインごとに自動でプロキシを切り替えてくれるブラウザ拡張はChromium系にもFirefoxにもいくつかあるが、これらはあくまでコンテンツのオリジンを元にプロキシを適用しており、ブラウザのタブを見ているわけではない。つまり、foo.comのページを開いていて、そこにbar.comのコンテンツがiframeで埋め込まれている場合、iframeの内部は、bar.comに対して使用するものと指定されたプロキシを使用して処理される。

一応、[https://superuser.com/questions/250172/disable-enable-the-proxy-on-a-tab-by-tab-basis-in-firefox Disable/enable the proxy on a tab by tab basis in Firefox]によると、Firefoxのcontainer-proxyというのがこれに近い機能を実質的に実現してくれるらしい。
[[Category:IT]]{{#seo:|title={{FULLPAGENAME}} - Turgenev's Wiki}}

LinuxのGUI（X11/Wayland）

2025-10-02T06:08:53Z

Turgenev: Notion-MW

== Wayland ==

とりあえずはGNOMEでの設定内容のみ。

* gnomeパッケージ自体を入れる必要はない（ゲームとか無駄なものが入る）
** gdm(3)は最低限必要
** waylandを有効にするために多分mutterが要る
** gnome-shell-extensionsも（gnome shell extensionsを使うなら）要る（なぜかgnome-shell-extension-managerのdependenciesに入っていないため（バグ報告した: [https://bugs.launchpad.net/ubuntu/+source/gnome-shell-extension-manager/+bug/1999001 Bug #1999001 “gnome-shell-extensions is not in dependencies” : Bugs : gnome-shell-extension-manager package : Ubuntu]））
** gnome-sessionはいらないかも
** [https://itsfoss.com/install-gnome-linux-mint/ https://itsfoss.com/install-gnome-linux-mint/] にあるvanilla-gnomeでもまだ余分なものが入っている気がする
* ここ参考になる [https://gihyo.jp/admin/serial/01/ubuntu-recipe/0717 https://gihyo.jp/admin/serial/01/ubuntu-recipe/0717]

指紋認証関連で弾かれる。pamとfprintdの連携がうまくいってない感があったので<code>libpam-fprintd</code>を入れたら治った。

[https://sites.google.com/site/zoom2writej/ubuntu/ibus https://sites.google.com/site/zoom2writej/ubuntu/ibus]

* USB-Cのディスプレイを起動時に認識しない。刺し直すと認識する。なんでだろう。→なんかこれはシャットダウンして待ったりすると治るタイプのやつ。ハードウェア的な問題かな。dmesg -ewとかで見れたりはする。Bad usb cable?とかなんとか言われてた気がする


=== NVIDIA ===

nvidiaが入っている状態だとちょっとめんどくてデフォルトだとXorgにされる。

[https://qiita.com/k0kubun/items/c1162098cbd7eba1bed0 https://qiita.com/k0kubun/items/c1162098cbd7eba1bed0]

に書いてあるとおり<code>nvidia-drm.modeset=1</code>をするといける。（それだけだとだめだったという情報もあるっちゃあるがこっちでは大丈夫だった）

* GRUB_CMDLINE_LINUX_DEFAULTに入れるとリカバリモードのオプションには追加されない[https://gihyo.jp/admin/serial/01/ubuntu-recipe/0743 第743回　Ubuntuの標準ブートローダーであるGRUBを改めて見直す | gihyo.jp]

NVIDIA上のmpv/celluloid

手元では<code>gpu-context=x11vk</code>が効果あり。mpvはこれだけでいけた。

celluloidの場合、さらに環境変数の<code>__EGL_VENDOR_LIBRARY_FILENAMES=/usr/share/glvnd/egl_vendor.d/50_mesa.json</code>が必要。参考: [https://github.com/mpv-player/mpv/issues/9393 https://github.com/mpv-player/mpv/issues/9393]

* applicationsの.desktopのほうでは、<code>env __EGL_VENDOR_LIBRARY_FILENAMES=/usr/share/glvnd/egl_vendor.d/50_mesa.json celluloid --mpv-gpu-context=x11vk %U</code>としておけばよい。

ただ、x11vkでperformanceが悪いというissueもある。[https://github.com/mpv-player/mpv/issues/10326 https://github.com/mpv-player/mpv/issues/10326] 見た感じこちらでは問題ない。

x11eglだと<code>libEGL warning: DRI3: Screen seems not DRI3 capable</code>と言われるが動いてはいるっぽい。

他にもいくつかある。

* [https://wiki.archlinux.org/title/mpv https://wiki.archlinux.org/title/mpv]

gnome-session-inhibitとかいうのは電源関連なのでそのさきの話かな。

==== 日本語入力 ====

ibus-mozcは廃止される？とかなんとか。Waylandに対応したfcitx5を使うのがよさそう。

全体的にはここ [https://gihyo.jp/admin/serial/01/ubuntu-recipe/0689 https://gihyo.jp/admin/serial/01/ubuntu-recipe/0689] （前述の第717回の記事でも引用されている）が参考になるかと。

基本的にはfcitx5-diagnoseを使って赤文字のところ（問題点）を順番に直していくのがよい。

まずGNOMEがめっちゃibus使おうとしてしまうらしいのでibus-daemonを除去する必要があるらしい。そこでibusパッケージをremoveする。

次に環境変数の

<syntaxhighlight lang="javascript">GTK_IM_MODULE=fcitx
QT_IM_MODULE=fcitx
XMODIFIERS=@im=fcitx</syntaxhighlight>
が必要らしい。/etc/environmentでもいいが、ユーザーごとにしたければ（Waylandの場合だと）<code>~/.config/environment.d/*.conf</code>に書くといいらしい。（参考: [https://blog.vikke.name/2020/01/27/wayland%E3%81%A7%E3%81%AExprofile%E3%82%84xsession%E3%81%AE%E4%BB%A3%E3%82%8F%E3%82%8A%E3%81%AB%E7%92%B0%E5%A2%83%E5%A4%89%E6%95%B0%E3%82%92%E8%A8%AD%E5%AE%9A%E3%81%99%E3%82%8B/ https://blog.vikke.name/2020/01/27/waylandでのxprofileやxsessionの代わりに環境変数を設定する/] 及びそこで引用されている[https://wiki.gnome.org/Initiatives/Wayland/SessionStart https://wiki.gnome.org/Initiatives/Wayland/SessionStart]）

さらにgnome-shell-extension-managerを入れてkimpanelを追加する。これでいけるはず

* gnome-shell-extension-managerのバージョンをどうにかしたような気もするが詳細忘れ

一応ibus使用時のメモ

[https://qiita.com/spumoni/items/f1e5023829c575af4dd0 Ubuntu 21.04でキーボードがus配列に変わってしまう問題 - Qiita]や[https://golang.hateblo.jp/entry/ubuntu22.04-keyboard-layout-mozc Ubuntu 22.04 でキーボードレイアウトおかしくなる問題。 - golangの日記]とかに書いてあるようにibus-mozcがjp配置を使うようにして（初期設定だとusになってしまう）、<code>ibus write-cache</code> と<code>ibus restart</code>（ibusに接続できませんと言われたら<code>ibus-daemon --xim -d -r</code>が有効かも）をする。いや普通に<code>ibus-daemon --xim -d -r</code>だけでいいっぽい

=== システムトレイ ===

MEGAなどが正しく動作しなかった。[https://github.com/JetBrains/compose-jb/issues/1847 https://github.com/JetBrains/compose-jb/issues/1847]に書いてあるとおり、extension managerから[https://extensions.gnome.org/extension/615/appindicator-support/ https://extensions.gnome.org/extension/615/appindicator-support/] を入れるとうまく動作するようになる。

* Linux Mint 21.1にしてから動かなくなった気がする
* <code>gnome-shell-extension-appindicator</code>というパッケージもある？
[[Category:IT]][[Category:Linux]]{{#seo:|title={{FULLPAGENAME}} - Turgenev's Wiki}}

Windowsの右クリックメニューから複数ファイルをまとめて開く

2025-09-01T01:32:12Z

Turgenev: Notion-MW

複数のファイルを別々にではなく一度にまとめて開きたいということがある。すなわち”app.exe file1” “app.exe file2”…をそれぞれ実行するのではなく、”app.exe file1 file2 …”を実行したい。例えば複数の音楽ファイルを連続再生したいときなどである。

ただ、エクスプローラ上で複数ファイルを選択して開く（右クリックで「開く」を選ぶorエンターキー）と、別々に実行されてしまう。では、右クリックメニューからこれを実行するにはどうすればいいか？というのがこの記事のテーマである。

ついでに、パス長さ制限を超えるファイルやフォルダにおける機能制限も解決する。


== Windows10以前の右クリックメニューに戻す ==

まず、Windows11に移行すると右クリックメニューの項目数が大幅に削られており、とても使いにくいので、Windows10までの仕様に戻す必要がある。[https://pc-karuma.net/right-click-context-menu-back-on-windows-11 Windows 11 - 右クリックメニューを旧仕様に戻す方法 - PC設定のカルマ]などに従って修正しよう。コマンド例は以下。これはユーザーごとの設定なので、管理者権限は不要である。

<syntaxhighlight lang="javascript">reg add "HKCU\Software\Classes\CLSID\{86ca1aa0-34aa-4e8b-a509-50c905bae2a2}\InprocServer32" /f /ve</syntaxhighlight>
ファイルを開く操作ならダブルクリックでできるわけで、それでもあえてファイルを右クリックするユーザーの層を考えれば、使用頻度の高いメニューに絞る必要がないことは明らかである。右クリックメニューは動作が重いという問題点も指摘されてきたが、それなら項目数を削る以外の方法でパフォーマンスを改善するのが筋だろう。そもそも、Windows 11の右クリックメニューもそれほど快適な動作ではない。

なおバージョン22H2からはShift+右クリックで旧仕様のメニューが出るようになったようなので、それで十分という人は設定しなくてもよい。

ちなみにこれ以降も同じだが、<code>HKEY_CURRENT_USER</code>以下はユーザー別設定なのでPC自体の再起動をしなくてもログアウト（サインアウト）→ログイン（サインイン）で全て反映されるはず。また今回の例に関しては、実際にはexplorerの再起動で十分である。

=== 動画の右クリックメニューの順番がおかしい ===

動画ファイル（mp4やmkvなど）に関して、右クリックメニューの順番がおかしくなるという問題がある。具体的には、全ファイル共通のメニュー（「お気に入りに追加」など）とClipchampのメニューが普通の「開く」よりも上に表示されてしまう。また単一ファイル選択時だと（関連付けがすでに設定されているにもかかわらず）「プログラムから開く」が太字になってしまっている。

* 単一ファイル選択時

<div class="res-img">https://turgenev.cloudfree.jp/mw1/imgs/win-rc/clipchamp-sing.png</div>

* 複数ファイル選択時

<div class="res-img">https://turgenev.cloudfree.jp/mw1/imgs/win-rc/clipchamp-mult.png</div>

これはどうやらClipchampのメニューが悪いらしく、[https://www.elevenforum.com/t/add-or-remove-edit-with-clipchamp-context-menu-in-windows-11.6882/ Add or Remove Edit with Clipchamp Context Menu in Windows 11 Tutorial | Windows 11 Forum]（[https://www.elevenforum.com/t/clipchamp-context-menu-removal.6150/ Clipchamp context menu removal | Windows 11 Forum]に書いてあった）や[https://www.naporitansushi.com/clipchamp-context-menu-disable/# Windowsの右クリックの「Clipchampで編集」を削除する方法 | ナポリタン寿司のPC日記]に書いてある通り、Clipchampのメニューを非表示にすると治る。コマンド例は以下。

<syntaxhighlight lang="javascript">reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Shell Extensions\Blocked" /v {8AB635F8-9A67-4698-AB99-784AD929F3B4} /f</syntaxhighlight>
* HKLMでも設定できる。また、「デバイスキャスト」を非表示にする場合はUUIDを<code>{7AD84985-87B4-4a16-BE58-8B72A5B390F7}</code>に変える。

Clipchampを表示したまま順番を治す方法は不明だが、自分でメニューを作ればできるかもしれない。Clipchampのメニューの実装に使われていると思われるIContextMenuについては後でも述べているのでそちらも参照。おそらくClipchampによるこのインターフェースの実装にバグがあるためにこのような挙動をしているのであろう。

以下に修正後の正しい表示を載せておく。いずれの例でも関連づけはデフォルトのメディアプレイヤーが使われているものと仮定している（書いていて気付いたが、同一アプリにもかかわらず「プレーヤー」「プレイヤー」の表記ゆれがある）。

* 単一ファイル選択時

<div class="res-img">https://turgenev.cloudfree.jp/mw1/imgs/win-rc/sing.png</div>

* 複数ファイル選択時

<div class="res-img">https://turgenev.cloudfree.jp/mw1/imgs/win-rc/mult.png</div>

== 不完全な解決策 ==

本題に入る。まずは、不完全ではあるがそこそこ簡単な解決策を紹介する。それは右クリックメニューにある「送る」を使う方法である。エクスプローラのアドレスバーに<code>shell:sendto</code>と入力すると「送る」メニューの元になっているフォルダを開くことができる。ここにショートカットやファイルを追加しておけば、それが右クリックメニューに表示され、選択されたファイルをまとめてコマンド引数として渡してくれる。ショートカットを編集すればオプションも渡せる（あるいはバッチファイルを突っ込んでもよい）。

* 今後紹介する方法にも共通するが、ファイルの順番としては、メインとして選択されたもの（右クリックされたもの）から下方向に進んでいき、下端まで達したら一番上に戻ってそれから選択されたものの直前まで進む。例えばファイルが”0”から”9”までの10個あるフォルダで全選択をして”5”を右クリックして「送る」を使うと、5 6 7 8 9 0 1 2 3 4の順番で渡される。

しかしこの「送る」には弱点があり、[ref]で紹介したように、この「送る」メニューは260文字の長さ制限を超えるパスをもつファイルに対してはうまく機能しない。音楽ファイルなんかはアーティスト名も曲名も色々入って長大な名前になりがちで、実際に自分がこれで困ることになった。

もう一つ、「送る」メニューは拡張子に関連付けられないという問題がある。つまり、音声ファイルを一度に開くためだけのコマンドも、画像ファイルを一度に開くためだけのコマンドも、全てのファイルを対象とした「送る」メニューにまとめて入れざるを得ない。メニュー数が無駄に増えればそれだけ管理・操作もしづらくなる。ついでに言えば、「送る」を一旦クリックしてから中の項目を選ぶ手間もなかなかバカにできないところがある。


== 前提知識 - メニューを管理するレジストリ ==

右クリックメニュー関連の設定はレジストリを使って管理されている。この記事では上記「送る」の問題を解決する方法をこの後で2つ紹介するが、いずれもレジストリの<code>command</code>という名前のキー（設定内容に応じて色々な所に設置されている）を編集する必要がある。それにあたって、前提知識としてレジストリの内容をある程度理解しておく必要があるだろう。

この話題に関しては比較的多くのサイトで解説があるが、Windowsのバージョンごとにかなり頻繁に仕様が変わっているようで、不十分なサイトも多い。最も優れているのは[https://www.pg-fl.jp/program/winreg/classes.htm Windowsレジストリ解剖記]で、かなり量は多いが、バージョンによる挙動の違いまで細かく示されている。

この記事に必要な操作を行うためには<code>command</code>の場所だけわかっていればいちおう十分だが、以下の内容くらいは覚えておいたほうがよい。

* HKEY_CURRENT_USERはHKCUと略され、ユーザーごとの設定を管理する。原則、変更はユーザー権限のみで可能。色々いじっても比較的安全。
* HKEY_LOCAL_MACHINEはHKLMと略され、システム全体（全ユーザー対象）の設定を管理する。変更には管理者権限が必要。設定は慎重に。
* HKEY_CLASSES_ROOTはHKCRと略され、関連付け専用のもので、HKCU\Software\ClassesとHKLM\Software\Classesの内容を合わせたものが表示される。関連づけの設定を確認するにはここを見るのがいいが、設定を変更する際にはここをいじるとHKLMのほうが変わってしまうことがあるのでHKCU\Software\Classesを変更したほうがよい。

以下では、設定方法を①ProgIDを使うもの②完全に独自のメニューを追加するものと大きく二つに分けて記述する。


=== ProgIDを使うもの ===

{{Valuable}}

特定の拡張子をもつファイルをダブルクリックやEnterで開くときに使われるプログラム、あるいは「既定のプログラム」あるいは「ファイルを開くプログラムの選択」のようなダイアログが表示されるときに表示されるプログラムは、このProgIDを用いて管理されている。この方法のメリットは、何より「ダブルクリックまたはEnterキー一発で起動できる」という操作性である。また、Windows11以前のメニューに戻さなくても使いやすい。

* 複数選択した際は「送る」と同様の順番で渡されるが、右クリックをしない場合は”メインとして選択されたファイル”がどれであるかが若干分かりづらい。基本的には最後に（左）クリックされたものになるはずで、よく見るとそれだけ少し太い（濃い）枠で表示されていることがわかる。なので音楽再生時など複数ファイルを上のものから順にすべて渡したいときは、「先に一番下にあるファイルをクリックしてから、一番上にあるファイルをShift+ダブルクリック（あるいはShift+クリックしたあとEnter）する」というのが有効である。

一方で、設定のしくみはやや煩雑である。具体的には、拡張子.xxxに対して

<code>HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.xxx\UserChoice</code>

というキーがあって、ここの<code>ProgId</code>の値を<code>value</code>としたときの<code>HKEY_CLASSES_ROOT\value\shell\open\command</code>の内容に従ってアプリケーションが起動される。

Windows10以降では<code>UserChoice</code>の中身を変更するためには普通の管理者権限やSYSTEMよりもさらに上位のTrustedInstaller権限が必要である。AdvancedRunなどを使ってTrustedInstaller権限で変更することは一応できたが、ハッシュ値の生成までちゃんとやっていないので自動で修正されてしまった（ここが解決できるかどうかは未調査）。従って、任意のコマンドを設定したい際は、まず<code>UserChoice</code>の中身を変更するところだけエクスプローラーのダイアログを使い、その後で<code>HKEY_CLASSES_ROOT\value</code>の中身を好きに変えるほうがよいだろう。

例えば新たなメニューを追加したい場合なら、以下のようにするとよい。

* 今まで使われていない（乱数値など）名前をもつダミーのexeファイル（実行ファイルとして正しく機能する必要はなく、空のファイルでもいいし、拡張子がexeでなくてもよい）を用意する（ここでは<code>dummy.exe</code>とする）
* 関連付けたい拡張子のファイルの右クリックメニューから「プログラムを開く」を選択し、<code>dummy.exe</code>を選んで関連づける
** これによりレジストリキー<code>HKEY_CURRENT_USER\Software\Classes\Applications\dummy.exe</code>が作られた上で<code>UserChoice</code>の<code>ProgId</code>には<code>Applications\dummy.exe</code>が書き込まれる
* <code>HKEY_CURRENT_USER\Software\Classes\Applications\dummy.exe\shell\open</code>の中身を自由に変更する。

=== 完全に独自のメニューを実装する ===

これは、「PowerShellをここで開く」「VS Codeで開く」のように完全に独自の右クリックメニューを追加するものである。設定は意外と簡単である。また、フォルダに対する右クリックメニューや全ファイルに共通の右クリックメニューを追加するにはこの方法しかない。ただし、Windows10以前のメニューに戻さないと「その他のオプション」を押す手間がかかるので注意。

拡張子ごとの設定は<code>HKEY_CLASSES_ROOT\SystemFileAssociations</code>にある（編集時は<code>HKEY_CURRENT_USER\Software\Classes\SystemFileAssociations</code>を使うのがいいだろう）（比較的新しいWindowsだと<code>HKEY_CURRENT_USER\Software\Classes\SystemFileAssociations</code>キー自体が存在しないことがあるが、自分で作ればちゃんと動作する）。<code>command</code>キーは<code>HKEY_CURRENT_USER\Software\Classes\SystemFileAssociations\.xxx\shell\yourcommandname\command</code>のような場所に作られることになる。

また、全てのファイルを対象にするメニューは<code>HKEY_CLASSES_ROOT\SystemFileAssociations\*</code>、フォルダを右クリックしたときのメニューは<code>HKEY_CLASSES_ROOT\Directory</code>、ドライブ（C:\など）を右クリックしたときのメニューは<code>HKEY_CLASSES_ROOT\Drive</code>、フォルダ（・ドライブ）の背景（何もないところ）を右クリックしたときのメニューは<code>HKEY_CLASSES_ROOT\Directory\Background</code>以下でそれぞれ管理されている。また、<code>HKEY_CLASSES_ROOT\AllFilesystemObjects</code>というのもあり、これはディレクトリとファイルの両方に適用される（ドライブやフォルダ背景には影響なし）。

* 一覧は[https://learn.microsoft.com/ja-jp/windows/win32/shell/reg-shell-exts ここ]かな？


==== 複数種類に一括で追加？ ====

<code>HKEY_CLASSES_ROOT</code>には<code>PerceivedType</code>という値があり、これに<code>video</code>などと指定されている場合は<code>HKEY_CLASSES_ROOT\SystemFileAssociations\video</code>にある設定が反映される（これによって複数種類のファイルに共通するメニューが作れる）…というような情報もあったのだが、手元のWindows 11では全く反映されなかった。（追記: [https://www.pg-fl.jp/program/winreg/classes.htm#reg_hkcr_systemfileassociations Windows レジストリ解剖記: HKEY_CLASSES_ROOT - Programming Field]に、<code>image</code>のような定義済みの名前以外には無効と記載あり）

そもそも<code>PerceivedType</code>に複数種類が指定できるか不明だったりと色々と意義が怪しいので諦めて各拡張子ごとに追加するのがよいのではないかと思う。CLSIDの部分は共通化されているわけなのでそれほど非効率な二重管理ということにもならないだろう。（そもそもこの辺のWindowsの仕様はころころ変わるっぽいのであまり頑張ってもしょうがないかも？）


=== Directory\Backgroundの表示 ===

エクスプローラーの左側のエリアにあるフォルダやドライブを右クリックしたときのメニューには、なぜかDirectory\Backgroundの内容も表示されてしまう。そのうえ、これらには正しくパラメータが渡されない（commandに直接書くときは<code>%V</code>などが入っていると起動せず、COM使用（少なくともDelegateExecute）で受け取る方法も不明）。

ただ、DirectoryやDriveに同名のメニューが登録されている場合はそちらが優先される。しかし、これを利用してメニューを非表示にすることはできない。（DirectoryやDriveのほうにLegacyDisableを書いたら、そもそもそちらが無かったのと同じになるっぽい）

実際には、Directory\Backgroundに設定するメニューはDirectoryにもDriveにも等しくあったほうがいい場合が多いと思うので、そのように設定するとよいだろう。

=== その他設定項目 ===

本筋とは関係ないので詳細は省くが、その他にもこれらのキーでは様々な設定ができる。

* <code>Icon</code>によるアイコンの設定
* <code>&</code>によるキーの設定（「"編集(E)"のEみたいなやつ」）
* <code>MUIVerb</code>（多分、言語設定ごとの表示文字列の切り替えとかができるようになるやつ）
* <code>AppliesTo</code>、<code>DefaultAppliesTo</code>による表示条件の設定
** AQS書式というのが使用可能で、かなり柔軟な指定ができる（特定フォルダ内のみに表示するなど）。ただしあまり情報がなく、[https://www.pg-fl.jp/program/winreg/classes.htm Windows レジストリ解剖記]でもそこまで詳細な解説はない。そこからもリンクされている[https://learn.microsoft.com/ja-jp/windows/win32/search/-search-3x-advancedquerysyntax?redirectedfrom=MSDN MSの公式ドキュメント]を読むのが早そう。あと、Backgroundメニューではそもそも背景フォルダに関する情報が全く渡されてこないようで（ただしどこかに書いてあったのではなく実験の結果）、使い物にならない。
*** Backgroundでは使えなかったという投稿の例
**** [https://superuser.com/questions/1020415/windows-explorer-context-menu-to-a-especific-folder-background Windows Explorer: Context menu to a especific folder (background) - Super User]
**** [https://stackoverflow.com/questions/47325736/windows-context-menu-directory-background-appliesto shell - Windows context menu directory\background AppliesTo - Stack Overflow]
* <code>HasLUAShield</code>による「管理者アイコン」の表示（<code>Icon</code>との併用可）
** これも実は上と同様にAQS書式で管理者アイコンの表示条件を設定できる
** このアイコン自体はSystem32のimageres.dllとかUserAccountControlSettings.exeとかに入っている
* <code>SubCommands</code>によるサブメニューの登録
** 手元のWindows11で試した限り、<code>Directory</code>や<code>Drive</code>ではうまくいくが<code>Directory\Background</code>だとサブメニューが出ない？
* <code>ExtendedSubCommandsKey</code>値による他の<code>shell</code>キーへの参照によるサブメニューの登録
** かなり強力で、循環参照も作れる。
** 例: [http://nonsubject.arinco.org/2011/08/ Nonsubject: 8月 2011]
** 一つのルートメニューが持てるサブメニュー上限は16個までという制限がある。[https://stackoverflow.com/questions/48625223/is-there-a-maximum-right-click-context-menu-items-limit https://stackoverflow.com/questions/48625223/is-there-a-maximum-right-click-context-menu-items-limit]
** これは<code>Directory\Background</code>でも有効。
* <code>Extended</code>によってShift+右クリックしたときのみ表示させる
* 設定例: [https://www.tenforums.com/tutorials/178668-add-remove-open-windows-terminal-administrator-context-menu.html Add or Remove 'Open in Windows Terminal as administrator' context menu | Tutorials]


=== ContextMenuHandlers（IContextMenu）を用いた実装 ===

{{Valuable}}

先ほどのClipchampのメニュー項目などはここまで述べたようにレジストリ内に静的に設定されているものではなくCOM(Component Object Model)を用いて外部のDLLの関数から動的に追加されているものである（ただDLLの指定自体はレジストリ内のInProcServer32のようなキーにあるはず）。Clipchamp以外だと7-ZipやPDF XChange Editorなどのメニューはこれを用いて実装されている。レジストリの<code>XXX\shellex\ContextMenuHandlers</code>といったキー以下に設定されているものはこれに分類される。

詳しくはIContextMenuなどのキーワードで検索すると出てくる[https://learn.microsoft.com/en-us/windows/win32/shell/shortcut-menu-using-dynamic-verbs Customizing a Shortcut Menu Using Dynamic Verbs - Win32 apps | Microsoft Learn]などを読むとよさそうだが、実装はかなり難解である。Clipchampもこの部分で不適切な実装をしたために順番がおかしくなったのではないかと思われる。

動作確認できたサンプルとしては、[https://github.com/microsoft/Windows-classic-samples/tree/main/Samples/Win7Samples/winui/shell/appshellintegration/NonDefaultDropMenuVerb https://github.com/microsoft/Windows-classic-samples/tree/main/Samples/Win7Samples/winui/shell/appshellintegration/NonDefaultDropMenuVerb]はIContextMenuを使って実装されており、dllをビルドしてCLSIDのInProcServer32でそれを指定するとちゃんと右クリックメニューが追加される。

また、メニューを追加する関数であるQueryContextMenuが呼ばれる時点で、引数となっているファイルの情報がわかる（Initialize関数においてIDataObjectが渡されているのでそれをクラスのフィールドなどとして持っておけばよい）ので、特定の拡張子のファイルのみに対してメニューを表示することもできる。もちろんファイルの内容まで読み取ってからメニューを表示するといったこともできるが、そこまですると右クリックするだけで動作が重くなるといった副作用が大きくなるのでやめた方が無難だろう。ただ、スタートメニューへのピン留め<code>{a2a9545d-a0c2-42b4-9708-a0b2badd77c8}</code>やPDF XChange Editor(9.3や10.2.1で確認)のメニューは実際にそのような挙動をする（余談だが、InfoTipの表示もexplorerが操作しづらくなる原因なので<code>HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced</code>の<code>ShowInfoTip</code>を0にしたほうがいい）（サムネイルなどはバックグラウンドで並列に走るので操作にはあまり影響がない）。またエラーが発生した場合はexplorer自体が強制終了することもあり、全体的に実装は慎重に行ったほうがよい。

==== コード例 ====

拡張子が.tで始まるファイル（*.txt, *.ttfなど）のみにメニューを追加するサンプル（から抜粋）。

<syntaxhighlight lang="c++">IFACEMETHODIMP CNonDefaultDropMenuVerb::QueryContextMenu(HMENU hmenu, UINT indexMenu, UINT idCmdFirst, UINT /*idCmdLast*/, UINT /*uFlags*/)
{
FORMATETC fmte = { CF_HDROP, NULL, DVASPECT_CONTENT, -1, TYMED_HGLOBAL };
STGMEDIUM medium;
HRESULT hr = _pdtobj->GetData(&fmte, &medium);
if (SUCCEEDED(hr))
{
HDROP hdrop = (HDROP)medium.hGlobal;
WCHAR szFile[MAX_PATH];
DragQueryFile(hdrop, 0, szFile, ARRAYSIZE(szFile));
const WCHAR* ext = wcsrchr(szFile, L'.');
ReleaseStgMedium(&medium);
if (ext && *(ext+1) != L't') {
return MAKE_HRESULT(SEVERITY_SUCCESS, 0, 0); // Add nothing
}
}
else
{
return MAKE_HRESULT(SEVERITY_SUCCESS, 0, 0); // Add nothing
}

WCHAR szMenuItem[80];

LoadString(g_hinst, IDS_CHECKDROP, szMenuItem, ARRAYSIZE(szMenuItem));
InsertMenu(hmenu, indexMenu++, MF_BYPOSITION, idCmdFirst + IDM_CHECKDROP, szMenuItem);

LoadString(g_hinst, IDS_CHECKNETRESOURCES, szMenuItem, ARRAYSIZE(szMenuItem));
InsertMenu(hmenu, indexMenu++, MF_BYPOSITION, idCmdFirst + IDM_CHECKNETRESOURCES, szMenuItem);

return MAKE_HRESULT(SEVERITY_SUCCESS, 0, (USHORT)(2)); // indicate that we added 2 verbs.
}</syntaxhighlight>
* 特定の拡張子に対して追加できるのは以下で知った
** できるという情報 
[https://stackoverflow.com/questions/43769772/how-to-add-context-menu-to-one-specific-file registry - How to add context menu to one specific File - Stack Overflow]
** 実際のコード 
[https://github.com/nyfair/freeimagerip/blob/master/plugin/FIShellExt/Thumb.cc freeimagerip/Thumb.cc at master · nyfair/freeimagerip]


==== IContextMenuの今後について ====

Windowsの右クリックメニューが重いと良く言われるのはこのような高い自由度をもつIContextMenuに起因するものであると思われる。Windows11ではIContextMenuよりIExplorerCommandがよいというのを見かけた（[https://twitter.com/kenichiuda/status/1417266893581295651 https://twitter.com/kenichiuda/status/1417266893581295651]や、そこで引用されている[https://twitter.com/madonomori/status/1417265763363168263 https://twitter.com/madonomori/status/1417265763363168263]）。[https://github.com/microsoft/Windows-classic-samples/tree/main/Samples/Win7Samples/winui/shell/appshellintegration/ExplorerCommandVerb https://github.com/microsoft/Windows-classic-samples/tree/main/Samples/Win7Samples/winui/shell/appshellintegration/ExplorerCommandVerb]も見てみる必要があるかも。

ただまあMicrosoftのことなのでIContextMenuもあと10年くらいは使えるだろう。

* [https://learn.microsoft.com/ja-jp/windows/apps/get-started/make-apps-great-for-windows#8-optimize-your-apps-context-menu-extensions-and-share-targets Windows 11 でアプリをすぐれたものにするためにできることトップ 11 - Windows apps | Microsoft Learn] を読んだら、Windows 11の（新しい）右クリックメニューに表示するためにはIExplorerCommandを使わなければならない（IContextMenuは不可）と明確に書いてあった。また、IExplorerCommandのサンプル（[https://learn.microsoft.com/ja-jp/windows/win32/shell/samples-explorercommandverb エクスプローラーコマンド動詞のサンプル - Win32 apps | Microsoft Learn]）を使ってみたが、IExplorerCommandState（CommandStateHandler）のほうは動作しているように見えるものの肝心のIExplorerCommand（ExplorerCommandHandler）は全く反応しなかった（右クリックを一度でも行うとdllへの上書きアクセスが禁止されるので読み込まれてはいるようだが、コンストラクタや<code>QueryInterface</code>にデバッグ用のメッセージボックスを入れても表示されない）。

==== サブメニュー ====

IContextMenuは自由度が高いのでサブメニューなども実装できるはず（7-Zipなどもそうしていると思われる）。またこのような記事もあった: [http://nonsubject.arinco.org/2014/06/cascading-desktopbackground-menus.html デスクトップのシェルメニューをサブメニューにする | Nonsubject]


=== Windows11の右クリックメニューへの追加 ===

これはどうやらますます面倒になりそうで、リリース済のWindowsストアアプリをインストールするか開発者モードを有効にしないと自分の好きなメニューを追加できない（多分）上、アプリ1つにつき1メニューしか追加できないらしい。

<ul>
<li>Windows 11の右クリックメニューに追加してくれるソフト
[https://github.com/ikas-mc/ContextMenuForWindows11 https://github.com/ikas-mc/ContextMenuForWindows11]
フォルダ背景を右クリックしたメニューに追加できない（[https://github.com/ikas-mc/ContextMenuForWindows11/issues/44 https://github.com/ikas-mc/ContextMenuForWindows11/issues/44]）（いや、使ってみたら普通にできてるっぽい？）、アプリ1つにつき1メニューしか追加できない（[https://github.com/ikas-mc/ContextMenuForWindows11/issues/45 https://github.com/ikas-mc/ContextMenuForWindows11/issues/45]）（これはWindows側がそういう仕様っぽいので厳しそう）</li>
<li>Microsoftの関連するサンプル 
[https://github.com/microsoft/AppModelSamples/tree/master/Samples/SparsePackages AppModelSamples/Samples/SparsePackages at master · microsoft/AppModelSamples]</li>
<li>Meryへの追加要望
[https://www.haijin-boys.com/discussions/6746 Windows 11の新コンテキストメニューにMeryのコマンドを追加したい]</li></ul>


== 解決策①COMを利用する ==

{{Valuable}}

まずは、COMを用いて実装するという方法がある。基本的にはこちらが綺麗な解決策である。

IExecuteCommandというインターフェースを具体的に実装している[https://learn.microsoft.com/en-us/windows/win32/shell/samples-executecommandverb Microsoftのサンプル]があったので、それを参考に、「取得したファイル・フォルダの情報を引数または標準入力として渡しつつ指定されたコマンドを起動する」というプログラムを作成した。

[https://github.com/ge9/ExecuteCommand-Pipe https://github.com/ge9/ExecuteCommand-Pipe]

COMを使っていることからわかるように、コマンドラインを介さず直接Explorerからデータが送られてくるので、他の方法に共通してみられるパス長さやファイル個数の制限が（事実上）皆無であり、非常に強力である。

{{Stub}}

=== 使い方 ===

詳しい使い方は上記レポジトリのREADMEも参照。

==== 基本 ====

引数となる（実際に起動したい）コマンドはレジストリキー

<code>HKEY_CURRENT_USER\Software\Classes\CLSID\{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}\LocalServer32</code>の既定の値で設定する。

その上で該当メニューに対応する<code>command</code>キー（レジストリの各所にある）に<code>DelegateExecute</code>という値を作成して<code>{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}</code>を書き込むことで起動できる（<code>command</code>の既定値よりも<code>DelegateExecute</code>が優先される）。


=== IDropTargetを用いた実装 ===

IExecuteCommandではなくIDropTargetというインターフェースを用いてもほぼ同じことができそうであった。対応するサンプルは[https://github.com/microsoft/Windows-classic-samples/tree/main/Samples/Win7Samples/winui/shell/appshellintegration/DropTargetVerb https://github.com/microsoft/Windows-classic-samples/tree/main/Samples/Win7Samples/winui/shell/appshellintegration/DropTargetVerb]である。IExecuteCommandとの機能的な違いはあまりよくわからないが、[https://learn.microsoft.com/en-us/windows/win32/shell/samples-droptargetverb https://learn.microsoft.com/en-us/windows/win32/shell/samples-droptargetverb]を読む限り、DropTargetのほうが古くからあるようである。CLSIDの登録までは同じだが、<code>command</code>のかわりに<code>DropTarget</code>キーを使用し、<code>DelegateExecute</code>値のかわりに<code>CLSID</code>値を使う（ソースを読めばわかる）。

== 解決策②プロセス間通信で頑張る ==

{{Valuable}}

「プロセス間通信を使って頑張る」という方法もある。要するに、コマンドとしては別々に渡されたとしても、既に立ち上がっているプロセスがあるときはそちらに投げて終了するようにすれば、一つのプロセスでまとめて開けるというわけである。

この部分を代わりにやってくれるものとしては[https://github.com/zenden2k/context-menu-launcher https://github.com/zenden2k/context-menu-launcher]がある。これを少し改善したフォークとして[https://github.com/KnIfER/SingleInstance-Launcher https://github.com/KnIfER/SingleInstance-Launcher]があり、さらに自分が64bit版のビルドを加えたものが[https://github.com/ge9/SingleInstance-Launcher https://github.com/ge9/SingleInstance-Launcher]にある。

ただ、これはCOMを使う方法とは違っていくつかの欠点がある。

* ファイル個数の上限
** ProgIDを使って開く場合には、選択個数がデフォルトで15個までに設定されており、これはMultipleInvokePromptMinimum値（詳しくは他サイト）の変更により増やせるが確実ではない（上限に諸説あり）。
** 独自メニューの場合は、"MultiSelectModel"を"Player"にすることでファイル数上限が100個になるが、それより大きくはできない。
* 長さ制限（260文字）を超えるパスをもつフォルダでは失敗する（詳しくは[[Windowsのパス長さ制限に関して|Windowsのパス長さ制限に関して]] を参照）。
* プロセス間通信を使っているため、起動時にラグがあったりすると、ごく稀に渡されたファイルの順番が乱れることがある。


=== SingleInstance-Launcher - 基本的な使い方 ===

上記GitHubリポジトリから実行ファイルをダウンロードしてどこか分かりやすい場所に置く。インストールなどは不要である。筆者がリリースした実行ファイルを信用できない・改変したいなどの場合はソースコードをどうぞ。言語はC++。ファイルの順番が乱れにくくなる改善など大歓迎。

README.mdにもあるが起動に用いる基本的な構文（レジストリに登録する値）は以下のようである（※ここでは64bit版を使うものとして説明しているが、32bit版でも全く同様）。

<syntaxhighlight lang="c">"C:\path\to\singleinstance_x64.exe" "%1" "C:\Program Files\path\to\app.exe" "$files" --si-timeout 1000 --option-to-app-1 --option-to-app-2</syntaxhighlight>
"C:\path\to\singleinstance_x64.exe"、"%1"、"C:\Program Files\path\to\app.exe"、"$files"の順番はおそらくこの通りである必要がある。その後にあるものはapp.exeにオプションとしてそのまま渡されるが、<code>--si-timeout n</code>に限り、singleinstance_x64.exeが解釈し、app.exeに渡されない。このオプションはSingleInstance-Launcherに対して次のファイルが渡されてくるのを待つタイムアウト期間をミリ秒で指定するものである。短すぎると、右クリックメニューの処理が遅い場合に途中で打ち切られてしまう可能性がある。長すぎると、その期間待つまでapp.exeは呼ばれないため、タイムラグが長く不便に感じる可能性がある。特に動作が重いPCでなければ1000（1秒）くらいにしておけば十分だろう。もう少し短くてもいいかもしれない。

%1や$filesの両側にダブルクォーテーションがないと、空白を含むファイル名を正しく扱えない。GitHubのサンプルでは付いていないものもあるので注意。
[[Category:IT]][[Category:Windows]]{{#seo:|title={{FULLPAGENAME}} - Turgenev's Wiki}}

デュアルブート

2025-09-01T01:32:05Z

Turgenev: Notion-MW

{{Outdated}}

WindowsとLinuxのデュアルブートにおいて役に立つ情報を記述する。古いメモを多く含む。[[Linuxのインストール|Linuxのインストール]]も参照。


== Windowsのプロダクトキー関連 ==

{{UnderConstruction|デュアルブート}}


== Bitlocker ==

とにかく前もって回復キーを保存しておくこと！！逆に回復キーさえあればBitlockerで大きなトラブルになることは多くない。

* [https://www.pcdock24.com/blog/?p=53931 BitLockerとは【BitLockerの要件と自動有効化の問題点】｜パソコン修理パソコンドック24] によるとローカルアカウントでBitlockerの有効/無効を確認するときはdiskmgmtから行かなきゃいけないらしい。
* Bitlockerを有効にしたあとにwinを起動すると再起動ループにハマることがある。解決法(Manage-bdeを使う)→[https://community.spiceworks.com/how_to/124388-stop-a-bitlocker-boot-loop Stop a BitLocker boot loop - Windows Forum - Spiceworks]


== Windowsパーティション（NTFS）のマウント ==

{{Outdated}}

==== remove_hiberfileについて ====

マウントが成功するにはWindowsが完全シャットダウンされている必要がある（またはそれが望ましい）。ただ、[https://unix.stackexchange.com/questions/107978/cant-access-windows-drive-windows-is-hibernated-refused-to-mount https://unix.stackexchange.com/questions/107978/cant-access-windows-drive-windows-is-hibernated-refused-to-mount]にある通り、windowsを正しくシャットダウンしてもなぜか「ハイバーネートされててマウントできません」的なのが出ることがあるので、マウントオプションにremove_hiberfileを追加するとよい。

* 高速スタートアップを無効にしているにもかかわらず完全シャットダウンされていないことがある気がしたので、Windowsでシャットダウン時に実行するスクリプトとして完全シャットダウンコマンドを追加したりした
* デスクトップPCではだいたい不要？


=== Bitlocker無し ===

普通にntfs-3gを使う。数字など適宜読み替えること。主にWindowsのDドライブ想定。

<ul>
<li>コマンド例
<syntaxhighlight lang="javascript">ntfs-3g -o remove_hiberfile /dev/nvme0n1p5 /media/win</syntaxhighlight></li>
<li>fstabの例
<syntaxhighlight lang="javascript">/dev/sda2 /media/ddrive ntfs-3g noauto,rw,nofail 0 0</syntaxhighlight></li></ul>


=== Bitlocker有り ===

ntfs-3gの前にDislockerで暗号化を解除する。参考→[http://www7390uo.sakura.ne.jp/wordpress/archives/270 http://www7390uo.sakura.ne.jp/wordpress/archives/2]

dislocker-fileの方式だと一旦復号したのをファイルに書き出して静的にマウントするので、（事実上）readonlyとなる。よってdislocker-fuseを使う→[https://www.systutorials.com/docs/linux/man/1-dislocker-fuse/ https://www.systutorials.com/docs/linux/man/1-dislocker-fuse/]

<ul>
<li>コマンド例
<syntaxhighlight lang="vb.net">$ sudo dislocker-fuse -V /dev/nvme0n1p3 --recovery-password=xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx -- /media/dl-fuse
$ sudo mount -o loop,rw /media/dl-fuse/dislocker-file /media/win/</syntaxhighlight></li>
<li>fstab例
<syntaxhighlight lang="vb.net">/dev/nvme0n1p3 /media/bitlocker fuse.dislocker recovery-password=xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx 0 0
/media/bitlocker/dislocker-file /media/win10 ntfs-3g rw,nofail,remove_hiberfile,permissions 0 2</syntaxhighlight>
と、二行に分けて記載する。
<ul>
<li>permissions については後述</li></ul>
</li></ul>

==== セキュリティ問題 ====

recovery-passwordを暗号化されていないパーティションに書いてしまうと結局Bitlockerの意味が全くなくなってしまうので、Linux側でもBitlockerのような暗号化パーティション（LUKSとか？）やユーザーログイン時に復号される暗号化フォルダ（ecryptfsとか）といったディスク上で暗号化される領域に書いておく必要がある（もちろん毎回パスワードの類を打ち込むのでよければそれでもいい）。


=== permissions, inheritについて ===

[https://github.com/tuxera/ntfs-3g/wiki/File-Ownership-and-Permissions https://github.com/tuxera/ntfs-3g/wiki/File-Ownership-and-Permissions] 詳しくはこちらも参照。

まず、マウントオプションとしてpermissionsを指定しない限り、ntfs-3gでマウントしたファイルは全てパーミッション・所有者が固定（uid, gid, umaskなどで指定）となり、個別のファイルについて変更することはできない。

そして、この場合、ntfs-3g経由で作成したファイルはWindows側で見るとすべてAdministratorの所有となり、さらにEveryoneにフルコントロール権限が付与される（この動作を変更するのは筆者の知る限り不可能）。

Linuxではフォルダの実行権限（x）が無ければその中に含まれたファイルにはアクセスが通らず、パスを推測することも不可能だが、Windowsではたとえ一切権限のないフォルダであっても中にあるファイル・フォルダのパスがわかれば直接パスを打つことでアクセスが通ってしまうようである（試した限り）。そのため、permissions無しでntfs-3gで作成したファイルはパスさえわかればWindows上の全ユーザーが閲覧・編集・削除できる状態ということになる。

従って、Gitを使用する場合や複数ユーザーで使用したい場合などパーミッション管理が必要なデータを扱う場合はもちろん、単に中にあるデータを保護したいという場合でもpermissionsオプションを指定することが必須になる。

次に、permissionsを指定して、かつUserMappingを指定しない場合、Linux上でrootが所有するファイルをWindows側で見ると、全てAdministratorsの所有物になり（ここはpermissionsがない場合と同じ）、そのアクセス権はLinux上での見え方と概ね一致するように設定されるようである。他のユーザーが所有するファイルにはS-1-5-21-3141592653-589793238-462643383-10000というような上位桁が円周率に由来する（この部分はハードコードされている）SIDが割り当てられ、こちらもアクセス権が適切に設定される。UserMappingを指定することで、このSIDの部分の割り当てを変更することができる。

Windowsに挙動を近づけるための他のオプションとしてはinheritというのもあり、これは新規作成時に上位フォルダの権限を継承するものである。しかし、これは所有者を継承するオプションではない（そして、所有者が違えばまともに継承もされない）。

* [https://github.com/tuxera/ntfs-3g/issues/90 https://github.com/tuxera/ntfs-3g/issues/90] では、UserMappingがなくても所有者が継承されるようになるパッチが示されているが、これを使うとpermissionsは動かなくなる（chmodなどが使えない）。自力で変えようとしてみたが、うまくいかなかった。

以上のことから、Windowsの一般ユーザーフォルダの内容などをLinuxから良い感じに（Windows側の権限設定を汚染せずに）使えるようにするには、明示的なUserMappingが事実上必須であることがわかる。

一方で、Administrator所有・全ユーザー閲覧可能（あるいは不可能）、といった、Windows側の全ての一般ユーザーに対して共通のアクセス権を適用する設定であれば、UserMappingを使用しなくても簡単に設定が可能である。個人用PCかつ、画像・動画などのメディアファイルやLinuxでしか使用しない大きめのソフトウェアを入れておく用途であれば、こちらで問題ないだろう。

Linux側で別ユーザーの所有に見せたい場合は、上記のS-1-5-21-3141592653-589793238-462643383-10000のようなSIDが見えてしまう状態でもよければ（かつ、権限設定にも問題がなければ）それでもいいし、下記のbindfsと併用する方法もある。いずれにしても、Linux側で全員が読み取り・書き込み・実行が可能なファイルは、Linux側での親フォルダの権限によらず、Windows側では（パスさえわかれば）対応する権限でアクセスができてしまうということに注意が必要である。

また、Windowsではファイルの新規作成時には必ず実行権限が付加されるので、Linux側でそれを見た場合も実行可能になる（実行権限を外すと.exeなどが実行できなくなる）。従って、GitのレポジトリのフォルダをWindows/Linux間で共用するようなことをすると、Windows側では実行権限無しで（これがデフォルトであるため）コミットされたファイルがLinux側では実行権限有りに見えるため差分が出てしまうといったことが発生する。これはUserMappingでも解決はできないので、Gitリポジトリのあるフォルダを共用するのは不可能である。

結局、後述のbindfsと組み合わせると、以下のようにするのが良さそう。

<ul>
<li>大元のntfsパーティションは、permissionsでマウント。UserMappingを使ってもよい。</li>
<li>Linux側でパーミッションを変更できる必要がなく、Windows側と共用したいものについては、bindfsで再マウントし、create-with-perms=a+rwxによってWindows側でアクセスに制約が出ないようにする。
<ul>
<li>より完全なオプションとしては、以下のような感じ？
<syntaxhighlight lang="javascript">map=root/myname:@root/@myname,perms=a+rwx,create-with-perms=a+rwx,chown-ignore,chgrp-ignore,chmod-ignore</syntaxhighlight></li></ul>
</li>
<li>Gitのようにパーミッションを変更できる必要があるものは、改めてこれも別のbindfsとして再マウントする。</li>
<li>あるいはbindfsを1つにまとめてcreate-with-perms=+rw（xは指定しない）にするのもいけるかもしれないが、本当にうまくいくかどうか…</li></ul>

==== bindfs ====

既存のディレクトリを、所有ユーザーやパーミッションを変更してマウントしてくれる。

<syntaxhighlight lang="python">sudo bindfs --mirror=myname --force-group=myname /media/win ~/.mnt_win/</syntaxhighlight>
または

<syntaxhighlight lang="python">sudo bindfs --force-user=myname --force-group=myname /media/win ~/.mnt_win/</syntaxhighlight>
この2つの違いは不明

作成した

sudoがないと<code>fusermount: option allow_other only allowed if 'user_allow_other' is set in /etc/fuse.conf</code>とか言われたりする

fstabの例

<syntaxhighlight lang="python">/media/win /home/myname/.mnt_win fuse.bindfs nofail,map=root/myname:@root/@myname,create-with-perms=g-w 0 0</syntaxhighlight>
Linuxだとrootのデフォルトのumaskが022で一般ユーザーが002なせいで一般ユーザーが作ったファイルが775とか664になってしまったりするがg-wをつけることによって755とか644になる（もちろんchmodすれば変えられる


== Minecraft ==

.minecraftフォルダをWindowsとLinuxで共有したはいいが、（それ自体.minecraftの中にある）ゲームディレクトリの指定も共有することを考えると、両OSでパスの仕様がやや異なるのが問題になる。

例えば以下ではWindowsのルートが/media/winにマウントされているとする。

まずLinuxのランチャーは相対パスどころかシンボリックリンクすら変換して普通の絶対パスにしてしまう（設定を書き換えてしまう）っぽいので、linuxでは絶対パス指定で/media/win/Users/pathのようにする。で、この書き方をするとWindowsでは相対パスと解釈されるのだが、基準となるフォルダが謎で、「PLAY」を押した時のチェック時は.minecraftが基準なのだが、実際に見られるのはランチャーがあるフォルダが基準（＝こっちになかった場合ゲームディレクトリが新たに作られる）

* ストアアプリ版の（新しい方の？）Minecraftランチャーでは、この「ランチャーがあるフォルダ」は<code>AppData\Local\Packages\Microsoft.4297127D64EC6_8wekyb3d8bbwe\LocalCache\Local</code> あたりである。

従って、ランチャーのフォルダと.minecraft内の両方にmediaというフォルダを作って中にwinという名前でC:\へのジャンクション置くとうまくいく。

.minecraftの中にはゲームディレクトリ専用のフォルダを作り、その中にmain, snapshotなど用途に応じたフォルダを作っておくとよい

== google-drive-ocamlfuse ==

labelを使うと複数アカウントをマウントできる。デフォルトのラベル名はdefault

しばらく使っていないと起動時におそらく認証の失敗が原因でマウントポイントのあるフォルダに対するlsがしばらく一切反応しなくなる（~/.gdfuse内の該当ラベル名のフォルダを削除して最初からやり直せば治る）。よってマウントポイントをホームディレクトリ直下に作るのは避けたほうがよい（gdfというフォルダを作っている）。


== MEGA ==

Winが完全にはシャットダウンされていない状態でLinuxを起動するとCドライブ上のMEGAのフォルダが読めずに同期が無効になってしまう。MEGA自身のかわりに、Cが読める状態でのみMEGAを起動するシェルスクリプト（mega-mounted.sh）をスタートアップに登録しておく。Cが読めなかった場合にはdialogコマンドで通知ダイアログを表示する。（このスクリプトではC自身のかわりにC:\Windowsをみている）（gdialogは一部のディストリにしか入っていないかもしれない。実際にコマンド打ってみてどんな表示になるかも含めて確かめておいたほうがよい）

<syntaxhighlight lang="shell">#!/bin/sh
if [ -d /media/win-rw/Windows ]; then
megasync
else
gdialog --title "Warning" --infobox "MEGAsync is not started because Windows partition is not mounted" 0 0
fi</syntaxhighlight>

== Bluetooth機器 ==

同じBluetooth機器を同じPCのWindowsとLinux双方にペアリングするというもの。自分はマウスでしかやったことがない。意外と難しいが何とかなる。

==== 参考 ====

* [https://orumin.blogspot.com/2019/02/bluetooth.html https://orumin.blogspot.com/2019/02/bluetooth.html]
* [https://qiita.com/yoko-yan/items/9b0235678fd804b4fe0d https://qiita.com/yoko-yan/items/9b0235678fd804b4fe0d]
* Bluetooth Low Energyという仕様もあるらしく、自分のマウスはこっちだった。これに関しては[http://aimingoff.way-nifty.com/blog/2018/09/windows-linux-b.html http://aimingoff.way-nifty.com/blog/2018/09/windows-linux-b.html]を参照。割と情報が少ないので感謝。
** <code>HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTHPORT\Parameters\Keys\xxxxxxxxxxxx</code>を見るためにpstoolsをダウンロードして<code>PsExec64 -s -i regedit</code>とする必要があることに注意。なお、セキュリティソフトによってPsexecが脅威と見なされ強制削除されてしまうときは代わりにフリーソフトのAdvancedRunを使うとよい。
** まとめ
*** CSRKをLocalSignatureKey
*** LTKをLongTermKey
*** EDIVをEdiv（16進→10進に変換）
*** ERandをRandに（バイト(2文字のかたまり)をすべて逆順にしてから10進変換）。ちなみにこれを間違えた結果、マウスを動かすたびにbluetoothアイコンが白↔黒と高速で切り替わる謎のバグっぽい現象が起こったことがあった。
*** 小文字を大文字に変える必要はない。また、IRKをIdentityResolvingKeyに書くのも不要。


==== マルチデバイス対応マウス（Logicool） ====

マルチデバイス対応（切り替えボタンがあるやつ）のマウス（LogicoolのM595）を使ったら、登録情報を一旦削除して再接続するごとにMacアドレスがひとつインクリメントされて困った。Linuxで接続→Winで接続→Linuxで上記の書き換え、とやったあと、フォルダ名を変更（1を足せばよいはずだが正確にはWinの情報を見るのがよい）するとうまくいった。[https://twitter.com/e9g/status/1381111849664409600 自分のツイート]にも記録あり
[[Category:IT]][[Category:Windows]]{{#seo:|title={{FULLPAGENAME}} - Turgenev's Wiki}}

Windowsにおける仮想的ディスプレイ

2025-09-01T01:31:55Z

Turgenev: Notion-MW

例えばZoomでプレゼンテーションをするときに、PowerPointの「発表者ツール」を使いたければ、普通は2つのディスプレイが必要である。しかしディスプレイが常に2つあるとは限らないので、画面共有に使用するだけの「仮想的なサブディスプレイ」があればいいのではないか、という発想がうまれる。他には、リモートのみで使用するPCや、ゲーム画面の配信などにおいても需要があるようである。


== 解決策1 - ダミープラグ ==

そこそこ普及している、ハードウェア的な解決策である。端子に差し込むとディスプレイが接続しているものと誤認させることができる。EDIDエミュレータとも呼ぶ？価格は500-1000円程度。4K対応かどうかなどスペックにより値段に多少の差はあるだろう。近年はHDMIが主流と思われるが、VGAのものもある（こちらは自作が可能との情報も）。

金はかかるが、後者の解決策にないメリットとして、一気に複数のOSに対応できる（製品による？）というのがある。


== 解決策2 - ソフトウェア的に ==

しかしPCを騙すためだけの虚構的な存在に金を払うのも考えれば面白くない話である。ソフトウェア的に解決できないだろうか。ということでこの記事ではWindowsに対するソフトウェア的解決策を紹介する。なおLinuxについてはxvfb?だとか、そういうのを使えばできそうな気がしたが今のところ手元ではできていない。できたら記事を書くかも。Macは持っていないので試せないが、[https://github.com/tSoniq/displayx https://github.com/tSoniq/displayx]とか、betterdisplayとかがあるらしい。PowerPointやゲーム実況という用途を考えるとWindowsが一番需要が大きそうではある。

ソフトウェア的解決策が欲しいといってすぐソフトが出てくればいいが、調べてもあまり出てこない。比較的それっぽくて怪しくなさそうだったのが

[https://www.amyuni.com/forum/viewtopic.php?t=3030 https://www.amyuni.com/forum/viewtopic.php?t=3030]

だが、それでもやはりちょっと素性が知れない。もう少し調べていくと、Indirect Display Driver (IDD)という技術を使うとそういうソフトウェアが書けるというMicrosoftのドキュメントが出てきた。そこからさらに調べてみるとこんなものがあった。

[https://github.com/roshkins/IddSampleDriver https://github.com/roshkins/IddSampleDriver]

これを試したら無事動いたので、ついでに解像度を変えてみたら、普通に8Kくらいまで動いた（ただしその分重くなる）。↑のレポジトリでも解像度増やしてというissueがあったので、forkして公開した。さらにver0.0.1.2では"C:\IddSampleDriver\option.txt”というファイルを設定することで解像度オプションやディスプレイの個数をユーザーが設定できるように変更した。

[https://github.com/ge9/IddSampleDriver https://github.com/ge9/IddSampleDriver]

本家のreadmeで紹介された結果、どうやらゲーム配信関係のRedditとかに載ったみたいで、実質的にはほぼ何もしていないのに800以上のstarを獲得している。

また、さらにこれをforkしたものとして[https://github.com/VirtualDrivers/Virtual-Display-Driver https://github.com/VirtualDrivers/Virtual-Display-Driver]が作られ、これはすでに5000starを超える大きなプロジェクトになっている。

* こちらはHDRにも対応していて積極的に開発されているので、今は基本的にはこちらを使ったほうがいいだろう。（以下の情報はIddSampleDriverなので古いかもしれない）

{{Outdated}}

以下、このソフトの話を主にしていく。

== インストール手順 ==

Scoopを使う方法と使わない方法の2種類がある。いずれもリポジトリのREADME.mdに書いてある通りで、それほど難しくはない。


==== Scoopを使う ====

筆者がかかわったものではないが、Scoopを用いてインストールができるようにしてくれた方がいるようである。インストールを行うスクリプトのソースコードは[https://github.com/ScoopInstaller/Nonportable/blob/master/bucket/iddsampledriver-ge9-np.json https://github.com/ScoopInstaller/Nonportable/blob/master/bucket/iddsampledriver-ge9-np.json]にある。

==== 通常のインストール ====

途中で、バッチファイルを用いて証明書（.cerという拡張子のファイル）をローカルコンピューターの「信頼されたルート証明機関」に登録する必要がある。そのバッチファイルではcertutilが使用されている（ちなみに以前のリリースではcertmgrが使用されていた）が、証明書を開いて表示される画面からの操作などによっても可能である。

登録を行わないと、デバイスマネージャで「このドライバーはデジタル署名されていません。」と警告が出て、最終的に「デバイスをインストール中にエラーが発生しました。」「ストアへドライバーを追加する際に問題が発生しました。」と言われて失敗する。

<ul>
<li>参考
[https://docs.microsoft.com/ja-jp/windows-hardware/drivers/install/installing-test-certificates https://docs.microsoft.com/ja-jp/windows-hardware/drivers/install/installing-test-certificates]
[https://garafu.blogspot.com/2014/04/blog-post.html https://garafu.blogspot.com/2014/04/blog-post.html]</li></ul>

== 開発者向け情報 ==

Indirect Display DriverについてはMicrosoft公式のドキュメントや公式サンプル[https://github.com/microsoft/windows-driver-samples/tree/master/video/IndirectDisplay https://github.com/microsoft/windows-driver-samples/tree/master/video/IndirectDisplay] を参照（IddSampleDriverはこれを編集してできたようである）。前述の通り自分は解像度を増やしただけなので技術的なことについては何もわかっていない。

公式サンプルはなんといっても公式のものであるから、まずはこれをビルドできる状態にするのが確実だろう。以下の説明は2021年8月頃にWindows10で試したときのものである。ビルドしようとするとWindowsUserModeDriver10.0がないと言われるので、[https://docs.microsoft.com/ja-jp/windows-hardware/drivers/download-the-wdk https://docs.microsoft.com/ja-jp/windows-hardware/drivers/download-the-wdk] を入れる。

すると次は「Spectre軽減策」（セキュリティ関係？）に関するエラーが出た。そこでVisual Studioのインストール時の「個別のコンポーネント」→「コンパイラ、ビルドツール、およびランタイム」のところから「最新」「（ARMではなく）x86とx64」と書いてある「Spectre軽減ライブラリ」を入れる（細かい表示は正確に記録していないかもしれないor変わっているかもしれない）。「SDK、ライブラリ、およびフレームワーク」にあるMFCとかATLみたいなやつは要らなさそうっぽい。

これでビルドが通った。exeを管理者権限で起動するとBluetoothのところのその他のデバイスとかに表示されるところまではいった。tmhがないとかSpectre関連のエラーとかwdfのエラーとか色々出ていたが全部大丈夫になった。

* [https://learn.microsoft.com/ja-jp/windows/win32/api/swdevice/nf-swdevice-swdevicecreate https://learn.microsoft.com/ja-jp/windows/win32/api/swdevice/nf-swdevice-swdevicecreate]に書いてあるように、SwDeviceCreateを呼びだすには管理者権限が必要である。従って、IddSampleDriverのようなソフトウェアをインストールするには管理者権限が事実上必須ということになる。ただし、インストールされたIddSampleDriverというデバイス自体は一般ユーザーでも使用可能である。

では次に本題のIddSampleDriverをビルドする。公式サンプルがビルドできている状況ならこちらも通るものと期待できる。少なくとも手元ではそうなった。逆にIddSampleDriverから始めてみても同様に、WindowsUserModeDriver10.0のエラー→Spectreのエラー、などとなった。

以下、当時の元リポジトリをビルドした際のメモ

* ソースコードに赤線は出ていたがコンパイルは通る。署名に関するエラー（file digestがなんとか）が出るのでプロジェクトのプロパティの下のほうのDriver SigningのFile Digest Algorithmに SHA256 と書く。
* 解像度やリフレッシュレートの設定が不適切だと、デバイスマネージャで何度か再読み込みされる感じの動作をしたあと自動的に停止され警告アイコンが表示される。
* 日付を超えるとタイムゾーン（筆者はJST=UTC+9）の関係でInf2Catが失敗する。プロジェクトのプロパティからInf2Catのメニューに行き、General → Use Local Time を「はい (/uselocaltime)」に設定する。参考: [https://monoist.atmarkit.co.jp/mn/articles/1307/26/news003_3.html https://monoist.atmarkit.co.jp/mn/articles/1307/26/news003_3.html]
** さらに、これを設定してもなぜか現地時間の21:00～24:00の間にビルドしたものは正常動作しなかった（ビルドは通るしデバイスマネージャでの警告アイコンも出ないのにサブディスプレイが出ない）ので、ビルド時はその範囲外になるようにPCの時計設定を適宜変更する（報告済み [https://github.com/roshkins/IddSampleDriver/issues/5 https://github.com/roshkins/IddSampleDriver/issues/5]）

自分でビルドしたやつのインストール時は、（おそらく自分のユーザー名を用いて署名が作られているため？）最初の一回のみ改めて.cerを登録する必要がある。二回目以降は、サブフォルダに生成されてるcat, dll, infをもってきて置き換えたあとデバイスマネージャから「ドライバーの更新」をすればよい。デバイスマネージャーは使ったフォルダをちゃんと覚えているようなので、頻繁に移動しなくていい安定した場所でビルドを行うのがいいだろう。


== HDR対応について ==

Virtual-Display-DriverのほうではHDRに対応している。

[https://github.com/VirtualDrivers/Virtual-Display-Driver/issues/32 https://github.com/VirtualDrivers/Virtual-Display-Driver/issues/32]や[https://github.com/roshkins/IddSampleDriver/issues/23 https://github.com/roshkins/IddSampleDriver/issues/23]で話題になっている通り、Windows 10ではHDRは動作しない。

* HDRの基本についてはここがよさそう？ [https://zenn.dev/okuoku/scraps/ca346768627367 https://zenn.dev/okuoku/scraps/ca346768627367]

=== その他参考情報 ===

このIDDというのはUser-modeで動作するやつなのだがKernel-modeで動作するKMDODとかいうものもあるらしく、そっちの方が多くのことができるのかもしれない。前述の両リポジトリのHDR関連issueでも言及されている。ただし調べた感じ、ただちに使えそうなものは見つからなかった。まあWindowsのディスプレイドライバなんか趣味でそうそう書くもんではないのでしょうがない。

一応適当に調べて出てきた参考リンクなど

* IDDとKMDODに関する議論（2019年） 
[https://community.osr.com/discussion/291368/wddm-display-only-driver-to-create-a-virtual-display-monitor https://community.osr.com/discussion/291368/wddm-display-only-driver-to-create-a-virtual-display-monitor]
* KMDODで仮想ディスプレイを作れるかどうかについて(2017年) 
[https://community.osr.com/discussion/286843/how-to-implement-virtual-display-adapter https://community.osr.com/discussion/286843/how-to-implement-virtual-display-adapter]
** そこで言及されているLin JiaBang氏のソフト（動作未確認） 
[https://github.com/LinJiabang/virtual-display https://github.com/LinJiabang/virtual-display]
* WDDMで仮想ディスプレイを作れるかどうかについて（2016年） 
[https://social.msdn.microsoft.com/Forums/vstudio/ja-JP/2d60c1c2-5198-47e2-b5d9-2ba28461e72e/how-to-implement-virtual-display-adapter-driver-on-windows-10?forum=wdk https://social.msdn.microsoft.com/Forums/vstudio/ja-JP/2d60c1c2-5198-47e2-b5d9-2ba28461e72e/how-to-implement-virtual-display-adapter-driver-on-windows-10?forum=wdk]

== 課題 ==

あくまで仮想的なディスプレイであるからその中身を目視で確認することはできない（ただし別途その内容をウインドウに表示するソフトなどは作れそう）。従って例えば、これを使って共有している間にZoomのミーティングコントロールが非表示になってミュートのon/offなどができなくなるなどの不便さはある。

ちなみに、Windowsでのマルチモニター管理を切り替えるメニューのショートカットはWin+Pであるが、ここで「セカンドスクリーンのみ」を選ぶなどして仮想でないほうのディスプレイが真っ暗になってしまったときはWin+Pを押せば復帰できる。

== 変更記録 ==

もともとディスプレイは5個追加されるが、重過ぎるのでNUM_VIRTUAL_DISPLAYSを1に変更。

解像度を大きくしたいのでソースコードを「1920」で検索し、3840x2160と2560x1440を追加する。

まず s_KnownMonitorModes のところ。この際リフレッシュレートが60HzになるようにPixel Clock Rateをちゃんと計算する必要がある。

<syntaxhighlight lang="c++">{
229008 * KHZ, // pixel clock rate [Hz]
{ 229008 * KHZ, 2560 + 40 }, // fractional horizontal refresh rate [Hz]
{ 229008 * KHZ, (2560 + 40) * (1440 + 28) }, // fractional vertical refresh rate [Hz]
{ 2560, 1440 }, // (horizontal, vertical) active pixel resolution
{ 2560 + 40, 1440 + 28 }, // (horizontal, vertical) total pixel resolution
{ { 255, 0 }}, // video standard and vsync divider
DISPLAYCONFIG_SCANLINE_ORDERING_PROGRESSIVE
},
{
509366 * KHZ, // pixel clock rate [Hz]
{ 509366 * KHZ, 3840 + 40 }, // fractional horizontal refresh rate [Hz]
{ 509366 * KHZ, (3840 + 40) * (2160 + 28) }, // fractional vertical refresh rate [Hz]
{ 3840, 2160 }, // (horizontal, vertical) active pixel resolution
{ 3840 + 40, 2160 + 28 }, // (horizontal, vertical) total pixel resolution
{ { 255, 0 }}, // video standard and vsync divider
DISPLAYCONFIG_SCANLINE_ORDERING_PROGRESSIVE
},</syntaxhighlight>
のようにする。Pixel Clock Rateの数値は多少のズレがあってもいいみたい？だけど気分的に少しだけ大きめに設定してある。

そのすぐ下のEDIDのところはそのままでよさげ。

そして、一番下のほうのTargetModesのところを変える。配列サイズの変更も忘れずに。いやvectorだから関係ないか。

ちなみにs_KnownMonitorModesがノータッチだとここには1920x1280までしか書けないっぽい。


== EDID編集に関して（メモ） ==

HDR機能の追加に使えるかと思ったが結局効果はなかった。

Deltacast E-EDID Editorがふつうに有能。ここに書いてあった: [https://ameblo.jp/holycater/entry-12467348533.html https://ameblo.jp/holycater/entry-12467348533.html]

[https://www.ninshoshiken.com/about-ajsc1-edid-editor/ https://www.ninshoshiken.com/about-ajsc1-edid-editor/]

[http://blawat2015.no-ip.com/~mieki256/diary/201602063.html http://blawat2015.no-ip.com/~mieki256/diary/201602063.html]

[http://www.edidreader.com/ http://www.edidreader.com/]
[[Category:IT]][[Category:Windows]]{{#seo:|title={{FULLPAGENAME}} - Turgenev's Wiki}}

Windowsでエクスプローラーからフォルダを各種ターミナルで開く

2025-09-01T01:31:51Z

Turgenev: Notion-MW

Explorerの右クリックメニューやアドレスバーからフォルダを各種ターミナルで開くための設定方法の紹介。cmd.exe, powershell（pwsh含む）, Cygwin, Git Bashの4つに対応。

== 基本 ==

* [[Windowsの右クリックメニューから複数ファイルをまとめて開く|Windowsの右クリックメニューから複数ファイルをまとめて開く]] のように、レジストリでフォルダ・フォルダ背景の右クリックメニューを編集できる。
** Windows10までの右クリックメニューに戻そう。
** <code>command</code>キーの既定値に直接コマンドを書く方法と、<code>DelegateExecute</code>値（など）を使ってCOMを通じて実行する方法（このために[https://github.com/ge9/ExecuteCommand-Pipe https://github.com/ge9/ExecuteCommand-Pipe]（使い方はレポジトリの説明を参照）を作った）がある。
** HKLMにあるマシン全体の設定は、それ自体は管理者権限（あるいはTrustedInstallerなどさらに上の権限）がないと書き換えられないが、HKCUに値があればそちらが優先されるので、自分だけに関する設定変更ならユーザー権限だけで可能である。
** <code>Directory</code>や<code>Directory\Background</code>の直下に<code>runas</code>という名前でキーを作った場合は、自動的に<code>command</code>の内容が管理者権限で実行される。ただ、<code>runas</code>という固定のただ一つの名前しか使えないため、例えば管理者としてコマンドプロンプトを開くメニューとPowerShellを開くメニューを共存させることができない。そのためこの記事では<code>runas</code>キーを使用するのではなくコマンドの中で明示的に管理者としての実行を行っている。
* Explorerのアドレスバー（address bar, location barなど）にcommandと入力してEnterを押すと、そのフォルダをカレントディレクトリとして<code>command</code>というコマンドが実行される。
** このアドレスバーの仕様はおそらく「ファイル名を指定して実行」とほぼ同じ。<code>command</code>で（メインとして）指定するファイルはフルパスなら必ず動作し、Pathが通っているまたはApp Pathsに登録されているならファイル名だけでよく、さらにbatやexeの場合は拡張子も省略できる。さらに、ほとんど知られていないが実はApp Pathsの値には実行ファイル以外も書けるようである。
** つまり、パスの通っているフォルダにあるimage.pngはフルパスを打たなくても「image.png」で開けるし、さらにはApp Pathsの<code>openimage.exe</code>というキーにimage.pngのフルパスを書けば<code>openimage</code>と打つだけで（実際にはそのような実行ファイルは全く存在しないにもかかわらず）image.pngが開くようになる。当然、vbsなども拡張子無しで呼び出せることになる。

== ポイント ==

==== パス名のルール ====

* Windowsではパスの長さが260文字以下という制限がある。詳しくは[[Windowsのパス長さ制限に関して|Windowsのパス長さ制限に関して]] 参照。
** 制限を超えるような長いパスは<code>\\?\</code>というプレフィックスを付けて（UNCパスの一種として）扱われる。
*** このようなフォルダをカレントディレクトリとしてコマンドを実行することはできないので、アドレスバーに打ち込む方式は使えない（System32をカレントディレクトリとして実行される）。wt -dなどにも指定できない。
*** 右クリックメニューでは、commandの既定の値に直接書く方式の場合は、<code>NoWorkingDirectory</code>を設定しないと呼び出されなくなる。
*** シンボリックリンク/ジャンクションでパスを短くしてやれば普通に扱えるようになる
* 普通に入力できる文字でWindowsのファイル名に使えないのは、<code>\</code> <code>/</code> <code>:</code> <code>*</code> <code>?</code> <code>"</code> <code><</code> <code>></code> <code>|</code>の9個（エクスプローラーの画面で入れようとすると表示される）。
** その他、ヌル文字やタブスペースのような0x20未満の制御文字も使えない（はず）。
*** これらを含むファイルはGit Bash/Cygwinを使っても作れない。
*** NTFS自体の制限はおそらく<code>/</code>だけで、それ以外に関してはLinux上で作ってからWindowsで見ると見られることもある。中身の閲覧などは不可。
* また、末尾が空白またはピリオドのファイルも禁止で、Explorerやcmdでは作れない（自動で除去される）。
** これらはGit Bash/Cygwinなら作れる。前者はエクスプローラーで閲覧など多少の操作ができるが後者はほとんど何もできず、DelegateExecuteの右クリックメニューでもピリオドが外れた名前しか取得できない。
* 先頭が空白のファイルはExplorerだと作れないがcmdなら作れる。禁止ではないはず。


==== Git Bash/Cygwin ====

* Git BashではWindowsの実行ファイルにスラッシュ付きオプションを渡すときはスラッシュを2つにする必要がある。<code>cmd //c</code>や<code>bcdedit //v</code>など。
* printf関数の%qオプションを使うと、文字列をエスケープされた状態にして返してくれる。これはshからの呼び出し先の別のshで再びフォルダ名をcdなどの引数として利用したいときに使える。
** bash（POSIX互換ではない）の組み込みコマンドのprintfと、独立実行ファイル（GNU Coreutilsの一部）である/bin/printfがある。基本的な趣旨としては同一のコマンドだが、組み込みコマンドのほうは入力に<code>"</code>が含まれていない限り結果にも<code>"</code>が使われることはないようで、このおかげで意図しない動作を回避できることがある。今回扱う例に関しては前者が後者の上位互換であるということになる。後者を使っているものはそれでも動いたものである。
** そもそも%qは組み込みコマンドのほうにしかないという話もある。環境によって違いそう。
* <code>\\?\</code>が付くような長いパスをカレントディレクトリにしていても、Git Bash/Cygwinに付属の（というかMSYS/Cygwin向けにコンパイルされた？）exeなら実行できる。
* Git Bashの(ba)shは<code>--login</code>をつけて起動してもカレントディレクトリが維持されるが、<s>Cygwinの(ba)shは</s><s><code>--login</code></s><s>をつけると強制的にホームディレクトリに移動する。</s>
** 2024/4頃、Cygwinの挙動が変化し、カレントディレクトリが維持されるようになっていることに気付く。変わっていた方のバージョンは3.5.3、変わっていない方は3.3.6であった。
** ところで、[https://superuser.com/questions/345964/start-bash-shell-cygwin-with-correct-path-without-changing-directory Start bash shell (cygwin) with correct path without changing directory - Super User]の通り、<code>CHERE_INVOKING</code>という変数を1に設定しておけばカレントディレクトリは維持される。
* Git Bashにおいては環境変数を正しく設定するため<code>--login</code>の時点で環境変数<code>MSYSTEM</code>を<code>MINGW64</code>にしておく必要がある。[[Windowsでのターミナル環境|Windowsでのターミナル環境]] 参照。


==== powershell/pwsh ====

* バージョン5まで（Windows PowerShell）はpowershell.exe、6以降（PowerShell Core, PowerShell）はpwsh.exeと実行ファイル名が違う
** 以後、「powershell(.exe)」と「pwsh(.exe)」で呼び分ける。ただし手元ではpowershellの5.1とpwshの7.2～7.3くらいでしか試していないので、一部バージョンではまた違う可能性もある。
** pwshは必ずしもWindowsに標準では入っていないので、以下の例でもあまり依存しないように気を付ける。
** 基本、シングルクォートで囲えばほとんどの特殊文字が無効になり、シングルクォート自体を書くときは2つ並べる。ただし注意点として、驚くべきことにpowershell/pwshでは「全角のシングルクォート（U+2018-U+201B、<code>‘</code> <code>’</code> <code>‚</code> <code>‛</code>の4つ）」も通常のシングルクォートと同じ効力があるので、同じようにエスケープする必要がある（参照: [https://learn.microsoft.com/ja-jp/powershell/scripting/lang-spec/chapter-02?view=powershell-7.2 https://learn.microsoft.com/ja-jp/powershell/scripting/lang-spec/chapter-02?view=powershell-7.2]）。掲載したスクリプトでは省略しているがやることは同じ。
* powershell.exe
** -Commandがなくても付けたのと同じ扱いになる？
*** 逆に、-Commandを付けなければいけないという点を除いてはpwshがpowershellの上位互換という感覚である（新しいのでそれはそう）。
** <code>`</code>や<code>[]</code>を含むフォルダの扱いにバグがあり、cmdなどでこれらのフォルダをカレントディレクトリとした状態で5系のPowerShellを起動すると<code>C:\</code>や<code>C:\Windows\System32\WindowsPowerShell\v1.0></code>をカレントディレクトリとして起動される（たとえば<code>C:\somefolder][</code>なら前者、<code>C:\somefolder[]</code>なら後者）。
** -Fileを使用してスクリプトを実行するとき、ダブルクォーテーションで囲われていない <code>-</code> が引数に含まれているとエラーになるバグがある。
* powershell.exe・pwsh.exe共通
** 連続した<code>`</code>があるフォルダに関する挙動にバグがある。コンソールプログラムを実行しても新規ウインドウで開かれる、そこをカレントディレクトリとしたときにファイルをmvできないなど。
** <code>`</code>や<code>[]</code>を含むフォルダに関しても、絶対パス指定したりきちんとエスケープしたりすれば操作自体はできる（場合もある）。
*** エスケープはいずれも直前に<code>`</code>を付ける。
*** これらを特殊文字として扱いたくないときは<code>-LiteralPath</code>を付けると良い場合もある。
** UNCパスをカレントディレクトリにすることができるが、<code>Microsoft.PowerShell.Core\FileSystem::\\</code>とかいう謎のプレフィックスが付く。
** 末尾が空白のフォルダについてはcdできず、Cygwinなどでそのようなフォルダをカレントディレクトリとして起動したとしても<code>C:\Windows\System32\WindowsPowerShell\v1.0</code>や<code>C:\Program Files\PowerShell\7</code>に移動してしまう。
** 8.3形式のパスを強制的に長い名前に戻してcdしてしまう。その結果、長いフォルダをカレントディレクトリとして外部プログラムを実行できなくなる。
* PSModulePath環境変数の関係な気がするが、pwshの中でcmdを起動してその中でpowershellを起動したりするとPSReadLineモジュールが読み込めない（<code>PSReadline モジュールを読み込めません。コンソールは PSReadline なしで実行されています。</code>）とか言われたりする

==== 環境変数への置換 ====

cmdなどを使うと<code>%</code>で囲われた環境変数（<code>%PATH%</code>など）が置換される。<code>%</code>はファイル名にも普通に使える文字なので、注意が必要となる

* 該当の名前の環境変数が定義されていたときのみ置換が行われ、定義されていなければそのままになる。
* <code>%</code><code>VAR</code><code>%</code>の置換は必ずしもcmdだけで行われるわけではない。「ファイル名を指定して実行」、VBSのWscript.Shellのrun、conhost、wtの引数などでも行われる。しかしCreateProcessやShellExecute(Ex)やレジストリ値では行われない（無理やりREG_EXPAND_SZにしたら展開されるが、後述の<code>%V</code>との適用順などは不明）。
* 一般には、環境変数には英数字とアンダースコアしか使えないとの説明もよくあるが、実際にはほとんどの記号が有効である。従って、<code>^%PATH^%</code>のようなキャレットによるエスケープはcmd向けにはある程度有効だが、<code>PATH^</code>という環境変数が定義されているとうまく動かない。
* （そういう変数が定義されていることは現実にほとんどないだろうし、それが保証できるなら以下の部分を読む必要はない）

これを防ぐ方法はいくつかある。ちなみに、<code>%%</code>でのエスケープというのはバッチファイルの中だけの話で、今回の場面では以下より簡単なエスケープ方法は多分ないと思う。

<ol style="list-style-type: decimal;">
<li>既に定義されているかもしれない環境変数をバックアップし、一時的にその中身を<code>%</code>に変えて使用することでリテラル文字としての<code>%</code>を表現し、後で元に戻す。
すなわち、<code>MY_PERCENT</code>のような変数の中身をバックアップし、<code>MY_PERCENT</code>の中身を<code>%</code>に変え、未知の文字列中の<code>%</code>をすべて<code>%MY_PERCENT%</code>にすることでこの部分が置換によって<code>%</code>に変わるのを利用して<code>%</code>をそのまま渡すということである（環境変数の置換は左から順に行われるため、たとえば<code>%MY_PERCENT%PATH%MY_PERCENT%</code>の<code>%PATH%</code>が置換されることはない）。受け渡しが終わったら<code>MY_PERCENT</code>の中身を復元する。
これは、変数のバックアップとリストアを同じプロセス・スクリプト内で行える（呼び出した後に元に戻ってくる）場面で有用である。呼び出し先プロセスでリストアすることも不可能ではないと思うが、環境変数には任意の文字が入る可能性があることを考えるとエスケープが大変困難になることが予想される。</li>
<li>VAR1, VAR2, VAR3, …のような無限個の変数を最初からチェックし、最初の未定義の変数を上記と同様に使用し、後で未設定にする。
ほぼ上記と同じだが、内容のリストアでなく未設定にするだけなので、呼び出し先プロセスでも容易に行える。ただし実装が面倒である。</li>
<li><code>%</code>を<code>==%</code>へと置換して、置換のプロセスを抜けた段階で元に戻す。
<ul>
<li>これは、最初の文字以外に<code>=</code>が含まれる環境変数名は（実際に環境変数が設定されていたとしても絶対に）置換されないことがわかったためである。
<ul>
<li><code>%=%</code>（あるいは、<code>%=VAR%</code>など）は少なくともcmdの対話シェル上だと置換されてしまうので<code>=%</code>へのエスケープだと不十分に見えるが、実際には<code>=</code>一つでも問題なく動く場合もあった。</li>
<li>しかし、動かないときもあるので、多くの例では<code>==%</code>にエスケープしている。<code>=%</code>になっているものは、試した限りはそれでも問題なく動いているものである。</li>
<li>[https://learn.microsoft.com/en-us/windows/win32/procthread/environment-variables Environment Variables - Win32 apps | Microsoft Learn]では「<code>=</code>は環境変数に使えない」と書かれていて、ダイアログからでも設定はできないが、レジストリだと無理やり設定できる。
<ul>
<li>ユーザー環境変数に設定する分にはとりあえず問題なさそうだが、システム環境変数にレジストリから<code>=</code>（と、<code>=</code>を名前に含むいくつかの変数。どれが原因かは正確にはわからない）を無理やり追加したら0xc000021のブルースクリーンでWindowsが起動しなくなった（Linuxからchntpwで該当の変数を全て削除したら治った）のでこれはやってはいけない。</li></ul>
</li>
<li>ちなみに、<code>=</code>や<code>%</code>はUnix側では特殊文字ではないので、printfとの適用順はあまり気にする必要はない。</li></ul>
</li>
<li>この方法のメリットは、一度置換してしまえばその文字列を何度使いまわしても変化がないことが保証されることと、未定義の変数の探索や変数のリストアが必要ないことである。
<ul>
<li>要は<code>%(=を含まない文字列)%</code>を含まない文字列だけを値にとる単射を構成すればいいだけなので、base64エンコーディングのようにしても構わない。</li></ul>
</li>
<li>ただ、<code>==%</code>を<code>%</code>に置換するという操作はPowerShellやshにとっては容易でもcmdにとっては不可能に近いので、最終的な呼び出し先がcmdであるときには採用しづらい。</li></ul>
</li></ol>

また、今回の記事ではcmdやvbsのRunを経由してコマンドを実行しているものが多くあるが、このスクリプトの内容自体もエスケープが必要である。つまり、例えば<code>cmd /c</code>の内側に<code>$mypath.Replace('%','%MY_PERCENT%')</code>というPowershellコードが含まれるなら、<code>','</code>や<code>MY_PERCENT</code>という環境変数が定義されていた時にその部分が置換されてしまう。これを回避するのはそこまで難しくなく、この例であれば<code>$mypath.Replace('%'.Trim('='),'%'.Trim('=')+'MY_PERCENT%')</code>のように<code>=</code>を含む無意味なコードを挿入すればよい。また、<code>%</code>をいったん<code>==%</code>にしている部分に関しては、<code>==%</code>ではなく<code>==%==</code>にすることで問題を避けられるだろう。無駄に複雑になるのでスクリプト例ではそのような措置はしていない。

==== cmd ====

* UNCパス（<code>\\?\</code>だけでなく普通のUNCパスも含む）をカレントディレクトリにすることはできない（rdなど一部コマンドでの取り扱いは可能）。
* 末尾が空白のフォルダにcdすることはできないが、Cygwinなどでそのようなフォルダをカレントディレクトリとした状態でcmdを起動した場合は、そのフォルダをカレントディレクトリとして起動する（外部プログラムの起動はできないがcdなどの内部コマンドは有効で、一度でも出たら戻れない）。
* 各種のパース規則が本当に謎。特に引用符周りは地獄である。[https://thinca.hatenablog.com/entry/20100210/1265813598 cmd.exe のコマンドラインの仕様を解析してみた - 永遠に未完成]を読むとわかるが、例えば「ファイル名を指定して実行」で以下の挙動を確かめよう。
** <code>cmd /k echo "a b"c d"</code>→<code>"a b"c d"</code>と出る
** <code>cmd /k echo "a & b"c d"</code>→<code>"a & b"c d"</code>
** <code>cmd /k echo "a b"c & d"</code>→<code>echo "a b"c</code>と<code>d"</code>がそれぞれ別々に実行される
** すなわち、<code>"</code>が一見特殊文字でないかのような振る舞いをする（そのまま出力される）割に、その前後で特殊文字の扱いが切り替わっている。


==== Windows Terminal ====

* 以下、wtと略す（実行ファイル名がwt.exeなため）。パスが通っているものと仮定する。
* wtでは<code>;</code>が特殊文字になるようで、<code>\;</code>とエスケープが必要。[https://github.com/microsoft/terminal/issues/13264 https://github.com/microsoft/terminal/issues/13264] かな？
** <code>"</code>も<code>\"</code>にする必要がある。一方で、単一の<code>\</code>は（うしろに<code>;</code>や<code>"</code>などがなければ）そのまま<code>\</code>になるようである。大丈夫なのか…？
* 起動時にカレントディレクトリがユーザーフォルダ（%USERPROFILE%）になる
** <code>-d</code>オプションで明示的に指定することができる

==== 連続空白 ====

空白が連続するファイル名の対応は割と厄介である。Windows側では引数を<code>""</code>で囲うことで、またsh側では適宜<code>IFS=</code>と設定することで対処できる。


==== Unicode対応 ====

* UTF8を使おう
* <code>chcp 65001</code>が一応使えるが、一旦シェル内部に入らないと使えないのでやや不便
** 使わなくても大丈夫なときもある。あまりちゃんと理解できていないが、経験上、powershellで<code>$input</code>変数を用いて標準入力を受け取る際には<code>chcp 65001</code>が必要そう。
* /bin/printfやprintfの実行時には<code>LANG</code>を<code>en_US.UTF8</code>とかに設定する。
** Cygwinなら不要？

==== デバッグ時 ====

* 管理者権限のものを試すときでもまず<code>-Verb Runas</code>を外して動作確認するとよい。
* 後述のwaitrunも役に立つだろう。
* 特殊文字に関しては、最初は空白のないフォルダ、次に空白のあるフォルダや連続空白のあるフォルダ、次にシングルクォートや<code>%PATH%</code>を含むフォルダなどとだんだん難しくしていくとよい。
* それとは別に、Unicode対応、<code>C:\</code>（ドライブ直下）対応、259文字のフォルダ対応（後述）などをチェックする
* 難しい例は、例えば<code>z 𠮷𠮷%PATH% ' '' ` `` $PATH & && %%PATH%%[] ] [ ^ ^^ ' ; ;; 𩸽𩸽!PATH!#$%&'()=~{`+}_,.][;@^- - ‘ ’ ‚ ‛</code>のような感じ（適当）。こんなファイル名を現実に見ることはないが、エクスプローラー上で普通に入力できる内容である。
** 「𠮷」はBMP外かつJIS外の漢字としては最も変換で出しやすいのでテストに重宝する。（𩸽はBMP外だがJIS外ではない（第4水準））

==== その他 ====

* デフォルトシェルは、通常ユーザーはwtでも管理者の場合はconhostに設定されているっぽい？
* <code>C:\</code>のようなドライブ直下のパスは末尾に<code>\</code>を付けなければいけないことが多い。たとえばwt -dの引数にする場合など。またcmdでcdコマンドや<code>CD</code>環境変数を見るときもドライブ直下のときだけは<code>\</code>が付いて返ってくる。
** ただ、wt -d に<code>C:</code>が渡されるように見えるのになぜか動いているものもある。未調査。
* shやcmdなどの中に一旦入ってしまうと一部の環境変数などが書き換わってしまうかもしれないが、多少は許容することとする。
* コマンド例は網羅的でない可能性があり、色々な書き方を提示しようとあえて統一していないところもある。現実にはもっと簡単なやり方があるかもしれない。あくまで一例ということで。
* CygwinとGit Bashはほぼ同じなのでGit Bashを主に載せてCygwinは適宜差分のみ記述する。
* shは、特にベースのシェルとして使うにはエスケープの方式などでWindowsと相性が悪く使いづらい感じがする。逆にcmdは内部コマンドは地獄だがベースのシェルとしては意外と副作用が少なく、そう悪くはない。
* 以下の例ではCygwinやGit Bashの実行ファイルにはPATHを通していないことを想定している。<code>C:\cygwin64</code>あたりは適当に読み替えていただきたい。
* 2021年途中ごろまで、wtなどのストアアプリ系？の実行ファイル（Explorer上で0バイトになってるエイリアス）をGit Bashから実行できない（Permission deniedとなる）バグがあった。 [https://github.com/git-for-windows/git/issues/2675 https://github.com/git-for-windows/git/issues/2675]
* ネットワークドライブは各ユーザー対象に割り当てられているせいなのか、管理者として実行すると利用できないらしい。割り当てられる前のネットワークパス自体は有効。
* wtを管理者権限で呼び出すときに（確率的に）ウインドウが最前面にならないことがある。chcpの有無で変わったりするなど詳細不明。conhostだとならない気がする。startrunなどを介して実行すると必ず最前面に出るようになるっぽい。


== 準備: win-console-delegator ==

cmdやPowerShellやCygwinのbashなどのシェルを使えば、スクリプトを起動して複雑なコマンドを呼び出せたり、パイプ実行が可能になったりと色々便利だが、それだけのためには大仰すぎて、特殊文字の扱いなどがかえって仇になることもある。

そこで、シェル関連の操作に汎用的に使えるコマンドをいくつか作成して公開した。[https://github.com/ge9/win-console-tools https://github.com/ge9/win-console-tools]

* 以前はC++で書いていた（[https://github.com/ge9/win-console-delegator https://github.com/ge9/win-console-delegator]）が、C#のほうが文字列の扱いなどが簡明。

ただし、これはあくまで筆者が独自に作ったものであり、Windows標準のもので何とかしようとするのが面白いところでもあるので、それほど積極的には使わない。今後出てくる例はすべて、これらを一切使わなくても（余計な環境変数が設定されてしまうかもしれないという点をのぞけば）同等の機能が実現できる。

<ul>
<li>runother
与えられた引数を特定の文字列とつなげて実行してくれるプログラム。この実行ファイル自体の名前を適宜変更して使用し、「特定の文字列」は別のファイルから読ませる。使用例は[[Windowsでのターミナル環境|Windowsでのターミナル環境]] を参照。</li>
<li>runother-gui
runotherとほぼ同じだが、コンソールアプリケーションではなくWindowsアプリケーション（黒いウインドウが出ない、cmd上で実行したときに終了待ちが行われないなど）。</li>
<li>evalrun
与えられたコマンドラインを実行し、その出力をそのままコマンドラインとして実行するコンソールアプリケーション。（テキストファイルからのコマンドラインの読み込みなどに使える）</li>
<li>startrun
与えられたコマンドラインをWindowsのデフォルトシェルで起動するだけのWindowsアプリケーション。</li>
<li>waitrun
与えられたコマンドラインを実行したあとキー入力を待ってから終了するコンソールアプリケーション。一瞬でウインドウが消えてしまうときのデバッグに使いやすい。</li>
<li>hiderun
コンソールウインドウ非表示の状態で与えられたコマンドを実行するWindowsアプリケーション。（GUIアプリケーションなどを与えた場合は非表示にならないかも）
vbsのvbHideでも非表示にできるが、コンソールウインドウの表示位置をみると非表示のウインドウが一つ挟まっていることが分かるのに対して、こちらの場合はそうならない。</li>
<li>piperun
与えられたコマンドラインを最初の<code>|</code>とそれ以降の2つに区切ってそれぞれコマンドとしてパイプでつなげて実行するコンソールアプリケーション。ただし最初のコマンドのほうに<code>|</code>自体を入力したいときは<code>||</code>でエスケープする。また2つ目のコマンドの先頭の空白は除去される。</li>
<li>piperunex
piperunと似ているが、2つだけでなく3つ以上の任意個のパイプ実行を一度に行う。一見便利だが、コマンドの後ろ側に未知の文字列が渡される場合、<code>|</code>をエスケープする必要が生じる。
<code>piperun piperunex command1 || command2 || ... || commandN | unknown_commandline</code>のように外側を<code>piperun</code>で囲うと安全。</li>
<li>adminrun
与えられたコマンドラインを管理者として実行するWindowsアプリケーション。<code>ShellExecuteEx</code>では実行ファイルパスと引数は別々に指定しなければいけないので最低限の引数の解析を行っている。PowerShell経由で管理者権限で実行するときのような面倒なエスケープが全て不要になるため非常に使いやすいが、この記事ではこれに依存しないようにする。
<ul>
<li>ちなみにこういうのもある。[https://github.com/mattn/sudo mattn/sudo: sudo for windows] これは、通常のUACのように別ウインドウで実行するのではなく、localhostのランダムなポートを使い、自分自身にポート番号を渡しつつ管理者権限で呼び出すことで標準入出力を転送し、元の端末でそれを読み書きできるという点で、linuxのsudoに近い。しかし標準入出力を介しているので、<code>cmd /c for /?</code>や<code>cmd /c pause</code>の挙動が変わってしまうという問題がある。また、呼び出し元でchcp 65001をしていると文字化けする。また、コマンドライン引数を一旦配列に分割してから組み直しているので情報が一部落ちている。あと、セキュリティ的にも懸念があるかもしれないが、これはそもそもLinuxのsudo自体がまずどうなの？という気持ちになった。（未解決）（参照: [https://twitter.com/e9g/status/1687385469921931264?s=20 https://twitter.com/e9g/status/1687385469921931264?s=20]）</li></ul>
</li>
<li>uacrun
startrunと同じだが、コンパイル時のマニフェスト設定でこのプログラム自体の実行に管理者権限を要求するようにしたので、adminrunと同じように使える（管理者権限で実行する対象が渡されたコマンドではなくuacrun自体になるという違いはある）</li>
<li>pecho
与えられたコマンドライン引数をそのままコンソールに出力する。→WindowsでUnicode文字（特にU+10000以上）を正しく表示（&ファイルに書き込み）するには、「出力先がコンソールならWriteConsoleW、そうでなければWriteFileを使用する」といった非常に面倒な実装が必要であり（参照: [https://twitter.com/mattn_jp/status/542581083242364928 https://twitter.com/mattn_jp/status/542581083242364928] など）、C++やC#では扱いづらい。そこでrustを用いて実装した。→[https://github.com/ge9/pure-echo-win pure-echo-win]</li>
<li>printcd
カレントディレクトリをコンソールに出力する。（ちなみにpwdの由来はprint working directoryなのでそれに倣った）</li></ul>


== 注意: 当初は後述のNoWorkingDirectoryを知らなかったので1.の方法に頼っていたが、実際には2.の方法のほうが簡明なので、そちらを使うことを勧める。1.（と1.1.）は残しておくが、読む必要はあまりない。 ==


== 1.標準入力から受け取る場合 ==

まず「標準入力からディレクトリのフルパスを受け取り、そのディレクトリで各種ターミナルを起動するコマンド」を紹介する。

そのようなコマンドを仮に<code>openterm</code>とすると、ExecuteCommand-Pipeを使用して、レジストリ（該当CLSIDのLocalServer32の既定の値）に以下のように書くことで、CLSIDが右クリックメニューのDelegateExecute値に使えるようになる。

<code>C:\path\to\ExecuteCommand4000.exe h openterm</code>

<code>h</code>はコンソールウインドウを非表示にするExecuteCommand-Pipeのオプションである。

また、この<code>openterm</code>の部分は非常に長くなることがあり、その場合レジストリに書いて直接編集するのは手間がかかる（操作もしづらいし、更新を即座に反映させるために「<code>LocalServer32</code>」キーの名前などを変えて戻す必要もあって面倒）。そこで、runotherを使ってtxtに<code>openterm</code>の内容をそのまま書くことで、<code>openterm</code>の部分にそのexeの名前だけを書けばよくなる。

また、いくつかはCygwin/Git Bash向けに冒頭でcygpathによる変換を入れているが、これを取り除けば、Cygwin/Git Bash用のパスを受け取って動作するコマンドということになる。

では以下で、<code>openterm</code>部分についてそれぞれ紹介する。

* 直接コマンド記入でも<code>NoWorkingDirectory</code>を指定すれば<code>\\?\</code>に対応できるというのをこのセクションの大部分を書き終えてから知ったので、このセクションは内容の多さの割には実際の必要性はそこまで大きくないかもしれない。


=== Git Bash ===


==== <code>git-bash.exe</code>で開く ====

この場合shの感覚で<code>git-bash.exe</code>に引数を渡せば勝手にminttyのウインドウで開いてくれるので最も楽である。

<code>cmd /c ""C:\Program Files\Git\usr\bin\cygpath" -f - | "C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=;/bin/env LANG=en_US.utf8 /bin/printf %q $(/bin/cat)" | "C:\Program Files\Git\usr\bin\xargs" -d '\n' -I {} "C:\Program Files\Git\git-bash.exe" -c "cd {};exec bash""</code>

* Git BashのcygpathでGit Bash用のパスに変換
* printfでエスケープ、utf8を設定
* git-bash.exeに渡す


==== デフォルトのターミナルで開く: ①startrunを使う ====

<code>cmd /c ""C:\Program Files\Git\usr\bin\cygpath" -f - | "C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=;/bin/env LANG=en_US.UTF8 /bin/printf %q $(/bin/cat)" | "C:\Program Files\Git\usr\bin\xargs.exe" -d '\n' -I {} startrun "C:\Program Files\Git\usr\bin\env.exe" MSYSTEM=MINGW64 "C:\Program Files\Git\usr\bin\bash.exe" --login -i -c 'cd {};exec bash'"</code>

* <code>git-bash.exe</code>や<code>C:\Program Files\Git\bin</code>のbashではなく/usr/binのbash.exeを使う。以後同じ。


==== デフォルトのターミナルで開く: ②cmdのstartを使う ====

<code>cmd /c ""C:\Program Files\Git\usr\bin\cygpath" -f - | "C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=;/bin/env LANG=en_US.UTF8 /bin/printf %q $(/bin/sed 's/\\^/^^/g;s/%/=%/g;s/&/^&/g')" | "C:\Program Files\Git\usr\bin\xargs.exe" -d '\n' -I {} cmd //c start "" "C:\Program Files\Git\usr\bin\env.exe" MSYSTEM=MINGW64 "C:\Program Files\Git\usr\bin\bash.exe" --login -i -c 'cd "$(echo {} ^| sed s/=%/%/g)";exec bash'"</code>

* この場合、cmdによる環境変数への置換を避ける必要があるほか、キャレットによるエスケープにも対応する必要がある。
* Git Bashからcmdを実行しているので<code>//c</code>のところのスラッシュは2つ。

==== conhostで開く ====

<code>cmd /c ""C:\Program Files\Git\usr\bin\cygpath" -f - | "C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=;/bin/env LANG=en_US.UTF8 /bin/printf %q $(/bin/sed 's/%/=%/g')" | "C:\Program Files\Git\usr\bin\xargs.exe" -d '\n' -I {} conhost "C:\Program Files\Git\usr\bin\env.exe" MSYSTEM=MINGW64 "C:\Program Files\Git\usr\bin\bash.exe" --login -i -c 'cd "$(echo {}|sed s/=%/%/g)";exec bash'"</code>

conhostによる環境変数の置換を抑制。


==== Windows Terminalで開く ====

<code>cmd /c ""C:\Program Files\Git\usr\bin\cygpath" -f - | "C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=;LANG=en_US.UTF8 printf %q $(/bin/sed 's/%/=%/g')" | "C:\Program Files\Git\usr\bin\sed.exe" "s/;/\\\\;/g" | "C:\Program Files\Git\usr\bin\xargs.exe" -d '\n' -I {} wt "C:\Program Files\Git\usr\bin\env.exe" MSYSTEM=MINGW64 "C:\Program Files\Git\usr\bin\bash.exe" --login -i -c "IFS=\\;cd $(echo {}|sed s/=%/%/g) \\;exec bash""</code>

上記に加えてセミコロンへの対応が必要なのと、こっちは/bin/printfじゃなくて組み込みのprintfでこうしないとだめだった。


==== Cygwin ====

付属のminttyを使うものだけはGit Bashと割と差があるので載せる。

<code>cmd /c ""C:\cygwin64\bin\cygpath" -f - | "C:\cygwin64\bin\sh.exe" -c "IFS=;/bin/printf %q $(/bin/cat)" | "C:\Program Files\Git\usr\bin\xargs" -d '\n' -I {} "C:\cygwin64\bin\mintty.exe" -e "C:\cygwin64\bin\bash.exe" --login -i -c "cd {};exec bash""</code>


=== PowerShell ===


==== デフォルトシェル, startrun ====

* パスのエスケープがおかしい気がするが、なぜか動いている

<code>cmd /c ""C:\Program Files\Git\usr\bin\sed.exe" "s/'/''/g" | "C:\Program Files\Git\usr\bin\xargs.exe" -d '\n' -I {} startrun powershell -noexit -command Set-Location -literalPath "'{}'""</code>


==== デフォルトシェル, cmdのstart ====

<code>cmd /c ""C:\Program Files\Git\usr\bin\sed.exe" "s/'/''/g;s/%/=%/g" | "C:\Program Files\Git\usr\bin\xargs.exe" -d '\n' -I {} cmd //c start "" powershell -noexit -command Set-Location -literalPath '\'{}\'.Replace(\'=^%\',\'%\')'"</code>


=== cmd ===


==== Windows Terminal ====

<code>cmd /c chcp 65001 & powershell -Command "$mypath=($input | ForEach-Object { return $_ });$bak=$env:MY_PERCENT; $env:MY_PERCENT = '%';if ($mypath.Length -gt 258) { $mypath = cmd /c \"for %A in (`\"$($mypath.Replace('%', '%MY_PERCENT%'))`\") do @echo %~sA\" };$env:MY_PERCENT = $bak;wt -d ($mypath -replace ';', '\;') cmd"</code>

<ul>
<li>[[Windowsのパス長さ制限に関して|Windowsのパス長さ制限に関して]] でも書いた通り、Windows側はちょうど259文字の長さのフォルダだけは（その必要があるにもかかわらず）8.3形式を使った短いパスにして渡してくれない。そこで、パス長さが258を超えていればcmdに渡して8.3形式の名前に変換する処理をPowerShell側で行う。この際はエスケープされていない正確なパス名をcmdに渡さなければならないので<code>MY_PERCENT</code>の値を一時的に<code>%</code>に設定する方法をとっている。
<ul>
<li>念のため再確認しておくが、この<code>'%MY_PERCENT%'</code>の部分は<code>'%'.Trim('=')+'MY_PERCENT%')</code>などと変えておかないと、<code>MY_PERCENT</code>が定義されていた場合に正しく動作しない。</li>
<li>cmdではちょうど258文字のフォルダでもdirが失敗するなど挙動が不自然であるため、もう少し保守的に257を超えていれば短くするという仕様でもいいかもしれない。</li></ul>
</li>
<li>（追記）8.3形式のパスを取得するのは普通にPowerShell内でもできるらしい…。以下のようになる。
<code>if ($mypath.Length -gt 258) { $mypath = (New-Object -ComObject Scripting.FileSystemObject).GetFolder($mypath).ShortPath}</code></li></ul>

259文字のフォルダを無視するなら以下のように簡潔に済む。

<code>cmd /c chcp 65001 & powershell -Command wt '-d' $input.Replace(';','\;') cmd</code>

==== デフォルトシェル ====

これは案外難しい。なぜなら、cmd内でcdさせるのは%のエスケープの関係で難しく（cmd内で=を含む文字列を置換することがどうやってもできなさそう（外部プログラムを呼び出すのも難しそうだった）なので、未定義の変数を探索するやり方しかない）、Start-Processの-WorkingDirectoryやCygwinのshは8.3形式に対応していないからである。要は「与えられたディレクトリ（8.3形式のパスが含まれるかもしれない）をカレントディレクトリとして与えられたコマンドを実行する」だけやってくれるプログラムがあればよく、これ自体はそう難しくないことのはずだが、現状、Windows標準環境でこれができるのは自前でプログラムをコンパイルする以外だと（pwshを入れていいならpwshと）vbsしかないようである。結局、この部分をついでにやってくれるWindows Terminalのほうが楽ということになる。

たとえば以下のようなvbsを用意する。

<syntaxhighlight style="margin-bottom:0.2em;" lang="vb.net">Dim objShell
Set objShell = CreateObject("WScript.Shell")
objShell.CurrentDirectory = WScript.Arguments(1)
objShell.Run(WScript.Arguments(0)),,False</syntaxhighlight>
<div style='text-align: center;'>startatdir.vbs</div>

すると以下のように書ける。

<code>cmd /c chcp 65001 & powershell -Command "$mypath=($input | ForEach-Object { return $_ });$bak=$env:MY_PERCENT;$env:MY_PERCENT = '%';if ($mypath.Length -gt 258) { $mypath = cmd /c \"for %A in (`\"$($mypath.Replace('%', '%MY_PERCENT%'))`\") do @echo %~sA\" };$env:MY_PERCENT = $bak; wscript 'C:\path\to\startatdir.vbs' cmd ('\"'+$mypath+'\"')"</code>

なお<code>startatdir.vbs</code>のパス指定はフルパスが必要そう（ただしここはcmd /cの中なので<code>%USERPROFILE%</code>とかを使って書いてもよい）


== 1.1.標準入力から受け取る場合 - 管理者権限あり ==

上記の続きで、こちらは管理者権限ありのもの。


=== Git Bash ===


==== デフォルトシェル ====

<code>cmd /c ""C:\Program Files\Git\usr\bin\cygpath" -f - | "C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=;/bin/env LANG=en_US.UTF8 /bin/printf %q $(/bin/cat)" | "C:\Program Files\Git\usr\bin\sed.exe" "s/'/''/g" | "C:\Program Files\Git\usr\bin\xargs.exe" -d '\n' -I {} powershell -Command Start-Process -Verb Runas -Filepath '"C:\Program Files\Git\usr\bin\env.exe"' -ArgumentList '"MSYSTEM=MINGW64"', '"`"C:\Program Files\Git\usr\bin\bash.exe`""' , '--login', '-i' , '-c', "'\"cd {}; exec bash\"'" "</code>

* Start-Process自体がstartみたいなものなので、引数にコンソールアプリケーションを指定したらデフォルトシェルで開かれる。
* 最後のところ、「<code>"'\"cd {}; exec bash\"'"</code>」のかわりに「<code>'\'"cd {};exec bash"\''</code>」とか「<code>'\'\"cd {};exec bash"\''</code>」でも動くのは謎。シングルクォーテーションのエスケープ規則がわからない。参考→[https://twitter.com/e9g/status/1678283164689760256 https://twitter.com/e9g/status/1678283164689760256]


==== Windows Terminal ====

<code>cmd /c ""C:\Program Files\Git\usr\bin\cygpath" -f - | "C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=;LANG=en_US.UTF-8 printf %q $(/bin/cat)" | "C:\Program Files\Git\usr\bin\sed.exe" "s/'/''/g;s/%/==%/g;s/;/\\\\;/g" | "C:\Program Files\Git\usr\bin\xargs.exe" -d '\n' -I {} powershell -Command Start-Process -Verb Runas -Filepath wt -ArgumentList "'"'"C:\Program Files\Git\usr\bin\env.exe"'"'" , '"MSYSTEM=MINGW64"' , "'"'"C:\Program Files\Git\usr\bin\sh.exe"'"'" , "'--login'", "'-c'", "'"'"IFS=\\;cd $(echo {}| /bin/sed s/==%/%/g) \\; exec bash"'"' " "</code>

==== adminrunを使う ====

<code>piperunex "C:\Program Files\Git\usr\bin\cygpath" -f - | "C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=; /bin/env LANG=en_US.UTF8 /bin/printf %q $(/bin/cat)" | "C:\Program Files\Git\usr\bin\sed.exe" "s/%/==%/g;s/;/\\\\;/g" | "C:\Program Files\Git\usr\bin\xargs.exe" -d '\n' -I {} adminrun wt "C:\Program Files\Git\usr\bin\env.exe" "MSYSTEM=MINGW64" "C:\Program Files\Git\usr\bin\sh.exe" --login -c "IFS=\\;cd $(echo {}|| /bin/sed s/==%/%/g) \\; exec bash"</code>


=== PowerShell ===


==== Windows Terminal ====

<code>cmd /c ""C:\Program Files\Git\usr\bin\sed.exe" "s/'/''''/g;s/%/==%/g;s/;/\\\\;/g" | "C:\Program Files\Git\usr\bin\xargs.exe" -d '\n' -I {} powershell -Command Start-Process -Verb Runas -Filepath wt -ArgumentList 'powershell', '-noexit', '-command', 'Set-Location', '-LiteralPath', "'''\"{}\"''.Replace(''==%'',''%'')'" "</code>

* Cygwin系なしで

<code>cmd /c "chcp 65001 & powershell -Command Start-Process -Verb Runas -Filepath wt -ArgumentList 'powershell', '-noexit', '-command', 'set-location', '-literalpath', ('\"'''+($input -replace '''', '''''' -replace '%', '==%' -replace ';', '\;' )+'''.Replace(''==%'',''%'')\"') "</code>


=== cmd ===


==== デフォルトシェル ====

再び、startatdir.vbsを使う。

<code>cmd /c chcp 65001 > nul & powershell -Command "$mypath=($input | ForEach-Object { return $_ });$bak=$env:MY_PERCENT; $env:MY_PERCENT = '%';if ($mypath.Length -gt 258) { $mypath = cmd /c \"for %A in (`\"$($mypath.Replace('%', '%MY_PERCENT%'))`\") do @echo %~sA\" };$env:MY_PERCENT = $bak; Start-Process -Verb Runas -Filepath wscript -Argumentlist '//Nologo', 'C:\path\to\startatdir.vbs', 'cmd', ('\"'+$mypath+'\"')"</code>


==== Windows Terminal ====

<code>cmd /c chcp 65001 & powershell -Command "$mypath=($input | ForEach-Object { return $_ }); $bak=$env:MY_PERCENT; $env:MY_PERCENT = '%';if ($mypath.Length -gt 258) { $mypath = cmd /c \"for %A in (`\"$($mypath.Replace('%', '%MY_PERCENT%'))`\") do @echo %~sA\" };$env:MY_PERCENT = $bak;Start-Process -Verb Runas -Filepath wt -Argumentlist '-d', ('\"'+($mypath -replace '\\$','\\\\' -replace ';', '\;')+'\"'), cmd"</code>

この場合は<code>C:\</code>のための対処（<code>-replace '\\$','\\\\'</code>）が必要である。259文字のフォルダを無視するなら以下の通り。

<code>cmd /c "chcp 65001 & powershell -Command Start-Process -Verb Runas -Filepath wt -ArgumentList '-d', ('\"'+($input -replace '\\$','\\\\').Replace(';','\;')+'\"'), cmd"</code>


== 2.直接コマンド記入の右クリックメニュー ==

レジストリの<code>command</code>キーの既定の値に直接コマンドを記入する方式である。

デフォルトでは、右クリックメニューを押した時点でのフォルダ（フォルダを右クリックするメニューからだと対象フォルダの親、フォルダ背景を右クリックするメニューなら対象フォルダ）をカレントディレクトリとしてコマンドが起動される。そのため<code>\\?\</code>を付けなければならないような長大なパスのフォルダでは動作しない。しかし、<code>shell\xxxx</code>キーに<code>NoWorkingDirectory</code>値を設定することで、カレントディレクトリが必ず<code>C:\Windows\System32</code>に設定されるようになるので動くようになる。

対象のディレクトリはどう取得するかというと、レジストリに書き込んだ値のうち<code>%V</code>という部分が対象ディレクトリに書き換えられてコマンドが実行される。この<code>%V</code>もC:などの場合は<code>C:\</code>になる。コマンドの中でそのまま%という文字を使いたい場合はバッチファイルと同様に%%とエスケープする必要があるようである（これはどこにも書いてない？）。

しかし、こうして渡される（特殊文字を含むかもしれない）ディレクトリ名を完璧に取得するのは意外と難しい。cmdに解釈させると<code>%</code><code>VAR</code><code>%</code>が置換されてしまうし、シングルクォートとバッククォートが両方含まれているのでpowershellやshに渡すのも簡単ではない。

コツは、powershell -commandやsh -cの中に直接書くのではなく、スクリプトへのコマンドライン引数として渡した上で、スクリプト内で引数として取得することである。それぞれ、基本形（そのまま出力するだけ）は以下のようになる。

<ul>
<li>powershell
<code>powershell -Command "& {echo $args[1].Trim('\"')}" --%% "\"%V\""</code>
<ul>
<li><code>--%</code>というトークンを入れることでその後のパラメータの解析を行わないようにできる。args[0]は<code>--%</code>になるのでargs[1]を使う。レジストリに書く際は<code>%</code>をエスケープして<code>--%%</code>。</li>
<li><code>--</code>でも同様のことができる？<code>powershell -Command "& {echo $args[0].Trim('\"')}" -- "\"%V\""</code>（args[0]になっていることに注意）</li>
<li>というか、<code>--%</code>で書き進めてしまったが、本当は<code>--</code>のほうが安定するかもしれない。</li></ul>

あるいは<code>$MyInvocation.Line</code>を使う方法もある。この場合、powershellへの引数が全て（この例なら<code>-noexit -Command "& {$spl = ...</code>のところから）取得されるので、目当ての部分を取り出すためにここでは最後から2番目の<code>"</code>と最後の<code>"</code>の間を取得するという風にしている。
<code>powershell -noexit -Command "& {$spl = $MyInvocation.Line -split'\"' ; Set-Location -LiteralPath $spl[$spl.Length-2]}" --%% "\"%V\""</code>
昔のPowerShell（2くらい）で試してみたらこちらでないと<code>`</code>や<code>&</code>あたりの処理がうまくいかない場合があった。argsを使うものからの書き換えは容易である。</li>
<li>sh
<code>sh -c "IFS=;echo $*" -- "%V</code>
<ul>
<li>最後が<code>"%V</code>と閉じられていないのはミスではなく、<code>"%V"</code>としてしまうと<code>C:\</code>のときに<code>C:"</code>が渡されてしまうのでそれを避けるためである（これはかなりトリッキーなのでもう少し真面目にやってもいいかなとは思う）。</li>
<li>UNCパスの最初の<code>\\</code>が<code>\</code>に変わってしまう（手元では、Cygwinの場合は<code>\\?\</code>のみで発生している？）という問題があり、適宜置換する必要がある。</li></ul>
</li></ul>

これらの書き方はいわゆる「ワンライナー」的なものであるが、もちろん外部にスクリプトファイルを用意してもよい。

また、外部にスクリプトを用意してよいという条件であれば、vbsも使用可能である。

<ul>
<li>この場合、まずレジストリには
<code>wscript "C:\path\to\script.vbs" "%V"</code>
などと書く。スクリプトの内容は上記のレジストリの内容をほぼそのままWscript.ShellでRunすればよいが、<code>%V</code>のかわりにWscript.Arguments(0)を挿入するのと、<code>%</code>を<code>%%</code>にエスケープしなくてよいのと、VBSなので文字列内の<code>"</code>は<code>""</code>に変えなければならない。これに加え、Runの引数に含まれる<code>%</code><code>VAR</code><code>%</code>が置換の対象となるため、対象フォルダの文字列については<code>==%</code>への置換でエスケープして、呼び出し先のpowershellなどで元に戻す。</li>
<li>必要に応じてRunのオプションでvbHideを指定する。</li>
<li>というか別に258文字を超えていたら云々みたいな処理も全部vbs側でやってしまってもよい（面倒なのでそういう例は載せていない）</li></ul>

バッチファイルに渡すのは、バッチファイルをcmdが呼び出す時点で<code>%PATH%</code>のようなファイル名の環境変数は既に展開されてしまうので、どうやっても不可能。

他には、（hiderunと）piperunとpechoを併用するという方法もあり、それらの実行ファイルを用意する必要があるという以外は綺麗にできる方法である。

いずれにしろ、一旦取得できてしまえばあとは前述の<code>openterm</code>に流し込むだけでよい。ただ、実際にはわざわざ<code>openterm</code>に流し込まなくても（パイプを使わなくても）もっと簡単に起動できることもあるのでそちらを中心に紹介する。

* commandの最初で指定する（メインの）実行ファイル（先ほどなら<code>powershell</code>や<code>sh</code>）をファイル名単体で書く場合は、それが（メニューをHKCUで設定するならHKCUの（最近のWindowsならHKLMのでも可？）、HKLMで設定するならHKLMの）App Pathsキーに登録されていなければならない（PATHは通っていなくてもいい）。登録されていない場合はフルパスで指定する必要がある。

=== 設定例 ===

==== 管理者権限なし ====

<ul>
<li>PowerShell
デフォルトターミナルで
<code>powershell -noexit -Command "& {Set-Location -LiteralPath $args[1].Trim('\"')}" --%% "\"%V\""</code>
<ul>
<li>参考までに、Windowsにもともと入っているメニューでは以下のようになっている。
<code>powershell.exe -noexit -command Set-Location -literalPath '%V'</code>
これだとシングルクォートと連続スペースに対応できない。連続スペースだけなら<code>'%V'</code>を<code>"'%V'"</code>に変えると解決できる。<code>%$[]`</code>あたりは見た感じ問題なし。
<ul>
<li>以下の解決策でもまだ不完全 [https://superuser.com/questions/1310258/open-powershell-window-here-file-explorer-context-menu-command-breaks-with-fol "Open PowerShell window here" File Explorer context-menu command breaks with folder names with apostrophes (single quotes) - Super User]</li></ul>
</li>
<li>この問題は[https://github.com/PowerShell/PowerShell/issues/6598 https://github.com/PowerShell/PowerShell/issues/6598]や[https://github.com/PowerShell/PowerShell/pull/6660 https://github.com/PowerShell/PowerShell/pull/6660] で扱われており、結局pwshでは-WorkingDirectoryというパラメータが追加された。[https://github.com/PowerShell/PowerShell/issues/14091 https://github.com/PowerShell/PowerShell/issues/14091]にある以下の文字列をレジストリに書いたところ、正しく動作したので、pwshではこれでよい。
<code>pwsh.exe -NoExit -RemoveWorkingDirectoryTrailingCharacter -WorkingDirectory "%V!" -Command "$host.UI.RawUI.WindowTitle = 'PowerShell 7 (x64)'"</code></li></ul>

wtで
<code>hiderun powershell -Command "& {wt powershell -noexit -Command Set-Location -LiteralPath ('\"'''+($args[1] -replace '''', '''''' -replace '%%', '==%%' -replace ';', '\;' )+'''.Replace(''==%%'',''%%'')\"')}" --%% "\"%V\""</code></li>
<li>cmd
wtで。標準入力のときとほぼ同じ。
<code>powershell -Command "& {$bak=$env:MY_PERCENT;$mypath=$args[1].Trim('\"'); $env:MY_PERCENT = '%%';if ($mypath.Length -gt 258) { $mypath = cmd /c \"for %%A in (`\"$($mypath.Replace('%%', '%%MY_PERCENT%%'))`\") do @echo %%~sA\" };$env:MY_PERCENT = $bak;wt -d ($mypath -replace ';', '\;') cmd}" --%% "\"%V\""</code>
<ul>
<li>デフォルトターミナルで
startatdir.vbsを使う。
<code>powershell -Command "& {$bak=$env:MY_PERCENT;$mypath=$args[1].Trim('\"'); $env:MY_PERCENT = '%%';if ($mypath.Length -gt 258) { $mypath = cmd /c \"for %%A in (`\"$($mypath.Replace('%%', '%%MY_PERCENT%%'))`\") do @echo %%~sA\" };$env:MY_PERCENT = $bak; wscript 'C:\path\to\startatdir.vbs' cmd ('\"'+$mypath+'\"')}" --%% "\"%V\""</code></li>
<li>Windowsにもともと入っているメニューでは以下。
<code>cmd.exe /s /k pushd "%V"</code>
これは（<code>\\?\</code>が付くパスを除いて）ほとんどの場合に正しく機能するが、<code>%PATH%</code>のような文字列が含まれているフォルダではうまくいかない。ちなみにpushdによりUNCパスには自動的にネットワークドライブが割り当てられる。</li></ul>
</li>
<li>Git Bash
<ul>
<li>mintty（git-bash.exe使用）
<code>"C:\Program Files\Git\git-bash.exe" -c "IFS=;cd $(echo $*|/bin/sed 's/\\\\/\\\\\\\\/'|/bin/cygpath -f -);exec bash" -- "%V</code>
<ul>
<li>ちなみに、Git Bashのインストーラにより設定される「Git Bash Here」メニューでは以下のようになっている。
<code>"C:\Program Files\Git\git-bash.exe" "--cd=%v."</code>
これは、特殊文字にはすべて対応しているが、（NoWorkingDirectoryをつけたとしても）<code>\\?\</code>で始まるパスではうまくいかない。最後の「.」はよくわからないがこれを付けておくと<code>--cd</code>がうまくやってくれるっぽい。</li></ul>
</li>
<li>デフォルトシェルで
<code>"C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=;cd $(echo $*|/bin/sed 's/\\\\/\\\\\\\\/'|/bin/cygpath -f -);export MSYSTEM=MINGW64;exec /bin/bash --login" -- "%V</code></li>
<li>wtで
<code>hiderun "C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=;LANG=en_US.UTF8; echo $*|/bin/sed 's/\\\\/\\\\\\\\/'|/bin/cygpath -f -|printf %%q $(/bin/sed 's/%%/=%%/g')|/bin/sed 's/;/\\\\;/g'|/bin/xargs -d '\n' -I {} -- wt \"C:\Program Files\Git\usr\bin\env.exe\" MSYSTEM=MINGW64 \"C:\Program Files\Git\usr\bin\bash.exe\" --login -i -c 'IFS=\\;cd $(echo {}|sed s/=%%/%%/g)\\;exec bash'" -- "%V</code></li></ul>
</li>
<li>Cygwin
<ul>
<li>デフォルトシェルで
<code>"C:\cygwin64\bin\sh.exe" --login -c "IFS=;cd $(echo $*|/bin/sed 's/\\\\?/\\\\\\\\?/'|/bin/cygpath -f -);exec bash" -- "%V</code>
<ul>
<li>置換の対象を<code>\\?\</code>のみとするためsedの引数に<code>?</code>が増えている</li></ul>
</li>
<li>wtで
<code>hiderun "C:\cygwin64\bin\sh.exe" -c "IFS=;echo $*|/bin/sed 's/\\\\?/\\\\\\\\?/'|/bin/cygpath -f -|printf %%q $(/bin/sed 's/%%/=%%/g')|/bin/sed 's/;/\\\\;/g'|/bin/xargs -d '\n' -I {} -- wt \"C:\cygwin64\bin\bash.exe\" --login -i -c 'IFS=\\;cd $(echo {}|sed s/=%%/%%/g)\\;exec bash'" -- "%V</code></li></ul>
</li></ul>

==== 管理者権限 ====

<ul>
<li>PowerShell
<code>powershell -Command "& {Start-Process -Verb Runas -Filepath wt -Argumentlist powershell, -noexit, -command, Set-Location, -LiteralPath, ('\"'''+($args[1].Trim('\"') -replace '''', '''''' -replace ';', '\;' -replace '%%', '==%%')+'''.Replace(''==%%'',''%%'')\"')}" --%% "\"%V\""</code>
環境変数の置換を抑止する必要がある。デフォルトシェルで起動するならこれは不要（で、wtでないので<code>;</code>のエスケープも不要）で、以下のようになる。
<code>powershell -Command "& {Start-Process -Verb Runas -Filepath powershell -Argumentlist '-noexit', '-command', Set-Location, '-LiteralPath', ('\"'''+($args[1].Trim('\"') -replace '''', '''''' )+'''\"')}" --%% "\"%V\""</code>
<ul>
<li>MyInvocationを使う例
<code>powershell -Command "& {$spl = $MyInvocation.Line -split'\"'; Start-Process -Verb Runas -Filepath powershell -Argumentlist '-noexit', '-command', Set-Location, '-LiteralPath', ('\"'''+($spl[$spl.Length-2] -replace '''', '''''' )+'''\"')}" --%% "\"%V\""</code></li>
<li>vbsの例
次の節で解説する「（自分が起動された）カレントディレクトリでの起動」にも対応している（引数がない場合）。
<syntaxhighlight lang="vb.net">Dim objShell
Dim curDir

Set ws = CreateObject("Wscript.Shell")
Dim dir
If WScript.Arguments.Count = 0 Then
dir = ws.CurrentDirectory
Else
dir = Wscript.Arguments(0)
End If
dir = Replace(dir,"%","==%")
ws.run "powershell -Command ""& {Start-Process -Verb Runas -Filepath wt -Argumentlist powershell, -noexit, -command, Set-Location, -LiteralPath, ('\""'''+($args[1].Trim('\""') -replace '''', '''''' -replace ';', '\;' )+'''.Replace(''==%'',''%'')\""')}"" --% ""\"""&dir&"\""""", vbHide

Set objShell = Nothing</syntaxhighlight></li></ul>
</li>
<li>cmd
<code>powershell -Command "& {$bak=$env:MY_PERCENT;$mypath=$args[1].Trim('\"'); $env:MY_PERCENT = '%%';if ($mypath.Length -gt 258) { $mypath = cmd /c \"for %%A in (`\"$($mypath.Replace('%%', '%%MY_PERCENT%%'))`\") do @echo %%~sA\" };$env:MY_PERCENT = $bak;Start-Process -Verb Runas -Filepath wt -Argumentlist '-d', ('\"'+($mypath -replace '\\$','\\\\' -replace ';', '\;')+'\"'), cmd}" --%% "\"%V\""</code>
この場合も<code>C:\</code>のための対処（<code>-replace '\\$','\\\\'</code>）が必要である。デフォルトシェルなら、startatdir.vbsを使う。
<code>powershell -Command "& {$bak=$env:MY_PERCENT;$mypath=$args[1].Trim('\"'); $env:MY_PERCENT = '%%';if ($mypath.Length -gt 258) { $mypath = cmd /c \"for %%A in (`\"$($mypath.Replace('%%', '%%MY_PERCENT%%'))`\") do @echo %%~sA\" };$env:MY_PERCENT = $bak;Start-Process -Verb Runas -Filepath wscript -Argumentlist '//Nologo', 'C:\path\to\startatdir.vbs', 'cmd', ('\"'+$mypath+'\"')}" --%% "\"%V\""</code></li>
<li>Git Bash
理論上はワンライナーでも書けるが、エスケープが面倒すぎるのでファイルに書いたほうがよいだろう。まずレジストリの中身は以下のようにする。
<code>"C:\Program Files\Git\usr\bin\sh.exe" "C:\path\to\gb-wt-admin.sh" "%V"</code>
で、<code>gb-wt-admin.sh</code>の中身は以下。
<syntaxhighlight lang="bash">#!/bin/sh
IFS=
LANG=en_US.UTF-8
echo $*|/bin/sed 's/\\/\\\\/'|/bin/cygpath -f -|printf %q $(/bin/cat) |/bin/sed "s/'/''/g;s/%/==%/g;s/;/\\\\;/g"|/bin/xargs -d '\n' -I {} powershell -Command Start-Process -Filepath wt -ArgumentList "'"'"C:\Program Files\Git\usr\bin\env.exe"'"'" , '"MSYSTEM=MINGW64"' , "'"'"C:\Program Files\Git\usr\bin\sh.exe"'"'" , "'--login'", "'-c'", "'"'"IFS=\;cd $(echo {}| /bin/sed s/==%/%/g) \; exec bash"'"'"</syntaxhighlight>
Cygwinも同様である。</li></ul>


==== VS Codeのメニュー（おまけ） ====

「Code で開く」メニューのcommand値は以下のように設定されている。

<code>"C:\Program Files\Microsoft VS Code\Code.exe" "%V"</code>

これは特殊文字などに関しても問題なく動作するうえ、実はそのまま<code>\\?\</code>が付いたパスにも適用可能である。従って、<code>VSCode</code>キーに<code>NoWorkingDirectory</code>値を設定する（設定の書き換えまたはHKCUによるオーバーライド）だけで、長大フォルダでもVS Codeが使えるようになる。ターミナルの起動には失敗してしまうがファイル・フォルダの作成・編集などの基本操作がGUIでできるので意外と便利（もちろん、他のBetter Explorer的なツールを使う手もあるだろう）。


== 3. エクスプローラーのアドレスバーから ==

このときは、末尾が空白のパスや<code>\\?\</code>が必要な長大パスやちょうど259文字のフォルダはそもそも対応していないので考えなくてよい。しかし通常のネットワークファイル向けのUNCパス（<code>\\192.168.1.1\disk</code>など）に対応する必要はあるので、cmdをベースにすることはできない（cmdの中に入った時点でカレントディレクトリが変わってしまう）。また<code>``</code>が含まれるパスをカレントディレクトリにできないことから、powershell.exeもベースとしては使えない。

なので、パイプを使って先ほどの<code>openterm</code>にむけて流し込もうと思ったら選択肢はpwsh.exeかpiperunかCygwin系だけである。それぞれの書き方は以下のようになる。

<ul>
<li>pwsh
<code>pwsh -Command $pwd.Path.Replace('Microsoft.PowerShell.Core\FileSystem::\\', '\\') | openterm</code></li>
<li>piperun
<code>piperun pwsh -Command $pwd.Path.Replace('Microsoft.PowerShell.Core\FileSystem::\\', '\\') | openterm</code>
上とほぼ変わっていないが、pwshはディレクトリの取得だけで使っているので<code>openterm</code>のところで環境変数が汚染されるのを防げる。</li>
<li>Cygwin/Git Bash
<code>"C:\Program Files\Git\usr\bin\sh.exe" -c "cmd //c \"chcp 65001 > nul\"| pwd | /bin/cygpath -w -f - | openterm"</code>
<ul>
<li>一つ問題があり、hiderunを使う（コンソールを非表示にする）とchcpが効かないようで、<code>openterm</code>でPowerShellの<code>$input</code>を使っているとUnicode文字が化けてしまう。</li>
<li>先ほどの<code>openterm</code>部分で先頭にcygpathが入っているものを使うときは、そちらのcygpathとこちらでのcygpath -wは打ち消し合って無駄なので消してよい。</li></ul>
</li></ul>

このほかにvbs(wscript)もカレントディレクトリの取得のところは問題なくやってくれるので、それをさっきのWscript.Arguments(0)のかわりに使えばよい。

最初に表示されるコンソールを非表示にしたければ、<code>hiderun</code>を付けてrunother経由で実行するのが手軽だが、前述の通りvbsも拡張子無しで呼び出せるように設定できるので、そうした上でvbHideで隠してもよい。


=== 管理者権限なし ===


==== cmd ====

これは普通にcmdと打てばよい。

（デフォルトシェルがconhostだとして）wtで開きたいときは、;をエスケープして-dで渡す。以下の通りbatファイルを作ってpathを通す。

<code>chcp 65001 & cd | powershell -Command wt -d $input.Replace(';','\;') cmd</code>

wtではなくconhostの場合はconhost cmdだけでよい。batにするなら<code>start "" conhost cmd</code>でよい。

コンソール非表示ならcmd /cをつけてhiderunする。runotherで、txtの中身は以下の通り。

<code>hiderun cmd /c chcp 65001 & cd | powershell -Command wt -d $input.Replace(';','\;') cmd</code>


==== powershell, pwsh ====

pwshはそのままpwshと打てばよい。powershell及びwtやconhostを明示的に指定する場合について以下で述べる。

たとえばwtでpwshなら、runotherを使って、txtの内容は以下。

<code>hiderun pwsh -Command wt -d $pwd.Path.Replace('Microsoft.PowerShell.Core\FileSystem::\\', '\\').Replace(';', '\;') pwsh</code>

powershellの場合は<code>``</code>に対応するため起動後に移動する。runotherでpiperunを使って、txtは以下。最終的に起動する方のpowershellで<code>==%</code>を<code>%</code>に戻している。

<code>hiderun piperunex cmd /c chcp 65001 | printcd | powershell -Command wt powershell -noexit -command Set-Location -LiteralPath ('"'''+($input -replace ';', '\;' -replace '''', '''''' -replace '%', '==%')+'''.Replace(''==%'',''%'')"')</code>

pwshが使えるならprintcdのかわりに<code>pwsh -Command $pwd.Path.Replace('Microsoft.PowerShell.Core\FileSystem::\\', '\\')</code>でもよい。

以下はpiperunを使わずshでやる例。前述の通りパイプからPowerShell側で<code>$input</code>を使って受け取ると文字化けするので引数として渡す。

<code>hiderun "C:\Program Files\Git\usr\bin\sh.exe" -c "WD=$(pwd | /bin/cygpath -w -f - | /bin/sed \"s/;/\\\\\\\\;/g; s/'/''/g; s/%/==%/g\"); wt powershell -noexit -command Set-Location -LiteralPath $\"'$WD'.Replace('==%','%')\"$"</code>


==== Git Bash/Cygwin ====

Git Bashは<code>--login</code>をつけてもカレントディレクトリを維持するので単純である。以下をrunotherのtxtに書く。

<code>"C:\Program Files\Git\usr\bin\env.exe" MSYSTEM=MINGW64 /bin/bash --login</code>

Cygwinは起動後にcdする。そのかわり<code>export MSYSTEM=MINGW64</code>が不要。

<code>"C:\cygwin64\bin\sh.exe" -c "IFS=;/bin/bash --login -i -c 'cd '$(/bin/printf %q `pwd`)'; exec bash'"</code>

printfで一旦エスケープしたものをcdの後につなげてそのまま渡している。

<ul>
<li>wtで
<ul>
<li>Git Bash
<code>wt "C:\Program Files\Git\usr\bin\env.exe" MSYSTEM=MINGW64 "C:\Program Files\Git\usr\bin\bash.exe" --login"</code>
<ul>
<li>あれ、wtなのにカレントディレクトリ維持されてる…？wt cmdではダメなのだが…</li></ul>
</li>
<li>Cygwin
<code>hiderun "C:\cygwin64\bin\sh.exe" -c "IFS=;WD=$(printf %q `pwd` | /bin/sed \"s/;/\\\\\\\\;/g; s/%/==%/g\"); wt \"C:\cygwin64\bin\bash.exe\" --login -c 'IFS=\\;cd $(echo '$WD'|sed s/==%/%/g)\\; exec bash'"</code></li></ul>
</li></ul>

=== 管理者権限あり ===


==== cmd ====

runotherを使って以下の通り。

<code>hiderun cmd /c "chcp 65001 > nul & cd | powershell -Command Start-Process -Verb Runas -Filepath wt -ArgumentList '-d', ('\"'+$input.TrimEnd('\\').Replace(';','\;')+'\"'), cmd"</code>

<code>TrimEnd('\\')</code>のところは<code>C:\</code>の末尾のバックスラッシュへの対応である（<code>wt -d "C:"</code>は通らないので一見ダメそうだが、なぜかこれで動く。原因不明。）。

batならそのまま以下の通り（黒い画面が一瞬出てしまう）。

<code>chcp 65001 & cd | powershell -Command Start-Process -Verb Runas -Filepath wt -ArgumentList '-d', ('\"'+$input.TrimEnd('\\').Replace(';','\;')+'\"'), cmd</code>

別解としてパイプを使わないものも載せておこう。cmdでは特殊文字ではないので<code>'</code>を<code>''</code>に変えるのは簡単である。

<code>hiderun cmd /c powershell -Command "& {Start-Process -Filepath wt -Verb Runas -ArgumentList '-d', ('\"'+$args[0].TrimEnd('\\').Replace(';','\;')+'\"'), cmd}" -- "'%CD:'=''%'"</code>

以下もうまくいく。cmdの<code>"</code>に関する仕様により、例えばStart-Processの直前に<code>echo '\"';</code>のような<code>"</code>を奇数個含む文字列を入れると動かなくなる。argsを使うとバッククォートがうまくいかなかったのでMyInvocationを使ってみる。

<code>hiderun cmd /c powershell -Command "& {$spl=$MyInvocation.Line.Split('\"'); Start-Process -Filepath wt -Verb Runas -ArgumentList '-d', ('\"'+$spl[$spl.Length-2].TrimEnd('\\').Replace(';','\;')+'\"'), cmd}" -- "\"%CD%\""</code>


==== powershell, pwsh ====

UNC非対応でよく、かつ（<code>``</code>をカレントディレクトリとして起動できる）pwshでよければ、上記のcmdをpwshに変えればよい。powershellならSet-Locationで移動が必要。以下をrunotherのtxtに書く。

<code>hiderun cmd /c "chcp 65001 & cd | powershell -Command Start-Process -Verb Runas -Filepath wt -ArgumentList 'powershell', '-noexit', '-command', 'Set-Location', '-LiteralPath', ('\"'''+($input -replace '''', '''''' -replace '%', '==%' -replace ';', '\;' )+'''.Replace(''==%'',''%'')\"')"</code>

UNC対応なら、管理者でないときと同じで、PSReadLineのエラーを回避するためpwshを一貫して使うのがいいだろう。

<code>hiderun pwsh -Command Start-Process -Verb Runas -Filepath wt -ArgumentList '-d', ('\"'+$pwd.Path.Replace('Microsoft.PowerShell.Core\FileSystem::\\', '\\').TrimEnd('\\').Replace(';','\;')+'\"'), pwsh</code>

powershellならpiperunを使う。カレントディレクトリの取得にpwshを使っているがprintcdでもよい。

<code>hiderun piperunex cmd /c chcp 65001 | printcd | powershell -Command Start-Process -Verb Runas -FilePath wt -ArgumentList powershell, -noexit, -command, Set-Location, -LiteralPath, ('\"'''+($input -replace ';', '\;' -replace '''', '''''' -replace '%', '==%')+'''.Replace(''==%'',''%'')\"')</code>

shなら以下。

<code>hiderun "C:\Program Files\Git\usr\bin\sh.exe" -c "WD=$( pwd | /bin/cygpath -w -f - | /bin/sed \"s/;/\\\\\\\\;/g; s/'/''''/g; s/%/==%/g\"); powershell -Command Start-Process -Verb Runas -Filepath wt -Argumentlist powershell, -noexit, -command, Set-Location, -LiteralPath, $\"'\\\"''$WD''.Replace(''==%'',''%'')\\\"'\"$"</code>


==== Git Bash ====

runotherとpiperunで以下。

<code>hiderun piperunex "C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=; LANG=en_US.UTF8; pwd || printf %q $(/bin/cat)" | "C:\Program Files\Git\usr\bin\sed.exe" "s/'/''/g;s/%/==%/g;s/;/\\\\;/g" | "C:\Program Files\Git\usr\bin\xargs.exe" -d '\n' -I {} -- powershell -Command Start-Process -Verb Runas -Filepath wt -ArgumentList '"C:\Program Files\Git\usr\bin\sh.exe"','-c', "'"'"IFS=\\; export MSYSTEM=MINGW64\\;cd $(echo {}|| /bin/sed s/==%/%/g)\\; exec /bin/bash --login"'"'"</code>

* <code>MSYSTEM=MINGW64</code>をもっと手前で設定して、<code>-ArgumentList</code>で<code>--login</code>を指定して、最後を<code>exec bash</code>にしてもよい。

piperunを使わずにshで頑張ることもできるが、エスケープが多く読みづらくなる。

<code>hiderun "C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=; LANG=en_US.UTF8; pwd | printf %q $(/bin/cat) | /bin/sed \"s/'/''/g;s/%/==%/g;s/;/\\\\\\\\;/g\" | /bin/xargs -d '\n' -I {} -- powershell -Command Start-Process -Verb Runas -Filepath wt -ArgumentList '\"C:\Program Files\Git\usr\bin\sh.exe\"','-c', \"'\"'\"IFS=\\; export MSYSTEM=MINGW64\\;cd $(echo {}| /bin/sed s/==%/%/g)\\; exec /bin/bash --login\"'\"'\" "</code>

Cygwinも同様。

== 関連 ==

[https://qiita.com/octopath9/items/4b7fe797ae1155c69dd9 コマンドプロンプトから管理者権限のコマンドプロンプトに切り替える - Qiita]

[https://qiita.com/tmiki/items/0dab4fd17e9bed04ed91 【Windows】GitBashをcontext menuからAdministrator権限付きで実行する - Qiita]

[https://note.com/redpeak/n/n5ddc3673117b エクスプローラーから管理者権限でコマンドプロンプトを開く方法｜ひるあんどん]
[[Category:IT]][[Category:Windows]]{{#seo:|title={{FULLPAGENAME}} - Turgenev's Wiki}}

HTTP・SOCKS・透過プロキシ・UDP

2025-09-01T01:31:47Z

Turgenev: Notion-MW

SOCKS・透過プロキシ・UDP-over-TCPなどを中心に、ネットワークの変更に使えるプロキシ関連の各種技術を雑にまとめた。

近年はGo製のものが多い。また検閲に対抗するためか、中国系（中国語でissueが投稿されているなど）のものが多い。gost, go-proxy, hysteria, txthinking/socks5, things-go/socks5などはいずれもその2つに当てはまる。たまにロシア系もある。


== 大規模・多機能系 ==

以下のものは機能が多くて分類できないのでソフトウェアごとに紹介する。

==== gost ====

GO Simple Tunnelの略らしい。安定版のv2系（[https://github.com/ginuerzh/gost https://github.com/ginuerzh/gost], [https://v2.gost.run/ https://v2.gost.run/]）と開発中のv3系（[https://github.com/go-gost https://github.com/go-gost], [https://gost.run/ https://gost.run/]）で大きく仕様が異なる。v3は開発中と言いつつv2系のページを見るとかなりv3推しに見える。

starはバージョン2が16k、バージョン3が5kほど。

イメージとしては、TCPによるシンプルなトンネルプロトコル（これがgost）（暗号化無し）と他の大量のプロトコルの間の相互変換を実装しているような感じと思われる。

非常に多機能で、このページで紹介している多くソフトウェアの基本機能をカバーしていると言ってもいいくらい。UDP-over-TCP系は基本これ1つで十分。機能の豊富さに比して明らかにドキュメントが不足しており、エラーメッセージも親切ではない（起動時ではなく実際にパケットが来てからエラーが出るような感じ）。

<ul>
<li>connectorとしてはsocks5も用意されているが、相手がgostでない限りUDP Associateは動かない模様。具体的には
<syntaxhighlight lang="javascript">gost -L "auto://:8480?udp=true&relay=udp" -F socks5://192.168.1.13:3129</syntaxhighlight>
などとしても、 05f3 0001 0000 0000 0000みたいなよくわからんリクエストが送られてしまう。このf3のところは下記の独自拡張っぽい。
[https://github.com/go-gost/x/blob/04d1587a77964636d8e50f5cce475ee8621bece7/internal/util/socks/socks.go#L17 https://github.com/go-gost/x/blob/04d1587a77964636d8e50f5cce475ee8621bece7/internal/util/socks/socks.go#L17]</li></ul>

==== go-proxy ====

[https://github.com/snail007/goproxy https://github.com/snail007/goproxy]

これも見た感じgostと同じくらいか一部では上回るくらい多機能に見えるが、この雰囲気にしては珍しく有料版があり、無料版だと一部機能が制限されているようなので、あまり使ったことはない。


== GFW回避 ==

中国政府の検閲システムであるグレート・ファイアウォール（GFW）に対抗することを主な目的とするもの。

==== shadowsocks ====

SOCKSに暗号化を施した独自プロトコルで、いくつかの実装がある。[https://github.com/shadowsocks/shadowsocks-rust https://github.com/shadowsocks/shadowsocks-rust]などが主流とみられる。

VPN以外のGFW回避ソフトウェアだとおそらくもっともメジャー。

サーバーとクライアントに分かれていて、クライアント側では透過プロキシにも対応している。


==== Hysteria ====

通信路がHTTP/3に偽装した形で暗号化される。shadowsocksの次世代に位置付けられるソフトウェアのように見える。

SOCKS5サーバー部分にはtxthinking/socks5を使っている。


== SNI Proxy ==

HTTP・HTTPSのリバースプロキシで、host（HTTPの場合）あるいはsni（HTTPSの場合）に基づいてアクセスを振り分けるものをSNI Proxyと呼ぶことがあるらしい。ドメイン→IPを決め打ちする場合は多くのソフトウェアでできそうだが、任意ドメインに対してDNSで解決しつつ振り分けるのは対応していない場合もある。gostはこれにも対応している。Nginxは対応しているが、ngx_stream_ssl_preread_moduleとかが必要なので、環境によっては動かしづらいかもしれない。HAProxyは自分が試した限りでは動かせなかった。これらの汎用のプロキシサーバーの他に、これを専門とするソフトウェアもある。

* Nginxでの使用例（自分の記事）→ [https://turgenev.hatenablog.com/entry/2025/03/21/020550 【Android】NextDNSをアプリごとに有効無効切り替え+Tailscale経由の自宅鯖を使ってControl D風のトラフィック転送 - turgenev’s blog]とか[https://turgenev.hatenablog.com/entry/2025/04/27/215220 【広告ブロックDNS】特定ドメインへのTCP接続を途中で切断してAd-Shield対策 - turgenev’s blog]


==== dlundquist/sniproxy ====

[https://github.com/dlundquist/sniproxy https://github.com/dlundquist/sniproxy]　starは2.6kほど。2024年に更新あり。非推奨である理由（HTTP/2とかQUICでうまくいかないとか）も書いてある。

==== tcpproxy ====

[https://github.com/inetaf/tcpproxy https://github.com/inetaf/tcpproxy]　starは1.3kほど。ライブラリ用途がメインか。


==== ameshkov/sniproxy ====

[https://github.com/ameshkov/sniproxy https://github.com/ameshkov/sniproxy]　starは70ほど。上流のSOCKS5, HTTPプロキシへの転送機能がある。


==== puxxustc/sniproxy ====

[https://github.com/puxxustc/sniproxy https://github.com/puxxustc/sniproxy]　starもほぼなく更新も9年前。


== SOCKSプロキシサーバー ==

ここにあげたものは特に注記がなければUDP（ただし筆者が念頭に置いているのはAssociateのみで、Bindに関してはほぼ調べていない）に対応している。


==== Dante ====

[https://www.inet.no/dante/index.html Dante - A free SOCKS server]

企業（Inferno Nettverk A/S）によるオープンソースなSOCKS5実装で、有償サポートまであるらしい。見るからに古臭いHPで、メンテされているかどうか不安になるが、つい最近2024年末にもアップデートがあり、次期バージョンの計画についても記載されている。

Cで書かれていて、おそらく最も正確なSOCKS5実装だろう。コメントも親切で、リファレンス実装のような雰囲気がある。他の透過プロキシクライアントなどをテストする際はDanteでテストして動けば安心感がある。

Cで書かれていて、おそらく最も正確なSOCKS5実装だろう。コメントも親切で、リファレンス実装のような雰囲気がある。他の透過プロキシクライアントなどをテストする際はDanteでテストして動けば安心感がある。


==== OpenSSH ====

現実的に最もよく使われているSOCKSサーバーは間違いなくOpenSSHだろう。しかし、UDP-over-TCPの問題があるため、UDPはサポートされていない。

ssh -Dでforward方向のプロキシを建てるのが有名だが、OpenSSH 7.6からは-Rでreverse方向にも建てられるようになった。クライアント側が7.6以上であればよい。

* 参考: [https://www.openssh.com/txt/release-7.6 OpenSSH 7.6] （<code>ssh(1): add support for reverse dynamic forwarding</code>）

==== socks-with-udp-over-ssh ====

[https://github.com/ge9/socks-with-udp-over-ssh https://github.com/ge9/socks-with-udp-over-ssh]

これ自体はSOCKS5サーバーではなく、TCP接続（あるいは任意のバイトストリーム）の上にUDP付きのSOCKS5を通すために自分が実装したツール。サーバー側とクライアント側に分かれている。しかし実装した後にgostで同じことができることに気付いた。

経緯・使い方などは[https://turgenev.hatenablog.com/entry/2024/05/12/231208 root権限のないssh上にUDPを通す方法について（ポートフォワード、SOCKS5プロキシなど） - turgenev’s blog]に書いてある。

* このツールでは、DNSリクエストを解釈してサーバー側（サーバー側から見えている外部のDNSを指定してもよい）で解決を行う機能も実装してある。この機能は”fake dns”と名付けているが、shadowsocks-rustのfake dnsやtun2proxyのvirtual dnsはこれとは異なる機能のようである。

==== 3proxy ====

[https://3proxy.ru/ 3proxy tiny free proxy server for Windows, Linux, Unix: SOCKS, HTTP, FTP proxy]

[https://github.com/3proxy/3proxy https://github.com/3proxy/3proxy]

ロシア系。SOCKS・HTTP・POP3・SMTPなどいくつかのプロキシを含む。エラーメッセージなどがかなり不親切だが、結構多機能で、ちゃんと動くソフト。<code>3proxy</code>というメインの実行ファイルとあわせて、各プロキシに対応した<code>socks</code>や<code>proxy</code>といった検索性の低い名前の実行ファイルがいくつか含まれているちょっと謎の構成。

==== fast-socks5 ====

[https://github.com/dizda/fast-socks5 https://github.com/dizda/fast-socks5] Rust製では最も有名か。starは500ほど。使ったことなし


==== txthinking/socks5 ====

[https://github.com/txthinking/socks5 https://github.com/txthinking/socks5]

starは700前後。hysteriaやtrojan-goなどいくつかの大きなプロジェクトで使われており、現在もメンテされているgo製のSOCKS5関連ライブラリでは一番メジャーか。

クライアントもある。

自分のfork（[https://github.com/ge9/socks5 https://github.com/ge9/socks5]）ではFull Cone NATを追加した


==== armon/go-socks5 ====

[https://github.com/armon/go-socks5 https://github.com/armon/go-socks5]

starは2kだが、最終更新2016年でUDP Associateも無し。Wireproxyで以前使われていたが使われなくなった（[https://github.com/whyvl/wireproxy/issues/15 https://github.com/whyvl/wireproxy/issues/15]）。

ここからフォークされたものが複数ある。


==== things-go/go-socks5 ====

[https://github.com/things-go/go-socks5 https://github.com/things-go/go-socks5]

armon/go-socks5からのフォーク（GitHub上ではfork扱いではない）。starは400個ほど。UDP Associateはサポートしているがバグあり（自分のPRが採用されるかどうかで揉めてる[https://github.com/things-go/go-socks5/pull/63 https://github.com/things-go/go-socks5/pull/63]）。

Wireproxyで使われている。

自分のフォーク [https://github.com/ge9/go-socks5 https://github.com/ge9/go-socks5] ではFull Cone NATを追加した


==== haxii/socks5 ====

[https://github.com/haxii/socks5 https://github.com/haxii/socks5]

armon/go-socks5からのfork。UDP Associate対応。starは50個前後。最終更新2019年。


==== wzshiming/socks5 ====

[https://github.com/wzshiming/socks5 https://github.com/wzshiming/socks5]

クライアントもある。

starは90個ほど。最終更新2024年。

とりあえずredsocksと組み合わせでUDP透過プロキシ動作確認済。

Wireproxyで使用が検討された（[https://github.com/whyvl/wireproxy/issues/15 https://github.com/whyvl/wireproxy/issues/15]）が結局使用されず。


==== haochen233/socks5 ====

[https://github.com/haochen233/socks5 https://github.com/haochen233/socks5]

クライアントもある。

UDP Associateはサポートしているが、starは49とさらに少なく、最終更新も2021年。

同じくWireproxyで使用が検討された（[https://github.com/whyvl/wireproxy/issues/15 https://github.com/whyvl/wireproxy/issues/15]）が結局使用されず。


== 透過SOCKSプロキシクライアント ==

[https://turgenev.hatenablog.com/entry/2024/03/25/160556 透過プロキシを用いて特定アプリケーションのTCP・UDP通信をSOCKS5経由にする方法（Windows・Linux（iptables TPROXY）・Androidなど） - turgenev’s blog]で扱った内容。

バックにSOCKS(SOCKS5)プロキシを用いてTCP・UDPのレイヤで透過プロキシを行うもの。VPNと同等の動作で、基本的には管理者権限（Linuxの場合、最低でもCAP_NET_ADMIN）が必要。

以下のいずれも、ドメイン解決にはプロキシが適用されない（Linux向けの2つはできなくはないかもしれないが、しづらい）ことに注意。

==== redsocks ====

[https://github.com/semigodking/redsocks semigodking/redsocks] （fork元の[https://github.com/darkk/redsocks darkk/redsocks]はメンテされておらず、TCPのTPROXYに非対応）

*nix対応。BSD系で動かすことができたという話は[https://turgenev.hatenablog.com/entry/2024/06/10/134017 FreeBSD/OpenBSD/NetBSDで透過プロキシのredsocksを動かしてみる - turgenev’s blog]に書いた。

==== hev-socks5-tproxy ====

[https://github.com/heiher/hev-socks5-tproxy https://github.com/heiher/hev-socks5-tproxy] Linux向け。redsocksより若干知名度は下がるものの、きちんとメンテされている。


==== ProxiFyre ====

[https://github.com/wiresock/proxifyre https://github.com/wiresock/proxifyre] Windows用の透過SOCKSクライアント。管理者権限必要。TCP/UDP両方対応。インストールも簡単で、よくできている。


==== Proxifier ====

[https://www.proxifier.com/ https://www.proxifier.com/] 見た感じ機能は十分そうだが、有料なので試していない。


== VPN(tun) ==

上記と似ているが、VPNとして動作するもの。プロセスが特定しづらい場合・特定のIPアドレス範囲だけで十分な場合などに効果を発揮する。

以下は特筆しない限りUDP Associateに対応。もちろん、pingなどは通らない。

==== tun2proxy ====

[https://github.com/tun2proxy/tun2proxy https://github.com/tun2proxy/tun2proxy]

Rust製。starは700ほど。SOCKSとHTTPをtunにしてくれる。

==== hev-socks5-tunnel ====

[https://github.com/heiher/hev-socks5-tunnel https://github.com/heiher/hev-socks5-tunnel]

hev-socks5-tproxyの作者による。Androidアプリの[https://github.com/heiher/sockstun https://github.com/heiher/sockstun]もここから。

== ライブラリ関数ハック系 ==

ライブラリ関数レベルでの置き換えになるため厳密性・安定性に欠ける（異常終了する場合もある）ものの、root権限がない場合に有効な手法。


=== Linux（LD_PRELOAD） ===

libc依存でないプログラム（Go製のものなど）には効かない。

==== socksify ====

後述のDanteの一部。UDP/TCP両対応。唯一のUDP対応のものである。

<syntaxhighlight lang="go">route {
from: 0.0.0.0/0 to: 0.0.0.0/0 via: 192.168.1.1 port = 1080
}</syntaxhighlight>
こんな感じの<code>/etc/socks.conf</code>を作るか、<code>SOCKS5_SERVER=192.168.1.1:1080 socksify curl http://ipv4.icanhazip.com</code> とかでもよい。

Macでも動くはずだが、筆者が唯一試したMac環境ではcurlに対してさえうまく動作しなかった（socksifyを使わないのと全く同様に動作するだけだった）（<code>DYLD_FORCE_FLAT_NAMESPACE=1</code>は指定している）。


==== proxychains-ng(proxychains) ====

ngはnew generationの略で、proxychainsの後継である。ただしコマンド名はproxychains4である。

多段プロキシを構成するためのソフトウェア。

UDP非対応（[https://github.com/rofl0r/proxychains-ng/issues/336 https://github.com/rofl0r/proxychains-ng/issues/336]）。ただしDNSに対応したproxy_dnsというオプションがあり、これを有効にするとDNS以外のUDP通信が正常に機能しなくなる副作用がある（[https://github.com/rofl0r/proxychains-ng/issues/103 https://github.com/rofl0r/proxychains-ng/issues/103]）。


==== torsocks(tsocks) ====

多分、メンテされていないtsocksがTorに取り込まれてtorsocksになったような感じ。tsocksは非常に古く、多分2010年以降には更新されていないが、知名度は高く、今でも多分そこそこ使われてそう。

torsocksはアクティブなはず。ただし、Torでない普通のSOCKS5を指定しても動かないようである（やり方が悪いかも）。

tsocksはUDPには対応していない。torsocksもそうだが、まずそもそもTor自体がUDPに対応していない。


=== Windows（DLL Hijacking） ===

どのDLLを置き換えたらいいか自明ではなさそうなので、LD_PRELOADと違って対象とするソフトウェアごとに実装が必要そう。そもそも不可能なソフトウェアもLD_PRELOADの場合より多そう。よく見かけるのはDiscordを対象にしたもので、ロシア系のものが多い。筆者は使ったことがない。

==== discord-drover ====

[https://github.com/hdrover/discord-drover https://github.com/hdrover/discord-drover]

==== discord-voice-proxy ====

[https://github.com/runetfreedom/discord-voice-proxy https://github.com/runetfreedom/discord-voice-proxy]


== HTTPプロキシ ==

Squid, Privoxyなどが有名。

Squidには透過プロキシ機能があるが、redsocksなどとは動作の細かい部分が異なる。[https://turgenev.hatenablog.com/entry/2025/03/25/171736 squidで透過プロキシ（intercept, tproxy）を動かす - turgenev’s blog]に書いた。


== localhost・LANなどへのアクセス制限 ==

典型的な設定例として、localhostやプライベートIPへのアクセスを制限する設定をSquid・Dante・3proxyそれぞれに関して紹介しておく。

プロキシ側で設定せず、cgroupなどを使ってファイアウォール側で制御する方法もある。

==== squid ====

<code>to_localhost</code>はbuilt-inとして定義されていて、<code>localnet</code>（=srcがlocalnet）についてもUbuntuパッケージで提供されるsquid.confには入っているのだが、localnetがdstであるものとなるとACLが定義されていない。

<code>deny to_localhost</code>と<code>deny to_linklocal</code>は定義済みという前提で、以下のように書くとよい。

<syntaxhighlight lang="go">acl to_localnet dst 0.0.0.1-0.255.255.255
acl to_localnet dst 10.0.0.0/8
acl to_localnet dst 100.64.0.0/10
acl to_localnet dst 172.16.0.0/12
acl to_localnet dst 192.168.0.0/16
acl to_localnet dst fc00::/7

http_access deny to_localnet</syntaxhighlight>

==== 3proxy ====

IPv4のみ対応。

<syntaxhighlight lang="go">deny * * 127.0.0.0/8,0.0.0.1-0.255.255.255,10.0.0.0/8,100.64.0.0/10,169.254.0.0/16,172.16.0.0/12,192.168.0.0/16 * * * *
allow *</syntaxhighlight>

==== dante ====

IPv4のみ対応。squid・3proxyの場合と違って0.0.0.0もblockしてしまっているが、そもそも使わないので問題ないはず。

<syntaxhighlight lang="go">client pass {
from: 0/0 to: 0/0
}

socks block {
from: 0/0 to: 127.0.0.0/8 # localhost
protocol: tcp udp
command: bind connect udpassociate bindreply udpreply
}
socks block {
from: 0/0 to: 0.0.0.0/8 # RFC 1122 "this" network (LAN)
protocol: tcp udp
command: bind connect udpassociate bindreply udpreply
}
socks block {
from: 0/0 to: 10.0.0.0/8 # RFC 1918 local private network (LAN)
protocol: tcp udp
command: bind connect udpassociate bindreply udpreply
}
socks block {
from: 0/0 to: 100.64.0.0/10 # RFC 6598 shared address space (CGN)
protocol: tcp udp
command: bind connect udpassociate bindreply udpreply
}
socks block {
from: 0/0 to: 169.254.0.0/16 # RFC 3927 link-local (directly plugged) machines
protocol: tcp udp
command: bind connect udpassociate bindreply udpreply
}
socks block {
from: 0/0 to: 172.16.0.0/12 # RFC 1918 local private network (LAN)
protocol: tcp udp
command: bind connect udpassociate bindreply udpreply
}
socks block {
from: 0/0 to: 192.168.0.0/16 # RFC 1918 local private network (LAN)
protocol: tcp udp
command: bind connect udpassociate bindreply udpreply
}

socks pass {
from: 0/0 to: 0.0.0.0/0
protocol: tcp udp
command: bind connect udpassociate bindreply udpreply
}</syntaxhighlight>

== SOCKS関連の話題 ==


==== NATが介在する場合などのUDP Associateの動作 ====

OpenSSHの項目でも関連することを述べたが、UDP-over-TCPの性能劣化を避けるため、UDP Associateは「サーバー側がクライアント側に対してUDP通信で使うための中継ポートを通知する」という動作を伴う。この際、ネットワーク上でクライアント側からサーバーが直接見えていればよいが、NATを介している場合、クライアントから見たときのサーバーのIPとサーバー自身から見たときのサーバーのIP（中継ポート通知に含まれるのはこれ）が異なることがあり、通信が成立しなくなってしまう（SSHのポート転送を普通に使うだけではUDP Associateが使えないのも直接にはこれが原因）。

ただし、[https://turgenev.hatenablog.com/entry/2024/03/25/160556 透過プロキシを用いて特定アプリケーションのTCP・UDP通信をSOCKS5経由にする方法（Windows・Linux（iptables TPROXY）・Androidなど） - turgenev’s blog]にも書いた通り、Proxifyreやhev-socks5-tproxyなどは中継ポート通知のIP部分を無視するため、ポート番号が変わらないNATであれば問題なく動作する（redsocksはダメ）。


==== SOCKS5によるドメイン解決 ====

SOCKS5（SOCKS4aも？）では、クライアントがCONNECTなどの要求をする際、接続先をIPアドレスではなくホスト名（ドメイン名）で指定することができる仕様になっている。これによりクライアント側ではなくSOCKS5サーバー側でドメイン解決が行われる。

透過SOCKSプロキシの場合、TCP/UDPレイヤでのプロキシとなるので、この機能が使われることはない（[https://turgenev.hatenablog.com/entry/2024/03/25/160556 透過プロキシを用いて特定アプリケーションのTCP・UDP通信をSOCKS5経由にする方法（Windows・Linux（iptables TPROXY）・Androidなど） - turgenev’s blog]）（さらに、繰り返しになるが付け加えておくと、普通にセットアップした場合はDNSにプロキシは使われない）。一方、HTTPのレイヤで動作するWebブラウザでは、この機能が使われる場合がある。2018年時点での[https://github.com/FelisCatus/SwitchyOmega/issues/1379 https://github.com/FelisCatus/SwitchyOmega/issues/1379]によれば、Chromeでは必ずSOCKS5サーバー側でドメイン解決が行われる（これは[https://github.com/FelisCatus/SwitchyOmega/wiki/FAQ FAQ]にも書いてある）一方、Firefoxではそうでなかったようである。現在のFirefoxでは「SOCKS v5 を使用するときは DNS もプロキシーを使用する（Proxy DNS when using SOCKS v5）」（v4についても同様のオプションがあるが、SOCKS4aではないSOCKS4でどうなるかは未検証）というオプションがあってデフォルトで有効になっているため、やはり基本的にはSOCKSサーバー側でドメイン解決が行われる。AndroidのFirefox（この設定項目がない）にProxy SwitchyOmegaを入れた場合もそのように動作した。

なお、HTTPプロキシについても、ブラウザで普通に使う分には、（HTTP/HTTPS共に）ドメイン解決は基本的にプロキシサーバー側で行われる。

* 拡張機能などではうまく動作しない場合がある模様。 [https://github.com/FelisCatus/SwitchyOmega/issues/2304 https://github.com/FelisCatus/SwitchyOmega/issues/2304]


==== ブラウザのSOCKS5プロキシのWebRTC対応 ====

基本的に現在主流のブラウザ（Firefox, Chrome）のSOCKS5プロキシ機能（拡張機能で設定する場合を含む）はUDPには対応していないため、Discordの通話などWebRTC関係の機能を使うと生IPが漏洩する（またはそれを防ごうとすると単にその機能が使えない）。これは原理的に実装が不可能なわけではなく、単に需要が少ないから実装されていないだけである。

* Chromeではどれが最新か不明（最近の物は少ない）。このへんとか？[https://issues.chromium.org/issues/41180783 Chromium]
* torのバグ報告 [https://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/151 https://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/151]
* firefoxの [https://bugzilla.mozilla.org/show_bug.cgi?id=1808692 https://bugzilla.mozilla.org/show_bug.cgi?id=1808692]
** QUIC関連 [https://bugzilla.mozilla.org/show_bug.cgi?id=1882071 https://bugzilla.mozilla.org/show_bug.cgi?id=1882071]
** 新しめの包括的なバグレポート [https://bugzilla.mozilla.org/show_bug.cgi?id=1947229 https://bugzilla.mozilla.org/show_bug.cgi?id=1947229]

従って、ブラウザのWebRTCをプロキシさせたい場合はVPNや透過プロキシなどroot/管理者権限が必要な手法を使うことが多くなるだろう。ただしLinux+Firefoxの場合はsocksifyが使えるのでrootが無くても可能。


==== UDP AssociateリクエストのDST.ADDRとDST.PORT ====

クライアントがサーバー側にUDP Associateリクエストをするとき、この2フィールドには通信したい宛先ではなく（←というかそもそもそれが複数ある場合もある）、クライアント側がUDP Associateに使用する予定のポートを入れる。指定しない場合（例えばNATがある場合、これを予測するのは難しくなる）は、全ビットを0に設定する必要がある。

これによってサーバー側は、UDPパケットが送られてきたタイミングでそれが事前に通知されたものと一致するかどうか確認できるというわけである。

この部分に誤ってクライアント側が通信したい宛先ポートを入れるよう実装していたSOCKS5クライアントがいくつかある。

* semigodking/redsocks…自分の[https://github.com/semigodking/redsocks/issues/210 https://github.com/semigodking/redsocks/issues/210]で修正済み。
* gost…[https://github.com/ginuerzh/gost/issues/96 https://github.com/ginuerzh/gost/issues/96]で修正済み。
* txthinking/socks5…[https://github.com/txthinking/socks5/issues/15 https://github.com/txthinking/socks5/issues/15]で修正済み。
* things-go/go-socks5…これはサーバー側。[https://github.com/things-go/go-socks5/issues/29 https://github.com/things-go/go-socks5/issues/29]の通り、クライアントが必ずアドレス・ポートを通知してくれる（ゼロ埋めしない）と仮定していたが、修正された。

== プロキシプロトコル間の変換 ==

==== socks-to-http-proxy ====

[https://github.com/KaranGauswami/socks-to-http-proxy https://github.com/KaranGauswami/socks-to-http-proxy]

名前の通り、socksをhttpにしてくれる。starは250ほど。

==== privoxy ====

基本的にはHTTPプロキシソフトウェア。socksプロキシをhttpプロキシとして使えるようにする機能はあるが、より大がかり（一般ユーザーでの実行がしづらい）


== UDP・Wireguard関連 ==


==== UDPでサーバー→クライアントにデータ送信 ====

[https://github.com/prof7bit/udp-reverse-tunnel https://github.com/prof7bit/udp-reverse-tunnel]

これを使うと、サーバー側だけでポートが開けられるとしても事実上クライアント側で開けられるのと同等になるのでreverseをするのが楽になる

* [https://superuser.com/questions/1737943/how-to-create-a-reverse-udp-tunnel https://superuser.com/questions/1737943/how-to-create-a-reverse-udp-tunnel]
* どっちも開放できない場合、UDPホールパンチングで何とかするしかない

==== wgslirpy ====

[https://github.com/vi/wgslirpy https://github.com/vi/wgslirpy]

Slirp（ユーザーランドで動くPPPサーバーのようなもの）のような形で実装されたWireguardサーバー。rootなしでWireguardサーバーとして動作する。

==== wireproxy ====

[https://github.com/whyvl/wireproxy https://github.com/whyvl/wireproxy]

wgslirpyの逆のような（？）ツール。Wireguardクライアントであるが、SOCKSサーバーとして動作する。

依存ライブラリのUDP Associate対応が不完全（自分がプルリクを送っている）だが、クライアントによってはうまくUDP Associateが動く（[https://github.com/whyvl/wireproxy/issues/30 https://github.com/whyvl/wireproxy/issues/30]）。

<ul>
<li>自分でカスタマイズしてCone NATを加えたthings-go/go-socks5を使えば（<code>go.mod</code>で<code>replace github.com/things-go/go-socks5 => ../../go-socks5</code>などとする）、以下のようなコードをroutine.goのsocks5.Optionのところに追加することでCone NATにできる。
<syntaxhighlight lang="go">socks5.WithDialUDP(func(laddr, raddr *net.UDPAddr) (net.PacketConn, error) { return vt.Tnet.DialUDP(laddr, raddr) }),</syntaxhighlight></li></ul>


=== Wireguard通信の確立: 各パターンでのやり方 ===

各状況に応じて、2端末間でUDPの暗号化された通信路を確立するための方法を書いた。

* forwardは「クライアント→サーバー」、reverseは「サーバー→クライアント」という意味。「サーバー」は、「ポートが開放できる方」という意味合い。

==== どっちもrootあり ====

普通にWireguardを使う

==== サーバーのみrootあり ====

forward

サーバーはWireguard、クライアントは普通にWireproxyでいける

reverse

udp-reverse-tunnelで頑張って逆にする（あるいはホールパンチング）。

その上で、wgslirpyを使うか、Hysteriaを使うか

==== クライアントのみrootあり ====

↑さっきと逆

forward

wgslirpyを使うか、Hysteriaを使うか

reverse

udp-reverse-tunnelで頑張ったうえで普通にWireguardとWireproxy

==== どっちもrootなし ====

この場合そもそもWireguardを使うメリットはあまりないかも。というのとrootがないならポート開放も無理そう

forward

Hysteriaでいけそう。

reverse

udp-reverse-tunnelしてHysteria？かな

== その他の話題 ==

==== ドメインごとにプロキシを変更できるブラウザ拡張のiframeにおける動作 ====

FoxyProxyやSwitchyOmega(ZeroOmega)など、ドメインごとに自動でプロキシを切り替えてくれるブラウザ拡張はChromium系にもFirefoxにもいくつかあるが、これらはあくまでコンテンツのオリジンを元にプロキシを適用しており、ブラウザのタブを見ているわけではない。つまり、foo.comのページを開いていて、そこにbar.comのコンテンツがiframeで埋め込まれている場合、iframeの内部は、bar.comに対して使用するものと指定されたプロキシを使用して処理される。

一応、[https://superuser.com/questions/250172/disable-enable-the-proxy-on-a-tab-by-tab-basis-in-firefox Disable/enable the proxy on a tab by tab basis in Firefox]によると、Firefoxのcontainer-proxyというのがこれに近い機能を実質的に実現してくれるらしい。
[[Category:IT]]{{#seo:|title={{FULLPAGENAME}} - Turgenev's Wiki}}

定理証明支援系Lean

2025-09-01T01:31:44Z

Turgenev: Notion-MW

Leanは、比較的新しい定理証明支援系（Lean以外にはCoqやIsabelleなどがある）である。

== 概要 ==

学術研究用なのもあって特にメジャーバージョンアップでは大きな破壊的変化がある。

Lean2以前はよく調べていないがLean2にはHoTTサポートがあって3で無くなったらしい。3→4ではマクロシステムが刷新されたり、Leanの処理系のうちLean自体で書かれた部分がさらに増えたり？した。


=== Lean3 ===

[https://leanprover.github.io/ 公式]（githubでの名前はleanprover）と、[https://leanprover-community.github.io/ 半分公式みたいなコミュニティ]（githubでの名前はleanprover-community）があって、公式では3.4.2まででアーカイブされているLean3もコミュニティversionでは3.47.0くらいになっている。また様々な分野の証明を集めたライブラリの[https://github.com/leanprover-community/mathlib mathlib]もコミュニティの成果物である。

もうほとんど使われていないだろう。


=== Lean4 ===

Lean4は現在のところ「公式」のみで扱われている。手元では、WindowsとMacではしばらく動かなかったが、2022年9月中旬頃にelanが1.4.2になったタイミングで動くようになった。しかしVSCode拡張は大文字/小文字の区別をうまく扱えずGo to definitionが失敗する（大文字/小文字の区別があるファイルシステムではおそらく問題なし？？）。既知のバグ。やなど。

VSCodeでの体感でもチェッカがLean3より明らかに速くなった。

== 学習用リソース ==


==== Lean3 ====

[https://leanprover-community.github.io/learn.html https://leanprover-community.github.io/learn.html]にリストされている。

最も基本的な使い方の解説が[https://leanprover.github.io/theorem_proving_in_lean/ Theorem Proving in Lean]であり、Leanを使って定理証明をする方法の概略が掲載されている。とりあえずはこれを読んでいけばいい。比較的よくまとまった資料であるが、Curry-Howard同型についてなど、型理論や証明論の事前知識が多少はないと読むのはやや大変かもしれない。そのあたりの知識から解説しているものもいちおう上記の一覧にある。

各tacticの動作など、辞書的な説明は[https://leanprover.github.io/reference/ reference manual]に載っている場合もあるが、こちらは未完成である。

Programming in leanというのもあるが、これも少なくとも最近はあまりメンテナンスされていない。

<div style="overflow:auto;width: 100%; max-width: 1200px; white-space:nowrap; border:1px solid; padding-left: 10px; padding-right: 10px;" class="mw-collapsible">
<div>Programming in leanに関する詳細</div>
<div class="mw-collapsible-content">

これまた未完成ではあるが[https://avigad.github.io/programming_in_lean/index.html Programming in Lean — Programming in Lean 3.4.2 documentation]を見ると説明が載っているかもしれない。programming in leanで検索すると、

[https://leanprover.github.io/programming_in_lean/programming_in_lean.pdf https://leanprover.github.io/programming_in_lean/programming_in_lean.pdf]

[https://leanprover.github.io/programming_in_lean/ https://leanprover.github.io/programming_in_lean/]

（この2つは同じ内容）

も出てくるが、こちらはリポジトリ([https://github.com/avigad/programming_in_lean avigad/programming_in_lean])と比較すると古いバージョンのようである（リポジトリの”old”フォルダの内容に対応している）。

</div></div>


==== Lean4 ====

前述の各資料に対応して[https://leanprover.github.io/theorem_proving_in_lean4/title_page.html https://leanprover.github.io/theorem_proving_in_lean4/title_page.html]と[https://leanprover.github.io/lean4/doc/ https://leanprover.github.io/lean4/doc/]と[https://leanprover.github.io/functional_programming_in_lean/ Functional Programming in Lean]がある。


== Publications ==

関連論文など

[https://leanprover.github.io/publications/ https://leanprover.github.io/publications/]

== 日本語情報 ==

[https://turgenev.hatenablog.com/entry/2020/11/25/095208 定理証明支援系Leanのインストールと初期設定（Linux）]（自分で書いたが、古いのでもう読まなくていい）

[https://manau.jp/lean/leaninstall/ 定理証明支援系 LEAN のインストール]

[http://myuon-myon.hatenablog.com/entry/2016/01/09/212750 Theorem Prover Leanの紹介 - Just $ A sandbox]

[https://myuon.github.io/posts/start-learning-proof-assistant/ 定理証明リンク集]

くらい。あんまりないが、順調にいけば今後増えていきそうではある。

* 2025/6追記最近はもっと増えてそう

== metaprogramming関連 ==

Leanの証明記述用言語（tactic）は、Leanそれ自体の上で実装されている。バージョン3→4によってさらにその傾向が強まりそうである。

tacticはmonadicな関数として実装されている。tacticをmonadで表現するというのはCoq用のMtac[^ziliani2013Mtac]などでも採用された手法である。


=== Lean3での例 ===

筆者は研究活動の一環として、Lean 3のソースコード上に構造的に関連付けられた形でコメントを書けるようにするライブラリであるNtac（[https://github.com/ge9/ntac https://github.com/ge9/ntac]）を公開している。これはLean 3のmetaprogrammingを活かした例である。

metaprogrammingについてはコミュニティのLearning resourcesの”Metaprogramming and tactic writing”の項目や[https://leanprover.github.io/papers/tactic.pdf https://leanprover.github.io/papers/tactic.pdf]を参考にした。また、独自のtacticシステムを作成するためのガイドとして、[https://leanprover-community.github.io/archive/stream/113488-general/topic/no.20lean.20messages.20output.20in.20hacked.20mode.html https://leanprover-community.github.io/archive/stream/113488-general/topic/no.20lean.20messages.20output.20in.20hacked.20mode.html]に実装上のヒントを得た。

* 基本的には、<code>tactic</code>という名前でStateモナドが定義されていて、各tacticはこのモナド値を返す関数として定義されている。しかし<code>tactic</code>は現在の状態しか持っておらず、コメントを紐づけたりするには証明の過程まで含めた全体の構造が欲しい。そこでntacでは、<code>tactic</code>の定義を変更して証明の「履歴」を木構造として保持するようにした<code>ntac</code>というモナドを定義し、既存のtacticを（適切な）<code>ntac</code>モナド値を持つような定義に変更した。


=== Lean4 ===

Schemeを参考に、強力な衛生的（hygienic）マクロシステムが実装された。柔軟なNotationの定義ができるようになる。論文としては[^ullrich2020Notations]に詳しく書いてある。

上記「ntac」のLean4版は現在開発中。構文解析中に外部のプログラムを呼び出すなど、なんでもできて面白い。

==== 例 ====

* replしてる例らしい [https://github.com/leanprover-community/repl https://github.com/leanprover-community/repl]

==== tacticの移行とか ====

Lean3までの証明（のうちtacticで書かれたもの）をLean4に移植する方法について。 
[https://leanprover.zulipchat.com/#narrow/stream/287929-mathlib4/topic/Tactic.20porting.20assignments/near/296694161 https://leanprover.zulipchat.com/#narrow/stream/287929-mathlib4/topic/Tactic.20porting.20assignments/near/296694161]

* とりあえず [[error_private_page|error_private_page]] で基礎知識を得るのがよさそう？

== elan ==

* leanを管理（各バージョンのインストール/アンインストールなど）するためのツール
* 適当にフォルダだけ消すとtoolchainの再インストールで引っ掛かるので、update-hashesも消すとよいかも
* rustupのforkらしい [https://zenn.dev/labbase/articles/b24dca38e0420d 関数型言語”兼”定理証明支援系Leanの環境構築]


== Lean3 ==

[https://leanprover-community.github.io/get_started.html https://leanprover-community.github.io/get_started.html] を読む。elanってやつが入れば大丈夫で、mathlib-toolsとかleanprojectは（今はもう案内ないか？）無視でいい（後述）

=== パッケージ ===

Leanでの開発はまずパッケージを作るところから始まる。

leanpkg.tomlっていうメインの管理ファイルがあって、ここにLeanのバージョンとかを指定しておくと、無ければ（VS Codeでフォルダ開くタイミングとかで）自動でelanが取ってきてくれる

* 特定パッケージと、そのパッケージに依存するパッケージの双方を依存関係として指定したとして、バージョンの齟齬があったら何が起きるのかは不明である。ちなみにLean4の話だが、mathlib4に関しては[https://github.com/leanprover-community/mathlib4 https://github.com/leanprover-community/mathlib4]に「If your project depends on <code>std4</code> or <code>quote4</code>, let <code>mathlib4</code> pull them transitively. That is, don't <code>require</code> them on your <code>lakefile.lean</code>」と明記されている。

=== mathlib ===

パッケージの一つ。半分標準のライブラリみたいなもの。数学の定理やリスト処理のプログラムなど、色々なものが形式化されている。文字列処理とかの便利関数も入ってるのでとりあえず入れて損はない

[https://leanprover-community.github.io/mathlib-overview.html https://leanprover-community.github.io/mathlib-overview.html]

=== mathlibの指定 ===

leanpkg.tomlで

<syntaxhighlight lang="javascript">mathlib = {git = "https://github.com/leanprover-community/mathlib", rev = "lean-3.49.1"}</syntaxhighlight>
のように指定しておくと

<syntaxhighlight lang="javascript">leanpkg upgrade</syntaxhighlight>
でlean-3.49.1ブランチを取ってきてくれる。masterブランチ指定とかするとバージョンアップで互換性がなくなって困るのでこれがおすすめ。

=== mathlib-toolsとleanprojectについて ===

* 基本Lean3用なのでもう使われないかも

leanprojectは[https://github.com/leanprover-community/mathlib-tools mathlib-tools]の一部で、mathlibをうまく扱うのが目的っぽい。<code>python3 -m pip install mathlibtools</code>で入る

prebuiltされた（ちなみに自前でビルドすると数時間かかる）mathlibを

<syntaxhighlight lang="javascript">https://oleanstorage.azureedge.net/mathlib/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.tar.xz</syntaxhighlight>
（xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxはコミットID）からダウンロードして、oleanにtouchして最新版にしてくれるが、それだけの機能しかなく、動作もあまり分かりやすくない。しかもよくわからんが、Lean4には未対応っぽい（というか、mathlibというのはLean3のパッケージの名前なのでそれはそうか（Lean4用のmathlibはmathlib4））。このまま使われなくなりそう。

そこで、自分でそれをやるスクリプトを書いてpathに登録した。これで十分と感じる。

<syntaxhighlight style="margin-bottom:0.2em;" lang="javascript">#!/bin/sh
if ! cd ../../../_target/deps/mathlib ;then
echo "must be run in 'mathlib' folders. exiting."; exit
fi
find src -name "*.olean" | xargs rm
curl -o olean.tar.xz https://oleanstorage.azureedge.net/mathlib/`cat .git/HEAD`.tar.xz
#touch all .olean (this is also done by leanproject in mathlib-tools)
find src -name "*.olean" | xargs touch
if tar xvf olean.tar.xz ; then
rm -f olean.tar.xz
fi</syntaxhighlight>
<div style='text-align: center;'>new-oleans.sh</div>


== Lean4 ==

=== 初期設定 ===

[https://github.com/leanprover/elan elan]をまず入れてそれからLeanを、ってのがv3以前のやり方だったと思うが[https://leanprover.github.io/lean4/doc/quickstart.html Setting Up Lean - Lean Manual]によるとどうやらv4はVS Code拡張経由で入れられるようである。


=== パッケージ(lake) ===

<code>lake new パッケージ名（パッケージ名と同じ名前のフォルダが作成され、その中にパッケージができる）</code>、または<code>lake init パッケージ名（パッケージはカレントディレクトリに作成される）</code>を実行。詳しいやり方は[https://github.com/leanprover-community/mathlib4 https://github.com/leanprover-community/mathlib4] とか。

lakeのドキュメントはここ [https://github.com/leanprover/lean4/tree/master/src/lake https://github.com/leanprover/lean4/tree/master/src/lake]

dependencyの書き方は [https://github.com/leanprover-community/mathlib4/blob/master/lakefile.lean https://github.com/leanprover-community/mathlib4/blob/master/lakefile.lean] とかを参考に。stdのURLがここにある。

=== mathlib4 ===

prebuiltされたものの提供はないっぽい。[https://leanprover.zulipchat.com/#narrow/stream/287929-mathlib4/topic/.E2.9C.94.20use.20prebuilt.20release.3F https://leanprover.zulipchat.com/#narrow/stream/287929-mathlib4/topic/.E2.9C.94.20use.20prebuilt.20release.3F]

* いや、[https://github.com/leanprover-community/mathlib4 https://github.com/leanprover-community/mathlib4]を読むと、<code>lake exe cache get</code>で取ってこれるように最近なった？

そのかわりlake build Mathlibと打てば（lean3のmathlibに比べて）割とすぐにビルドが終わる（5分前後？）

<syntaxhighlight lang="javascript">require ml4 from git "https://github.com/leanprover-community/mathlib4" @ "master"</syntaxhighlight>
↑依存パッケージとしてはこういうふうに書くが、lake build ml4ではなくlake build Mathlibが正しいっぽい。

* そもそも、require ml4じゃなくてrequire mathlibと必ず書かなきゃいけない説もある
[[Category:IT]]{{#seo:|title={{FULLPAGENAME}} - Turgenev's Wiki}}

Windowsの右クリックメニューから複数ファイルをまとめて開く

2025-06-30T09:02:50Z

Turgenev: Notion-MW

複数のファイルを別々にではなく一度にまとめて開きたいということがある。すなわち”app.exe file1” “app.exe file2”…をそれぞれ実行するのではなく、”app.exe file1 file2 …”を実行したい。例えば複数の音楽ファイルを連続再生したいときなどである。

ただ、エクスプローラ上で複数ファイルを選択して開く（右クリックで「開く」を選ぶorエンターキー）と、別々に実行されてしまう。では、右クリックメニューからこれを実行するにはどうすればいいか？というのがこの記事のテーマである。

ついでに、パス長さ制限を超えるファイルやフォルダにおける機能制限も解決する。


== Windows10以前の右クリックメニューに戻す ==

まず、Windows11に移行すると右クリックメニューの項目数が大幅に削られており、とても使いにくいので、Windows10までの仕様に戻す必要がある。[https://pc-karuma.net/right-click-context-menu-back-on-windows-11 Windows 11 - 右クリックメニューを旧仕様に戻す方法 - PC設定のカルマ]などに従って修正しよう。コマンド例は以下。これはユーザーごとの設定なので、管理者権限は不要である。

<syntaxhighlight lang="javascript">reg add "HKCU\Software\Classes\CLSID\{86ca1aa0-34aa-4e8b-a509-50c905bae2a2}\InprocServer32" /f /ve</syntaxhighlight>
ファイルを開く操作ならダブルクリックでできるわけで、それでもあえてファイルを右クリックするユーザーの層を考えれば、使用頻度の高いメニューに絞る必要がないことは明らかである。右クリックメニューは動作が重いという問題点も指摘されてきたが、それなら項目数を削る以外の方法でパフォーマンスを改善するのが筋だろう。そもそも、Windows 11の右クリックメニューもそれほど快適な動作ではない。

なおバージョン22H2からはShift+右クリックで旧仕様のメニューが出るようになったようなので、それで十分という人は設定しなくてもよい。

ちなみにこれ以降も同じだが、<code>HKEY_CURRENT_USER</code>以下はユーザー別設定なのでPC自体の再起動をしなくてもログアウト（サインアウト）→ログイン（サインイン）で全て反映されるはず。また今回の例に関しては、実際にはexplorerの再起動で十分である。

=== 動画の右クリックメニューの順番がおかしい ===

動画ファイル（mp4やmkvなど）に関して、右クリックメニューの順番がおかしくなるという問題がある。具体的には、全ファイル共通のメニュー（「お気に入りに追加」など）とClipchampのメニューが普通の「開く」よりも上に表示されてしまう。また単一ファイル選択時だと（関連付けがすでに設定されているにもかかわらず）「プログラムから開く」が太字になってしまっている。

* 単一ファイル選択時

<div class="res-img">https://turgenev.cloudfree.jp/mw1/imgs/win-rc/clipchamp-sing.png</div>

* 複数ファイル選択時

<div class="res-img">https://turgenev.cloudfree.jp/mw1/imgs/win-rc/clipchamp-mult.png</div>

これはどうやらClipchampのメニューが悪いらしく、[https://www.elevenforum.com/t/add-or-remove-edit-with-clipchamp-context-menu-in-windows-11.6882/ Add or Remove Edit with Clipchamp Context Menu in Windows 11 Tutorial | Windows 11 Forum]（[https://www.elevenforum.com/t/clipchamp-context-menu-removal.6150/ Clipchamp context menu removal | Windows 11 Forum]に書いてあった）や[https://www.naporitansushi.com/clipchamp-context-menu-disable/# Windowsの右クリックの「Clipchampで編集」を削除する方法 | ナポリタン寿司のPC日記]に書いてある通り、Clipchampのメニューを非表示にすると治る。コマンド例は以下。

<syntaxhighlight lang="javascript">reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Shell Extensions\Blocked" /v {8AB635F8-9A67-4698-AB99-784AD929F3B4} /f</syntaxhighlight>
* HKLMでも設定できる。また、「デバイスキャスト」を非表示にする場合はUUIDを<code>{7AD84985-87B4-4a16-BE58-8B72A5B390F7}</code>に変える。

Clipchampを表示したまま順番を治す方法は不明だが、自分でメニューを作ればできるかもしれない。Clipchampのメニューの実装に使われていると思われるIContextMenuについては後でも述べているのでそちらも参照。おそらくClipchampによるこのインターフェースの実装にバグがあるためにこのような挙動をしているのであろう。

以下に修正後の正しい表示を載せておく。いずれの例でも関連づけはデフォルトのメディアプレイヤーが使われているものと仮定している（書いていて気付いたが、同一アプリにもかかわらず「プレーヤー」「プレイヤー」の表記ゆれがある）。

* 単一ファイル選択時

<div class="res-img">https://turgenev.cloudfree.jp/mw1/imgs/win-rc/sing.png</div>

* 複数ファイル選択時

<div class="res-img">https://turgenev.cloudfree.jp/mw1/imgs/win-rc/mult.png</div>

== 不完全な解決策 ==

本題に入る。まずは、不完全ではあるがそこそこ簡単な解決策を紹介する。それは右クリックメニューにある「送る」を使う方法である。エクスプローラのアドレスバーに<code>shell:sendto</code>と入力すると「送る」メニューの元になっているフォルダを開くことができる。ここにショートカットやファイルを追加しておけば、それが右クリックメニューに表示され、選択されたファイルをまとめてコマンド引数として渡してくれる。ショートカットを編集すればオプションも渡せる（あるいはバッチファイルを突っ込んでもよい）。

* 今後紹介する方法にも共通するが、ファイルの順番としては、メインとして選択されたもの（右クリックされたもの）から下方向に進んでいき、下端まで達したら一番上に戻ってそれから選択されたものの直前まで進む。例えばファイルが”0”から”9”までの10個あるフォルダで全選択をして”5”を右クリックして「送る」を使うと、5 6 7 8 9 0 1 2 3 4の順番で渡される。

しかしこの「送る」には弱点があり、[ref]で紹介したように、この「送る」メニューは260文字の長さ制限を超えるパスをもつファイルに対してはうまく機能しない。音楽ファイルなんかはアーティスト名も曲名も色々入って長大な名前になりがちで、実際に自分がこれで困ることになった。

もう一つ、「送る」メニューは拡張子に関連付けられないという問題がある。つまり、音声ファイルを一度に開くためだけのコマンドも、画像ファイルを一度に開くためだけのコマンドも、全てのファイルを対象とした「送る」メニューにまとめて入れざるを得ない。メニュー数が無駄に増えればそれだけ管理・操作もしづらくなる。ついでに言えば、「送る」を一旦クリックしてから中の項目を選ぶ手間もなかなかバカにできないところがある。


== 前提知識 - メニューを管理するレジストリ ==

右クリックメニュー関連の設定はレジストリを使って管理されている。この記事では上記「送る」の問題を解決する方法をこの後で2つ紹介するが、いずれもレジストリの<code>command</code>という名前のキー（設定内容に応じて色々な所に設置されている）を編集する必要がある。それにあたって、前提知識としてレジストリの内容をある程度理解しておく必要があるだろう。

この話題に関しては比較的多くのサイトで解説があるが、Windowsのバージョンごとにかなり頻繁に仕様が変わっているようで、不十分なサイトも多い。最も優れているのは[https://www.pg-fl.jp/program/winreg/classes.htm Windowsレジストリ解剖記]で、かなり量は多いが、バージョンによる挙動の違いまで細かく示されている。

この記事に必要な操作を行うためには<code>command</code>の場所だけわかっていればいちおう十分だが、以下の内容くらいは覚えておいたほうがよい。

* HKEY_CURRENT_USERはHKCUと略され、ユーザーごとの設定を管理する。原則、変更はユーザー権限のみで可能。色々いじっても比較的安全。
* HKEY_LOCAL_MACHINEはHKLMと略され、システム全体（全ユーザー対象）の設定を管理する。変更には管理者権限が必要。設定は慎重に。
* HKEY_CLASSES_ROOTはHKCRと略され、関連付け専用のもので、HKCU\Software\ClassesとHKLM\Software\Classesの内容を合わせたものが表示される。関連づけの設定を確認するにはここを見るのがいいが、設定を変更する際にはここをいじるとHKLMのほうが変わってしまうことがあるのでHKCU\Software\Classesを変更したほうがよい。

以下では、設定方法を①ProgIDを使うもの②完全に独自のメニューを追加するものと大きく二つに分けて記述する。


=== ProgIDを使うもの ===

{{Valuable}}

特定の拡張子をもつファイルをダブルクリックやEnterで開くときに使われるプログラム、あるいは「既定のプログラム」あるいは「ファイルを開くプログラムの選択」のようなダイアログが表示されるときに表示されるプログラムは、このProgIDを用いて管理されている。この方法のメリットは、何より「ダブルクリックまたはEnterキー一発で起動できる」という操作性である。また、Windows11以前のメニューに戻さなくても使いやすい。

* 複数選択した際は「送る」と同様の順番で渡されるが、右クリックをしない場合は”メインとして選択されたファイル”がどれであるかが若干分かりづらい。基本的には最後に（左）クリックされたものになるはずで、よく見るとそれだけ少し太い（濃い）枠で表示されていることがわかる。なので音楽再生時など複数ファイルを上のものから順にすべて渡したいときは、「先に一番下にあるファイルをクリックしてから、一番上にあるファイルをShift+ダブルクリック（あるいはShift+クリックしたあとEnter）する」というのが有効である。

一方で、設定のしくみはやや煩雑である。具体的には、拡張子.xxxに対して

<code>HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.xxx\UserChoice</code>

というキーがあって、ここの<code>ProgId</code>の値を<code>value</code>としたときの<code>HKEY_CLASSES_ROOT\value\shell\open\command</code>の内容に従ってアプリケーションが起動される。

Windows10以降では<code>UserChoice</code>の中身を変更するためには普通の管理者権限やSYSTEMよりもさらに上位のTrustedInstaller権限が必要である。AdvancedRunなどを使ってTrustedInstaller権限で変更することは一応できたが、ハッシュ値の生成までちゃんとやっていないので自動で修正されてしまった（ここが解決できるかどうかは未調査）。従って、任意のコマンドを設定したい際は、まず<code>UserChoice</code>の中身を変更するところだけエクスプローラーのダイアログを使い、その後で<code>HKEY_CLASSES_ROOT\value</code>の中身を好きに変えるほうがよいだろう。

例えば新たなメニューを追加したい場合なら、以下のようにするとよい。

* 今まで使われていない（乱数値など）名前をもつダミーのexeファイル（実行ファイルとして正しく機能する必要はなく、空のファイルでもいいし、拡張子がexeでなくてもよい）を用意する（ここでは<code>dummy.exe</code>とする）
* 関連付けたい拡張子のファイルの右クリックメニューから「プログラムを開く」を選択し、<code>dummy.exe</code>を選んで関連づける
** これによりレジストリキー<code>HKEY_CURRENT_USER\Software\Classes\Applications\dummy.exe</code>が作られた上で<code>UserChoice</code>の<code>ProgId</code>には<code>Applications\dummy.exe</code>が書き込まれる
* <code>HKEY_CURRENT_USER\Software\Classes\Applications\dummy.exe\shell\open</code>の中身を自由に変更する。

=== 完全に独自のメニューを実装する ===

これは、「PowerShellをここで開く」「VS Codeで開く」のように完全に独自の右クリックメニューを追加するものである。設定は意外と簡単である。また、フォルダに対する右クリックメニューや全ファイルに共通の右クリックメニューを追加するにはこの方法しかない。ただし、Windows10以前のメニューに戻さないと「その他のオプション」を押す手間がかかるので注意。

拡張子ごとの設定は<code>HKEY_CLASSES_ROOT\SystemFileAssociations</code>にある（編集時は<code>HKEY_CURRENT_USER\Software\Classes\SystemFileAssociations</code>を使うのがいいだろう）（比較的新しいWindowsだと<code>HKEY_CURRENT_USER\Software\Classes\SystemFileAssociations</code>キー自体が存在しないことがあるが、自分で作ればちゃんと動作する）。<code>command</code>キーは<code>HKEY_CURRENT_USER\Software\Classes\SystemFileAssociations\.xxx\shell\yourcommandname\command</code>のような場所に作られることになる。

また、全てのファイルを対象にするメニューは<code>HKEY_CLASSES_ROOT\SystemFileAssociations\*</code>、フォルダを右クリックしたときのメニューは<code>HKEY_CLASSES_ROOT\Directory</code>、ドライブ（C:\など）を右クリックしたときのメニューは<code>HKEY_CLASSES_ROOT\Drive</code>、フォルダ（・ドライブ）の背景（何もないところ）を右クリックしたときのメニューは<code>HKEY_CLASSES_ROOT\Directory\Background</code>以下でそれぞれ管理されている。また、<code>HKEY_CLASSES_ROOT\AllFilesystemObjects</code>というのもあり、これはディレクトリとファイルの両方に適用される（ドライブやフォルダ背景には影響なし）。

* 一覧は[https://learn.microsoft.com/ja-jp/windows/win32/shell/reg-shell-exts ここ]かな？


==== 複数種類に一括で追加？ ====

<code>HKEY_CLASSES_ROOT</code>には<code>PerceivedType</code>という値があり、これに<code>video</code>などと指定されている場合は<code>HKEY_CLASSES_ROOT\SystemFileAssociations\video</code>にある設定が反映される（これによって複数種類のファイルに共通するメニューが作れる）…というような情報もあったのだが、手元のWindows 11では全く反映されなかった。

そもそも<code>PerceivedType</code>に複数種類が指定できるか不明だったりと色々と意義が怪しいので諦めて各拡張子ごとに追加するのがよいのではないかと思う。CLSIDの部分は共通化されているわけなのでそれほど非効率な二重管理ということにもならないだろう。（そもそもこの辺のWindowsの仕様はころころ変わるっぽいのであまり頑張ってもしょうがないかも？）


=== Directory\Backgroundの表示 ===

エクスプローラーの左側のエリアにあるフォルダやドライブを右クリックしたときのメニューには、なぜかDirectory\Backgroundの内容も表示されてしまう。そのうえ、これらには正しくパラメータが渡されない（commandに直接書くときは<code>%V</code>などが入っていると起動せず、COM使用（少なくともDelegateExecute）で受け取る方法も不明）。

ただ、DirectoryやDriveに同名のメニューが登録されている場合はそちらが優先される。しかし、これを利用してメニューを非表示にすることはできない。（DirectoryやDriveのほうにLegacyDisableを書いたら、そもそもそちらが無かったのと同じになるっぽい）

実際には、Directory\Backgroundに設定するメニューはDirectoryにもDriveにも等しくあったほうがいい場合が多いと思うので、そのように設定するとよいだろう。

=== その他設定項目 ===

本筋とは関係ないので詳細は省くが、その他にもこれらのキーでは様々な設定ができる。

* <code>Icon</code>によるアイコンの設定
* <code>&</code>によるキーの設定（「"編集(E)"のEみたいなやつ」）
* <code>MUIVerb</code>（多分、言語設定ごとの表示文字列の切り替えとかができるようになるやつ）
* <code>AppliesTo</code>、<code>DefaultAppliesTo</code>による表示条件の設定
** AQS書式というのが使用可能で、かなり柔軟な指定ができる（特定フォルダ内のみに表示するなど）。ただしあまり情報がなく、[https://www.pg-fl.jp/program/winreg/classes.htm Windows レジストリ解剖記]でもそこまで詳細な解説はない。そこからもリンクされている[https://learn.microsoft.com/ja-jp/windows/win32/search/-search-3x-advancedquerysyntax?redirectedfrom=MSDN MSの公式ドキュメント]を読むのが早そう。あと、Backgroundメニューではそもそも背景フォルダに関する情報が全く渡されてこないようで（ただしどこかに書いてあったのではなく実験の結果）、使い物にならない。
*** Backgroundでは使えなかったという投稿の例
**** [https://superuser.com/questions/1020415/windows-explorer-context-menu-to-a-especific-folder-background Windows Explorer: Context menu to a especific folder (background) - Super User]
**** [https://stackoverflow.com/questions/47325736/windows-context-menu-directory-background-appliesto shell - Windows context menu directory\background AppliesTo - Stack Overflow]
* <code>HasLUAShield</code>による「管理者アイコン」の表示（<code>Icon</code>との併用可）
** これも実は上と同様にAQS書式で管理者アイコンの表示条件を設定できる
** このアイコン自体はSystem32のimageres.dllとかUserAccountControlSettings.exeとかに入っている
* <code>SubCommands</code>によるサブメニューの登録
** 手元のWindows11で試した限り、<code>Directory</code>や<code>Drive</code>ではうまくいくが<code>Directory\Background</code>だとサブメニューが出ない？
* <code>ExtendedSubCommandsKey</code>値による他の<code>shell</code>キーへの参照によるサブメニューの登録
** かなり強力で、循環参照も作れる。
** 例: [http://nonsubject.arinco.org/2011/08/ Nonsubject: 8月 2011]
** 一つのルートメニューが持てるサブメニュー上限は16個までという制限がある。[https://stackoverflow.com/questions/48625223/is-there-a-maximum-right-click-context-menu-items-limit https://stackoverflow.com/questions/48625223/is-there-a-maximum-right-click-context-menu-items-limit]
** これは<code>Directory\Background</code>でも有効。
* <code>Extended</code>によってShift+右クリックしたときのみ表示させる
* 設定例: [https://www.tenforums.com/tutorials/178668-add-remove-open-windows-terminal-administrator-context-menu.html Add or Remove 'Open in Windows Terminal as administrator' context menu | Tutorials]


=== ContextMenuHandlers（IContextMenu）を用いた実装 ===

{{Valuable}}

先ほどのClipchampのメニュー項目などはここまで述べたようにレジストリ内に静的に設定されているものではなくCOM(Component Object Model)を用いて外部のDLLの関数から動的に追加されているものである（ただDLLの指定自体はレジストリ内のInProcServer32のようなキーにあるはず）。Clipchamp以外だと7-ZipやPDF XChange Editorなどのメニューはこれを用いて実装されている。レジストリの<code>XXX\shellex\ContextMenuHandlers</code>といったキー以下に設定されているものはこれに分類される。

詳しくはIContextMenuなどのキーワードで検索すると出てくる[https://learn.microsoft.com/en-us/windows/win32/shell/shortcut-menu-using-dynamic-verbs Customizing a Shortcut Menu Using Dynamic Verbs - Win32 apps | Microsoft Learn]などを読むとよさそうだが、実装はかなり難解である。Clipchampもこの部分で不適切な実装をしたために順番がおかしくなったのではないかと思われる。

動作確認できたサンプルとしては、[https://github.com/microsoft/Windows-classic-samples/tree/main/Samples/Win7Samples/winui/shell/appshellintegration/NonDefaultDropMenuVerb https://github.com/microsoft/Windows-classic-samples/tree/main/Samples/Win7Samples/winui/shell/appshellintegration/NonDefaultDropMenuVerb]はIContextMenuを使って実装されており、dllをビルドしてCLSIDのInProcServer32でそれを指定するとちゃんと右クリックメニューが追加される。

また、メニューを追加する関数であるQueryContextMenuが呼ばれる時点で、引数となっているファイルの情報がわかる（Initialize関数においてIDataObjectが渡されているのでそれをクラスのフィールドなどとして持っておけばよい）ので、特定の拡張子のファイルのみに対してメニューを表示することもできる。もちろんファイルの内容まで読み取ってからメニューを表示するといったこともできるが、そこまですると右クリックするだけで動作が重くなるといった副作用が大きくなるのでやめた方が無難だろう。ただ、スタートメニューへのピン留め<code>{a2a9545d-a0c2-42b4-9708-a0b2badd77c8}</code>やPDF XChange Editor(9.3や10.2.1で確認)のメニューは実際にそのような挙動をする（余談だが、InfoTipの表示もexplorerが操作しづらくなる原因なのでshowinfotipを0にしたほうがいい）（サムネイルなどはバックグラウンドで並列に走るので操作にはあまり影響がない）。またエラーが発生した場合はexplorer自体が強制終了することもあり、全体的に実装は慎重に行ったほうがよい。

==== コード例 ====

拡張子が.tで始まるファイル（*.txt, *.ttfなど）のみにメニューを追加するサンプル（から抜粋）。

<syntaxhighlight lang="c++">IFACEMETHODIMP CNonDefaultDropMenuVerb::QueryContextMenu(HMENU hmenu, UINT indexMenu, UINT idCmdFirst, UINT /*idCmdLast*/, UINT /*uFlags*/)
{
FORMATETC fmte = { CF_HDROP, NULL, DVASPECT_CONTENT, -1, TYMED_HGLOBAL };
STGMEDIUM medium;
HRESULT hr = _pdtobj->GetData(&fmte, &medium);
if (SUCCEEDED(hr))
{
HDROP hdrop = (HDROP)medium.hGlobal;
WCHAR szFile[MAX_PATH];
DragQueryFile(hdrop, 0, szFile, ARRAYSIZE(szFile));
const WCHAR* ext = wcsrchr(szFile, L'.');
ReleaseStgMedium(&medium);
if (ext && *(ext+1) != L't') {
return MAKE_HRESULT(SEVERITY_SUCCESS, 0, 0); // Add nothing
}
}
else
{
return MAKE_HRESULT(SEVERITY_SUCCESS, 0, 0); // Add nothing
}

WCHAR szMenuItem[80];

LoadString(g_hinst, IDS_CHECKDROP, szMenuItem, ARRAYSIZE(szMenuItem));
InsertMenu(hmenu, indexMenu++, MF_BYPOSITION, idCmdFirst + IDM_CHECKDROP, szMenuItem);

LoadString(g_hinst, IDS_CHECKNETRESOURCES, szMenuItem, ARRAYSIZE(szMenuItem));
InsertMenu(hmenu, indexMenu++, MF_BYPOSITION, idCmdFirst + IDM_CHECKNETRESOURCES, szMenuItem);

return MAKE_HRESULT(SEVERITY_SUCCESS, 0, (USHORT)(2)); // indicate that we added 2 verbs.
}</syntaxhighlight>
* 特定の拡張子に対して追加できるのは以下で知った
** できるという情報 
[https://stackoverflow.com/questions/43769772/how-to-add-context-menu-to-one-specific-file registry - How to add context menu to one specific File - Stack Overflow]
** 実際のコード 
[https://github.com/nyfair/freeimagerip/blob/master/plugin/FIShellExt/Thumb.cc freeimagerip/Thumb.cc at master · nyfair/freeimagerip]


==== IContextMenuの今後について ====

Windowsの右クリックメニューが重いと良く言われるのはこのような高い自由度をもつIContextMenuに起因するものであると思われる。Windows11ではIContextMenuよりIExplorerCommandがよいというのを見かけた（[https://twitter.com/kenichiuda/status/1417266893581295651 https://twitter.com/kenichiuda/status/1417266893581295651]や、そこで引用されている[https://twitter.com/madonomori/status/1417265763363168263 https://twitter.com/madonomori/status/1417265763363168263]）。[https://github.com/microsoft/Windows-classic-samples/tree/main/Samples/Win7Samples/winui/shell/appshellintegration/ExplorerCommandVerb https://github.com/microsoft/Windows-classic-samples/tree/main/Samples/Win7Samples/winui/shell/appshellintegration/ExplorerCommandVerb]も見てみる必要があるかも。

ただまあMicrosoftのことなのでIContextMenuもあと10年くらいは使えるだろう。

* [https://learn.microsoft.com/ja-jp/windows/apps/get-started/make-apps-great-for-windows#8-optimize-your-apps-context-menu-extensions-and-share-targets Windows 11 でアプリをすぐれたものにするためにできることトップ 11 - Windows apps | Microsoft Learn] を読んだら、Windows 11の（新しい）右クリックメニューに表示するためにはIExplorerCommandを使わなければならない（IContextMenuは不可）と明確に書いてあった。また、IExplorerCommandのサンプル（[https://learn.microsoft.com/ja-jp/windows/win32/shell/samples-explorercommandverb エクスプローラーコマンド動詞のサンプル - Win32 apps | Microsoft Learn]）を使ってみたが、IExplorerCommandState（CommandStateHandler）のほうは動作しているように見えるものの肝心のIExplorerCommand（ExplorerCommandHandler）は全く反応しなかった（右クリックを一度でも行うとdllへの上書きアクセスが禁止されるので読み込まれてはいるようだが、コンストラクタや<code>QueryInterface</code>にデバッグ用のメッセージボックスを入れても表示されない）。

==== サブメニュー ====

IContextMenuは自由度が高いのでサブメニューなども実装できるはず（7-Zipなどもそうしていると思われる）。またこのような記事もあった: [http://nonsubject.arinco.org/2014/06/cascading-desktopbackground-menus.html デスクトップのシェルメニューをサブメニューにする | Nonsubject]


=== Windows11の右クリックメニューへの追加 ===

これはどうやらますます面倒になりそうで、リリース済のWindowsストアアプリをインストールするか開発者モードを有効にしないと自分の好きなメニューを追加できない（多分）上、アプリ1つにつき1メニューしか追加できないらしい。

<ul>
<li>Windows 11の右クリックメニューに追加してくれるソフト
[https://github.com/ikas-mc/ContextMenuForWindows11 https://github.com/ikas-mc/ContextMenuForWindows11]
フォルダ背景を右クリックしたメニューに追加できない（[https://github.com/ikas-mc/ContextMenuForWindows11/issues/44 https://github.com/ikas-mc/ContextMenuForWindows11/issues/44]）（いや、使ってみたら普通にできてるっぽい？）、アプリ1つにつき1メニューしか追加できない（[https://github.com/ikas-mc/ContextMenuForWindows11/issues/45 https://github.com/ikas-mc/ContextMenuForWindows11/issues/45]）（これはWindows側がそういう仕様っぽいので厳しそう）</li>
<li>Microsoftの関連するサンプル 
[https://github.com/microsoft/AppModelSamples/tree/master/Samples/SparsePackages AppModelSamples/Samples/SparsePackages at master · microsoft/AppModelSamples]</li>
<li>Meryへの追加要望
[https://www.haijin-boys.com/discussions/6746 Windows 11の新コンテキストメニューにMeryのコマンドを追加したい]</li></ul>


== 解決策①COMを利用する ==

{{Valuable}}

まずは、COMを用いて実装するという方法がある。基本的にはこちらが綺麗な解決策である。

IExecuteCommandというインターフェースを具体的に実装している[https://learn.microsoft.com/en-us/windows/win32/shell/samples-executecommandverb Microsoftのサンプル]があったので、それを参考に、「取得したファイル・フォルダの情報を引数または標準入力として渡しつつ指定されたコマンドを起動する」というプログラムを作成した。

[https://github.com/ge9/ExecuteCommand-Pipe https://github.com/ge9/ExecuteCommand-Pipe]

COMを使っていることからわかるように、コマンドラインを介さず直接Explorerからデータが送られてくるので、他の方法に共通してみられるパス長さやファイル個数の制限が（事実上）皆無であり、非常に強力である。

{{Stub}}

=== 使い方 ===

詳しい使い方は上記レポジトリのREADMEも参照。

==== 基本 ====

引数となる（実際に起動したい）コマンドはレジストリキー

<code>HKEY_CURRENT_USER\Software\Classes\CLSID\{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}\LocalServer32</code>の既定の値で設定する。

その上で該当メニューに対応する<code>command</code>キー（レジストリの各所にある）に<code>DelegateExecute</code>という値を作成して<code>{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}</code>を書き込むことで起動できる（<code>command</code>の既定値よりも<code>DelegateExecute</code>が優先される）。


=== IDropTargetを用いた実装 ===

IExecuteCommandではなくIDropTargetというインターフェースを用いてもほぼ同じことができそうであった。対応するサンプルは[https://github.com/microsoft/Windows-classic-samples/tree/main/Samples/Win7Samples/winui/shell/appshellintegration/DropTargetVerb https://github.com/microsoft/Windows-classic-samples/tree/main/Samples/Win7Samples/winui/shell/appshellintegration/DropTargetVerb]である。IExecuteCommandとの機能的な違いはあまりよくわからないが、[https://learn.microsoft.com/en-us/windows/win32/shell/samples-droptargetverb https://learn.microsoft.com/en-us/windows/win32/shell/samples-droptargetverb]を読む限り、DropTargetのほうが古くからあるようである。CLSIDの登録までは同じだが、<code>command</code>のかわりに<code>DropTarget</code>キーを使用し、<code>DelegateExecute</code>値のかわりに<code>CLSID</code>値を使う（ソースを読めばわかる）。

== 解決策②プロセス間通信で頑張る ==

{{Valuable}}

「プロセス間通信を使って頑張る」という方法もある。要するに、コマンドとしては別々に渡されたとしても、既に立ち上がっているプロセスがあるときはそちらに投げて終了するようにすれば、一つのプロセスでまとめて開けるというわけである。

この部分を代わりにやってくれるものとしては[https://github.com/zenden2k/context-menu-launcher https://github.com/zenden2k/context-menu-launcher]がある。これを少し改善したフォークとして[https://github.com/KnIfER/SingleInstance-Launcher https://github.com/KnIfER/SingleInstance-Launcher]があり、さらに自分が64bit版のビルドを加えたものが[https://github.com/ge9/SingleInstance-Launcher https://github.com/ge9/SingleInstance-Launcher]にある。

ただ、これはCOMを使う方法とは違っていくつかの欠点がある。

* ファイル個数の上限
** ProgIDを使って開く場合には、選択個数がデフォルトで15個までに設定されており、これはMultipleInvokePromptMinimum値（詳しくは他サイト）の変更により増やせるが確実ではない（上限に諸説あり）。
** 独自メニューの場合は、"MultiSelectModel"を"Player"にすることでファイル数上限が100個になるが、それより大きくはできない。
* 長さ制限（260文字）を超えるパスをもつフォルダでは失敗する（詳しくは[[Windowsのパス長さ制限に関して|Windowsのパス長さ制限に関して]] を参照）。
* プロセス間通信を使っているため、起動時にラグがあったりすると、ごく稀に渡されたファイルの順番が乱れることがある。


=== SingleInstance-Launcher - 基本的な使い方 ===

上記GitHubリポジトリから実行ファイルをダウンロードしてどこか分かりやすい場所に置く。インストールなどは不要である。筆者がリリースした実行ファイルを信用できない・改変したいなどの場合はソースコードをどうぞ。言語はC++。ファイルの順番が乱れにくくなる改善など大歓迎。

README.mdにもあるが起動に用いる基本的な構文（レジストリに登録する値）は以下のようである（※ここでは64bit版を使うものとして説明しているが、32bit版でも全く同様）。

<syntaxhighlight lang="c">"C:\path\to\singleinstance_x64.exe" "%1" "C:\Program Files\path\to\app.exe" "$files" --si-timeout 1000 --option-to-app-1 --option-to-app-2</syntaxhighlight>
"C:\path\to\singleinstance_x64.exe"、"%1"、"C:\Program Files\path\to\app.exe"、"$files"の順番はおそらくこの通りである必要がある。その後にあるものはapp.exeにオプションとしてそのまま渡されるが、<code>--si-timeout n</code>に限り、singleinstance_x64.exeが解釈し、app.exeに渡されない。このオプションはSingleInstance-Launcherに対して次のファイルが渡されてくるのを待つタイムアウト期間をミリ秒で指定するものである。短すぎると、右クリックメニューの処理が遅い場合に途中で打ち切られてしまう可能性がある。長すぎると、その期間待つまでapp.exeは呼ばれないため、タイムラグが長く不便に感じる可能性がある。特に動作が重いPCでなければ1000（1秒）くらいにしておけば十分だろう。もう少し短くてもいいかもしれない。

%1や$filesの両側にダブルクォーテーションがないと、空白を含むファイル名を正しく扱えない。GitHubのサンプルでは付いていないものもあるので注意。
[[Category:IT]][[Category:Windows]]{{#seo:|title={{FULLPAGENAME}} - Turgenev's Wiki}}

デュアルブート

2025-06-30T09:02:46Z

Turgenev: Notion-MW

{{Outdated}}

WindowsとLinuxのデュアルブートにおいて役に立つ情報を記述する。古いメモを多く含む。[[Linuxのインストール|Linuxのインストール]]も参照。


== Windowsのプロダクトキー関連 ==

{{UnderConstruction|デュアルブート}}


== Bitlocker ==

とにかく前もって回復キーを保存しておくこと！！逆に回復キーさえあればBitlockerで大きなトラブルになることは多くない。

* [https://www.pcdock24.com/blog/?p=53931 BitLockerとは【BitLockerの要件と自動有効化の問題点】｜パソコン修理パソコンドック24] によるとローカルアカウントでBitlockerの有効/無効を確認するときはdiskmgmtから行かなきゃいけないらしい。
* Bitlockerを有効にしたあとにwinを起動すると再起動ループにハマることがある。解決法(Manage-bdeを使う)→[https://community.spiceworks.com/how_to/124388-stop-a-bitlocker-boot-loop Stop a BitLocker boot loop - Windows Forum - Spiceworks]


== Windowsパーティション（NTFS）のマウント ==

{{Outdated}}

==== remove_hiberfileについて ====

マウントが成功するにはWindowsが完全シャットダウンされている必要がある（またはそれが望ましい）。ただ、[https://unix.stackexchange.com/questions/107978/cant-access-windows-drive-windows-is-hibernated-refused-to-mount https://unix.stackexchange.com/questions/107978/cant-access-windows-drive-windows-is-hibernated-refused-to-mount]にある通り、windowsを正しくシャットダウンしてもなぜか「ハイバーネートされててマウントできません」的なのが出ることがあるので、マウントオプションにremove_hiberfileを追加するとよい。

* 高速スタートアップを無効にしているにもかかわらず完全シャットダウンされていないことがある気がしたので、Windowsでシャットダウン時に実行するスクリプトとして完全シャットダウンコマンドを追加したりした
* デスクトップPCではだいたい不要？


=== Bitlocker無し ===

普通にntfs-3gを使う。数字など適宜読み替えること。主にWindowsのDドライブ想定。

<ul>
<li>コマンド例
<syntaxhighlight lang="javascript">ntfs-3g -o remove_hiberfile /dev/nvme0n1p5 /media/win</syntaxhighlight></li>
<li>fstabの例
<syntaxhighlight lang="javascript">/dev/sda2 /media/ddrive ntfs-3g noauto,rw,nofail 0 0</syntaxhighlight></li></ul>


=== Bitlocker有り ===

ntfs-3gの前にDislockerで暗号化を解除する。参考→[http://www7390uo.sakura.ne.jp/wordpress/archives/270 http://www7390uo.sakura.ne.jp/wordpress/archives/2]

dislocker-fileの方式だと一旦復号したのをファイルに書き出して静的にマウントするので、（事実上）readonlyとなる。よってdislocker-fuseを使う→[https://www.systutorials.com/docs/linux/man/1-dislocker-fuse/ https://www.systutorials.com/docs/linux/man/1-dislocker-fuse/]

<ul>
<li>コマンド例
<syntaxhighlight lang="vb.net">$ sudo dislocker-fuse -V /dev/nvme0n1p3 --recovery-password=xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx -- /media/dl-fuse
$ sudo mount -o loop,rw /media/dl-fuse/dislocker-file /media/win/</syntaxhighlight></li>
<li>fstab例
<syntaxhighlight lang="vb.net">/dev/nvme0n1p3 /media/bitlocker fuse.dislocker recovery-password=xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx 0 0
/media/bitlocker/dislocker-file /media/win10 ntfs-3g rw,nofail,remove_hiberfile,permissions 0 2</syntaxhighlight>
と、二行に分けて記載する。
<ul>
<li>permissions については後述</li></ul>
</li></ul>

==== セキュリティ問題 ====

recovery-passwordを暗号化されていないパーティションに書いてしまうと結局Bitlockerの意味が全くなくなってしまうので、Linux側でもBitlockerのような暗号化パーティション（LUKSとか？）やユーザーログイン時に復号される暗号化フォルダ（ecryptfsとか）といったディスク上で暗号化される領域に書いておく必要がある（もちろん毎回パスワードの類を打ち込むのでよければそれでもいい）。


=== permissions, inheritについて ===

[https://github.com/tuxera/ntfs-3g/wiki/File-Ownership-and-Permissions https://github.com/tuxera/ntfs-3g/wiki/File-Ownership-and-Permissions] 詳しくはこちらも参照。

まず、マウントオプションとしてpermissionsを指定しない限り、ntfs-3gでマウントしたファイルは全てパーミッション・所有者が固定（uid, gid, umaskなどで指定）となり、個別のファイルについて変更することはできない。

そして、この場合、ntfs-3g経由で作成したファイルはWindows側で見るとすべてAdministratorの所有となり、さらにEveryoneにフルコントロール権限が付与される（この動作を変更するのは筆者の知る限り不可能）。

Linuxではフォルダの実行権限（x）が無ければその中に含まれたファイルにはアクセスが通らず、パスを推測することも不可能だが、Windowsではたとえ一切権限のないフォルダであっても中にあるファイル・フォルダのパスがわかれば直接パスを打つことでアクセスが通ってしまうようである（試した限り）。そのため、permissions無しでntfs-3gで作成したファイルはパスさえわかればWindows上の全ユーザーが閲覧・編集・削除できる状態ということになる。

従って、Gitを使用する場合や複数ユーザーで使用したい場合などパーミッション管理が必要なデータを扱う場合はもちろん、単に中にあるデータを保護したいという場合でもpermissionsオプションを指定することが必須になる。

次に、permissionsを指定して、かつUserMappingを指定しない場合、Linux上でrootが所有するファイルをWindows側で見ると、全てAdministratorsの所有物になり（ここはpermissionsがない場合と同じ）、そのアクセス権はLinux上での見え方と概ね一致するように設定されるようである。他のユーザーが所有するファイルにはS-1-5-21-3141592653-589793238-462643383-10000というような上位桁が円周率に由来する（この部分はハードコードされている）SIDが割り当てられ、こちらもアクセス権が適切に設定される。UserMappingを指定することで、このSIDの部分の割り当てを変更することができる。

Windowsに挙動を近づけるための他のオプションとしてはinheritというのもあり、これは新規作成時に上位フォルダの権限を継承するものである。しかし、これは所有者を継承するオプションではない（そして、所有者が違えばまともに継承もされない）。

* [https://github.com/tuxera/ntfs-3g/issues/90 https://github.com/tuxera/ntfs-3g/issues/90] では、UserMappingがなくても所有者が継承されるようになるパッチが示されているが、これを使うとpermissionsは動かなくなる（chmodなどが使えない）。

以上のことから、Windowsの一般ユーザーフォルダの内容などをLinuxから良い感じに（Windows側の権限設定を汚染せずに）使えるようにするには、明示的なUserMappingが事実上必須であることがわかる。

一方で、Administrator所有・全ユーザー閲覧可能（あるいは不可能）、といった、Windows側の全ての一般ユーザーに対して共通のアクセス権を適用する設定であれば、UserMappingを使用しなくても簡単に設定が可能である。個人用PCかつ、画像・動画などのメディアファイルやLinuxでしか使用しない大きめのソフトウェアを入れておく用途であれば、こちらで問題ないだろう。

Linux側で別ユーザーの所有に見せたい場合は、上記のS-1-5-21-3141592653-589793238-462643383-10000のようなSIDが見えてしまう状態でもよければ（かつ、権限設定にも問題がなければ）それでもいいし、下記のbindfsと併用する方法もある。いずれにしても、Linux側で全員が読み取り・書き込み・実行が可能なファイルは、Linux側での親フォルダの権限によらず、Windows側では（パスさえわかれば）対応する権限でアクセスができてしまうということに注意が必要である。

また、Windowsではファイルの新規作成時には必ず実行権限が付加されるので、Linux側でそれを見た場合も実行可能になる（実行権限を外すと.exeなどが実行できなくなる）。従って、GitのレポジトリのフォルダをWindows/Linux間で共用するようなことをすると、Windows側では実行権限無しで（これがデフォルトであるため）コミットされたファイルがLinux側では実行権限有りに見えるため差分が出てしまうといったことが発生する。これはUserMappingでも解決はできないので、Gitリポジトリのあるフォルダを共用するのは不可能である。

==== bindfs ====

既存のディレクトリを、所有ユーザーやパーミッションを変更してマウントしてくれる。

<syntaxhighlight lang="python">sudo bindfs --mirror=myname --force-group=myname /media/win ~/.mnt_win/</syntaxhighlight>
または

<syntaxhighlight lang="python">sudo bindfs --force-user=myname --force-group=myname /media/win ~/.mnt_win/</syntaxhighlight>
この2つの違いは不明

作成した

sudoがないと<code>fusermount: option allow_other only allowed if 'user_allow_other' is set in /etc/fuse.conf</code>とか言われたりする

fstabの例

<syntaxhighlight lang="python">/media/win /home/myname/.mnt_win fuse.bindfs nofail,map=root/myname:@root/@myname,create-with-perms=g-w 0 0</syntaxhighlight>
Linuxだとrootのデフォルトのumaskが022で一般ユーザーが002なせいで一般ユーザーが作ったファイルが775とか664になってしまったりするがg-wをつけることによって755とか644になる（もちろんchmodすれば変えられる


== Minecraft ==

.minecraftフォルダをWindowsとLinuxで共有したはいいが、（それ自体.minecraftの中にある）ゲームディレクトリの指定も共有することを考えると、両OSでパスの仕様がやや異なるのが問題になる。

例えば以下ではWindowsのルートが/media/winにマウントされているとする。

まずLinuxのランチャーは相対パスどころかシンボリックリンクすら変換して普通の絶対パスにしてしまう（設定を書き換えてしまう）っぽいので、linuxでは絶対パス指定で/media/win/Users/pathのようにする。で、この書き方をするとWindowsでは相対パスと解釈されるのだが、基準となるフォルダが謎で、「PLAY」を押した時のチェック時は.minecraftが基準なのだが、実際に見られるのはランチャーがあるフォルダが基準（＝こっちになかった場合ゲームディレクトリが新たに作られる）

* ストアアプリ版の（新しい方の？）Minecraftランチャーでは、この「ランチャーがあるフォルダ」は<code>AppData\Local\Packages\Microsoft.4297127D64EC6_8wekyb3d8bbwe\LocalCache\Local</code> あたりである。

従って、ランチャーのフォルダと.minecraft内の両方にmediaというフォルダを作って中にwinという名前でC:\へのジャンクション置くとうまくいく。

.minecraftの中にはゲームディレクトリ専用のフォルダを作り、その中にmain, snapshotなど用途に応じたフォルダを作っておくとよい

== google-drive-ocamlfuse ==

labelを使うと複数アカウントをマウントできる。デフォルトのラベル名はdefault

しばらく使っていないと起動時におそらく認証の失敗が原因でマウントポイントのあるフォルダに対するlsがしばらく一切反応しなくなる（~/.gdfuse内の該当ラベル名のフォルダを削除して最初からやり直せば治る）。よってマウントポイントをホームディレクトリ直下に作るのは避けたほうがよい（gdfというフォルダを作っている）。


== MEGA ==

Winが完全にはシャットダウンされていない状態でLinuxを起動するとCドライブ上のMEGAのフォルダが読めずに同期が無効になってしまう。MEGA自身のかわりに、Cが読める状態でのみMEGAを起動するシェルスクリプト（mega-mounted.sh）をスタートアップに登録しておく。Cが読めなかった場合にはdialogコマンドで通知ダイアログを表示する。（このスクリプトではC自身のかわりにC:\Windowsをみている）（gdialogは一部のディストリにしか入っていないかもしれない。実際にコマンド打ってみてどんな表示になるかも含めて確かめておいたほうがよい）

<syntaxhighlight lang="shell">#!/bin/sh
if [ -d /media/win-rw/Windows ]; then
megasync
else
gdialog --title "Warning" --infobox "MEGAsync is not started because Windows partition is not mounted" 0 0
fi</syntaxhighlight>

== Bluetooth機器 ==

同じBluetooth機器を同じPCのWindowsとLinux双方にペアリングするというもの。自分はマウスでしかやったことがない。意外と難しいが何とかなる。

==== 参考 ====

* [https://orumin.blogspot.com/2019/02/bluetooth.html https://orumin.blogspot.com/2019/02/bluetooth.html]
* [https://qiita.com/yoko-yan/items/9b0235678fd804b4fe0d https://qiita.com/yoko-yan/items/9b0235678fd804b4fe0d]
* Bluetooth Low Energyという仕様もあるらしく、自分のマウスはこっちだった。これに関しては[http://aimingoff.way-nifty.com/blog/2018/09/windows-linux-b.html http://aimingoff.way-nifty.com/blog/2018/09/windows-linux-b.html]を参照。割と情報が少ないので感謝。
** <code>HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTHPORT\Parameters\Keys\xxxxxxxxxxxx</code>を見るためにpstoolsをダウンロードして<code>PsExec64 -s -i regedit</code>とする必要があることに注意。なお、セキュリティソフトによってPsexecが脅威と見なされ強制削除されてしまうときは代わりにフリーソフトのAdvancedRunを使うとよい。
** まとめ
*** CSRKをLocalSignatureKey
*** LTKをLongTermKey
*** EDIVをEdiv（16進→10進に変換）
*** ERandをRandに（バイト(2文字のかたまり)をすべて逆順にしてから10進変換）。ちなみにこれを間違えた結果、マウスを動かすたびにbluetoothアイコンが白↔黒と高速で切り替わる謎のバグっぽい現象が起こったことがあった。
*** 小文字を大文字に変える必要はない。また、IRKをIdentityResolvingKeyに書くのも不要。


==== マルチデバイス対応マウス（Logicool） ====

マルチデバイス対応（切り替えボタンがあるやつ）のマウス（LogicoolのM595）を使ったら、登録情報を一旦削除して再接続するごとにMacアドレスがひとつインクリメントされて困った。Linuxで接続→Winで接続→Linuxで上記の書き換え、とやったあと、フォルダ名を変更（1を足せばよいはずだが正確にはWinの情報を見るのがよい）するとうまくいった。[https://twitter.com/e9g/status/1381111849664409600 自分のツイート]にも記録あり
[[Category:IT]][[Category:Windows]]{{#seo:|title={{FULLPAGENAME}} - Turgenev's Wiki}}

PDF

2025-06-30T09:02:43Z

Turgenev: Notion-MW

pdfを扱う方法について。

== pdftkとcpdf ==

pdftkは有能だが、cpdfはさらに強い

==== pdftk ====

<ul>
<li>切り出し
<syntaxhighlight lang="vb.net">pdftk hoge.pdf cat 1 3-5 output fuga.pdf</syntaxhighlight></li></ul>

==== cpdf ====

非商用に限り[https://community.coherentpdf.com/ https://community.coherentpdf.com/] このcommunityバージョンが無料で使える

概要は[http://pdf-file.nnn2.com/?p=892 http://pdf-file.nnn2.com/?p=892] 、具体的なコマンド例は [http://pdf-file.nnn2.com/?p=1025 http://pdf-file.nnn2.com/?p=1025] など参照

例えば、「1,5ページ目のサイズを縦横とも半分にして出力したい」ときは

<syntaxhighlight lang="javascript">cpdf input.pdf 1,5 -scale-page "0.5 0.5" -o output.pdf</syntaxhighlight>
とする。一方で、「1,5ページ目のサイズを縦横とも半分にして1, 5ページ目のみを出力したい」ときは

<syntaxhighlight lang="javascript">cpdf input.pdf 1,5 AND -scale-page "0.5 0.5" -o output.pdf</syntaxhighlight>
のようにANDを入れるといいっぽい。

* -remove-fontsで埋め込みフォントを除去できる。ただしAcrobat Readerでの表示とかはかなりおかしくなる（Chromeならいけてたりする）


== Adobe reader ==

* 「文書」メニューの前回のビュー設定を復元をしておくとよい。これをクラウドで共有できたりすると便利かもしれないができるかどうか不明。→ [https://superuser.com/questions/83935/pdf-where-does-acrobat-reader-save-information-about-last-view-settings https://superuser.com/questions/83935/pdf-where-does-acrobat-reader-save-information-about-last-view-settings] によるとレジストリの <code>HKCU\Software\Adobe\Acrobat Reader\9.0\RememberedViews</code>にあるらしい。見てみたら今は <code>\HKEY_CURRENT_USER\Software\Adobe\Acrobat Reader\DC\RememberedViews</code>っぽい。15ファイルが上限？Recent自体は100個保存してるみたいだが

上書き保存なのに毎回ダイアログが出て不快。設定から「ファイルを保存するときにオンラインストレージを表示」を外すと良い（というよりマシな）感じになる（無駄なクリック数が減る）。保護モードを解除すれば即座に上書き保存できるようだが、セキュリティリスクがありそうなのでやめておいた。

Alt+方向キーで進む戻るはできるが、Logicoolのマウスの進む戻るは効かなかったので、Logicool Optionsをインストールしてアプリケーション個別の設定をした

Shift+Enterで次に移動できるようにするためにAutoHotKeyで

<syntaxhighlight lang="javascript">#IfWinActive ahk_class AcrobatSDIWindow
+Enter::^+G
#IfWinActive</syntaxhighlight>
と書いて起動しておく


== 暗号化（編集の禁止）の解除 ==

qpdfで--decryptをする

== 結合 ==

<code>pdftk *.pdf cat output out.pdf compress</code>

compressはなくてもいい気がする。あるとサイズが増えることさえあった（？）

== 圧縮 ==

[https://zat.ifdef.jp/html/2010/09-17.html https://zat.ifdef.jp/html/2010/09-17.html]

ghostscriptの/defaultがかなりよさそう？

== 余白追加 ==

==== 固定値 ====

元のサイズから固定値だけ大きくする場合（各辺3mm追加など）[https://github.com/abarker/pdfCropMargins pdfCropMargins]を使う。pipで入れられる。

<syntaxhighlight lang="shell">pdf-crop-margins -o out.pdf -p 100 -a4 $left $bottom $right $top in.pdf</syntaxhighlight>
（a4は、用紙サイズのA4とは無関係）

参考: [https://unix.stackexchange.com/questions/441888/add-extra-margin-on-right-to-a-pdf-without-losing-outline Add extra margin (on right) to a pdf without losing outline?]

==== コンテンツに応じて計算 ====

コンテンツに対する余白を指定したい場合。

上記のpdfCropMarginsでもいいし、TeX Live付属のpdfcropでもできる。

[https://stackoverflow.com/questions/16158435/add-margin-to-pdf-file-when-merging-using-pdftk-or-similar Add margin to PDF file when merging using PDFTK or similar]

== 重ね合わせ ==

pdftkなら(multi)stamp/background [https://satiseni.hateblo.jp/entry/2020/07/28/105907 https://satiseni.hateblo.jp/entry/2020/07/28/105907] ただ、全文検索ができない？（他の2つはできた）

qpdfだと--underlayとか--overlay

cpdfならstamp-onとかcombine-pages [https://www.coherentpdf.com/cpdfmanual/cpdfmanualch8.html https://www.coherentpdf.com/cpdfmanual/cpdfmanualch8.html]


== PDF/Aへの変換 ==

[https://stackoverflow.com/questions/1659147/how-to-use-ghostscript-to-convert-pdf-to-pdf-a-or-pdf-x https://stackoverflow.com/questions/1659147/how-to-use-ghostscript-to-convert-pdf-to-pdf-a-or-pdf-x]


== しおり（table of contents） ==

[https://superuser.com/questions/311388/how-can-the-table-of-contents-in-a-pdf-file-be-edited https://superuser.com/questions/311388/how-can-the-table-of-contents-in-a-pdf-file-be-edited]　によるとJPdfBookmarksがよさそうだった（使ってみたが実際よかった、GPLだし）、pdfModとかいうのもいつか使ってみるかも


==== JPdfBookmarks ====

しおり情報をdumpしたファイルを編集するとよい、open/closedというのはしおりが折りたたまれているべきかどうかを指定するっぽい

<code>FitPage</code>にするとジャンプしたときに必ずビューアの表示サイズが調整されて1ページが画面に収まるよう変更されてしまう。<code>FitWidth</code>だと「幅に合わせる」になる。直したいときは<code>TopLeftZoom,0,0,0.0</code> にするとよい。ただし手間がかかるし、普通に全画面で見るならそこまで不便はないかも。

あと普通にpdftkも使えるっぽい（djvuのところでも引用した[https://bobbielf2.github.io/blog/2017/04/11/preserve-the-table-of-contents-when-converting-a-book-from-djvu-to-pdf/ https://bobbielf2.github.io/blog/2017/04/11/preserve-the-table-of-contents-when-converting-a-book-from-djvu-to-pdf/]など参照）


== PDF→SVG ==

pdftocairoというのがlatexに入っている。[https://acetaminophen.hatenablog.com/entry/2015/03/10/154412 ここ]も参照。

pdftocairoを呼び出す設定をVSCodeのLaTeX拡張に書けばよい。 [[LaTeX|LaTeX]] を参照。

あと、Inkscapeでもできるはず。


== djvuの表示、pdfへの変換 ==

djvulibreを入れる（Winもある）

bookmarkに関しては[https://bobbielf2.github.io/blog/2017/04/11/preserve-the-table-of-contents-when-converting-a-book-from-djvu-to-pdf/ https://bobbielf2.github.io/blog/2017/04/11/preserve-the-table-of-contents-when-converting-a-book-from-djvu-to-pdf/] にあるPythonコードを改変したものを用いる


== OCR ==

ocrmypdfを使おう


==== OCRデータだけにする ====

ghostscriptを使うと画像とアウトラインデータを消せるので実質的に不可視テキストだけになる [https://askubuntu.com/questions/477663/how-to-remove-images-from-a-pdf-file https://askubuntu.com/questions/477663/how-to-remove-images-from-a-pdf-file]
[[Category:IT]]{{#seo:|title={{FULLPAGENAME}} - Turgenev's Wiki}}

Windowsでエクスプローラーからフォルダを各種ターミナルで開く

2025-06-30T09:02:40Z

Turgenev: Notion-MW

Explorerの右クリックメニューやアドレスバーからフォルダを各種ターミナルで開くための設定方法の紹介。cmd.exe, powershell（pwsh含む）, Cygwin, Git Bashの4つに対応。

== 基本 ==

* [[Windowsの右クリックメニューから複数ファイルをまとめて開く|Windowsの右クリックメニューから複数ファイルをまとめて開く]] のように、レジストリでフォルダ・フォルダ背景の右クリックメニューを編集できる。
** Windows10までの右クリックメニューに戻そう。
** <code>command</code>キーの既定値に直接コマンドを書く方法と、<code>DelegateExecute</code>値（など）を使ってCOMを通じて実行する方法（このために[https://github.com/ge9/ExecuteCommand-Pipe https://github.com/ge9/ExecuteCommand-Pipe]（使い方はレポジトリの説明を参照）を作った）がある。
** HKLMにあるマシン全体の設定は、それ自体は管理者権限（あるいはTrustedInstallerなどさらに上の権限）がないと書き換えられないが、HKCUに値があればそちらが優先されるので、自分だけに関する設定変更ならユーザー権限だけで可能である。
** <code>Directory</code>や<code>Directory\Background</code>の直下に<code>runas</code>という名前でキーを作った場合は、自動的に<code>command</code>の内容が管理者権限で実行される。ただ、<code>runas</code>という固定のただ一つの名前しか使えないため、例えば管理者としてコマンドプロンプトを開くメニューとPowerShellを開くメニューを共存させることができない。そのためこの記事では<code>runas</code>キーを使用するのではなくコマンドの中で明示的に管理者としての実行を行っている。
* Explorerのアドレスバー（address bar, location barなど）にcommandと入力してEnterを押すと、そのフォルダをカレントディレクトリとして<code>command</code>というコマンドが実行される。
** このアドレスバーの仕様はおそらく「ファイル名を指定して実行」とほぼ同じ。<code>command</code>で（メインとして）指定するファイルはフルパスなら必ず動作し、Pathが通っているまたはApp Pathsに登録されているならファイル名だけでよく、さらにbatやexeの場合は拡張子も省略できる。さらに、ほとんど知られていないが実はApp Pathsの値には実行ファイル以外も書けるようである。
** つまり、パスの通っているフォルダにあるimage.pngはフルパスを打たなくても「image.png」で開けるし、さらにはApp Pathsの<code>openimage.exe</code>というキーにimage.pngのフルパスを書けば<code>openimage</code>と打つだけで（実際にはそのような実行ファイルは全く存在しないにもかかわらず）image.pngが開くようになる。当然、vbsなども拡張子無しで呼び出せることになる。

== ポイント ==

==== パス名のルール ====

* Windowsではパスの長さが260文字以下という制限がある。詳しくは[[Windowsのパス長さ制限に関して|Windowsのパス長さ制限に関して]] 参照。
** 制限を超えるような長いパスは<code>\\?\</code>というプレフィックスを付けて（UNCパスの一種として）扱われる。
*** このようなフォルダをカレントディレクトリとしてコマンドを実行することはできないので、アドレスバーに打ち込む方式は使えない（System32をカレントディレクトリとして実行される）。wt -dなどにも指定できない。
*** 右クリックメニューでは、commandの既定の値に直接書く方式の場合は、<code>NoWorkingDirectory</code>を設定しないと呼び出されなくなる。
*** シンボリックリンク/ジャンクションでパスを短くしてやれば普通に扱えるようになる
* 普通に入力できる文字でWindowsのファイル名に使えないのは、<code>\</code> <code>/</code> <code>:</code> <code>*</code> <code>?</code> <code>"</code> <code><</code> <code>></code> <code>|</code>の9個（エクスプローラーの画面で入れようとすると表示される）。
** その他、ヌル文字やタブスペースのような0x20未満の制御文字も使えない（はず）。
*** これらを含むファイルはGit Bash/Cygwinを使っても作れない。
*** NTFS自体の制限はおそらく<code>/</code>だけで、それ以外に関してはLinux上で作ってからWindowsで見ると見られることもある。中身の閲覧などは不可。
* また、末尾が空白またはピリオドのファイルも禁止で、Explorerやcmdでは作れない（自動で除去される）。
** これらはGit Bash/Cygwinなら作れる。前者はエクスプローラーで閲覧など多少の操作ができるが後者はほとんど何もできず、DelegateExecuteの右クリックメニューでもピリオドが外れた名前しか取得できない。
* 先頭が空白のファイルはExplorerだと作れないがcmdなら作れる。禁止ではないはず。


==== Git Bash/Cygwin ====

* Git BashではWindowsの実行ファイルにスラッシュ付きオプションを渡すときはスラッシュを2つにする必要がある。<code>cmd //c</code>や<code>bcdedit //v</code>など。
* printf関数の%qオプションを使うと、文字列をエスケープされた状態にして返してくれる。これはshからの呼び出し先の別のshで再びフォルダ名をcdなどの引数として利用したいときに使える。
** bash（POSIX互換ではない）の組み込みコマンドのprintfと、独立実行ファイル（GNU Coreutilsの一部）である/bin/printfがある。基本的な趣旨としては同一のコマンドだが、組み込みコマンドのほうは入力に<code>"</code>が含まれていない限り結果にも<code>"</code>が使われることはないようで、このおかげで意図しない動作を回避できることがある。今回扱う例に関しては前者が後者の上位互換であるということになる。後者を使っているものはそれでも動いたものである。
** そもそも%qは組み込みコマンドのほうにしかないという話もある。環境によって違いそう。
* <code>\\?\</code>が付くような長いパスをカレントディレクトリにしていても、Git Bash/Cygwinに付属の（というかMSYS/Cygwin向けにコンパイルされた？）exeなら実行できる。
* Git Bashの(ba)shは<code>--login</code>をつけて起動してもカレントディレクトリが維持されるが、<s>Cygwinの(ba)shは</s><s><code>--login</code></s><s>をつけると強制的にホームディレクトリに移動する。</s>
** 2024/4頃、Cygwinの挙動が変化し、カレントディレクトリが維持されるようになっていることに気付く。変わっていた方のバージョンは3.5.3、変わっていない方は3.3.6であった。
** ところで、[https://superuser.com/questions/345964/start-bash-shell-cygwin-with-correct-path-without-changing-directory Start bash shell (cygwin) with correct path without changing directory - Super User]の通り、<code>CHERE_INVOKING</code>という変数を1に設定しておけばカレントディレクトリは維持される。
* Git Bashにおいては環境変数を正しく設定するため<code>--login</code>の時点で環境変数<code>MSYSTEM</code>を<code>MINGW64</code>にしておく必要がある。[[Windowsでのターミナル環境|Windowsでのターミナル環境]] 参照。


==== powershell/pwsh ====

* バージョン5まで（Windows PowerShell）はpowershell.exe、6以降（PowerShell Core, PowerShell）はpwsh.exeと実行ファイル名が違う
** 以後、「powershell(.exe)」と「pwsh(.exe)」で呼び分ける。ただし手元ではpowershellの5.1とpwshの7.2～7.3くらいでしか試していないので、一部バージョンではまた違う可能性もある。
** pwshは必ずしもWindowsに標準では入っていないので、以下の例でもあまり依存しないように気を付ける。
** 基本、シングルクォートで囲えばほとんどの特殊文字が無効になり、シングルクォート自体を書くときは2つ並べる。ただし注意点として、驚くべきことにpowershell/pwshでは「全角のシングルクォート（U+2018-U+201B、<code>‘</code> <code>’</code> <code>‚</code> <code>‛</code>の4つ）」も通常のシングルクォートと同じ効力があるので、同じようにエスケープする必要がある（参照: [https://learn.microsoft.com/ja-jp/powershell/scripting/lang-spec/chapter-02?view=powershell-7.2 https://learn.microsoft.com/ja-jp/powershell/scripting/lang-spec/chapter-02?view=powershell-7.2]）。掲載したスクリプトでは省略しているがやることは同じ。
* powershell.exe
** -Commandがなくても付けたのと同じ扱いになる？
*** 逆に、-Commandを付けなければいけないという点を除いてはpwshがpowershellの上位互換という感覚である（新しいのでそれはそう）。
** <code>`</code>や<code>[]</code>を含むフォルダの扱いにバグがあり、cmdなどでこれらのフォルダをカレントディレクトリとした状態で5系のPowerShellを起動すると<code>C:\</code>や<code>C:\Windows\System32\WindowsPowerShell\v1.0></code>をカレントディレクトリとして起動される（たとえば<code>C:\somefolder][</code>なら前者、<code>C:\somefolder[]</code>なら後者）。
** -Fileを使用してスクリプトを実行するとき、ダブルクォーテーションで囲われていない <code>-</code> が引数に含まれているとエラーになるバグがある。
* powershell.exe・pwsh.exe共通
** 連続した<code>`</code>があるフォルダに関する挙動にバグがある。コンソールプログラムを実行しても新規ウインドウで開かれる、そこをカレントディレクトリとしたときにファイルをmvできないなど。
** <code>`</code>や<code>[]</code>を含むフォルダに関しても、絶対パス指定したりきちんとエスケープしたりすれば操作自体はできる（場合もある）。
*** エスケープはいずれも直前に<code>`</code>を付ける。
*** これらを特殊文字として扱いたくないときは<code>-LiteralPath</code>を付けると良い場合もある。
** UNCパスをカレントディレクトリにすることができるが、<code>Microsoft.PowerShell.Core\FileSystem::\\</code>とかいう謎のプレフィックスが付く。
** 末尾が空白のフォルダについてはcdできず、Cygwinなどでそのようなフォルダをカレントディレクトリとして起動したとしても<code>C:\Windows\System32\WindowsPowerShell\v1.0</code>や<code>C:\Program Files\PowerShell\7</code>に移動してしまう。
** 8.3形式のパスを強制的に長い名前に戻してcdしてしまう。その結果、長いフォルダをカレントディレクトリとして外部プログラムを実行できなくなる。
* PSModulePath環境変数の関係な気がするが、pwshの中でcmdを起動してその中でpowershellを起動したりするとPSReadLineモジュールが読み込めない（<code>PSReadline モジュールを読み込めません。コンソールは PSReadline なしで実行されています。</code>）とか言われたりする

==== 環境変数への置換 ====

cmdなどを使うと<code>%</code>で囲われた環境変数（<code>%PATH%</code>など）が置換される。<code>%</code>はファイル名にも普通に使える文字なので、注意が必要となる

* 該当の名前の環境変数が定義されていたときのみ置換が行われ、定義されていなければそのままになる。
* <code>%</code><code>VAR</code><code>%</code>の置換は必ずしもcmdだけで行われるわけではない。「ファイル名を指定して実行」、VBSのWscript.Shellのrun、conhost、wtの引数などでも行われる。しかしCreateProcessやShellExecute(Ex)やレジストリ値では行われない（無理やりREG_EXPAND_SZにしたら展開されるが、後述の<code>%V</code>との適用順などは不明）。
* 一般には、環境変数には英数字とアンダースコアしか使えないとの説明もよくあるが、実際にはほとんどの記号が有効である。従って、<code>^%PATH^%</code>のようなキャレットによるエスケープはcmd向けにはある程度有効だが、<code>PATH^</code>という環境変数が定義されているとうまく動かない。
* （そういう変数が定義されていることは現実にほとんどないだろうし、それが保証できるなら以下の部分を読む必要はない）

これを防ぐ方法はいくつかある。ちなみに、<code>%%</code>でのエスケープというのはバッチファイルの中だけの話で、今回の場面では以下より簡単なエスケープ方法は多分ないと思う。

<ol style="list-style-type: decimal;">
<li>既に定義されているかもしれない環境変数をバックアップし、一時的にその中身を<code>%</code>に変えて使用することでリテラル文字としての<code>%</code>を表現し、後で元に戻す。
すなわち、<code>MY_PERCENT</code>のような変数の中身をバックアップし、<code>MY_PERCENT</code>の中身を<code>%</code>に変え、未知の文字列中の<code>%</code>をすべて<code>%MY_PERCENT%</code>にすることでこの部分が置換によって<code>%</code>に変わるのを利用して<code>%</code>をそのまま渡すということである（環境変数の置換は左から順に行われるため、たとえば<code>%MY_PERCENT%PATH%MY_PERCENT%</code>の<code>%PATH%</code>が置換されることはない）。受け渡しが終わったら<code>MY_PERCENT</code>の中身を復元する。
これは、変数のバックアップとリストアを同じプロセス・スクリプト内で行える（呼び出した後に元に戻ってくる）場面で有用である。呼び出し先プロセスでリストアすることも不可能ではないと思うが、環境変数には任意の文字が入る可能性があることを考えるとエスケープが大変困難になることが予想される。</li>
<li>VAR1, VAR2, VAR3, …のような無限個の変数を最初からチェックし、最初の未定義の変数を上記と同様に使用し、後で未設定にする。
ほぼ上記と同じだが、内容のリストアでなく未設定にするだけなので、呼び出し先プロセスでも容易に行える。ただし実装が面倒である。</li>
<li><code>%</code>を<code>==%</code>へと置換して、置換のプロセスを抜けた段階で元に戻す。
<ul>
<li>これは、最初の文字以外に<code>=</code>が含まれる環境変数名は（実際に環境変数が設定されていたとしても絶対に）置換されないことがわかったためである。
<ul>
<li><code>%=%</code>（あるいは、<code>%=VAR%</code>など）は少なくともcmdの対話シェル上だと置換されてしまうので<code>=%</code>へのエスケープだと不十分に見えるが、実際には<code>=</code>一つでも問題なく動く場合もあった。</li>
<li>しかし、動かないときもあるので、多くの例では<code>==%</code>にエスケープしている。<code>=%</code>になっているものは、試した限りはそれでも問題なく動いているものである。</li>
<li>[https://learn.microsoft.com/en-us/windows/win32/procthread/environment-variables Environment Variables - Win32 apps | Microsoft Learn]では「<code>=</code>は環境変数に使えない」と書かれていて、ダイアログからでも設定はできないが、レジストリだと無理やり設定できる。
<ul>
<li>ユーザー環境変数に設定する分にはとりあえず問題なさそうだが、システム環境変数にレジストリから<code>=</code>（と、<code>=</code>を名前に含むいくつかの変数。どれが原因かは正確にはわからない）を無理やり追加したら0xc000021のブルースクリーンでWindowsが起動しなくなった（Linuxからchntpwで該当の変数を全て削除したら治った）のでこれはやってはいけない。</li></ul>
</li>
<li>ちなみに、<code>=</code>や<code>%</code>はUnix側では特殊文字ではないので、printfとの適用順はあまり気にする必要はない。</li></ul>
</li>
<li>この方法のメリットは、一度置換してしまえばその文字列を何度使いまわしても変化がないことが保証されることと、未定義の変数の探索や変数のリストアが必要ないことである。
<ul>
<li>要は<code>%(=を含まない文字列)%</code>を含まない文字列だけを値にとる単射を構成すればいいだけなので、base64エンコーディングのようにしても構わない。</li></ul>
</li>
<li>ただ、<code>==%</code>を<code>%</code>に置換するという操作はPowerShellやshにとっては容易でもcmdにとっては不可能に近いので、最終的な呼び出し先がcmdであるときには採用しづらい。</li></ul>
</li></ol>

また、今回の記事ではcmdやvbsのRunを経由してコマンドを実行しているものが多くあるが、このスクリプトの内容自体もエスケープが必要である。つまり、例えば<code>cmd /c</code>の内側に<code>$mypath.Replace('%','%MY_PERCENT%')</code>というPowershellコードが含まれるなら、<code>','</code>や<code>MY_PERCENT</code>という環境変数が定義されていた時にその部分が置換されてしまう。これを回避するのはそこまで難しくなく、この例であれば<code>$mypath.Replace('%'.Trim('='),'%'.Trim('=')+'MY_PERCENT%')</code>のように<code>=</code>を含む無意味なコードを挿入すればよい。また、<code>%</code>をいったん<code>==%</code>にしている部分に関しては、<code>==%</code>ではなく<code>==%==</code>にすることで問題を避けられるだろう。無駄に複雑になるのでスクリプト例ではそのような措置はしていない。

==== cmd ====

* UNCパス（<code>\\?\</code>だけでなく普通のUNCパスも含む）をカレントディレクトリにすることはできない（rdなど一部コマンドでの取り扱いは可能）。
* 末尾が空白のフォルダにcdすることはできないが、Cygwinなどでそのようなフォルダをカレントディレクトリとした状態でcmdを起動した場合は、そのフォルダをカレントディレクトリとして起動する（外部プログラムの起動はできないがcdなどの内部コマンドは有効で、一度でも出たら戻れない）。
* 各種のパース規則が本当に謎。特に引用符周りは地獄である。[https://thinca.hatenablog.com/entry/20100210/1265813598 cmd.exe のコマンドラインの仕様を解析してみた - 永遠に未完成]を読むとわかるが、例えば「ファイル名を指定して実行」で以下の挙動を確かめよう。
** <code>cmd /k echo "a b"c d"</code>→<code>"a b"c d"</code>と出る
** <code>cmd /k echo "a & b"c d"</code>→<code>"a & b"c d"</code>
** <code>cmd /k echo "a b"c & d"</code>→<code>echo "a b"c</code>と<code>d"</code>がそれぞれ別々に実行される
** すなわち、<code>"</code>が一見特殊文字でないかのような振る舞いをする（そのまま出力される）割に、その前後で特殊文字の扱いが切り替わっている。


==== Windows Terminal ====

* 以下、wtと略す（実行ファイル名がwt.exeなため）。パスが通っているものと仮定する。
* wtでは<code>;</code>が特殊文字になるようで、<code>\;</code>とエスケープが必要。[https://github.com/microsoft/terminal/issues/13264 https://github.com/microsoft/terminal/issues/13264] かな？
** <code>"</code>も<code>\"</code>にする必要がある。一方で、単一の<code>\</code>は（うしろに<code>;</code>や<code>"</code>などがなければ）そのまま<code>\</code>になるようである。大丈夫なのか…？
* 起動時にカレントディレクトリがユーザーフォルダ（%USERPROFILE%）になる
** <code>-d</code>オプションで明示的に指定することができる

==== 連続空白 ====

空白が連続するファイル名の対応は割と厄介である。Windows側では引数を<code>""</code>で囲うことで、またsh側では適宜<code>IFS=</code>と設定することで対処できる。


==== Unicode対応 ====

* UTF8を使おう
* <code>chcp 65001</code>が一応使えるが、一旦シェル内部に入らないと使えないのでやや不便
** 使わなくても大丈夫なときもある。あまりちゃんと理解できていないが、経験上、powershellで<code>$input</code>変数を用いて標準入力を受け取る際には<code>chcp 65001</code>が必要そう。
* /bin/printfやprintfの実行時には<code>LANG</code>を<code>en_US.UTF8</code>とかに設定する。
** Cygwinなら不要？

==== デバッグ時 ====

* 管理者権限のものを試すときでもまず<code>-Verb Runas</code>を外して動作確認するとよい。
* 後述のwaitrunも役に立つだろう。
* 特殊文字に関しては、最初は空白のないフォルダ、次に空白のあるフォルダや連続空白のあるフォルダ、次にシングルクォートや<code>%PATH%</code>を含むフォルダなどとだんだん難しくしていくとよい。
* それとは別に、Unicode対応、<code>C:\</code>（ドライブ直下）対応、259文字のフォルダ対応（後述）などをチェックする
* 難しい例は、例えば<code>z 𠮷𠮷%PATH% ' '' ` `` $PATH & && %%PATH%%[] ] [ ^ ^^ ' ; ;; 𩸽𩸽!PATH!#$%&'()=~{`+}_,.][;@^- - ‘ ’ ‚ ‛</code>のような感じ（適当）。こんなファイル名を現実に見ることはないが、エクスプローラー上で普通に入力できる内容である。
** 「𠮷」はBMP外かつJIS外の漢字としては最も変換で出しやすいのでテストに重宝する。（𩸽はBMP外だがJIS外ではない（第4水準））

==== その他 ====

* デフォルトシェルは、通常ユーザーはwtでも管理者の場合はconhostに設定されているっぽい？
* <code>C:\</code>のようなドライブ直下のパスは末尾に<code>\</code>を付けなければいけないことが多い。たとえばwt -dの引数にする場合など。またcmdでcdコマンドや<code>CD</code>環境変数を見るときもドライブ直下のときだけは<code>\</code>が付いて返ってくる。
** ただ、wt -d に<code>C:</code>が渡されるように見えるのになぜか動いているものもある。未調査。
* shやcmdなどの中に一旦入ってしまうと一部の環境変数などが書き換わってしまうかもしれないが、多少は許容することとする。
* コマンド例は網羅的でない可能性があり、色々な書き方を提示しようとあえて統一していないところもある。現実にはもっと簡単なやり方があるかもしれない。あくまで一例ということで。
* CygwinとGit Bashはほぼ同じなのでGit Bashを主に載せてCygwinは適宜差分のみ記述する。
* shは、特にベースのシェルとして使うにはエスケープの方式などでWindowsと相性が悪く使いづらい感じがする。逆にcmdは内部コマンドは地獄だがベースのシェルとしては意外と副作用が少なく、そう悪くはない。
* 以下の例ではCygwinやGit Bashの実行ファイルにはPATHを通していないことを想定している。<code>C:\cygwin64</code>あたりは適当に読み替えていただきたい。
* 2021年途中ごろまで、wtなどのストアアプリ系？の実行ファイル（Explorer上で0バイトになってるエイリアス）をGit Bashから実行できない（Permission deniedとなる）バグがあった。 [https://github.com/git-for-windows/git/issues/2675 https://github.com/git-for-windows/git/issues/2675]
* ネットワークドライブは各ユーザー対象に割り当てられているせいなのか、管理者として実行すると利用できないらしい。割り当てられる前のネットワークパス自体は有効。
* wtを管理者権限で呼び出すときに（確率的に）ウインドウが最前面にならないことがある。chcpの有無で変わったりするなど詳細不明。conhostだとならない気がする。startrunなどを介して実行すると必ず最前面に出るようになるっぽい。


== 準備: win-console-delegator ==

cmdやPowerShellやCygwinのbashなどのシェルを使えば、スクリプトを起動して複雑なコマンドを呼び出せたり、パイプ実行が可能になったりと色々便利だが、それだけのためには大仰すぎて、特殊文字の扱いなどがかえって仇になることもある。

そこで、シェル関連の操作に汎用的に使えるコマンドをいくつか作成して公開した。[https://github.com/ge9/win-console-tools https://github.com/ge9/win-console-tools]

* 以前はC++で書いていた（[https://github.com/ge9/win-console-delegator https://github.com/ge9/win-console-delegator]）が、C#のほうが文字列の扱いなどが簡明。

ただし、これはあくまで筆者が独自に作ったものであり、Windows標準のもので何とかしようとするのが面白いところでもあるので、それほど積極的には使わない。今後出てくる例はすべて、これらを一切使わなくても（余計な環境変数が設定されてしまうかもしれないという点をのぞけば）同等の機能が実現できる。

<ul>
<li>runother
与えられた引数を特定の文字列とつなげて実行してくれるプログラム。この実行ファイル自体の名前を適宜変更して使用し、「特定の文字列」は別のファイルから読ませる。使用例は[[Windowsでのターミナル環境|Windowsでのターミナル環境]] を参照。</li>
<li>runother-gui
runotherとほぼ同じだが、コンソールアプリケーションではなくWindowsアプリケーション（黒いウインドウが出ない、cmd上で実行したときに終了待ちが行われないなど）。</li>
<li>evalrun
与えられたコマンドラインを実行し、その出力をそのままコマンドラインとして実行するコンソールアプリケーション。（テキストファイルからのコマンドラインの読み込みなどに使える）</li>
<li>startrun
与えられたコマンドラインをWindowsのデフォルトシェルで起動するだけのWindowsアプリケーション。</li>
<li>waitrun
与えられたコマンドラインを実行したあとキー入力を待ってから終了するコンソールアプリケーション。一瞬でウインドウが消えてしまうときのデバッグに使いやすい。</li>
<li>hiderun
コンソールウインドウ非表示の状態で与えられたコマンドを実行するWindowsアプリケーション。（GUIアプリケーションなどを与えた場合は非表示にならないかも）
vbsのvbHideでも非表示にできるが、コンソールウインドウの表示位置をみると非表示のウインドウが一つ挟まっていることが分かるのに対して、こちらの場合はそうならない。</li>
<li>piperun
与えられたコマンドラインを最初の<code>|</code>とそれ以降の2つに区切ってそれぞれコマンドとしてパイプでつなげて実行するコンソールアプリケーション。ただし最初のコマンドのほうに<code>|</code>自体を入力したいときは<code>||</code>でエスケープする。また2つ目のコマンドの先頭の空白は除去される。</li>
<li>piperunex
piperunと似ているが、2つだけでなく3つ以上の任意個のパイプ実行を一度に行う。一見便利だが、コマンドの後ろ側に未知の文字列が渡される場合、<code>|</code>をエスケープする必要が生じる。
<code>piperun piperunex command1 || command2 || ... || commandN | unknown_commandline</code>のように外側を<code>piperun</code>で囲うと安全。</li>
<li>adminrun
与えられたコマンドラインを管理者として実行するWindowsアプリケーション。<code>ShellExecuteEx</code>では実行ファイルパスと引数は別々に指定しなければいけないので最低限の引数の解析を行っている。PowerShell経由で管理者権限で実行するときのような面倒なエスケープが全て不要になるため非常に使いやすいが、この記事ではこれに依存しないようにする。
<ul>
<li>ちなみにこういうのもある。[https://github.com/mattn/sudo mattn/sudo: sudo for windows] これは、通常のUACのように別ウインドウで実行するのではなく、localhostのランダムなポートを使い、自分自身にポート番号を渡しつつ管理者権限で呼び出すことで標準入出力を転送し、元の端末でそれを読み書きできるという点で、linuxのsudoに近い。しかし標準入出力を介しているので、<code>cmd /c for /?</code>や<code>cmd /c pause</code>の挙動が変わってしまうという問題がある。また、呼び出し元でchcp 65001をしていると文字化けする。また、コマンドライン引数を一旦配列に分割してから組み直しているので情報が一部落ちている。あと、セキュリティ的にも懸念があるかもしれないが、これはそもそもLinuxのsudo自体がまずどうなの？という気持ちになった。（未解決）（参照: [https://twitter.com/e9g/status/1687385469921931264?s=20 https://twitter.com/e9g/status/1687385469921931264?s=20]）</li></ul>
</li>
<li>uacrun
startrunと同じだが、コンパイル時のマニフェスト設定でこのプログラム自体の実行に管理者権限を要求するようにしたので、adminrunと同じように使える（管理者権限で実行する対象が渡されたコマンドではなくuacrun自体になるという違いはある）</li>
<li>pecho
与えられたコマンドライン引数をそのままコンソールに出力する。→WindowsでUnicode文字（特にU+10000以上）を正しく表示（&ファイルに書き込み）するには、「出力先がコンソールならWriteConsoleW、そうでなければWriteFileを使用する」といった非常に面倒な実装が必要であり（参照: [https://twitter.com/mattn_jp/status/542581083242364928 https://twitter.com/mattn_jp/status/542581083242364928] など）、C++やC#では扱いづらい。そこでrustを用いて実装した。→[https://github.com/ge9/pure-echo-win pure-echo-win]</li>
<li>printcd
カレントディレクトリをコンソールに出力する。（ちなみにpwdの由来はprint working directoryなのでそれに倣った）</li></ul>


== 注意: 当初は後述のNoWorkingDirectoryを知らなかったので1.の方法に頼っていたが、実際には2.の方法のほうが簡明なので、そちらを使うことを勧める。1.（と1.1.）は残しておくが、読む必要はあまりない。 ==

{{UnderConstruction|Windowsでエクスプローラーからフォルダを各種ターミナルで開く}}


== 1.標準入力から受け取る場合 ==

まず「標準入力からディレクトリのフルパスを受け取り、そのディレクトリで各種ターミナルを起動するコマンド」を紹介する。

そのようなコマンドを仮に<code>openterm</code>とすると、ExecuteCommand-Pipeを使用して、レジストリ（該当CLSIDのLocalServer32の既定の値）に以下のように書くことで、CLSIDが右クリックメニューのDelegateExecute値に使えるようになる。

<code>C:\path\to\ExecuteCommand4000.exe h openterm</code>

<code>h</code>はコンソールウインドウを非表示にするExecuteCommand-Pipeのオプションである。

また、この<code>openterm</code>の部分は非常に長くなることがあり、その場合レジストリに書いて直接編集するのは手間がかかる（操作もしづらいし、更新を即座に反映させるために「<code>LocalServer32</code>」キーの名前などを変えて戻す必要もあって面倒）。そこで、runotherを使ってtxtに<code>openterm</code>の内容をそのまま書くことで、<code>openterm</code>の部分にそのexeの名前だけを書けばよくなる。

また、いくつかはCygwin/Git Bash向けに冒頭でcygpathによる変換を入れているが、これを取り除けば、Cygwin/Git Bash用のパスを受け取って動作するコマンドということになる。

では以下で、<code>openterm</code>部分についてそれぞれ紹介する。

* 直接コマンド記入でも<code>NoWorkingDirectory</code>を指定すれば<code>\\?\</code>に対応できるというのをこのセクションの大部分を書き終えてから知ったので、このセクションは内容の多さの割には実際の必要性はそこまで大きくないかもしれない。


=== Git Bash ===


==== <code>git-bash.exe</code>で開く ====

この場合shの感覚で<code>git-bash.exe</code>に引数を渡せば勝手にminttyのウインドウで開いてくれるので最も楽である。

<code>cmd /c ""C:\Program Files\Git\usr\bin\cygpath" -f - | "C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=;/bin/env LANG=en_US.utf8 /bin/printf %q $(/bin/cat)" | "C:\Program Files\Git\usr\bin\xargs" -d '\n' -I {} "C:\Program Files\Git\git-bash.exe" -c "cd {};exec bash""</code>

* Git BashのcygpathでGit Bash用のパスに変換
* printfでエスケープ、utf8を設定
* git-bash.exeに渡す


==== デフォルトのターミナルで開く: ①startrunを使う ====

<code>cmd /c ""C:\Program Files\Git\usr\bin\cygpath" -f - | "C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=;/bin/env LANG=en_US.UTF8 /bin/printf %q $(/bin/cat)" | "C:\Program Files\Git\usr\bin\xargs.exe" -d '\n' -I {} startrun "C:\Program Files\Git\usr\bin\env.exe" MSYSTEM=MINGW64 "C:\Program Files\Git\usr\bin\bash.exe" --login -i -c 'cd {};exec bash'"</code>

* <code>git-bash.exe</code>や<code>C:\Program Files\Git\bin</code>のbashではなく/usr/binのbash.exeを使う。以後同じ。


==== デフォルトのターミナルで開く: ②cmdのstartを使う ====

<code>cmd /c ""C:\Program Files\Git\usr\bin\cygpath" -f - | "C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=;/bin/env LANG=en_US.UTF8 /bin/printf %q $(/bin/sed 's/\\^/^^/g;s/%/=%/g;s/&/^&/g')" | "C:\Program Files\Git\usr\bin\xargs.exe" -d '\n' -I {} cmd //c start "" "C:\Program Files\Git\usr\bin\env.exe" MSYSTEM=MINGW64 "C:\Program Files\Git\usr\bin\bash.exe" --login -i -c 'cd "$(echo {} ^| sed s/=%/%/g)";exec bash'"</code>

* この場合、cmdによる環境変数への置換を避ける必要があるほか、キャレットによるエスケープにも対応する必要がある。
* Git Bashからcmdを実行しているので<code>//c</code>のところのスラッシュは2つ。

==== conhostで開く ====

<code>cmd /c ""C:\Program Files\Git\usr\bin\cygpath" -f - | "C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=;/bin/env LANG=en_US.UTF8 /bin/printf %q $(/bin/sed 's/%/=%/g')" | "C:\Program Files\Git\usr\bin\xargs.exe" -d '\n' -I {} conhost "C:\Program Files\Git\usr\bin\env.exe" MSYSTEM=MINGW64 "C:\Program Files\Git\usr\bin\bash.exe" --login -i -c 'cd "$(echo {}|sed s/=%/%/g)";exec bash'"</code>

conhostによる環境変数の置換を抑制。


==== Windows Terminalで開く ====

<code>cmd /c ""C:\Program Files\Git\usr\bin\cygpath" -f - | "C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=;LANG=en_US.UTF8 printf %q $(/bin/sed 's/%/=%/g')" | "C:\Program Files\Git\usr\bin\sed.exe" "s/;/\\\\;/g" | "C:\Program Files\Git\usr\bin\xargs.exe" -d '\n' -I {} wt "C:\Program Files\Git\usr\bin\env.exe" MSYSTEM=MINGW64 "C:\Program Files\Git\usr\bin\bash.exe" --login -i -c "IFS=\\;cd $(echo {}|sed s/=%/%/g) \\;exec bash""</code>

上記に加えてセミコロンへの対応が必要なのと、こっちは/bin/printfじゃなくて組み込みのprintfでこうしないとだめだった。


==== Cygwin ====

付属のminttyを使うものだけはGit Bashと割と差があるので載せる。

<code>cmd /c ""C:\cygwin64\bin\cygpath" -f - | "C:\cygwin64\bin\sh.exe" -c "IFS=;/bin/printf %q $(/bin/cat)" | "C:\Program Files\Git\usr\bin\xargs" -d '\n' -I {} "C:\cygwin64\bin\mintty.exe" -e "C:\cygwin64\bin\bash.exe" --login -i -c "cd {};exec bash""</code>


=== PowerShell ===


==== デフォルトシェル, startrun ====

* パスのエスケープがおかしい気がするが、なぜか動いている

<code>cmd /c ""C:\Program Files\Git\usr\bin\sed.exe" "s/'/''/g" | "C:\Program Files\Git\usr\bin\xargs.exe" -d '\n' -I {} startrun powershell -noexit -command Set-Location -literalPath "'{}'""</code>


==== デフォルトシェル, cmdのstart ====

<code>cmd /c ""C:\Program Files\Git\usr\bin\sed.exe" "s/'/''/g;s/%/=%/g" | "C:\Program Files\Git\usr\bin\xargs.exe" -d '\n' -I {} cmd //c start "" powershell -noexit -command Set-Location -literalPath '\'{}\'.Replace(\'=^%\',\'%\')'"</code>


=== cmd ===


==== Windows Terminal ====

<code>cmd /c chcp 65001 & powershell -Command "$mypath=($input | ForEach-Object { return $_ });$bak=$env:MY_PERCENT; $env:MY_PERCENT = '%';if ($mypath.Length -gt 258) { $mypath = cmd /c \"for %A in (`\"$($mypath.Replace('%', '%MY_PERCENT%'))`\") do @echo %~sA\" };$env:MY_PERCENT = $bak;wt -d ($mypath -replace ';', '\;') cmd"</code>

<ul>
<li>[[Windowsのパス長さ制限に関して|Windowsのパス長さ制限に関して]] でも書いた通り、Windows側はちょうど259文字の長さのフォルダだけは（その必要があるにもかかわらず）8.3形式を使った短いパスにして渡してくれない。そこで、パス長さが258を超えていればcmdに渡して8.3形式の名前に変換する処理をPowerShell側で行う。この際はエスケープされていない正確なパス名をcmdに渡さなければならないので<code>MY_PERCENT</code>の値を一時的に<code>%</code>に設定する方法をとっている。
<ul>
<li>念のため再確認しておくが、この<code>'%MY_PERCENT%'</code>の部分は<code>'%'.Trim('=')+'MY_PERCENT%')</code>などと変えておかないと、<code>MY_PERCENT</code>が定義されていた場合に正しく動作しない。</li>
<li>cmdではちょうど258文字のフォルダでもdirが失敗するなど挙動が不自然であるため、もう少し保守的に257を超えていれば短くするという仕様でもいいかもしれない。</li></ul>
</li>
<li>（追記）8.3形式のパスを取得するのは普通にPowerShell内でもできるらしい…。以下のようになる。
<code>if ($mypath.Length -gt 258) { $mypath = (New-Object -ComObject Scripting.FileSystemObject).GetFolder($mypath).ShortPath}</code></li></ul>

259文字のフォルダを無視するなら以下のように簡潔に済む。

<code>cmd /c chcp 65001 & powershell -Command wt '-d' $input.Replace(';','\;') cmd</code>

==== デフォルトシェル ====

これは案外難しい。なぜなら、cmd内でcdさせるのは%のエスケープの関係で難しく（cmd内で=を含む文字列を置換することがどうやってもできなさそう（外部プログラムを呼び出すのも難しそうだった）なので、未定義の変数を探索するやり方しかない）、Start-Processの-WorkingDirectoryやCygwinのshは8.3形式に対応していないからである。要は「与えられたディレクトリ（8.3形式のパスが含まれるかもしれない）をカレントディレクトリとして与えられたコマンドを実行する」だけやってくれるプログラムがあればよく、これ自体はそう難しくないことのはずだが、現状、Windows標準環境でこれができるのは自前でプログラムをコンパイルする以外だと（pwshを入れていいならpwshと）vbsしかないようである。結局、この部分をついでにやってくれるWindows Terminalのほうが楽ということになる。

たとえば以下のようなvbsを用意する。

<syntaxhighlight style="margin-bottom:0.2em;" lang="vb.net">Dim objShell
Set objShell = CreateObject("WScript.Shell")
objShell.CurrentDirectory = WScript.Arguments(1)
objShell.Run(WScript.Arguments(0)),,False</syntaxhighlight>
<div style='text-align: center;'>startatdir.vbs</div>

すると以下のように書ける。

<code>cmd /c chcp 65001 & powershell -Command "$mypath=($input | ForEach-Object { return $_ });$bak=$env:MY_PERCENT;$env:MY_PERCENT = '%';if ($mypath.Length -gt 258) { $mypath = cmd /c \"for %A in (`\"$($mypath.Replace('%', '%MY_PERCENT%'))`\") do @echo %~sA\" };$env:MY_PERCENT = $bak; wscript 'C:\path\to\startatdir.vbs' cmd ('\"'+$mypath+'\"')"</code>

なお<code>startatdir.vbs</code>のパス指定はフルパスが必要そう（ただしここはcmd /cの中なので<code>%USERPROFILE%</code>とかを使って書いてもよい）


== 1.1.標準入力から受け取る場合 - 管理者権限あり ==

上記の続きで、こちらは管理者権限ありのもの。


=== Git Bash ===


==== デフォルトシェル ====

<code>cmd /c ""C:\Program Files\Git\usr\bin\cygpath" -f - | "C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=;/bin/env LANG=en_US.UTF8 /bin/printf %q $(/bin/cat)" | "C:\Program Files\Git\usr\bin\sed.exe" "s/'/''/g" | "C:\Program Files\Git\usr\bin\xargs.exe" -d '\n' -I {} powershell -Command Start-Process -Verb Runas -Filepath '"C:\Program Files\Git\usr\bin\env.exe"' -ArgumentList '"MSYSTEM=MINGW64"', '"`"C:\Program Files\Git\usr\bin\bash.exe`""' , '--login', '-i' , '-c', "'\"cd {}; exec bash\"'" "</code>

* Start-Process自体がstartみたいなものなので、引数にコンソールアプリケーションを指定したらデフォルトシェルで開かれる。
* 最後のところ、「<code>"'\"cd {}; exec bash\"'"</code>」のかわりに「<code>'\'"cd {};exec bash"\''</code>」とか「<code>'\'\"cd {};exec bash"\''</code>」でも動くのは謎。シングルクォーテーションのエスケープ規則がわからない。参考→[https://twitter.com/e9g/status/1678283164689760256 https://twitter.com/e9g/status/1678283164689760256]


==== Windows Terminal ====

<code>cmd /c ""C:\Program Files\Git\usr\bin\cygpath" -f - | "C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=;LANG=en_US.UTF-8 printf %q $(/bin/cat)" | "C:\Program Files\Git\usr\bin\sed.exe" "s/'/''/g;s/%/==%/g;s/;/\\\\;/g" | "C:\Program Files\Git\usr\bin\xargs.exe" -d '\n' -I {} powershell -Command Start-Process -Verb Runas -Filepath wt -ArgumentList "'"'"C:\Program Files\Git\usr\bin\env.exe"'"'" , '"MSYSTEM=MINGW64"' , "'"'"C:\Program Files\Git\usr\bin\sh.exe"'"'" , "'--login'", "'-c'", "'"'"IFS=\\;cd $(echo {}| /bin/sed s/==%/%/g) \\; exec bash"'"' " "</code>

==== adminrunを使う ====

<code>piperunex "C:\Program Files\Git\usr\bin\cygpath" -f - | "C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=; /bin/env LANG=en_US.UTF8 /bin/printf %q $(/bin/cat)" | "C:\Program Files\Git\usr\bin\sed.exe" "s/%/==%/g;s/;/\\\\;/g" | "C:\Program Files\Git\usr\bin\xargs.exe" -d '\n' -I {} adminrun wt "C:\Program Files\Git\usr\bin\env.exe" "MSYSTEM=MINGW64" "C:\Program Files\Git\usr\bin\sh.exe" --login -c "IFS=\\;cd $(echo {}|| /bin/sed s/==%/%/g) \\; exec bash"</code>


=== PowerShell ===


==== Windows Terminal ====

<code>cmd /c ""C:\Program Files\Git\usr\bin\sed.exe" "s/'/''''/g;s/%/==%/g;s/;/\\\\;/g" | "C:\Program Files\Git\usr\bin\xargs.exe" -d '\n' -I {} powershell -Command Start-Process -Verb Runas -Filepath wt -ArgumentList 'powershell', '-noexit', '-command', 'Set-Location', '-LiteralPath', "'''\"{}\"''.Replace(''==%'',''%'')'" "</code>

* Cygwin系なしで

<code>cmd /c "chcp 65001 & powershell -Command Start-Process -Verb Runas -Filepath wt -ArgumentList 'powershell', '-noexit', '-command', 'set-location', '-literalpath', ('\"'''+($input -replace '''', '''''' -replace '%', '==%' -replace ';', '\;' )+'''.Replace(''==%'',''%'')\"') "</code>


=== cmd ===


==== デフォルトシェル ====

再び、startatdir.vbsを使う。

<code>cmd /c chcp 65001 > nul & powershell -Command "$mypath=($input | ForEach-Object { return $_ });$bak=$env:MY_PERCENT; $env:MY_PERCENT = '%';if ($mypath.Length -gt 258) { $mypath = cmd /c \"for %A in (`\"$($mypath.Replace('%', '%MY_PERCENT%'))`\") do @echo %~sA\" };$env:MY_PERCENT = $bak; Start-Process -Verb Runas -Filepath wscript -Argumentlist '//Nologo', 'C:\path\to\startatdir.vbs', 'cmd', ('\"'+$mypath+'\"')"</code>


==== Windows Terminal ====

<code>cmd /c chcp 65001 & powershell -Command "$mypath=($input | ForEach-Object { return $_ }); $bak=$env:MY_PERCENT; $env:MY_PERCENT = '%';if ($mypath.Length -gt 258) { $mypath = cmd /c \"for %A in (`\"$($mypath.Replace('%', '%MY_PERCENT%'))`\") do @echo %~sA\" };$env:MY_PERCENT = $bak;Start-Process -Verb Runas -Filepath wt -Argumentlist '-d', ('\"'+($mypath -replace '\\$','\\\\' -replace ';', '\;')+'\"'), cmd"</code>

この場合は<code>C:\</code>のための対処（<code>-replace '\\$','\\\\'</code>）が必要である。259文字のフォルダを無視するなら以下の通り。

<code>cmd /c "chcp 65001 & powershell -Command Start-Process -Verb Runas -Filepath wt -ArgumentList '-d', ('\"'+($input -replace '\\$','\\\\').Replace(';','\;')+'\"'), cmd"</code>


== 2.直接コマンド記入の右クリックメニュー ==

レジストリの<code>command</code>キーの既定の値に直接コマンドを記入する方式である。

デフォルトでは、右クリックメニューを押した時点でのフォルダ（フォルダを右クリックするメニューからだと対象フォルダの親、フォルダ背景を右クリックするメニューなら対象フォルダ）をカレントディレクトリとしてコマンドが起動される。そのため<code>\\?\</code>を付けなければならないような長大なパスのフォルダでは動作しない。しかし、<code>shell\xxxx</code>キーに<code>NoWorkingDirectory</code>値を設定することで、カレントディレクトリが必ず<code>C:\Windows\System32</code>に設定されるようになるので動くようになる。

対象のディレクトリはどう取得するかというと、レジストリに書き込んだ値のうち<code>%V</code>という部分が対象ディレクトリに書き換えられてコマンドが実行される。この<code>%V</code>もC:などの場合は<code>C:\</code>になる。コマンドの中でそのまま%という文字を使いたい場合はバッチファイルと同様に%%とエスケープする必要があるようである（これはどこにも書いてない？）。

しかし、こうして渡される（特殊文字を含むかもしれない）ディレクトリ名を完璧に取得するのは意外と難しい。cmdに解釈させると<code>%</code><code>VAR</code><code>%</code>が置換されてしまうし、シングルクォートとバッククォートが両方含まれているのでpowershellやshに渡すのも簡単ではない。

コツは、powershell -commandやsh -cの中に直接書くのではなく、スクリプトへのコマンドライン引数として渡した上で、スクリプト内で引数として取得することである。それぞれ、基本形（そのまま出力するだけ）は以下のようになる。

<ul>
<li>powershell
<code>powershell -Command "& {echo $args[1].Trim('\"')}" --%% "\"%V\""</code>
<ul>
<li><code>--%</code>というトークンを入れることでその後のパラメータの解析を行わないようにできる。args[0]は<code>--%</code>になるのでargs[1]を使う。レジストリに書く際は<code>%</code>をエスケープして<code>--%%</code>。</li>
<li><code>--</code>でも同様のことができる？<code>powershell -Command "& {echo $args[0].Trim('\"')}" -- "\"%V\""</code>（args[0]になっていることに注意）</li>
<li>というか、<code>--%</code>で書き進めてしまったが、本当は<code>--</code>のほうが安定するかもしれない。</li></ul>

あるいは<code>$MyInvocation.Line</code>を使う方法もある。この場合、powershellへの引数が全て（この例なら<code>-noexit -Command "& {$spl = ...</code>のところから）取得されるので、目当ての部分を取り出すためにここでは最後から2番目の<code>"</code>と最後の<code>"</code>の間を取得するという風にしている。
<code>powershell -noexit -Command "& {$spl = $MyInvocation.Line -split'\"' ; Set-Location -LiteralPath $spl[$spl.Length-2]}" --%% "\"%V\""</code>
昔のPowerShell（2くらい）で試してみたらこちらでないと<code>`</code>や<code>&</code>あたりの処理がうまくいかない場合があった。argsを使うものからの書き換えは容易である。</li>
<li>sh
<code>sh -c "IFS=;echo $*" -- "%V</code>
<ul>
<li>最後が<code>"%V</code>と閉じられていないのはミスではなく、<code>"%V"</code>としてしまうと<code>C:\</code>のときに<code>C:"</code>が渡されてしまうのでそれを避けるためである（これはかなりトリッキーなのでもう少し真面目にやってもいいかなとは思う）。</li>
<li>UNCパスの最初の<code>\\</code>が<code>\</code>に変わってしまう（手元では、Cygwinの場合は<code>\\?\</code>のみで発生している？）という問題があり、適宜置換する必要がある。</li></ul>
</li></ul>

これらの書き方はいわゆる「ワンライナー」的なものであるが、もちろん外部にスクリプトファイルを用意してもよい。

また、外部にスクリプトを用意してよいという条件であれば、vbsも使用可能である。

<ul>
<li>この場合、まずレジストリには
<code>wscript "C:\path\to\script.vbs" "%V"</code>
などと書く。スクリプトの内容は上記のレジストリの内容をほぼそのままWscript.ShellでRunすればよいが、<code>%V</code>のかわりにWscript.Arguments(0)を挿入するのと、<code>%</code>を<code>%%</code>にエスケープしなくてよいのと、VBSなので文字列内の<code>"</code>は<code>""</code>に変えなければならない。これに加え、Runの引数に含まれる<code>%</code><code>VAR</code><code>%</code>が置換の対象となるため、対象フォルダの文字列については<code>==%</code>への置換でエスケープして、呼び出し先のpowershellなどで元に戻す。</li>
<li>必要に応じてRunのオプションでvbHideを指定する。</li>
<li>というか別に258文字を超えていたら云々みたいな処理も全部vbs側でやってしまってもよい（面倒なのでそういう例は載せていない）</li></ul>

バッチファイルに渡すのは、バッチファイルをcmdが呼び出す時点で<code>%PATH%</code>のようなファイル名の環境変数は既に展開されてしまうので、どうやっても不可能。

他には、（hiderunと）piperunとpechoを併用するという方法もあり、それらの実行ファイルを用意する必要があるという以外は綺麗にできる方法である。

いずれにしろ、一旦取得できてしまえばあとは前述の<code>openterm</code>に流し込むだけでよい。ただ、実際にはわざわざ<code>openterm</code>に流し込まなくても（パイプを使わなくても）もっと簡単に起動できることもあるのでそちらを中心に紹介する。

* commandの最初で指定する（メインの）実行ファイル（先ほどなら<code>powershell</code>や<code>sh</code>）をファイル名単体で書く場合は、それが（メニューをHKCUで設定するならHKCUの（最近のWindowsならHKLMのでも可？）、HKLMで設定するならHKLMの）App Pathsキーに登録されていなければならない（PATHは通っていなくてもいい）。登録されていない場合はフルパスで指定する必要がある。

=== 設定例 ===

==== 管理者権限なし ====

<ul>
<li>PowerShell
デフォルトターミナルで
<code>powershell -noexit -Command "& {Set-Location -LiteralPath $args[1].Trim('\"')}" --%% "\"%V\""</code>
<ul>
<li>参考までに、Windowsにもともと入っているメニューでは以下のようになっている。
<code>powershell.exe -noexit -command Set-Location -literalPath '%V'</code>
これだとシングルクォートと連続スペースに対応できない。連続スペースだけなら<code>'%V'</code>を<code>"'%V'"</code>に変えると解決できる。<code>%$[]`</code>あたりは見た感じ問題なし。
<ul>
<li>以下の解決策でもまだ不完全 [https://superuser.com/questions/1310258/open-powershell-window-here-file-explorer-context-menu-command-breaks-with-fol "Open PowerShell window here" File Explorer context-menu command breaks with folder names with apostrophes (single quotes) - Super User]</li></ul>
</li>
<li>この問題は[https://github.com/PowerShell/PowerShell/issues/6598 https://github.com/PowerShell/PowerShell/issues/6598]や[https://github.com/PowerShell/PowerShell/pull/6660 https://github.com/PowerShell/PowerShell/pull/6660] で扱われており、結局pwshでは-WorkingDirectoryというパラメータが追加された。[https://github.com/PowerShell/PowerShell/issues/14091 https://github.com/PowerShell/PowerShell/issues/14091]にある以下の文字列をレジストリに書いたところ、正しく動作したので、pwshではこれでよい。
<code>pwsh.exe -NoExit -RemoveWorkingDirectoryTrailingCharacter -WorkingDirectory "%V!" -Command "$host.UI.RawUI.WindowTitle = 'PowerShell 7 (x64)'"</code></li></ul>

wtで
<code>hiderun powershell -Command "& {wt powershell -noexit -Command Set-Location -LiteralPath ('\"'''+($args[1] -replace '''', '''''' -replace '%%', '==%%' -replace ';', '\;' )+'''.Replace(''==%%'',''%%'')\"')}" --%% "\"%V\""</code></li>
<li>cmd
wtで。標準入力のときとほぼ同じ。
<code>powershell -Command "& {$bak=$env:MY_PERCENT;$mypath=$args[1].Trim('\"'); $env:MY_PERCENT = '%%';if ($mypath.Length -gt 258) { $mypath = cmd /c \"for %%A in (`\"$($mypath.Replace('%%', '%%MY_PERCENT%%'))`\") do @echo %%~sA\" };$env:MY_PERCENT = $bak;wt -d ($mypath -replace ';', '\;') cmd}" --%% "\"%V\""</code>
<ul>
<li>デフォルトターミナルで
startatdir.vbsを使う。
<code>powershell -Command "& {$bak=$env:MY_PERCENT;$mypath=$args[1].Trim('\"'); $env:MY_PERCENT = '%%';if ($mypath.Length -gt 258) { $mypath = cmd /c \"for %%A in (`\"$($mypath.Replace('%%', '%%MY_PERCENT%%'))`\") do @echo %%~sA\" };$env:MY_PERCENT = $bak; wscript 'C:\path\to\startatdir.vbs' cmd ('\"'+$mypath+'\"')}" --%% "\"%V\""</code></li>
<li>Windowsにもともと入っているメニューでは以下。
<code>cmd.exe /s /k pushd "%V"</code>
これは（<code>\\?\</code>が付くパスを除いて）ほとんどの場合に正しく機能するが、<code>%PATH%</code>のような文字列が含まれているフォルダではうまくいかない。ちなみにpushdによりUNCパスには自動的にネットワークドライブが割り当てられる。</li></ul>
</li>
<li>Git Bash
<ul>
<li>mintty（git-bash.exe使用）
<code>"C:\Program Files\Git\git-bash.exe" -c "IFS=;cd $(echo $*|/bin/sed 's/\\\\/\\\\\\\\/'|/bin/cygpath -f -);exec bash" -- "%V</code>
<ul>
<li>ちなみに、Git Bashのインストーラにより設定される「Git Bash Here」メニューでは以下のようになっている。
<code>"C:\Program Files\Git\git-bash.exe" "--cd=%v."</code>
これは、特殊文字にはすべて対応しているが、（NoWorkingDirectoryをつけたとしても）<code>\\?\</code>で始まるパスではうまくいかない。最後の「.」はよくわからないがこれを付けておくと<code>--cd</code>がうまくやってくれるっぽい。</li></ul>
</li>
<li>デフォルトシェルで
<code>"C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=;cd $(echo $*|/bin/sed 's/\\\\/\\\\\\\\/'|/bin/cygpath -f -);export MSYSTEM=MINGW64;exec /bin/bash --login" -- "%V</code></li>
<li>wtで
<code>hiderun "C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=;LANG=en_US.UTF8; echo $*|/bin/sed 's/\\\\/\\\\\\\\/'|/bin/cygpath -f -|printf %%q $(/bin/sed 's/%%/=%%/g')|/bin/sed 's/;/\\\\;/g'|/bin/xargs -d '\n' -I {} -- wt \"C:\Program Files\Git\usr\bin\env.exe\" MSYSTEM=MINGW64 \"C:\Program Files\Git\usr\bin\bash.exe\" --login -i -c 'IFS=\\;cd $(echo {}|sed s/=%%/%%/g)\\;exec bash'" -- "%V</code></li></ul>
</li>
<li>Cygwin
<ul>
<li>デフォルトシェルで
<code>"C:\cygwin64\bin\sh.exe" --login -c "IFS=;cd $(echo $*|/bin/sed 's/\\\\?/\\\\\\\\?/'|/bin/cygpath -f -);exec bash" -- "%V</code>
<ul>
<li>置換の対象を<code>\\?\</code>のみとするためsedの引数に<code>?</code>が増えている</li></ul>
</li>
<li>wtで
<code>hiderun "C:\cygwin64\bin\sh.exe" -c "IFS=;echo $*|/bin/sed 's/\\\\?/\\\\\\\\?/'|/bin/cygpath -f -|printf %%q $(/bin/sed 's/%%/=%%/g')|/bin/sed 's/;/\\\\;/g'|/bin/xargs -d '\n' -I {} -- wt \"C:\cygwin64\bin\bash.exe\" --login -i -c 'IFS=\\;cd $(echo {}|sed s/=%%/%%/g)\\;exec bash'" -- "%V</code></li></ul>
</li></ul>

==== 管理者権限 ====

<ul>
<li>PowerShell
<code>powershell -Command "& {Start-Process -Verb Runas -Filepath wt -Argumentlist powershell, -noexit, -command, Set-Location, -LiteralPath, ('\"'''+($args[1].Trim('\"') -replace '''', '''''' -replace ';', '\;' -replace '%%', '==%%')+'''.Replace(''==%%'',''%%'')\"')}" --%% "\"%V\""</code>
環境変数の置換を抑止する必要がある。デフォルトシェルで起動するならこれは不要（で、wtでないので<code>;</code>のエスケープも不要）で、以下のようになる。
<code>powershell -Command "& {Start-Process -Verb Runas -Filepath powershell -Argumentlist '-noexit', '-command', Set-Location, '-LiteralPath', ('\"'''+($args[1].Trim('\"') -replace '''', '''''' )+'''\"')}" --%% "\"%V\""</code>
<ul>
<li>MyInvocationを使う例
<code>powershell -Command "& {$spl = $MyInvocation.Line -split'\"'; Start-Process -Verb Runas -Filepath powershell -Argumentlist '-noexit', '-command', Set-Location, '-LiteralPath', ('\"'''+($spl[$spl.Length-2] -replace '''', '''''' )+'''\"')}" --%% "\"%V\""</code></li>
<li>vbsの例
次の節で解説する「（自分が起動された）カレントディレクトリでの起動」にも対応している（引数がない場合）。
<syntaxhighlight lang="vb.net">Dim objShell
Dim curDir

Set ws = CreateObject("Wscript.Shell")
Dim dir
If WScript.Arguments.Count = 0 Then
dir = ws.CurrentDirectory
Else
dir = Wscript.Arguments(0)
End If
dir = Replace(dir,"%","==%")
ws.run "powershell -Command ""& {Start-Process -Verb Runas -Filepath wt -Argumentlist powershell, -noexit, -command, Set-Location, -LiteralPath, ('\""'''+($args[1].Trim('\""') -replace '''', '''''' -replace ';', '\;' )+'''.Replace(''==%'',''%'')\""')}"" --% ""\"""&dir&"\""""", vbHide

Set objShell = Nothing</syntaxhighlight></li></ul>
</li>
<li>cmd
<code>powershell -Command "& {$bak=$env:MY_PERCENT;$mypath=$args[1].Trim('\"'); $env:MY_PERCENT = '%%';if ($mypath.Length -gt 258) { $mypath = cmd /c \"for %%A in (`\"$($mypath.Replace('%%', '%%MY_PERCENT%%'))`\") do @echo %%~sA\" };$env:MY_PERCENT = $bak;Start-Process -Verb Runas -Filepath wt -Argumentlist '-d', ('\"'+($mypath -replace '\\$','\\\\' -replace ';', '\;')+'\"'), cmd}" --%% "\"%V\""</code>
この場合も<code>C:\</code>のための対処（<code>-replace '\\$','\\\\'</code>）が必要である。デフォルトシェルなら、startatdir.vbsを使う。
<code>powershell -Command "& {$bak=$env:MY_PERCENT;$mypath=$args[1].Trim('\"'); $env:MY_PERCENT = '%%';if ($mypath.Length -gt 258) { $mypath = cmd /c \"for %%A in (`\"$($mypath.Replace('%%', '%%MY_PERCENT%%'))`\") do @echo %%~sA\" };$env:MY_PERCENT = $bak;Start-Process -Verb Runas -Filepath wscript -Argumentlist '//Nologo', 'C:\path\to\startatdir.vbs', 'cmd', ('\"'+$mypath+'\"')}" --%% "\"%V\""</code></li>
<li>Git Bash
理論上はワンライナーでも書けるが、エスケープが面倒すぎるのでファイルに書いたほうがよいだろう。まずレジストリの中身は以下のようにする。
<code>"C:\Program Files\Git\usr\bin\sh.exe" "C:\path\to\gb-wt-admin.sh" "%V"</code>
で、<code>gb-wt-admin.sh</code>の中身は以下。
<syntaxhighlight lang="bash">#!/bin/sh
IFS=
LANG=en_US.UTF-8
echo $*|/bin/sed 's/\\/\\\\/'|/bin/cygpath -f -|printf %q $(/bin/cat) |/bin/sed "s/'/''/g;s/%/==%/g;s/;/\\\\;/g"|/bin/xargs -d '\n' -I {} powershell -Command Start-Process -Filepath wt -ArgumentList "'"'"C:\Program Files\Git\usr\bin\env.exe"'"'" , '"MSYSTEM=MINGW64"' , "'"'"C:\Program Files\Git\usr\bin\sh.exe"'"'" , "'--login'", "'-c'", "'"'"IFS=\;cd $(echo {}| /bin/sed s/==%/%/g) \; exec bash"'"'"</syntaxhighlight>
Cygwinも同様である。</li></ul>


==== VS Codeのメニュー（おまけ） ====

「Code で開く」メニューのcommand値は以下のように設定されている。

<code>"C:\Program Files\Microsoft VS Code\Code.exe" "%V"</code>

これは特殊文字などに関しても問題なく動作するうえ、実はそのまま<code>\\?\</code>が付いたパスにも適用可能である。従って、<code>VSCode</code>キーに<code>NoWorkingDirectory</code>値を設定する（設定の書き換えまたはHKCUによるオーバーライド）だけで、長大フォルダでもVS Codeが使えるようになる。ターミナルの起動には失敗してしまうがファイル・フォルダの作成・編集などの基本操作がGUIでできるので意外と便利（もちろん、他のBetter Explorer的なツールを使う手もあるだろう）。


== 3. エクスプローラーのアドレスバーから ==

このときは、末尾が空白のパスや<code>\\?\</code>が必要な長大パスやちょうど259文字のフォルダはそもそも対応していないので考えなくてよい。しかし通常のネットワークファイル向けのUNCパス（<code>\\192.168.1.1\disk</code>など）に対応する必要はあるので、cmdをベースにすることはできない（cmdの中に入った時点でカレントディレクトリが変わってしまう）。また<code>``</code>が含まれるパスをカレントディレクトリにできないことから、powershell.exeもベースとしては使えない。

なので、パイプを使って先ほどの<code>openterm</code>にむけて流し込もうと思ったら選択肢はpwsh.exeかpiperunかCygwin系だけである。それぞれの書き方は以下のようになる。

<ul>
<li>pwsh
<code>pwsh -Command $pwd.Path.Replace('Microsoft.PowerShell.Core\FileSystem::\\', '\\') | openterm</code></li>
<li>piperun
<code>piperun pwsh -Command $pwd.Path.Replace('Microsoft.PowerShell.Core\FileSystem::\\', '\\') | openterm</code>
上とほぼ変わっていないが、pwshはディレクトリの取得だけで使っているので<code>openterm</code>のところで環境変数が汚染されるのを防げる。</li>
<li>Cygwin/Git Bash
<code>"C:\Program Files\Git\usr\bin\sh.exe" -c "cmd //c \"chcp 65001 > nul\"| pwd | /bin/cygpath -w -f - | openterm"</code>
<ul>
<li>一つ問題があり、hiderunを使う（コンソールを非表示にする）とchcpが効かないようで、<code>openterm</code>でPowerShellの<code>$input</code>を使っているとUnicode文字が化けてしまう。</li>
<li>先ほどの<code>openterm</code>部分で先頭にcygpathが入っているものを使うときは、そちらのcygpathとこちらでのcygpath -wは打ち消し合って無駄なので消してよい。</li></ul>
</li></ul>

このほかにvbs(wscript)もカレントディレクトリの取得のところは問題なくやってくれるので、それをさっきのWscript.Arguments(0)のかわりに使えばよい。

最初に表示されるコンソールを非表示にしたければ、<code>hiderun</code>を付けてrunother経由で実行するのが手軽だが、前述の通りvbsも拡張子無しで呼び出せるように設定できるので、そうした上でvbHideで隠してもよい。


=== 管理者権限なし ===


==== cmd ====

これは普通にcmdと打てばよい。

（デフォルトシェルがconhostだとして）wtで開きたいときは、;をエスケープして-dで渡す。以下の通りbatファイルを作ってpathを通す。

<code>chcp 65001 & cd | powershell -Command wt -d $input.Replace(';','\;') cmd</code>

wtではなくconhostの場合はconhost cmdだけでよい。batにするなら<code>start "" conhost cmd</code>でよい。

コンソール非表示ならcmd /cをつけてhiderunする。runotherで、txtの中身は以下の通り。

<code>hiderun cmd /c chcp 65001 & cd | powershell -Command wt -d $input.Replace(';','\;') cmd</code>


==== powershell, pwsh ====

pwshはそのままpwshと打てばよい。powershell及びwtやconhostを明示的に指定する場合について以下で述べる。

たとえばwtでpwshなら、runotherを使って、txtの内容は以下。

<code>hiderun pwsh -Command wt -d $pwd.Path.Replace('Microsoft.PowerShell.Core\FileSystem::\\', '\\').Replace(';', '\;') pwsh</code>

powershellの場合は<code>``</code>に対応するため起動後に移動する。runotherでpiperunを使って、txtは以下。最終的に起動する方のpowershellで<code>==%</code>を<code>%</code>に戻している。

<code>hiderun piperunex cmd /c chcp 65001 | printcd | powershell -Command wt powershell -noexit -command Set-Location -LiteralPath ('"'''+($input -replace ';', '\;' -replace '''', '''''' -replace '%', '==%')+'''.Replace(''==%'',''%'')"')</code>

pwshが使えるならprintcdのかわりに<code>pwsh -Command $pwd.Path.Replace('Microsoft.PowerShell.Core\FileSystem::\\', '\\')</code>でもよい。

以下はpiperunを使わずshでやる例。前述の通りパイプからPowerShell側で<code>$input</code>を使って受け取ると文字化けするので引数として渡す。

<code>hiderun "C:\Program Files\Git\usr\bin\sh.exe" -c "WD=$(pwd | /bin/cygpath -w -f - | /bin/sed \"s/;/\\\\\\\\;/g; s/'/''/g; s/%/==%/g\"); wt powershell -noexit -command Set-Location -LiteralPath $\"'$WD'.Replace('==%','%')\"$"</code>


==== Git Bash/Cygwin ====

Git Bashは<code>--login</code>をつけてもカレントディレクトリを維持するので単純である。以下をrunotherのtxtに書く。

<code>"C:\Program Files\Git\usr\bin\env.exe" MSYSTEM=MINGW64 /bin/bash --login</code>

Cygwinは起動後にcdする。そのかわり<code>export MSYSTEM=MINGW64</code>が不要。

<code>"C:\cygwin64\bin\sh.exe" -c "IFS=;/bin/bash --login -i -c 'cd '$(/bin/printf %q `pwd`)'; exec bash'"</code>

printfで一旦エスケープしたものをcdの後につなげてそのまま渡している。

<ul>
<li>wtで
<ul>
<li>Git Bash
<code>wt "C:\Program Files\Git\usr\bin\env.exe" MSYSTEM=MINGW64 "C:\Program Files\Git\usr\bin\bash.exe" --login"</code>
<ul>
<li>あれ、wtなのにカレントディレクトリ維持されてる…？wt cmdではダメなのだが…</li></ul>
</li>
<li>Cygwin
<code>hiderun "C:\cygwin64\bin\sh.exe" -c "IFS=;WD=$(printf %q `pwd` | /bin/sed \"s/;/\\\\\\\\;/g; s/%/==%/g\"); wt \"C:\cygwin64\bin\bash.exe\" --login -c 'IFS=\\;cd $(echo '$WD'|sed s/==%/%/g)\\; exec bash'"</code></li></ul>
</li></ul>

=== 管理者権限あり ===


==== cmd ====

runotherを使って以下の通り。

<code>hiderun cmd /c "chcp 65001 > nul & cd | powershell -Command Start-Process -Verb Runas -Filepath wt -ArgumentList '-d', ('\"'+$input.TrimEnd('\\').Replace(';','\;')+'\"'), cmd"</code>

<code>TrimEnd('\\')</code>のところは<code>C:\</code>の末尾のバックスラッシュへの対応である（<code>wt -d "C:"</code>は通らないので一見ダメそうだが、なぜかこれで動く。原因不明。）。

batならそのまま以下の通り（黒い画面が一瞬出てしまう）。

<code>chcp 65001 & cd | powershell -Command Start-Process -Verb Runas -Filepath wt -ArgumentList '-d', ('\"'+$input.TrimEnd('\\').Replace(';','\;')+'\"'), cmd</code>

別解としてパイプを使わないものも載せておこう。cmdでは特殊文字ではないので<code>'</code>を<code>''</code>に変えるのは簡単である。

<code>hiderun cmd /c powershell -Command "& {Start-Process -Filepath wt -Verb Runas -ArgumentList '-d', ('\"'+$args[0].TrimEnd('\\').Replace(';','\;')+'\"'), cmd}" -- "'%CD:'=''%'"</code>

以下もうまくいく。cmdの<code>"</code>に関する仕様により、例えばStart-Processの直前に<code>echo '\"';</code>のような<code>"</code>を奇数個含む文字列を入れると動かなくなる。argsを使うとバッククォートがうまくいかなかったのでMyInvocationを使ってみる。

<code>hiderun cmd /c powershell -Command "& {$spl=$MyInvocation.Line.Split('\"'); Start-Process -Filepath wt -Verb Runas -ArgumentList '-d', ('\"'+$spl[$spl.Length-2].TrimEnd('\\').Replace(';','\;')+'\"'), cmd}" -- "\"%CD%\""</code>


==== powershell, pwsh ====

UNC非対応でよく、かつ（<code>``</code>をカレントディレクトリとして起動できる）pwshでよければ、上記のcmdをpwshに変えればよい。powershellならSet-Locationで移動が必要。以下をrunotherのtxtに書く。

<code>hiderun cmd /c "chcp 65001 & cd | powershell -Command Start-Process -Verb Runas -Filepath wt -ArgumentList 'powershell', '-noexit', '-command', 'Set-Location', '-LiteralPath', ('\"'''+($input -replace '''', '''''' -replace '%', '==%' -replace ';', '\;' )+'''.Replace(''==%'',''%'')\"')"</code>

UNC対応なら、管理者でないときと同じで、PSReadLineのエラーを回避するためpwshを一貫して使うのがいいだろう。

<code>hiderun pwsh -Command Start-Process -Verb Runas -Filepath wt -ArgumentList '-d', ('\"'+$pwd.Path.Replace('Microsoft.PowerShell.Core\FileSystem::\\', '\\').TrimEnd('\\').Replace(';','\;')+'\"'), pwsh</code>

powershellならpiperunを使う。カレントディレクトリの取得にpwshを使っているがprintcdでもよい。

<code>hiderun piperunex cmd /c chcp 65001 | printcd | powershell -Command Start-Process -Verb Runas -FilePath wt -ArgumentList powershell, -noexit, -command, Set-Location, -LiteralPath, ('\"'''+($input -replace ';', '\;' -replace '''', '''''' -replace '%', '==%')+'''.Replace(''==%'',''%'')\"')</code>

shなら以下。

<code>hiderun "C:\Program Files\Git\usr\bin\sh.exe" -c "WD=$( pwd | /bin/cygpath -w -f - | /bin/sed \"s/;/\\\\\\\\;/g; s/'/''''/g; s/%/==%/g\"); powershell -Command Start-Process -Verb Runas -Filepath wt -Argumentlist powershell, -noexit, -command, Set-Location, -LiteralPath, $\"'\\\"''$WD''.Replace(''==%'',''%'')\\\"'\"$"</code>


==== Git Bash ====

runotherとpiperunで以下。

<code>hiderun piperunex "C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=; LANG=en_US.UTF8; pwd || printf %q $(/bin/cat)" | "C:\Program Files\Git\usr\bin\sed.exe" "s/'/''/g;s/%/==%/g;s/;/\\\\;/g" | "C:\Program Files\Git\usr\bin\xargs.exe" -d '\n' -I {} -- powershell -Command Start-Process -Verb Runas -Filepath wt -ArgumentList '"C:\Program Files\Git\usr\bin\sh.exe"','-c', "'"'"IFS=\\; export MSYSTEM=MINGW64\\;cd $(echo {}|| /bin/sed s/==%/%/g)\\; exec /bin/bash --login"'"'"</code>

* <code>MSYSTEM=MINGW64</code>をもっと手前で設定して、<code>-ArgumentList</code>で<code>--login</code>を指定して、最後を<code>exec bash</code>にしてもよい。

piperunを使わずにshで頑張ることもできるが、エスケープが多く読みづらくなる。

<code>hiderun "C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=; LANG=en_US.UTF8; pwd | printf %q $(/bin/cat) | /bin/sed \"s/'/''/g;s/%/==%/g;s/;/\\\\\\\\;/g\" | /bin/xargs -d '\n' -I {} -- powershell -Command Start-Process -Verb Runas -Filepath wt -ArgumentList '\"C:\Program Files\Git\usr\bin\sh.exe\"','-c', \"'\"'\"IFS=\\; export MSYSTEM=MINGW64\\;cd $(echo {}| /bin/sed s/==%/%/g)\\; exec /bin/bash --login\"'\"'\" "</code>

Cygwinも同様。

== 関連 ==

[https://qiita.com/octopath9/items/4b7fe797ae1155c69dd9 コマンドプロンプトから管理者権限のコマンドプロンプトに切り替える - Qiita]

[https://qiita.com/tmiki/items/0dab4fd17e9bed04ed91 【Windows】GitBashをcontext menuからAdministrator権限付きで実行する - Qiita]

[https://note.com/redpeak/n/n5ddc3673117b エクスプローラーから管理者権限でコマンドプロンプトを開く方法｜ひるあんどん]
[[Category:IT]][[Category:Windows]]{{#seo:|title={{FULLPAGENAME}} - Turgenev's Wiki}}

定理証明支援系Lean

2025-06-30T09:02:37Z

Turgenev: Notion-MW

Leanは、比較的新しい定理証明支援系（Lean以外にはCoqやIsabelleなどがある）である。

== 概要 ==

学術研究用なのもあって特にメジャーバージョンアップでは大きな破壊的変化がある。

Lean2以前はよく調べていないがLean2にはHoTTサポートがあって3で無くなったらしい。3→4ではマクロシステムが刷新されたり、Leanの処理系のうちLean自体で書かれた部分がさらに増えたり？した。


=== Lean3 ===

[https://leanprover.github.io/ 公式]（githubでの名前はleanprover）と、[https://leanprover-community.github.io/ 半分公式みたいなコミュニティ]（githubでの名前はleanprover-community）があって、公式では3.4.2まででアーカイブされているLean3もコミュニティversionでは3.47.0くらいになっている。また様々な分野の証明を集めたライブラリの[https://github.com/leanprover-community/mathlib mathlib]もコミュニティの成果物である。

もうほとんど使われていないだろう。


=== Lean4 ===

Lean4は現在のところ「公式」のみで扱われている。手元では、WindowsとMacではしばらく動かなかったが、2022年9月中旬頃にelanが1.4.2になったタイミングで動くようになった。しかしVSCode拡張は大文字/小文字の区別をうまく扱えずGo to definitionが失敗する（大文字/小文字の区別があるファイルシステムではおそらく問題なし？？）。既知のバグ。やなど。

VSCodeでの体感でもチェッカがLean3より明らかに速くなった。

== 学習用リソース ==


==== Lean3 ====

[https://leanprover-community.github.io/learn.html https://leanprover-community.github.io/learn.html]にリストされている。

最も基本的な使い方の解説が[https://leanprover.github.io/theorem_proving_in_lean/ Theorem Proving in Lean]であり、Leanを使って定理証明をする方法の概略が掲載されている。とりあえずはこれを読んでいけばいい。比較的よくまとまった資料であるが、Curry-Howard同型についてなど、型理論や証明論の事前知識が多少はないと読むのはやや大変かもしれない。そのあたりの知識から解説しているものもいちおう上記の一覧にある。

各tacticの動作など、辞書的な説明は[https://leanprover.github.io/reference/ reference manual]に載っている場合もあるが、こちらは未完成である。

Programming in leanというのもあるが、これも少なくとも最近はあまりメンテナンスされていない。

<div style="overflow:auto;width: 100%; max-width: 1200px; white-space:nowrap; border:1px solid; padding-left: 10px; padding-right: 10px;" class="mw-collapsible">
<div>Programming in leanに関する詳細</div>
<div class="mw-collapsible-content">

これまた未完成ではあるが[https://avigad.github.io/programming_in_lean/index.html Programming in Lean — Programming in Lean 3.4.2 documentation]を見ると説明が載っているかもしれない。programming in leanで検索すると、

[https://leanprover.github.io/programming_in_lean/programming_in_lean.pdf https://leanprover.github.io/programming_in_lean/programming_in_lean.pdf]

[https://leanprover.github.io/programming_in_lean/ https://leanprover.github.io/programming_in_lean/]

（この2つは同じ内容）

も出てくるが、こちらはリポジトリ([https://github.com/avigad/programming_in_lean avigad/programming_in_lean])と比較すると古いバージョンのようである（リポジトリの”old”フォルダの内容に対応している）。

</div></div>


==== Lean4 ====

前述の各資料に対応して[https://leanprover.github.io/theorem_proving_in_lean4/title_page.html https://leanprover.github.io/theorem_proving_in_lean4/title_page.html]と[https://leanprover.github.io/lean4/doc/ https://leanprover.github.io/lean4/doc/]と[https://leanprover.github.io/functional_programming_in_lean/ Functional Programming in Lean]がある。


== Publications ==

関連論文など

[https://leanprover.github.io/publications/ https://leanprover.github.io/publications/]

== 日本語情報 ==

[https://turgenev.hatenablog.com/entry/2020/11/25/095208 定理証明支援系Leanのインストールと初期設定（Linux）]（自分で書いたが、古いのでもう読まなくていい）

[https://manau.jp/lean/leaninstall/ 定理証明支援系 LEAN のインストール]

[http://myuon-myon.hatenablog.com/entry/2016/01/09/212750 Theorem Prover Leanの紹介 - Just $ A sandbox]

[https://myuon.github.io/posts/start-learning-proof-assistant/ 定理証明リンク集]

くらい。あんまりないが、順調にいけば今後増えていきそうではある。

* 2025/6追記最近はもっと増えてそう

== metaprogramming関連 ==

Leanの証明記述用言語（tactic）は、Leanそれ自体の上で実装されている。バージョン3→4によってさらにその傾向が強まりそうである。

tacticはmonadicな関数として実装されている。tacticをmonadで表現するというのはCoq用のMtac[^ziliani2013Mtac]などでも採用された手法である。


=== Lean3での例 ===

筆者は研究活動の一環として、Lean 3のソースコード上に構造的に関連付けられた形でコメントを書けるようにするライブラリであるNtac（[https://github.com/ge9/ntac https://github.com/ge9/ntac]）を公開している。これはLean 3のmetaprogrammingを活かした例である。

metaprogrammingについてはコミュニティのLearning resourcesの”Metaprogramming and tactic writing”の項目や[https://leanprover.github.io/papers/tactic.pdf https://leanprover.github.io/papers/tactic.pdf]を参考にした。また、独自のtacticシステムを作成するためのガイドとして、[https://leanprover-community.github.io/archive/stream/113488-general/topic/no.20lean.20messages.20output.20in.20hacked.20mode.html https://leanprover-community.github.io/archive/stream/113488-general/topic/no.20lean.20messages.20output.20in.20hacked.20mode.html]に実装上のヒントを得た。

* 基本的には、<code>tactic</code>という名前でStateモナドが定義されていて、各tacticはこのモナド値を返す関数として定義されている。しかし<code>tactic</code>は現在の状態しか持っておらず、コメントを紐づけたりするには証明の過程まで含めた全体の構造が欲しい。そこでntacでは、<code>tactic</code>の定義を変更して証明の「履歴」を木構造として保持するようにした<code>ntac</code>というモナドを定義し、既存のtacticを（適切な）<code>ntac</code>モナド値を持つような定義に変更した。


=== Lean4 ===

Schemeを参考に、強力な衛生的（hygienic）マクロシステムが実装された。柔軟なNotationの定義ができるようになる。論文としては[^ullrich2020Notations]に詳しく書いてある。

上記「ntac」のLean4版は現在開発中。構文解析中に外部のプログラムを呼び出すなど、なんでもできて面白い。

==== 例 ====

* replしてる例らしい [https://github.com/leanprover-community/repl https://github.com/leanprover-community/repl]

==== tacticの移行とか ====

Lean3までの証明（のうちtacticで書かれたもの）をLean4に移植する方法について。 
[https://leanprover.zulipchat.com/#narrow/stream/287929-mathlib4/topic/Tactic.20porting.20assignments/near/296694161 https://leanprover.zulipchat.com/#narrow/stream/287929-mathlib4/topic/Tactic.20porting.20assignments/near/296694161]

* とりあえず [[error_private_page|error_private_page]] で基礎知識を得るのがよさそう？

== elan ==

* leanを管理（各バージョンのインストール/アンインストールなど）するためのツール
* 適当にフォルダだけ消すとtoolchainの再インストールで引っ掛かるので、update-hashesも消すとよいかも
* rustupのforkらしい [https://zenn.dev/labbase/articles/b24dca38e0420d 関数型言語”兼”定理証明支援系Leanの環境構築]


== Lean3 ==

[https://leanprover-community.github.io/get_started.html https://leanprover-community.github.io/get_started.html] を読む。elanってやつが入れば大丈夫で、mathlib-toolsとかleanprojectは（今はもう案内ないか？）無視でいい（後述）

=== パッケージ ===

Leanでの開発はまずパッケージを作るところから始まる。

leanpkg.tomlっていうメインの管理ファイルがあって、ここにLeanのバージョンとかを指定しておくと、無ければ（VS Codeでフォルダ開くタイミングとかで）自動でelanが取ってきてくれる

* 特定パッケージと、そのパッケージに依存するパッケージの双方を依存関係として指定したとして、バージョンの齟齬があったら何が起きるのかは不明である。ちなみにLean4の話だが、mathlib4に関しては[https://github.com/leanprover-community/mathlib4 https://github.com/leanprover-community/mathlib4]に「If your project depends on <code>std4</code> or <code>quote4</code>, let <code>mathlib4</code> pull them transitively. That is, don't <code>require</code> them on your <code>lakefile.lean</code>」と明記されている。

=== mathlib ===

パッケージの一つ。半分標準のライブラリみたいなもの。数学の定理やリスト処理のプログラムなど、色々なものが形式化されている。文字列処理とかの便利関数も入ってるのでとりあえず入れて損はない

[https://leanprover-community.github.io/mathlib-overview.html https://leanprover-community.github.io/mathlib-overview.html]

=== mathlibの指定 ===

leanpkg.tomlで

<syntaxhighlight lang="javascript">mathlib = {git = "https://github.com/leanprover-community/mathlib", rev = "lean-3.49.1"}</syntaxhighlight>
のように指定しておくと

<syntaxhighlight lang="javascript">leanpkg upgrade</syntaxhighlight>
でlean-3.49.1ブランチを取ってきてくれる。masterブランチ指定とかするとバージョンアップで互換性がなくなって困るのでこれがおすすめ。

=== mathlib-toolsとleanprojectについて ===

* 基本Lean3用なのでもう使われないかも

leanprojectは[https://github.com/leanprover-community/mathlib-tools mathlib-tools]の一部で、mathlibをうまく扱うのが目的っぽい。<code>python3 -m pip install mathlibtools</code>で入る

prebuiltされた（ちなみに自前でビルドすると数時間かかる）mathlibを

<syntaxhighlight lang="javascript">https://oleanstorage.azureedge.net/mathlib/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.tar.xz</syntaxhighlight>
（xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxはコミットID）からダウンロードして、oleanにtouchして最新版にしてくれるが、それだけの機能しかなく、動作もあまり分かりやすくない。しかもよくわからんが、Lean4には未対応っぽい（というか、mathlibというのはLean3のパッケージの名前なのでそれはそうか（Lean4用のmathlibはmathlib4））。このまま使われなくなりそう。

そこで、自分でそれをやるスクリプトを書いてpathに登録した。これで十分と感じる。

<syntaxhighlight style="margin-bottom:0.2em;" lang="javascript">#!/bin/sh
if ! cd ../../../_target/deps/mathlib ;then
echo "must be run in 'mathlib' folders. exiting."; exit
fi
find src -name "*.olean" | xargs rm
curl -o olean.tar.xz https://oleanstorage.azureedge.net/mathlib/`cat .git/HEAD`.tar.xz
#touch all .olean (this is also done by leanproject in mathlib-tools)
find src -name "*.olean" | xargs touch
if tar xvf olean.tar.xz ; then
rm -f olean.tar.xz
fi</syntaxhighlight>
<div style='text-align: center;'>new-oleans.sh</div>


== Lean4 ==

=== 初期設定 ===

[https://github.com/leanprover/elan elan]をまず入れてそれからLeanを、ってのがv3以前のやり方だったと思うが[https://leanprover.github.io/lean4/doc/quickstart.html Setting Up Lean - Lean Manual]によるとどうやらv4はVS Code拡張経由で入れられるようである。


=== パッケージ(lake) ===

<code>lake new フォルダ名（この中にパッケージができる）</code>、または<code>lake init パッケージ名（パッケージはカレントディレクトリに作成される）</code>を実行。詳しいやり方は[https://github.com/leanprover-community/mathlib4 https://github.com/leanprover-community/mathlib4] とか。

lakeのドキュメントはここ [https://github.com/leanprover/lean4/tree/master/src/lake https://github.com/leanprover/lean4/tree/master/src/lake]

dependencyの書き方は [https://github.com/leanprover-community/mathlib4/blob/master/lakefile.lean https://github.com/leanprover-community/mathlib4/blob/master/lakefile.lean] とかを参考に。stdのURLがここにある。

=== mathlib4 ===

prebuiltされたものの提供はないっぽい。[https://leanprover.zulipchat.com/#narrow/stream/287929-mathlib4/topic/.E2.9C.94.20use.20prebuilt.20release.3F https://leanprover.zulipchat.com/#narrow/stream/287929-mathlib4/topic/.E2.9C.94.20use.20prebuilt.20release.3F]

* いや、[https://github.com/leanprover-community/mathlib4 https://github.com/leanprover-community/mathlib4]を読むと、<code>lake exe cache get</code>で取ってこれるように最近なった？

そのかわりlake build Mathlibと打てば（lean3のmathlibに比べて）割とすぐにビルドが終わる（5分前後？）

<syntaxhighlight lang="javascript">require ml4 from git "https://github.com/leanprover-community/mathlib4" @ "master"</syntaxhighlight>
↑依存パッケージとしてはこういうふうに書くが、lake build ml4ではなくlake build Mathlibが正しいっぽい。

* そもそも、require ml4じゃなくてrequire mathlibと必ず書かなきゃいけない説もある
[[Category:IT]]{{#seo:|title={{FULLPAGENAME}} - Turgenev's Wiki}}

LinuxのGUI（X11/Wayland）

2025-06-30T09:02:35Z

Turgenev: Notion-MW

== Wayland ==

とりあえずはGNOMEでの設定内容のみ。

* gnomeパッケージ自体を入れる必要はない（ゲームとか無駄なものが入る）
** gdm(3)は最低限必要
** waylandを有効にするために多分mutterが要る
** gnome-shell-extensionsも（gnome shell extensionsを使うなら）要る（なぜかgnome-shell-extension-managerのdependenciesに入っていないため（バグ報告した: [https://bugs.launchpad.net/ubuntu/+source/gnome-shell-extension-manager/+bug/1999001 Bug #1999001 “gnome-shell-extensions is not in dependencies” : Bugs : gnome-shell-extension-manager package : Ubuntu]））
** gnome-sessionはいらないかも
** [https://itsfoss.com/install-gnome-linux-mint/ https://itsfoss.com/install-gnome-linux-mint/] にあるvanilla-gnomeでもまだ余分なものが入っている気がする
* ここ参考になる [https://gihyo.jp/admin/serial/01/ubuntu-recipe/0717 https://gihyo.jp/admin/serial/01/ubuntu-recipe/0717]

指紋認証関連で弾かれる。pamとfprintdの連携がうまくいってない感があったので<code>libpam-fprintd</code>を入れたら治った。

[https://sites.google.com/site/zoom2writej/ubuntu/ibus https://sites.google.com/site/zoom2writej/ubuntu/ibus]

* USB-Cのディスプレイを起動時に認識しない。刺し直すと認識する。なんでだろう。→なんかこれはシャットダウンして待ったりすると治るタイプのやつ。ハードウェア的な問題かな。dmesg -ewとかで見れたりはする。Bad usb cable?とかなんとか言われてた気がする


=== NVIDIA ===

nvidiaが入っている状態だとちょっとめんどくてデフォルトだとXorgにされる。

[https://qiita.com/k0kubun/items/c1162098cbd7eba1bed0 https://qiita.com/k0kubun/items/c1162098cbd7eba1bed0]

に書いてあるとおり<code>nvidia-drm.modeset=1</code>をするといける。（それだけだとだめだったという情報もあるっちゃあるがこっちでは大丈夫だった）

* GRUB_CMDLINE_LINUX_DEFAULTに入れるとリカバリモードのオプションには追加されない[https://gihyo.jp/admin/serial/01/ubuntu-recipe/0743 第743回　Ubuntuの標準ブートローダーであるGRUBを改めて見直す | gihyo.jp]

NVIDIA上のmpv/celluloid

手元では<code>gpu-context=x11vk</code>が効果あり。mpvはこれだけでいけた。

celluloidの場合、さらに環境変数の<code>__EGL_VENDOR_LIBRARY_FILENAMES=/usr/share/glvnd/egl_vendor.d/50_mesa.json</code>が必要。参考: [https://github.com/mpv-player/mpv/issues/9393 https://github.com/mpv-player/mpv/issues/9393]

* applicationsの.desktopのほうでは、<code>env __EGL_VENDOR_LIBRARY_FILENAMES=/usr/share/glvnd/egl_vendor.d/50_mesa.json celluloid --mpv-gpu-context=x11vk %U</code>としておけばよい。

ただ、x11vkでperformanceが悪いというissueもある。[https://github.com/mpv-player/mpv/issues/10326 https://github.com/mpv-player/mpv/issues/10326] 見た感じこちらでは問題ない。

x11eglだと<code>libEGL warning: DRI3: Screen seems not DRI3 capable</code>と言われるが動いてはいるっぽい。

他にもいくつかある。

* [https://wiki.archlinux.org/title/mpv https://wiki.archlinux.org/title/mpv]

gnome-session-inhibitとかいうのは電源関連なのでそのさきの話かな。

==== 日本語入力 ====

ibus-mozcは廃止される？とかなんとか。Waylandに対応したfcitx5を使うのがよさそう。

全体的にはここ [https://gihyo.jp/admin/serial/01/ubuntu-recipe/0689 https://gihyo.jp/admin/serial/01/ubuntu-recipe/0689] （前述の第717回の記事でも引用されている）が参考になるかと。

基本的にはfcitx5-diagnoseを使って赤文字のところ（問題点）を順番に直していくのがよい。

まずGNOMEがめっちゃibus使おうとしてしまうらしいのでibus-daemonを除去する必要があるらしい。そこでibusパッケージをremoveする。

次に環境変数の

<syntaxhighlight lang="javascript">GTK_IM_MODULE=fcitx
QT_IM_MODULE=fcitx
XMODIFIERS=@im=fcitx</syntaxhighlight>
が必要らしい。/etc/environmentでもいいが、ユーザーごとにしたければ（Waylandの場合だと）<code>~/.config/environment.d/*.conf</code>に書くといいらしい。（参考: [https://blog.vikke.name/2020/01/27/wayland%E3%81%A7%E3%81%AExprofile%E3%82%84xsession%E3%81%AE%E4%BB%A3%E3%82%8F%E3%82%8A%E3%81%AB%E7%92%B0%E5%A2%83%E5%A4%89%E6%95%B0%E3%82%92%E8%A8%AD%E5%AE%9A%E3%81%99%E3%82%8B/ https://blog.vikke.name/2020/01/27/waylandでのxprofileやxsessionの代わりに環境変数を設定する/] 及びそこで引用されている[https://wiki.gnome.org/Initiatives/Wayland/SessionStart https://wiki.gnome.org/Initiatives/Wayland/SessionStart]）

さらにgnome-shell-extension-managerを入れてkimpanelを追加する。これでいけるはず

* gnome-shell-extension-managerのバージョンをどうにかしたような気もするが詳細忘れ

一応ibus使用時のメモ

[https://qiita.com/spumoni/items/f1e5023829c575af4dd0 Ubuntu 21.04でキーボードがus配列に変わってしまう問題 - Qiita]や[https://golang.hateblo.jp/entry/ubuntu22.04-keyboard-layout-mozc Ubuntu 22.04 でキーボードレイアウトおかしくなる問題。 - golangの日記]とかに書いてあるようにibus-mozcがjp配置を使うようにして（初期設定だとusになってしまう）、<code>ibus write-cache</code> と<code>ibus restart</code>（ibusに接続できませんと言われたら<code>ibus-daemon --xim -d -r</code>が有効かも）をする。いや普通に<code>ibus-daemon --xim -d -r</code>だけでいいっぽい

=== システムトレイ ===

MEGAなどが正しく動作しなかった。[https://github.com/JetBrains/compose-jb/issues/1847 https://github.com/JetBrains/compose-jb/issues/1847]に書いてあるとおり、extension managerから[https://extensions.gnome.org/extension/615/appindicator-support/ https://extensions.gnome.org/extension/615/appindicator-support/] を入れるとうまく動作するようになる。

* Linux Mint 21.1にしてから動かなくなった気がする
* <code>gnome-shell-extension-appindicator</code>というパッケージもある？
[[Category:IT]][[Category:Linux]]{{#seo:|title={{FULLPAGENAME}} - Turgenev's Wiki}}

デュアルブート

2025-06-03T13:39:59Z

Turgenev: Notion-MW

{{Outdated}}

WindowsとLinuxのデュアルブートにおいて役に立つ情報を記述する。古いメモを多く含む。[[Linuxのインストール|Linuxのインストール]]も参照。


== Windowsのプロダクトキー関連 ==

{{UnderConstruction|デュアルブート}}


== Bitlocker ==

とにかく前もって回復キーを保存しておくこと！！逆に回復キーさえあればBitlockerで大きなトラブルになることは多くない。

* [https://www.pcdock24.com/blog/?p=53931 BitLockerとは【BitLockerの要件と自動有効化の問題点】｜パソコン修理パソコンドック24] によるとローカルアカウントでBitlockerの有効/無効を確認するときはdiskmgmtから行かなきゃいけないらしい。
* Bitlockerを有効にしたあとにwinを起動すると再起動ループにハマることがある。解決法(Manage-bdeを使う)→[https://community.spiceworks.com/how_to/124388-stop-a-bitlocker-boot-loop Stop a BitLocker boot loop - Windows Forum - Spiceworks]


== Windowsパーティション（NTFS）のマウント ==

{{Outdated}}

==== remove_hiberfileについて ====

マウントが成功するにはWindowsが完全シャットダウンされている必要がある（またはそれが望ましい）。ただ、[https://unix.stackexchange.com/questions/107978/cant-access-windows-drive-windows-is-hibernated-refused-to-mount https://unix.stackexchange.com/questions/107978/cant-access-windows-drive-windows-is-hibernated-refused-to-mount]にある通り、windowsを正しくシャットダウンしてもなぜか「ハイバーネートされててマウントできません」的なのが出ることがあるので、マウントオプションにremove_hiberfileを追加するとよい。

* 高速スタートアップを無効にしているにもかかわらず完全シャットダウンされていないことがある気がしたので、Windowsでシャットダウン時に実行するスクリプトとして完全シャットダウンコマンドを追加したりした
* デスクトップPCではだいたい不要？


=== Bitlocker無し ===

普通にntfs-3gを使う。数字など適宜読み替えること。主にWindowsのDドライブ想定。

<ul>
<li>コマンド例
<syntaxhighlight lang="javascript">ntfs-3g -o remove_hiberfile /dev/nvme0n1p5 /media/win</syntaxhighlight></li>
<li>fstabの例
<syntaxhighlight lang="javascript">/dev/sda2 /media/ddrive ntfs-3g noauto,rw,nofail 0 0</syntaxhighlight></li></ul>


=== Bitlocker有り ===

ntfs-3gの前にDislockerで暗号化を解除する。参考→[http://www7390uo.sakura.ne.jp/wordpress/archives/270 http://www7390uo.sakura.ne.jp/wordpress/archives/2]

dislocker-fileの方式だと一旦復号したのをファイルに書き出して静的にマウントするので、（事実上）readonlyとなる。よってdislocker-fuseを使う→[https://www.systutorials.com/docs/linux/man/1-dislocker-fuse/ https://www.systutorials.com/docs/linux/man/1-dislocker-fuse/]

<ul>
<li>コマンド例
<syntaxhighlight lang="vb.net">$ sudo dislocker-fuse -V /dev/nvme0n1p3 --recovery-password=xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx -- /media/dl-fuse
$ sudo mount -o loop,rw /media/dl-fuse/dislocker-file /media/win/</syntaxhighlight></li>
<li>fstab例
<syntaxhighlight lang="vb.net">/dev/nvme0n1p3 /media/bitlocker fuse.dislocker recovery-password=xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx 0 0
/media/bitlocker/dislocker-file /media/win10 ntfs-3g rw,nofail,remove_hiberfile,permissions 0 2</syntaxhighlight>
と、二行に分けて記載する。
<ul>
<li>permissions については後述</li></ul>
</li></ul>

==== セキュリティ問題 ====

recovery-passwordを暗号化されていないパーティションに書いてしまうと結局Bitlockerの意味が全くなくなってしまうので、Linux側でもBitlockerのような暗号化パーティション（LUKSとか？）やユーザーログイン時に復号される暗号化フォルダ（ecryptfsとか）といったディスク上で暗号化される領域に書いておく必要がある（もちろん毎回パスワードの類を打ち込むのでよければそれでもいい）。


=== permissions, inheritについて ===

[https://github.com/tuxera/ntfs-3g/wiki/File-Ownership-and-Permissions https://github.com/tuxera/ntfs-3g/wiki/File-Ownership-and-Permissions] 詳しくはこちらも参照。

まず、マウントオプションとしてpermissionsを指定しない限り、ntfs-3gでマウントしたファイルは全てパーミッション・所有者が固定（uid, gid, umaskなどで指定）となり、個別のファイルについて変更することはできない。

そして、この場合、ntfs-3g経由で作成したファイルはWindows側で見るとすべてAdministratorの所有となり、さらにEveryoneにフルコントロール権限が付与される（この動作を変更するのは筆者の知る限り不可能）。

Linuxではフォルダの実行権限（x）が無ければその中に含まれたファイルにはアクセスが通らず、パスを推測することも不可能だが、Windowsではたとえ一切権限のないフォルダであっても中にあるファイル・フォルダのパスがわかれば直接パスを打つことでアクセスが通ってしまうようである（試した限り）。そのため、permissions無しでntfs-3gで作成したファイルはパスさえわかればWindows上の全ユーザーが閲覧・編集・削除できる状態ということになる。

従って、Gitを使用する場合や複数ユーザーで使用したい場合などパーミッション管理が必要なデータを扱う場合はもちろん、単に中にあるデータを保護したいという場合でもpermissionsオプションを指定することが必須になる。

次に、permissionsを指定して、かつUserMappingを指定しない場合、Linux上でrootが所有するファイルをWindows側で見ると、全てAdministratorsの所有物になり（ここはpermissionsがない場合と同じ）、そのアクセス権はLinux上での見え方と概ね一致するように設定されるようである。他のユーザーが所有するファイルにはS-1-5-21-3141592653-589793238-462643383-10000というような上位桁が円周率に由来する（この部分はハードコードされている）SIDが割り当てられ、こちらもアクセス権が適切に設定される。UserMappingを指定することで、このSIDの部分の割り当てを変更することができる。

Windowsに挙動を近づけるための他のオプションとしてはinheritというのもあり、これは新規作成時に上位フォルダの権限を継承するものである。しかし、これは所有者を継承するオプションではない（そして、所有者が違えばまともに継承もされない）。

以上のことから、Windowsの一般ユーザーフォルダの内容などをLinuxから良い感じに（Windows側の権限設定を汚染せずに）使えるようにするには、明示的なUserMappingが事実上必須であることがわかる。

一方で、Administrator所有・全ユーザー閲覧可能（あるいは不可能）、といった、Windows側の全ての一般ユーザーに対して共通のアクセス権を適用する設定であれば、UserMappingを使用しなくても簡単に設定が可能である。個人用PCかつ、画像・動画などのメディアファイルやLinuxでしか使用しない大きめのソフトウェアを入れておく用途であれば、こちらで問題ないだろう。

Linux側で別ユーザーの所有に見せたい場合は、上記のS-1-5-21-3141592653-589793238-462643383-10000のようなSIDが見えてしまう状態でもよければ（かつ、権限設定にも問題がなければ）それでもいいし、下記のbindfsと併用する方法もある。いずれにしても、Linux側で全員が読み取り・書き込み・実行が可能なファイルは、Linux側での親フォルダの権限によらず、Windows側では（パスさえわかれば）対応する権限でアクセスができてしまうということに注意が必要である。

また、Windowsではファイルの新規作成時には必ず実行権限が付加されるので、Linux側でそれを見た場合も実行可能になる（実行権限を外すと.exeなどが実行できなくなる）。従って、GitのレポジトリのフォルダをWindows/Linux間で共用するようなことをすると、Windows側では実行権限無しで（これがデフォルトであるため）コミットされたファイルがLinux側では実行権限有りに見えるため差分が出てしまうといったことが発生する。これはUserMappingでも解決はできないので、Gitリポジトリのあるフォルダを共用するのは不可能である。

==== bindfs ====

既存のディレクトリを、所有ユーザーやパーミッションを変更してマウントしてくれる。

<syntaxhighlight lang="python">sudo bindfs --mirror=myname --force-group=myname /media/win ~/.mnt_win/</syntaxhighlight>
または

<syntaxhighlight lang="python">sudo bindfs --force-user=myname --force-group=myname /media/win ~/.mnt_win/</syntaxhighlight>
この2つの違いは不明

作成した

sudoがないと<code>fusermount: option allow_other only allowed if 'user_allow_other' is set in /etc/fuse.conf</code>とか言われたりする

fstabの例

<syntaxhighlight lang="python">/media/win /home/myname/.mnt_win fuse.bindfs nofail,map=root/myname:@root/@myname,create-with-perms=g-w 0 0</syntaxhighlight>
Linuxだとrootのデフォルトのumaskが022で一般ユーザーが002なせいで一般ユーザーが作ったファイルが775とか664になってしまったりするがg-wをつけることによって755とか644になる（もちろんchmodすれば変えられる


== Minecraft ==

.minecraftフォルダをWindowsとLinuxで共有したはいいが、（それ自体.minecraftの中にある）ゲームディレクトリの指定も共有することを考えると、両OSでパスの仕様がやや異なるのが問題になる。

例えば以下ではWindowsのルートが/media/winにマウントされているとする。

まずLinuxのランチャーは相対パスどころかシンボリックリンクすら変換して普通の絶対パスにしてしまう（設定を書き換えてしまう）っぽいので、linuxでは絶対パス指定で/media/win/Users/pathのようにする。で、この書き方をするとWindowsでは相対パスと解釈されるのだが、基準となるフォルダが謎で、「PLAY」を押した時のチェック時は.minecraftが基準なのだが、実際に見られるのはランチャーがあるフォルダが基準（＝こっちになかった場合ゲームディレクトリが新たに作られる）

* ストアアプリ版の（新しい方の？）Minecraftランチャーでは、この「ランチャーがあるフォルダ」は<code>AppData\Local\Packages\Microsoft.4297127D64EC6_8wekyb3d8bbwe\LocalCache\Local</code> あたりである。

従って、ランチャーのフォルダと.minecraft内の両方にmediaというフォルダを作って中にwinという名前でC:\へのジャンクション置くとうまくいく。

.minecraftの中にはゲームディレクトリ専用のフォルダを作り、その中にmain, snapshotなど用途に応じたフォルダを作っておくとよい

== google-drive-ocamlfuse ==

labelを使うと複数アカウントをマウントできる。デフォルトのラベル名はdefault

しばらく使っていないと起動時におそらく認証の失敗が原因でマウントポイントのあるフォルダに対するlsがしばらく一切反応しなくなる（~/.gdfuse内の該当ラベル名のフォルダを削除して最初からやり直せば治る）。よってマウントポイントをホームディレクトリ直下に作るのは避けたほうがよい（gdfというフォルダを作っている）。


== MEGA ==

Winが完全にはシャットダウンされていない状態でLinuxを起動するとCドライブ上のMEGAのフォルダが読めずに同期が無効になってしまう。MEGA自身のかわりに、Cが読める状態でのみMEGAを起動するシェルスクリプト（mega-mounted.sh）をスタートアップに登録しておく。Cが読めなかった場合にはdialogコマンドで通知ダイアログを表示する。（このスクリプトではC自身のかわりにC:\Windowsをみている）（gdialogは一部のディストリにしか入っていないかもしれない。実際にコマンド打ってみてどんな表示になるかも含めて確かめておいたほうがよい）

<syntaxhighlight lang="shell">#!/bin/sh
if [ -d /media/win-rw/Windows ]; then
megasync
else
gdialog --title "Warning" --infobox "MEGAsync is not started because Windows partition is not mounted" 0 0
fi</syntaxhighlight>

== Bluetooth機器 ==

同じBluetooth機器を同じPCのWindowsとLinux双方にペアリングするというもの。自分はマウスでしかやったことがない。意外と難しいが何とかなる。

==== 参考 ====

* [https://orumin.blogspot.com/2019/02/bluetooth.html https://orumin.blogspot.com/2019/02/bluetooth.html]
* [https://qiita.com/yoko-yan/items/9b0235678fd804b4fe0d https://qiita.com/yoko-yan/items/9b0235678fd804b4fe0d]
* Bluetooth Low Energyという仕様もあるらしく、自分のマウスはこっちだった。これに関しては[http://aimingoff.way-nifty.com/blog/2018/09/windows-linux-b.html http://aimingoff.way-nifty.com/blog/2018/09/windows-linux-b.html]を参照。割と情報が少ないので感謝。
** <code>HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTHPORT\Parameters\Keys\xxxxxxxxxxxx</code>を見るためにpstoolsをダウンロードして<code>PsExec64 -s -i regedit</code>とする必要があることに注意。なお、セキュリティソフトによってPsexecが脅威と見なされ強制削除されてしまうときは代わりにフリーソフトのAdvancedRunを使うとよい。
** まとめ
*** CSRKをLocalSignatureKey
*** LTKをLongTermKey
*** EDIVをEdiv（16進→10進に変換）
*** ERandをRandに（バイト(2文字のかたまり)をすべて逆順にしてから10進変換）。ちなみにこれを間違えた結果、マウスを動かすたびにbluetoothアイコンが白↔黒と高速で切り替わる謎のバグっぽい現象が起こったことがあった。
*** 小文字を大文字に変える必要はない。また、IRKをIdentityResolvingKeyに書くのも不要。


==== マルチデバイス対応マウス（Logicool） ====

マルチデバイス対応（切り替えボタンがあるやつ）のマウス（LogicoolのM595）を使ったら、登録情報を一旦削除して再接続するごとにMacアドレスがひとつインクリメントされて困った。Linuxで接続→Winで接続→Linuxで上記の書き換え、とやったあと、フォルダ名を変更（1を足せばよいはずだが正確にはWinの情報を見るのがよい）するとうまくいった。[https://twitter.com/e9g/status/1381111849664409600 自分のツイート]にも記録あり
[[Category:IT]][[Category:Windows]]{{#seo:|title={{FULLPAGENAME}} - Turgenev's Wiki}}

HTTP・SOCKS・透過プロキシ・UDP

2025-06-03T13:39:53Z

Turgenev: Notion-MW

SOCKS・透過プロキシ・UDP-over-TCPなどを中心に、ネットワークの変更に使えるプロキシ関連の各種技術を雑にまとめた。

近年はGo製のものが多い。また検閲に対抗するためか、中国系（中国語でissueが投稿されているなど）のものが多い。gost, go-proxy, hysteria, txthinking/socks5, things-go/socks5などはいずれもその2つに当てはまる。たまにロシア系もある。


== 大規模・多機能系 ==

以下のものは機能が多くて分類できないのでソフトウェアごとに紹介する。

==== gost ====

GO Simple Tunnelの略らしい。安定版のv2系（[https://github.com/ginuerzh/gost https://github.com/ginuerzh/gost], [https://v2.gost.run/ https://v2.gost.run/]）と開発中のv3系（[https://github.com/go-gost https://github.com/go-gost], [https://gost.run/ https://gost.run/]）で大きく仕様が異なる。v3は開発中と言いつつv2系のページを見るとかなりv3推しに見える。

starはバージョン2が16k、バージョン3が5kほど。

イメージとしては、TCPによるシンプルなトンネルプロトコル（これがgost）（暗号化無し）と他の大量のプロトコルの間の相互変換を実装しているような感じと思われる。

非常に多機能で、このページで紹介している多くソフトウェアの基本機能をカバーしていると言ってもいいくらい。UDP-over-TCP系は基本これ1つで十分。機能の豊富さに比して明らかにドキュメントが不足しており、エラーメッセージも親切ではない（起動時ではなく実際にパケットが来てからエラーが出るような感じ）。

<ul>
<li>connectorとしてはsocks5も用意されているが、相手がgostでない限りUDP Associateは動かない模様。具体的には
<syntaxhighlight lang="javascript">gost -L "auto://:8480?udp=true&relay=udp" -F socks5://192.168.1.13:3129</syntaxhighlight>
などとしても、 05f3 0001 0000 0000 0000みたいなよくわからんリクエストが送られてしまう。このf3のところは下記の独自拡張っぽい。
[https://github.com/go-gost/x/blob/04d1587a77964636d8e50f5cce475ee8621bece7/internal/util/socks/socks.go#L17 https://github.com/go-gost/x/blob/04d1587a77964636d8e50f5cce475ee8621bece7/internal/util/socks/socks.go#L17]</li></ul>

==== go-proxy ====

[https://github.com/snail007/goproxy https://github.com/snail007/goproxy]

これも見た感じgostと同じくらいか一部では上回るくらい多機能に見えるが、この雰囲気にしては珍しく有料版があり、無料版だと一部機能が制限されているようなので、あまり使ったことはない。


== GFW回避 ==

中国政府の検閲システムであるグレート・ファイアウォール（GFW）に対抗することを主な目的とするもの。

==== shadowsocks ====

SOCKSに暗号化を施した独自プロトコルで、いくつかの実装がある。[https://github.com/shadowsocks/shadowsocks-rust https://github.com/shadowsocks/shadowsocks-rust]などが主流とみられる。

VPN以外のGFW回避ソフトウェアだとおそらくもっともメジャー。

サーバーとクライアントに分かれていて、クライアント側では透過プロキシにも対応している。


==== Hysteria ====

通信路がHTTP/3に偽装した形で暗号化される。shadowsocksの次世代に位置付けられるソフトウェアのように見える。

SOCKS5サーバー部分にはtxthinking/socks5を使っている。


== SNI Proxy ==

HTTP・HTTPSのリバースプロキシで、host（HTTPの場合）あるいはsni（HTTPSの場合）に基づいてアクセスを振り分けるものをSNI Proxyと呼ぶことがあるらしい。NginxやHAProxyのような汎用のプロキシサーバーでも使える機能だが、これを専門とするソフトウェアもある。

* こんな使い方もある（自分の記事）→ [https://turgenev.hatenablog.com/entry/2025/03/21/020550 【Android】NextDNSをアプリごとに有効無効切り替え+Tailscale経由の自宅鯖を使ってControl D風のトラフィック転送 - turgenev’s blog]


==== dlundquist/sniproxy ====

[https://github.com/dlundquist/sniproxy https://github.com/dlundquist/sniproxy]　starは2.6kほど。2024年に更新あり。非推奨である理由（HTTP/2とかQUICでうまくいかないとか）も書いてある。

==== tcpproxy ====

[https://github.com/inetaf/tcpproxy https://github.com/inetaf/tcpproxy]　starは1.3kほど。ライブラリ用途がメインか。


==== ameshkov/sniproxy ====

[https://github.com/ameshkov/sniproxy https://github.com/ameshkov/sniproxy]　starは70ほど。上流のSOCKS5, HTTPプロキシへの転送機能がある。


==== puxxustc/sniproxy ====

[https://github.com/puxxustc/sniproxy https://github.com/puxxustc/sniproxy]　starもほぼなく更新も9年前。


== SOCKSプロキシサーバー ==

ここにあげたものは特に注記がなければUDP（ただし筆者が念頭に置いているのはAssociateのみで、Bindに関してはほぼ調べていない）に対応している。


==== Dante ====

[https://www.inet.no/dante/index.html Dante - A free SOCKS server]

企業（Inferno Nettverk A/S）によるオープンソースなSOCKS5実装で、有償サポートまであるらしい。見るからに古臭いHPで、メンテされているかどうか不安になるが、つい最近2024年末にもアップデートがあり、次期バージョンの計画についても記載されている。

Cで書かれていて、おそらく最も正確なSOCKS5実装だろう。コメントも親切で、リファレンス実装のような雰囲気がある。他の透過プロキシクライアントなどをテストする際はDanteでテストして動けば安心感がある。


==== OpenSSH ====

現実的に最もよく使われているSOCKSサーバーは間違いなくOpenSSHだろう。しかし、UDP-over-TCPの問題があるため、UDPはサポートされていない。

ssh -Dでforward方向のプロキシを建てるのが有名だが、OpenSSH 7.6からは-Rでreverse方向にも建てられるようになった。クライアント側が7.6以上であればよい。

* 参考: [https://www.openssh.com/txt/release-7.6 OpenSSH 7.6] （<code>ssh(1): add support for reverse dynamic forwarding</code>）

==== socks-with-udp-over-ssh ====

[https://github.com/ge9/socks-with-udp-over-ssh https://github.com/ge9/socks-with-udp-over-ssh]

これ自体はSOCKS5サーバーではなく、TCP接続（あるいは任意のバイトストリーム）の上にUDP付きのSOCKS5を通すために自分が実装したツール。サーバー側とクライアント側に分かれている。しかし実装した後にgostで同じことができることに気付いた。

経緯・使い方などは[https://turgenev.hatenablog.com/entry/2024/05/12/231208 root権限のないssh上にUDPを通す方法について（ポートフォワード、SOCKS5プロキシなど） - turgenev’s blog]に書いてある。

==== 3proxy ====

[https://3proxy.ru/ 3proxy tiny free proxy server for Windows, Linux, Unix: SOCKS, HTTP, FTP proxy]

[https://github.com/3proxy/3proxy https://github.com/3proxy/3proxy]

ロシア系。SOCKS・HTTP・POP3・SMTPなどいくつかのプロキシを含む。エラーメッセージなどがかなり不親切だが、結構多機能で、ちゃんと動くソフト。<code>3proxy</code>というメインの実行ファイルとあわせて、各プロキシに対応した<code>socks</code>や<code>proxy</code>といった検索性の低い名前の実行ファイルがいくつか含まれているちょっと謎の構成。

==== fast-socks5 ====

[https://github.com/dizda/fast-socks5 https://github.com/dizda/fast-socks5] Rust製では最も有名か。starは500ほど。使ったことなし


==== txthinking/socks5 ====

[https://github.com/txthinking/socks5 https://github.com/txthinking/socks5]

starは700前後。hysteriaやtrojan-goなどいくつかの大きなプロジェクトで使われており、現在もメンテされているgo製のSOCKS5関連ライブラリでは一番メジャーか。

クライアントもある。

自分のfork（[https://github.com/ge9/socks5 https://github.com/ge9/socks5]）ではFull Cone NATを追加した


==== armon/go-socks5 ====

[https://github.com/armon/go-socks5 https://github.com/armon/go-socks5]

starは2kだが、最終更新2016年でUDP Associateも無し。Wireproxyで以前使われていたが使われなくなった（[https://github.com/whyvl/wireproxy/issues/15 https://github.com/whyvl/wireproxy/issues/15]）。

ここからフォークされたものが複数ある。


==== things-go/go-socks5 ====

[https://github.com/things-go/go-socks5 https://github.com/things-go/go-socks5]

armon/go-socks5からのフォーク（GitHub上ではfork扱いではない）。starは400個ほど。UDP Associateはサポートしているがバグあり（自分のPRが採用されるかどうかで揉めてる[https://github.com/things-go/go-socks5/pull/63 https://github.com/things-go/go-socks5/pull/63]）。

Wireproxyで使われている。

自分のフォーク [https://github.com/ge9/go-socks5 https://github.com/ge9/go-socks5] ではFull Cone NATを追加した


==== haxii/socks5 ====

[https://github.com/haxii/socks5 https://github.com/haxii/socks5]

armon/go-socks5からのfork。UDP Associate対応。starは50個前後。最終更新2019年。


==== wzshiming/socks5 ====

[https://github.com/wzshiming/socks5 https://github.com/wzshiming/socks5]

クライアントもある。

starは90個ほど。最終更新2024年。

とりあえずredsocksと組み合わせでUDP透過プロキシ動作確認済。

Wireproxyで使用が検討された（[https://github.com/whyvl/wireproxy/issues/15 https://github.com/whyvl/wireproxy/issues/15]）が結局使用されず。


==== haochen233/socks5 ====

[https://github.com/haochen233/socks5 https://github.com/haochen233/socks5]

クライアントもある。

UDP Associateはサポートしているが、starは49とさらに少なく、最終更新も2021年。

同じくWireproxyで使用が検討された（[https://github.com/whyvl/wireproxy/issues/15 https://github.com/whyvl/wireproxy/issues/15]）が結局使用されず。


== 透過SOCKSプロキシクライアント ==

[https://turgenev.hatenablog.com/entry/2024/03/25/160556 透過プロキシを用いて特定アプリケーションのTCP・UDP通信をSOCKS5経由にする方法（Windows・Linux（iptables TPROXY）・Androidなど） - turgenev’s blog]で扱った内容。

バックにSOCKS(SOCKS5)プロキシを用いてTCP・UDPのレイヤで透過プロキシを行うもの。VPNと同等の動作で、基本的には管理者権限（Linuxの場合、最低でもCAP_NET_ADMIN）が必要。

以下のいずれも、ドメイン解決にはプロキシが適用されない（Linux向けの2つはできなくはないかもしれないが、しづらい）ことに注意。

==== redsocks ====

[https://github.com/semigodking/redsocks semigodking/redsocks] （fork元の[https://github.com/darkk/redsocks darkk/redsocks]はメンテされておらず、TCPのTPROXYに非対応）

*nix対応。BSD系で動かすことができたという話は[https://turgenev.hatenablog.com/entry/2024/06/10/134017 FreeBSD/OpenBSD/NetBSDで透過プロキシのredsocksを動かしてみる - turgenev’s blog]に書いた。

==== hev-socks5-tproxy ====

[https://github.com/heiher/hev-socks5-tproxy https://github.com/heiher/hev-socks5-tproxy] Linux向け。redsocksより若干知名度は下がるものの、きちんとメンテされている。


==== ProxiFyre ====

[https://github.com/wiresock/proxifyre https://github.com/wiresock/proxifyre] Windows用の透過SOCKSクライアント。管理者権限必要。TCP/UDP両方対応。インストールも簡単で、よくできている。


==== Proxifier ====

[https://www.proxifier.com/ https://www.proxifier.com/] 見た感じ機能は十分そうだが、有料なので試していない。


== VPN(tun) ==

上記と似ているが、VPNとして動作するもの。プロセスが特定しづらい場合・特定のIPアドレス範囲だけで十分な場合などに効果を発揮する。

以下は特筆しない限りUDP Associateに対応。もちろん、pingなどは通らない。

==== tun2proxy ====

[https://github.com/tun2proxy/tun2proxy https://github.com/tun2proxy/tun2proxy]

Rust製。starは700ほど。SOCKSとHTTPをtunにしてくれる。

==== hev-socks5-tunnel ====

[https://github.com/heiher/hev-socks5-tunnel https://github.com/heiher/hev-socks5-tunnel]

hev-socks5-tproxyの作者による。Androidアプリの[https://github.com/heiher/sockstun https://github.com/heiher/sockstun]もここから。

== ライブラリ関数ハック系 ==

ライブラリ関数レベルでの置き換えになるため厳密性・安定性に欠ける（異常終了する場合もある）ものの、root権限がない場合に有効な手法。


=== Linux（LD_PRELOAD） ===

libc依存でないプログラム（Go製のものなど）には効かない。

==== socksify ====

後述のDanteの一部。UDP/TCP両対応。唯一のUDP対応のものである。

<syntaxhighlight lang="go">route {
from: 0.0.0.0/0 to: 0.0.0.0/0 via: 192.168.1.1 port = 1080
}</syntaxhighlight>
こんな感じの<code>/etc/socks.conf</code>を作るか、<code>SOCKS5_SERVER=192.168.1.1:1080 socksify curl http://ipv4.icanhazip.com</code> とかでもよい。

Macでも動くはずだが、筆者が唯一試したMac環境ではcurlに対してさえうまく動作しなかった（socksifyを使わないのと全く同様に動作するだけだった）（<code>DYLD_FORCE_FLAT_NAMESPACE=1</code>は指定している）。


==== proxychains-ng(proxychains) ====

ngはnew generationの略で、proxychainsの後継である。ただしコマンド名はproxychains4である。

多段プロキシを構成するためのソフトウェア。

UDP非対応（[https://github.com/rofl0r/proxychains-ng/issues/336 https://github.com/rofl0r/proxychains-ng/issues/336]）。ただしDNSに対応したproxy_dnsというオプションがあり、これを有効にするとDNS以外のUDP通信が正常に機能しなくなる副作用がある（[https://github.com/rofl0r/proxychains-ng/issues/103 https://github.com/rofl0r/proxychains-ng/issues/103]）。


==== torsocks(tsocks) ====

多分、メンテされていないtsocksがTorに取り込まれてtorsocksになったような感じ。tsocksは非常に古く、多分2010年以降には更新されていないが、知名度は高く、今でも多分そこそこ使われてそう。

torsocksはアクティブなはず。ただし、Torでない普通のSOCKS5を指定しても動かないようである（やり方が悪いかも）。

tsocksはUDPには対応していない。torsocksもそうだが、まずそもそもTor自体がUDPに対応していない。


=== Windows（DLL Hijacking） ===

どのDLLを置き換えたらいいか自明ではなさそうなので、LD_PRELOADと違って対象とするソフトウェアごとに実装が必要そう。そもそも不可能なソフトウェアもLD_PRELOADの場合より多そう。よく見かけるのはDiscordを対象にしたもので、ロシア系のものが多い。筆者は使ったことがない。

==== discord-drover ====

[https://github.com/hdrover/discord-drover https://github.com/hdrover/discord-drover]

==== discord-voice-proxy ====

[https://github.com/runetfreedom/discord-voice-proxy https://github.com/runetfreedom/discord-voice-proxy]


== HTTPプロキシ ==

Squid, Privoxyなどが有名。

Squidには透過プロキシ機能があるが、redsocksなどとは動作の細かい部分が異なる。[https://turgenev.hatenablog.com/entry/2025/03/25/171736 squidで透過プロキシ（intercept, tproxy）を動かす - turgenev’s blog]に書いた。


== localhost・LANなどへのアクセス制限 ==

典型的な設定例として、localhostやプライベートIPへのアクセスを制限する設定をSquid・Dante・3proxyそれぞれに関して紹介しておく。

==== squid ====

<code>to_localhost</code>はbuilt-inとして定義されていて、<code>localnet</code>（=srcがlocalnet）についてもUbuntuパッケージで提供されるsquid.confには入っているのだが、localnetがdstであるものとなるとACLが定義されていない。

<code>deny to_localhost</code>と<code>deny to_linklocal</code>は定義済みという前提で、以下のように書くとよい。

<syntaxhighlight lang="go">acl to_localnet dst 0.0.0.1-0.255.255.255
acl to_localnet dst 10.0.0.0/8
acl to_localnet dst 100.64.0.0/10
acl to_localnet dst 172.16.0.0/12
acl to_localnet dst 192.168.0.0/16
acl to_localnet dst fc00::/7

http_access deny to_localnet</syntaxhighlight>

==== 3proxy ====

IPv4のみ対応。

<syntaxhighlight lang="go">deny * * 127.0.0.0/8,0.0.0.1-0.255.255.255,10.0.0.0/8,100.64.0.0/10,169.254.0.0/16,172.16.0.0/12,192.168.0.0/16 * * * *
allow *</syntaxhighlight>

==== dante ====

IPv4のみ対応。squid・3proxyの場合と違って0.0.0.0もblockしてしまっているが、そもそも使わないので問題ないはず。

<syntaxhighlight lang="go">client pass {
from: 0/0 to: 0/0
}

socks block {
from: 0/0 to: 127.0.0.0/8 # localhost
protocol: tcp udp
command: bind connect udpassociate bindreply udpreply
}
socks block {
from: 0/0 to: 0.0.0.0/8 # RFC 1122 "this" network (LAN)
protocol: tcp udp
command: bind connect udpassociate bindreply udpreply
}
socks block {
from: 0/0 to: 10.0.0.0/8 # RFC 1918 local private network (LAN)
protocol: tcp udp
command: bind connect udpassociate bindreply udpreply
}
socks block {
from: 0/0 to: 100.64.0.0/10 # RFC 6598 shared address space (CGN)
protocol: tcp udp
command: bind connect udpassociate bindreply udpreply
}
socks block {
from: 0/0 to: 169.254.0.0/16 # RFC 3927 link-local (directly plugged) machines
protocol: tcp udp
command: bind connect udpassociate bindreply udpreply
}
socks block {
from: 0/0 to: 172.16.0.0/12 # RFC 1918 local private network (LAN)
protocol: tcp udp
command: bind connect udpassociate bindreply udpreply
}
socks block {
from: 0/0 to: 192.168.0.0/16 # RFC 1918 local private network (LAN)
protocol: tcp udp
command: bind connect udpassociate bindreply udpreply
}

socks pass {
from: 0/0 to: 0.0.0.0/0
protocol: tcp udp
command: bind connect udpassociate bindreply udpreply
}</syntaxhighlight>

== SOCKS関連の話題 ==


==== NATが介在する場合などのUDP Associateの動作 ====

OpenSSHの項目でも関連することを述べたが、UDP-over-TCPの性能劣化を避けるため、UDP Associateは「サーバー側がクライアント側に対してUDP通信で使うための中継ポートを通知する」という動作を伴う。この際、ネットワーク上でクライアント側からサーバーが直接見えていればよいが、NATを介している場合、クライアントから見たときのサーバーのIPとサーバー自身から見たときのサーバーのIP（中継ポート通知に含まれるのはこれ）が異なることがあり、通信が成立しなくなってしまう（SSHのポート転送を普通に使うだけではUDP Associateが使えないのも直接にはこれが原因）。

ただし、[https://turgenev.hatenablog.com/entry/2024/03/25/160556 透過プロキシを用いて特定アプリケーションのTCP・UDP通信をSOCKS5経由にする方法（Windows・Linux（iptables TPROXY）・Androidなど） - turgenev’s blog]にも書いた通り、Proxifyreやhev-socks5-tproxyなどは中継ポート通知のIP部分を無視するため、ポート番号が変わらないNATであれば問題なく動作する（redsocksはダメ）。


==== SOCKS5によるドメイン解決 ====

SOCKS5（SOCKS4aも？）では、クライアントがCONNECTなどの要求をする際、接続先をIPアドレスではなくホスト名（ドメイン名）で指定することができる仕様になっている。これによりクライアント側ではなくSOCKS5サーバー側でドメイン解決が行われる。

透過SOCKSプロキシの場合、TCP/UDPレイヤでのプロキシとなるので、この機能が使われることはない（[https://turgenev.hatenablog.com/entry/2024/03/25/160556 透過プロキシを用いて特定アプリケーションのTCP・UDP通信をSOCKS5経由にする方法（Windows・Linux（iptables TPROXY）・Androidなど） - turgenev’s blog]）（さらに、繰り返しになるが付け加えておくと、普通にセットアップした場合はDNSにプロキシは使われない）。一方、HTTPのレイヤで動作するWebブラウザでは、この機能が使われる場合がある。2018年時点での[https://github.com/FelisCatus/SwitchyOmega/issues/1379 https://github.com/FelisCatus/SwitchyOmega/issues/1379]によれば、Chromeでは必ずSOCKS5サーバー側でドメイン解決が行われる（これは[https://github.com/FelisCatus/SwitchyOmega/wiki/FAQ FAQ]にも書いてある）一方、Firefoxではそうでなかったようである。現在のFirefoxでは「SOCKS v5 を使用するときは DNS もプロキシーを使用する（Proxy DNS when using SOCKS v5）」（v4についても同様のオプションがあるが、SOCKS4aではないSOCKS4でどうなるかは未検証）というオプションがあってデフォルトで有効になっているため、やはり基本的にはSOCKSサーバー側でドメイン解決が行われる。AndroidのFirefox（この設定項目がない）にProxy SwitchyOmegaを入れた場合もそのように動作した。

なお、HTTPプロキシについても、ブラウザで普通に使う分には、（HTTP/HTTPS共に）ドメイン解決は基本的にプロキシサーバー側で行われる。

* 拡張機能などではうまく動作しない場合がある模様。 [https://github.com/FelisCatus/SwitchyOmega/issues/2304 https://github.com/FelisCatus/SwitchyOmega/issues/2304]


==== ブラウザのSOCKS5プロキシのWebRTC対応 ====

基本的に現在主流のブラウザ（Firefox, Chrome）のSOCKS5プロキシ機能（拡張機能で設定する場合を含む）はUDPには対応していないため、Discordの通話などWebRTC関係の機能を使うと生IPが漏洩する（またはそれを防ごうとすると単にその機能が使えない）。これは原理的に実装が不可能なわけではなく、単に需要が少ないから実装されていないだけである。

* Chromeではどれが最新か不明（最近の物は少ない）。このへんとか？[https://issues.chromium.org/issues/41180783 Chromium]
* torのバグ報告 [https://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/151 https://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/151]
* firefoxの [https://bugzilla.mozilla.org/show_bug.cgi?id=1808692 https://bugzilla.mozilla.org/show_bug.cgi?id=1808692]
** QUIC関連 [https://bugzilla.mozilla.org/show_bug.cgi?id=1882071 https://bugzilla.mozilla.org/show_bug.cgi?id=1882071]
** 新しめの包括的なバグレポート [https://bugzilla.mozilla.org/show_bug.cgi?id=1947229 https://bugzilla.mozilla.org/show_bug.cgi?id=1947229]

従って、ブラウザのWebRTCをプロキシさせたい場合はVPNや透過プロキシなどroot/管理者権限が必要な手法を使うことが多くなるだろう。ただしLinux+Firefoxの場合はsocksifyが使えるのでrootが無くても可能。


==== UDP AssociateリクエストのDST.ADDRとDST.PORT ====

クライアントがサーバー側にUDP Associateリクエストをするとき、この2フィールドには通信したい宛先ではなく（←というかそもそもそれが複数ある場合もある）、クライアント側がUDP Associateに使用する予定のポートを入れる。指定しない場合（例えばNATがある場合、これを予測するのは難しくなる）は、全ビットを0に設定する必要がある。

これによってサーバー側は、UDPパケットが送られてきたタイミングでそれが事前に通知されたものと一致するかどうか確認できるというわけである。

この部分に誤ってクライアント側が通信したい宛先ポートを入れるよう実装していたSOCKS5クライアントがいくつかある。

* semigodking/redsocks…自分の[https://github.com/semigodking/redsocks/issues/210 https://github.com/semigodking/redsocks/issues/210]で修正済み。
* gost…[https://github.com/ginuerzh/gost/issues/96 https://github.com/ginuerzh/gost/issues/96]で修正済み。
* txthinking/socks5…[https://github.com/txthinking/socks5/issues/15 https://github.com/txthinking/socks5/issues/15]で修正済み。
* things-go/go-socks5…これはサーバー側。[https://github.com/things-go/go-socks5/issues/29 https://github.com/things-go/go-socks5/issues/29]の通り、クライアントが必ずアドレス・ポートを通知してくれる（ゼロ埋めしない）と仮定していたが、修正された。

== プロキシプロトコル間の変換 ==

==== socks-to-http-proxy ====

[https://github.com/KaranGauswami/socks-to-http-proxy https://github.com/KaranGauswami/socks-to-http-proxy]

名前の通り、socksをhttpにしてくれる。starは250ほど。

==== privoxy ====

基本的にはHTTPプロキシソフトウェア。socksプロキシをhttpプロキシとして使えるようにする機能はあるが、より大がかり（一般ユーザーでの実行がしづらい）


== UDP・Wireguard関連 ==


==== UDPでサーバー→クライアントにデータ送信 ====

[https://github.com/prof7bit/udp-reverse-tunnel https://github.com/prof7bit/udp-reverse-tunnel]

これを使うと、サーバー側だけでポートが開けられるとしても事実上クライアント側で開けられるのと同等になるのでreverseをするのが楽になる

* [https://superuser.com/questions/1737943/how-to-create-a-reverse-udp-tunnel https://superuser.com/questions/1737943/how-to-create-a-reverse-udp-tunnel]
* どっちも開放できない場合、UDPホールパンチングで何とかするしかない

==== wgslirpy ====

[https://github.com/vi/wgslirpy https://github.com/vi/wgslirpy]

Slirp（ユーザーランドで動くPPPサーバーのようなもの）のような形で実装されたWireguardサーバー。rootなしでWireguardサーバーとして動作する。

==== wireproxy ====

[https://github.com/whyvl/wireproxy https://github.com/whyvl/wireproxy]

wgslirpyの逆のような（？）ツール。Wireguardクライアントであるが、SOCKSサーバーとして動作する。

依存ライブラリのUDP Associate対応が不完全（自分がプルリクを送っている）だが、クライアントによってはうまくUDP Associateが動く（[https://github.com/whyvl/wireproxy/issues/30 https://github.com/whyvl/wireproxy/issues/30]）。

<ul>
<li>自分でカスタマイズしてCone NATを加えたthings-go/go-socks5を使えば（<code>go.mod</code>で<code>replace github.com/things-go/go-socks5 => ../../go-socks5</code>などとする）、以下のようなコードをroutine.goのsocks5.Optionのところに追加することでCone NATにできる。
<syntaxhighlight lang="go">socks5.WithDialUDP(func(laddr, raddr *net.UDPAddr) (net.PacketConn, error) { return vt.Tnet.DialUDP(laddr, raddr) }),</syntaxhighlight></li></ul>


=== Wireguard通信の確立: 各パターンでのやり方 ===

各状況に応じて、2端末間でUDPの暗号化された通信路を確立するための方法を書いた。

* forwardは「クライアント→サーバー」、reverseは「サーバー→クライアント」という意味。「サーバー」は、「ポートが開放できる方」という意味合い。

==== どっちもrootあり ====

普通にWireguardを使う

==== サーバーのみrootあり ====

forward

サーバーはWireguard、クライアントは普通にWireproxyでいける

reverse

udp-reverse-tunnelで頑張って逆にする（あるいはホールパンチング）。

その上で、wgslirpyを使うか、Hysteriaを使うか

==== クライアントのみrootあり ====

↑さっきと逆

forward

wgslirpyを使うか、Hysteriaを使うか

reverse

udp-reverse-tunnelで頑張ったうえで普通にWireguardとWireproxy

==== どっちもrootなし ====

この場合そもそもWireguardを使うメリットはあまりないかも。というのとrootがないならポート開放も無理そう

forward

Hysteriaでいけそう。

reverse

udp-reverse-tunnelしてHysteria？かな

== その他の話題 ==

==== ドメインごとにプロキシを変更できるブラウザ拡張のiframeにおける動作 ====

FoxyProxyやSwitchyOmega(ZeroOmega)など、ドメインごとに自動でプロキシを切り替えてくれるブラウザ拡張はChromium系にもFirefoxにもいくつかあるが、これらはあくまでコンテンツのオリジンを元にプロキシを適用しており、ブラウザのタブを見ているわけではない。つまり、foo.comのページを開いていて、そこにbar.comのコンテンツがiframeで埋め込まれている場合、iframeの内部は、bar.comに対して使用するものと指定されたプロキシを使用して処理される。

一応、[https://superuser.com/questions/250172/disable-enable-the-proxy-on-a-tab-by-tab-basis-in-firefox Disable/enable the proxy on a tab by tab basis in Firefox]によると、Firefoxのcontainer-proxyというのがこれに近い機能を実質的に実現してくれるらしい。
[[Category:IT]]{{#seo:|title={{FULLPAGENAME}} - Turgenev's Wiki}}

Sandbox4moved3

2025-05-06T05:00:15Z

Turgenev: Notion-MW

[https://github.com/souvikinator/notion-to-md https://github.com/souvikinator/notion-to-md]

asasd

[https://github.com/souvikinator/notion-to-md link_preview]
[[Category:sandbox]]{{#seo:|title={{FULLPAGENAME}} - Turgenev's Wiki}}

MediaWiki

2025-05-06T04:36:22Z

Turgenev: Notion-MW

Wikipediaやこのサイトで使用されている代表的なWikiシステムであるMediaWikiについて解説する。

== 初期設定 ==

==== 動作要件 ====

データベース（MySQL）と（CGI版の）phpが使えることを確認しておく。スターサーバーフリー（php+mysql）では動いた。

SSHが使えないような低価格帯のレンタルサーバーのプランの中でも、PHPでexecなどの機能を使えば事実上任意コマンドが実行できるものと、それらの機能が制限されているサーバーがある。後者でもMediaWikiは一通り動くが、一部機能が動作しない場合もあるのであまりお勧めしない（特に他サーバー移行で手こずるのは困る）。

==== インストール ====

詳しくは[https://wikipedia.memo.wiki/d/%CC%B5%CE%C1%A5%EC%A5%F3%A5%BF%A5%EB%A5%B5%A1%BC%A5%D0%A1%BC%A4%CBMediaWiki%A4%F2%A5%A4%A5%F3%A5%B9%A5%C8%A1%BC%A5%EB%A4%B9%A4%EB ここ]を参照。

MySQLの設定をしたら、Mediawikiのファイル一式を設置し、/mw-configにアクセスして指示に従うとインストールが完了する。/mw-configは誰でも見られるファイルなので少し不安だが、MySQLのパスワードがわからないとインストールは完了しないため、別に公開でも問題なさそう。（不安ならBasic認証をかけておく？）

初期の管理ユーザーのパスワードを忘れるとやや面倒なことになる。Chromeがちゃんと覚えてくれない場合があるので注意すること。

<div style="overflow:auto;width: 100%; max-width: 1200px; white-space:nowrap; border:1px solid; padding-left: 10px; padding-right: 10px;" class="mw-collapsible">
<div>忘れた場合の初期化方法（CGI版phpの場合？）</div>
<div class="mw-collapsible-content">

データベース（phpMyAdmin）から、

<syntaxhighlight lang="vb.net">UPDATE `user` SET user_password = CONCAT(':B:somesalt:', MD5(CONCAT('somesalt-', MD5('somepass')))) WHERE user_name = 'someuser'</syntaxhighlight>
とする。[https://www.mediawiki.org/wiki/Topic:Rnq7yc02mg1o4j34 https://www.mediawiki.org/wiki/Topic:Rnq7yc02mg1o4j34]より。2か所あるsomesaltのところにはLocalSettings.phpの$wgDBpasswordの値を入れること。

MediaWiki1.12以前はちょっと違うらしい。自分が成功したのは1.39.1（2023年1月）。

* CGI版じゃなくてphpコマンドが直接打てるなら、[https://plaza.rakuten.co.jp/zuka2007/diary/201705010000/ こちらの方法]でもいけそうである。

</div></div>

* ファイル一式は、zipを解凍してからFTPでアップロードするとかなり時間がかかるので（1時間くらい）、zipでアップロードしてサーバー上で解凍したほうがいい。レンタルサーバー提供のファイルマネージャーでできない場合は、[https://nicoiworks.com/ftp/ ZIPファイルをサーバーにアップしてから解凍する方法] のようにPHPでファイル名を指定して解凍するか、[https://github.com/dulldusk/phpfm https://github.com/dulldusk/phpfm] のようなPHPで動くファイルマネージャー（フォルダ削除なども高速にできる）から解凍するとよい。ただし、これらのphpファイルはBasic認証で保護するなどアクセス権限には十分気を付けること。exec系（任意コマンド実行）が許可されていないstarserver freeでもこれらは動作した。

MediaWikiの拡張はたくさん（全部）onにするとよいらしい。

設定が終わるとLocalSettings.phpが出力され、以後これで色々な設定ができるようになる。インストール後にフォルダ名を変えるときはリネームの上、LocalSettings.phpで<code>$wgScriptPath = "/mw";</code>などと変えればよい。新規ユーザー作成を許可するかどうかなどの設定もここでできるので、禁止したい場合などはこのタイミングでやっておくとよいだろう。


==== Gitからのインストール ====

[https://www.mediawiki.org/wiki/Download_from_Git/ja Git からのダウンロード - MediaWiki]などに書いてあるが、安定版リリースにバンドルされている拡張やスキン（[https://www.mediawiki.org/wiki/Bundled_extensions_and_skins Bundled extensions and skins - MediaWiki]）やvendorフォルダ（？）が無かったりして動かすのに一手間かかる。

==== その他初期設定 ====

<ul>
<li>管理画面
ブラウザ上から$wgScriptPath以下の/mw-configというパスにアクセスすればよい。ここは誰でも見れてしまうが、その先に進むには（初期インストール後に生成されてLocalSettings.phpに書き込まれる）$wgUpgradeKeyが必要なので管理者以外は操作できない。</li>
<li>ロゴ 
参考サイトにもあるが、resource/assets/にデフォルトのchange-your-logo.svgがある。それを上書きするか、名前を変えるなら$wgLogosで設定。サイズは135x135で表示される（それより大きいサイズにすると切り取られる）模様。</li>
<li>faviconも$wgFaviconで設定。自分はsvgを256x256のpngで保存してからImageMagickでicoに変換した。</li>
<li>[https://www.mediawiki.org/wiki/Manual:RevisionDelete/ja ここ]から設定すると版指定削除ができる。</li>
<li>スキン 
$wgDefaultSkin = "vector";となっているが、"vector-2022"のほうが良さそうだったのでそちらに変えた。あわせて$wgVectorResponsiveをtrueにしてモバイルでの視認性を上げた。</li>
<li>カテゴリページの自動作成 
[https://www.mediawiki.org/wiki/Extension:Auto_Create_Category_Pages Auto Create Category Pages]をダウンロードし、<code>wfLoadExtension( 'AutoCreateCategoryPages' );</code>とする。これは便利。</li>
<li>アクセス数解析
精度のほどはわからないが、[https://www.mediawiki.org/wiki/Extension:HitCounters HitCounters]でできる。同じようにダウンロードした後、リンク先に記載のとおり、管理画面に行ってupdate.phpを実行する必要がある。その後で<code>wfLoadExtension</code>をすればよい。アクセス数は誰からでも見えるようであるが、特に問題はないので放置。</li>
<li>SyntaxHightlight
Linuxのサーバーでは、<code>extensions/SyntaxHighlight_GeSHi/pygments/pygmentize</code>のパーミッションを変更して所有者に実行権限を付加（先頭の桁を7にする）。参考: [https://www.mediawiki.org/wiki/Extension:SyntaxHighlight/ja Extension:SyntaxHighlight - MediaWiki]</li></ul>

== アップグレード ==

基本的には、

# 新しいバージョンのMediaWikiファイル一式を新しいフォルダに設置して、そこに
#* LocalSettings.phpとimagesをコピー
#** LocalSettings.phpは場合によって手直しが必要かも
#* 自分で追加した拡張（extensions）（このサイトでいえばAutoCreateCategoryPagesとWikiSEO）やスキンなどを改めてダウンロードして追加（コピーしてきてもいいが、バージョンを更新したほうが良さそう）
#* ロゴなど、その他リソースをコピー
# シェル（推奨）またはmw-config（当サイトの環境ではシェルのPHPが古すぎるのでこっち）からDBの更新（ただ、バージョンの差が小さければ、既に更新前の段階で基本的に問題なくページが閲覧できる場合も多そう）

という流れ。

1.のところでは、既存のMediaWikiインストールに上書きコピーするというのも一応可能で、実際これでやっている人も結構いそうだが、古いバージョンの（不要な）ファイルが残ってしまうので推奨はされていない。


== スキン・デザイン ==


=== CSS/JS ===

[https://meta.m.wikimedia.org/wiki/Help:User_style/ja Help:User style/ja - Meta] とかにある通り、デフォルトではcssを直接ページ内に書いても有効にならない。<code>wgAllowUserCss</code>をtrueにして有効にするか、MediaWiki:Common.cssを直接編集するとよい。管理がしやすいので当サイトでは後者の方法を採用した。

当サイトでは使っていないがJSについても同じ（<code>wgAllowUserJs</code>とMediaWiki:Common.js）。


==== スキンに関するCSS ====

当サイトではVectorテーマを使用しているので、MediaWiki:Vector.cssの内容も適用される。さらにVector 2022を使っているのでMediaWiki:Vector-2022.cssの内容も適用される。

<s>設定内容としては、ja.wikipedia.orgに合わせて文字サイズを0.875emから0.944emに変更している。</s>現在は0.944→0.974に変更している。さらに、<code>vector-font-size</code>（[[MediaWiki#文字サイズ|文字サイズ]]参照）関連の設定が優先される状態になっている。

=== 文字サイズ ===

MediaWikiの文字サイズは結構小さくて、Google検索コンソールでも評価を下げられたりすることがあり、[[MediaWiki#スキン・デザイン|CSS/JS]]の通りにサイズを手動で大きくするなどしていた。しかし、最近（2025/04）Wikipediaなどを見たら文字サイズが改善していて、さらによく見ると右側に表示（Appearance）というサイドバーがあり、非ログインユーザーでも文字サイズを3段階で変更できる（Cookieに保存される）ようになっている。

これは[https://www.mediawiki.org/wiki/Topic:Ybg9afru94numvhu The Appearance menu and new default standard font size will be available for logged-out users on Project:Village Pump/Flow]などに詳しく書いてあるが、どうやらver1.43前後からこの機能が追加されたようである。

ただし、デフォルトでは非ログインユーザーの文字サイズは3段階の一番小さいものに設定されており見づらい。このデフォルト値をLocalSettings.phpで変更する方法は多分なさそうだが、ソースコードを読むと、<code>skins/Vector/skin.json</code>の<code>"vector-font-size": 0</code>を例えば<code>1</code>に変更するとデフォルトが真ん中のサイズになることがわかる。

上記リンクには、いずれデフォルトがStandardサイズ（つまり<code>1</code>）に変更されるだろうと書いてある。そして、日本語版Wikipediaでは既にデフォルトが<code>1</code>になっている。しかし、現時点の日本語版WikipediaのMediaWIkiのバージョン（[https://ja.m.wikipedia.org/wiki/Special:Version バージョン情報]）である1.44.0-wmf.27 (fbabd90)（かなり新しい）では、依然として上記の設定値に<code>0</code>になっていた（[https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/skins/Vector/+/refs/heads/wmf/1.44.0-wmf.27/skin.json skin.json - mediawiki/skins/Vector - Gitiles]）。日本語版Wikipediaでもソースコードにカスタマイズが入っているのか、それとも他の方法があるのかは不明。


=== モバイル・minerva ===

[https://www.mediawiki.org/wiki/Extension:MobileFrontend/ja Extension:MobileFrontend - MediaWiki]を使うと、モバイルデバイスでアクセスした際に（デフォルトでは）minerva（<code>MinervaNeue</code>）スキンが使われるようになる。

minervaスキンだとカテゴリが表示されないが、LocalSettings.phpに<code>$wgMinervaShowCategories = [ 'base' => true ];</code>と書くことで表示されるようになる。<code>$wgMinervaShowCategoriesButton = [ 'base' => true ];</code>という情報も出てくるが、現在の最新版ではこれは効果がなかった。

== シェルアクセス ==

[https://www.mediawiki.org/wiki/Manual:Maintenance_scripts/Running_the_scripts#No_shell_access Manual:Maintenance scripts/Running the scripts - MediaWiki]にあるように、シェルアクセスがないところで使っている場合は拡張機能でどうにかする。2つ書いてあるがMaintenanceShellのほうがいろいろと良さそう。MaintenanceShellは、有効にしたあと、Special:MaintenanceShellにアクセスする。

しかし、generateSitemapとかはまともに動かなかった。まあやはりというか、普通はシェルアクセスのあるところで使ったほうがいいっぽい。


== API ==

nodeでやる。requestはdeprecatedになったのでaxiosを使う。

cookieを使うってことがどこにも書いてなくて難しかった。[https://stackoverflow.com/questions/49367096/how-to-login-to-mediawiki-wikipedia-api-in-node-js ここ]でようやく見つけた。

== 画像 ==

[https://www.mediawiki.org/wiki/Help:Images/ja Help:画像 - MediaWiki]に詳しく書いてある。

MediaWikiにアップロードするのが原則だが、[https://www.mediawiki.org/wiki/Manual:$wgAllowExternalImages $wgAllowExternalImages]という変数を設定することで外部サイトの画像を直接掲載できる。このサイトは個人サイトであり、管理しやすい（普通のアップロードだとランダムなフォルダに入れられたりするし、移行が煩雑そう）のでこちらを使っている。

==== サイズ ====

<code>style="max-width:100%; height:auto;"</code>みたいなCSS（当サイトでは前述のCommon.cssに入れた）を使えば、外部サイトの画像でもサイズを変えられる。


==== 500 internal server error ====

アップロードまではできたが、画像ファイルが（ftpで見てもちゃんとアップロードされているのに）500 internal server errorで見れない。

これはstarserverの性質かもしれないが、どうやらimages直下の.htaccessが悪いようで、これを消したら見れた。実際に悪さをしているのは<code>Options +FollowSymLinks</code>だったっぽい。これをコメントアウトすると見れた。


== URLを短くする ==

最初の設定だとURLに<code>index.php?title=</code>のような見栄えのよくない文字列が入ってしまうが、Wikipediaのように<code>example.com/wiki/タイトル</code>のような形式が使えるように設定することもできる。[https://www.mediawiki.org/wiki/Manual:Short_URL/ja Manual:短縮URL - MediaWiki]に案内がある。そこに書いてある通り、URLに<code>?</code>が入っているのは見栄えだけでなくSEO上もあまりよくないとのこと。

注意点として、<code>index.php?title=</code>形式を短い形式に強制的にリダイレクトさせるわけではない（index.phpは単なる記事の閲覧以外にも使われるので、そのように設定するのは面倒そう）。ただ、この状態でも、記事間リンクは短いURLを使ってくれるようになる。あとはWikiSEO拡張（後述）を使うと検索エンジンにも短いURLが通知される。

このサイトはサーバーがApacheなので、[https://www.mediawiki.org/wiki/Manual:Short_URL/Apache Manual:Short URL/Apache - MediaWiki]の通りにする。長々と説明が書いてあるが、普通に設定するならSimple instructionsのところだけ読めばよい。URLに設定したい場所（たとえば<code>wiki</code>）が既にMediaWikiのフォルダとして使われているとうまくいかない（このサイトの場合は<code>mw</code>なので大丈夫）ので、この記事の最初の方にある通りにMediaWikiのフォルダのほうを動かす。

== テンプレート ==

MediaWikiにはテンプレートというものがあり、記事のパーツを引用して使いまわすことができる。このWikiでもWikipediaの「[https://ja.wikipedia.org/wiki/Template:%E7%8B%AC%E8%87%AA%E7%A0%94%E7%A9%B6 独自研究]」などに倣ったメッセージボックスをいくつかテンプレートとして利用している。

例えば、まず以下のような汎用の<code>Mbox</code>というテンプレートを作り（色も引数で指定できるのがポイント）、

<syntaxhighlight style="margin-bottom:0.2em;" lang="html"><div style="border-left: 0.4rem solid #119922" ><div style="padding-left: 10px; padding-right: 10px; border: 1px solid #222222; background-color:#FBFBFB; border-left: 0.4rem solid {{{1}}}" >{{{2}}}</div>
</div></syntaxhighlight>
<div style='text-align: center;'>Template:Mbox</div>

これを利用して下書きのテンプレートを作っている。

<syntaxhighlight style="margin-bottom:0.2em;" lang="vb.net">{{Mbox|#000022|このセクションの内容は未完成であり、今後の加筆が予定されています。}}</syntaxhighlight>
<div style='text-align: center;'>Template:Stub</div>


== SEO・OGP ==

まずは[https://www.mediawiki.org/wiki/Extension:WikiSEO/ja WikiSEO]というextensionを同じように入れる。


==== OGP ====

このサイトではとりあえず大した設定はしておらず、<code>$wgWikiSeoDefaultImage = "http://turgenev0.starfree.jp/mw/logo0.png";</code>でロゴを設定し（相対パスでも表示はされるようだが、[https://webma.xscore.co.jp/study/ogp-seo/ SNSで重要なOGPとは？SEOとの関係性や設定方法を解説 -webma-]とかを見ると多分絶対パスのほうがよさそう）、各ページに<code>{{#seo:|title={{FULLPAGENAME}} - Turgenev's Wiki}}</code>と書いただけで、あとは何もしていない。先ほどの「URLを短くする」をやっておくと、そちらのURLが正規URL（カノニカルURL）として扱われるっぽい。

表示を確かめたいときは[https://developers.facebook.com/tools/debug/?locale=ja_JP シェアデバッガー - Meta for Developers]を使うとよい。

<code>{{#seo:...}}</code>でimageなどを一度設定してしまうと、後でimageを消してもその設定がそのまま残ってしまった（WikiSEOの<code>wfLoadExtension</code>を外すと消えるが、付けるとまた復活する）。おそらくページなどを格納しているMySQLデータベースのどこかに前回の設定が残っているのであろう。ページを削除するとリセットできるがそれ以外の治し方は不明。

==== サイトマップ ====

generateSitemap.phpを使えばよい。しかし以前使っていたスターサーバーフリーではシェルアクセスがなくて使えなかったので自前で生成できるようにした（参考: [[フィルターされたNotionページによるMediaWiki|フィルターされたNotionページによるMediaWiki]]）


==== その他SEO ====

そこまでの必要性を感じないが、気が向いたらやるかも。

{{Stub}}
[[Category:IT]]{{#seo:|title={{FULLPAGENAME}} - Turgenev's Wiki}}

Windowsの右クリックメニューから複数ファイルをまとめて開く

2025-05-06T04:36:16Z

Turgenev: Notion-MW

複数のファイルを別々にではなく一度にまとめて開きたいということがある。すなわち”app.exe file1” “app.exe file2”…をそれぞれ実行するのではなく、”app.exe file1 file2 …”を実行したい。例えば複数の音楽ファイルを連続再生したいときなどである。

ただ、エクスプローラ上で複数ファイルを選択して開く（右クリックで「開く」を選ぶorエンターキー）と、別々に実行されてしまう。では、右クリックメニューからこれを実行するにはどうすればいいか？というのがこの記事のテーマである。

ついでに、パス長さ制限を超えるファイルやフォルダにおける機能制限も解決する。


== Windows10以前の右クリックメニューに戻す ==

まず、Windows11に移行すると右クリックメニューの項目数が大幅に削られており、とても使いにくいので、Windows10までの仕様に戻す必要がある。[https://pc-karuma.net/right-click-context-menu-back-on-windows-11 Windows 11 - 右クリックメニューを旧仕様に戻す方法 - PC設定のカルマ]などに従って修正しよう。コマンド例は以下。これはユーザーごとの設定なので、管理者権限は不要である。

<syntaxhighlight lang="javascript">reg add "HKCU\Software\Classes\CLSID\{86ca1aa0-34aa-4e8b-a509-50c905bae2a2}\InprocServer32" /f /ve</syntaxhighlight>
ファイルを開く操作ならダブルクリックでできるわけで、それでもあえてファイルを右クリックするユーザーの層を考えれば、使用頻度の高いメニューに絞る必要がないことは明らかである。右クリックメニューは動作が重いという問題点も指摘されてきたが、それなら項目数を削る以外の方法でパフォーマンスを改善するのが筋だろう。そもそも、Windows 11の右クリックメニューもそれほど快適な動作ではない。

なおバージョン22H2からはShift+右クリックで旧仕様のメニューが出るようになったようなので、それで十分という人は設定しなくてもよい。

ちなみにこれ以降も同じだが、<code>HKEY_CURRENT_USER</code>以下はユーザー別設定なのでPC自体の再起動をしなくてもログアウト（サインアウト）→ログイン（サインイン）で全て反映されるはず。また今回の例に関しては、実際にはexplorerの再起動で十分である。

=== 動画の右クリックメニューの順番がおかしい ===

動画ファイル（mp4やmkvなど）に関して、右クリックメニューの順番がおかしくなるという問題がある。具体的には、全ファイル共通のメニュー（「お気に入りに追加」など）とClipchampのメニューが普通の「開く」よりも上に表示されてしまう。また単一ファイル選択時だと（関連付けがすでに設定されているにもかかわらず）「プログラムから開く」が太字になってしまっている。

* 単一ファイル選択時

<div class="res-img">https://turgenev.cloudfree.jp/mw1/imgs/win-rc/clipchamp-sing.png</div>

* 複数ファイル選択時

<div class="res-img">https://turgenev.cloudfree.jp/mw1/imgs/win-rc/clipchamp-mult.png</div>

これはどうやらClipchampのメニューが悪いらしく、[https://www.elevenforum.com/t/add-or-remove-edit-with-clipchamp-context-menu-in-windows-11.6882/ Add or Remove Edit with Clipchamp Context Menu in Windows 11 Tutorial | Windows 11 Forum]（[https://www.elevenforum.com/t/clipchamp-context-menu-removal.6150/ Clipchamp context menu removal | Windows 11 Forum]に書いてあった）や[https://www.naporitansushi.com/clipchamp-context-menu-disable/# Windowsの右クリックの「Clipchampで編集」を削除する方法 | ナポリタン寿司のPC日記]に書いてある通り、Clipchampのメニューを非表示にすると治る。コマンド例は以下。

<syntaxhighlight lang="javascript">reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Shell Extensions\Blocked" /v {8AB635F8-9A67-4698-AB99-784AD929F3B4} /f</syntaxhighlight>
* HKLMでも設定できる。また、「デバイスキャスト」を非表示にする場合はUUIDを<code>{7AD84985-87B4-4a16-BE58-8B72A5B390F7}</code>に変える。

Clipchampを表示したまま順番を治す方法は不明だが、自分でメニューを作ればできるかもしれない。Clipchampのメニューの実装に使われていると思われるIContextMenuについては後でも述べているのでそちらも参照。おそらくClipchampによるこのインターフェースの実装にバグがあるためにこのような挙動をしているのであろう。

以下に修正後の正しい表示を載せておく。いずれの例でも関連づけはデフォルトのメディアプレイヤーが使われているものと仮定している（書いていて気付いたが、同一アプリにもかかわらず「プレーヤー」「プレイヤー」の表記ゆれがある）。

* 単一ファイル選択時

<div class="res-img">https://turgenev.cloudfree.jp/mw1/imgs/win-rc/sing.png</div>

* 複数ファイル選択時

<div class="res-img">https://turgenev.cloudfree.jp/mw1/imgs/win-rc/mult.png</div>

== 不完全な解決策 ==

本題に入る。まずは、不完全ではあるがそこそこ簡単な解決策を紹介する。それは右クリックメニューにある「送る」を使う方法である。エクスプローラのアドレスバーに<code>shell:sendto</code>と入力すると「送る」メニューの元になっているフォルダを開くことができる。ここにショートカットやファイルを追加しておけば、それが右クリックメニューに表示され、選択されたファイルをまとめてコマンド引数として渡してくれる。ショートカットを編集すればオプションも渡せる（あるいはバッチファイルを突っ込んでもよい）。

* 今後紹介する方法にも共通するが、ファイルの順番としては、メインとして選択されたもの（右クリックされたもの）から下方向に進んでいき、下端まで達したら一番上に戻ってそれから選択されたものの直前まで進む。例えばファイルが”0”から”9”までの10個あるフォルダで全選択をして”5”を右クリックして「送る」を使うと、5 6 7 8 9 0 1 2 3 4の順番で渡される。

しかしこの「送る」には弱点があり、[ref]で紹介したように、この「送る」メニューは260文字の長さ制限を超えるパスをもつファイルに対してはうまく機能しない。音楽ファイルなんかはアーティスト名も曲名も色々入って長大な名前になりがちで、実際に自分がこれで困ることになった。

もう一つ、「送る」メニューは拡張子に関連付けられないという問題がある。つまり、音声ファイルを一度に開くためだけのコマンドも、画像ファイルを一度に開くためだけのコマンドも、全てのファイルを対象とした「送る」メニューにまとめて入れざるを得ない。メニュー数が無駄に増えればそれだけ管理・操作もしづらくなる。ついでに言えば、「送る」を一旦クリックしてから中の項目を選ぶ手間もなかなかバカにできないところがある。


== 前提知識 - メニューを管理するレジストリ ==

右クリックメニュー関連の設定はレジストリを使って管理されている。この記事では上記「送る」の問題を解決する方法をこの後で2つ紹介するが、いずれもレジストリの<code>command</code>という名前のキー（設定内容に応じて色々な所に設置されている）を編集する必要がある。それにあたって、前提知識としてレジストリの内容をある程度理解しておく必要があるだろう。

この話題に関しては比較的多くのサイトで解説があるが、Windowsのバージョンごとにかなり頻繁に仕様が変わっているようで、不十分なサイトも多い。最も優れているのは[https://www.pg-fl.jp/program/winreg/classes.htm Windowsレジストリ解剖記]で、かなり量は多いが、バージョンによる挙動の違いまで細かく示されている。

この記事に必要な操作を行うためには<code>command</code>の場所だけわかっていればいちおう十分だが、以下の内容くらいは覚えておいたほうがよい。

* HKEY_CURRENT_USERはHKCUと略され、ユーザーごとの設定を管理する。原則、変更はユーザー権限のみで可能。色々いじっても比較的安全。
* HKEY_LOCAL_MACHINEはHKLMと略され、システム全体（全ユーザー対象）の設定を管理する。変更には管理者権限が必要。設定は慎重に。
* HKEY_CLASSES_ROOTはHKCRと略され、関連付け専用のもので、HKCU\Software\ClassesとHKLM\Software\Classesの内容を合わせたものが表示される。関連づけの設定を確認するにはここを見るのがいいが、設定を変更する際にはここをいじるとHKLMのほうが変わってしまうことがあるのでHKCU\Software\Classesを変更したほうがよい。

以下では、設定方法を①ProgIDを使うもの②完全に独自のメニューを追加するものと大きく二つに分けて記述する。


=== ProgIDを使うもの ===

{{Valuable}}

特定の拡張子をもつファイルをダブルクリックやEnterで開くときに使われるプログラム、あるいは「既定のプログラム」あるいは「ファイルを開くプログラムの選択」のようなダイアログが表示されるときに表示されるプログラムは、このProgIDを用いて管理されている。この方法のメリットは、何より「ダブルクリックまたはEnterキー一発で起動できる」という操作性である。また、Windows11以前のメニューに戻さなくても使いやすい。

* 複数選択した際は「送る」と同様の順番で渡されるが、右クリックをしない場合は”メインとして選択されたファイル”がどれであるかが若干分かりづらい。基本的には最後に（左）クリックされたものになるはずで、よく見るとそれだけ少し太い（濃い）枠で表示されていることがわかる。なので音楽再生時など複数ファイルを上のものから順にすべて渡したいときは、「先に一番下にあるファイルをクリックしてから、一番上にあるファイルをShift+ダブルクリック（あるいはShift+クリックしたあとEnter）する」というのが有効である。

一方で、設定のしくみはやや煩雑である。具体的には、拡張子.xxxに対して

<code>HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.xxx\UserChoice</code>

というキーがあって、ここの<code>ProgId</code>の値を<code>value</code>としたときの<code>HKEY_CLASSES_ROOT\value\shell\open\command</code>の内容に従ってアプリケーションが起動される。

Windows10以降では<code>UserChoice</code>の中身を変更するためには普通の管理者権限やSYSTEMよりもさらに上位のTrustedInstaller権限が必要である。AdvancedRunなどを使ってTrustedInstaller権限で変更することは一応できたが、ハッシュ値の生成までちゃんとやっていないので自動で修正されてしまった（ここが解決できるかどうかは未調査）。従って、任意のコマンドを設定したい際は、まず<code>UserChoice</code>の中身を変更するところだけエクスプローラーのダイアログを使い、その後で<code>HKEY_CLASSES_ROOT\value</code>の中身を好きに変えるほうがよいだろう。

例えば新たなメニューを追加したい場合なら、以下のようにするとよい。

* 今まで使われていない（乱数値など）名前をもつダミーのexeファイル（実行ファイルとして正しく機能する必要はなく、空のファイルでもいいし、拡張子がexeでなくてもよい）を用意する（ここでは<code>dummy.exe</code>とする）
* 関連付けたい拡張子のファイルの右クリックメニューから「プログラムを開く」を選択し、<code>dummy.exe</code>を選んで関連づける
** これによりレジストリキー<code>HKEY_CURRENT_USER\Software\Classes\Applications\dummy.exe</code>が作られた上で<code>UserChoice</code>の<code>ProgId</code>には<code>Applications\dummy.exe</code>が書き込まれる
* <code>HKEY_CURRENT_USER\Software\Classes\Applications\dummy.exe\shell\open</code>の中身を自由に変更する。

=== 完全に独自のメニューを実装する ===

これは、「PowerShellをここで開く」「VS Codeで開く」のように完全に独自の右クリックメニューを追加するものである。設定は意外と簡単である。また、フォルダに対する右クリックメニューや全ファイルに共通の右クリックメニューを追加するにはこの方法しかない。ただし、Windows10以前のメニューに戻さないと「その他のオプション」を押す手間がかかるので注意。

拡張子ごとの設定は<code>HKEY_CLASSES_ROOT\SystemFileAssociations</code>にある（編集時は<code>HKEY_CURRENT_USER\Software\Classes\SystemFileAssociations</code>を使うのがいいだろう）（比較的新しいWindowsだと<code>HKEY_CURRENT_USER\Software\Classes\SystemFileAssociations</code>キー自体が存在しないことがあるが、自分で作ればちゃんと動作する）。<code>command</code>キーは<code>HKEY_CURRENT_USER\Software\Classes\SystemFileAssociations\.xxx\shell\yourcommandname\command</code>のような場所に作られることになる。

また、全てのファイルを対象にするメニューは<code>HKEY_CLASSES_ROOT\SystemFileAssociations\*</code>、フォルダを右クリックしたときのメニューは<code>HKEY_CLASSES_ROOT\Directory</code>、ドライブ（C:\など）を右クリックしたときのメニューは<code>HKEY_CLASSES_ROOT\Drive</code>、フォルダ（・ドライブ）の背景（何もないところ）を右クリックしたときのメニューは<code>HKEY_CLASSES_ROOT\Directory\Background</code>以下でそれぞれ管理されている。また、<code>HKEY_CLASSES_ROOT\AllFilesystemObjects</code>というのもあり、これはディレクトリとファイルの両方に適用される（ドライブやフォルダ背景には影響なし）。

* 一覧は[https://learn.microsoft.com/ja-jp/windows/win32/shell/reg-shell-exts ここ]かな？


==== 複数種類に一括で追加？ ====

<code>HKEY_CLASSES_ROOT</code>には<code>PerceivedType</code>という値があり、これに<code>video</code>などと指定されている場合は<code>HKEY_CLASSES_ROOT\SystemFileAssociations\video</code>にある設定が反映される（これによって複数種類のファイルに共通するメニューが作れる）…というような情報もあったのだが、手元のWindows 11では全く反映されなかった。

そもそも<code>PerceivedType</code>に複数種類が指定できるか不明だったりと色々と意義が怪しいので諦めて各拡張子ごとに追加するのがよいのではないかと思う。CLSIDの部分は共通化されているわけなのでそれほど非効率な二重管理ということにもならないだろう。（そもそもこの辺のWindowsの仕様はころころ変わるっぽいのであまり頑張ってもしょうがないかも？）


=== Directory\Backgroundの表示 ===

エクスプローラーの左側のエリアにあるフォルダやドライブを右クリックしたときのメニューには、なぜかDirectory\Backgroundの内容も表示されてしまう。そのうえ、これらには正しくパラメータが渡されない（commandに直接書くときは<code>%V</code>などが入っていると起動せず、COM使用（少なくともDelegateExecute）で受け取る方法も不明）。

ただ、DirectoryやDriveに同名のメニューが登録されている場合はそちらが優先される。しかし、これを利用してメニューを非表示にすることはできない。（DirectoryやDriveのほうにLegacyDisableを書いたら、そもそもそちらが無かったのと同じになるっぽい）

実際には、Directory\Backgroundに設定するメニューはDirectoryにもDriveにも等しくあったほうがいい場合が多いと思うので、そのように設定するとよいだろう。

=== その他設定項目 ===

本筋とは関係ないので詳細は省くが、その他にもこれらのキーでは様々な設定ができる。

* <code>Icon</code>によるアイコンの設定
* <code>&</code>によるキーの設定（「"編集(E)"のEみたいなやつ」）
* <code>MUIVerb</code>（多分、言語設定ごとの表示文字列の切り替えとかができるようになるやつ）
* <code>AppliesTo</code>、<code>DefaultAppliesTo</code>による表示条件の設定
** AQS書式というのが使用可能で、かなり柔軟な指定ができる（特定フォルダ内のみに表示するなど）。ただしあまり情報がなく、[https://www.pg-fl.jp/program/winreg/classes.htm Windows レジストリ解剖記]でもそこまで詳細な解説はない。そこからもリンクされている[https://learn.microsoft.com/ja-jp/windows/win32/search/-search-3x-advancedquerysyntax?redirectedfrom=MSDN MSの公式ドキュメント]を読むのが早そう。あと、Backgroundメニューではそもそも背景フォルダに関する情報が全く渡されてこないようで（ただしどこかに書いてあったのではなく実験の結果）、使い物にならない。
*** Backgroundでは使えなかったという投稿の例
**** [https://superuser.com/questions/1020415/windows-explorer-context-menu-to-a-especific-folder-background Windows Explorer: Context menu to a especific folder (background) - Super User]
**** [https://stackoverflow.com/questions/47325736/windows-context-menu-directory-background-appliesto shell - Windows context menu directory\background AppliesTo - Stack Overflow]
* <code>HasLUAShield</code>による「管理者アイコン」の表示（<code>Icon</code>との併用可）
** これも実は上と同様にAQS書式で管理者アイコンの表示条件を設定できる
** このアイコン自体はSystem32のimageres.dllとかUserAccountControlSettings.exeとかに入っている
* <code>SubCommands</code>によるサブメニューの登録
** 手元のWindows11で試した限り、<code>Directory</code>や<code>Drive</code>ではうまくいくが<code>Directory\Background</code>だとサブメニューが出ない？
* <code>ExtendedSubCommandsKey</code>値による他の<code>shell</code>キーへの参照によるサブメニューの登録
** かなり強力で、循環参照も作れる。
** 例: [http://nonsubject.arinco.org/2011/08/ Nonsubject: 8月 2011]
** 一つのルートメニューが持てるサブメニュー上限は16個までという制限がある。[https://stackoverflow.com/questions/48625223/is-there-a-maximum-right-click-context-menu-items-limit https://stackoverflow.com/questions/48625223/is-there-a-maximum-right-click-context-menu-items-limit]
** これは<code>Directory\Background</code>でも有効。
* <code>Extended</code>によってShift+右クリックしたときのみ表示させる
* 設定例: [https://www.tenforums.com/tutorials/178668-add-remove-open-windows-terminal-administrator-context-menu.html Add or Remove 'Open in Windows Terminal as administrator' context menu | Tutorials]


=== ContextMenuHandlers（IContextMenu）を用いた実装 ===

{{Valuable}}

先ほどのClipchampのメニュー項目などはここまで述べたようにレジストリ内に静的に設定されているものではなくCOM(Component Object Model)を用いて外部のDLLの関数から動的に追加されているものである（ただDLLの指定自体はレジストリ内のInProcServer32のようなキーにあるはず）。Clipchamp以外だと7-ZipやPDF XChange Editorなどのメニューはこれを用いて実装されている。レジストリの<code>XXX\shellex\ContextMenuHandlers</code>といったキー以下に設定されているものはこれに分類される。

詳しくはIContextMenuなどのキーワードで検索すると出てくる[https://learn.microsoft.com/en-us/windows/win32/shell/shortcut-menu-using-dynamic-verbs Customizing a Shortcut Menu Using Dynamic Verbs - Win32 apps | Microsoft Learn]などを読むとよさそうだが、実装はかなり難解である。Clipchampもこの部分で不適切な実装をしたために順番がおかしくなったのではないかと思われる。

動作確認できたサンプルとしては、[https://github.com/microsoft/Windows-classic-samples/tree/main/Samples/Win7Samples/winui/shell/appshellintegration/NonDefaultDropMenuVerb https://github.com/microsoft/Windows-classic-samples/tree/main/Samples/Win7Samples/winui/shell/appshellintegration/NonDefaultDropMenuVerb]はIContextMenuを使って実装されており、dllをビルドしてCLSIDのInProcServer32でそれを指定するとちゃんと右クリックメニューが追加される。

また、メニューを追加する関数であるQueryContextMenuが呼ばれる時点で、引数となっているファイルの情報がわかる（Initialize関数においてIDataObjectが渡されているのでそれをクラスのフィールドなどとして持っておけばよい）ので、特定の拡張子のファイルのみに対してメニューを表示することもできる。もちろんファイルの内容まで読み取ってからメニューを表示するといったこともできるが、そこまですると右クリックするだけで動作が重くなるといった副作用が大きくなるのでやめた方が無難だろう。ただ、スタートメニューへのピン留め<code>{a2a9545d-a0c2-42b4-9708-a0b2badd77c8}</code>やPDF XChange Editor(9.3や10.2.1で確認)のメニューは実際にそのような挙動をする（余談だが、InfoTipの表示もexplorerが操作しづらくなる原因なのでshowinfotipを0にしたほうがいい）（サムネイルなどはバックグラウンドで並列に走るので操作にはあまり影響がない）。またエラーが発生した場合はexplorer自体が強制終了することもあり、全体的に実装は慎重に行ったほうがよい。

==== コード例 ====

拡張子が.tで始まるファイル（*.txt, *.ttfなど）のみにメニューを追加するサンプル（から抜粋）。

<syntaxhighlight lang="c++">IFACEMETHODIMP CNonDefaultDropMenuVerb::QueryContextMenu(HMENU hmenu, UINT indexMenu, UINT idCmdFirst, UINT /*idCmdLast*/, UINT /*uFlags*/)
{
FORMATETC fmte = { CF_HDROP, NULL, DVASPECT_CONTENT, -1, TYMED_HGLOBAL };
STGMEDIUM medium;
HRESULT hr = _pdtobj->GetData(&fmte, &medium);
if (SUCCEEDED(hr))
{
HDROP hdrop = (HDROP)medium.hGlobal;
WCHAR szFile[MAX_PATH];
DragQueryFile(hdrop, 0, szFile, ARRAYSIZE(szFile));
const WCHAR* ext = wcsrchr(szFile, L'.');
ReleaseStgMedium(&medium);
if (ext && *(ext+1) != L't') {
return MAKE_HRESULT(SEVERITY_SUCCESS, 0, 0); // Add nothing
}
}
else
{
return MAKE_HRESULT(SEVERITY_SUCCESS, 0, 0); // Add nothing
}

WCHAR szMenuItem[80];

LoadString(g_hinst, IDS_CHECKDROP, szMenuItem, ARRAYSIZE(szMenuItem));
InsertMenu(hmenu, indexMenu++, MF_BYPOSITION, idCmdFirst + IDM_CHECKDROP, szMenuItem);

LoadString(g_hinst, IDS_CHECKNETRESOURCES, szMenuItem, ARRAYSIZE(szMenuItem));
InsertMenu(hmenu, indexMenu++, MF_BYPOSITION, idCmdFirst + IDM_CHECKNETRESOURCES, szMenuItem);

return MAKE_HRESULT(SEVERITY_SUCCESS, 0, (USHORT)(2)); // indicate that we added 2 verbs.
}</syntaxhighlight>
* 特定の拡張子に対して追加できるのは以下で知った
** できるという情報 
[https://stackoverflow.com/questions/43769772/how-to-add-context-menu-to-one-specific-file registry - How to add context menu to one specific File - Stack Overflow]
** 実際のコード 
[https://github.com/nyfair/freeimagerip/blob/master/plugin/FIShellExt/Thumb.cc freeimagerip/Thumb.cc at master · nyfair/freeimagerip]


==== IContextMenuの今後について ====

Windowsの右クリックメニューが重いと良く言われるのはこのような高い自由度をもつIContextMenuに起因するものであると思われる。Windows11ではIContextMenuよりIExplorerCommandがよいというのを見かけた（[https://twitter.com/kenichiuda/status/1417266893581295651 https://twitter.com/kenichiuda/status/1417266893581295651]や、そこで引用されている[https://twitter.com/madonomori/status/1417265763363168263 https://twitter.com/madonomori/status/1417265763363168263]）。[https://github.com/microsoft/Windows-classic-samples/tree/main/Samples/Win7Samples/winui/shell/appshellintegration/ExplorerCommandVerb https://github.com/microsoft/Windows-classic-samples/tree/main/Samples/Win7Samples/winui/shell/appshellintegration/ExplorerCommandVerb]も見てみる必要があるかも。

ただまあMicrosoftのことなのでIContextMenuもあと10年くらいは使えるだろう。

* [https://learn.microsoft.com/ja-jp/windows/apps/get-started/make-apps-great-for-windows#8-optimize-your-apps-context-menu-extensions-and-share-targets Windows 11 でアプリをすぐれたものにするためにできることトップ 11 - Windows apps | Microsoft Learn] を読んだら、Windows 11の（新しい）右クリックメニューに表示するためにはIExplorerCommandを使わなければならない（IContextMenuは不可）と明確に書いてあった。また、IExplorerCommandのサンプル（[https://learn.microsoft.com/ja-jp/windows/win32/shell/samples-explorercommandverb エクスプローラーコマンド動詞のサンプル - Win32 apps | Microsoft Learn]）を使ってみたが、IExplorerCommandState（CommandStateHandler）のほうは動作しているように見えるものの肝心のIExplorerCommand（ExplorerCommandHandler）は全く反応しなかった（右クリックを一度でも行うとdllへの上書きアクセスが禁止されるので読み込まれてはいるようだが、コンストラクタや<code>QueryInterface</code>にデバッグ用のメッセージボックスを入れても表示されない）。

==== サブメニュー ====

IContextMenuは自由度が高いのでサブメニューなども実装できるはず（7-Zipなどもそうしていると思われる）。またこのような記事もあった: [http://nonsubject.arinco.org/2014/06/cascading-desktopbackground-menus.html デスクトップのシェルメニューをサブメニューにする | Nonsubject]


=== Windows11の右クリックメニューへの追加 ===

これはどうやらますます面倒になりそうで、リリース済のWindowsストアアプリをインストールするか開発者モードを有効にしないと自分の好きなメニューを追加できない（多分）上、アプリ1つにつき1メニューしか追加できないらしい。

<ul>
<li>Windows 11の右クリックメニューに追加してくれるソフト
[https://github.com/ikas-mc/ContextMenuForWindows11 https://github.com/ikas-mc/ContextMenuForWindows11]
フォルダ背景を右クリックしたメニューに追加できない（[https://github.com/ikas-mc/ContextMenuForWindows11/issues/44 https://github.com/ikas-mc/ContextMenuForWindows11/issues/44]）（いや、使ってみたら普通にできてるっぽい？）、アプリ1つにつき1メニューしか追加できない（[https://github.com/ikas-mc/ContextMenuForWindows11/issues/45 https://github.com/ikas-mc/ContextMenuForWindows11/issues/45]）（これはWindows側がそういう仕様っぽいので厳しそう）</li>
<li>Microsoftの関連するサンプル 
[https://github.com/microsoft/AppModelSamples/tree/master/Samples/SparsePackages AppModelSamples/Samples/SparsePackages at master · microsoft/AppModelSamples]</li>
<li>Meryへの追加要望
[https://www.haijin-boys.com/discussions/6746 Windows 11の新コンテキストメニューにMeryのコマンドを追加したい]</li></ul>


== 解決策①COMを利用する ==

{{Valuable}}

まずは、COMを用いて実装するという方法がある。基本的にはこちらが綺麗な解決策である。

IExecuteCommandというインターフェースを具体的に実装している[https://learn.microsoft.com/en-us/windows/win32/shell/samples-executecommandverb Microsoftのサンプル]があったので、それを参考に、「任意コマンドを引数にとり、取得したファイル・フォルダの情報をそのコマンドの標準入力にUTF-8で送信する」というプログラムを作成した。

[https://github.com/ge9/ExecuteCommand-Pipe https://github.com/ge9/ExecuteCommand-Pipe]

COMを使っていることからわかるように、コマンドラインを介さず直接Explorerからデータが送られてくるので、他の方法に共通してみられるパス長さやファイル個数の制限が（事実上）皆無であり、非常に強力である。

{{Stub}}

=== 使い方 ===

詳しい使い方は上記レポジトリのREADMEも参照。

==== 基本 ====

引数となる（実際に起動したい）コマンドはレジストリキー

<code>HKEY_CURRENT_USER\Software\Classes\CLSID\{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}\LocalServer32</code>の既定の値で設定する。

その上で該当メニューに対応する<code>command</code>キー（レジストリの各所にある）に<code>DelegateExecute</code>という値を作成して<code>{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}</code>を書き込むことで起動できる（<code>command</code>の既定値よりも<code>DelegateExecute</code>が優先される）。


=== IDropTargetを用いた実装 ===

IExecuteCommandではなくIDropTargetというインターフェースを用いてもほぼ同じことができそうであった。対応するサンプルは[https://github.com/microsoft/Windows-classic-samples/tree/main/Samples/Win7Samples/winui/shell/appshellintegration/DropTargetVerb https://github.com/microsoft/Windows-classic-samples/tree/main/Samples/Win7Samples/winui/shell/appshellintegration/DropTargetVerb]である。IExecuteCommandとの機能的な違いはあまりよくわからないが、[https://learn.microsoft.com/en-us/windows/win32/shell/samples-droptargetverb https://learn.microsoft.com/en-us/windows/win32/shell/samples-droptargetverb]を読む限り、DropTargetのほうが古くからあるようである。CLSIDの登録までは同じだが、<code>command</code>のかわりに<code>DropTarget</code>キーを使用し、<code>DelegateExecute</code>値のかわりに<code>CLSID</code>値を使う（ソースを読めばわかる）。

== 解決策②プロセス間通信で頑張る ==

{{Valuable}}

「プロセス間通信を使って頑張る」という方法もある。要するに、コマンドとしては別々に渡されたとしても、既に立ち上がっているプロセスがあるときはそちらに投げて終了するようにすれば、一つのプロセスでまとめて開けるというわけである。

この部分を代わりにやってくれるものとしては[https://github.com/zenden2k/context-menu-launcher https://github.com/zenden2k/context-menu-launcher]がある。これを少し改善したフォークとして[https://github.com/KnIfER/SingleInstance-Launcher https://github.com/KnIfER/SingleInstance-Launcher]があり、さらに自分が64bit版のビルドを加えたものが[https://github.com/ge9/SingleInstance-Launcher https://github.com/ge9/SingleInstance-Launcher]にある。

ただ、これはCOMを使う方法とは違っていくつかの欠点がある。

* ファイル個数の上限
** ProgIDを使って開く場合には、選択個数がデフォルトで15個までに設定されており、これはMultipleInvokePromptMinimum値（詳しくは他サイト）の変更により増やせるが確実ではない（上限に諸説あり）。
** 独自メニューの場合は、"MultiSelectModel"を"Player"にすることでファイル数上限が100個になるが、それより大きくはできない。
* 長さ制限（260文字）を超えるパスをもつフォルダでは失敗する（詳しくは[[Windowsのパス長さ制限に関して|Windowsのパス長さ制限に関して]] を参照）。
* プロセス間通信を使っているため、起動時にラグがあったりすると、ごく稀に渡されたファイルの順番が乱れることがある。


=== SingleInstance-Launcher - 基本的な使い方 ===

上記GitHubリポジトリから実行ファイルをダウンロードしてどこか分かりやすい場所に置く。インストールなどは不要である。筆者がリリースした実行ファイルを信用できない・改変したいなどの場合はソースコードをどうぞ。言語はC++。ファイルの順番が乱れにくくなる改善など大歓迎。

README.mdにもあるが起動に用いる基本的な構文（レジストリに登録する値）は以下のようである（※ここでは64bit版を使うものとして説明しているが、32bit版でも全く同様）。

<syntaxhighlight lang="c">"C:\path\to\singleinstance_x64.exe" "%1" "C:\Program Files\path\to\app.exe" "$files" --si-timeout 1000 --option-to-app-1 --option-to-app-2</syntaxhighlight>
"C:\path\to\singleinstance_x64.exe"、"%1"、"C:\Program Files\path\to\app.exe"、"$files"の順番はおそらくこの通りである必要がある。その後にあるものはapp.exeにオプションとしてそのまま渡されるが、<code>--si-timeout n</code>に限り、singleinstance_x64.exeが解釈し、app.exeに渡されない。このオプションはSingleInstance-Launcherに対して次のファイルが渡されてくるのを待つタイムアウト期間をミリ秒で指定するものである。短すぎると、右クリックメニューの処理が遅い場合に途中で打ち切られてしまう可能性がある。長すぎると、その期間待つまでapp.exeは呼ばれないため、タイムラグが長く不便に感じる可能性がある。特に動作が重いPCでなければ1000（1秒）くらいにしておけば十分だろう。もう少し短くてもいいかもしれない。

%1や$filesの両側にダブルクォーテーションがないと、空白を含むファイル名を正しく扱えない。GitHubのサンプルでは付いていないものもあるので注意。
[[Category:IT]][[Category:Windows]]{{#seo:|title={{FULLPAGENAME}} - Turgenev's Wiki}}

Linuxのインストール

2025-05-06T04:36:12Z

Turgenev: Notion-MW

Linuxのインストールおよびその後の初期設定に関する情報。Windowsとの併用に関しては[[デュアルブート|デュアルブート]] も参照。

自分が使ったことのあるUbuntu（Debian系？）にしか通用しない話もあるかもしれないので注意。

{{Outdated}}


== ISO書き込み ==

インストールのためにはCD/DVDやUSB（フラッシュメモリでもHDD/SSDでも可）へのisoの書き込みが必要になる。書き込みソフトによってうまく起動したりしなかったりする（特にUSB？）ので色々なものを試すとよい。

==== 参考サイト ====

{{Outdated}}

参考サイト:[https://qiita.com/Jies_/items/9774ddd55d6b2070c268 https://qiita.com/Jies_/items/9774ddd55d6b2070c268]

[https://orumin.blogspot.com/2015/05/securebootlinux.html https://orumin.blogspot.com/2015/05/securebootlinux.html]

[https://ramsdenj.com/2016/08/29/arch-linux-on-the-surface-pro-4.html https://ramsdenj.com/2016/08/29/arch-linux-on-the-surface-pro-4.html]

[https://www.rodsbooks.com/refind/installing.html#winprob https://www.rodsbooks.com/refind/installing.html#winprob]

[http://penguin.tantin.jp/unstable/Ubuntu1610OnSurfacePro4.html http://penguin.tantin.jp/unstable/Ubuntu1610OnSurfacePro4.html]

== 初期設定全般 ==

[https://sicklylife.jp/ubuntu/2004/settings.html Ubuntu 20.04 LTSをインストールした直後に行う設定 & インストールするソフト] ここはよくまとまっていてわかりやすい。特に時計の設定とユーザフォルダ名変更はいつもやっている。


== Grub ==

* quiet splash は不要？（トラブル時に分かりづらいので）
** セキュリティ的にあったほうが良かったりもするんだろうか
* デザインはは[https://wiki.archlinux.jp/index.php/GRUB/%E3%83%92%E3%83%B3%E3%83%88%E3%81%A8%E3%83%86%E3%82%AF%E3%83%8B%E3%83%83%E3%82%AF#.E3.83.86.E3.83.BC.E3.83.9E 「テーマ」設定]で変えられる。大体dropboxリンクで配布されているが、2012年に投稿されたやつとかはだいたい404Not Foundだった。

==== 再インストール ====

archwikiとか[http://john1851.html.xdomain.jp/notes/ubuntu/repair-grub.html http://john1851.html.xdomain.jp/notes/ubuntu/repair-grub.html] とか[https://qiita.com/air-gh/items/4265cf4308114092a7a7 https://qiita.com/air-gh/items/4265cf4308114092a7a7] を見る

<ul>
<li>LiveCD(USB)からならchrootを使う必要がある。以下の通り
[https://wiki.ubuntulinux.jp/UbuntuTips/Others/ReinstallGrub2 https://wiki.ubuntulinux.jp/UbuntuTips/Others/ReinstallGrub2]
[https://qiita.com/TsutomuNakamura/items/04176b91d791de46142c https://qiita.com/TsutomuNakamura/items/04176b91d791de46142c]
[http://d.hatena.ne.jp/snsw/20101211/1292036382 http://d.hatena.ne.jp/snsw/20101211/1292036382]
[https://qiita.com/gpioblink/items/708b2a5add6c854965cf https://qiita.com/gpioblink/items/708b2a5add6c854965cf]
[https://guminote.sakura.ne.jp/archives/316 https://guminote.sakura.ne.jp/archives/316]
[https://qiita.com/NewGyu/items/49703922c2f35def43b9 https://qiita.com/NewGyu/items/49703922c2f35def43b9]
この一番下のやつが一番今後役に立ちそう（他のやつはmbrとかでやってるのも多そう）</li></ul>

==== トラブルなど ====

{{Outdated}}

<ul>
<li>NVIDIAのGPUが入っているPCでgrubが出るのにその先行かない（スプラッシュで止まるとか）時はnomodesetをつける（重要）</li>
<li>セキュアブート関係かわからないが、
<syntaxhighlight lang="plain text">error processing package grub-efi-amd64-signed (--configure):
subprocess installed post-installation script returned error exit status 1</syntaxhighlight>
というエラーが更新をインストールするたびに出たことがあった。これは[https://askubuntu.com/questions/763472/what-can-i-do-to-fix-this-error-on-grub-efi https://askubuntu.com/questions/763472/what-can-i-do-to-fix-this-error-on-grub-efi] の通りgrubパッケージを再インストールする。この際途中で、grubのブートローダーのファイルを消しますか？と聞かれて、めんどいので消さないことにしたりして、色々やったり再起動したりしたりしたらなんか治ったきがする。詳細忘れた。</li></ul>

== bcdedit ==

Win側でブート順をいじるためのコマンド。割と使う機会が多いので覚えておくとよい。特に<code>bcdedit /enum firmware</code>の出力結果を一通り理解しておくと安心。<code>bcdedit /set {fwbootmgr}</code>あたりもよく使う割に情報が少ない気がする。

[https://docs.microsoft.com/ja-jp/windows-hardware/manufacture/desktop/bcdedit-command-line-options?view=windows-11 https://docs.microsoft.com/ja-jp/windows-hardware/manufacture/desktop/bcdedit-command-line-options?view=windows-11]

が公式マニュアル

* Linux側で同じ場面で使うのはefibootmgr
* grubのエントリが消えたときはWinのをcopyするか、createするか（その際applicationはosloaderでもbootsectorでもよい？調べるとどっちも出てくる気がする）


== NVIDIA ==

{{Valuable}}

筆者による[https://turgenev.hatenablog.com/entry/2019/10/21/001851 NVIDIAドライバのLinuxへのインストール・トラブルシューティング総まとめ - turgenev’s blog]が参考になる。[https://zenn.dev/190ikp/articles/how_to_install_nvidia_drivers こちら]も良い。

== ブルーライトカット ==

{{Valuable}}

[https://turgenev.hatenablog.com/entry/2018/11/10/171257?_ga=2.83762325.2078320998.1590755417-2046136024.1578745817 ブログ]を参照。そちらでは~/.config/redshift.confを作成する方法を書いてしまったが、常に一定の値にしておきたいだけなら、わざわざそんなことをしなくても、redshift -x（補正を除去）したときに6500Kの値（デフォルトのcolorramp.cでは1.0 1.0 1.0になっている）になることを利用して、そこだけ1.0 0.9 0.6とかに変えてビルドしてスクリプトには./redshift -xだけ書けばよいかも。

==== モニターごとに適用 ====

一部のモニターだけに適用するには、crtcで指定する。ただしcrtcは割と不安定に変わってしまう感じがあるため、xrandrで表示されるoutputの名前（eDP-1とかHDMI-2とか）で指定したい。自分でxrandrの出力から計算するしかなさそう。(eDP-1での)例:

<syntaxhighlight lang="shell">#!/bin/sh
cd `dirname $0`
./redshift -x
CRTC=`xrandr --verbose | sed -n "/^eDP-1/,/^\tCRTCs:/p" | sed -n "s/^\tCRTC: *$[0-9]*$/\1/p"`
echo $CRTC
if [ -n "$CRTC" ]; then
./redshift -m randr:crtc=$CRTC -o
fi</syntaxhighlight>
なお、eDP-1に関するxrandrの出力のなかに<code>CRTCs:</code>というフィールドが出現するという仮定のもとにこのスクリプトは書かれていることに注意せよ。

これをディスプレイがつけ外しされるたびに実行する必要がある。自動でできる

{{Stub}}


== Wi-Fi ==

ワイヤレスはWinよりも4本立つ基準が厳しい気がする（速度に有意差はなさそう？調べたらubuntuだけネットワークが遅いという投稿自体はたくさんあったが…）


== 右Alt ==

xmodmapを使う [https://qiita.com/macinjoke/items/746c0c0adb74cfdeb9e7 https://qiita.com/macinjoke/items/746c0c0adb74cfdeb9e7]


== Wine ==

stagingを含む新しめのWineのインストール方法は公式サイトの「Download」を見るとわかる [https://wiki.winehq.org/Download https://wiki.winehq.org/Download]

== 自動起動 ==

パスに"~"が入ってると正しく展開されないかもしれない。/home/usernameを使ったほうがよい。


== (L)ubuntu限定っぽい話 ==

{{Outdated}}

自分がLubuntuを使っていた時期のメモをもとにしている。


==== HiDPI ====

~/.Xresourcesに

Xft.dpi: 180

を書き込むのが一番確実で手軽そう、Xorg.confは怖い

個々のソフトウェアで表示サイズを調節するのはキリがないのでやめたほうがいい

* HiDPI対応とかに関しては例えばLinux Mintのほうが優れているのかもしれない

==== スクロールの向き ====

スクロールの向きはデスクトップ環境の設定でも変えられるが根本のxの設定から変えたほうが良い。（[https://qiita.com/Buuuchi408/items/35dce365ce4a00c947c3 https://qiita.com/Buuuchi408/items/35dce365ce4a00c947c3]）synclient

を実行し、その結果のVertScrollDeltaとHorizScrollDeltaを負の値にする。そして

#!/bin/sh

synclient VertScrollDelta=-43

synclient HorizScrollDelta=-43

を自動起動に登録。

==== ウインドウ ====

ウインドウの端が狭すぎて動かしにくいので

[https://askubuntu.com/questions/833950/size-of-grab-area-for-resizing-window-in-lubuntu https://askubuntu.com/questions/833950/size-of-grab-area-for-resizing-window-in-lubuntu]

に書かれているとおりにやる。ただ、見た目の幅も変わってしまうのであまり美しくない。Alt+右ドラッグで端を持っていなくてもリサイズできるので慣れればそのほうがラクそう 
あとはマウスカーソルのテーマを変えるとやりやすくなる。DMZみたいなテーマがいい

* そもそも別のデスクトップ環境を選んだ方がいい


== Surface Pro 4にLubuntuを入れる ==

{{Outdated}}

Surfaceはハードウェアが色々と独自仕様で、キーボードは動くけどタッチとかはできないので修正のため[https://github.com/linux-surface/linux-surface linux-surface/linux-surface: Linux Kernel for Surface Devices]をインストールする（昔は[https://github.com/jakeday/linux-surface jakeday/linux-surface: Linux Kernel for Surface Devices]だった）。サイトが丁寧。

<ul>
<li>※以下リンク切れ多数</li>
<li>筆者による[https://turgenev.hatenablog.com/entry/2019/01/17/004545 Surface Pro 4でlubuntu 18.04を使う - turgenev’s blog] も参照（そちらも古い）</li>
<li>shim-signedパッケージのエラーがaptやるたびにでてるのは
[https://github.com/jakeday/linux-surface/commits/master/SIGNING.md https://github.com/jakeday/linux-surface/commits/master/SIGNING.md]
（現在は最新版が削除されているので[https://github.com/jakeday/linux-surface/blob/a39cc29295318894d624977a107c0999cc0ef6ac/SIGNING.md こちら]）に従ってブートローダーに署名すれば良いっぽい
<ul>
<li>ubuntu系に関しては [https://github.com/berglh/ubuntu-sb-kernel-signing https://github.com/berglh/ubuntu-sb-kernel-signing] を使うのが楽そう。設定項目は基本的にはデフォルトのままで進めればいいと思うが、MokManagerに関するものだけなぜかデフォルトがNoになっているのでこれはYesにしたほうがいい。</li></ul>
</li>
<li>タッチパネルをすばやく操作すると反応しなくなることがある。その時は[https://github.com/jakeday/linux-surface/issues/55 https://github.com/jakeday/linux-surface/issues/55]に記載の通り、
rmmod intel_ipts
modprobe intel_ipts
とすれば治る。いちいち打つのは面倒なのでキーボードショートカットにするが、root権限がいるので、root権限無しで実行できる特例としてシェルスクリプトを作り（[https://askubuntu.com/questions/821919/how-do-i-add-sudo-commands-to-a-keyboard-shortcut How do I add sudo commands to a keyboard shortcut? - Ask Ubuntu]など参照）、ホットキー登録する。
<syntaxhighlight lang="shell">USERNAME ALL=(root) NOPASSWD: /usr/local/bin/set-kbd-backlight</syntaxhighlight></li></ul>


==== 蓋（キーボード）、ハイバーネート ====

デフォルトではカバーを閉じるとハイバーネートするようになっているがSurfaceだと起動しなくなってしまう。これは/etc/systemd/logind.confのHandleLidSwitchで設定するのだが、ignoreかpoweroffならとりあえずうまく機能する。lockだとダメでlightdmをrestartする羽目になる。

* 何とかハイバーネートができないかとしばらく頑張ってみたが自分の環境ではあまりうまく動かなかった。たまーに成功した。
[[Category:IT]]{{#seo:|title={{FULLPAGENAME}} - Turgenev's Wiki}}

Windowsにおける仮想的ディスプレイ

2025-05-06T04:36:07Z

Turgenev: Notion-MW

例えばZoomでプレゼンテーションをするときに、PowerPointの「発表者ツール」を使いたければ、普通は2つのディスプレイが必要である。しかしディスプレイが常に2つあるとは限らないので、画面共有に使用するだけの「仮想的なサブディスプレイ」があればいいのではないか、という発想がうまれる。他には、リモートのみで使用するPCや、ゲーム画面の配信などにおいても需要があるようである。


== 解決策1 - ダミープラグ ==

そこそこ普及している、ハードウェア的な解決策である。端子に差し込むとディスプレイが接続しているものと誤認させることができる。EDIDエミュレータとも呼ぶ？価格は500-1000円程度。4K対応かどうかなどスペックにより値段に多少の差はあるだろう。近年はHDMIが主流と思われるが、VGAのものもある（こちらは自作が可能との情報も）。

金はかかるが、後者の解決策にないメリットとして、一気に複数のOSに対応できる（製品による？）というのがある。


== 解決策2 - ソフトウェア的に ==

しかしPCを騙すためだけの虚構的な存在に金を払うのも考えれば面白くない話である。ソフトウェア的に解決できないだろうか。ということでこの記事ではWindowsに対するソフトウェア的解決策を紹介する。なおLinuxについてはxvfb?だとか、そういうのを使えばできそうな気がしたが今のところ手元ではできていない。できたら記事を書くかも。Macは持っていないので試せないが、[https://github.com/tSoniq/displayx https://github.com/tSoniq/displayx]とか、betterdisplayとかがあるらしい。PowerPointやゲーム実況という用途を考えるとWindowsが一番需要が大きそうではある。

ソフトウェア的解決策が欲しいといってすぐソフトが出てくればいいが、調べてもあまり出てこない。比較的それっぽくて怪しくなさそうだったのが

[https://www.amyuni.com/forum/viewtopic.php?t=3030 https://www.amyuni.com/forum/viewtopic.php?t=3030]

だが、それでもやはりちょっと素性が知れない。もう少し調べていくと、Indirect Display Driver (IDD)という技術を使うとそういうソフトウェアが書けるというMicrosoftのドキュメントが出てきた。そこからさらに調べてみるとこんなものがあった。

[https://github.com/roshkins/IddSampleDriver https://github.com/roshkins/IddSampleDriver]

これを試したら無事動いたので、ついでに解像度を変えてみたら、普通に8Kくらいまで動いた（ただしその分重くなる）。↑のレポジトリでも解像度増やしてというissueがあったので、forkして公開した。さらにver0.0.1.2では"C:\IddSampleDriver\option.txt”というファイルを設定することで解像度オプションやディスプレイの個数をユーザーが設定できるように変更した。

[https://github.com/ge9/IddSampleDriver https://github.com/ge9/IddSampleDriver]

本家のreadmeで紹介された結果、どうやらゲーム配信関係のRedditとかに載ったみたいで、実質的にはほぼ何もしていないのに800以上のstarを獲得している。

また、さらにこれをforkしたものとして[https://github.com/VirtualDrivers/Virtual-Display-Driver https://github.com/VirtualDrivers/Virtual-Display-Driver]が作られ、これはすでに5000starを超える大きなプロジェクトになっている。

以下、このソフトの話を主にしていく。

== インストール手順 ==

Scoopを使う方法と使わない方法の2種類がある。いずれもリポジトリのREADME.mdに書いてある通りで、それほど難しくはない。


==== Scoopを使う ====

筆者がかかわったものではないが、Scoopを用いてインストールができるようにしてくれた方がいるようである。インストールを行うスクリプトのソースコードは[https://github.com/ScoopInstaller/Nonportable/blob/master/bucket/iddsampledriver-ge9-np.json https://github.com/ScoopInstaller/Nonportable/blob/master/bucket/iddsampledriver-ge9-np.json]にある。

==== 通常のインストール ====

途中で、バッチファイルを用いて証明書（.cerという拡張子のファイル）をローカルコンピューターの「信頼されたルート証明機関」に登録する必要がある。そのバッチファイルではcertutilが使用されている（ちなみに以前のリリースではcertmgrが使用されていた）が、証明書を開いて表示される画面からの操作などによっても可能である。

登録を行わないと、デバイスマネージャで「このドライバーはデジタル署名されていません。」と警告が出て、最終的に「デバイスをインストール中にエラーが発生しました。」「ストアへドライバーを追加する際に問題が発生しました。」と言われて失敗する。

<ul>
<li>参考
[https://docs.microsoft.com/ja-jp/windows-hardware/drivers/install/installing-test-certificates https://docs.microsoft.com/ja-jp/windows-hardware/drivers/install/installing-test-certificates]
[https://garafu.blogspot.com/2014/04/blog-post.html https://garafu.blogspot.com/2014/04/blog-post.html]</li></ul>

== 開発者向け情報 ==

Indirect Display DriverについてはMicrosoft公式のドキュメントや公式サンプル[https://github.com/microsoft/windows-driver-samples/tree/master/video/IndirectDisplay https://github.com/microsoft/windows-driver-samples/tree/master/video/IndirectDisplay] を参照（IddSampleDriverはこれを編集してできたようである）。前述の通り自分は解像度を増やしただけなので技術的なことについては何もわかっていない。

公式サンプルはなんといっても公式のものであるから、まずはこれをビルドできる状態にするのが確実だろう。以下の説明は2021年8月頃にWindows10で試したときのものである。ビルドしようとするとWindowsUserModeDriver10.0がないと言われるので、[https://docs.microsoft.com/ja-jp/windows-hardware/drivers/download-the-wdk https://docs.microsoft.com/ja-jp/windows-hardware/drivers/download-the-wdk] を入れる。

すると次は「Spectre軽減策」（セキュリティ関係？）に関するエラーが出た。そこでVisual Studioのインストール時の「個別のコンポーネント」→「コンパイラ、ビルドツール、およびランタイム」のところから「最新」「（ARMではなく）x86とx64」と書いてある「Spectre軽減ライブラリ」を入れる（細かい表示は正確に記録していないかもしれないor変わっているかもしれない）。「SDK、ライブラリ、およびフレームワーク」にあるMFCとかATLみたいなやつは要らなさそうっぽい。

これでビルドが通った。exeを管理者権限で起動するとBluetoothのところのその他のデバイスとかに表示されるところまではいった。tmhがないとかSpectre関連のエラーとかwdfのエラーとか色々出ていたが全部大丈夫になった。

* [https://learn.microsoft.com/ja-jp/windows/win32/api/swdevice/nf-swdevice-swdevicecreate https://learn.microsoft.com/ja-jp/windows/win32/api/swdevice/nf-swdevice-swdevicecreate]に書いてあるように、SwDeviceCreateを呼びだすには管理者権限が必要である。従って、IddSampleDriverのようなソフトウェアをインストールするには管理者権限が事実上必須ということになる。ただし、インストールされたIddSampleDriverというデバイス自体は一般ユーザーでも使用可能である。

では次に本題のIddSampleDriverをビルドする。公式サンプルがビルドできている状況ならこちらも通るものと期待できる。少なくとも手元ではそうなった。逆にIddSampleDriverから始めてみても同様に、WindowsUserModeDriver10.0のエラー→Spectreのエラー、などとなった。

以下、当時の元リポジトリをビルドした際のメモ

* ソースコードに赤線は出ていたがコンパイルは通る。署名に関するエラー（file digestがなんとか）が出るのでプロジェクトのプロパティの下のほうのDriver SigningのFile Digest Algorithmに SHA256 と書く。
* 解像度やリフレッシュレートの設定が不適切だと、デバイスマネージャで何度か再読み込みされる感じの動作をしたあと自動的に停止され警告アイコンが表示される。
* 日付を超えるとタイムゾーン（筆者はJST=UTC+9）の関係でInf2Catが失敗する。プロジェクトのプロパティからInf2Catのメニューに行き、General → Use Local Time を「はい (/uselocaltime)」に設定する。参考: [https://monoist.atmarkit.co.jp/mn/articles/1307/26/news003_3.html https://monoist.atmarkit.co.jp/mn/articles/1307/26/news003_3.html]
** さらに、これを設定してもなぜか現地時間の21:00～24:00の間にビルドしたものは正常動作しなかった（ビルドは通るしデバイスマネージャでの警告アイコンも出ないのにサブディスプレイが出ない）ので、ビルド時はその範囲外になるようにPCの時計設定を適宜変更する（報告済み [https://github.com/roshkins/IddSampleDriver/issues/5 https://github.com/roshkins/IddSampleDriver/issues/5]）

自分でビルドしたやつのインストール時は、（おそらく自分のユーザー名を用いて署名が作られているため？）最初の一回のみ改めて.cerを登録する必要がある。二回目以降は、サブフォルダに生成されてるcat, dll, infをもってきて置き換えたあとデバイスマネージャから「ドライバーの更新」をすればよい。デバイスマネージャーは使ったフォルダをちゃんと覚えているようなので、頻繁に移動しなくていい安定した場所でビルドを行うのがいいだろう。


== HDR対応について ==

* HDRの基本についてはここがよさそう？ [https://zenn.dev/okuoku/scraps/ca346768627367 https://zenn.dev/okuoku/scraps/ca346768627367]

GitHubのissueでも複数回挙がっているのが、HDR (High Dynamic Range)への対応であるが、現在のところ解決の目処は立っていない。

* IDDの枠組みではそもそもサポートされてない？ 
[https://github.com/MicrosoftDocs/windows-driver-docs-ddi/issues/199 https://github.com/MicrosoftDocs/windows-driver-docs-ddi/issues/199]
* 報奨金を設定した人がいる 
[https://github.com/5andr0/Virtual-HDR-Display/issues/1 https://github.com/5andr0/Virtual-HDR-Display/issues/1]

=== その他参考情報 ===

このIDDというのはUser-modeで動作するやつなのだがKernel-modeで動作するKMDODとかいうものもあるらしく、そっちの方が多くのことができるのかもしれない。ただし調べた感じ、ただちに使えそうなものは見つからなかった。まあWindowsのディスプレイドライバなんか趣味でそうそう書くもんではないのでしょうがない。

一応適当に調べて出てきた参考リンクなど

* IDDとKMDODに関する議論（2019年） 
[https://community.osr.com/discussion/291368/wddm-display-only-driver-to-create-a-virtual-display-monitor https://community.osr.com/discussion/291368/wddm-display-only-driver-to-create-a-virtual-display-monitor]
* KMDODで仮想ディスプレイを作れるかどうかについて(2017年) 
[https://community.osr.com/discussion/286843/how-to-implement-virtual-display-adapter https://community.osr.com/discussion/286843/how-to-implement-virtual-display-adapter]
** そこで言及されているLin JiaBang氏のソフト（動作未確認） 
[https://github.com/LinJiabang/virtual-display https://github.com/LinJiabang/virtual-display]
* WDDMで仮想ディスプレイを作れるかどうかについて（2016年） 
[https://social.msdn.microsoft.com/Forums/vstudio/ja-JP/2d60c1c2-5198-47e2-b5d9-2ba28461e72e/how-to-implement-virtual-display-adapter-driver-on-windows-10?forum=wdk https://social.msdn.microsoft.com/Forums/vstudio/ja-JP/2d60c1c2-5198-47e2-b5d9-2ba28461e72e/how-to-implement-virtual-display-adapter-driver-on-windows-10?forum=wdk]

== 課題 ==

あくまで仮想的なディスプレイであるからその中身を目視で確認することはできない（ただし別途その内容をウインドウに表示するソフトなどは作れそう）。従って例えば、これを使って共有している間にZoomのミーティングコントロールが非表示になってミュートのon/offなどができなくなるなどの不便さはある。

ちなみに、Windowsでのマルチモニター管理を切り替えるメニューのショートカットはWin+Pであるが、ここで「セカンドスクリーンのみ」を選ぶなどして仮想でないほうのディスプレイが真っ暗になってしまったときはWin+Pを押せば復帰できる。

== 変更記録 ==

もともとディスプレイは5個追加されるが、重過ぎるのでNUM_VIRTUAL_DISPLAYSを1に変更。

解像度を大きくしたいのでソースコードを「1920」で検索し、3840x2160と2560x1440を追加する。

まず s_KnownMonitorModes のところ。この際リフレッシュレートが60HzになるようにPixel Clock Rateをちゃんと計算する必要がある。

<syntaxhighlight lang="c++">{
229008 * KHZ, // pixel clock rate [Hz]
{ 229008 * KHZ, 2560 + 40 }, // fractional horizontal refresh rate [Hz]
{ 229008 * KHZ, (2560 + 40) * (1440 + 28) }, // fractional vertical refresh rate [Hz]
{ 2560, 1440 }, // (horizontal, vertical) active pixel resolution
{ 2560 + 40, 1440 + 28 }, // (horizontal, vertical) total pixel resolution
{ { 255, 0 }}, // video standard and vsync divider
DISPLAYCONFIG_SCANLINE_ORDERING_PROGRESSIVE
},
{
509366 * KHZ, // pixel clock rate [Hz]
{ 509366 * KHZ, 3840 + 40 }, // fractional horizontal refresh rate [Hz]
{ 509366 * KHZ, (3840 + 40) * (2160 + 28) }, // fractional vertical refresh rate [Hz]
{ 3840, 2160 }, // (horizontal, vertical) active pixel resolution
{ 3840 + 40, 2160 + 28 }, // (horizontal, vertical) total pixel resolution
{ { 255, 0 }}, // video standard and vsync divider
DISPLAYCONFIG_SCANLINE_ORDERING_PROGRESSIVE
},</syntaxhighlight>
のようにする。Pixel Clock Rateの数値は多少のズレがあってもいいみたい？だけど気分的に少しだけ大きめに設定してある。

そのすぐ下のEDIDのところはそのままでよさげ。

そして、一番下のほうのTargetModesのところを変える。配列サイズの変更も忘れずに。いやvectorだから関係ないか。

ちなみにs_KnownMonitorModesがノータッチだとここには1920x1280までしか書けないっぽい。


== EDID編集に関して（メモ） ==

HDR機能の追加に使えるかと思ったが結局効果はなかった。

Deltacast E-EDID Editorがふつうに有能。ここに書いてあった: [https://ameblo.jp/holycater/entry-12467348533.html https://ameblo.jp/holycater/entry-12467348533.html]

[https://www.ninshoshiken.com/about-ajsc1-edid-editor/ https://www.ninshoshiken.com/about-ajsc1-edid-editor/]

[http://blawat2015.no-ip.com/~mieki256/diary/201602063.html http://blawat2015.no-ip.com/~mieki256/diary/201602063.html]

[http://www.edidreader.com/ http://www.edidreader.com/]
[[Category:IT]][[Category:Windows]]{{#seo:|title={{FULLPAGENAME}} - Turgenev's Wiki}}

MediaWiki:Mobile.css

2025-05-06T01:01:14Z

Turgenev:

/* ここに記述した全てのCSSはモバイル版サイトの利用者に影響します */

MediaWiki:Mobile.css

2025-05-06T00:59:32Z

Turgenev: ページの作成:「/* ここに記述した全てのCSSはモバイル版サイトの利用者に影響します */ #catlinks { display: yes; }」

/* ここに記述した全てのCSSはモバイル版サイトの利用者に影響します */
#catlinks {
display: yes;
}

デュアルブート

2025-05-05T01:30:35Z

Turgenev: Notion-MW

{{Outdated}}

WindowsとLinuxのデュアルブートにおいて役に立つ情報を記述する。古いメモを多く含む。[[Linuxのインストール|Linuxのインストール]]も参照。


== Windowsのプロダクトキー関連 ==

{{UnderConstruction|デュアルブート}}


== Bitlocker ==

とにかく前もって回復キーを保存しておくこと！！逆に回復キーさえあればBitlockerで大きなトラブルになることは多くない。

* [https://www.pcdock24.com/blog/?p=53931 BitLockerとは【BitLockerの要件と自動有効化の問題点】｜パソコン修理パソコンドック24] によるとローカルアカウントでBitlockerの有効/無効を確認するときはdiskmgmtから行かなきゃいけないらしい。
* Bitlockerを有効にしたあとにwinを起動すると再起動ループにハマることがある。解決法(Manage-bdeを使う)→[https://community.spiceworks.com/how_to/124388-stop-a-bitlocker-boot-loop Stop a BitLocker boot loop - Windows Forum - Spiceworks]


== Windowsパーティション（NTFS）のマウント ==

{{Outdated}}

==== remove_hiberfileについて ====

マウントが成功するにはWindowsが完全シャットダウンされている必要がある（またはそれが望ましい）。ただ、[https://unix.stackexchange.com/questions/107978/cant-access-windows-drive-windows-is-hibernated-refused-to-mount https://unix.stackexchange.com/questions/107978/cant-access-windows-drive-windows-is-hibernated-refused-to-mount]にある通り、windowsを正しくシャットダウンしてもなぜか「ハイバーネートされててマウントできません」的なのが出ることがあるので、マウントオプションにremove_hiberfileを追加するとよい。

* 高速スタートアップを無効にしているにもかかわらず完全シャットダウンされていないことがある気がしたので、Windowsでシャットダウン時に実行するスクリプトとして完全シャットダウンコマンドを追加したりした
* デスクトップPCではだいたい不要？


=== Bitlocker無し ===

普通にntfs-3gを使う。数字など適宜読み替えること。主にWindowsのDドライブ想定。

<ul>
<li>コマンド例
<syntaxhighlight lang="javascript">ntfs-3g -o remove_hiberfile /dev/nvme0n1p5 /media/win</syntaxhighlight></li>
<li>fstabの例
<syntaxhighlight lang="javascript">/dev/sda2 /media/ddrive ntfs-3g noauto,rw,nofail 0 0</syntaxhighlight></li></ul>


=== Bitlocker有り ===

ntfs-3gの前にDislockerで暗号化を解除する。参考→[http://www7390uo.sakura.ne.jp/wordpress/archives/270 http://www7390uo.sakura.ne.jp/wordpress/archives/2]

dislocker-fileの方式だと一旦復号したのをファイルに書き出して静的にマウントするので、（事実上）readonlyとなる。よってdislocker-fuseを使う→[https://www.systutorials.com/docs/linux/man/1-dislocker-fuse/ https://www.systutorials.com/docs/linux/man/1-dislocker-fuse/]

<ul>
<li>コマンド例
<syntaxhighlight lang="vb.net">$ sudo dislocker-fuse -V /dev/nvme0n1p3 --recovery-password=xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx -- /media/dl-fuse
$ sudo mount -o loop,rw /media/dl-fuse/dislocker-file /media/win/</syntaxhighlight></li>
<li>fstab例
<syntaxhighlight lang="vb.net">/dev/nvme0n1p3 /media/bitlocker fuse.dislocker recovery-password=xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx 0 0
/media/bitlocker/dislocker-file /media/win10 ntfs-3g rw,nofail,remove_hiberfile,permissions 0 2</syntaxhighlight>
と、二行に分けて記載する。
<ul>
<li>permissions については後述</li></ul>
</li></ul>

==== セキュリティ問題 ====

recovery-passwordを暗号化されていないパーティションに書いてしまうと結局Bitlockerの意味が全くなくなってしまうので、Linux側でもBitlockerのような暗号化パーティション（LUKSとか？）やユーザーログイン時に復号される暗号化フォルダ（ecryptfsとか）といったディスク上で暗号化される領域に書いておく必要がある（もちろん毎回パスワードの類を打ち込むのでよければそれでもいい）。


=== permissions, inheritについて ===

[https://github.com/tuxera/ntfs-3g/wiki/File-Ownership-and-Permissions https://github.com/tuxera/ntfs-3g/wiki/File-Ownership-and-Permissions] 詳しくはこちらも参照。

まず、マウントオプションとしてpermissionsを指定しない限り、ntfs-3gでマウントしたファイルは全てパーミッション・所有者が固定（uid, gid, umaskなどで指定）となり、個別のファイルについて変更することはできない。

そして、この場合、ntfs-3g経由で作成したファイルはWindows側で見るとすべてAdministratorの所有となり、さらにEveryoneにフルコントロール権限が付与される（この動作を変更するのは筆者の知る限り不可能）。

Linuxではフォルダの実行権限（x）が無ければその中に含まれたファイルにはアクセスが通らず、パスを推測することも不可能だが、Windowsではたとえ一切権限のないフォルダであっても中にあるファイル・フォルダのパスがわかれば直接パスを打つことでアクセスが通ってしまうようである（試した限り）。そのため、permissions無しでntfs-3gで作成したファイルはパスさえわかればWindows上の全ユーザーが閲覧・編集・削除できる状態ということになる。

従って、Gitを使用する場合や複数ユーザーで使用したい場合などパーミッション管理が必要なデータを扱う場合はもちろん、単に中にあるデータを保護したいという場合でもpermissionsオプションを指定することが必須になる。

次に、permissionsを指定して、かつUserMappingを指定しない場合、Linux上でrootが所有するファイルをWindows側で見ると、全てAdministratorsの所有物になり（ここはpermissionsがない場合と同じ）、そのアクセス権はLinux上での見え方と概ね一致するように設定されるようである。他のユーザーが所有するファイルにはS-1-5-21-3141592653-589793238-462643383-10000というような上位桁が円周率に由来する（この部分はハードコードされている）SIDが割り当てられ、こちらもアクセス権が適切に設定される。UserMappingを指定することで、このSIDの部分の割り当てを変更することができる。

Windowsに挙動を近づけるための他のオプションとしてはinheritというのもあり、これは新規作成時に上位フォルダの権限を継承するものである。しかし、これは所有者を継承するオプションではない（そして、所有者が違えばまともに継承もされない）。

以上のことから、Windowsの一般ユーザーフォルダの内容などをLinuxから良い感じに（Windows側の権限設定を汚染せずに）使えるようにするには、明示的なUserMappingが事実上必須であることがわかる。

一方で、Administrator所有・全ユーザー閲覧可能（あるいは不可能）、といった、Windows側の全ての一般ユーザーに対して共通のアクセス権を適用する設定であれば、UserMappingを使用しなくても簡単に設定が可能である。個人用PCかつ、画像・動画などのメディアファイルやLinuxでしか使用しない大きめのソフトウェアを入れておく用途であれば、こちらで問題ないだろう。

Linux側で別ユーザーの所有に見せたい場合は、上記のS-1-5-21-3141592653-589793238-462643383-10000のようなSIDが見えてしまう状態でもよければ（かつ、権限設定にも問題がなければ）それでもいいし、下記のbindfsと併用する方法もある。いずれにしても、Linux側で全員が読み取り・書き込み・実行が可能なファイルは、Linux側での親フォルダの権限によらず、Windows側では（パスさえわかれば）対応する権限でアクセスができてしまうということに注意が必要である。

また、Windowsではファイルの新規作成時には必ず実行権限が付加されるので、Linux側でそれを見た場合も実行可能になる（実行権限を外すと.exeなどが実行できなくなる）。従って、GitのレポジトリのフォルダをWindows/Linux間で共用するようなことをすると、Windows側では実行権限無しで（これがデフォルトであるため）コミットされたファイルがLinux側では実行権限有りに見えるため差分が出てしまうといったことが発生する。これはUserMappingでも解決はできないので、Gitリポジトリのあるフォルダを共用するのは不可能である。

==== bindfs ====

既存のディレクトリを、所有ユーザーやパーミッションを変更してマウントしてくれる。

<syntaxhighlight lang="python">sudo bindfs --mirror=myname --force-group=myname /media/win ~/.mnt_win/</syntaxhighlight>
または

<syntaxhighlight lang="python">sudo bindfs --force-user=myname --force-group=myname /media/win ~/.mnt_win/</syntaxhighlight>
この2つの違いは不明

sudoがないと<code>fusermount: option allow_other only allowed if 'user_allow_other' is set in /etc/fuse.conf</code>とか言われたりする

fstabの例

<syntaxhighlight lang="python">/media/win /home/myname/.mnt_win fuse.bindfs nofail,map=root/myname:@root/@myname,create-with-perms=g-w 0 0</syntaxhighlight>
Linuxだとrootのデフォルトのumaskが022で一般ユーザーが002なせいで一般ユーザーが作ったファイルが775とか664になってしまったりするがg-wをつけることによって755とか644になる（もちろんchmodすれば変えられる


== Minecraft ==

.minecraftフォルダをWindowsとLinuxで共有したはいいが、（それ自体.minecraftの中にある）ゲームディレクトリの指定も共有することを考えると、両OSでパスの仕様がやや異なるのが問題になる。

例えば以下ではWindowsのルートが/media/winにマウントされているとする。

まずLinuxのランチャーは相対パスどころかシンボリックリンクすら変換して普通の絶対パスにしてしまう（設定を書き換えてしまう）っぽいので、linuxでは絶対パス指定で/media/win/Users/pathのようにする。で、この書き方をするとWindowsでは相対パスと解釈されるのだが、基準となるフォルダが謎で、「PLAY」を押した時のチェック時は.minecraftが基準なのだが、実際に見られるのはランチャーがあるフォルダが基準（＝こっちになかった場合ゲームディレクトリが新たに作られる）

* ストアアプリ版の（新しい方の？）Minecraftランチャーでは、この「ランチャーがあるフォルダ」は<code>AppData\Local\Packages\Microsoft.4297127D64EC6_8wekyb3d8bbwe\LocalCache\Local</code> あたりである。

従って、ランチャーのフォルダと.minecraft内の両方にmediaというフォルダを作って中にwinという名前でC:\へのジャンクション置くとうまくいく。

.minecraftの中にはゲームディレクトリ専用のフォルダを作り、その中にmain, snapshotなど用途に応じたフォルダを作っておくとよい

== google-drive-ocamlfuse ==

labelを使うと複数アカウントをマウントできる。デフォルトのラベル名はdefault

しばらく使っていないと起動時におそらく認証の失敗が原因でマウントポイントのあるフォルダに対するlsがしばらく一切反応しなくなる（~/.gdfuse内の該当ラベル名のフォルダを削除して最初からやり直せば治る）。よってマウントポイントをホームディレクトリ直下に作るのは避けたほうがよい（gdfというフォルダを作っている）。


== MEGA ==

Winが完全にはシャットダウンされていない状態でLinuxを起動するとCドライブ上のMEGAのフォルダが読めずに同期が無効になってしまう。MEGA自身のかわりに、Cが読める状態でのみMEGAを起動するシェルスクリプト（mega-mounted.sh）をスタートアップに登録しておく。Cが読めなかった場合にはdialogコマンドで通知ダイアログを表示する。（このスクリプトではC自身のかわりにC:\Windowsをみている）（gdialogは一部のディストリにしか入っていないかもしれない。実際にコマンド打ってみてどんな表示になるかも含めて確かめておいたほうがよい）

<syntaxhighlight lang="shell">#!/bin/sh
if [ -d /media/win-rw/Windows ]; then
megasync
else
gdialog --title "Warning" --infobox "MEGAsync is not started because Windows partition is not mounted" 0 0
fi</syntaxhighlight>

== Bluetooth機器 ==

同じBluetooth機器を同じPCのWindowsとLinux双方にペアリングするというもの。自分はマウスでしかやったことがない。意外と難しいが何とかなる。

==== 参考 ====

* [https://orumin.blogspot.com/2019/02/bluetooth.html https://orumin.blogspot.com/2019/02/bluetooth.html]
* [https://qiita.com/yoko-yan/items/9b0235678fd804b4fe0d https://qiita.com/yoko-yan/items/9b0235678fd804b4fe0d]
* Bluetooth Low Energyという仕様もあるらしく、自分のマウスはこっちだった。これに関しては[http://aimingoff.way-nifty.com/blog/2018/09/windows-linux-b.html http://aimingoff.way-nifty.com/blog/2018/09/windows-linux-b.html]を参照。割と情報が少ないので感謝。
** <code>HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTHPORT\Parameters\Keys\xxxxxxxxxxxx</code>を見るためにpstoolsをダウンロードして<code>PsExec64 -s -i regedit</code>とする必要があることに注意。なお、セキュリティソフトによってPsexecが脅威と見なされ強制削除されてしまうときは代わりにフリーソフトのAdvancedRunを使うとよい。
** まとめ
*** CSRKをLocalSignatureKey
*** LTKをLongTermKey
*** EDIVをEdiv（16進→10進に変換）
*** ERandをRandに（バイト(2文字のかたまり)をすべて逆順にしてから10進変換）。ちなみにこれを間違えた結果、マウスを動かすたびにbluetoothアイコンが白↔黒と高速で切り替わる謎のバグっぽい現象が起こったことがあった。
*** 小文字を大文字に変える必要はない。また、IRKをIdentityResolvingKeyに書くのも不要。


==== マルチデバイス対応マウス（Logicool） ====

マルチデバイス対応（切り替えボタンがあるやつ）のマウス（LogicoolのM595）を使ったら、登録情報を一旦削除して再接続するごとにMacアドレスがひとつインクリメントされて困った。Linuxで接続→Winで接続→Linuxで上記の書き換え、とやったあと、フォルダ名を変更（1を足せばよいはずだが正確にはWinの情報を見るのがよい）するとうまくいった。[https://twitter.com/e9g/status/1381111849664409600 自分のツイート]にも記録あり
[[Category:IT]][[Category:Windows]]{{#seo:|title={{FULLPAGENAME}} - Turgenev's Wiki}}

Windowsでエクスプローラーからフォルダを各種ターミナルで開く

2025-05-05T01:30:30Z

Turgenev: Notion-MW

Explorerの右クリックメニューやアドレスバーからフォルダを各種ターミナルで開くための設定方法の紹介。cmd.exe, powershell（pwsh含む）, Cygwin, Git Bashの4つに対応。

== 基本 ==

* [[Windowsの右クリックメニューから複数ファイルをまとめて開く|Windowsの右クリックメニューから複数ファイルをまとめて開く]] のように、レジストリでフォルダ・フォルダ背景の右クリックメニューを編集できる。
** Windows10までの右クリックメニューに戻そう。
** <code>command</code>キーの既定値に直接コマンドを書く方法と、<code>DelegateExecute</code>値（など）を使ってCOMを通じて実行する方法（このために[https://github.com/ge9/ExecuteCommand-Pipe https://github.com/ge9/ExecuteCommand-Pipe]（使い方はレポジトリの説明を参照）を作った）がある。
** HKLMにあるマシン全体の設定は、それ自体は管理者権限（あるいはTrustedInstallerなどさらに上の権限）がないと書き換えられないが、HKCUに値があればそちらが優先されるので、自分だけに関する設定変更ならユーザー権限だけで可能である。
** <code>Directory</code>や<code>Directory\Background</code>の直下に<code>runas</code>という名前でキーを作った場合は、自動的に<code>command</code>の内容が管理者権限で実行される。ただ、<code>runas</code>という固定のただ一つの名前しか使えないため、例えば管理者としてコマンドプロンプトを開くメニューとPowerShellを開くメニューを共存させることができない。そのためこの記事では<code>runas</code>キーを使用するのではなくコマンドの中で明示的に管理者としての実行を行っている。
* Explorerのアドレスバー（address bar, location barなど）にcommandと入力してEnterを押すと、そのフォルダをカレントディレクトリとして<code>command</code>というコマンドが実行される。
** このアドレスバーの仕様はおそらく「ファイル名を指定して実行」とほぼ同じ。<code>command</code>で（メインとして）指定するファイルはフルパスなら必ず動作し、Pathが通っているまたはApp Pathsに登録されているならファイル名だけでよく、さらにbatやexeの場合は拡張子も省略できる。さらに、ほとんど知られていないが実はApp Pathsの値には実行ファイル以外も書けるようである。
** つまり、パスの通っているフォルダにあるimage.pngはフルパスを打たなくても「image.png」で開けるし、さらにはApp Pathsの<code>openimage.exe</code>というキーにimage.pngのフルパスを書けば<code>openimage</code>と打つだけで（実際にはそのような実行ファイルは全く存在しないにもかかわらず）image.pngが開くようになる。当然、vbsなども拡張子無しで呼び出せることになる。

== ポイント ==

==== パス名のルール ====

* Windowsではパスの長さが260文字以下という制限がある。詳しくは[[Windowsのパス長さ制限に関して|Windowsのパス長さ制限に関して]] 参照。
** 制限を超えるような長いパスは<code>\\?\</code>というプレフィックスを付けて（UNCパスの一種として）扱われる。
*** このようなフォルダをカレントディレクトリとしてコマンドを実行することはできないので、アドレスバーに打ち込む方式は使えない（System32をカレントディレクトリとして実行される）。wt -dなどにも指定できない。
*** 右クリックメニューでは、commandの既定の値に直接書く方式の場合は、<code>NoWorkingDirectory</code>を設定しないと呼び出されなくなる。
*** シンボリックリンク/ジャンクションでパスを短くしてやれば普通に扱えるようになる
* 普通に入力できる文字でWindowsのファイル名に使えないのは、<code>\</code> <code>/</code> <code>:</code> <code>*</code> <code>?</code> <code>"</code> <code><</code> <code>></code> <code>|</code>の9個（エクスプローラーの画面で入れようとすると表示される）。
** その他、ヌル文字やタブスペースのような0x20未満の制御文字も使えない（はず）。
*** これらを含むファイルはGit Bash/Cygwinを使っても作れない。
*** NTFS自体の制限はおそらく<code>/</code>だけで、それ以外に関してはLinux上で作ってからWindowsで見ると見られることもある。中身の閲覧などは不可。
* また、末尾が空白またはピリオドのファイルも禁止で、Explorerやcmdでは作れない（自動で除去される）。
** これらはGit Bash/Cygwinなら作れる。前者はエクスプローラーで閲覧など多少の操作ができるが後者はほとんど何もできず、DelegateExecuteの右クリックメニューでもピリオドが外れた名前しか取得できない。
* 先頭が空白のファイルはExplorerだと作れないがcmdなら作れる。禁止ではないはず。


==== Git Bash/Cygwin ====

* Git BashではWindowsの実行ファイルにスラッシュ付きオプションを渡すときはスラッシュを2つにする必要がある。<code>cmd //c</code>や<code>bcdedit //v</code>など。
* printf関数の%qオプションを使うと、文字列をエスケープされた状態にして返してくれる。これはshからの呼び出し先の別のshで再びフォルダ名をcdなどの引数として利用したいときに使える。
** bash（POSIX互換ではない）の組み込みコマンドのprintfと、独立実行ファイル（GNU Coreutilsの一部）である/bin/printfがある。基本的な趣旨としては同一のコマンドだが、組み込みコマンドのほうは入力に<code>"</code>が含まれていない限り結果にも<code>"</code>が使われることはないようで、このおかげで意図しない動作を回避できることがある。今回扱う例に関しては前者が後者の上位互換であるということになる。後者を使っているものはそれでも動いたものである。
** そもそも%qは組み込みコマンドのほうにしかないという話もある。環境によって違いそう。
* <code>\\?\</code>が付くような長いパスをカレントディレクトリにしていても、Git Bash/Cygwinに付属の（というかMSYS/Cygwin向けにコンパイルされた？）exeなら実行できる。
* Git Bashの(ba)shは<code>--login</code>をつけて起動してもカレントディレクトリが維持されるが、<s>Cygwinの(ba)shは</s><s><code>--login</code></s><s>をつけると強制的にホームディレクトリに移動する。</s>
** 2024/4頃、Cygwinの挙動が変化し、カレントディレクトリが維持されるようになっていることに気付く。変わっていた方のバージョンは3.5.3、変わっていない方は3.3.6であった。
** ところで、[https://superuser.com/questions/345964/start-bash-shell-cygwin-with-correct-path-without-changing-directory Start bash shell (cygwin) with correct path without changing directory - Super User]の通り、<code>CHERE_INVOKING</code>という変数を1に設定しておけばカレントディレクトリは維持される。
* Git Bashにおいては環境変数を正しく設定するため<code>--login</code>の時点で環境変数<code>MSYSTEM</code>を<code>MINGW64</code>にしておく必要がある。[[Windowsでのターミナル環境|Windowsでのターミナル環境]] 参照。


==== powershell/pwsh ====

* バージョン5まで（Windows PowerShell）はpowershell.exe、6以降（PowerShell Core, PowerShell）はpwsh.exeと実行ファイル名が違う
** 以後、「powershell(.exe)」と「pwsh(.exe)」で呼び分ける。ただし手元ではpowershellの5.1とpwshの7.2～7.3くらいでしか試していないので、一部バージョンではまた違う可能性もある。
** pwshは必ずしもWindowsに標準では入っていないので、以下の例でもあまり依存しないように気を付ける。
** 基本、シングルクォートで囲えばほとんどの特殊文字が無効になり、シングルクォート自体を書くときは2つ並べる。ただし注意点として、驚くべきことにpowershell/pwshでは「全角のシングルクォート（U+2018-U+201B、<code>‘</code> <code>’</code> <code>‚</code> <code>‛</code>の4つ）」も通常のシングルクォートと同じ効力があるので、同じようにエスケープする必要がある（参照: [https://learn.microsoft.com/ja-jp/powershell/scripting/lang-spec/chapter-02?view=powershell-7.2 https://learn.microsoft.com/ja-jp/powershell/scripting/lang-spec/chapter-02?view=powershell-7.2]）。掲載したスクリプトでは省略しているがやることは同じ。
* powershell.exe
** -Commandがなくても付けたのと同じ扱いになる？
*** 逆に、-Commandを付けなければいけないという点を除いてはpwshがpowershellの上位互換という感覚である（新しいのでそれはそう）。
** <code>`</code>や<code>[]</code>を含むフォルダの扱いにバグがあり、cmdなどでこれらのフォルダをカレントディレクトリとした状態で5系のPowerShellを起動すると<code>C:\</code>や<code>C:\Windows\System32\WindowsPowerShell\v1.0></code>をカレントディレクトリとして起動される（たとえば<code>C:\somefolder][</code>なら前者、<code>C:\somefolder[]</code>なら後者）。
** -Fileを使用してスクリプトを実行するとき、ダブルクォーテーションで囲われていない <code>-</code> が引数に含まれているとエラーになるバグがある。
* powershell.exe・pwsh.exe共通
** 連続した<code>`</code>があるフォルダに関する挙動にバグがある。コンソールプログラムを実行しても新規ウインドウで開かれる、そこをカレントディレクトリとしたときにファイルをmvできないなど。
** <code>`</code>や<code>[]</code>を含むフォルダに関しても、絶対パス指定したりきちんとエスケープしたりすれば操作自体はできる（場合もある）。
*** エスケープはいずれも直前に<code>`</code>を付ける。
*** これらを特殊文字として扱いたくないときは<code>-LiteralPath</code>を付けると良い場合もある。
** UNCパスをカレントディレクトリにすることができるが、<code>Microsoft.PowerShell.Core\FileSystem::\\</code>とかいう謎のプレフィックスが付く。
** 末尾が空白のフォルダについてはcdできず、Cygwinなどでそのようなフォルダをカレントディレクトリとして起動したとしても<code>C:\Windows\System32\WindowsPowerShell\v1.0</code>や<code>C:\Program Files\PowerShell\7</code>に移動してしまう。
** 8.3形式のパスを強制的に長い名前に戻してcdしてしまう。その結果、長いフォルダをカレントディレクトリとして外部プログラムを実行できなくなる。
* PSModulePath環境変数の関係な気がするが、pwshの中でcmdを起動してその中でpowershellを起動したりするとPSReadLineモジュールが読み込めない（<code>PSReadline モジュールを読み込めません。コンソールは PSReadline なしで実行されています。</code>）とか言われたりする

==== 環境変数への置換 ====

cmdなどを使うと<code>%</code>で囲われた環境変数（<code>%PATH%</code>など）が置換される。<code>%</code>はファイル名にも普通に使える文字なので、注意が必要となる

* 該当の名前の環境変数が定義されていたときのみ置換が行われ、定義されていなければそのままになる。
* <code>%</code><code>VAR</code><code>%</code>の置換は必ずしもcmdだけで行われるわけではない。「ファイル名を指定して実行」、VBSのWscript.Shellのrun、conhost、wtの引数などでも行われる。しかしCreateProcessやShellExecute(Ex)やレジストリ値では行われない（無理やりREG_EXPAND_SZにしたら展開されるが、後述の<code>%V</code>との適用順などは不明）。
* 一般には、環境変数には英数字とアンダースコアしか使えないとの説明もよくあるが、実際にはほとんどの記号が有効である。従って、<code>^%PATH^%</code>のようなキャレットによるエスケープはcmd向けにはある程度有効だが、<code>PATH^</code>という環境変数が定義されているとうまく動かない。
* （そういう変数が定義されていることは現実にほとんどないだろうし、それが保証できるなら以下の部分を読む必要はない）

これを防ぐ方法はいくつかある。ちなみに、<code>%%</code>でのエスケープというのはバッチファイルの中だけの話で、今回の場面では以下より簡単なエスケープ方法は多分ないと思う。

<ol style="list-style-type: decimal;">
<li>既に定義されているかもしれない環境変数をバックアップし、一時的にその中身を<code>%</code>に変えて使用することでリテラル文字としての<code>%</code>を表現し、後で元に戻す。
すなわち、<code>MY_PERCENT</code>のような変数の中身をバックアップし、<code>MY_PERCENT</code>の中身を<code>%</code>に変え、未知の文字列中の<code>%</code>をすべて<code>%MY_PERCENT%</code>にすることでこの部分が置換によって<code>%</code>に変わるのを利用して<code>%</code>をそのまま渡すということである（環境変数の置換は左から順に行われるため、たとえば<code>%MY_PERCENT%PATH%MY_PERCENT%</code>の<code>%PATH%</code>が置換されることはない）。受け渡しが終わったら<code>MY_PERCENT</code>の中身を復元する。
これは、変数のバックアップとリストアを同じプロセス・スクリプト内で行える（呼び出した後に元に戻ってくる）場面で有用である。呼び出し先プロセスでリストアすることも不可能ではないと思うが、環境変数には任意の文字が入る可能性があることを考えるとエスケープが大変困難になることが予想される。</li>
<li>VAR1, VAR2, VAR3, …のような無限個の変数を最初からチェックし、最初の未定義の変数を上記と同様に使用し、後で未設定にする。
ほぼ上記と同じだが、内容のリストアでなく未設定にするだけなので、呼び出し先プロセスでも容易に行える。ただし実装が面倒である。</li>
<li><code>%</code>を<code>==%</code>へと置換して、置換のプロセスを抜けた段階で元に戻す。
<ul>
<li>これは、最初の文字以外に<code>=</code>が含まれる環境変数名は（実際に環境変数が設定されていたとしても絶対に）置換されないことがわかったためである。
<ul>
<li><code>%=%</code>（あるいは、<code>%=VAR%</code>など）は少なくともcmdの対話シェル上だと置換されてしまうので<code>=%</code>へのエスケープだと不十分に見えるが、実際には<code>=</code>一つでも問題なく動く場合もあった。</li>
<li>しかし、動かないときもあるので、多くの例では<code>==%</code>にエスケープしている。<code>=%</code>になっているものは、試した限りはそれでも問題なく動いているものである。</li>
<li>[https://learn.microsoft.com/en-us/windows/win32/procthread/environment-variables Environment Variables - Win32 apps | Microsoft Learn]では「<code>=</code>は環境変数に使えない」と書かれていて、ダイアログからでも設定はできないが、レジストリだと無理やり設定できる。
<ul>
<li>ユーザー環境変数に設定する分にはとりあえず問題なさそうだが、システム環境変数にレジストリから<code>=</code>（と、<code>=</code>を名前に含むいくつかの変数。どれが原因かは正確にはわからない）を無理やり追加したら0xc000021のブルースクリーンでWindowsが起動しなくなった（該当の変数を全て削除したら治った）のでこれはやってはいけない。</li></ul>
</li>
<li>ちなみに、<code>=</code>や<code>%</code>はUnix側では特殊文字ではないので、printfとの適用順はあまり気にする必要はない。</li></ul>
</li>
<li>この方法のメリットは、一度置換してしまえばその文字列を何度使いまわしても変化がないことが保証されることと、未定義の変数の探索や変数のリストアが必要ないことである。
<ul>
<li>要は<code>%(=を含まない文字列)%</code>を含まない文字列だけを値にとる単射を構成すればいいだけなので、base64エンコーディングのようにしても構わない。</li></ul>
</li>
<li>ただ、<code>==%</code>を<code>%</code>に置換するという操作はPowerShellやshにとっては容易でもcmdにとっては不可能に近いので、最終的な呼び出し先がcmdであるときには採用しづらい。</li></ul>
</li></ol>

また、今回の記事ではcmdやvbsのRunを経由してコマンドを実行しているものが多くあるが、このスクリプトの内容自体もエスケープが必要である。つまり、例えば<code>cmd /c</code>の内側に<code>$mypath.Replace('%','%MY_PERCENT%')</code>というPowershellコードが含まれるなら、<code>','</code>や<code>MY_PERCENT</code>という環境変数が定義されていた時にその部分が置換されてしまう。これを回避するのはそこまで難しくなく、この例であれば<code>$mypath.Replace('%'.Trim('='),'%'.Trim('=')+'MY_PERCENT%')</code>のように<code>=</code>を含む無意味なコードを挿入すればよい。また、<code>%</code>をいったん<code>==%</code>にしている部分に関しては、<code>==%</code>ではなく<code>==%==</code>にすることで問題を避けられるだろう。無駄に複雑になるのでスクリプト例ではそのような措置はしていない。

==== cmd ====

* UNCパス（<code>\\?\</code>だけでなく普通のUNCパスも含む）をカレントディレクトリにすることはできない（rdなど一部コマンドでの取り扱いは可能）。
* 末尾が空白のフォルダにcdすることはできないが、Cygwinなどでそのようなフォルダをカレントディレクトリとした状態でcmdを起動した場合は、そのフォルダをカレントディレクトリとして起動する（外部プログラムの起動はできないがcdなどの内部コマンドは有効で、一度でも出たら戻れない）。
* 各種のパース規則が本当に謎。特に引用符周りは地獄である。[https://thinca.hatenablog.com/entry/20100210/1265813598 cmd.exe のコマンドラインの仕様を解析してみた - 永遠に未完成]を読むとわかるが、例えば「ファイル名を指定して実行」で以下の挙動を確かめよう。
** <code>cmd /k echo "a b"c d"</code>→<code>"a b"c d"</code>と出る
** <code>cmd /k echo "a & b"c d"</code>→<code>"a & b"c d"</code>
** <code>cmd /k echo "a b"c & d"</code>→<code>echo "a b"c</code>と<code>d"</code>がそれぞれ別々に実行される
** すなわち、<code>"</code>が一見特殊文字でないかのような振る舞いをする（そのまま出力される）割に、その前後で特殊文字の扱いが切り替わっている。


==== Windows Terminal ====

* 以下、wtと略す（実行ファイル名がwt.exeなため）。パスが通っているものと仮定する。
* wtでは<code>;</code>が特殊文字になるようで、<code>\;</code>とエスケープが必要。[https://github.com/microsoft/terminal/issues/13264 https://github.com/microsoft/terminal/issues/13264] かな？
** <code>"</code>も<code>\"</code>にする必要がある。一方で、単一の<code>\</code>は（うしろに<code>;</code>や<code>"</code>などがなければ）そのまま<code>\</code>になるようである。大丈夫なのか…？
* 起動時にカレントディレクトリがユーザーフォルダ（%USERPROFILE%）になる
** <code>-d</code>オプションで明示的に指定することができる

==== 連続空白 ====

空白が連続するファイル名の対応は割と厄介である。Windows側では引数を<code>""</code>で囲うことで、またsh側では適宜<code>IFS=</code>と設定することで対処できる。


==== Unicode対応 ====

* UTF8を使おう
* <code>chcp 65001</code>が一応使えるが、一旦シェル内部に入らないと使えないのでやや不便
** 使わなくても大丈夫なときもある。あまりちゃんと理解できていないが、経験上、powershellで<code>$input</code>変数を用いて標準入力を受け取る際には<code>chcp 65001</code>が必要そう。
* /bin/printfやprintfの実行時には<code>LANG</code>を<code>en_US.UTF8</code>とかに設定する。
** Cygwinなら不要？

==== デバッグ時 ====

* 管理者権限のものを試すときでもまず<code>-Verb Runas</code>を外して動作確認するとよい。
* 後述のwaitrunも役に立つだろう。
* 特殊文字に関しては、最初は空白のないフォルダ、次に空白のあるフォルダや連続空白のあるフォルダ、次にシングルクォートや<code>%PATH%</code>を含むフォルダなどとだんだん難しくしていくとよい。
* それとは別に、Unicode対応、<code>C:\</code>（ドライブ直下）対応、259文字のフォルダ対応（後述）などをチェックする
* 難しい例は、例えば<code>z 𠮷𠮷%PATH% ' '' ` `` $PATH & && %%PATH%%[] ] [ ^ ^^ ' ; ;; 𩸽𩸽!PATH!#$%&'()=~{`+}_,.][;@^- - ‘ ’ ‚ ‛</code>のような感じ（適当）。こんなファイル名を現実に見ることはないが、エクスプローラー上で普通に入力できる内容である。
** 「𠮷」はBMP外かつJIS外の漢字としては最も変換で出しやすいのでテストに重宝する。（𩸽はBMP外だがJIS外ではない（第4水準））

==== その他 ====

* デフォルトシェルは、通常ユーザーはwtでも管理者の場合はconhostに設定されているっぽい？
* <code>C:\</code>のようなドライブ直下のパスは末尾に<code>\</code>を付けなければいけないことが多い。たとえばwt -dの引数にする場合など。またcmdでcdコマンドや<code>CD</code>環境変数を見るときもドライブ直下のときだけは<code>\</code>が付いて返ってくる。
** ただ、wt -d に<code>C:</code>が渡されるように見えるのになぜか動いているものもある。未調査。
* shやcmdなどの中に一旦入ってしまうと一部の環境変数などが書き換わってしまうかもしれないが、多少は許容することとする。
* コマンド例は網羅的でない可能性があり、色々な書き方を提示しようとあえて統一していないところもある。現実にはもっと簡単なやり方があるかもしれない。あくまで一例ということで。
* CygwinとGit Bashはほぼ同じなのでGit Bashを主に載せてCygwinは適宜差分のみ記述する。
* shは、特にベースのシェルとして使うにはエスケープの方式などでWindowsと相性が悪く使いづらい感じがする。逆にcmdは内部コマンドは地獄だがベースのシェルとしては意外と副作用が少なく、そう悪くはない。
* 以下の例ではCygwinやGit Bashの実行ファイルにはPATHを通していないことを想定している。<code>C:\cygwin64</code>あたりは適当に読み替えていただきたい。
* 2021年途中ごろまで、wtなどのストアアプリ系？の実行ファイル（Explorer上で0バイトになってるエイリアス）をGit Bashから実行できない（Permission deniedとなる）バグがあった。 [https://github.com/git-for-windows/git/issues/2675 https://github.com/git-for-windows/git/issues/2675]
* ネットワークドライブは各ユーザー対象に割り当てられているせいなのか、管理者として実行すると利用できないらしい。割り当てられる前のネットワークパス自体は有効。
* wtを管理者権限で呼び出すときに（確率的に）ウインドウが最前面にならないことがある。chcpの有無で変わったりするなど詳細不明。conhostだとならない気がする。startrunなどを介して実行すると必ず最前面に出るようになるっぽい。


== 準備: win-console-delegator ==

cmdやPowerShellやCygwinのbashなどのシェルを使えば、スクリプトを起動して複雑なコマンドを呼び出せたり、パイプ実行が可能になったりと色々便利だが、それだけのためには大仰すぎて、特殊文字の扱いなどがかえって仇になることもある。

そこで、シェル関連の操作に汎用的に使えるコマンドをいくつか作成して公開した。[https://github.com/ge9/win-console-tools https://github.com/ge9/win-console-tools]

* 以前はC++で書いていた（[https://github.com/ge9/win-console-delegator https://github.com/ge9/win-console-delegator]）が、C#のほうが文字列の扱いなどが簡明。

ただし、これはあくまで筆者が独自に作ったものであり、Windows標準のもので何とかしようとするのが面白いところでもあるので、それほど積極的には使わない。今後出てくる例はすべて、これらを一切使わなくても（余計な環境変数が設定されてしまうかもしれないという点をのぞけば）同等の機能が実現できる。

<ul>
<li>runother
与えられた引数を特定の文字列とつなげて実行してくれるプログラム。この実行ファイル自体の名前を適宜変更して使用し、「特定の文字列」は別のファイルから読ませる。使用例は[[Windowsでのターミナル環境|Windowsでのターミナル環境]] を参照。</li>
<li>runother-gui
runotherとほぼ同じだが、コンソールアプリケーションではなくWindowsアプリケーション（黒いウインドウが出ない、cmd上で実行したときに終了待ちが行われないなど）。</li>
<li>evalrun
与えられたコマンドラインを実行し、その出力をそのままコマンドラインとして実行するコンソールアプリケーション。（テキストファイルからのコマンドラインの読み込みなどに使える）</li>
<li>startrun
与えられたコマンドラインをWindowsのデフォルトシェルで起動するだけのWindowsアプリケーション。</li>
<li>waitrun
与えられたコマンドラインを実行したあとキー入力を待ってから終了するコンソールアプリケーション。一瞬でウインドウが消えてしまうときのデバッグに使いやすい。</li>
<li>hiderun
コンソールウインドウ非表示の状態で与えられたコマンドを実行するWindowsアプリケーション。（GUIアプリケーションなどを与えた場合は非表示にならないかも）
vbsのvbHideでも非表示にできるが、コンソールウインドウの表示位置をみると非表示のウインドウが一つ挟まっていることが分かるのに対して、こちらの場合はそうならない。</li>
<li>piperun
与えられたコマンドラインを最初の<code>|</code>とそれ以降の2つに区切ってそれぞれコマンドとしてパイプでつなげて実行するコンソールアプリケーション。ただし最初のコマンドのほうに<code>|</code>自体を入力したいときは<code>||</code>でエスケープする。また2つ目のコマンドの先頭の空白は除去される。</li>
<li>piperunex
piperunと似ているが、2つだけでなく3つ以上の任意個のパイプ実行を一度に行う。一見便利だが、コマンドの後ろ側に未知の文字列が渡される場合、<code>|</code>をエスケープする必要が生じる。
<code>piperun piperunex command1 || command2 || ... || commandN | unknown_commandline</code>のように外側を<code>piperun</code>で囲うと安全。</li>
<li>adminrun
与えられたコマンドラインを管理者として実行するWindowsアプリケーション。<code>ShellExecuteEx</code>では実行ファイルパスと引数は別々に指定しなければいけないので最低限の引数の解析を行っている。PowerShell経由で管理者権限で実行するときのような面倒なエスケープが全て不要になるため非常に使いやすいが、この記事ではこれに依存しないようにする。
<ul>
<li>ちなみにこういうのもある。[https://github.com/mattn/sudo mattn/sudo: sudo for windows] これは、通常のUACのように別ウインドウで実行するのではなく、localhostのランダムなポートを使い、自分自身にポート番号を渡しつつ管理者権限で呼び出すことで標準入出力を転送し、元の端末でそれを読み書きできるという点で、linuxのsudoに近い。しかし標準入出力を介しているので、<code>cmd /c for /?</code>や<code>cmd /c pause</code>の挙動が変わってしまうという問題がある。また、呼び出し元でchcp 65001をしていると文字化けする。また、コマンドライン引数を一旦配列に分割してから組み直しているので情報が一部落ちている。あと、セキュリティ的にも懸念があるかもしれないが、これはそもそもLinuxのsudo自体がまずどうなの？という気持ちになった。（未解決）（参照: [https://twitter.com/e9g/status/1687385469921931264?s=20 https://twitter.com/e9g/status/1687385469921931264?s=20]）</li></ul>
</li>
<li>uacrun
startrunと同じだが、コンパイル時のマニフェスト設定でこのプログラム自体の実行に管理者権限を要求するようにしたので、adminrunと同じように使える（管理者権限で実行する対象が渡されたコマンドではなくuacrun自体になるという違いはある）</li>
<li>pecho
与えられたコマンドライン引数をそのままコンソールに出力する。→WindowsでUnicode文字（特にU+10000以上）を正しく表示（&ファイルに書き込み）するには、「出力先がコンソールならWriteConsoleW、そうでなければWriteFileを使用する」といった非常に面倒な実装が必要であり（参照: [https://twitter.com/mattn_jp/status/542581083242364928 https://twitter.com/mattn_jp/status/542581083242364928] など）、C++やC#では扱いづらい。そこでrustを用いて実装した。→[https://github.com/ge9/pure-echo-win pure-echo-win]</li>
<li>printcd
カレントディレクトリをコンソールに出力する。（ちなみにpwdの由来はprint working directoryなのでそれに倣った）</li></ul>


== 注意: 当初は後述のNoWorkingDirectoryを知らなかったので1.の方法に頼っていたが、実際には2.の方法のほうが簡明なので、そちらを使うことを勧める。1.は残しておくが、読む必要はあまりない。 ==


== 1.標準入力から受け取る場合 ==

まず「標準入力からディレクトリのフルパスを受け取り、そのディレクトリで各種ターミナルを起動するコマンド」を紹介する。

そのようなコマンドを仮に<code>openterm</code>とすると、ExecuteCommand-Pipeを使用して、レジストリ（該当CLSIDのLocalServer32の既定の値）に以下のように書くことで、CLSIDが右クリックメニューのDelegateExecute値に使えるようになる。

<code>C:\path\to\ExecuteCommand4000.exe h openterm</code>

<code>h</code>はコンソールウインドウを非表示にするExecuteCommand-Pipeのオプションである。

また、この<code>openterm</code>の部分は非常に長くなることがあり、その場合レジストリに書いて直接編集するのは手間がかかる（操作もしづらいし、更新を即座に反映させるために「<code>LocalServer32</code>」キーの名前などを変えて戻す必要もあって面倒）。そこで、runotherを使ってtxtに<code>openterm</code>の内容をそのまま書くことで、<code>openterm</code>の部分にそのexeの名前だけを書けばよくなる。

また、いくつかはCygwin/Git Bash向けに冒頭でcygpathによる変換を入れているが、これを取り除けば、Cygwin/Git Bash用のパスを受け取って動作するコマンドということになる。

では以下で、<code>openterm</code>部分についてそれぞれ紹介する。

* 直接コマンド記入でも<code>NoWorkingDirectory</code>を指定すれば<code>\\?\</code>に対応できるというのをこのセクションの大部分を書き終えてから知ったので、このセクションは内容の多さの割には実際の必要性はそこまで大きくないかもしれない。


=== Git Bash ===


==== <code>git-bash.exe</code>で開く ====

この場合shの感覚で<code>git-bash.exe</code>に引数を渡せば勝手にminttyのウインドウで開いてくれるので最も楽である。

<code>cmd /c ""C:\Program Files\Git\usr\bin\cygpath" -f - | "C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=;/bin/env LANG=en_US.utf8 /bin/printf %q $(/bin/cat)" | "C:\Program Files\Git\usr\bin\xargs" -d '\n' -I {} "C:\Program Files\Git\git-bash.exe" -c "cd {};exec bash""</code>

* Git BashのcygpathでGit Bash用のパスに変換
* printfでエスケープ、utf8を設定
* git-bash.exeに渡す


==== デフォルトのターミナルで開く: ①startrunを使う ====

<code>cmd /c ""C:\Program Files\Git\usr\bin\cygpath" -f - | "C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=;/bin/env LANG=en_US.UTF8 /bin/printf %q $(/bin/cat)" | "C:\Program Files\Git\usr\bin\xargs.exe" -d '\n' -I {} startrun "C:\Program Files\Git\usr\bin\env.exe" MSYSTEM=MINGW64 "C:\Program Files\Git\usr\bin\bash.exe" --login -i -c 'cd {};exec bash'"</code>

* <code>git-bash.exe</code>や<code>C:\Program Files\Git\bin</code>のbashではなく/usr/binのbash.exeを使う。以後同じ。


==== デフォルトのターミナルで開く: ②cmdのstartを使う ====

<code>cmd /c ""C:\Program Files\Git\usr\bin\cygpath" -f - | "C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=;/bin/env LANG=en_US.UTF8 /bin/printf %q $(/bin/sed 's/\\^/^^/g;s/%/=%/g;s/&/^&/g')" | "C:\Program Files\Git\usr\bin\xargs.exe" -d '\n' -I {} cmd //c start "" "C:\Program Files\Git\usr\bin\env.exe" MSYSTEM=MINGW64 "C:\Program Files\Git\usr\bin\bash.exe" --login -i -c 'cd "$(echo {} ^| sed s/=%/%/g)";exec bash'"</code>

* この場合、cmdによる環境変数への置換を避ける必要があるほか、キャレットによるエスケープにも対応する必要がある。
* Git Bashからcmdを実行しているので<code>//c</code>のところのスラッシュは2つ。

==== conhostで開く ====

<code>cmd /c ""C:\Program Files\Git\usr\bin\cygpath" -f - | "C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=;/bin/env LANG=en_US.UTF8 /bin/printf %q $(/bin/sed 's/%/=%/g')" | "C:\Program Files\Git\usr\bin\xargs.exe" -d '\n' -I {} conhost "C:\Program Files\Git\usr\bin\env.exe" MSYSTEM=MINGW64 "C:\Program Files\Git\usr\bin\bash.exe" --login -i -c 'cd "$(echo {}|sed s/=%/%/g)";exec bash'"</code>

conhostによる環境変数の置換を抑制。


==== Windows Terminalで開く ====

<code>cmd /c ""C:\Program Files\Git\usr\bin\cygpath" -f - | "C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=;LANG=en_US.UTF8 printf %q $(/bin/sed 's/%/=%/g')" | "C:\Program Files\Git\usr\bin\sed.exe" "s/;/\\\\;/g" | "C:\Program Files\Git\usr\bin\xargs.exe" -d '\n' -I {} wt "C:\Program Files\Git\usr\bin\env.exe" MSYSTEM=MINGW64 "C:\Program Files\Git\usr\bin\bash.exe" --login -i -c "IFS=\\;cd $(echo {}|sed s/=%/%/g) \\;exec bash""</code>

上記に加えてセミコロンへの対応が必要なのと、こっちは/bin/printfじゃなくて組み込みのprintfでこうしないとだめだった。


==== Cygwin ====

付属のminttyを使うものだけはGit Bashと割と差があるので載せる。

<code>cmd /c ""C:\cygwin64\bin\cygpath" -f - | "C:\cygwin64\bin\sh.exe" -c "IFS=;/bin/printf %q $(/bin/cat)" | "C:\Program Files\Git\usr\bin\xargs" -d '\n' -I {} "C:\cygwin64\bin\mintty.exe" -e "C:\cygwin64\bin\bash.exe" --login -i -c "cd {};exec bash""</code>


=== PowerShell ===


==== デフォルトシェル, startrun ====

* パスのエスケープがおかしい気がするが、なぜか動いている

<code>cmd /c ""C:\Program Files\Git\usr\bin\sed.exe" "s/'/''/g" | "C:\Program Files\Git\usr\bin\xargs.exe" -d '\n' -I {} startrun powershell -noexit -command Set-Location -literalPath "'{}'""</code>


==== デフォルトシェル, cmdのstart ====

<code>cmd /c ""C:\Program Files\Git\usr\bin\sed.exe" "s/'/''/g;s/%/=%/g" | "C:\Program Files\Git\usr\bin\xargs.exe" -d '\n' -I {} cmd //c start "" powershell -noexit -command Set-Location -literalPath '\'{}\'.Replace(\'=^%\',\'%\')'"</code>


=== cmd ===


==== Windows Terminal ====

<code>cmd /c chcp 65001 & powershell -Command "$mypath=($input | ForEach-Object { return $_ });$bak=$env:MY_PERCENT; $env:MY_PERCENT = '%';if ($mypath.Length -gt 258) { $mypath = cmd /c \"for %A in (`\"$($mypath.Replace('%', '%MY_PERCENT%'))`\") do @echo %~sA\" };$env:MY_PERCENT = $bak;wt -d ($mypath -replace ';', '\;') cmd"</code>

<ul>
<li>[[Windowsのパス長さ制限に関して|Windowsのパス長さ制限に関して]] でも書いた通り、Windows側はちょうど259文字の長さのフォルダだけは（その必要があるにもかかわらず）8.3形式を使った短いパスにして渡してくれない。そこで、パス長さが258を超えていればcmdに渡して8.3形式の名前に変換する処理をPowerShell側で行う。この際はエスケープされていない正確なパス名をcmdに渡さなければならないので<code>MY_PERCENT</code>の値を一時的に<code>%</code>に設定する方法をとっている。
<ul>
<li>念のため再確認しておくが、この<code>'%MY_PERCENT%'</code>の部分は<code>'%'.Trim('=')+'MY_PERCENT%')</code>などと変えておかないと、<code>MY_PERCENT</code>が定義されていた場合に正しく動作しない。</li>
<li>cmdではちょうど258文字のフォルダでもdirが失敗するなど挙動が不自然であるため、もう少し保守的に257を超えていれば短くするという仕様でもいいかもしれない。</li></ul>
</li>
<li>（追記）8.3形式のパスを取得するのは普通にPowerShell内でもできるらしい…。以下のようになる。
<code>if ($mypath.Length -gt 258) { $mypath = (New-Object -ComObject Scripting.FileSystemObject).GetFolder($mypath).ShortPath}</code></li></ul>

259文字のフォルダを無視するなら以下のように簡潔に済む。

<code>cmd /c chcp 65001 & powershell -Command wt '-d' $input.Replace(';','\;') cmd</code>

==== デフォルトシェル ====

これは案外難しい。なぜなら、cmd内でcdさせるのは%のエスケープの関係で難しく（cmd内で=を含む文字列を置換することがどうやってもできなさそう（外部プログラムを呼び出すのも難しそうだった）なので、未定義の変数を探索するやり方しかない）、Start-Processの-WorkingDirectoryやCygwinのshは8.3形式に対応していないからである。要は「与えられたディレクトリ（8.3形式のパスが含まれるかもしれない）をカレントディレクトリとして与えられたコマンドを実行する」だけやってくれるプログラムがあればよく、これ自体はそう難しくないことのはずだが、現状、Windows標準環境でこれができるのは自前でプログラムをコンパイルする以外だと（pwshを入れていいならpwshと）vbsしかないようである。結局、この部分をついでにやってくれるWindows Terminalのほうが楽ということになる。

たとえば以下のようなvbsを用意する。

<syntaxhighlight style="margin-bottom:0.2em;" lang="vb.net">Dim objShell
Set objShell = CreateObject("WScript.Shell")
objShell.CurrentDirectory = WScript.Arguments(1)
objShell.Run(WScript.Arguments(0)),,False</syntaxhighlight>
<div style='text-align: center;'>startatdir.vbs</div>

すると以下のように書ける。

<code>cmd /c chcp 65001 & powershell -Command "$mypath=($input | ForEach-Object { return $_ });$bak=$env:MY_PERCENT;$env:MY_PERCENT = '%';if ($mypath.Length -gt 258) { $mypath = cmd /c \"for %A in (`\"$($mypath.Replace('%', '%MY_PERCENT%'))`\") do @echo %~sA\" };$env:MY_PERCENT = $bak; wscript 'C:\path\to\startatdir.vbs' cmd ('\"'+$mypath+'\"')"</code>

なお<code>startatdir.vbs</code>のパス指定はフルパスが必要そう（ただしここはcmd /cの中なので<code>%USERPROFILE%</code>とかを使って書いてもよい）


== 1.1.標準入力から受け取る場合 - 管理者権限あり ==

上記の続きで、こちらは管理者権限ありのもの。


=== Git Bash ===


==== デフォルトシェル ====

<code>cmd /c ""C:\Program Files\Git\usr\bin\cygpath" -f - | "C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=;/bin/env LANG=en_US.UTF8 /bin/printf %q $(/bin/cat)" | "C:\Program Files\Git\usr\bin\sed.exe" "s/'/''/g" | "C:\Program Files\Git\usr\bin\xargs.exe" -d '\n' -I {} powershell -Command Start-Process -Verb Runas -Filepath '"C:\Program Files\Git\usr\bin\env.exe"' -ArgumentList '"MSYSTEM=MINGW64"', '"`"C:\Program Files\Git\usr\bin\bash.exe`""' , '--login', '-i' , '-c', "'\"cd {}; exec bash\"'" "</code>

* Start-Process自体がstartみたいなものなので、引数にコンソールアプリケーションを指定したらデフォルトシェルで開かれる。
* 最後のところ、「<code>"'\"cd {}; exec bash\"'"</code>」のかわりに「<code>'\'"cd {};exec bash"\''</code>」とか「<code>'\'\"cd {};exec bash"\''</code>」でも動くのは謎。シングルクォーテーションのエスケープ規則がわからない。参考→[https://twitter.com/e9g/status/1678283164689760256 https://twitter.com/e9g/status/1678283164689760256]


==== Windows Terminal ====

<code>cmd /c ""C:\Program Files\Git\usr\bin\cygpath" -f - | "C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=;LANG=en_US.UTF-8 printf %q $(/bin/cat)" | "C:\Program Files\Git\usr\bin\sed.exe" "s/'/''/g;s/%/==%/g;s/;/\\\\;/g" | "C:\Program Files\Git\usr\bin\xargs.exe" -d '\n' -I {} powershell -Command Start-Process -Verb Runas -Filepath wt -ArgumentList "'"'"C:\Program Files\Git\usr\bin\env.exe"'"'" , '"MSYSTEM=MINGW64"' , "'"'"C:\Program Files\Git\usr\bin\sh.exe"'"'" , "'--login'", "'-c'", "'"'"IFS=\\;cd $(echo {}| /bin/sed s/==%/%/g) \\; exec bash"'"' " "</code>

==== adminrunを使う ====

<code>piperunex "C:\Program Files\Git\usr\bin\cygpath" -f - | "C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=; /bin/env LANG=en_US.UTF8 /bin/printf %q $(/bin/cat)" | "C:\Program Files\Git\usr\bin\sed.exe" "s/%/==%/g;s/;/\\\\;/g" | "C:\Program Files\Git\usr\bin\xargs.exe" -d '\n' -I {} adminrun wt "C:\Program Files\Git\usr\bin\env.exe" "MSYSTEM=MINGW64" "C:\Program Files\Git\usr\bin\sh.exe" --login -c "IFS=\\;cd $(echo {}|| /bin/sed s/==%/%/g) \\; exec bash"</code>


=== PowerShell ===


==== Windows Terminal ====

<code>cmd /c ""C:\Program Files\Git\usr\bin\sed.exe" "s/'/''''/g;s/%/==%/g;s/;/\\\\;/g" | "C:\Program Files\Git\usr\bin\xargs.exe" -d '\n' -I {} powershell -Command Start-Process -Verb Runas -Filepath wt -ArgumentList 'powershell', '-noexit', '-command', 'Set-Location', '-LiteralPath', "'''\"{}\"''.Replace(''==%'',''%'')'" "</code>

* Cygwin系なしで

<code>cmd /c "chcp 65001 & powershell -Command Start-Process -Verb Runas -Filepath wt -ArgumentList 'powershell', '-noexit', '-command', 'set-location', '-literalpath', ('\"'''+($input -replace '''', '''''' -replace '%', '==%' -replace ';', '\;' )+'''.Replace(''==%'',''%'')\"') "</code>


=== cmd ===


==== デフォルトシェル ====

再び、startatdir.vbsを使う。

<code>cmd /c chcp 65001 > nul & powershell -Command "$mypath=($input | ForEach-Object { return $_ });$bak=$env:MY_PERCENT; $env:MY_PERCENT = '%';if ($mypath.Length -gt 258) { $mypath = cmd /c \"for %A in (`\"$($mypath.Replace('%', '%MY_PERCENT%'))`\") do @echo %~sA\" };$env:MY_PERCENT = $bak; Start-Process -Verb Runas -Filepath wscript -Argumentlist '//Nologo', 'C:\path\to\startatdir.vbs', 'cmd', ('\"'+$mypath+'\"')"</code>


==== Windows Terminal ====

<code>cmd /c chcp 65001 & powershell -Command "$mypath=($input | ForEach-Object { return $_ }); $bak=$env:MY_PERCENT; $env:MY_PERCENT = '%';if ($mypath.Length -gt 258) { $mypath = cmd /c \"for %A in (`\"$($mypath.Replace('%', '%MY_PERCENT%'))`\") do @echo %~sA\" };$env:MY_PERCENT = $bak;Start-Process -Verb Runas -Filepath wt -Argumentlist '-d', ('\"'+($mypath -replace '\\$','\\\\' -replace ';', '\;')+'\"'), cmd"</code>

この場合は<code>C:\</code>のための対処（<code>-replace '\\$','\\\\'</code>）が必要である。259文字のフォルダを無視するなら以下の通り。

<code>cmd /c "chcp 65001 & powershell -Command Start-Process -Verb Runas -Filepath wt -ArgumentList '-d', ('\"'+($input -replace '\\$','\\\\').Replace(';','\;')+'\"'), cmd"</code>


== 2.直接コマンド記入の右クリックメニュー ==

レジストリの<code>command</code>キーの既定の値に直接コマンドを記入する方式である。

デフォルトでは、右クリックメニューを押した時点でのフォルダ（フォルダを右クリックするメニューからだと対象フォルダの親、フォルダ背景を右クリックするメニューなら対象フォルダ）をカレントディレクトリとしてコマンドが起動される。そのため<code>\\?\</code>を付けなければならないような長大なパスのフォルダでは動作しない。しかし、<code>shell\xxxx</code>キーに<code>NoWorkingDirectory</code>値を設定することで、カレントディレクトリが必ず<code>C:\Windows\System32</code>に設定されるようになるので動くようになる。

対象のディレクトリはどう取得するかというと、レジストリに書き込んだ値のうち<code>%V</code>という部分が対象ディレクトリに書き換えられてコマンドが実行される。この<code>%V</code>もC:などの場合は<code>C:\</code>になる。コマンドの中でそのまま%という文字を使いたい場合はバッチファイルと同様に%%とエスケープする必要があるようである（これはどこにも書いてない？）。

しかし、こうして渡される（特殊文字を含むかもしれない）ディレクトリ名を完璧に取得するのは意外と難しい。cmdに解釈させると<code>%</code><code>VAR</code><code>%</code>が置換されてしまうし、シングルクォートとバッククォートが両方含まれているのでpowershellやshに渡すのも簡単ではない。

コツは、powershell -commandやsh -cの中に直接書くのではなく、スクリプトへのコマンドライン引数として渡した上で、スクリプト内で引数として取得することである。それぞれ、基本形（そのまま出力するだけ）は以下のようになる。

<ul>
<li>powershell
<code>powershell -Command "& {echo $args[1].Trim('\"')}" --%% "\"%V\""</code>
<ul>
<li><code>--%</code>というトークンを入れることでその後のパラメータの解析を行わないようにできる。args[0]は<code>--%</code>になるのでargs[1]を使う。レジストリに書く際は<code>%</code>をエスケープして<code>--%%</code>。</li>
<li><code>--</code>でも同様のことができる？<code>powershell -Command "& {echo $args[0].Trim('\"')}" -- "\"%V\""</code>（args[0]になっていることに注意）</li>
<li>というか、<code>--%</code>で書き進めてしまったが、本当は<code>--</code>のほうが安定するかもしれない。</li></ul>

あるいは<code>$MyInvocation.Line</code>を使う方法もある。この場合、powershellへの引数が全て（この例なら<code>-noexit -Command "& {$spl = ...</code>のところから）取得されるので、目当ての部分を取り出すためにここでは最後から2番目の<code>"</code>と最後の<code>"</code>の間を取得するという風にしている。
<code>powershell -noexit -Command "& {$spl = $MyInvocation.Line -split'\"' ; Set-Location -LiteralPath $spl[$spl.Length-2]}" --%% "\"%V\""</code>
昔のPowerShell（2くらい）で試してみたらこちらでないと<code>`</code>や<code>&</code>あたりの処理がうまくいかない場合があった。argsを使うものからの書き換えは容易である。</li>
<li>sh
<code>sh -c "IFS=;echo $*" -- "%V</code>
<ul>
<li>最後が<code>"%V</code>と閉じられていないのはミスではなく、<code>"%V"</code>としてしまうと<code>C:\</code>のときに<code>C:"</code>が渡されてしまうのでそれを避けるためである（これはかなりトリッキーなのでもう少し真面目にやってもいいとは思う）。</li>
<li>UNCパスの最初の<code>\\</code>が<code>\</code>に変わってしまう（手元では、Cygwinの場合は<code>\\?\</code>のみで発生している？）という問題があり、適宜置換する必要がある。</li></ul>
</li></ul>

これらの書き方はいわゆる「ワンライナー」的なものであるが、もちろん外部にスクリプトファイルを用意してもよい。

また、外部にスクリプトを用意してよいという条件であれば、vbsも使用可能である。

<ul>
<li>この場合、まずレジストリには
<code>wscript "C:\path\to\script.vbs" "%V"</code>
などと書く。スクリプトの内容は上記のレジストリの内容をほぼそのままWscript.ShellでRunすればよいが、<code>%V</code>のかわりにWscript.Arguments(0)を挿入するのと、<code>%</code>を<code>%%</code>にエスケープしなくてよいのと、VBSなので文字列内の<code>"</code>は<code>""</code>に変えなければならない。これに加え、Runの引数に含まれる<code>%</code><code>VAR</code><code>%</code>が置換の対象となるため、対象フォルダの文字列については<code>==%</code>への置換でエスケープして、呼び出し先のpowershellなどで元に戻す。</li>
<li>必要に応じてRunのオプションでvbHideを指定する。</li>
<li>というか別に258文字を超えていたら云々みたいな処理も全部vbs側でやってしまってもよい（面倒なのでそういう例は載せていない）</li></ul>

バッチファイルに渡すのは、バッチファイルをcmdが呼び出す時点で<code>%PATH%</code>のようなファイル名の環境変数は既に展開されてしまうので、どうやっても不可能。

他には、（hiderunと）piperunとpechoを併用するという方法もあり、それらの実行ファイルを用意する必要があるという以外は綺麗にできる方法である。

いずれにしろ、一旦取得できてしまえばあとは前述の<code>openterm</code>に流し込むだけでよい。ただ、実際にはわざわざ<code>openterm</code>に流し込まなくても（パイプを使わなくても）もっと簡単に起動できることもあるのでそちらを中心に紹介する。

* commandの最初で指定する（メインの）実行ファイル（先ほどなら<code>powershell</code>や<code>sh</code>）をファイル名単体で書く場合は、それが（メニューをHKCUで設定するならHKCUの（最近のWindowsならHKLMのでも可？）、HKLMで設定するならHKLMの）App Pathsキーに登録されていなければならない（PATHは通っていなくてもいい）。登録されていない場合はフルパスで指定する必要がある。

=== 設定例 ===

==== 管理者権限なし ====

<ul>
<li>PowerShell
デフォルトターミナルで
<code>powershell -noexit -Command "& {Set-Location -LiteralPath $args[1].Trim('\"')}" --%% "\"%V\""</code>
<ul>
<li>参考までに、Windowsにもともと入っているメニューでは以下のようになっている。
<code>powershell.exe -noexit -command Set-Location -literalPath '%V'</code>
これだとシングルクォートと連続スペースに対応できない。連続スペースだけなら<code>'%V'</code>を<code>"'%V'"</code>に変えると解決できる。<code>%$[]`</code>あたりは見た感じ問題なし。
<ul>
<li>以下の解決策でもまだ不完全 [https://superuser.com/questions/1310258/open-powershell-window-here-file-explorer-context-menu-command-breaks-with-fol "Open PowerShell window here" File Explorer context-menu command breaks with folder names with apostrophes (single quotes) - Super User]</li></ul>
</li>
<li>この問題は[https://github.com/PowerShell/PowerShell/issues/6598 https://github.com/PowerShell/PowerShell/issues/6598]や[https://github.com/PowerShell/PowerShell/pull/6660 https://github.com/PowerShell/PowerShell/pull/6660] で扱われており、結局pwshでは-WorkingDirectoryというパラメータが追加された。[https://github.com/PowerShell/PowerShell/issues/14091 https://github.com/PowerShell/PowerShell/issues/14091]にある以下の文字列をレジストリに書いたところ、正しく動作したので、pwshではこれでよい。
<code>pwsh.exe -NoExit -RemoveWorkingDirectoryTrailingCharacter -WorkingDirectory "%V!" -Command "$host.UI.RawUI.WindowTitle = 'PowerShell 7 (x64)'"</code></li></ul>

wtで
<code>hiderun powershell -Command "& {wt powershell -noexit -Command Set-Location -LiteralPath ('\"'''+($args[1] -replace '''', '''''' -replace '%%', '==%%' -replace ';', '\;' )+'''.Replace(''==%%'',''%%'')\"')}" --%% "\"%V\""</code></li>
<li>cmd
wtで。標準入力のときとほぼ同じ。
<code>powershell -Command "& {$bak=$env:MY_PERCENT;$mypath=$args[1].Trim('\"'); $env:MY_PERCENT = '%%';if ($mypath.Length -gt 258) { $mypath = cmd /c \"for %%A in (`\"$($mypath.Replace('%%', '%%MY_PERCENT%%'))`\") do @echo %%~sA\" };$env:MY_PERCENT = $bak;wt -d ($mypath -replace ';', '\;') cmd}" --%% "\"%V\""</code>
<ul>
<li>デフォルトターミナルで
startatdir.vbsを使う。
<code>powershell -Command "& {$bak=$env:MY_PERCENT;$mypath=$args[1].Trim('\"'); $env:MY_PERCENT = '%%';if ($mypath.Length -gt 258) { $mypath = cmd /c \"for %%A in (`\"$($mypath.Replace('%%', '%%MY_PERCENT%%'))`\") do @echo %%~sA\" };$env:MY_PERCENT = $bak; wscript 'C:\path\to\startatdir.vbs' cmd ('\"'+$mypath+'\"')}" --%% "\"%V\""</code></li>
<li>Windowsにもともと入っているメニューでは以下。
<code>cmd.exe /s /k pushd "%V"</code>
これは（<code>\\?\</code>が付くパスを除いて）ほとんどの場合に正しく機能するが、<code>%PATH%</code>のような文字列が含まれているフォルダではうまくいかない。ちなみにpushdによりUNCパスには自動的にネットワークドライブが割り当てられる。</li></ul>
</li>
<li>Git Bash
<ul>
<li>mintty（git-bash.exe使用）
<code>"C:\Program Files\Git\git-bash.exe" -c "IFS=;cd $(echo $*|/bin/sed 's/\\\\/\\\\\\\\/'|/bin/cygpath -f -);exec bash" -- "%V</code>
<ul>
<li>Git Bashのインストーラにより設定される「Git Bash Here」メニューでは以下のようになっている。
<code>"C:\Program Files\Git\git-bash.exe" "--cd=%v."</code>
これは、特殊文字にはすべて対応しているが、（NoWorkingDirectoryをつけたとしても）<code>\\?\</code>で始まるパスではうまくいかない。最後の「.」はよくわからないがこれを付けておくと<code>--cd</code>がうまくやってくれるっぽい。</li></ul>
</li>
<li>デフォルトシェルで
<code>"C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=;cd $(echo $*|/bin/sed 's/\\\\/\\\\\\\\/'|/bin/cygpath -f -);export MSYSTEM=MINGW64;exec /bin/bash --login" -- "%V</code></li>
<li>wtで
<code>hiderun "C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=;LANG=en_US.UTF8; echo $*|/bin/sed 's/\\\\/\\\\\\\\/'|/bin/cygpath -f -|printf %%q $(/bin/sed 's/%%/=%%/g')|/bin/sed 's/;/\\\\;/g'|/bin/xargs -d '\n' -I {} -- wt \"C:\Program Files\Git\usr\bin\env.exe\" MSYSTEM=MINGW64 \"C:\Program Files\Git\usr\bin\bash.exe\" --login -i -c 'IFS=\\;cd $(echo {}|sed s/=%%/%%/g)\\;exec bash'" -- "%V</code></li></ul>
</li>
<li>Cygwin
<ul>
<li>デフォルトシェルで
<code>"C:\cygwin64\bin\sh.exe" --login -c "IFS=;cd $(echo $*|/bin/sed 's/\\\\?/\\\\\\\\?/'|/bin/cygpath -f -);exec bash" -- "%V</code>
<ul>
<li>置換の対象を<code>\\?\</code>のみとするためsedの引数に<code>?</code>が増えている</li></ul>
</li>
<li>wtで
<code>hiderun "C:\cygwin64\bin\sh.exe" -c "IFS=;echo $*|/bin/sed 's/\\\\?/\\\\\\\\?/'|/bin/cygpath -f -|printf %%q $(/bin/sed 's/%%/=%%/g')|/bin/sed 's/;/\\\\;/g'|/bin/xargs -d '\n' -I {} -- wt \"C:\cygwin64\bin\bash.exe\" --login -i -c 'IFS=\\;cd $(echo {}|sed s/=%%/%%/g)\\;exec bash'" -- "%V</code></li></ul>
</li></ul>

==== 管理者権限 ====

<ul>
<li>PowerShell
<code>powershell -Command "& {Start-Process -Verb Runas -Filepath wt -Argumentlist powershell, -noexit, -command, Set-Location, -LiteralPath, ('\"'''+($args[1].Trim('\"') -replace '''', '''''' -replace ';', '\;' -replace '%%', '==%%')+'''.Replace(''==%%'',''%%'')\"')}" --%% "\"%V\""</code>
環境変数の置換を抑止する必要がある。デフォルトシェルで起動するならこれは不要（で、wtでないので<code>;</code>のエスケープも不要）で、以下のようになる。
<code>powershell -Command "& {Start-Process -Verb Runas -Filepath powershell -Argumentlist '-noexit', '-command', Set-Location, '-LiteralPath', ('\"'''+($args[1].Trim('\"') -replace '''', '''''' )+'''\"')}" --%% "\"%V\""</code>
<ul>
<li>MyInvocationを使う例
<code>powershell -Command "& {$spl = $MyInvocation.Line -split'\"'; Start-Process -Verb Runas -Filepath powershell -Argumentlist '-noexit', '-command', Set-Location, '-LiteralPath', ('\"'''+($spl[$spl.Length-2] -replace '''', '''''' )+'''\"')}" --%% "\"%V\""</code></li>
<li>vbsの例
次の節で解説する「（自分が起動された）カレントディレクトリでの起動」にも対応している（引数がない場合）。
<syntaxhighlight lang="vb.net">Dim objShell
Dim curDir

Set ws = CreateObject("Wscript.Shell")
Dim dir
If WScript.Arguments.Count = 0 Then
dir = ws.CurrentDirectory
Else
dir = Wscript.Arguments(0)
End If
dir = Replace(dir,"%","==%")
ws.run "powershell -Command ""& {Start-Process -Verb Runas -Filepath wt -Argumentlist powershell, -noexit, -command, Set-Location, -LiteralPath, ('\""'''+($args[1].Trim('\""') -replace '''', '''''' -replace ';', '\;' )+'''.Replace(''==%'',''%'')\""')}"" --% ""\"""&dir&"\""""", vbHide

Set objShell = Nothing</syntaxhighlight></li></ul>
</li>
<li>cmd
<code>powershell -Command "& {$bak=$env:MY_PERCENT;$mypath=$args[1].Trim('\"'); $env:MY_PERCENT = '%%';if ($mypath.Length -gt 258) { $mypath = cmd /c \"for %%A in (`\"$($mypath.Replace('%%', '%%MY_PERCENT%%'))`\") do @echo %%~sA\" };$env:MY_PERCENT = $bak;Start-Process -Verb Runas -Filepath wt -Argumentlist '-d', ('\"'+($mypath -replace '\\$','\\\\' -replace ';', '\;')+'\"'), cmd}" --%% "\"%V\""</code>
この場合も<code>C:\</code>のための対処（<code>-replace '\\$','\\\\'</code>）が必要である。デフォルトシェルなら、startatdir.vbsを使う。
<code>powershell -Command "& {$bak=$env:MY_PERCENT;$mypath=$args[1].Trim('\"'); $env:MY_PERCENT = '%%';if ($mypath.Length -gt 258) { $mypath = cmd /c \"for %%A in (`\"$($mypath.Replace('%%', '%%MY_PERCENT%%'))`\") do @echo %%~sA\" };$env:MY_PERCENT = $bak;Start-Process -Verb Runas -Filepath wscript -Argumentlist '//Nologo', 'C:\path\to\startatdir.vbs', 'cmd', ('\"'+$mypath+'\"')}" --%% "\"%V\""</code></li>
<li>Git Bash
理論上はワンライナーでも書けるが、エスケープが面倒すぎるのでファイルに書いたほうがよいだろう。まずレジストリの中身は以下のようにする。
<code>"C:\Program Files\Git\usr\bin\sh.exe" "C:\path\to\gb-wt-admin.sh" "%V"</code>
で、<code>gb-wt-admin.sh</code>の中身は以下。
<syntaxhighlight lang="bash">#!/bin/sh
IFS=
LANG=en_US.UTF-8
echo $*|/bin/sed 's/\\/\\\\/'|/bin/cygpath -f -|printf %q $(/bin/cat) |/bin/sed "s/'/''/g;s/%/==%/g;s/;/\\\\;/g"|/bin/xargs -d '\n' -I {} powershell -Command Start-Process -Filepath wt -ArgumentList "'"'"C:\Program Files\Git\usr\bin\env.exe"'"'" , '"MSYSTEM=MINGW64"' , "'"'"C:\Program Files\Git\usr\bin\sh.exe"'"'" , "'--login'", "'-c'", "'"'"IFS=\;cd $(echo {}| /bin/sed s/==%/%/g) \; exec bash"'"'"</syntaxhighlight>
Cygwinも同様である。</li></ul>


==== VS Codeのメニュー（おまけ） ====

「Code で開く」メニューのcommand値は以下のように設定されている。

<code>"C:\Program Files\Microsoft VS Code\Code.exe" "%V"</code>

これは特殊文字などに関しても問題なく動作するうえ、実はそのまま<code>\\?\</code>が付いたパスにも適用可能である。従って、<code>VSCode</code>キーに<code>NoWorkingDirectory</code>値を設定する（設定の書き換えまたはHKCUによるオーバーライド）だけで、長大フォルダでもVS Codeが使えるようになる。ターミナルの起動には失敗してしまうがファイル・フォルダの作成・編集などの基本操作がGUIでできるので意外と便利（もちろん、他のBetter Explorer的なツールを使う手もあるだろう）。


== 3. エクスプローラーのアドレスバーから ==

このときは、末尾が空白のパスや<code>\\?\</code>が必要な長大パスやちょうど259文字のフォルダはそもそも対応していないので考えなくてよい。しかし通常のネットワークファイル向けのUNCパス（<code>\\192.168.1.1\disk</code>など）に対応する必要はあるので、cmdをベースにすることはできない（cmdの中に入った時点でカレントディレクトリが変わってしまう）。また<code>``</code>が含まれるパスをカレントディレクトリにできないことから、powershell.exeもベースとしては使えない。

なので、パイプを使って先ほどの<code>openterm</code>にむけて流し込もうと思ったら選択肢はpwsh.exeかpiperunかCygwin系だけである。それぞれの書き方は以下のようになる。

<ul>
<li>pwsh
<code>pwsh -Command $pwd.Path.Replace('Microsoft.PowerShell.Core\FileSystem::\\', '\\') | openterm</code></li>
<li>piperun
<code>piperun pwsh -Command $pwd.Path.Replace('Microsoft.PowerShell.Core\FileSystem::\\', '\\') | openterm</code>
上とほぼ変わっていないが、pwshはディレクトリの取得だけで使っているので<code>openterm</code>のところで環境変数が汚染されるのを防げる。</li>
<li>Cygwin/Git Bash
<code>"C:\Program Files\Git\usr\bin\sh.exe" -c "cmd //c \"chcp 65001 > nul\"| pwd | /bin/cygpath -w -f - | openterm"</code>
<ul>
<li>一つ問題があり、hiderunを使う（コンソールを非表示にする）とchcpが効かないようで、<code>openterm</code>でPowerShellの<code>$input</code>を使っているとUnicode文字が化けてしまう。</li>
<li>先ほどの<code>openterm</code>部分で先頭にcygpathが入っているものを使うときは、そちらのcygpathとこちらでのcygpath -wは打ち消し合って無駄なので消してよい。</li></ul>
</li></ul>

このほかにvbs(wscript)もカレントディレクトリの取得のところは問題なくやってくれるので、それをさっきのWscript.Arguments(0)のかわりに使えばよい。

最初に表示されるコンソールを非表示にしたければ、<code>hiderun</code>を付けてrunother経由で実行するのが手軽だが、前述の通りvbsも拡張子無しで呼び出せるように設定できるので、そうした上でvbHideで隠してもよい。


=== 管理者権限なし ===


==== cmd ====

これは普通にcmdと打てばよい。

（デフォルトシェルがconhostだとして）wtで開きたいときは、;をエスケープして-dで渡す。以下の通りbatファイルを作ってpathを通す。

<code>chcp 65001 & cd | powershell -Command wt -d $input.Replace(';','\;') cmd</code>

wtではなくconhostの場合はconhost cmdだけでよい。batにするなら<code>start "" conhost cmd</code>でよい。

コンソール非表示ならcmd /cをつけてhiderunする。runotherで、txtの中身は以下の通り。

<code>hiderun cmd /c chcp 65001 & cd | powershell -Command wt -d $input.Replace(';','\;') cmd</code>


==== powershell, pwsh ====

pwshはそのままpwshと打てばよい。powershell及びwtやconhostを明示的に指定する場合について以下で述べる。

たとえばwtでpwshなら、runotherを使って、txtの内容は以下。

<code>hiderun pwsh -Command wt -d $pwd.Path.Replace('Microsoft.PowerShell.Core\FileSystem::\\', '\\').Replace(';', '\;') pwsh</code>

powershellの場合は<code>``</code>に対応するため起動後に移動する。runotherでpiperunを使って、txtは以下。最終的に起動する方のpowershellで<code>==%</code>を<code>%</code>に戻している。

<code>hiderun piperunex cmd /c chcp 65001 | printcd | powershell -Command wt powershell -noexit -command Set-Location -LiteralPath ('"'''+($input -replace ';', '\;' -replace '''', '''''' -replace '%', '==%')+'''.Replace(''==%'',''%'')"')</code>

pwshが使えるならprintcdのかわりに<code>pwsh -Command $pwd.Path.Replace('Microsoft.PowerShell.Core\FileSystem::\\', '\\')</code>でもよい。

以下はpiperunを使わずshでやる例。前述の通りパイプからPowerShell側で<code>$input</code>を使って受け取ると文字化けするので引数として渡す。

<code>hiderun "C:\Program Files\Git\usr\bin\sh.exe" -c "WD=$(pwd | /bin/cygpath -w -f - | /bin/sed \"s/;/\\\\\\\\;/g; s/'/''/g; s/%/==%/g\"); wt powershell -noexit -command Set-Location -LiteralPath $\"'$WD'.Replace('==%','%')\"$"</code>


==== Git Bash/Cygwin ====

Git Bashは<code>--login</code>をつけてもカレントディレクトリを維持するので単純である。以下をrunotherのtxtに書く。

<code>"C:\Program Files\Git\usr\bin\env.exe" MSYSTEM=MINGW64 /bin/bash --login</code>

Cygwinは起動後にcdする。そのかわり<code>export MSYSTEM=MINGW64</code>が不要。

<code>"C:\cygwin64\bin\sh.exe" -c "IFS=;/bin/bash --login -i -c 'cd '$(/bin/printf %q `pwd`)'; exec bash'"</code>

printfで一旦エスケープしたものをcdの後につなげてそのまま渡している。

<ul>
<li>wtで
<ul>
<li>Git Bash
<code>wt "C:\Program Files\Git\usr\bin\env.exe" MSYSTEM=MINGW64 "C:\Program Files\Git\usr\bin\bash.exe" --login"</code>
<ul>
<li>あれ、wtなのにカレントディレクトリ維持されてる…？wt cmdではダメなのだが…</li></ul>
</li>
<li>Cygwin
<code>hiderun "C:\cygwin64\bin\sh.exe" -c "IFS=;WD=$(printf %q `pwd` | /bin/sed \"s/;/\\\\\\\\;/g; s/%/==%/g\"); wt \"C:\cygwin64\bin\bash.exe\" --login -c 'IFS=\\;cd $(echo '$WD'|sed s/==%/%/g)\\; exec bash'"</code></li></ul>
</li></ul>

=== 管理者権限あり ===


==== cmd ====

runotherを使って以下の通り。

<code>hiderun cmd /c "chcp 65001 > nul & cd | powershell -Command Start-Process -Verb Runas -Filepath wt -ArgumentList '-d', ('\"'+$input.TrimEnd('\\').Replace(';','\;')+'\"'), cmd"</code>

<code>TrimEnd('\\')</code>のところは<code>C:\</code>の末尾のバックスラッシュへの対応である（<code>wt -d "C:"</code>は通らないので一見ダメそうだが、なぜかこれで動く。原因不明。）。

batならそのまま以下の通り（黒い画面が一瞬出てしまう）。

<code>chcp 65001 & cd | powershell -Command Start-Process -Verb Runas -Filepath wt -ArgumentList '-d', ('\"'+$input.TrimEnd('\\').Replace(';','\;')+'\"'), cmd</code>

別解としてパイプを使わないものも載せておこう。cmdでは特殊文字ではないので<code>'</code>を<code>''</code>に変えるのは簡単である。

<code>hiderun cmd /c powershell -Command "& {Start-Process -Filepath wt -Verb Runas -ArgumentList '-d', ('\"'+$args[0].TrimEnd('\\').Replace(';','\;')+'\"'), cmd}" -- "'%CD:'=''%'"</code>

以下もうまくいく。cmdの<code>"</code>に関する仕様により、例えばStart-Processの直前に<code>echo '\"';</code>のような<code>"</code>を奇数個含む文字列を入れると動かなくなる。argsを使うとバッククォートがうまくいかなかったのでMyInvocationを使ってみる。

<code>hiderun cmd /c powershell -Command "& {$spl=$MyInvocation.Line.Split('\"'); Start-Process -Filepath wt -Verb Runas -ArgumentList '-d', ('\"'+$spl[$spl.Length-2].TrimEnd('\\').Replace(';','\;')+'\"'), cmd}" -- "\"%CD%\""</code>


==== powershell, pwsh ====

UNC非対応でよく、かつ（<code>``</code>をカレントディレクトリとして起動できる）pwshでよければ、上記のcmdをpwshに変えればよい。powershellならSet-Locationで移動が必要。以下をrunotherのtxtに書く。

<code>hiderun cmd /c "chcp 65001 & cd | powershell -Command Start-Process -Verb Runas -Filepath wt -ArgumentList 'powershell', '-noexit', '-command', 'Set-Location', '-LiteralPath', ('\"'''+($input -replace '''', '''''' -replace '%', '==%' -replace ';', '\;' )+'''.Replace(''==%'',''%'')\"')"</code>

UNC対応なら、管理者でないときと同じで、PSReadLineのエラーを回避するためpwshを一貫して使うのがいいだろう。

<code>hiderun pwsh -Command Start-Process -Verb Runas -Filepath wt -ArgumentList '-d', ('\"'+$pwd.Path.Replace('Microsoft.PowerShell.Core\FileSystem::\\', '\\').TrimEnd('\\').Replace(';','\;')+'\"'), pwsh</code>

powershellならpiperunを使う。カレントディレクトリの取得にpwshを使っているがprintcdでもよい。

<code>hiderun piperunex cmd /c chcp 65001 | printcd | powershell -Command Start-Process -Verb Runas -FilePath wt -ArgumentList powershell, -noexit, -command, Set-Location, -LiteralPath, ('\"'''+($input -replace ';', '\;' -replace '''', '''''' -replace '%', '==%')+'''.Replace(''==%'',''%'')\"')</code>

shなら以下。

<code>hiderun "C:\Program Files\Git\usr\bin\sh.exe" -c "WD=$( pwd | /bin/cygpath -w -f - | /bin/sed \"s/;/\\\\\\\\;/g; s/'/''''/g; s/%/==%/g\"); powershell -Command Start-Process -Verb Runas -Filepath wt -Argumentlist powershell, -noexit, -command, Set-Location, -LiteralPath, $\"'\\\"''$WD''.Replace(''==%'',''%'')\\\"'\"$"</code>


==== Git Bash ====

runotherとpiperunで以下。

<code>hiderun piperunex "C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=; LANG=en_US.UTF8; pwd || printf %q $(/bin/cat)" | "C:\Program Files\Git\usr\bin\sed.exe" "s/'/''/g;s/%/==%/g;s/;/\\\\;/g" | "C:\Program Files\Git\usr\bin\xargs.exe" -d '\n' -I {} -- powershell -Command Start-Process -Verb Runas -Filepath wt -ArgumentList '"C:\Program Files\Git\usr\bin\sh.exe"','-c', "'"'"IFS=\\; export MSYSTEM=MINGW64\\;cd $(echo {}|| /bin/sed s/==%/%/g)\\; exec /bin/bash --login"'"'"</code>

* <code>MSYSTEM=MINGW64</code>をもっと手前で設定して、<code>-ArgumentList</code>で<code>--login</code>を指定して、最後を<code>exec bash</code>にしてもよい。

piperunを使わずにshで頑張ることもできるが、エスケープが多く読みづらくなる。

<code>hiderun "C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=; LANG=en_US.UTF8; pwd | printf %q $(/bin/cat) | /bin/sed \"s/'/''/g;s/%/==%/g;s/;/\\\\\\\\;/g\" | /bin/xargs -d '\n' -I {} -- powershell -Command Start-Process -Verb Runas -Filepath wt -ArgumentList '\"C:\Program Files\Git\usr\bin\sh.exe\"','-c', \"'\"'\"IFS=\\; export MSYSTEM=MINGW64\\;cd $(echo {}| /bin/sed s/==%/%/g)\\; exec /bin/bash --login\"'\"'\" "</code>

Cygwinも同様。

== 関連 ==

[https://qiita.com/octopath9/items/4b7fe797ae1155c69dd9 コマンドプロンプトから管理者権限のコマンドプロンプトに切り替える - Qiita]

[https://qiita.com/tmiki/items/0dab4fd17e9bed04ed91 【Windows】GitBashをcontext menuからAdministrator権限付きで実行する - Qiita]

[https://note.com/redpeak/n/n5ddc3673117b エクスプローラーから管理者権限でコマンドプロンプトを開く方法｜ひるあんどん]
[[Category:IT]][[Category:Windows]]{{#seo:|title={{FULLPAGENAME}} - Turgenev's Wiki}}

Twitter

2025-05-05T01:30:27Z

Turgenev: Notion-MW

== 疑似TweetDeck ==

TweetDeckのバージョンが新しくなり、有料化された。どうやら新バージョンのTweetDeckでも複数アカウント表示はできるらしく、しかも1アカウントだけ課金すれば十分という情報もあるが、ここでは課金せずに複数アカウントを並べる方法を紹介する。といっても技術的には何も興味深いことはなく、単に別プロファイルでブラウザを複数起動してアカウントを使い分けるのを多少やりやすくしたという程度である。

具体的には、まずウインドウスタイルと表示領域の変更によってタイトルバーなど無駄な領域を削減し、自動でサイズと位置を調整して画面上に同じサイズで綺麗に並ぶようにした。さらに、ショートカットキーを用いて全ウインドウ一度に表示（Ctrl+Alt+Shift+<code>.</code>）/非表示（Ctrl+Alt+Shift+<code>,</code>）の切り替えができるようにした。

実装にはAutoHotkeyを用いた（Windowsのみで動作確認）。スクリプト例ではChromeを使用しているが、単にウインドウを等間隔に並べて表示/非表示を切り替えるだけなので、何のソフトでも構わない（ただしタイトルバーでのウインドウの検出などは普通にできる必要がある）。自動リロード機能なども特に実装していない。（単にブラウザを動かしているだけなので拡張機能など使えばよい）

* chromeを起動するところの<code>--app-id=jgeocpdicgmkeemopbanhokmhcgcflmi</code>の部分については[[Webブラウザ（Chrome）|Webブラウザ（Chrome）]]のPWAのところを参照。

<syntaxhighlight lang="plain text">; ウインドウのアクティベート時に強引な方法を用いる（FlashWindowだけで終わってしまうのを避ける）？
#WinActivateForce

; Windowsのディスプレイのworkarea（ディスプレイからタスクバーの部分を除いたもの）を縦にn分割し、n個のウインドウを並べる。
; Windowsでは、Region指定によりウインドウの一部の長方形領域だけを表示することができるので、これを利用して画面の無駄な余白を削る。
; ただし通常のウインドウスタイルだと不自然な表示になることがあるので、ボーダーレスウインドウ（0x00000080、WS_EX_TOOLWINDOW）を指定している。
; 概念的には、3種類の領域を想定している。狭いほうから順に、
; 1. メイン領域…そのウインドウの「持ち分」であると考えられるメインの表示領域。これが互いに被らないように画面をn分割する。
; 2. 可視領域…ウインドウが実際に画面上で表示されているサイズ。つまり、各ウインドウは、ディスプレイの端や他のウインドウの上に少しずつはみ出して表示されている。（隙間から背景をクリックしてしまうことがなくなり、動作が安定する）
; 3. ウインドウ領域…Windowsでの内部的なウインドウの領域。Region指定により、一部は不可視になっている。
; 以下では、ウインドウ領域に入っているが可視領域に入っていない部分を「不可視領域」、可視領域に入っているがメイン領域に入っていない領域を「オーバーラップ領域」と呼ぶ。

; 左右の不可視領域の幅
Global off_wid_sum := 10 + 5
; 上部の不可視領域の幅（タイトルバーがあるので大きめ）（下部には不可視領域を設定していない）
Global off_top_add = 30

; 上下と左右のオーバーラップ領域
Global off_wid_overlap = 4
Global off_hei_overlap = 8

; タスクバーの位置とサイズを取得
SysGet, TaskBar, MonitorWorkArea, 0
Global num_of_decks := 3

; メイン領域
Global Width_org := (TaskBarRight-TaskBarLeft) // num_of_decks
Global Height_org := TaskBarBottom-TaskBarTop

; 可視領域
Global Width_3 := Width_org+off_wid_overlap*2
Global MyHeight := Height_org+off_hei_overlap*2

; ウインドウを移動する際に、上にスナップした扱いにならないための安全な距離
Global safe_dist_border = 10
; 角にスナップした扱いにならないように、（横方向の）中央付近をつかむ
Global safe_dist_wid := Width_3 / 2

; この文字列で対象アプリケーションの起動を検出
Global TitleStr := "Twitter"

SetBorderlessWindow(ByRef this_id)
{
; 非クライアント領域のレンダリングを無効に
DllCall("dwmapi\DwmSetWindowAttribute", "ptr", this_id, "uint", DWMWA_NCRENDERING_POLICY := 2, "int*", DWMNCRP_DISABLED := 1, "uint", 4)
;これらは役に立たない
;WinSet, Style, -0x80000000, ahk_id %this_id%
;WinSet, Style, -0x00020000, ahk_id %this_id%
;WinSet, Style, -0x00040000, ahk_id %this_id%
WinSet, ExStyle, 0x00000080, ahk_id %this_id%
; 可視領域の設定
WinSet, Region, W%Width_3% H%MyHeight% %off_wid_sum%-%off_top_add%, ahk_id %this_id%

}

; 与えられた座標にメイン領域を設定する関数
PlaceWindowAtPos(ByRef this_id, x, y)
{
; ウインドウサイズの設定。負の座標には直接は動かせない（動かすと、強制的に違うサイズにされてしまった）ので、一旦正の座標に動かしてからマウスで移動
WinMove, ahk_id %this_id%,, x, y, Width_3 + off_wid_sum*2, MyHeight+off_top_add ;
SetBorderlessWindow(this_id)
WinSet, Redraw, , ahk_id %this_id%
Sleep, 300
MouseClickDrag, LEFT, safe_dist_wid + safe_dist_border + off_wid_sum + off_wid_overlap, safe_dist_border + off_top_add + off_hei_overlap, safe_dist_wid + safe_dist_border, safe_dist_border, 5
}

; メイン部分
; TitleStrがタイトルになっている既存のウインドウがあれば無視したいので、配列に格納
MyTitleHandles := []
WinGet, windows, List, %TitleStr%
Loop, %windows%
{
this_id := windows%A_Index%
MyTitleHandles[this_id] := true
}

ProfileNames:=["""Default""", """Profile 6""" ,"""Profile 5"""]
Wins:=[]
Loop, %num_of_decks%
{
; Twitterの起動
win_index := A_Index
Prof := ProfileNames[A_Index]
; idはtwitter.comが提供するマニフェストからchromeが計算した結果必ずこれになる
Run, "C:\Program Files\Google\Chrome\Application\chrome_proxy.exe" --profile-directory=%Prof% --app-id=jgeocpdicgmkeemopbanhokmhcgcflmi

Loop, {
Sleep, 222
WinGet, newWindows, List, %TitleStr%
Loop, %newWindows%
{
this_id := newWindows%A_Index%
if (!MyTitleHandles.HasKey(this_id))
{
Sleep, 300
; Indexに応じたメイン領域を設定
PlaceWindowAtPos(this_id, (win_index-1)*Width_org, TaskBarTop)
MyTitleHandles[this_id] := true
Wins[win_index] := this_id
Goto, NEX
}
}
}

NEX:
}

OnExit, ExitSub
; 開始処理はここで終了
return

; 常駐してショートカット処理
^!+,:: ; Ctrl+Alt+Shift+,
{
Loop, %num_of_decks%
{
wintemp := Wins[A_Index]
WinHide, ahk_id %wintemp%
}
}
return

^!+.:: ; Ctrl+Alt+Shift+.
{
Loop, %num_of_decks%
{
wintemp := Wins[A_Index]
WinShow, ahk_id %wintemp%
}
Sleep, 100
Loop, %num_of_decks%
{
wintemp := Wins[A_Index]
WinActivate ahk_id %wintemp%
SetBorderlessWindow(wintemp)
}
}
return

; 新しいインスタンスによって置換される際には（←これに限定しなくてもいいかもしれないが…）ウインドウを閉じる
ExitSub:
If A_ExitReason = Single
Loop, %num_of_decks%
{
wintemp := Wins[A_Index]
WinClose ahk_id %wintemp%
}
ExitApp</syntaxhighlight>
* 必要に応じて、後述の狭い画面向けのCSSと併用するとよい。
* 需要があれば、画面を縦だけでなく横に分割するなどの機能拡張を実装するかもしれない。
* Vivaldiのタイリング機能を使って、複数タブを横並びで表示することもできるようだが、タブ間でセッションが共有されているので複数のアカウントに同時にログインしてTLを並べて表示することはできない（単一アカウントのTLと通知を並べるなどは可）。
* Stack browser（無料版だと機能制限あり？）など、複数セッションを並べて表示できるサービスもあるようなので、それでもよいかも


== 狭い画面向けのTwitterのCSS ==

StylusなどのCSSを適用してくれる拡張機能をインストールし、以下を入力する。コメントで簡単に説明を書いたので必要に応じて数値の変更やコメントアウトなどするとよい。

* Stylusに類似のものでStylishというのがあったが、個人情報の収集かなんかで問題になったので使わない方が良さそう

<syntaxhighlight lang="css">/*一応参考（ただし結局ほぼ使わず） https://polygonote.com/2022_0308_18019/ */
/* メインエリアの幅の制約を解除 */
main
{
width: 100%;
}

/*最大幅の制約を解除*/
.r-1ye8kvj {
max-width: 6000px;
}

/*最も広いときの幅の制約の解除*/
.r-113js5t {
width: 100%;
}
/*比較的広いときの幅の制約の解除*/
.r-rthrr5 {
width: 100%;
}
/*やや狭いときの幅の制約の解除*/
.r-1obr2lp {
width: 100%;
}
/*狭いときの幅の制約の解除*/
.r-33ulu8 {
width: 100%;
}
/*DM欄の幅を確保*/
section[aria-labelledby="root-header"]{
width: 30%;
}
section[aria-labelledby="detail-header"]{
width: 70%;
}
/*トレンドエリア非表示*/
div[data-testid="sidebarColumn"]{
display: none;
}

/*参考記事にあったが、不要そう
.r-o96wvk {
width: 100%;
}
*/

/*左側バナーのサイズを常に狭くする（オリジナルのサイトで最も狭くしたときの値は68で、ここからpadding-leftとpadding-rightで8ずつ引くと52になる）*/
header[role="banner"] > div,
header[role="banner"] > div > div > div
{
width:52px
}
/*幅が広いときの左側バナーの余白を無効に*/
header[role="banner"] > div {
margin-left: 0px;
}
/*header[role="banner"], こっちは不要？*/
header[role="banner"] > div > div > div > div > div > a/*「ツイートする」ボタンのサイズ*/
{
max-width: 100%;
padding-left: 0px;
padding-right: 0px;

}

/*「ツイートする」ボタンのサイズ*/
.r-1dye5f7 {
padding-left: 0px;
padding-right: 0px;
}

/*幅が広いときでも各種バナーアイコンを常に中央揃え*/
header[role="banner"] > div > div > div > div > div,
header .r-1habvwh
{
/*不要？ width: 100%; */
-webkit-align-items: center;
-webkit-box-align: center;
align-items: center;
-ms-flex-align: center;
}

/*幅が広いときでもバナーの各種アイコンの横に「通知」などの文字は出さない*/
/*これらは古いのでおそらく不要
header > div > div > div > div.css-1dbjc4n.r-usiww2 > div > div > div.css-1dbjc4n.r-1wbh5a2.r-dnmrzs.r-1ny4l3l,
header > div > div > div > div.css-1dbjc4n.r-usiww2 > div > div > div.css-1dbjc4n.r-obd0qt.r-16y2uox,
nav > div > div > div.css-901oao.css-1hf3ou5.r-18jsvk2.r-1tl8opc.r-adyw6z.r-135wba7.r-1joea0r.r-88pszg.r-bcqeeo.r-qvutc0,
nav > a > div > div.css-901oao.css-1hf3ou5.r-18jsvk2.r-1tl8opc.r-adyw6z.r-135wba7.r-1joea0r.r-88pszg.r-bcqeeo.r-qvutc0,
*/
header[role="banner"] > div > div > div > div > div > nav > a > div > div:nth-child(2),
header[role="banner"] > div > div > div > div > div > nav > button > div > div:nth-child(2),/*もっと見る*/
header[role="banner"] > div > div > div > div > div > nav > div > div > div:nth-child(2),
header[role="banner"] > div > div > div > div > div > button > div:nth-child(n+2),/*下のアイコン*/
header[role="banner"] > div > div > div > div.r-usiww2 > div > div > div:nth-child(n+2){
display:none
}

/*画像サイズ調整*/
/*div.css-1dbjc4n.r-1ets6dv.r-1867qdf.r-rs99b7.r-1loqt21.r-adacv.r-1ny4l3l.r-1udh08x.r-o7ynqc.r-6416eg > div > div.css-1dbjc4n.r-14gqq1x > div, /*引用ツイート内画像専用。不要*/

/*ツイート画像・動画。しかし一行下のもののほうが動画を再生時のみ枠に収めて最大化ボタンを押せるようにできるので、こちらは不要そう。
article[data-testid="tweet"] > div > div > div.css-1dbjc4n.r-18u37iz > div.css-1dbjc4n.r-1iusvr4.r-16y2uox.r-1777fci.r-kzbkwu > div.css-1dbjc4n.r-1ssbvtb.r-1s2bzr4 > div.r-9aw3ui > div > div > div,*/
/*article[data-testid="tweet"] > div > div > div.css-1dbjc4n.r-18u37iz > div.css-1dbjc4n.r-1iusvr4.r-16y2uox.r-1777fci.r-kzbkwu > div.css-1dbjc4n.r-1ssbvtb.r-1s2bzr4 > div.r-9aw3ui > div > div > div > div,再生時の動画コンテンツ。サムネイル状態だとうまく適用外になってくれる*/
/*上2つはおそらくもう機能していないので下を追加*/
div:has(> div > div > div[data-testid="videoPlayer"]),

/*article[data-testid="tweet"] > div > div > div > div > div > div > div > div > div:has(> div> div > div > div > div > div > div > a > div > div[data-testid="tweetPhoto"]),/*引用ツイート内複数画像*/

/*article[data-testid="tweet"] > div > div > div > div > div > div > div > div > div > div > div > div > div > div > div > div:has(> div > a > div > div[data-testid="tweetPhoto"]),/*引用ツイート内複数画像（少なめ）*/

article[data-testid="tweet"] > div > div > div > div > div > div > div > div > div > div > div:has(> div > div > a > div > div > div[data-testid="tweetPhoto"]),/*引用画像*/
article[data-testid="tweet"] > div > div > div > div > div > div > div > div > div:has(> div > div > a > div > div > div[data-testid="tweetPhoto"]),/*画像*/

div:has(a > div > div > img):has(> a > div > svg),/*Grokによる画像*/

aaadiv:has(> div> div> div[data-testid="previewInterstitial"]),/*四角い動画（・画像？）*/

div[data-testid="testCondensedMedia"] > div > div,/*複数枚入ってるものは直後のスタイルで上書きされる*/

article[data-testid="tweet"] > div > div > div > div > div > div > div > div > div:has(> div > div[data-testid="tweetPhoto"] > div > div > div > div[data-testid="placementTracking"] > div[data-testid="videoPlayer"]),/*動画*/
article[data-testid="tweet"] > div > div > div > div > div > div > div > div > div > div:has(> div[data-testid="tweetPhoto"] > div > div > div > div[data-testid="placementTracking"] > div[data-testid="videoPlayer"]),/*動画（内側も）*/
article[data-testid="tweet"] > div > div > div > div > div > div > div > div > div > div > div > div:has(> div[data-testid="tweetPhoto"] > div > div > div > div[data-testid="placementTracking"] > div[data-testid="videoPlayer"]),/*引用動画*/

/*引用ツイート画像・動画。しかし一行下のもののほうが動画を再生時のみ枠に収めて最大化ボタンを押せるようにできるので、こちらは不要そう。
article[data-testid="tweet"] > div > div > div.css-1dbjc4n.r-18u37iz > div.css-1dbjc4n.r-1iusvr4.r-16y2uox.r-1777fci.r-kzbkwu > div.css-1dbjc4n.r-1ssbvtb.r-1s2bzr4 > div > div > div > div.r-14gqq1x > div,/*引用ツイートの画像・動画*/
article[data-testid="tweet"] > div > div > div.css-1dbjc4n.r-18u37iz > div.css-1dbjc4n.r-1iusvr4.r-16y2uox.r-1777fci.r-kzbkwu > div.css-1dbjc4n.r-1ssbvtb.r-1s2bzr4 > div > div > div > div.r-14gqq1x > div> div> div,/*同上。*/

/*以下2つは、それぞれの子要素のdivに適用するよりこのほうがうまくいった*/
div[data-testid="card.wrapper"] > div[data-testid="card.layoutLarge.media"] > a,/*埋め込み記事の画像*/
div[data-testid="card.wrapper"]:has( > div[data-testid="card.layoutLarge.media"] > a),/*埋め込み記事の画像*/
div[data-testid="card.wrapper"] > div[data-testid="card.layoutLarge.media"] > div/*埋め込み記事の動画。サイトによっては画像も引っかかる？*/
{
max-height: 200px;
max-width: 500px;
justify-content: center;
overflow:hidden;
}

article[data-testid="tweet"] > div > div > div > div > div > div > div > div > div:has(> div > div > div > div > div > a > div > div[data-testid="tweetPhoto"]),/*複数画像（2枚）*/
article[data-testid="tweet"] > div > div > div > div > div > div > div > div > div > div:has(> div > div> div > div[data-testid="tweetPhoto"] > div > div > div > div[data-testid="placementTracking"] > div[data-testid="videoPlayer"]),/*複数動画（2枚）*/
article[data-testid="tweet"] > div > div > div > div > div > div > div > div > div > div > div:has(> div > div > div> div > div > a > div > div[data-testid="tweetPhoto"]),/*引用ツイート内複数画像（2枚）*/
article[data-testid="tweet"] > div > div > div > div > div > div > div > div > div > div > div > div:has(> div > div> div > div[data-testid="tweetPhoto"] > div > div > div > div[data-testid="placementTracking"] > div[data-testid="videoPlayer"])/*引用ツイート内複数動画（2枚）*/
{
max-height: 200px;
max-width: 1000px;
justify-content: center;
overflow:hidden;
}

article[data-testid="tweet"] > div > div > div > div > div > div > div > div > div:has(> div > div > div > div > div > div > a > div > div[data-testid="tweetPhoto"]),/*複数画像（3, 4枚）*/
article[data-testid="tweet"] > div > div > div > div > div > div > div > div > div > div:has(> div > div> div > div > div[data-testid="tweetPhoto"] > div > div > div > div[data-testid="placementTracking"] > div[data-testid="videoPlayer"]),/*複数動画（3, 4枚）*/
article[data-testid="tweet"] > div > div > div > div > div > div > div > div > div> div> div:has( > div > div > div > div> div > div> a > div > div[data-testid="tweetPhoto"]),/*引用ツイート内複数画像（3, 4枚）*/
article[data-testid="tweet"] > div > div > div > div > div > div > div > div > div > div > div > div:has(> div > div> div > div > div[data-testid="tweetPhoto"] > div > div > div > div[data-testid="placementTracking"] > div[data-testid="videoPlayer"])/*引用ツイート内複数動画（3, 4枚）*/
{
max-height: 400px;
max-width: 1000px;
justify-content: center;
overflow:hidden;
}
/*画像の余白の色を枠線と合わせる*/
div[data-testid="card.wrapper"] > div[data-testid="card.layoutLarge.media"],
article[data-testid="tweet"] > div > div > div.css-1dbjc4n.r-18u37iz > div.css-1dbjc4n.r-1iusvr4.r-16y2uox.r-1777fci.r-kzbkwu > div.css-1dbjc4n.r-1ssbvtb.r-1s2bzr4 > div > div > div > div.r-14gqq1x
{
background-color:rgb(232, 232, 232)
}

div[data-testid="card.wrapper"] > div[data-testid="card.layoutLarge.media"] > div >div[style="padding-bottom: 100%;"]/*埋め込み記事の動画*/
{
/*不要？ display:none*/
}

/*「さらに表示」があるツイート*/
/*article[data-testid="tweet"]:has(> div > div > div > div > div > div[data-testid="tweet-text-show-more-link"]),*/
/*AdBlock*/
/* article[data-testid="tweet"]:has(> div > div > div > div > div:nth-child(5) > div > svg){
display:none
} */
/*Grok（広告だっけ？）*/
div[data-testid="cellInnerDiv"]:has(> div > div > div > div[data-testid="inlinePrompt"]){
display:none
}

/*「ホーム」ではなくツイート単独ページ（https://twitter.com/###/status/#########?s=20）用。nth-child(3)がないとTL上の画像にも適用されてしまう*/
article[data-testid="tweet"] > div > div > div:nth-child(3) > div > div.css-1dbjc4n.r-1ssbvtb.r-1s2bzr4 > div > div > div > div
{
max-width: 800px;

}

/*ツイートの枠線の色を濃くする*/
.r-j5o65s {
border-bottom-color: rgb(150, 150, 150);
}

.r-jxzhtn {
border-color: rgb(150, 150, 150);
}

/* フォントサイズと行間 */
.r-a023e6 {
font-size: 15px;
}
.r-rjixqe {
line-height: 17px;
}
/*参考記事にあったが、不要？
.r-1i10wst {
font-size: 15px;
}
*/
/* ツイート入力エリアの文字高さ。そのままで良さそう。
.r-135wba7 {
line-height: 20px;
}
*/
/*「ホーム」の文字を中央揃え*/
main > div > div > div > div > div > div:first-child > div:first-child > div:first-child > div > div > div > div > div .r-1habvwh
{
-webkit-align-items: center;
}

/*「ホーム」部分の長さ上限解除（広いとき）*/
.r-sb58tz {
max-width: 100%;
}

/*入力欄の幅が変わってしまうので、固定*/
.r-1pjcn9w {
max-width: 600px;
}

/*サイドバーのアイコンエリアの余白削る*/
.r-1pn2ns4 {
padding-left: 0px;
padding-right:0px;
}

/*サイドバーの各アイコンの余白も削る*/
.r-xyw6el {
padding-left: 0px;
padding-right: 0px;
}
/*「ホーム」「おすすめ」「通知」など狭く*/
.r-1h3ijdo {
height: 30px;
}

/*「おすすめ」「フォロー中」の青い線が見えるように*/
.r-95jzfe {
padding-top: 8px;
}
.r-1l7z4oj {
padding-bottom: 8px;
}
/*ツイートの上部分を削る*/
.r-ttdzmv {
padding-top: 4px;
}
/*ツイートの下部分、つまり「いいね」「リツイート」アイコンの下を削る*/
.r-kzbkwu {
padding-bottom: 4px;
}
/*上記アイコンの上も削る*/
.r-1s2bzr4 {
margin-top: 4px;
}
/* 何のために入れたんだっけ…？
.r-ttdzmv.r-ero68b.r-nf76sl,
.r-kzbkwu.r-ero68b.r-nf76sl
{
padding-bottom: 12px;
padding-top: 12px;

}*/
/*検索ボックスの幅を小さく*/
/*input[data-testid="SearchBox_Search_Input_label"]
{
padding-top: 0px;
padding-bottom: 0px;
}*/
.r-ero68b {
min-height: 20px;
}</syntaxhighlight>
[[Category:IT]]{{#seo:|title={{FULLPAGENAME}} - Turgenev's Wiki}}

HTTP・SOCKS・透過プロキシ・UDP

2025-05-05T01:30:21Z

Turgenev: Notion-MW

SOCKS・透過プロキシ・UDP-over-TCPなどを中心に、ネットワークの変更に使えるプロキシ関連の各種技術を雑にまとめた。

近年はGo製のものが多い。また検閲に対抗するためか、中国系（中国語でissueが投稿されているなど）のものが多い。gost, go-proxy, hysteria, txthinking/socks5, things-go/socks5などはいずれもその2つに当てはまる。たまにロシア系もある。


== 大規模・多機能系 ==

以下のものは機能が多くて分類できないのでソフトウェアごとに紹介する。

==== gost ====

GO Simple Tunnelの略らしい。安定版のv2系（[https://github.com/ginuerzh/gost https://github.com/ginuerzh/gost], [https://v2.gost.run/ https://v2.gost.run/]）と開発中のv3系（[https://github.com/go-gost https://github.com/go-gost], [https://gost.run/ https://gost.run/]）で大きく仕様が異なる。v3は開発中と言いつつv2系のページを見るとかなりv3推しに見える。

starはバージョン2が16k、バージョン3が5kほど。

イメージとしては、TCPによるシンプルなトンネルプロトコル（これがgost）（暗号化無し）と他の大量のプロトコルの間の相互変換を実装しているような感じと思われる。

非常に多機能で、このページで紹介している多くソフトウェアの基本機能をカバーしていると言ってもいいくらい。UDP-over-TCP系は基本これ1つで十分。機能の豊富さに比して明らかにドキュメントが不足しており、エラーメッセージも親切ではない（起動時ではなく実際にパケットが来てからエラーが出るような感じ）。

<ul>
<li>connectorとしてはsocks5も用意されているが、相手がgostでない限りUDP Associateは動かない模様。具体的には
<syntaxhighlight lang="javascript">gost -L "auto://:8480?udp=true&relay=udp" -F socks5://192.168.1.13:3129</syntaxhighlight>
などとしても、 05f3 0001 0000 0000 0000みたいなよくわからんリクエストが送られてしまう。このf3のところは下記の独自拡張っぽい。
[https://github.com/go-gost/x/blob/04d1587a77964636d8e50f5cce475ee8621bece7/internal/util/socks/socks.go#L17 https://github.com/go-gost/x/blob/04d1587a77964636d8e50f5cce475ee8621bece7/internal/util/socks/socks.go#L17]</li></ul>

==== go-proxy ====

[https://github.com/snail007/goproxy https://github.com/snail007/goproxy]

これも見た感じgostと同じくらいか一部では上回るくらい多機能に見えるが、この雰囲気にしては珍しく有料版があり、無料版だと一部機能が制限されているようなので、あまり使ったことはない。


== GFW回避 ==

中国政府の検閲システムであるグレート・ファイアウォール（GFW）に対抗することを主な目的とするもの。

==== shadowsocks ====

SOCKSに暗号化を施した独自プロトコルで、いくつかの実装がある。[https://github.com/shadowsocks/shadowsocks-rust https://github.com/shadowsocks/shadowsocks-rust]などが主流とみられる。

VPN以外のGFW回避ソフトウェアだとおそらくもっともメジャー。

サーバーとクライアントに分かれていて、クライアント側では透過プロキシにも対応している。


==== Hysteria ====

通信路がHTTP/3に偽装した形で暗号化される。shadowsocksの次世代に位置付けられるソフトウェアのように見える。

SOCKS5サーバー部分にはtxthinking/socks5を使っている。


== SNI Proxy ==

HTTP・HTTPSのリバースプロキシで、host（HTTPの場合）あるいはsni（HTTPSの場合）に基づいてアクセスを振り分けるものをSNI Proxyと呼ぶことがあるらしい。NginxやHAProxyのような汎用のプロキシサーバーでも使える機能だが、これを専門とするソフトウェアもある。

* こんな使い方もある（自分の記事）→ [https://turgenev.hatenablog.com/entry/2025/03/21/020550 【Android】NextDNSをアプリごとに有効無効切り替え+Tailscale経由の自宅鯖を使ってControl D風のトラフィック転送 - turgenev’s blog]


==== dlundquist/sniproxy ====

[https://github.com/dlundquist/sniproxy https://github.com/dlundquist/sniproxy]　starは2.6kほど。2024年に更新あり。非推奨である理由（HTTP/2とかQUICでうまくいかないとか）も書いてある。

==== tcpproxy ====

[https://github.com/inetaf/tcpproxy https://github.com/inetaf/tcpproxy]　starは1.3kほど。ライブラリ用途がメインか。


==== ameshkov/sniproxy ====

[https://github.com/ameshkov/sniproxy https://github.com/ameshkov/sniproxy]　starは70ほど。上流のSOCKS5, HTTPプロキシへの転送機能がある。


==== puxxustc/sniproxy ====

[https://github.com/puxxustc/sniproxy https://github.com/puxxustc/sniproxy]　starもほぼなく更新も9年前。


== SOCKSプロキシサーバー ==

ここにあげたものは特に注記がなければUDP（ただし筆者が念頭に置いているのはAssociateのみで、Bindに関してはほぼ調べていない）に対応している。


==== Dante ====

[https://www.inet.no/dante/index.html Dante - A free SOCKS server]

企業（Inferno Nettverk A/S）によるオープンソースなSOCKS5実装で、有償サポートまであるらしい。見るからに古臭いHPで、メンテされているかどうか不安になるが、つい最近2024年末にもアップデートがあり、次期バージョンの計画についても記載されている。

Cで書かれていて、おそらく最も正確なSOCKS5実装だろう。コメントも親切で、リファレンス実装のような雰囲気がある。他の透過プロキシクライアントなどをテストする際はDanteでテストして動けば安心感がある。


==== OpenSSH ====

現実的に最もよく使われているSOCKSサーバーは間違いなくOpenSSHだろう。しかし、UDP-over-TCPの問題があるため、UDPはサポートされていない。

ssh -Dでforward方向のプロキシを建てるのが有名だが、OpenSSH 7.6からは-Rでreverse方向にも建てられるようになった。クライアント側が7.6以上であればよい。

* 参考: [https://www.openssh.com/txt/release-7.6 OpenSSH 7.6] （<code>ssh(1): add support for reverse dynamic forwarding</code>）

==== socks-with-udp-over-ssh ====

[https://github.com/ge9/socks-with-udp-over-ssh https://github.com/ge9/socks-with-udp-over-ssh]

これ自体はSOCKS5サーバーではなく、TCP接続（あるいは任意のバイトストリーム）の上にUDP付きのSOCKS5を通すために自分が実装したツール。サーバー側とクライアント側に分かれている。しかし実装した後にgostで同じことができることに気付いた。

経緯・使い方などは[https://turgenev.hatenablog.com/entry/2024/05/12/231208 root権限のないssh上にUDPを通す方法について（ポートフォワード、SOCKS5プロキシなど） - turgenev’s blog]に書いてある。

==== 3proxy ====

[https://3proxy.ru/ 3proxy tiny free proxy server for Windows, Linux, Unix: SOCKS, HTTP, FTP proxy]

[https://github.com/3proxy/3proxy https://github.com/3proxy/3proxy]

ロシア系。SOCKS・HTTP・POP3・SMTPなどいくつかのプロキシを含む。エラーメッセージなどがかなり不親切だが、結構多機能で、ちゃんと動くソフト。<code>3proxy</code>というメインの実行ファイルとあわせて、各プロキシに対応した<code>socks</code>や<code>proxy</code>といった検索性の低い名前の実行ファイルがいくつか含まれているちょっと謎の構成。

==== fast-socks5 ====

[https://github.com/dizda/fast-socks5 https://github.com/dizda/fast-socks5] Rust製では最も有名か。starは500ほど。使ったことなし


==== txthinking/socks5 ====

[https://github.com/txthinking/socks5 https://github.com/txthinking/socks5]

starは700前後。hysteriaやtrojan-goなどいくつかの大きなプロジェクトで使われており、現在もメンテされているgo製のSOCKS5関連ライブラリでは一番メジャーか。

クライアントもある。

自分のfork（[https://github.com/ge9/socks5 https://github.com/ge9/socks5]）ではFull Cone NATを追加した


==== armon/go-socks5 ====

[https://github.com/armon/go-socks5 https://github.com/armon/go-socks5]

starは2kだが、最終更新2016年でUDP Associateも無し。Wireproxyで以前使われていたが使われなくなった（[https://github.com/whyvl/wireproxy/issues/15 https://github.com/whyvl/wireproxy/issues/15]）。

ここからフォークされたものが複数ある。


==== things-go/go-socks5 ====

[https://github.com/things-go/go-socks5 https://github.com/things-go/go-socks5]

armon/go-socks5からのフォーク（GitHub上ではfork扱いではない）。starは400個ほど。UDP Associateはサポートしているがバグあり（自分のPRが採用されるかどうかで揉めてる[https://github.com/things-go/go-socks5/pull/63 https://github.com/things-go/go-socks5/pull/63]）。

Wireproxyで使われている。

自分のフォーク [https://github.com/ge9/go-socks5 https://github.com/ge9/go-socks5] ではFull Cone NATを追加した


==== haxii/socks5 ====

[https://github.com/haxii/socks5 https://github.com/haxii/socks5]

armon/go-socks5からのfork。UDP Associate対応。starは50個前後。最終更新2019年。


==== wzshiming/socks5 ====

[https://github.com/wzshiming/socks5 https://github.com/wzshiming/socks5]

クライアントもある。

starは90個ほど。最終更新2024年。

とりあえずredsocksと組み合わせでUDP透過プロキシ動作確認済。

Wireproxyで使用が検討された（[https://github.com/whyvl/wireproxy/issues/15 https://github.com/whyvl/wireproxy/issues/15]）が結局使用されず。


==== haochen233/socks5 ====

[https://github.com/haochen233/socks5 https://github.com/haochen233/socks5]

クライアントもある。

UDP Associateはサポートしているが、starは49とさらに少なく、最終更新も2021年。

同じくWireproxyで使用が検討された（[https://github.com/whyvl/wireproxy/issues/15 https://github.com/whyvl/wireproxy/issues/15]）が結局使用されず。

=== tun系 ===

==== tun2proxy ====

[https://github.com/tun2proxy/tun2proxy https://github.com/tun2proxy/tun2proxy]


== 透過SOCKSプロキシクライアント ==

[https://turgenev.hatenablog.com/entry/2024/03/25/160556 透過プロキシを用いて特定アプリケーションのTCP・UDP通信をSOCKS5経由にする方法（Windows・Linux（iptables TPROXY）・Androidなど） - turgenev’s blog]で扱った内容。

バックにSOCKS(SOCKS5)プロキシを用いてTCP・UDPのレイヤで透過プロキシを行うもの。基本的には管理者権限（Linuxの場合、最低でもCAP_NET_ADMIN）が必要。

以下のいずれも、ドメイン解決にはプロキシが適用されない（Linux向けの2つはできなくはないかもしれないが、しづらい）ことに注意。

==== redsocks ====

[https://github.com/semigodking/redsocks semigodking/redsocks] （fork元の[https://github.com/darkk/redsocks darkk/redsocks]はメンテされておらず、TCPのTPROXYに非対応）

*nix対応。BSD系で動かすことができたという話は[https://turgenev.hatenablog.com/entry/2024/06/10/134017 FreeBSD/OpenBSD/NetBSDで透過プロキシのredsocksを動かしてみる - turgenev’s blog]に書いた。

==== hev-socks5-tproxy ====

[https://github.com/heiher/hev-socks5-tproxy https://github.com/heiher/hev-socks5-tproxy] Linux向け。redsocksより若干知名度は下がるものの、きちんとメンテされている。


==== ProxiFyre ====

[https://github.com/wiresock/proxifyre https://github.com/wiresock/proxifyre] Windows用の透過SOCKSクライアント。管理者権限必要。TCP/UDP両方対応。インストールも簡単で、よくできている。


==== Proxifier ====

[https://www.proxifier.com/ https://www.proxifier.com/] 見た感じ機能は十分そうだが、有料なので試していない。

== ライブラリ関数ハック系 ==

ライブラリ関数レベルでの置き換えになるため厳密性・安定性に欠ける（異常終了する場合もある）ものの、root権限がない場合に有効な手法。


=== Linux（LD_PRELOAD） ===

libc依存でないプログラム（Go製のものなど）には効かない。

==== socksify ====

後述のDanteの一部。UDP/TCP両対応。唯一のUDP対応のものである。

<syntaxhighlight lang="go">route {
from: 0.0.0.0/0 to: 0.0.0.0/0 via: 192.168.1.1 port = 1080
}</syntaxhighlight>
こんな感じの<code>/etc/socks.conf</code>を作るか、<code>SOCKS5_SERVER=192.168.1.1:1080 socksify curl http://ipv4.icanhazip.com</code> とかでもよい。

Macでも動くはずだが、筆者が唯一試したMac環境ではcurlに対してさえうまく動作しなかった（socksifyを使わないのと全く同様に動作するだけだった）（<code>DYLD_FORCE_FLAT_NAMESPACE=1</code>は指定している）。


==== proxychains-ng(proxychains) ====

ngはnew generationの略で、proxychainsの後継である。ただしコマンド名はproxychains4である。

多段プロキシを構成するためのソフトウェア。

UDP非対応（[https://github.com/rofl0r/proxychains-ng/issues/336 https://github.com/rofl0r/proxychains-ng/issues/336]）。ただしDNSに対応したproxy_dnsというオプションがあり、これを有効にするとDNS以外のUDP通信が正常に機能しなくなる副作用がある（[https://github.com/rofl0r/proxychains-ng/issues/103 https://github.com/rofl0r/proxychains-ng/issues/103]）。


==== torsocks(tsocks) ====

多分、メンテされていないtsocksがTorに取り込まれてtorsocksになったような感じ。tsocksは非常に古く、多分2010年以降には更新されていないが、知名度は高く、今でも多分そこそこ使われてそう。

torsocksはアクティブなはず。ただし、Torでない普通のSOCKS5を指定しても動かないようである（やり方が悪いかも）。

tsocksはUDPには対応していない。torsocksもそうだが、まずそもそもTor自体がUDPに対応していない。


=== Windows（DLL Hijacking） ===

どのDLLを置き換えたらいいか自明ではなさそうなので、LD_PRELOADと違って対象とするソフトウェアごとに実装が必要そう。そもそも不可能なソフトウェアもLD_PRELOADの場合より多そう。よく見かけるのはDiscordを対象にしたもので、ロシア系のものが多い。筆者は使ったことがない。

==== discord-drover ====

[https://github.com/hdrover/discord-drover https://github.com/hdrover/discord-drover]

==== discord-voice-proxy ====

[https://github.com/runetfreedom/discord-voice-proxy https://github.com/runetfreedom/discord-voice-proxy]


== HTTPプロキシ ==

Squid, Privoxyなどが有名。

Squidには透過プロキシ機能があるが、redsocksなどとは動作の細かい部分が異なる。[https://turgenev.hatenablog.com/entry/2025/03/25/171736 squidで透過プロキシ（intercept, tproxy）を動かす - turgenev’s blog]に書いた。


== localhost・LANなどへのアクセス制限 ==

典型的な設定例として、localhostやプライベートIPへのアクセスを制限する設定をSquid・Dante・3proxyそれぞれに関して紹介しておく。

==== squid ====

<code>to_localhost</code>はbuilt-inとして定義されていて、<code>localnet</code>（=srcがlocalnet）についてもUbuntuパッケージで提供されるsquid.confには入っているのだが、localnetがdstであるものとなるとACLが定義されていない。

<code>deny to_localhost</code>と<code>deny to_linklocal</code>は定義済みという前提で、以下のように書くとよい。

<syntaxhighlight lang="go">acl to_localnet dst 0.0.0.1-0.255.255.255
acl to_localnet dst 10.0.0.0/8
acl to_localnet dst 100.64.0.0/10
acl to_localnet dst 172.16.0.0/12
acl to_localnet dst 192.168.0.0/16
acl to_localnet dst fc00::/7

http_access deny to_localnet</syntaxhighlight>

==== 3proxy ====

IPv4のみ対応。

<syntaxhighlight lang="go">deny * * 127.0.0.0/8,0.0.0.1-0.255.255.255,10.0.0.0/8,100.64.0.0/10,169.254.0.0/16,172.16.0.0/12,192.168.0.0/16 * * * *
allow *</syntaxhighlight>

==== dante ====

IPv4のみ対応。squid・3proxyの場合と違って0.0.0.0もblockしてしまっているが、そもそも使わないので問題ないはず。

<syntaxhighlight lang="go">client pass {
from: 0/0 to: 0/0
}

socks block {
from: 0/0 to: 127.0.0.0/8 # localhost
protocol: tcp udp
command: bind connect udpassociate bindreply udpreply
}
socks block {
from: 0/0 to: 0.0.0.0/8 # RFC 1122 "this" network (LAN)
protocol: tcp udp
command: bind connect udpassociate bindreply udpreply
}
socks block {
from: 0/0 to: 10.0.0.0/8 # RFC 1918 local private network (LAN)
protocol: tcp udp
command: bind connect udpassociate bindreply udpreply
}
socks block {
from: 0/0 to: 100.64.0.0/10 # RFC 6598 shared address space (CGN)
protocol: tcp udp
command: bind connect udpassociate bindreply udpreply
}
socks block {
from: 0/0 to: 169.254.0.0/16 # RFC 3927 link-local (directly plugged) machines
protocol: tcp udp
command: bind connect udpassociate bindreply udpreply
}
socks block {
from: 0/0 to: 172.16.0.0/12 # RFC 1918 local private network (LAN)
protocol: tcp udp
command: bind connect udpassociate bindreply udpreply
}
socks block {
from: 0/0 to: 192.168.0.0/16 # RFC 1918 local private network (LAN)
protocol: tcp udp
command: bind connect udpassociate bindreply udpreply
}

socks pass {
from: 0/0 to: 0.0.0.0/0
protocol: tcp udp
command: bind connect udpassociate bindreply udpreply
}</syntaxhighlight>

== SOCKS関連の話題 ==


==== NATが介在する場合などのUDP Associateの動作 ====

OpenSSHの項目でも関連することを述べたが、UDP-over-TCPの性能劣化を避けるため、UDP Associateは「サーバー側がクライアント側に対してUDP通信で使うための中継ポートを通知する」という動作を伴う。この際、ネットワーク上でクライアント側からサーバーが直接見えていればよいが、NATを介している場合、クライアントから見たときのサーバーのIPとサーバー自身から見たときのサーバーのIP（中継ポート通知に含まれるのはこれ）が異なることがあり、通信が成立しなくなってしまう（SSHのポート転送を普通に使うだけではUDP Associateが使えないのも直接にはこれが原因）。

ただし、[https://turgenev.hatenablog.com/entry/2024/03/25/160556 透過プロキシを用いて特定アプリケーションのTCP・UDP通信をSOCKS5経由にする方法（Windows・Linux（iptables TPROXY）・Androidなど） - turgenev’s blog]にも書いた通り、Proxifyreやhev-socks5-tproxyなどは中継ポート通知のIP部分を無視するため、ポート番号が変わらないNATであれば問題なく動作する（redsocksはダメ）。


==== SOCKS5によるドメイン解決 ====

SOCKS5（SOCKS4aも？）では、クライアントがCONNECTなどの要求をする際、接続先をIPアドレスではなくホスト名（ドメイン名）で指定することができる仕様になっている。これによりクライアント側ではなくSOCKS5サーバー側でドメイン解決が行われる。

透過SOCKSプロキシの場合、TCP/UDPレイヤでのプロキシとなるので、この機能が使われることはない（[https://turgenev.hatenablog.com/entry/2024/03/25/160556 透過プロキシを用いて特定アプリケーションのTCP・UDP通信をSOCKS5経由にする方法（Windows・Linux（iptables TPROXY）・Androidなど） - turgenev’s blog]）（さらに、繰り返しになるが付け加えておくと、普通にセットアップした場合はDNSにプロキシは使われない）。一方、HTTPのレイヤで動作するWebブラウザでは、この機能が使われる場合がある。2018年時点での[https://github.com/FelisCatus/SwitchyOmega/issues/1379 https://github.com/FelisCatus/SwitchyOmega/issues/1379]によれば、Chromeでは必ずSOCKS5サーバー側でドメイン解決が行われる（これは[https://github.com/FelisCatus/SwitchyOmega/wiki/FAQ FAQ]にも書いてある）一方、Firefoxではそうでなかったようである。現在のFirefoxでは「SOCKS v5 を使用するときは DNS もプロキシーを使用する（Proxy DNS when using SOCKS v5）」（v4についても同様のオプションがあるが、SOCKS4aではないSOCKS4でどうなるかは未検証）というオプションがあってデフォルトで有効になっているため、やはり基本的にはSOCKSサーバー側でドメイン解決が行われる。AndroidのFirefox（この設定項目がない）にProxy SwitchyOmegaを入れた場合もそのように動作した。

なお、HTTPプロキシについても、ブラウザで普通に使う分には、（HTTP/HTTPS共に）ドメイン解決は基本的にプロキシサーバー側で行われる。

* 拡張機能などではうまく動作しない場合がある模様。 [https://github.com/FelisCatus/SwitchyOmega/issues/2304 https://github.com/FelisCatus/SwitchyOmega/issues/2304]


==== ブラウザのSOCKS5プロキシのWebRTC対応 ====

基本的に現在主流のブラウザ（Firefox, Chrome）のSOCKS5プロキシ機能（拡張機能で設定する場合を含む）はUDPには対応していないため、Discordの通話などWebRTC関係の機能を使うと生IPが漏洩する（またはそれを防ごうとすると単にその機能が使えない）。これは原理的に実装が不可能なわけではなく、単に需要が少ないから実装されていないだけである。

* Chromeではどれが最新か不明（最近の物は少ない）。このへんとか？[https://issues.chromium.org/issues/41180783 Chromium]
* torのバグ報告 [https://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/151 https://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/151]
* firefoxの [https://bugzilla.mozilla.org/show_bug.cgi?id=1808692 https://bugzilla.mozilla.org/show_bug.cgi?id=1808692]
** QUIC関連 [https://bugzilla.mozilla.org/show_bug.cgi?id=1882071 https://bugzilla.mozilla.org/show_bug.cgi?id=1882071]
** 新しめの包括的なバグレポート [https://bugzilla.mozilla.org/show_bug.cgi?id=1947229 https://bugzilla.mozilla.org/show_bug.cgi?id=1947229]

従って、ブラウザのWebRTCをプロキシさせたい場合はVPNや透過プロキシなどroot/管理者権限が必要な手法を使うことが多くなるだろう。ただしLinux+Firefoxの場合はsocksifyが使えるのでrootが無くても可能。


==== UDP AssociateリクエストのDST.ADDRとDST.PORT ====

クライアントがサーバー側にUDP Associateリクエストをするとき、この2フィールドには通信したい宛先ではなく（←というかそもそもそれが複数ある場合もある）、クライアント側がUDP Associateに使用する予定のポートを入れる。指定しない場合（例えばNATがある場合、これを予測するのは難しくなる）は、全ビットを0に設定する必要がある。

これによってサーバー側は、UDPパケットが送られてきたタイミングでそれが事前に通知されたものと一致するかどうか確認できるというわけである。

この部分に誤ってクライアント側が通信したい宛先ポートを入れるよう実装していたSOCKS5クライアントがいくつかある。

* semigodking/redsocks…自分の[https://github.com/semigodking/redsocks/issues/210 https://github.com/semigodking/redsocks/issues/210]で修正済み。
* gost…[https://github.com/ginuerzh/gost/issues/96 https://github.com/ginuerzh/gost/issues/96]で修正済み。
* txthinking/socks5…[https://github.com/txthinking/socks5/issues/15 https://github.com/txthinking/socks5/issues/15]で修正済み。
* things-go/go-socks5…これはサーバー側。[https://github.com/things-go/go-socks5/issues/29 https://github.com/things-go/go-socks5/issues/29]の通り、クライアントが必ずアドレス・ポートを通知してくれる（ゼロ埋めしない）と仮定していたが、修正された。


== VPN(tun) ==


==== tun2proxy ====

[https://github.com/tun2proxy/tun2proxy https://github.com/tun2proxy/tun2proxy]

Rust製。starは700ほど。SOCKSとHTTPをtunにしてくれる。

==== hev-socks5-tunnel ====

[https://github.com/heiher/hev-socks5-tunnel https://github.com/heiher/hev-socks5-tunnel]

hev-socks5-tproxyの作者による。Androidアプリの[https://github.com/heiher/sockstun https://github.com/heiher/sockstun]もここから。

== プロキシプロトコル間の変換 ==

==== socks-to-http-proxy ====

[https://github.com/KaranGauswami/socks-to-http-proxy https://github.com/KaranGauswami/socks-to-http-proxy]

名前の通り、socksをhttpにしてくれる。starは250ほど。

==== privoxy ====

基本的にはHTTPプロキシソフトウェア。socksプロキシをhttpプロキシとして使えるようにする機能はあるが、より大がかり（一般ユーザーでの実行がしづらい）


== UDP・Wireguard関連 ==


==== UDPでサーバー→クライアントにデータ送信 ====

[https://github.com/prof7bit/udp-reverse-tunnel https://github.com/prof7bit/udp-reverse-tunnel]

これを使うと、サーバー側だけでポートが開けられるとしても事実上クライアント側で開けられるのと同等になるのでreverseをするのが楽になる

* [https://superuser.com/questions/1737943/how-to-create-a-reverse-udp-tunnel https://superuser.com/questions/1737943/how-to-create-a-reverse-udp-tunnel]
* どっちも開放できない場合、UDPホールパンチングで何とかするしかない

==== wgslirpy ====

[https://github.com/vi/wgslirpy https://github.com/vi/wgslirpy]

Slirp（ユーザーランドで動くPPPサーバーのようなもの）のような形で実装されたWireguardサーバー。rootなしでWireguardサーバーとして動作する。

==== wireproxy ====

[https://github.com/whyvl/wireproxy https://github.com/whyvl/wireproxy]

wgslirpyの逆のような（？）ツール。Wireguardクライアントであるが、SOCKSサーバーとして動作する。

依存ライブラリのUDP Associate対応が不完全（自分がプルリクを送っている）だが、クライアントによってはうまくUDP Associateが動く（[https://github.com/whyvl/wireproxy/issues/30 https://github.com/whyvl/wireproxy/issues/30]）。

<ul>
<li>自分でカスタマイズしてCone NATを加えたthings-go/go-socks5を使えば（<code>go.mod</code>で<code>replace github.com/things-go/go-socks5 => ../../go-socks5</code>などとする）、以下のようなコードをroutine.goのsocks5.Optionのところに追加することでCone NATにできる。
<syntaxhighlight lang="go">socks5.WithDialUDP(func(laddr, raddr *net.UDPAddr) (net.PacketConn, error) { return vt.Tnet.DialUDP(laddr, raddr) }),</syntaxhighlight></li></ul>


=== Wireguard通信の確立: 各パターンでのやり方 ===

各状況に応じて、2端末間でUDPの暗号化された通信路を確立するための方法を書いた。

* forwardは「クライアント→サーバー」、reverseは「サーバー→クライアント」という意味。「サーバー」は、「ポートが開放できる方」という意味合い。

==== どっちもrootあり ====

普通にWireguardを使う

==== サーバーのみrootあり ====

forward

サーバーはWireguard、クライアントは普通にWireproxyでいける

reverse

udp-reverse-tunnelで頑張って逆にする（あるいはホールパンチング）。

その上で、wgslirpyを使うか、Hysteriaを使うか

==== クライアントのみrootあり ====

↑さっきと逆

forward

wgslirpyを使うか、Hysteriaを使うか

reverse

udp-reverse-tunnelで頑張ったうえで普通にWireguardとWireproxy

==== どっちもrootなし ====

この場合そもそもWireguardを使うメリットはあまりないかも。というのとrootがないならポート開放も無理そう

forward

Hysteriaでいけそう。

reverse

udp-reverse-tunnelしてHysteria？かな

== その他の話題 ==

==== ドメインごとにプロキシを変更できるブラウザ拡張のiframeにおける動作 ====

FoxyProxyやSwitchyOmega(ZeroOmega)など、ドメインごとに自動でプロキシを切り替えてくれるブラウザ拡張はChromium系にもFirefoxにもいくつかあるが、これらはあくまでコンテンツのオリジンを元にプロキシを適用しており、ブラウザのタブを見ているわけではない。つまり、foo.comのページを開いていて、そこにbar.comのコンテンツがiframeで埋め込まれている場合、iframeの内部は、bar.comに対して使用するものと指定されたプロキシを使用して処理される。

一応、[https://superuser.com/questions/250172/disable-enable-the-proxy-on-a-tab-by-tab-basis-in-firefox Disable/enable the proxy on a tab by tab basis in Firefox]によると、Firefoxのcontainer-proxyというのがこれに近い機能を実質的に実現してくれるらしい。
[[Category:IT]]{{#seo:|title={{FULLPAGENAME}} - Turgenev's Wiki}}

Notion2mdtest

2025-04-15T13:57:12Z

Turgenev: Notion-MW

head

test 
ここは常に表示

== 表示1 ==

content2e

=== 表示2 ===

==== 表示3作業中 ====

{{UnderConstruction|Notion2mdtest}}

==== 表示4 ====

content4

== 表示5 ==

==== レベル3作業中 ====

{{UnderConstruction|Notion2mdtest}}

== 見出し書式 ==

=== ===


==== BOLD ====

{{UnderConstruction|Notion2mdtest}}


=== "double quote ===


==== <tag> ====

{{UnderConstruction|Notion2mdtest}}


=== ## そのまま#表示 ===

{{UnderConstruction|Notion2mdtest}}

== テンプレート ==

{{Stub}}

{{Valuable}}

{{Outdated}}

== インデント ==

test

<pre>indented

indented2</pre>
text

<pre># インデント見出し</pre>
test2

<pre>### インデント見出し2

## インデント見出し黄色</pre>

== 箇条書き・要約など ==

[https://github.com/souvikinator/notion-to-md/issues/91 https://github.com/souvikinator/notion-to-md/issues/91]への対応確認

<div style="overflow:auto;width: 100%; max-width: 1200px; white-space:nowrap; border:1px solid; padding-left: 10px; padding-right: 10px;" class="mw-collapsible">
<div>summary1</div>
<div class="mw-collapsible-content">

detail1

</div></div>

* bullet1
** bullet2

(some text)

<div style="overflow:auto;width: 100%; max-width: 1200px; white-space:nowrap; border:1px solid; padding-left: 10px; padding-right: 10px;" class="mw-collapsible">
<div>summary2</div>
<div class="mw-collapsible-content">

detail2

</div></div>

==== セル内改行 ====

<ul>
<li>リンクと箇条書き 
[https://www.google.com/ Google]
<ul>
<li>リンクと箇条書き 
[https://www.google.com/ Google] 
text
[https://www.google.com/ Google]</li>
<li>[https://www.google.com/ Google] 
[https://www.google.com/ Google]</li></ul>

[https://www.google.com/ Google]</li></ul>

[https://www.google.com/ Google]

==== 箇条書き ====

<ol style="list-style-type: decimal;">
<li>11111111111</li>
<li>2222222222222
<ol style="list-style-type: decimal;">
<li>aaaaaaaaaaa</li>
<li>bbbbbbbbbbb
<ol style="list-style-type: decimal;">
<li>iiiiiiii</li>
<li>IIIIIII</li></ol>
</li>
<li>cccccc</li>
<li>dddddddddd</li></ol>

<ul>
<li>separator</li></ul>

<ol style="list-style-type: decimal;">
<li>111111</li>
<li>22222</li>
<li>3333</li></ol>
</li>
<li>33333
<ol style="list-style-type: decimal;">
<li>aaaaaaaa</li></ol>
</li></ol>

==== デフォルト表示の設定 ====

<div style="overflow:auto;width: 100%; max-width: 1200px; white-space:nowrap; border:1px solid; padding-left: 10px; padding-right: 10px;" class="mw-collapsible mw-collapsed">
<div>デフォルトで折り畳み
改行</div>
<div class="mw-collapsible-content">

中身 
改行

</div></div>

<div style="overflow:auto;width: 100%; max-width: 1200px; white-space:nowrap; border:1px solid; padding-left: 10px; padding-right: 10px;" class="mw-collapsible">
<div>デフォルトで表示
改行</div>
<div class="mw-collapsible-content">

インデント

* a
** ed
** %&\$\\`+~

</div></div>

==== ネスト ====

<div style="overflow:auto;width: 100%; max-width: 1200px; white-space:nowrap; border:1px solid; padding-left: 10px; padding-right: 10px;" class="mw-collapsible">
<div>toggle
kaigyo</div>
<div class="mw-collapsible-content">

tog 
kaigyo

<div style="overflow:auto;width: 100%; max-width: 1200px; white-space:nowrap; border:1px solid; padding-left: 10px; padding-right: 10px;" class="mw-collapsible mw-collapsed">
<div>toggled2
kaigyo</div>
<div class="mw-collapsible-content">

lev2

<div style="overflow:auto;width: 100%; max-width: 1200px; white-space:nowrap; border:1px solid; padding-left: 10px; padding-right: 10px;" class="mw-collapsible">
<div>lev3</div>
<div class="mw-collapsible-content">

cont3

</div></div>

ciot

</div></div>

<div style="overflow:auto;width: 100%; max-width: 1200px; white-space:nowrap; border:1px solid; padding-left: 10px; padding-right: 10px;" class="mw-collapsible">
<div>lev22
s</div>
<div class="mw-collapsible-content">
<div style="overflow:auto;width: 100%; max-width: 1200px; white-space:nowrap; border:1px solid; padding-left: 10px; padding-right: 10px;" class="mw-collapsible mw-collapsed">
<div>clev3</div>
<div class="mw-collapsible-content">

aaa

</div></div>

</div></div>

</div></div>

== 表 ==

[https://github.com/souvikinator/notion-to-md/issues/86 https://github.com/souvikinator/notion-to-md/issues/86]への対応

{| class="wikitable"
|-
!
!
!
|-
|
| d
|
|-
|
| f
|
|-
|
|
|
|}

== 書式 ==

=== 文字の消滅確認 ===

textitalicBO<s>L</s><s>o</s>ld<s>a</s><s>b</s>

=== セル内改行入り ===

* 基本的に非推奨、連続改行（空行）は禁止 
先頭に空白とか特殊文字入れるとかも危なそう

test 
改行 
改行3 
改行<code>e 
a 
f</code> 
z 
aa<code>df</code> 
<code>ug</code><code>g 
f 
|aa|bb|vc|{}{|}a{a</code> 
|aa|bb|vc|{}{|}a{a{{s|aa}} 
<code>dd==aaaa== 
; bbbb</code> 
<code>; bbbb</code> 
<code>; bbbb</code> 
<s><code>; bbbb</code></s> 
<code>* bbbb 
----- 
---- 
: 一個のインデント 
:: 二個のインデント </code> 
- sdg 
* sfs 
space 
 space2 
- spacehyphen 
 - hyphen2

=== その他エスケープシーケンスの確認 ===

code<code>d`d`d</code>

（Wikipediaの書式の例から流用）

::::: 多数のインデント

# 一 

# 二 

#* 二・一 

#* 二・二 

# 三 

#; 三項目一 

#: 三定義一 

# 四 

#: 四定義一 

#: 四定義一から続いているように見えるので 

#: &lt;nowiki&gt;&lt;br /&gt;&lt;/nowiki&gt; の代わりとして &lt;br /&gt; 

#: よく使われます 

# 五 

## 五の一 

### 五の一の一 

## 五の二

&amp;lt;

&amp;amp;

&amp;#98;

'''''可能'''''

# 一 
# 二 
#* 二・一 
#* 二・二 
# 三 
#; 三項目一 
#: 三定義一 
# 四 
#: 四定義一 
#: 四定義一から続いているように見えるので 
#: <nowiki> </nowiki> の代わりとして 
#: よく使われます 
# 五 
## 五の一 
### 五の一の一 
## 五の二 
&lt; 
&amp; 
&#98; 
---- 
~~~~

あ~~a~~b~c~~d~~e~~~f~~~~g

{{stub}}

{{UnderConstruction}}

==aaaa==

&amp ^caret^ +*@*****<s>*</s>*<s>*</s>****

\\$\$%&@@`””’’a’a’’’a’’’’’a\”

[text](link) {bra'''’ck''a'’et''''’’_’} |bar|+-.!()#

- (a)..aa'''’+

斜_体で_はない

==== リンクなど ====

+ item!! [https://google.com/ li[]nk] [https://ja.wikipedia.org/wiki/%E3%82%B9%E3%82%AB%E3%83%A9%E3%83%BC_(%E6%95%B0%E5%AD%A6) li!#$-{{}}a|a|{{}s*_^””’s}a=~~~~[[[]]n[]k2]

! a | ‘’a’’ [text](http://127.0.0.1)

privateページリンク[[error_private_page|error_private_page]]

自己リンク [[Notion2mdtest|Notion2mdtest]]

ページ内へ [[Notion2mdtest#コード|コード]]

google.com

<code>google.com</code>

[https://www.google.com/ https://www.google.com/]

[https://www.rodsbooks.com/refind/installing.html#winprob https://www.rodsbooks.com/refind/installing.html#winprob]

=== 数式 ===

数式<math display="inline">d^2</math>

数式<math display="inline">\sum_{n=1}^{10}{n}=55\$\$</math>

<math display="block">
|x| = \begin{cases}a'g\\aa'\end{cases}\{aa\}
</math>

$not math$

$$ 
not math 
$$

数式ではない$\sum_{n=1}^{10}{n}=55$です

=== コード ===

両端はtrimされる

<syntaxhighlight lang="python">code ```aaaa`````aaa`a```
```
```wsss
```
{{stub}}
{{UnderConstruction}}
----
~~~~
[[link|link]]
aaa
```aaa
```bold
italic
strike
unders
```</syntaxhighlight>
`not code`

``` 
koremo not code 
```

<code><details><summary>s1s</summary></details></code>

<details><summary>2ss</summary></details>

<div></div>tilde~~tilde~

<code>code</code> <code>code</code> <code>code</code> <s><code>code</code></s>

<code>code</code> <code>code</code> <code>code</code> <s><code>code</code></s>

<s><code>code</code></s><s>df</s><s>df</s><s><code>ef</code></s><s>d</s>d<code>f</code><s><code>d</code></s><code>f</code>vf

空白入りの言語名

<syntaxhighlight lang="vb.net"><tag></svg>
\\$\$%&@@`"""'""'"
# $ $\ ss
<details><summary>2ss</div>
<div class="mw-collapsible-content"></div></div>
</div>
<div class="mw-collapsible-content">
</div></div>
[text](link) {bra'''cks''a'et''''_a_} |bar|+-.!()#
+ #
- (a)..aa'''+</syntaxhighlight>
特殊記号のあるプログラム言語名

<syntaxhighlight lang="c#">public static Type Max<Type>(Type a, Type b)
where Type : IComparable
{
return a.CompareTo(b) > 0 ? a : b;
}</syntaxhighlight>
=== その他 ===

水平線

-----

<blockquote>引用
</blockquote>
== 画像 ==

<div class="res-img">https://ja.wikipedia.org/static/images/icons/wikipedia.png</div>
[[Category:sandbox]]{{#seo:|title={{FULLPAGENAME}} - Turgenev's Wiki}}

Windowsでエクスプローラーからフォルダを各種ターミナルで開く

2025-04-15T13:57:09Z

Turgenev: Notion-MW

Explorerの右クリックメニューやアドレスバーからフォルダを各種ターミナルで開くための設定方法の紹介。cmd.exe, powershell（pwsh含む）, Cygwin, Git Bashの4つに対応。

== 基本 ==

* [[Windowsの右クリックメニューから複数ファイルをまとめて開く|Windowsの右クリックメニューから複数ファイルをまとめて開く]] のように、レジストリでフォルダ・フォルダ背景の右クリックメニューを編集できる。
** Windows10までの右クリックメニューに戻そう。
** <code>command</code>キーの既定値に直接コマンドを書く方法と、<code>DelegateExecute</code>値（など）を使ってCOMを通じて実行する方法（このために[https://github.com/ge9/ExecuteCommand-Pipe https://github.com/ge9/ExecuteCommand-Pipe]（使い方はレポジトリの説明を参照）を作った）がある。
** HKLMにあるマシン全体の設定は、それ自体は管理者権限（あるいはTrustedInstallerなどさらに上の権限）がないと書き換えられないが、HKCUに値があればそちらが優先されるので、自分だけに関する設定変更ならユーザー権限だけで可能である。
** <code>Directory</code>や<code>Directory\Background</code>の直下に<code>runas</code>という名前でキーを作った場合は、自動的に<code>command</code>の内容が管理者権限で実行される。ただ、<code>runas</code>という固定のただ一つの名前しか使えないため、例えば管理者としてコマンドプロンプトを開くメニューとPowerShellを開くメニューを共存させることができない。そのためこの記事では<code>runas</code>キーを使用するのではなくコマンドの中で明示的に管理者としての実行を行っている。
* Explorerのアドレスバー（address bar, location barなど）にcommandと入力してEnterを押すと、そのフォルダをカレントディレクトリとして<code>command</code>というコマンドが実行される。
** このアドレスバーの仕様はおそらく「ファイル名を指定して実行」とほぼ同じ。<code>command</code>で（メインとして）指定するファイルはフルパスなら必ず動作し、Pathが通っているまたはApp Pathsに登録されているならファイル名だけでよく、さらにbatやexeの場合は拡張子も省略できる。さらに、ほとんど知られていないが実はApp Pathsの値には実行ファイル以外も書けるようである。
** つまり、パスの通っているフォルダにあるimage.pngはフルパスを打たなくても「image.png」で開けるし、さらにはApp Pathsの<code>openimage.exe</code>というキーにimage.pngのフルパスを書けば<code>openimage</code>と打つだけで（実際にはそのような実行ファイルは全く存在しないにもかかわらず）image.pngが開くようになる。当然、vbsなども拡張子無しで呼び出せることになる。

== ポイント ==

==== パス名のルール ====

* Windowsではパスの長さが260文字以下という制限がある。詳しくは[[Windowsのパス長さ制限に関して|Windowsのパス長さ制限に関して]] 参照。
** 制限を超えるような長いパスは<code>\\?\</code>というプレフィックスを付けて（UNCパスの一種として）扱われる。
*** このようなフォルダをカレントディレクトリとしてコマンドを実行することはできないので、アドレスバーに打ち込む方式は使えない（System32をカレントディレクトリとして実行される）。wt -dなどにも指定できない。
*** 右クリックメニューでは、commandの既定の値に直接書く方式の場合は、<code>NoWorkingDirectory</code>を設定しないと呼び出されなくなる。
*** シンボリックリンク/ジャンクションでパスを短くしてやれば普通に扱えるようになる
* 普通に入力できる文字でWindowsのファイル名に使えないのは、<code>\</code> <code>/</code> <code>:</code> <code>*</code> <code>?</code> <code>"</code> <code><</code> <code>></code> <code>|</code>の9個（エクスプローラーの画面で入れようとすると表示される）。
** その他、ヌル文字やタブスペースのような0x20未満の制御文字も使えない（はず）。
*** これらを含むファイルはGit Bash/Cygwinを使っても作れない。
*** NTFS自体の制限はおそらく<code>/</code>だけで、それ以外に関してはLinux上で作ってからWindowsで見ると見られることもある。中身の閲覧などは不可。
* また、末尾が空白またはピリオドのファイルも禁止で、Explorerやcmdでは作れない（自動で除去される）。
** これらはGit Bash/Cygwinなら作れる。前者はエクスプローラーで閲覧など多少の操作ができるが後者はほとんど何もできず、DelegateExecuteの右クリックメニューでもピリオドが外れた名前しか取得できない。
* 先頭が空白のファイルはExplorerだと作れないがcmdなら作れる。禁止ではないはず。


==== Git Bash/Cygwin ====

* Git BashではWindowsの実行ファイルにスラッシュ付きオプションを渡すときはスラッシュを2つにする必要がある。<code>cmd //c</code>や<code>bcdedit //v</code>など。
* printf関数の%qオプションを使うと、文字列をエスケープされた状態にして返してくれる。これはshからの呼び出し先の別のshで再びフォルダ名をcdなどの引数として利用したいときに使える。
** bash（POSIX互換ではない）の組み込みコマンドのprintfと、独立実行ファイル（GNU Coreutilsの一部）である/bin/printfがある。基本的な趣旨としては同一のコマンドだが、組み込みコマンドのほうは入力に<code>"</code>が含まれていない限り結果にも<code>"</code>が使われることはないようで、このおかげで意図しない動作を回避できることがある。今回扱う例に関しては前者が後者の上位互換であるということになる。後者を使っているものはそれでも動いたものである。
** そもそも%qは組み込みコマンドのほうにしかないという話もある。環境によって違いそう。
* <code>\\?\</code>が付くような長いパスをカレントディレクトリにしていても、Git Bash/Cygwinに付属の（というかMSYS/Cygwin向けにコンパイルされた？）exeなら実行できる。
* Git Bashの(ba)shは<code>--login</code>をつけて起動してもカレントディレクトリが維持されるが、<s>Cygwinの(ba)shは</s><s><code>--login</code></s><s>をつけると強制的にホームディレクトリに移動する。</s>
** 2024/4頃、Cygwinの挙動が変化し、カレントディレクトリが維持されるようになっていることに気付く。変わっていた方のバージョンは3.5.3、変わっていない方は3.3.6であった。
** ところで、[https://superuser.com/questions/345964/start-bash-shell-cygwin-with-correct-path-without-changing-directory Start bash shell (cygwin) with correct path without changing directory - Super User]の通り、<code>CHERE_INVOKING</code>という変数を1に設定しておけばカレントディレクトリは維持される。
* Git Bashにおいては環境変数を正しく設定するため<code>--login</code>の時点で環境変数<code>MSYSTEM</code>を<code>MINGW64</code>にしておく必要がある。[[Windowsでのターミナル環境|Windowsでのターミナル環境]] 参照。


==== powershell/pwsh ====

* バージョン5まで（Windows PowerShell）はpowershell.exe、6以降（PowerShell Core, PowerShell）はpwsh.exeと実行ファイル名が違う
** 以後、「powershell(.exe)」と「pwsh(.exe)」で呼び分ける。ただし手元ではpowershellの5.1とpwshの7.2～7.3くらいでしか試していないので、一部バージョンではまた違う可能性もある。
** pwshは必ずしもWindowsに標準では入っていないので、以下の例でもあまり依存しないように気を付ける。
** 基本、シングルクォートで囲えばほとんどの特殊文字が無効になり、シングルクォート自体を書くときは2つ並べる。ただし注意点として、驚くべきことにpowershell/pwshでは「全角のシングルクォート（U+2018-U+201B、<code>‘</code> <code>’</code> <code>‚</code> <code>‛</code>の4つ）」も通常のシングルクォートと同じ効力があるので、同じようにエスケープする必要がある（参照: [https://learn.microsoft.com/ja-jp/powershell/scripting/lang-spec/chapter-02?view=powershell-7.2 https://learn.microsoft.com/ja-jp/powershell/scripting/lang-spec/chapter-02?view=powershell-7.2]）。掲載したスクリプトでは省略しているがやることは同じ。
* powershell.exe
** -Commandがなくても付けたのと同じ扱いになる？
*** 逆に、-Commandを付けなければいけないという点を除いてはpwshがpowershellの上位互換という感覚である（新しいのでそれはそう）。
** <code>`</code>や<code>[]</code>を含むフォルダの扱いにバグがあり、cmdなどでこれらのフォルダをカレントディレクトリとした状態で5系のPowerShellを起動すると<code>C:\</code>や<code>C:\Windows\System32\WindowsPowerShell\v1.0></code>をカレントディレクトリとして起動される（たとえば<code>C:\somefolder][</code>なら前者、<code>C:\somefolder[]</code>なら後者）。
** -Fileを使用してスクリプトを実行するとき、ダブルクォーテーションで囲われていない <code>-</code> が引数に含まれているとエラーになるバグがある。
* powershell.exe・pwsh.exe共通
** 連続した<code>`</code>があるフォルダに関する挙動にバグがある。コンソールプログラムを実行しても新規ウインドウで開かれる、そこをカレントディレクトリとしたときにファイルをmvできないなど。
** <code>`</code>や<code>[]</code>を含むフォルダに関しても、絶対パス指定したりきちんとエスケープしたりすれば操作自体はできる（場合もある）。
*** エスケープはいずれも直前に<code>`</code>を付ける。
*** これらを特殊文字として扱いたくないときは<code>-LiteralPath</code>を付けると良い場合もある。
** UNCパスをカレントディレクトリにすることができるが、<code>Microsoft.PowerShell.Core\FileSystem::\\</code>とかいう謎のプレフィックスが付く。
** 末尾が空白のフォルダについてはcdできず、Cygwinなどでそのようなフォルダをカレントディレクトリとして起動したとしても<code>C:\Windows\System32\WindowsPowerShell\v1.0</code>や<code>C:\Program Files\PowerShell\7</code>に移動してしまう。
** 8.3形式のパスを強制的に長い名前に戻してcdしてしまう。その結果、長いフォルダをカレントディレクトリとして外部プログラムを実行できなくなる。
* PSModulePath環境変数の関係な気がするが、pwshの中でcmdを起動してその中でpowershellを起動したりするとPSReadLineモジュールが読み込めない（<code>PSReadline モジュールを読み込めません。コンソールは PSReadline なしで実行されています。</code>）とか言われたりする

==== 環境変数への置換 ====

cmdなどを使うと<code>%</code>で囲われた環境変数（<code>%PATH%</code>など）が置換される。<code>%</code>はファイル名にも普通に使える文字なので、注意が必要となる

* 該当の名前の環境変数が定義されていたときのみ置換が行われ、定義されていなければそのままになる。
* <code>%</code><code>VAR</code><code>%</code>の置換は必ずしもcmdだけで行われるわけではない。「ファイル名を指定して実行」、VBSのWscript.Shellのrun、conhost、wtの引数などでも行われる。しかしCreateProcessやShellExecute(Ex)やレジストリ値では行われない（無理やりREG_EXPAND_SZにしたら展開されるが、後述の<code>%V</code>との適用順などは不明）。
* 一般には、環境変数には英数字とアンダースコアしか使えないとの説明もよくあるが、実際にはほとんどの記号が有効である。従って、<code>^%PATH^%</code>のようなキャレットによるエスケープはcmd向けにはある程度有効だが、<code>PATH^</code>という環境変数が定義されているとうまく動かない。
* （そういう変数が定義されていることは現実にほとんどないだろうし、それが保証できるなら以下の部分を読む必要はない）

これを防ぐ方法はいくつかある。ちなみに、<code>%%</code>でのエスケープというのはバッチファイルの中だけの話で、今回の場面では以下より簡単なエスケープ方法は多分ないと思う。

<ol style="list-style-type: decimal;">
<li>既に定義されているかもしれない環境変数をバックアップし、一時的にその中身を<code>%</code>に変えて使用することでリテラル文字としての<code>%</code>を表現し、後で元に戻す。
すなわち、<code>MY_PERCENT</code>のような変数の中身をバックアップし、<code>MY_PERCENT</code>の中身を<code>%</code>に変え、未知の文字列中の<code>%</code>をすべて<code>%MY_PERCENT%</code>にすることでこの部分が置換によって<code>%</code>に変わるのを利用して<code>%</code>をそのまま渡すということである（環境変数の置換は左から順に行われるため、たとえば<code>%MY_PERCENT%PATH%MY_PERCENT%</code>の<code>%PATH%</code>が置換されることはない）。受け渡しが終わったら<code>MY_PERCENT</code>の中身を復元する。
これは、変数のバックアップとリストアを同じプロセス・スクリプト内で行える（呼び出した後に元に戻ってくる）場面で有用である。呼び出し先プロセスでリストアすることも不可能ではないと思うが、環境変数には任意の文字が入る可能性があることを考えるとエスケープが大変困難になることが予想される。</li>
<li>VAR1, VAR2, VAR3, …のような無限個の変数を最初からチェックし、最初の未定義の変数を上記と同様に使用し、後で未設定にする。
ほぼ上記と同じだが、内容のリストアでなく未設定にするだけなので、呼び出し先プロセスでも容易に行える。ただし実装が面倒である。</li>
<li><code>%</code>を<code>==%</code>へと置換して、置換のプロセスを抜けた段階で元に戻す。
<ul>
<li>これは、最初の文字以外に<code>=</code>が含まれる環境変数名は（実際に環境変数が設定されていたとしても絶対に）置換されないことがわかったためである。
<ul>
<li><code>%=%</code>（あるいは、<code>%=VAR%</code>など）は少なくともcmdの対話シェル上だと置換されてしまうので<code>=%</code>へのエスケープだと不十分に見えるが、実際には<code>=</code>一つでも問題なく動く場合もあった。</li>
<li>しかし、動かないときもあるので、多くの例では<code>==%</code>にエスケープしている。<code>=%</code>になっているものは、試した限りはそれでも問題なく動いているものである。</li>
<li>[https://learn.microsoft.com/en-us/windows/win32/procthread/environment-variables Environment Variables - Win32 apps | Microsoft Learn]では「<code>=</code>は環境変数に使えない」と書かれていて、ダイアログからでも設定はできないが、レジストリだと無理やり設定できる。
<ul>
<li>ユーザー環境変数に設定する分にはとりあえず問題なさそうだが、システム環境変数にレジストリから<code>=</code>（と、<code>=</code>を名前に含むいくつかの変数。どれが原因かは正確にはわからない）を無理やり追加したら0xc000021のブルースクリーンでWindowsが起動しなくなった（該当の変数を全て削除したら治った）のでこれはやってはいけない。</li></ul>
</li>
<li>ちなみに、<code>=</code>や<code>%</code>はUnix側では特殊文字ではないので、printfとの適用順はあまり気にする必要はない。</li></ul>
</li>
<li>この方法のメリットは、一度置換してしまえばその文字列を何度使いまわしても変化がないことが保証されることと、未定義の変数の探索や変数のリストアが必要ないことである。
<ul>
<li>要は<code>%(=を含まない文字列)%</code>を含まない文字列だけを値にとる単射を構成すればいいだけなので、base64エンコーディングのようにしても構わない。</li></ul>
</li>
<li>ただ、<code>==%</code>を<code>%</code>に置換するという操作はPowerShellやshにとっては容易でもcmdにとっては不可能に近いので、最終的な呼び出し先がcmdであるときには採用しづらい。</li></ul>
</li></ol>

また、今回の記事ではcmdやvbsのRunを経由してコマンドを実行しているものが多くあるが、このスクリプトの内容自体もエスケープが必要である。つまり、例えば<code>cmd /c</code>の内側に<code>$mypath.Replace('%','%MY_PERCENT%')</code>というPowershellコードが含まれるなら、<code>','</code>や<code>MY_PERCENT</code>という環境変数が定義されていた時にその部分が置換されてしまう。これを回避するのはそこまで難しくなく、この例であれば<code>$mypath.Replace('%'.Trim('='),'%'.Trim('=')+'MY_PERCENT%')</code>のように<code>=</code>を含む無意味なコードを挿入すればよい。また、<code>%</code>をいったん<code>==%</code>にしている部分に関しては、<code>==%</code>ではなく<code>==%==</code>にすることで問題を避けられるだろう。無駄に複雑になるのでスクリプト例ではそのような措置はしていない。

==== cmd ====

* UNCパス（<code>\\?\</code>だけでなく普通のUNCパスも含む）をカレントディレクトリにすることはできない（rdなど一部コマンドでの取り扱いは可能）。
* 末尾が空白のフォルダにcdすることはできないが、Cygwinなどでそのようなフォルダをカレントディレクトリとした状態でcmdを起動した場合は、そのフォルダをカレントディレクトリとして起動する（外部プログラムの起動はできないがcdなどの内部コマンドは有効で、一度でも出たら戻れない）。
* 各種のパース規則が本当に謎。特に引用符周りは地獄である。[https://thinca.hatenablog.com/entry/20100210/1265813598 cmd.exe のコマンドラインの仕様を解析してみた - 永遠に未完成]を読むとわかるが、例えば「ファイル名を指定して実行」で以下の挙動を確かめよう。
** <code>cmd /k echo "a b"c d"</code>→<code>"a b"c d"</code>と出る
** <code>cmd /k echo "a & b"c d"</code>→<code>"a & b"c d"</code>
** <code>cmd /k echo "a b"c & d"</code>→<code>echo "a b"c</code>と<code>d"</code>がそれぞれ別々に実行される
** すなわち、<code>"</code>が一見特殊文字でないかのような振る舞いをする（そのまま出力される）割に、その前後で特殊文字の扱いが切り替わっている。


==== Windows Terminal ====

* 以下、wtと略す（実行ファイル名がwt.exeなため）。パスが通っているものと仮定する。
* wtでは<code>;</code>が特殊文字になるようで、<code>\;</code>とエスケープが必要。[https://github.com/microsoft/terminal/issues/13264 https://github.com/microsoft/terminal/issues/13264] かな？
** <code>"</code>も<code>\"</code>にする必要がある。一方で、単一の<code>\</code>は（うしろに<code>;</code>や<code>"</code>などがなければ）そのまま<code>\</code>になるようである。大丈夫なのか…？
* 起動時にカレントディレクトリがユーザーフォルダ（%USERPROFILE%）になる
** <code>-d</code>オプションで明示的に指定することができる

==== 連続空白 ====

空白が連続するファイル名の対応は割と厄介である。Windows側では引数を<code>""</code>で囲うことで、またsh側では適宜<code>IFS=</code>と設定することで対処できる。


==== Unicode対応 ====

* UTF8を使おう
* <code>chcp 65001</code>が一応使えるが、一旦シェル内部に入らないと使えないのでやや不便
** 使わなくても大丈夫なときもある。あまりちゃんと理解できていないが、経験上、powershellで<code>$input</code>変数を用いて標準入力を受け取る際には<code>chcp 65001</code>が必要そう。
* /bin/printfやprintfの実行時には<code>LANG</code>を<code>en_US.UTF8</code>とかに設定する。
** Cygwinなら不要？

==== デバッグ時 ====

* 管理者権限のものを試すときでもまず<code>-Verb Runas</code>を外して動作確認するとよい。
* 後述のwaitrunも役に立つだろう。
* 特殊文字に関しては、最初は空白のないフォルダ、次に空白のあるフォルダや連続空白のあるフォルダ、次にシングルクォートや<code>%PATH%</code>を含むフォルダなどとだんだん難しくしていくとよい。
* それとは別に、Unicode対応、<code>C:\</code>（ドライブ直下）対応、259文字のフォルダ対応（後述）などをチェックする
* 難しい例は、例えば<code>z 𠮷𠮷%PATH% ' '' ` `` $PATH & && %%PATH%%[] ] [ ^ ^^ ' ; ;; 𩸽𩸽!PATH!#$%&'()=~{`+}_,.][;@^- - ‘ ’ ‚ ‛</code>のような感じ（適当）。こんなファイル名を現実に見ることはないが、エクスプローラー上で普通に入力できる内容である。
** 「𠮷」はBMP外かつJIS外の漢字としては最も変換で出しやすいのでテストに重宝する。（𩸽はBMP外だがJIS外ではない（第4水準））

==== その他 ====

* デフォルトシェルは、通常ユーザーはwtでも管理者の場合はconhostに設定されているっぽい？
* <code>C:\</code>のようなドライブ直下のパスは末尾に<code>\</code>を付けなければいけないことが多い。たとえばwt -dの引数にする場合など。またcmdでcdコマンドや<code>CD</code>環境変数を見るときもドライブ直下のときだけは<code>\</code>が付いて返ってくる。
** ただ、wt -d に<code>C:</code>が渡されるように見えるのになぜか動いているものもある。未調査。
* shやcmdなどの中に一旦入ってしまうと一部の環境変数などが書き換わってしまうかもしれないが、多少は許容することとする。
* コマンド例は網羅的でない可能性があり、色々な書き方を提示しようとあえて統一していないところもある。現実にはもっと簡単なやり方があるかもしれない。あくまで一例ということで。
* CygwinとGit Bashはほぼ同じなのでGit Bashを主に載せてCygwinは適宜差分のみ記述する。
* shは、特にベースのシェルとして使うにはエスケープの方式などでWindowsと相性が悪く使いづらい感じがする。逆にcmdは内部コマンドは地獄だがベースのシェルとしては意外と副作用が少なく、そう悪くはない。
* 以下の例ではCygwinやGit Bashの実行ファイルにはPATHを通していないことを想定している。<code>C:\cygwin64</code>あたりは適当に読み替えていただきたい。
* 2021年途中ごろまで、wtなどのストアアプリ系？の実行ファイル（Explorer上で0バイトになってるエイリアス）をGit Bashから実行できない（Permission deniedとなる）バグがあった。 [https://github.com/git-for-windows/git/issues/2675 https://github.com/git-for-windows/git/issues/2675]
* ネットワークドライブは各ユーザー対象に割り当てられているせいなのか、管理者として実行すると利用できないらしい。割り当てられる前のネットワークパス自体は有効。
* wtを管理者権限で呼び出すときに（確率的に）ウインドウが最前面にならないことがある。chcpの有無で変わったりするなど詳細不明。conhostだとならない気がする。startrunなどを介して実行すると必ず最前面に出るようになるっぽい。


== 準備: win-console-delegator ==

cmdやPowerShellやCygwinのbashなどのシェルを使えば、スクリプトを起動して複雑なコマンドを呼び出せたり、パイプ実行が可能になったりと色々便利だが、それだけのためには大仰すぎて、特殊文字の扱いなどがかえって仇になることもある。

そこで、シェル関連の操作に汎用的に使えるコマンドをいくつか作成して公開した。[https://github.com/ge9/win-console-tools https://github.com/ge9/win-console-tools]

* 以前はC++で書いていた（[https://github.com/ge9/win-console-delegator https://github.com/ge9/win-console-delegator]）が、C#のほうが文字列の扱いなどが簡明。

ただし、これはあくまで筆者が独自に作ったものであり、Windows標準のもので何とかしようとするのが面白いところでもあるので、それほど積極的には使わない。今後出てくる例はすべて、これらを一切使わなくても（余計な環境変数が設定されてしまうかもしれないという点をのぞけば）同等の機能が実現できる。

<ul>
<li>runother
与えられた引数を特定の文字列とつなげて実行してくれるプログラム。この実行ファイル自体の名前を適宜変更して使用し、「特定の文字列」は別のファイルから読ませる。使用例は[[Windowsでのターミナル環境|Windowsでのターミナル環境]] を参照。</li>
<li>runother-gui
runotherとほぼ同じだが、コンソールアプリケーションではなくWindowsアプリケーション（黒いウインドウが出ない、cmd上で実行したときに終了待ちが行われないなど）。</li>
<li>evalrun
与えられたコマンドラインを実行し、その出力をそのままコマンドラインとして実行するコンソールアプリケーション。（テキストファイルからのコマンドラインの読み込みなどに使える）</li>
<li>startrun
与えられたコマンドラインをWindowsのデフォルトシェルで起動するだけのWindowsアプリケーション。</li>
<li>waitrun
与えられたコマンドラインを実行したあとキー入力を待ってから終了するコンソールアプリケーション。一瞬でウインドウが消えてしまうときのデバッグに使いやすい。</li>
<li>hiderun
コンソールウインドウ非表示の状態で与えられたコマンドを実行するWindowsアプリケーション。（GUIアプリケーションなどを与えた場合は非表示にならないかも）
vbsのvbHideでも非表示にできるが、コンソールウインドウの表示位置をみると非表示のウインドウが一つ挟まっていることが分かるのに対して、こちらの場合はそうならない。</li>
<li>piperun
与えられたコマンドラインを最初の<code>|</code>とそれ以降の2つに区切ってそれぞれコマンドとしてパイプでつなげて実行するコンソールアプリケーション。ただし最初のコマンドのほうに<code>|</code>自体を入力したいときは<code>||</code>でエスケープする。また2つ目のコマンドの先頭の空白は除去される。</li>
<li>piperunex
piperunと似ているが、2つだけでなく3つ以上の任意個のパイプ実行を一度に行う。一見便利だが、コマンドの後ろ側に未知の文字列が渡される場合、<code>|</code>をエスケープする必要が生じる。
<code>piperun piperunex command1 || command2 || ... || commandN | unknown_commandline</code>のように外側を<code>piperun</code>で囲うと安全。</li>
<li>adminrun
与えられたコマンドラインを管理者として実行するWindowsアプリケーション。<code>ShellExecuteEx</code>では実行ファイルパスと引数は別々に指定しなければいけないので最低限の引数の解析を行っている。PowerShell経由で管理者権限で実行するときのような面倒なエスケープが全て不要になるため非常に使いやすいが、この記事ではこれに依存しないようにする。
<ul>
<li>ちなみにこういうのもある。[https://github.com/mattn/sudo mattn/sudo: sudo for windows] これは、通常のUACのように別ウインドウで実行するのではなく、localhostのランダムなポートを使い、自分自身にポート番号を渡しつつ管理者権限で呼び出すことで標準入出力を転送し、元の端末でそれを読み書きできるという点で、linuxのsudoに近い。しかし標準入出力を介しているので、<code>cmd /c for /?</code>や<code>cmd /c pause</code>の挙動が変わってしまうという問題がある。また、呼び出し元でchcp 65001をしていると文字化けする。また、コマンドライン引数を一旦配列に分割してから組み直しているので情報が一部落ちている。あと、セキュリティ的にも懸念があるかもしれないが、これはそもそもLinuxのsudo自体がまずどうなの？という気持ちになった。（未解決）（参照: [https://twitter.com/e9g/status/1687385469921931264?s=20 https://twitter.com/e9g/status/1687385469921931264?s=20]）</li></ul>
</li>
<li>uacrun
startrunと同じだが、コンパイル時のマニフェスト設定でこのプログラム自体の実行に管理者権限を要求するようにしたので、adminrunと同じように使える（管理者権限で実行する対象が渡されたコマンドではなくuacrun自体になるという違いはある）</li>
<li>pecho
与えられたコマンドライン引数をそのままコンソールに出力する。→WindowsでUnicode文字（特にU+10000以上）を正しく表示（&ファイルに書き込み）するには、「出力先がコンソールならWriteConsoleW、そうでなければWriteFileを使用する」といった非常に面倒な実装が必要であり（参照: [https://twitter.com/mattn_jp/status/542581083242364928 https://twitter.com/mattn_jp/status/542581083242364928] など）、C++やC#では扱いづらい。そこでrustを用いて実装した。→[https://github.com/ge9/pure-echo-win pure-echo-win]</li>
<li>printcd
カレントディレクトリをコンソールに出力する。（ちなみにpwdの由来はprint working directoryなのでそれに倣った）</li></ul>


== 注意: 当初は後述のNoWorkingDirectoryを知らなかったので1.の方法に頼っていたが、実際には2.の方法のほうが簡明なので、そちらを使うことを勧める。1.は残しておくが、読む必要はあまりない。 ==

{{UnderConstruction|Windowsでエクスプローラーからフォルダを各種ターミナルで開く}}


== 1.標準入力から受け取る場合 ==

まず「標準入力からディレクトリのフルパスを受け取り、そのディレクトリで各種ターミナルを起動するコマンド」を紹介する。

そのようなコマンドを仮に<code>openterm</code>とすると、ExecuteCommand-Pipeを使用して、レジストリ（該当CLSIDのLocalServer32の既定の値）に以下のように書くことで、CLSIDが右クリックメニューのDelegateExecute値に使えるようになる。

<code>C:\path\to\ExecuteCommand4000.exe h openterm</code>

<code>h</code>はコンソールウインドウを非表示にするExecuteCommand-Pipeのオプションである。

また、この<code>openterm</code>の部分は非常に長くなることがあり、その場合レジストリに書いて直接編集するのは手間がかかる（操作もしづらいし、更新を即座に反映させるために「<code>LocalServer32</code>」キーの名前などを変えて戻す必要もあって面倒）。そこで、runotherを使ってtxtに<code>openterm</code>の内容をそのまま書くことで、<code>openterm</code>の部分にそのexeの名前だけを書けばよくなる。

また、いくつかはCygwin/Git Bash向けに冒頭でcygpathによる変換を入れているが、これを取り除けば、Cygwin/Git Bash用のパスを受け取って動作するコマンドということになる。

では以下で、<code>openterm</code>部分についてそれぞれ紹介する。

* 直接コマンド記入でも<code>NoWorkingDirectory</code>を指定すれば<code>\\?\</code>に対応できるというのをこのセクションの大部分を書き終えてから知ったので、このセクションは内容の多さの割には実際の必要性はそこまで大きくないかもしれない。


=== Git Bash ===


==== <code>git-bash.exe</code>で開く ====

この場合shの感覚で<code>git-bash.exe</code>に引数を渡せば勝手にminttyのウインドウで開いてくれるので最も楽である。

<code>cmd /c ""C:\Program Files\Git\usr\bin\cygpath" -f - | "C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=;/bin/env LANG=en_US.utf8 /bin/printf %q $(/bin/cat)" | "C:\Program Files\Git\usr\bin\xargs" -d '\n' -I {} "C:\Program Files\Git\git-bash.exe" -c "cd {};exec bash""</code>

* Git BashのcygpathでGit Bash用のパスに変換
* printfでエスケープ、utf8を設定
* git-bash.exeに渡す


==== デフォルトのターミナルで開く: ①startrunを使う ====

<code>cmd /c ""C:\Program Files\Git\usr\bin\cygpath" -f - | "C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=;/bin/env LANG=en_US.UTF8 /bin/printf %q $(/bin/cat)" | "C:\Program Files\Git\usr\bin\xargs.exe" -d '\n' -I {} startrun "C:\Program Files\Git\usr\bin\env.exe" MSYSTEM=MINGW64 "C:\Program Files\Git\usr\bin\bash.exe" --login -i -c 'cd {};exec bash'"</code>

* <code>git-bash.exe</code>や<code>C:\Program Files\Git\bin</code>のbashではなく/usr/binのbash.exeを使う。以後同じ。


==== デフォルトのターミナルで開く: ②cmdのstartを使う ====

<code>cmd /c ""C:\Program Files\Git\usr\bin\cygpath" -f - | "C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=;/bin/env LANG=en_US.UTF8 /bin/printf %q $(/bin/sed 's/\\^/^^/g;s/%/=%/g;s/&/^&/g')" | "C:\Program Files\Git\usr\bin\xargs.exe" -d '\n' -I {} cmd //c start "" "C:\Program Files\Git\usr\bin\env.exe" MSYSTEM=MINGW64 "C:\Program Files\Git\usr\bin\bash.exe" --login -i -c 'cd "$(echo {} ^| sed s/=%/%/g)";exec bash'"</code>

* この場合、cmdによる環境変数への置換を避ける必要があるほか、キャレットによるエスケープにも対応する必要がある。
* Git Bashからcmdを実行しているので<code>//c</code>のところのスラッシュは2つ。

==== conhostで開く ====

<code>cmd /c ""C:\Program Files\Git\usr\bin\cygpath" -f - | "C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=;/bin/env LANG=en_US.UTF8 /bin/printf %q $(/bin/sed 's/%/=%/g')" | "C:\Program Files\Git\usr\bin\xargs.exe" -d '\n' -I {} conhost "C:\Program Files\Git\usr\bin\env.exe" MSYSTEM=MINGW64 "C:\Program Files\Git\usr\bin\bash.exe" --login -i -c 'cd "$(echo {}|sed s/=%/%/g)";exec bash'"</code>

conhostによる環境変数の置換を抑制。


==== Windows Terminalで開く ====

<code>cmd /c ""C:\Program Files\Git\usr\bin\cygpath" -f - | "C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=;LANG=en_US.UTF8 printf %q $(/bin/sed 's/%/=%/g')" | "C:\Program Files\Git\usr\bin\sed.exe" "s/;/\\\\;/g" | "C:\Program Files\Git\usr\bin\xargs.exe" -d '\n' -I {} wt "C:\Program Files\Git\usr\bin\env.exe" MSYSTEM=MINGW64 "C:\Program Files\Git\usr\bin\bash.exe" --login -i -c "IFS=\\;cd $(echo {}|sed s/=%/%/g) \\;exec bash""</code>

上記に加えてセミコロンへの対応が必要なのと、こっちは/bin/printfじゃなくて組み込みのprintfでこうしないとだめだった。


==== Cygwin ====

付属のminttyを使うものだけはGit Bashと割と差があるので載せる。

<code>cmd /c ""C:\cygwin64\bin\cygpath" -f - | "C:\cygwin64\bin\sh.exe" -c "IFS=;/bin/printf %q $(/bin/cat)" | "C:\Program Files\Git\usr\bin\xargs" -d '\n' -I {} "C:\cygwin64\bin\mintty.exe" -e "C:\cygwin64\bin\bash.exe" --login -i -c "cd {};exec bash""</code>


=== PowerShell ===


==== デフォルトシェル, startrun ====

* パスのエスケープがおかしい気がするが、なぜか動いている

<code>cmd /c ""C:\Program Files\Git\usr\bin\sed.exe" "s/'/''/g" | "C:\Program Files\Git\usr\bin\xargs.exe" -d '\n' -I {} startrun powershell -noexit -command Set-Location -literalPath "'{}'""</code>


==== デフォルトシェル, cmdのstart ====

<code>cmd /c ""C:\Program Files\Git\usr\bin\sed.exe" "s/'/''/g;s/%/=%/g" | "C:\Program Files\Git\usr\bin\xargs.exe" -d '\n' -I {} cmd //c start "" powershell -noexit -command Set-Location -literalPath '\'{}\'.Replace(\'=^%\',\'%\')'"</code>


=== cmd ===


==== Windows Terminal ====

<code>cmd /c chcp 65001 & powershell -Command "$mypath=($input | ForEach-Object { return $_ });$bak=$env:MY_PERCENT; $env:MY_PERCENT = '%';if ($mypath.Length -gt 258) { $mypath = cmd /c \"for %A in (`\"$($mypath.Replace('%', '%MY_PERCENT%'))`\") do @echo %~sA\" };$env:MY_PERCENT = $bak;wt -d ($mypath -replace ';', '\;') cmd"</code>

<ul>
<li>[[Windowsのパス長さ制限に関して|Windowsのパス長さ制限に関して]] でも書いた通り、Windows側はちょうど259文字の長さのフォルダだけは（その必要があるにもかかわらず）8.3形式を使った短いパスにして渡してくれない。そこで、パス長さが258を超えていればcmdに渡して8.3形式の名前に変換する処理をPowerShell側で行う。この際はエスケープされていない正確なパス名をcmdに渡さなければならないので<code>MY_PERCENT</code>の値を一時的に<code>%</code>に設定する方法をとっている。
<ul>
<li>念のため再確認しておくが、この<code>'%MY_PERCENT%'</code>の部分は<code>'%'.Trim('=')+'MY_PERCENT%')</code>などと変えておかないと、<code>MY_PERCENT</code>が定義されていた場合に正しく動作しない。</li>
<li>cmdではちょうど258文字のフォルダでもdirが失敗するなど挙動が不自然であるため、もう少し保守的に257を超えていれば短くするという仕様でもいいかもしれない。</li></ul>
</li>
<li>（追記）8.3形式のパスを取得するのは普通にPowerShell内でもできるらしい…。以下のようになる。
<code>if ($mypath.Length -gt 258) { $mypath = (New-Object -ComObject Scripting.FileSystemObject).GetFolder($mypath).ShortPath}</code></li></ul>

259文字のフォルダを無視するなら以下のように簡潔に済む。

<code>cmd /c chcp 65001 & powershell -Command wt '-d' $input.Replace(';','\;') cmd</code>

==== デフォルトシェル ====

これは案外難しい。なぜなら、cmd内でcdさせるのは%のエスケープの関係で難しく（cmd内で=を含む文字列を置換することがどうやってもできなさそう（外部プログラムを呼び出すのも難しそうだった）なので、未定義の変数を探索するやり方しかない）、Start-Processの-WorkingDirectoryやCygwinのshは8.3形式に対応していないからである。要は「与えられたディレクトリ（8.3形式のパスが含まれるかもしれない）をカレントディレクトリとして与えられたコマンドを実行する」だけやってくれるプログラムがあればよく、これ自体はそう難しくないことのはずだが、現状、Windows標準環境でこれができるのは自前でプログラムをコンパイルする以外だと（pwshを入れていいならpwshと）vbsしかないようである。結局、この部分をついでにやってくれるWindows Terminalのほうが楽ということになる。

たとえば以下のようなvbsを用意する。

<syntaxhighlight style="margin-bottom:0.2em;" lang="vb.net">Dim objShell
Set objShell = CreateObject("WScript.Shell")
objShell.CurrentDirectory = WScript.Arguments(1)
objShell.Run(WScript.Arguments(0)),,False</syntaxhighlight>
<div style='text-align: center;'>startatdir.vbs</div>

すると以下のように書ける。

<code>cmd /c chcp 65001 & powershell -Command "$mypath=($input | ForEach-Object { return $_ });$bak=$env:MY_PERCENT;$env:MY_PERCENT = '%';if ($mypath.Length -gt 258) { $mypath = cmd /c \"for %A in (`\"$($mypath.Replace('%', '%MY_PERCENT%'))`\") do @echo %~sA\" };$env:MY_PERCENT = $bak; wscript 'C:\path\to\startatdir.vbs' cmd ('\"'+$mypath+'\"')"</code>

なお<code>startatdir.vbs</code>のパス指定はフルパスが必要そう（ただしここはcmd /cの中なので<code>%USERPROFILE%</code>とかを使って書いてもよい）


== 1.1.標準入力から受け取る場合 - 管理者権限あり ==

上記の続きで、こちらは管理者権限ありのもの。


=== Git Bash ===


==== デフォルトシェル ====

<code>cmd /c ""C:\Program Files\Git\usr\bin\cygpath" -f - | "C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=;/bin/env LANG=en_US.UTF8 /bin/printf %q $(/bin/cat)" | "C:\Program Files\Git\usr\bin\sed.exe" "s/'/''/g" | "C:\Program Files\Git\usr\bin\xargs.exe" -d '\n' -I {} powershell -Command Start-Process -Verb Runas -Filepath '"C:\Program Files\Git\usr\bin\env.exe"' -ArgumentList '"MSYSTEM=MINGW64"', '"`"C:\Program Files\Git\usr\bin\bash.exe`""' , '--login', '-i' , '-c', "'\"cd {}; exec bash\"'" "</code>

* Start-Process自体がstartみたいなものなので、引数にコンソールアプリケーションを指定したらデフォルトシェルで開かれる。
* 最後のところ、「<code>"'\"cd {}; exec bash\"'"</code>」のかわりに「<code>'\'"cd {};exec bash"\''</code>」とか「<code>'\'\"cd {};exec bash"\''</code>」でも動くのは謎。シングルクォーテーションのエスケープ規則がわからない。参考→[https://twitter.com/e9g/status/1678283164689760256 https://twitter.com/e9g/status/1678283164689760256]


==== Windows Terminal ====

<code>cmd /c ""C:\Program Files\Git\usr\bin\cygpath" -f - | "C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=;LANG=en_US.UTF-8 printf %q $(/bin/cat)" | "C:\Program Files\Git\usr\bin\sed.exe" "s/'/''/g;s/%/==%/g;s/;/\\\\;/g" | "C:\Program Files\Git\usr\bin\xargs.exe" -d '\n' -I {} powershell -Command Start-Process -Verb Runas -Filepath wt -ArgumentList "'"'"C:\Program Files\Git\usr\bin\env.exe"'"'" , '"MSYSTEM=MINGW64"' , "'"'"C:\Program Files\Git\usr\bin\sh.exe"'"'" , "'--login'", "'-c'", "'"'"IFS=\\;cd $(echo {}| /bin/sed s/==%/%/g) \\; exec bash"'"' " "</code>

==== adminrunを使う ====

<code>piperunex "C:\Program Files\Git\usr\bin\cygpath" -f - | "C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=; /bin/env LANG=en_US.UTF8 /bin/printf %q $(/bin/cat)" | "C:\Program Files\Git\usr\bin\sed.exe" "s/%/==%/g;s/;/\\\\;/g" | "C:\Program Files\Git\usr\bin\xargs.exe" -d '\n' -I {} adminrun wt "C:\Program Files\Git\usr\bin\env.exe" "MSYSTEM=MINGW64" "C:\Program Files\Git\usr\bin\sh.exe" --login -c "IFS=\\;cd $(echo {}|| /bin/sed s/==%/%/g) \\; exec bash"</code>


=== PowerShell ===


==== Windows Terminal ====

<code>cmd /c ""C:\Program Files\Git\usr\bin\sed.exe" "s/'/''''/g;s/%/==%/g;s/;/\\\\;/g" | "C:\Program Files\Git\usr\bin\xargs.exe" -d '\n' -I {} powershell -Command Start-Process -Verb Runas -Filepath wt -ArgumentList 'powershell', '-noexit', '-command', 'Set-Location', '-LiteralPath', "'''\"{}\"''.Replace(''==%'',''%'')'" "</code>

* Cygwin系なしで

<code>cmd /c "chcp 65001 & powershell -Command Start-Process -Verb Runas -Filepath wt -ArgumentList 'powershell', '-noexit', '-command', 'set-location', '-literalpath', ('\"'''+($input -replace '''', '''''' -replace '%', '==%' -replace ';', '\;' )+'''.Replace(''==%'',''%'')\"') "</code>


=== cmd ===


==== デフォルトシェル ====

再び、startatdir.vbsを使う。

<code>cmd /c chcp 65001 > nul & powershell -Command "$mypath=($input | ForEach-Object { return $_ });$bak=$env:MY_PERCENT; $env:MY_PERCENT = '%';if ($mypath.Length -gt 258) { $mypath = cmd /c \"for %A in (`\"$($mypath.Replace('%', '%MY_PERCENT%'))`\") do @echo %~sA\" };$env:MY_PERCENT = $bak; Start-Process -Verb Runas -Filepath wscript -Argumentlist '//Nologo', 'C:\path\to\startatdir.vbs', 'cmd', ('\"'+$mypath+'\"')"</code>


==== Windows Terminal ====

<code>cmd /c chcp 65001 & powershell -Command "$mypath=($input | ForEach-Object { return $_ }); $bak=$env:MY_PERCENT; $env:MY_PERCENT = '%';if ($mypath.Length -gt 258) { $mypath = cmd /c \"for %A in (`\"$($mypath.Replace('%', '%MY_PERCENT%'))`\") do @echo %~sA\" };$env:MY_PERCENT = $bak;Start-Process -Verb Runas -Filepath wt -Argumentlist '-d', ('\"'+($mypath -replace '\\$','\\\\' -replace ';', '\;')+'\"'), cmd"</code>

この場合は<code>C:\</code>のための対処（<code>-replace '\\$','\\\\'</code>）が必要である。259文字のフォルダを無視するなら以下の通り。

<code>cmd /c "chcp 65001 & powershell -Command Start-Process -Verb Runas -Filepath wt -ArgumentList '-d', ('\"'+($input -replace '\\$','\\\\').Replace(';','\;')+'\"'), cmd"</code>


== 2.直接コマンド記入の右クリックメニュー ==

レジストリの<code>command</code>キーの既定の値に直接コマンドを記入する方式である。

デフォルトでは、右クリックメニューを押した時点でのフォルダ（フォルダを右クリックするメニューからだと対象フォルダの親、フォルダ背景を右クリックするメニューなら対象フォルダ）をカレントディレクトリとしてコマンドが起動される。そのため<code>\\?\</code>を付けなければならないような長大なパスのフォルダでは動作しない。しかし、<code>shell\xxxx</code>キーに<code>NoWorkingDirectory</code>値を設定することで、カレントディレクトリが必ず<code>C:\Windows\System32</code>に設定されるようになるので動くようになる。

対象のディレクトリはどう取得するかというと、レジストリに書き込んだ値のうち<code>%V</code>という部分が対象ディレクトリに書き換えられてコマンドが実行される。この<code>%V</code>もC:などの場合は<code>C:\</code>になる。コマンドの中でそのまま%という文字を使いたい場合はバッチファイルと同様に%%とエスケープする必要があるようである（これはどこにも書いてない？）。

しかし、こうして渡される（特殊文字を含むかもしれない）ディレクトリ名を完璧に取得するのは意外と難しい。cmdに解釈させると<code>%</code><code>VAR</code><code>%</code>が置換されてしまうし、シングルクォートとバッククォートが両方含まれているのでpowershellやshに渡すのも簡単ではない。

コツは、powershell -commandやsh -cの中に直接書くのではなく、スクリプトへのコマンドライン引数として渡した上で、スクリプト内で引数として取得することである。それぞれ、基本形（そのまま出力するだけ）は以下のようになる。

<ul>
<li>powershell
<code>powershell -Command "& {echo $args[1].Trim('\"')}" --%% "\"%V\""</code>
<ul>
<li><code>--%</code>というトークンを入れることでその後のパラメータの解析を行わないようにできる。args[0]は<code>--%</code>になるのでargs[1]を使う。レジストリに書く際は<code>%</code>をエスケープして<code>--%%</code>。</li>
<li><code>--</code>でも同様のことができる？<code>powershell -Command "& {echo $args[0].Trim('\"')}" -- "\"%V\""</code>（args[0]になっていることに注意）</li>
<li>というか、<code>--%</code>で書き進めてしまったが、本当は<code>--</code>のほうが安定するかもしれない。</li></ul>

あるいは<code>$MyInvocation.Line</code>を使う方法もある。この場合、powershellへの引数が全て（この例なら<code>-noexit -Command "& {$spl = ...</code>のところから）取得されるので、目当ての部分を取り出すためにここでは最後から2番目の<code>"</code>と最後の<code>"</code>の間を取得するという風にしている。
<code>powershell -noexit -Command "& {$spl = $MyInvocation.Line -split'\"' ; Set-Location -LiteralPath $spl[$spl.Length-2]}" --%% "\"%V\""</code>
昔のPowerShell（2くらい）で試してみたらこちらでないと<code>`</code>や<code>&</code>あたりの処理がうまくいかない場合があった。argsを使うものからの書き換えは容易である。</li>
<li>sh
<code>sh -c "IFS=;echo $*" -- "%V</code>
<ul>
<li>最後が<code>"%V</code>と閉じられていないのはミスではなく、<code>"%V"</code>としてしまうと<code>C:\</code>のときに<code>C:"</code>が渡されてしまうのでそれを避けるためである（これはかなりトリッキーなのでもう少し真面目にやってもいいとは思う）。</li>
<li>UNCパスの最初の<code>\\</code>が<code>\</code>に変わってしまう（手元では、Cygwinの場合は<code>\\?\</code>のみで発生している？）という問題があり、適宜置換する必要がある。</li></ul>
</li></ul>

これらの書き方はいわゆる「ワンライナー」的なものであるが、もちろん外部にスクリプトファイルを用意してもよい。

また、外部にスクリプトを用意してよいという条件であれば、vbsも使用可能である。

<ul>
<li>この場合、まずレジストリには
<code>wscript "C:\path\to\script.vbs" "%V"</code>
などと書く。スクリプトの内容は上記のレジストリの内容をほぼそのままWscript.ShellでRunすればよいが、<code>%V</code>のかわりにWscript.Arguments(0)を挿入するのと、<code>%</code>を<code>%%</code>にエスケープしなくてよいのと、VBSなので文字列内の<code>"</code>は<code>""</code>に変えなければならない。これに加え、Runの引数に含まれる<code>%</code><code>VAR</code><code>%</code>が置換の対象となるため、対象フォルダの文字列については<code>==%</code>への置換でエスケープして、呼び出し先のpowershellなどで元に戻す。</li>
<li>必要に応じてRunのオプションでvbHideを指定する。</li>
<li>というか別に258文字を超えていたら云々みたいな処理も全部vbs側でやってしまってもよい（面倒なのでそういう例は載せていない）</li></ul>

バッチファイルに渡すのは、バッチファイルをcmdが呼び出す時点で<code>%PATH%</code>のようなファイル名の環境変数は既に展開されてしまうので、どうやっても不可能。

他には、（hiderunと）piperunとpechoを併用するという方法もあり、それらの実行ファイルを用意する必要があるという以外は綺麗にできる方法である。

いずれにしろ、一旦取得できてしまえばあとは前述の<code>openterm</code>に流し込むだけでよい。ただ、実際にはわざわざ<code>openterm</code>に流し込まなくても（パイプを使わなくても）もっと簡単に起動できることもあるのでそちらを中心に紹介する。

* commandの最初で指定する（メインの）実行ファイル（先ほどなら<code>powershell</code>や<code>sh</code>）をファイル名単体で書く場合は、それが（メニューをHKCUで設定するならHKCUの（最近のWindowsならHKLMのでも可？）、HKLMで設定するならHKLMの）App Pathsキーに登録されていなければならない（PATHは通っていなくてもいい）。登録されていない場合はフルパスで指定する必要がある。

=== 設定例 ===

==== 管理者権限なし ====

<ul>
<li>PowerShell
デフォルトターミナルで
<code>powershell -noexit -Command "& {Set-Location -LiteralPath $args[1].Trim('\"')}" --%% "\"%V\""</code>
<ul>
<li>参考までに、Windowsにもともと入っているメニューでは以下のようになっている。
<code>powershell.exe -noexit -command Set-Location -literalPath '%V'</code>
これだとシングルクォートと連続スペースに対応できない。連続スペースだけなら<code>'%V'</code>を<code>"'%V'"</code>に変えると解決できる。<code>%$[]`</code>あたりは見た感じ問題なし。
<ul>
<li>以下の解決策でもまだ不完全 [https://superuser.com/questions/1310258/open-powershell-window-here-file-explorer-context-menu-command-breaks-with-fol "Open PowerShell window here" File Explorer context-menu command breaks with folder names with apostrophes (single quotes) - Super User]</li></ul>
</li>
<li>この問題は[https://github.com/PowerShell/PowerShell/issues/6598 https://github.com/PowerShell/PowerShell/issues/6598]や[https://github.com/PowerShell/PowerShell/pull/6660 https://github.com/PowerShell/PowerShell/pull/6660] で扱われており、結局pwshでは-WorkingDirectoryというパラメータが追加された。[https://github.com/PowerShell/PowerShell/issues/14091 https://github.com/PowerShell/PowerShell/issues/14091]にある以下の文字列をレジストリに書いたところ、正しく動作したので、pwshではこれでよい。
<code>pwsh.exe -NoExit -RemoveWorkingDirectoryTrailingCharacter -WorkingDirectory "%V!" -Command "$host.UI.RawUI.WindowTitle = 'PowerShell 7 (x64)'"</code></li></ul>

wtで
<code>hiderun powershell -Command "& {wt powershell -noexit -Command Set-Location -LiteralPath ('\"'''+($args[1] -replace '''', '''''' -replace '%%', '==%%' -replace ';', '\;' )+'''.Replace(''==%%'',''%%'')\"')}" --%% "\"%V\""</code></li>
<li>cmd
wtで。標準入力のときとほぼ同じ。
<code>powershell -Command "& {$bak=$env:MY_PERCENT;$mypath=$args[1].Trim('\"'); $env:MY_PERCENT = '%%';if ($mypath.Length -gt 258) { $mypath = cmd /c \"for %%A in (`\"$($mypath.Replace('%%', '%%MY_PERCENT%%'))`\") do @echo %%~sA\" };$env:MY_PERCENT = $bak;wt -d ($mypath -replace ';', '\;') cmd}" --%% "\"%V\""</code>
<ul>
<li>デフォルトターミナルで
startatdir.vbsを使う。
<code>powershell -Command "& {$bak=$env:MY_PERCENT;$mypath=$args[1].Trim('\"'); $env:MY_PERCENT = '%%';if ($mypath.Length -gt 258) { $mypath = cmd /c \"for %%A in (`\"$($mypath.Replace('%%', '%%MY_PERCENT%%'))`\") do @echo %%~sA\" };$env:MY_PERCENT = $bak; wscript 'C:\path\to\startatdir.vbs' cmd ('\"'+$mypath+'\"')}" --%% "\"%V\""</code></li>
<li>Windowsにもともと入っているメニューでは以下。
<code>cmd.exe /s /k pushd "%V"</code>
これは（<code>\\?\</code>が付くパスを除いて）ほとんどの場合に正しく機能するが、<code>%PATH%</code>のような文字列が含まれているフォルダではうまくいかない。ちなみにpushdによりUNCパスには自動的にネットワークドライブが割り当てられる。</li></ul>
</li>
<li>Git Bash
<ul>
<li>mintty（git-bash.exe使用）
<code>"C:\Program Files\Git\git-bash.exe" -c "IFS=;cd $(echo $*|/bin/sed 's/\\\\/\\\\\\\\/'|/bin/cygpath -f -);exec bash" -- "%V</code>
<ul>
<li>Git Bashのインストーラにより設定される「Git Bash Here」メニューでは以下のようになっている。
<code>"C:\Program Files\Git\git-bash.exe" "--cd=%v."</code>
これは、特殊文字にはすべて対応しているが、（NoWorkingDirectoryをつけたとしても）<code>\\?\</code>で始まるパスではうまくいかない。最後の「.」はよくわからないがこれを付けておくと<code>--cd</code>がうまくやってくれるっぽい。</li></ul>
</li>
<li>デフォルトシェルで
<code>"C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=;cd $(echo $*|/bin/sed 's/\\\\/\\\\\\\\/'|/bin/cygpath -f -);export MSYSTEM=MINGW64;exec /bin/bash --login" -- "%V</code></li>
<li>wtで
<code>hiderun "C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=;LANG=en_US.UTF8; echo $*|/bin/sed 's/\\\\/\\\\\\\\/'|/bin/cygpath -f -|printf %%q $(/bin/sed 's/%%/=%%/g')|/bin/sed 's/;/\\\\;/g'|/bin/xargs -d '\n' -I {} -- wt \"C:\Program Files\Git\usr\bin\env.exe\" MSYSTEM=MINGW64 \"C:\Program Files\Git\usr\bin\bash.exe\" --login -i -c 'IFS=\\;cd $(echo {}|sed s/=%%/%%/g)\\;exec bash'" -- "%V</code></li></ul>
</li>
<li>Cygwin
<ul>
<li>デフォルトシェルで
<code>"C:\cygwin64\bin\sh.exe" --login -c "IFS=;cd $(echo $*|/bin/sed 's/\\\\?/\\\\\\\\?/'|/bin/cygpath -f -);exec bash" -- "%V</code>
<ul>
<li>置換の対象を<code>\\?\</code>のみとするためsedの引数に<code>?</code>が増えている</li></ul>
</li>
<li>wtで
<code>hiderun "C:\cygwin64\bin\sh.exe" -c "IFS=;echo $*|/bin/sed 's/\\\\?/\\\\\\\\?/'|/bin/cygpath -f -|printf %%q $(/bin/sed 's/%%/=%%/g')|/bin/sed 's/;/\\\\;/g'|/bin/xargs -d '\n' -I {} -- wt \"C:\cygwin64\bin\bash.exe\" --login -i -c 'IFS=\\;cd $(echo {}|sed s/=%%/%%/g)\\;exec bash'" -- "%V</code></li></ul>
</li></ul>

==== 管理者権限 ====

<ul>
<li>PowerShell
<code>powershell -Command "& {Start-Process -Verb Runas -Filepath wt -Argumentlist powershell, -noexit, -command, Set-Location, -LiteralPath, ('\"'''+($args[1].Trim('\"') -replace '''', '''''' -replace ';', '\;' -replace '%%', '==%%')+'''.Replace(''==%%'',''%%'')\"')}" --%% "\"%V\""</code>
環境変数の置換を抑止する必要がある。デフォルトシェルで起動するならこれは不要（で、wtでないので<code>;</code>のエスケープも不要）で、以下のようになる。
<code>powershell -Command "& {Start-Process -Verb Runas -Filepath powershell -Argumentlist '-noexit', '-command', Set-Location, '-LiteralPath', ('\"'''+($args[1].Trim('\"') -replace '''', '''''' )+'''\"')}" --%% "\"%V\""</code>
<ul>
<li>MyInvocationを使う例
<code>powershell -Command "& {$spl = $MyInvocation.Line -split'\"'; Start-Process -Verb Runas -Filepath powershell -Argumentlist '-noexit', '-command', Set-Location, '-LiteralPath', ('\"'''+($spl[$spl.Length-2] -replace '''', '''''' )+'''\"')}" --%% "\"%V\""</code></li>
<li>vbsの例
次の節で解説する「（自分が起動された）カレントディレクトリでの起動」にも対応している（引数がない場合）。
<syntaxhighlight lang="vb.net">Dim objShell
Dim curDir

Set ws = CreateObject("Wscript.Shell")
Dim dir
If WScript.Arguments.Count = 0 Then
dir = ws.CurrentDirectory
Else
dir = Wscript.Arguments(0)
End If
dir = Replace(dir,"%","==%")
ws.run "powershell -Command ""& {Start-Process -Verb Runas -Filepath wt -Argumentlist powershell, -noexit, -command, Set-Location, -LiteralPath, ('\""'''+($args[1].Trim('\""') -replace '''', '''''' -replace ';', '\;' )+'''.Replace(''==%'',''%'')\""')}"" --% ""\"""&dir&"\""""", vbHide

Set objShell = Nothing</syntaxhighlight></li></ul>
</li>
<li>cmd
<code>powershell -Command "& {$bak=$env:MY_PERCENT;$mypath=$args[1].Trim('\"'); $env:MY_PERCENT = '%%';if ($mypath.Length -gt 258) { $mypath = cmd /c \"for %%A in (`\"$($mypath.Replace('%%', '%%MY_PERCENT%%'))`\") do @echo %%~sA\" };$env:MY_PERCENT = $bak;Start-Process -Verb Runas -Filepath wt -Argumentlist '-d', ('\"'+($mypath -replace '\\$','\\\\' -replace ';', '\;')+'\"'), cmd}" --%% "\"%V\""</code>
この場合も<code>C:\</code>のための対処（<code>-replace '\\$','\\\\'</code>）が必要である。デフォルトシェルなら、startatdir.vbsを使う。
<code>powershell -Command "& {$bak=$env:MY_PERCENT;$mypath=$args[1].Trim('\"'); $env:MY_PERCENT = '%%';if ($mypath.Length -gt 258) { $mypath = cmd /c \"for %%A in (`\"$($mypath.Replace('%%', '%%MY_PERCENT%%'))`\") do @echo %%~sA\" };$env:MY_PERCENT = $bak;Start-Process -Verb Runas -Filepath wscript -Argumentlist '//Nologo', 'C:\path\to\startatdir.vbs', 'cmd', ('\"'+$mypath+'\"')}" --%% "\"%V\""</code></li>
<li>Git Bash
理論上はワンライナーでも書けるが、エスケープが面倒すぎるのでファイルに書いたほうがよいだろう。まずレジストリの中身は以下のようにする。
<code>"C:\Program Files\Git\usr\bin\sh.exe" "C:\path\to\gb-wt-admin.sh" "%V"</code>
で、<code>gb-wt-admin.sh</code>の中身は以下。
<syntaxhighlight lang="bash">#!/bin/sh
IFS=
LANG=en_US.UTF-8
echo $*|/bin/sed 's/\\/\\\\/'|/bin/cygpath -f -|printf %q $(/bin/cat) |/bin/sed "s/'/''/g;s/%/==%/g;s/;/\\\\;/g"|/bin/xargs -d '\n' -I {} powershell -Command Start-Process -Filepath wt -ArgumentList "'"'"C:\Program Files\Git\usr\bin\env.exe"'"'" , '"MSYSTEM=MINGW64"' , "'"'"C:\Program Files\Git\usr\bin\sh.exe"'"'" , "'--login'", "'-c'", "'"'"IFS=\;cd $(echo {}| /bin/sed s/==%/%/g) \; exec bash"'"'"</syntaxhighlight>
Cygwinも同様である。</li></ul>


==== VS Codeのメニュー（おまけ） ====

「Code で開く」メニューのcommand値は以下のように設定されている。

<code>"C:\Program Files\Microsoft VS Code\Code.exe" "%V"</code>

これは特殊文字などに関しても問題なく動作するうえ、実はそのまま<code>\\?\</code>が付いたパスにも適用可能である。従って、<code>VSCode</code>キーに<code>NoWorkingDirectory</code>値を設定する（設定の書き換えまたはHKCUによるオーバーライド）だけで、長大フォルダでもVS Codeが使えるようになる。ターミナルの起動には失敗してしまうがファイル・フォルダの作成・編集などの基本操作がGUIでできるので意外と便利（もちろん、他のBetter Explorer的なツールを使う手もあるだろう）。


== 3. エクスプローラーのアドレスバーから ==

このときは、末尾が空白のパスや<code>\\?\</code>が必要な長大パスやちょうど259文字のフォルダはそもそも対応していないので考えなくてよい。しかし通常のネットワークファイル向けのUNCパス（<code>\\192.168.1.1\disk</code>など）に対応する必要はあるので、cmdをベースにすることはできない（cmdの中に入った時点でカレントディレクトリが変わってしまう）。また<code>``</code>が含まれるパスをカレントディレクトリにできないことから、powershell.exeもベースとしては使えない。

なので、パイプを使って先ほどの<code>openterm</code>にむけて流し込もうと思ったら選択肢はpwsh.exeかpiperunかCygwin系だけである。それぞれの書き方は以下のようになる。

<ul>
<li>pwsh
<code>pwsh -Command $pwd.Path.Replace('Microsoft.PowerShell.Core\FileSystem::\\', '\\') | openterm</code></li>
<li>piperun
<code>piperun pwsh -Command $pwd.Path.Replace('Microsoft.PowerShell.Core\FileSystem::\\', '\\') | openterm</code>
上とほぼ変わっていないが、pwshはディレクトリの取得だけで使っているので<code>openterm</code>のところで環境変数が汚染されるのを防げる。</li>
<li>Cygwin/Git Bash
<code>"C:\Program Files\Git\usr\bin\sh.exe" -c "cmd //c \"chcp 65001 > nul\"| pwd | /bin/cygpath -w -f - | openterm"</code>
<ul>
<li>一つ問題があり、hiderunを使う（コンソールを非表示にする）とchcpが効かないようで、<code>openterm</code>でPowerShellの<code>$input</code>を使っているとUnicode文字が化けてしまう。</li>
<li>先ほどの<code>openterm</code>部分で先頭にcygpathが入っているものを使うときは、そちらのcygpathとこちらでのcygpath -wは打ち消し合って無駄なので消してよい。</li></ul>
</li></ul>

このほかにvbs(wscript)もカレントディレクトリの取得のところは問題なくやってくれるので、それをさっきのWscript.Arguments(0)のかわりに使えばよい。

最初に表示されるコンソールを非表示にしたければ、<code>hiderun</code>を付けてrunother経由で実行するのが手軽だが、前述の通りvbsも拡張子無しで呼び出せるように設定できるので、そうした上でvbHideで隠してもよい。


=== 管理者権限なし ===


==== cmd ====

これは普通にcmdと打てばよい。

（デフォルトシェルがconhostだとして）wtで開きたいときは、;をエスケープして-dで渡す。以下の通りbatファイルを作ってpathを通す。

<code>chcp 65001 & cd | powershell -Command wt -d $input.Replace(';','\;') cmd</code>

wtではなくconhostの場合はconhost cmdだけでよい。batにするなら<code>start "" conhost cmd</code>でよい。

コンソール非表示ならcmd /cをつけてhiderunする。runotherで、txtの中身は以下の通り。

<code>hiderun cmd /c chcp 65001 & cd | powershell -Command wt -d $input.Replace(';','\;') cmd</code>


==== powershell, pwsh ====

pwshはそのままpwshと打てばよい。powershell及びwtやconhostを明示的に指定する場合について以下で述べる。

たとえばwtでpwshなら、runotherを使って、txtの内容は以下。

<code>hiderun pwsh -Command wt -d $pwd.Path.Replace('Microsoft.PowerShell.Core\FileSystem::\\', '\\').Replace(';', '\;') pwsh</code>

powershellの場合は<code>``</code>に対応するため起動後に移動する。runotherでpiperunを使って、txtは以下。最終的に起動する方のpowershellで<code>==%</code>を<code>%</code>に戻している。

<code>hiderun piperunex cmd /c chcp 65001 | printcd | powershell -Command wt powershell -noexit -command Set-Location -LiteralPath ('"'''+($input -replace ';', '\;' -replace '''', '''''' -replace '%', '==%')+'''.Replace(''==%'',''%'')"')</code>

pwshが使えるならprintcdのかわりに<code>pwsh -Command $pwd.Path.Replace('Microsoft.PowerShell.Core\FileSystem::\\', '\\')</code>でもよい。

以下はpiperunを使わずshでやる例。前述の通りパイプからPowerShell側で<code>$input</code>を使って受け取ると文字化けするので引数として渡す。

<code>hiderun "C:\Program Files\Git\usr\bin\sh.exe" -c "WD=$(pwd | /bin/cygpath -w -f - | /bin/sed \"s/;/\\\\\\\\;/g; s/'/''/g; s/%/==%/g\"); wt powershell -noexit -command Set-Location -LiteralPath $\"'$WD'.Replace('==%','%')\"$"</code>


==== Git Bash/Cygwin ====

Git Bashは<code>--login</code>をつけてもカレントディレクトリを維持するので単純である。以下をrunotherのtxtに書く。

<code>"C:\Program Files\Git\usr\bin\env.exe" MSYSTEM=MINGW64 /bin/bash --login</code>

Cygwinは起動後にcdする。そのかわり<code>export MSYSTEM=MINGW64</code>が不要。

<code>"C:\cygwin64\bin\sh.exe" -c "IFS=;/bin/bash --login -i -c 'cd '$(/bin/printf %q `pwd`)'; exec bash'"</code>

printfで一旦エスケープしたものをcdの後につなげてそのまま渡している。

<ul>
<li>wtで
<ul>
<li>Git Bash
<code>wt "C:\Program Files\Git\usr\bin\env.exe" MSYSTEM=MINGW64 "C:\Program Files\Git\usr\bin\bash.exe" --login"</code>
<ul>
<li>あれ、wtなのにカレントディレクトリ維持されてる…？wt cmdではダメなのだが…</li></ul>
</li>
<li>Cygwin
<code>hiderun "C:\cygwin64\bin\sh.exe" -c "IFS=;WD=$(printf %q `pwd` | /bin/sed \"s/;/\\\\\\\\;/g; s/%/==%/g\"); wt \"C:\cygwin64\bin\bash.exe\" --login -c 'IFS=\\;cd $(echo '$WD'|sed s/==%/%/g)\\; exec bash'"</code></li></ul>
</li></ul>

=== 管理者権限あり ===


==== cmd ====

runotherを使って以下の通り。

<code>hiderun cmd /c "chcp 65001 > nul & cd | powershell -Command Start-Process -Verb Runas -Filepath wt -ArgumentList '-d', ('\"'+$input.TrimEnd('\\').Replace(';','\;')+'\"'), cmd"</code>

<code>TrimEnd('\\')</code>のところは<code>C:\</code>の末尾のバックスラッシュへの対応である（<code>wt -d "C:"</code>は通らないので一見ダメそうだが、なぜかこれで動く。原因不明。）。

batならそのまま以下の通り（黒い画面が一瞬出てしまう）。

<code>chcp 65001 & cd | powershell -Command Start-Process -Verb Runas -Filepath wt -ArgumentList '-d', ('\"'+$input.TrimEnd('\\').Replace(';','\;')+'\"'), cmd</code>

別解としてパイプを使わないものも載せておこう。cmdでは特殊文字ではないので<code>'</code>を<code>''</code>に変えるのは簡単である。

<code>hiderun cmd /c powershell -Command "& {Start-Process -Filepath wt -Verb Runas -ArgumentList '-d', ('\"'+$args[0].TrimEnd('\\').Replace(';','\;')+'\"'), cmd}" -- "'%CD:'=''%'"</code>

以下もうまくいく。cmdの<code>"</code>に関する仕様により、例えばStart-Processの直前に<code>echo '\"';</code>のような<code>"</code>を奇数個含む文字列を入れると動かなくなる。argsを使うとバッククォートがうまくいかなかったのでMyInvocationを使ってみる。

<code>hiderun cmd /c powershell -Command "& {$spl=$MyInvocation.Line.Split('\"'); Start-Process -Filepath wt -Verb Runas -ArgumentList '-d', ('\"'+$spl[$spl.Length-2].TrimEnd('\\').Replace(';','\;')+'\"'), cmd}" -- "\"%CD%\""</code>


==== powershell, pwsh ====

UNC非対応でよく、かつ（<code>``</code>をカレントディレクトリとして起動できる）pwshでよければ、上記のcmdをpwshに変えればよい。powershellならSet-Locationで移動が必要。以下をrunotherのtxtに書く。

<code>hiderun cmd /c "chcp 65001 & cd | powershell -Command Start-Process -Verb Runas -Filepath wt -ArgumentList 'powershell', '-noexit', '-command', 'Set-Location', '-LiteralPath', ('\"'''+($input -replace '''', '''''' -replace '%', '==%' -replace ';', '\;' )+'''.Replace(''==%'',''%'')\"')"</code>

UNC対応なら、管理者でないときと同じで、PSReadLineのエラーを回避するためpwshを一貫して使うのがいいだろう。

<code>hiderun pwsh -Command Start-Process -Verb Runas -Filepath wt -ArgumentList '-d', ('\"'+$pwd.Path.Replace('Microsoft.PowerShell.Core\FileSystem::\\', '\\').TrimEnd('\\').Replace(';','\;')+'\"'), pwsh</code>

powershellならpiperunを使う。カレントディレクトリの取得にpwshを使っているがprintcdでもよい。

<code>hiderun piperunex cmd /c chcp 65001 | printcd | powershell -Command Start-Process -Verb Runas -FilePath wt -ArgumentList powershell, -noexit, -command, Set-Location, -LiteralPath, ('\"'''+($input -replace ';', '\;' -replace '''', '''''' -replace '%', '==%')+'''.Replace(''==%'',''%'')\"')</code>

shなら以下。

<code>hiderun "C:\Program Files\Git\usr\bin\sh.exe" -c "WD=$( pwd | /bin/cygpath -w -f - | /bin/sed \"s/;/\\\\\\\\;/g; s/'/''''/g; s/%/==%/g\"); powershell -Command Start-Process -Verb Runas -Filepath wt -Argumentlist powershell, -noexit, -command, Set-Location, -LiteralPath, $\"'\\\"''$WD''.Replace(''==%'',''%'')\\\"'\"$"</code>


==== Git Bash ====

runotherとpiperunで以下。

<code>hiderun piperunex "C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=; LANG=en_US.UTF8; pwd || printf %q $(/bin/cat)" | "C:\Program Files\Git\usr\bin\sed.exe" "s/'/''/g;s/%/==%/g;s/;/\\\\;/g" | "C:\Program Files\Git\usr\bin\xargs.exe" -d '\n' -I {} -- powershell -Command Start-Process -Verb Runas -Filepath wt -ArgumentList '"C:\Program Files\Git\usr\bin\sh.exe"','-c', "'"'"IFS=\\; export MSYSTEM=MINGW64\\;cd $(echo {}|| /bin/sed s/==%/%/g)\\; exec /bin/bash --login"'"'"</code>

* <code>MSYSTEM=MINGW64</code>をもっと手前で設定して、<code>-ArgumentList</code>で<code>--login</code>を指定して、最後を<code>exec bash</code>にしてもよい。

piperunを使わずにshで頑張ることもできるが、エスケープが多く読みづらくなる。

<code>hiderun "C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=; LANG=en_US.UTF8; pwd | printf %q $(/bin/cat) | /bin/sed \"s/'/''/g;s/%/==%/g;s/;/\\\\\\\\;/g\" | /bin/xargs -d '\n' -I {} -- powershell -Command Start-Process -Verb Runas -Filepath wt -ArgumentList '\"C:\Program Files\Git\usr\bin\sh.exe\"','-c', \"'\"'\"IFS=\\; export MSYSTEM=MINGW64\\;cd $(echo {}| /bin/sed s/==%/%/g)\\; exec /bin/bash --login\"'\"'\" "</code>

Cygwinも同様。

== 関連 ==

[https://qiita.com/octopath9/items/4b7fe797ae1155c69dd9 コマンドプロンプトから管理者権限のコマンドプロンプトに切り替える - Qiita]

[https://qiita.com/tmiki/items/0dab4fd17e9bed04ed91 【Windows】GitBashをcontext menuからAdministrator権限付きで実行する - Qiita]

[https://note.com/redpeak/n/n5ddc3673117b エクスプローラーから管理者権限でコマンドプロンプトを開く方法｜ひるあんどん]
[[Category:IT]][[Category:Windows]]{{#seo:|title={{FULLPAGENAME}} - Turgenev's Wiki}}

HTTP・SOCKS・透過プロキシ・UDP

2025-04-02T15:42:26Z

Turgenev: Notion-MW

SOCKS・透過プロキシ・UDP-over-TCPなどを中心に、ネットワークの変更に使えるプロキシ関連の各種技術を雑にまとめた。

近年はGo製のものが多い。また検閲に対抗するためか、中国系（中国語でissueが投稿されているなど）のものが多い。gost, go-proxy, hysteria, txthinking/socks5, things-go/socks5などはいずれもその2つに当てはまる。たまにロシア系もある。


== 大規模・多機能系 ==

以下のものは機能が多くて分類できないのでソフトウェアごとに紹介する。

==== gost ====

GO Simple Tunnelの略らしい。安定版のv2系（[https://github.com/ginuerzh/gost https://github.com/ginuerzh/gost], [https://v2.gost.run/ https://v2.gost.run/]）と開発中のv3系（[https://github.com/go-gost https://github.com/go-gost], [https://gost.run/ https://gost.run/]）で大きく仕様が異なる。v3は開発中と言いつつv2系のページを見るとかなりv3推しに見える。

starはバージョン2が16k、バージョン3が5kほど。

イメージとしては、TCPによるシンプルなトンネルプロトコル（これがgost）（暗号化無し）と他の大量のプロトコルの間の相互変換を実装しているような感じと思われる。

非常に多機能で、このページで紹介している多くソフトウェアの基本機能をカバーしていると言ってもいいくらい。UDP-over-TCP系は基本これ1つで十分。機能の豊富さに比して明らかにドキュメントが不足しており、エラーメッセージも親切ではない（起動時ではなく実際にパケットが来てからエラーが出るような感じ）。

<ul>
<li>connectorとしてはsocks5も用意されているが、相手がgostでない限りUDP Associateは動かない模様。具体的には
<syntaxhighlight lang="javascript">gost -L "auto://:8480?udp=true&relay=udp" -F socks5://192.168.1.13:3129</syntaxhighlight>
などとしても、 05f3 0001 0000 0000 0000みたいなよくわからんリクエストが送られてしまう。このf3のところは下記の独自拡張っぽい。
[https://github.com/go-gost/x/blob/04d1587a77964636d8e50f5cce475ee8621bece7/internal/util/socks/socks.go#L17 https://github.com/go-gost/x/blob/04d1587a77964636d8e50f5cce475ee8621bece7/internal/util/socks/socks.go#L17]</li></ul>

==== go-proxy ====

[https://github.com/snail007/goproxy https://github.com/snail007/goproxy]

これも見た感じgostと同じくらいか一部では上回るくらい多機能に見えるが、この雰囲気にしては珍しく有料版があり、無料版だと一部機能が制限されているようなので、あまり使ったことはない。


== GFW回避 ==

中国政府の検閲システムであるグレート・ファイアウォール（GFW）に対抗することを主な目的とするもの。

==== shadowsocks ====

SOCKSに暗号化を施した独自プロトコルで、いくつかの実装がある。[https://github.com/shadowsocks/shadowsocks-rust https://github.com/shadowsocks/shadowsocks-rust]などが主流とみられる。

VPN以外のGFW回避ソフトウェアだとおそらくもっともメジャー。

サーバーとクライアントに分かれていて、クライアント側では透過プロキシにも対応している。


==== Hysteria ====

通信路がHTTP/3に偽装した形で暗号化される。shadowsocksの次世代に位置付けられるソフトウェアのように見える。

SOCKS5サーバー部分にはtxthinking/socks5を使っている。


== SNI Proxy ==

HTTP・HTTPSのリバースプロキシで、host（HTTPの場合）あるいはsni（HTTPSの場合）に基づいてアクセスを振り分けるものをSNI Proxyと呼ぶことがあるらしい。NginxやHAProxyのような汎用のプロキシサーバーでも使える機能だが、これを専門とするソフトウェアもある。

* こんな使い方もある（自分の記事）→ [https://turgenev.hatenablog.com/entry/2025/03/21/020550 【Android】NextDNSをアプリごとに有効無効切り替え+Tailscale経由の自宅鯖を使ってControl D風のトラフィック転送 - turgenev’s blog]


==== dlundquist/sniproxy ====

[https://github.com/dlundquist/sniproxy https://github.com/dlundquist/sniproxy]　starは2.6kほど。2024年に更新あり。非推奨である理由（HTTP/2とかQUICでうまくいかないとか）も書いてある。

==== tcpproxy ====

[https://github.com/inetaf/tcpproxy https://github.com/inetaf/tcpproxy]　starは1.3kほど。ライブラリ用途がメインか。


==== ameshkov/sniproxy ====

[https://github.com/ameshkov/sniproxy https://github.com/ameshkov/sniproxy]　starは70ほど。上流のSOCKS5, HTTPプロキシへの転送機能がある。


==== puxxustc/sniproxy ====

[https://github.com/puxxustc/sniproxy https://github.com/puxxustc/sniproxy]　starもほぼなく更新も9年前。


== SOCKSプロキシサーバー ==

ここにあげたものは特に注記がなければUDP（ただし筆者が念頭に置いているのはAssociateのみで、Bindに関してはほぼ調べていない）に対応している。


==== Dante ====

[https://www.inet.no/dante/index.html Dante - A free SOCKS server]

企業（Inferno Nettverk A/S）によるオープンソースなSOCKS5実装で、有償サポートまであるらしい。見るからに古臭いHPで、メンテされているかどうか不安になるが、つい最近2024年末にもアップデートがあり、次期バージョンの計画についても記載されている。

Cで書かれていて、おそらく最も正確なSOCKS5実装だろう。コメントも親切で、リファレンス実装のような雰囲気がある。他の透過プロキシクライアントなどをテストする際はDanteでテストして動けば安心感がある。


==== OpenSSH ====

現実的に最もよく使われているSOCKSサーバーは間違いなくOpenSSHだろう。しかし、UDP-over-TCPの問題があるため、UDPはサポートされていない。

ssh -Dでforward方向のプロキシを建てるのが有名だが、OpenSSH 7.6からは-Rでreverse方向にも建てられるようになった。クライアント側が7.6以上であればよい。

* 参考: [https://www.openssh.com/txt/release-7.6 OpenSSH 7.6] （<code>ssh(1): add support for reverse dynamic forwarding</code>）

==== socks-with-udp-over-ssh ====

[https://github.com/ge9/socks-with-udp-over-ssh https://github.com/ge9/socks-with-udp-over-ssh]

これ自体はSOCKS5サーバーではなく、TCP接続（あるいは任意のバイトストリーム）の上にUDP付きのSOCKS5を通すために自分が実装したツール。サーバー側とクライアント側に分かれている。しかし実装した後にgostで同じことができることに気付いた。

経緯・使い方などは[https://turgenev.hatenablog.com/entry/2024/05/12/231208 root権限のないssh上にUDPを通す方法について（ポートフォワード、SOCKS5プロキシなど） - turgenev’s blog]に書いてある。

==== 3proxy ====

[https://3proxy.ru/ 3proxy tiny free proxy server for Windows, Linux, Unix: SOCKS, HTTP, FTP proxy]

[https://github.com/3proxy/3proxy https://github.com/3proxy/3proxy]

ロシア系。SOCKS・HTTP・POP3・SMTPなどいくつかのプロキシを含む。エラーメッセージなどがかなり不親切だが、結構多機能で、ちゃんと動くソフト。<code>3proxy</code>というメインの実行ファイルとあわせて、各プロキシに対応した<code>socks</code>や<code>proxy</code>といった検索性の低い名前の実行ファイルがいくつか含まれているちょっと謎の構成。

==== fast-socks5 ====

[https://github.com/dizda/fast-socks5 https://github.com/dizda/fast-socks5] Rust製では最も有名か。starは500ほど。使ったことなし


==== txthinking/socks5 ====

[https://github.com/txthinking/socks5 https://github.com/txthinking/socks5]

starは700前後。hysteriaやtrojan-goなどいくつかの大きなプロジェクトで使われており、go製のSOCKS5関連ライブラリでは一番メジャーか。

クライアントもある。

自分のfork（[https://github.com/ge9/socks5 https://github.com/ge9/socks5]）ではFull Cone NATを追加した


==== armon/go-socks5 ====

[https://github.com/armon/go-socks5 https://github.com/armon/go-socks5]

starは2kだが、最終更新2016年でUDP Associateも無し。Wireproxyで以前使われていたが使われなくなった（[https://github.com/whyvl/wireproxy/issues/15 https://github.com/whyvl/wireproxy/issues/15]）。

ここからフォークされたものが複数ある。


==== things-go/go-socks5 ====

[https://github.com/things-go/go-socks5 https://github.com/things-go/go-socks5]

armon/go-socks5からのフォーク（GitHub上ではfork扱いではない）。starは400個ほど。UDP Associateはサポートしているがバグあり（自分のPRが採用されるかどうかで揉めてる[https://github.com/things-go/go-socks5/pull/63 https://github.com/things-go/go-socks5/pull/63]）。

Wireproxyで使われている。

自分のフォーク [https://github.com/ge9/go-socks5 https://github.com/ge9/go-socks5] ではFull Cone NATを追加した


==== haxii/socks5 ====

[https://github.com/haxii/socks5 https://github.com/haxii/socks5]

armon/go-socks5からのfork。UDP Associate対応。starは50個前後。最終更新2019年。


==== wzshiming/socks5 ====

[https://github.com/wzshiming/socks5 https://github.com/wzshiming/socks5]

クライアントもある。

starは90個ほど。最終更新2024年。

とりあえずredsocksと組み合わせでUDP透過プロキシ動作確認済。

Wireproxyで使用が検討された（[https://github.com/whyvl/wireproxy/issues/15 https://github.com/whyvl/wireproxy/issues/15]）が結局使用されず。


==== haochen233/socks5 ====

[https://github.com/haochen233/socks5 https://github.com/haochen233/socks5]

クライアントもある。

UDP Associateはサポートしているが、starは49とさらに少なく、最終更新も2021年。

同じくWireproxyで使用が検討された（[https://github.com/whyvl/wireproxy/issues/15 https://github.com/whyvl/wireproxy/issues/15]）が結局使用されず。

=== tun系 ===

==== tun2proxy ====

[https://github.com/tun2proxy/tun2proxy https://github.com/tun2proxy/tun2proxy]


== 透過SOCKSプロキシクライアント ==

[https://turgenev.hatenablog.com/entry/2024/03/25/160556 透過プロキシを用いて特定アプリケーションのTCP・UDP通信をSOCKS5経由にする方法（Windows・Linux（iptables TPROXY）・Androidなど） - turgenev’s blog]で扱った内容。

バックにSOCKS(SOCKS5)プロキシを用いてTCP・UDPのレイヤで透過プロキシを行うもの。基本的には管理者権限（最低でもCAP_NET_ADMIN）が必要。

==== redsocks ====

[https://github.com/semigodking/redsocks semigodking/redsocks] （fork元の[https://github.com/darkk/redsocks darkk/redsocks]はメンテされておらず、TCPのTPROXYに非対応）

*nix対応。BSD系で動かすことができたという話は[https://turgenev.hatenablog.com/entry/2024/06/10/134017 FreeBSD/OpenBSD/NetBSDで透過プロキシのredsocksを動かしてみる - turgenev’s blog]に書いた。


==== ProxiFyre ====

[https://github.com/wiresock/proxifyre https://github.com/wiresock/proxifyre] Windows用の透過SOCKSクライアント。管理者権限必要。TCP/UDP両方対応。インストールも簡単で、よくできている。

==== hev-socks5-tproxy ====

[https://github.com/heiher/hev-socks5-tproxy https://github.com/heiher/hev-socks5-tproxy] Linux向け。redsocksより若干知名度は下がるものの、きちんとメンテされている。


==== Proxifier ====

[https://www.proxifier.com/ https://www.proxifier.com/] 見た感じ機能は十分そうだが、有料なので試していない。

== ライブラリ関数ハック系 ==

ライブラリ関数レベルでの置き換えになるため厳密性・安定性に欠ける（異常終了する場合もある）ものの、root権限がない場合に有効な手法。


=== Linux（LD_PRELOAD） ===

libc依存でないプログラム（Go製のものなど）には効かない。

==== socksify ====

後述のDanteの一部。UDP/TCP両対応。唯一のUDP対応のものである。

<syntaxhighlight lang="go">route {
from: 0.0.0.0/0 to: 0.0.0.0/0 via: 192.168.1.1 port = 1080
}</syntaxhighlight>
こんな感じの<code>/etc/socks.conf</code>を作るか、<code>SOCKS5_SERVER=192.168.1.1:1080 socksify curl http://ipv4.icanhazip.com</code> とかでもよい。

Macでも動くはずだが、筆者が唯一試したMac環境ではcurlに対してさえうまく動作しなかった（socksifyを使わないのと全く同様に動作するだけだった）（<code>DYLD_FORCE_FLAT_NAMESPACE=1</code>は指定している）。


==== proxychains-ng(proxychains) ====

ngはnew generationの略で、proxychainsの後継である。ただしコマンド名はproxychains4である。

多段プロキシを構成するためのソフトウェア。

UDP非対応（[https://github.com/rofl0r/proxychains-ng/issues/336 https://github.com/rofl0r/proxychains-ng/issues/336]）。ただしDNSに対応したproxy_dnsというオプションがあり、これを有効にするとDNS以外のUDP通信が正常に機能しなくなる副作用がある（[https://github.com/rofl0r/proxychains-ng/issues/103 https://github.com/rofl0r/proxychains-ng/issues/103]）。


==== torsocks(tsocks) ====

多分、メンテされていないtsocksがTorに取り込まれてtorsocksになったような感じ。tsocksは非常に古く、多分2010年以降には更新されていないが、知名度は高く、今でも多分そこそこ使われてそう。

torsocksはアクティブなはず。ただし、Torでない普通のSOCKS5を指定しても動かないようである（やり方が悪いかも）。

tsocksはUDPには対応していない。torsocksもそうだが、まずそもそもTor自体がUDPに対応していない。


=== Windows（DLL Hijacking） ===

どのDLLを置き換えたらいいか自明ではなさそうなので、LD_PRELOADと違って対象とするソフトウェアごとに実装が必要そう。そもそも不可能なソフトウェアもLD_PRELOADの場合より多そう。よく見かけるのはDiscordを対象にしたもので、ロシア系のものが多い。筆者は使ったことがない。

==== discord-drover ====

[https://github.com/hdrover/discord-drover https://github.com/hdrover/discord-drover]

==== discord-voice-proxy ====

[https://github.com/runetfreedom/discord-voice-proxy https://github.com/runetfreedom/discord-voice-proxy]


== HTTPプロキシ ==

Squid, Privoxyなどが有名。

Squidには透過プロキシ機能があるが、redsocksなどとは動作の細かい部分が異なる。[https://turgenev.hatenablog.com/entry/2025/03/25/171736 squidで透過プロキシ（intercept, tproxy）を動かす - turgenev’s blog]に書いた。


== SOCKS関連の話題 ==


==== NATが介在する場合などのUDP Associateの動作 ====

OpenSSHの項目でも関連することを述べたが、UDP-over-TCPの性能劣化を避けるため、UDP Associateは「サーバー側がクライアント側に対してUDP通信で使うための中継ポートを通知する」という動作を伴う。この際、ネットワーク上でクライアント側からサーバーが直接見えていればよいが、NATを介している場合、クライアントから見たときのサーバーのIPとサーバー自身から見たときのサーバーのIP（中継ポート通知に含まれるのはこれ）が異なることがあり、通信が成立しなくなってしまう（SSHのポート転送を普通に使うだけではUDP Associateが使えないのも直接にはこれが原因）。

ただし、[https://turgenev.hatenablog.com/entry/2024/03/25/160556 透過プロキシを用いて特定アプリケーションのTCP・UDP通信をSOCKS5経由にする方法（Windows・Linux（iptables TPROXY）・Androidなど） - turgenev’s blog]にも書いた通り、Proxifyreやhev-socks5-tproxyなどは中継ポート通知のIP部分を無視するため、ポート番号が変わらないNATであれば問題なく動作する（redsocksはダメ）。


==== SOCKS5によるドメイン解決 ====

SOCKS5（SOCKS4aも？）では、クライアントがCONNECTなどの要求をする際、接続先をIPアドレスではなくホスト名（ドメイン名）で指定することができる仕様になっている。これによりクライアント側ではなくSOCKS5サーバー側でドメイン解決が行われる。

Proxifyreやredsocksを普通に使う場合、TCP/UDPレイヤでのプロキシとなるので、この機能が使われることはない（[https://turgenev.hatenablog.com/entry/2024/03/25/160556 透過プロキシを用いて特定アプリケーションのTCP・UDP通信をSOCKS5経由にする方法（Windows・Linux（iptables TPROXY）・Androidなど） - turgenev’s blog]）。一方、HTTPのレイヤで動作するWebブラウザでは、この機能が使われる場合がある。2018年時点での[https://github.com/FelisCatus/SwitchyOmega/issues/1379 https://github.com/FelisCatus/SwitchyOmega/issues/1379]によれば、Chromeでは必ずSOCKS5サーバー側でドメイン解決が行われる一方、Firefoxではそうでなかったようである。現在のFirefoxでは「SOCKS v5 を使用するときは DNS もプロキシーを使用する（Proxy DNS when using SOCKS v5）」（v4についても同様のオプションがあるが、SOCKS4aではないSOCKS4でどうなるかは未検証）というオプションがあってデフォルトで有効になっているため、やはり基本的にはSOCKSサーバー側でドメイン解決が行われる。AndroidのFirefox（この設定項目がない）にProxy SwitchyOmegaを入れた場合もそのように動作した。

なお、HTTPプロキシについても、ブラウザで普通に使う分には、（HTTP/HTTPS共に）ドメイン解決は基本的にプロキシサーバー側で行われる。

* 拡張機能などではうまく動作しない場合がある模様。 [https://github.com/FelisCatus/SwitchyOmega/issues/2304 https://github.com/FelisCatus/SwitchyOmega/issues/2304]


==== ブラウザのSOCKS5プロキシのWebRTC対応 ====

基本的に現在主流のブラウザ（Firefox, Chrome）のSOCKS5プロキシ機能（拡張機能で設定する場合を含む）はUDPには対応していないため、Discordの通話などWebRTC関係の機能を使うと生IPが漏洩する（またはそれを防ごうとすると単にその機能が使えない）。これは原理的に実装が不可能なわけではなく、単に需要が少ないから実装されていないだけである。

* Chromeではどれが最新か不明（最近の物は少ない）。このへんとか？[https://issues.chromium.org/issues/41180783 Chromium]
* torのバグ報告 [https://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/151 https://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/151]
* firefoxの [https://bugzilla.mozilla.org/show_bug.cgi?id=1808692 https://bugzilla.mozilla.org/show_bug.cgi?id=1808692]
** QUIC関連 [https://bugzilla.mozilla.org/show_bug.cgi?id=1882071 https://bugzilla.mozilla.org/show_bug.cgi?id=1882071]
** 新しめの包括的なバグレポート [https://bugzilla.mozilla.org/show_bug.cgi?id=1947229 https://bugzilla.mozilla.org/show_bug.cgi?id=1947229]

従って、ブラウザのWebRTCをプロキシさせたい場合はVPNや透過プロキシなどroot/管理者権限が必要な手法を使うことになる。ただしLinux+Firefoxの場合はsocksifyが使えるのでrootが無くても可能。


==== UDP AssociateリクエストのDST.ADDRとDST.PORT ====

クライアントがサーバー側にUDP Associateリクエストをするとき、この2フィールドには通信したい宛先ではなく（←というかそもそもそれが複数ある場合もある）、クライアント側がUDP Associateに使用する予定のポートを入れる。指定しない場合（例えばNATがある場合、これを予測するのは難しくなる）は、全ビットを0に設定する必要がある。

これによってサーバー側は、UDPパケットが送られてきたタイミングでそれが事前に通知されたものと一致するかどうか確認できるというわけである。

この部分に誤ってクライアント側が通信したい宛先ポートを入れるよう実装していたSOCKS5クライアントがいくつかある。

* semigodking/redsocks…自分の[https://github.com/semigodking/redsocks/issues/210 https://github.com/semigodking/redsocks/issues/210]で修正済み。
* gost…[https://github.com/ginuerzh/gost/issues/96 https://github.com/ginuerzh/gost/issues/96]で修正済み。
* txthinking/socks5…[https://github.com/txthinking/socks5/issues/15 https://github.com/txthinking/socks5/issues/15]で修正済み。
* things-go/go-socks5…これはサーバー側。[https://github.com/things-go/go-socks5/issues/29 https://github.com/things-go/go-socks5/issues/29]の通り、クライアントが必ずアドレス・ポートを通知してくれる（ゼロ埋めしない）と仮定していたが、修正された。


== VPN(tun) ==


==== tun2proxy ====

[https://github.com/tun2proxy/tun2proxy https://github.com/tun2proxy/tun2proxy]

Rust製。starは700ほど。SOCKSとHTTPをtunにしてくれる。

==== hev-socks5-tunnel ====

[https://github.com/heiher/hev-socks5-tunnel https://github.com/heiher/hev-socks5-tunnel]

hev-socks5-tproxyの作者による。Androidアプリの[https://github.com/heiher/sockstun https://github.com/heiher/sockstun]もここから。

== プロキシプロトコル間の変換 ==

==== socks-to-http-proxy ====

[https://github.com/KaranGauswami/socks-to-http-proxy https://github.com/KaranGauswami/socks-to-http-proxy]

名前の通り、socksをhttpにしてくれる。starは250ほど。

==== privoxy ====

基本的にはHTTPプロキシソフトウェア。socksプロキシをhttpプロキシとして使えるようにする機能はあるが、より大がかり（一般ユーザーでの実行がしづらい）


== UDP・Wireguard関連 ==


==== UDPでサーバー→クライアントにデータ送信 ====

[https://github.com/prof7bit/udp-reverse-tunnel https://github.com/prof7bit/udp-reverse-tunnel]

これを使うと、サーバー側だけでポートが開けられるとしても事実上クライアント側で開けられるのと同等になるのでreverseをするのが楽になる

* [https://superuser.com/questions/1737943/how-to-create-a-reverse-udp-tunnel https://superuser.com/questions/1737943/how-to-create-a-reverse-udp-tunnel]
* どっちも開放できない場合、UDPホールパンチングで何とかするしかない

==== wgslirpy ====

[https://github.com/vi/wgslirpy https://github.com/vi/wgslirpy]

Slirp（ユーザーランドで動くPPPサーバーのようなもの）のような形で実装されたWireguardサーバー。rootなしでWireguardサーバーとして動作する。

==== wireproxy ====

[https://github.com/whyvl/wireproxy https://github.com/whyvl/wireproxy]

wgslirpyの逆のような（？）ツール。Wireguardクライアントであるが、SOCKSサーバーとして動作する。

依存ライブラリのUDP Associate対応が不完全（自分がプルリクを送っている）だが、クライアントによってはうまくUDP Associateが動く（[https://github.com/whyvl/wireproxy/issues/30 https://github.com/whyvl/wireproxy/issues/30]）。

<ul>
<li>自分でカスタマイズしてCone NATを加えたthings-go/go-socks5を使えば（<code>go.mod</code>で<code>replace github.com/things-go/go-socks5 => ../../go-socks5</code>などとする）、以下のようなコードをroutine.goのsocks5.Optionのところに追加することでCone NATにできる。
<syntaxhighlight lang="go">socks5.WithDialUDP(func(laddr, raddr *net.UDPAddr) (net.PacketConn, error) { return vt.Tnet.DialUDP(laddr, raddr) }),</syntaxhighlight></li></ul>


=== Wireguard通信の確立: 各パターンでのやり方 ===

各状況に応じて、2端末間でUDPの暗号化された通信路を確立するための方法を書いた。

* forwardは「クライアント→サーバー」、reverseは「サーバー→クライアント」という意味。「サーバー」は、「ポートが開放できる方」という意味合い。

==== どっちもrootあり ====

普通にWireguardを使う

==== サーバーのみrootあり ====

forward

サーバーはWireguard、クライアントは普通にWireproxyでいける

reverse

udp-reverse-tunnelで頑張って逆にする（あるいはホールパンチング）。

その上で、wgslirpyを使うか、Hysteriaを使うか

==== クライアントのみrootあり ====

↑さっきと逆

forward

wgslirpyを使うか、Hysteriaを使うか

reverse

udp-reverse-tunnelで頑張ったうえで普通にWireguardとWireproxy

==== どっちもrootなし ====

この場合そもそもWireguardを使うメリットはあまりないかも。というのとrootがないならポート開放も無理そう

forward

Hysteriaでいけそう。

reverse

udp-reverse-tunnelしてHysteria？かな
[[Category:IT]]{{#seo:|title={{FULLPAGENAME}} - Turgenev's Wiki}}

HTTP・SOCKS・透過プロキシ・UDP

2025-04-02T15:29:11Z

Turgenev: Notion-MW

SOCKS・透過プロキシ・UDP-over-TCPなどを中心に、ネットワークの変更に使えるプロキシ関連の各種技術を雑にまとめた。

近年はGo製のものが多い。また検閲に対抗するためか、中国系（中国語でissueが投稿されているなど）のものが多い。gost, go-proxy, hysteria, txthinking/socks5, things-go/socks5などはいずれもその2つに当てはまる。たまにロシア系もある。


== 大規模・多機能系 ==

以下のものは機能が多くて分類できないのでソフトウェアごとに紹介する。

==== gost ====

GO Simple Tunnelの略らしい。安定版のv2系（[https://github.com/ginuerzh/gost https://github.com/ginuerzh/gost], [https://v2.gost.run/ https://v2.gost.run/]）と開発中のv3系（[https://github.com/go-gost https://github.com/go-gost], [https://gost.run/ https://gost.run/]）で大きく仕様が異なる。v3は開発中と言いつつv2系のページを見るとかなりv3推しに見える。

starはバージョン2が16k、バージョン3が5kほど。

イメージとしては、TCPによるシンプルなトンネルプロトコル（これがgost）（暗号化無し）と他の大量のプロトコルの間の相互変換を実装しているような感じと思われる。

非常に多機能で、このページで紹介している多くソフトウェアの基本機能をカバーしていると言ってもいいくらい。UDP-over-TCP系は基本これ1つで十分。機能の豊富さに比して明らかにドキュメントが不足しており、エラーメッセージも親切ではない（起動時ではなく実際にパケットが来てからエラーが出るような感じ）。

<ul>
<li>connectorとしてはsocks5も用意されているが、相手がgostでない限りUDP Associateは動かない模様。具体的には
<syntaxhighlight lang="javascript">gost -L "auto://:8480?udp=true&relay=udp" -F socks5://192.168.1.13:3129</syntaxhighlight>
などとしても、 05f3 0001 0000 0000 0000みたいなよくわからんリクエストが送られてしまう。このf3のところは下記の独自拡張っぽい。
[https://github.com/go-gost/x/blob/04d1587a77964636d8e50f5cce475ee8621bece7/internal/util/socks/socks.go#L17 https://github.com/go-gost/x/blob/04d1587a77964636d8e50f5cce475ee8621bece7/internal/util/socks/socks.go#L17]</li></ul>

==== go-proxy ====

[https://github.com/snail007/goproxy https://github.com/snail007/goproxy]

これも見た感じgostと同じくらいか一部では上回るくらい多機能に見えるが、この雰囲気にしては珍しく有料版があり、無料版だと一部機能が制限されているようなので、あまり使ったことはない。


== GFW回避 ==

中国政府の検閲システムであるグレート・ファイアウォール（GFW）に対抗することを主な目的とするもの。

==== shadowsocks ====

SOCKSに暗号化を施した独自プロトコルで、いくつかの実装がある。[https://github.com/shadowsocks/shadowsocks-rust https://github.com/shadowsocks/shadowsocks-rust]などが主流とみられる。

VPN以外のGFW回避ソフトウェアだとおそらくもっともメジャー。

サーバーとクライアントに分かれていて、クライアント側では透過プロキシにも対応している。


==== Hysteria ====

通信路がHTTP/3に偽装した形で暗号化される。shadowsocksの次世代に位置付けられるソフトウェアのように見える。

SOCKS5サーバー部分にはtxthinking/socks5を使っている。


== SNI Proxy ==

HTTP・HTTPSのリバースプロキシで、host（HTTPの場合）あるいはsni（HTTPSの場合）に基づいてアクセスを振り分けるものをSNI Proxyと呼ぶことがあるらしい。NginxやHAProxyのような汎用のプロキシサーバーでも使える機能だが、これを専門とするソフトウェアもある。

* こんな使い方もある（自分の記事）→ [https://turgenev.hatenablog.com/entry/2025/03/21/020550 【Android】NextDNSをアプリごとに有効無効切り替え+Tailscale経由の自宅鯖を使ってControl D風のトラフィック転送 - turgenev’s blog]


==== dlundquist/sniproxy ====

[https://github.com/dlundquist/sniproxy https://github.com/dlundquist/sniproxy]　starは2.6kほど。2024年に更新あり。非推奨である理由（HTTP/2とかQUICでうまくいかないとか）も書いてある。

==== tcpproxy ====

[https://github.com/inetaf/tcpproxy https://github.com/inetaf/tcpproxy]　starは1.3kほど。ライブラリ用途がメインか。


==== ameshkov/sniproxy ====

[https://github.com/ameshkov/sniproxy https://github.com/ameshkov/sniproxy]　starは70ほど。上流のSOCKS5, HTTPプロキシへの転送機能がある。


==== puxxustc/sniproxy ====

[https://github.com/puxxustc/sniproxy https://github.com/puxxustc/sniproxy]　starもほぼなく更新も9年前。


== SOCKSプロキシサーバー ==

ここにあげたものは特に注記がなければUDPに対応している。


==== Dante ====

[https://www.inet.no/dante/index.html Dante - A free SOCKS server]

企業（Inferno Nettverk A/S）によるオープンソースなSOCKS5実装で、有償サポートまであるらしい。見るからに古臭いHPで、メンテされているかどうか不安になるが、つい最近2024年末にもアップデートがあり、次期バージョンの計画についても記載されている。

Cで書かれていて、おそらく最も正確なSOCKS5実装だろう。コメントも親切で、リファレンス実装のような雰囲気がある。他の透過プロキシクライアントなどをテストする際はDanteでテストして動けば安心感がある。


==== OpenSSH ====

現実的に最もよく使われているSOCKSサーバーは間違いなくOpenSSHだろう。しかし、UDP-over-TCPの問題があるため、UDPはサポートされていない。

ssh -Dでforward方向のプロキシを建てるのが有名だが、OpenSSH 7.6からは-Rでreverse方向にも建てられるようになった。クライアント側が7.6以上であればよい。

* 参考: [https://www.openssh.com/txt/release-7.6 OpenSSH 7.6] （<code>ssh(1): add support for reverse dynamic forwarding</code>）

==== socks-with-udp-over-ssh ====

[https://github.com/ge9/socks-with-udp-over-ssh https://github.com/ge9/socks-with-udp-over-ssh]

これ自体はSOCKS5サーバーではなく、TCP接続（あるいは任意のバイトストリーム）の上にUDP付きのSOCKS5を通すために自分が実装したツール。サーバー側とクライアント側に分かれている。しかし実装した後にgostで同じことができることに気付いた。

経緯・使い方などは[https://turgenev.hatenablog.com/entry/2024/05/12/231208 root権限のないssh上にUDPを通す方法について（ポートフォワード、SOCKS5プロキシなど） - turgenev’s blog]に書いてある。

==== 3proxy ====

[https://3proxy.ru/ 3proxy tiny free proxy server for Windows, Linux, Unix: SOCKS, HTTP, FTP proxy]

[https://github.com/3proxy/3proxy https://github.com/3proxy/3proxy]

ロシア系。SOCKS・HTTP・POP3・SMTPなどいくつかのプロキシを含む。エラーメッセージなどがかなり不親切だが、結構多機能で、ちゃんと動くソフト。<code>3proxy</code>というメインの実行ファイルとあわせて、各プロキシに対応した<code>socks</code>や<code>proxy</code>といった検索性の低い名前の実行ファイルがいくつか含まれているちょっと謎の構成。

==== fast-socks5 ====

[https://github.com/dizda/fast-socks5 https://github.com/dizda/fast-socks5] Rust製では最も有名か。starは500ほど。使ったことなし


==== txthinking/socks5 ====

[https://github.com/txthinking/socks5 https://github.com/txthinking/socks5]

starは700前後。hysteriaやtrojan-goなどいくつかの大きなプロジェクトで使われており、go製のSOCKS5関連ライブラリでは一番メジャーか。

クライアントもある。

自分のfork（[https://github.com/ge9/socks5 https://github.com/ge9/socks5]）ではFull Cone NATを追加した


==== armon/go-socks5 ====

[https://github.com/armon/go-socks5 https://github.com/armon/go-socks5]

starは2kだが、最終更新2016年でUDP Associateも無し。Wireproxyで以前使われていたが使われなくなった（[https://github.com/whyvl/wireproxy/issues/15 https://github.com/whyvl/wireproxy/issues/15]）。

ここからフォークされたものが複数ある。


==== things-go/go-socks5 ====

[https://github.com/things-go/go-socks5 https://github.com/things-go/go-socks5]

armon/go-socks5からのフォーク（GitHub上ではfork扱いではない）。starは400個ほど。UDP Associateはサポートしているがバグあり（自分のPRが採用されるかどうかで揉めてる[https://github.com/things-go/go-socks5/pull/63 https://github.com/things-go/go-socks5/pull/63]）。

Wireproxyで使われている。

自分のフォーク [https://github.com/ge9/go-socks5 https://github.com/ge9/go-socks5] ではFull Cone NATを追加した


==== haxii/socks5 ====

[https://github.com/haxii/socks5 https://github.com/haxii/socks5]

armon/go-socks5からのfork。UDP Associate対応。starは50個前後。最終更新2019年。


==== wzshiming/socks5 ====

[https://github.com/wzshiming/socks5 https://github.com/wzshiming/socks5]

クライアントもある。

starは90個ほど。最終更新2024年。

とりあえずredsocksと組み合わせでUDP透過プロキシ動作確認済。

Wireproxyで使用が検討された（[https://github.com/whyvl/wireproxy/issues/15 https://github.com/whyvl/wireproxy/issues/15]）が結局使用されず。


==== haochen233/socks5 ====

[https://github.com/haochen233/socks5 https://github.com/haochen233/socks5]

クライアントもある。

UDP Associateはサポートしているが、starは49とさらに少なく、最終更新も2021年。

同じくWireproxyで使用が検討された（[https://github.com/whyvl/wireproxy/issues/15 https://github.com/whyvl/wireproxy/issues/15]）が結局使用されず。

=== tun系 ===

==== tun2proxy ====

[https://github.com/tun2proxy/tun2proxy https://github.com/tun2proxy/tun2proxy]


== 透過SOCKSプロキシクライアント ==

[https://turgenev.hatenablog.com/entry/2024/03/25/160556 透過プロキシを用いて特定アプリケーションのTCP・UDP通信をSOCKS5経由にする方法（Windows・Linux（iptables TPROXY）・Androidなど） - turgenev’s blog]で扱った内容。

バックにSOCKS(SOCKS5)プロキシを用いてTCP・UDPのレイヤで透過プロキシを行うもの。基本的には管理者権限（最低でもCAP_NET_ADMIN）が必要。

==== redsocks ====

[https://github.com/semigodking/redsocks semigodking/redsocks] （fork元の[https://github.com/darkk/redsocks darkk/redsocks]はメンテされておらず、TCPのTPROXYに非対応）

*nix対応。BSD系で動かすことができたという話は[https://turgenev.hatenablog.com/entry/2024/06/10/134017 FreeBSD/OpenBSD/NetBSDで透過プロキシのredsocksを動かしてみる - turgenev’s blog]に書いた。


==== ProxiFyre ====

[https://github.com/wiresock/proxifyre https://github.com/wiresock/proxifyre] Windows用の透過SOCKSクライアント。管理者権限必要。TCP/UDP両方対応。インストールも簡単で、よくできている。

==== hev-socks5-tproxy ====

[https://github.com/heiher/hev-socks5-tproxy https://github.com/heiher/hev-socks5-tproxy] Linux向け。redsocksより若干知名度は下がるものの、きちんとメンテされている。


==== Proxifier ====

[https://www.proxifier.com/ https://www.proxifier.com/] 見た感じ機能は十分そうだが、有料なので試していない。

== ライブラリ関数ハック系 ==

ライブラリ関数レベルでの置き換えになるため厳密性・安定性に欠ける（異常終了する場合もある）ものの、root権限がない場合に有効な手法。


=== Linux（LD_PRELOAD） ===

libc依存でないプログラム（Go製のものなど）には効かない。

==== socksify ====

後述のDanteの一部。UDP/TCP両対応。唯一のUDP対応のものである。

<syntaxhighlight lang="go">route {
from: 0.0.0.0/0 to: 0.0.0.0/0 via: 192.168.1.1 port = 1080
}</syntaxhighlight>
こんな感じの<code>/etc/socks.conf</code>を作るか、<code>SOCKS5_SERVER=192.168.1.1:1080 socksify curl http://ipv4.icanhazip.com</code> とかでもよい。

Macでも動くはずだが、筆者が唯一試したMac環境ではcurlに対してさえうまく動作しなかった（socksifyを使わないのと全く同様に動作するだけだった）（<code>DYLD_FORCE_FLAT_NAMESPACE=1</code>は指定している）。


==== proxychains-ng(proxychains) ====

ngはnew generationの略で、proxychainsの後継である。ただしコマンド名はproxychains4である。

多段プロキシを構成するためのソフトウェア。

UDP非対応（[https://github.com/rofl0r/proxychains-ng/issues/336 https://github.com/rofl0r/proxychains-ng/issues/336]）。ただしDNSに対応したproxy_dnsというオプションがあり、これを有効にするとDNS以外のUDP通信が正常に機能しなくなる副作用がある（[https://github.com/rofl0r/proxychains-ng/issues/103 https://github.com/rofl0r/proxychains-ng/issues/103]）。


==== torsocks(tsocks) ====

多分、メンテされていないtsocksがTorに取り込まれてtorsocksになったような感じ。tsocksは非常に古く、多分2010年以降には更新されていないが、知名度は高く、今でも多分そこそこ使われてそう。

torsocksはアクティブなはず。ただし、Torでない普通のSOCKS5を指定しても動かないようである（やり方が悪いかも）。

tsocksはUDPには対応していない。torsocksもそうだが、まずそもそもTor自体がUDPに対応していない。


=== Windows（DLL Hijacking） ===

どのDLLを置き換えたらいいか自明ではなさそうなので、LD_PRELOADと違って対象とするソフトウェアごとに実装が必要そう。そもそも不可能なソフトウェアもLD_PRELOADの場合より多そう。よく見かけるのはDiscordを対象にしたもので、ロシア系のものが多い。筆者は使ったことがない。

==== discord-drover ====

[https://github.com/hdrover/discord-drover https://github.com/hdrover/discord-drover]

==== discord-voice-proxy ====

[https://github.com/runetfreedom/discord-voice-proxy https://github.com/runetfreedom/discord-voice-proxy]


== HTTPプロキシ ==

Squid, Privoxyなどが有名。

Squidには透過プロキシ機能があるが、redsocksなどとは動作の細かい部分が異なる。[https://turgenev.hatenablog.com/entry/2025/03/25/171736 squidで透過プロキシ（intercept, tproxy）を動かす - turgenev’s blog]に書いた。


== SOCKS関連の話題 ==


==== SOCKS5によるドメイン解決 ====

SOCKS5（SOCKS4aも？）では、クライアントがCONNECTなどの要求をする際、接続先をIPアドレスではなくホスト名（ドメイン名）で指定することができる仕様になっている。これによりクライアント側ではなくSOCKS5サーバー側でドメイン解決が行われる。

Proxifyreやredsocksを普通に使う場合、TCP/UDPレイヤでのプロキシとなるので、この機能が使われることはない（[https://turgenev.hatenablog.com/entry/2025/03/25/171736 squidで透過プロキシ（intercept, tproxy）を動かす - turgenev’s blog]）。一方、HTTPのレイヤで動作するWebブラウザでは、この機能が使われる場合がある。2018年時点での[https://github.com/FelisCatus/SwitchyOmega/issues/1379 https://github.com/FelisCatus/SwitchyOmega/issues/1379]によれば、Chromeでは必ずSOCKS5サーバー側でドメイン解決が行われる一方、Firefoxではそうでなかったようである。現在のFirefoxでは「SOCKS v5 を使用するときは DNS もプロキシーを使用する（Proxy DNS when using SOCKS v5）」（v4についても同様のオプションがあるが、SOCKS4aではないSOCKS4でどうなるかは未検証）というオプションがあってデフォルトで有効になっているため、やはり基本的にはSOCKSサーバー側でドメイン解決が行われる。AndroidのFirefox（この設定項目がない）にProxy SwitchyOmegaを入れた場合もそのように動作した。

なお、HTTPプロキシについても、ブラウザで普通に使う分には、（HTTP/HTTPS共に）ドメイン解決は基本的にプロキシサーバー側で行われる。

* 拡張機能などではうまく動作しない場合がある模様。 [https://github.com/FelisCatus/SwitchyOmega/issues/2304 https://github.com/FelisCatus/SwitchyOmega/issues/2304]


==== ブラウザのSOCKS5プロキシのWebRTC対応 ====

基本的に現在主流のブラウザ（Firefox, Chrome）のSOCKS5プロキシ機能（拡張機能で設定する場合を含む）はUDPには対応していないため、Discordの通話などWebRTC関係の機能を使うと生IPが漏洩する（またはそれを防ごうとすると単にその機能が使えない）。これは原理的に実装が不可能なわけではなく、単に需要が少ないから実装されていないだけである。

* Chromeではどれが最新か不明（最近の物は少ない）。このへんとか？[https://issues.chromium.org/issues/41180783 Chromium]
* torのバグ報告 [https://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/151 https://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/151]
* firefoxの [https://bugzilla.mozilla.org/show_bug.cgi?id=1808692 https://bugzilla.mozilla.org/show_bug.cgi?id=1808692]
** QUIC関連 [https://bugzilla.mozilla.org/show_bug.cgi?id=1882071 https://bugzilla.mozilla.org/show_bug.cgi?id=1882071]
** 新しめの包括的なバグレポート [https://bugzilla.mozilla.org/show_bug.cgi?id=1947229 https://bugzilla.mozilla.org/show_bug.cgi?id=1947229]

従って、ブラウザのWebRTCをプロキシさせたい場合はVPNや透過プロキシなどroot/管理者権限が必要な手法を使うことになる。ただしLinux+Firefoxの場合はsocksifyが使えるのでrootが無くても可能。


==== UDP AssociateリクエストのDST.ADDRとDST.PORT ====

クライアントがサーバー側にUDP Associateリクエストをするとき、この2フィールドには通信したい宛先ではなく（←というかそもそもそれが複数ある場合もある）、クライアント側がUDP Associateに使用する予定のポートを入れる。指定しない場合（例えばNATがある場合、これを予測するのは難しくなる）は、全ビットを0に設定する必要がある。

これによってサーバー側は、UDPパケットが送られてきたタイミングでそれが事前に通知されたものと一致するかどうか確認できるというわけである。

この部分に誤ってクライアント側が通信したい宛先ポートを入れるよう実装していたSOCKS5クライアントがいくつかある。

* semigodking/redsocks…自分の[https://github.com/semigodking/redsocks/issues/210 https://github.com/semigodking/redsocks/issues/210]で修正済み。
* gost…[https://github.com/ginuerzh/gost/issues/96 https://github.com/ginuerzh/gost/issues/96]で修正済み。
* txthinking/socks5…[https://github.com/txthinking/socks5/issues/15 https://github.com/txthinking/socks5/issues/15]で修正済み。
* things-go/go-socks5…これはサーバー側。[https://github.com/things-go/go-socks5/issues/29 https://github.com/things-go/go-socks5/issues/29]の通り、クライアントが必ずアドレス・ポートを通知してくれる（ゼロ埋めしない）と仮定していたが、修正された。


== VPN(tun) ==


==== tun2proxy ====

[https://github.com/tun2proxy/tun2proxy https://github.com/tun2proxy/tun2proxy]

Rust製。starは700ほど。SOCKSとHTTPをtunにしてくれる。

==== hev-socks5-tunnel ====

[https://github.com/heiher/hev-socks5-tunnel https://github.com/heiher/hev-socks5-tunnel]

hev-socks5-tproxyの作者による。Androidアプリの[https://github.com/heiher/sockstun https://github.com/heiher/sockstun]もここから。

== プロキシプロトコル間の変換 ==

==== socks-to-http-proxy ====

[https://github.com/KaranGauswami/socks-to-http-proxy https://github.com/KaranGauswami/socks-to-http-proxy]

名前の通り、socksをhttpにしてくれる。starは250ほど。

==== privoxy ====

基本的にはHTTPプロキシソフトウェア。socksプロキシをhttpプロキシとして使えるようにする機能はあるが、より大がかり（一般ユーザーでの実行がしづらい）


== UDP・Wireguard関連 ==


==== UDPでサーバー→クライアントにデータ送信 ====

[https://github.com/prof7bit/udp-reverse-tunnel https://github.com/prof7bit/udp-reverse-tunnel]

これを使うと、サーバー側だけでポートが開けられるとしても事実上クライアント側で開けられるのと同等になるのでreverseをするのが楽になる

* [https://superuser.com/questions/1737943/how-to-create-a-reverse-udp-tunnel https://superuser.com/questions/1737943/how-to-create-a-reverse-udp-tunnel]
* どっちも開放できない場合、UDPホールパンチングで何とかするしかない

==== wgslirpy ====

[https://github.com/vi/wgslirpy https://github.com/vi/wgslirpy]

Slirp（ユーザーランドで動くPPPサーバーのようなもの）のような形で実装されたWireguardサーバー。rootなしでWireguardサーバーとして動作する。

==== wireproxy ====

[https://github.com/whyvl/wireproxy https://github.com/whyvl/wireproxy]

wgslirpyの逆のような（？）ツール。Wireguardクライアントであるが、SOCKSサーバーとして動作する。

依存ライブラリのUDP Associate対応が不完全（自分がプルリクを送っている）だが、クライアントによってはうまくUDP Associateが動く（[https://github.com/whyvl/wireproxy/issues/30 https://github.com/whyvl/wireproxy/issues/30]）。

<ul>
<li>自分でカスタマイズしてCone NATを加えたthings-go/go-socks5を使えば（<code>go.mod</code>で<code>replace github.com/things-go/go-socks5 => ../../go-socks5</code>などとする）、以下のようなコードをroutine.goのsocks5.Optionのところに追加することでCone NATにできる。
<syntaxhighlight lang="go">socks5.WithDialUDP(func(laddr, raddr *net.UDPAddr) (net.PacketConn, error) { return vt.Tnet.DialUDP(laddr, raddr) }),</syntaxhighlight></li></ul>


=== Wireguard通信の確立: 各パターンでのやり方 ===

各状況に応じて、2端末間でUDPの暗号化された通信路を確立するための方法を書いた。

* forwardは「クライアント→サーバー」、reverseは「サーバー→クライアント」という意味。「サーバー」は、「ポートが開放できる方」という意味合い。

==== どっちもrootあり ====

普通にWireguardを使う

==== サーバーのみrootあり ====

forward

サーバーはWireguard、クライアントは普通にWireproxyでいける

reverse

udp-reverse-tunnelで頑張って逆にする（あるいはホールパンチング）。

その上で、wgslirpyを使うか、Hysteriaを使うか

==== クライアントのみrootあり ====

↑さっきと逆

forward

wgslirpyを使うか、Hysteriaを使うか

reverse

udp-reverse-tunnelで頑張ったうえで普通にWireguardとWireproxy

==== どっちもrootなし ====

この場合そもそもWireguardを使うメリットはあまりないかも。というのとrootがないならポート開放も無理そう

forward

Hysteriaでいけそう。

reverse

udp-reverse-tunnelしてHysteria？かな
[[Category:IT]]{{#seo:|title={{FULLPAGENAME}} - Turgenev's Wiki}}

Zotero

2025-04-02T09:57:15Z

Turgenev: Notion-MW

文献管理ソフト。Firefox界隈由来のOSSで、割と自由に何でも設定できるので、そういうのが好きな人にはおすすめ。

== 初期設定 ==

Zoteroが提供するストレージは300MBとかしかないので外部のクラウドストレージで論文ファイルを管理するのがおすすめ。これに関しては [https://note.com/sdeso/n/n013952313c1b 【令和最新版】文献管理ソフト Zoteroのすゝめ｜SD｜note] が大変詳しく、これでほぼ十分であるが、いくつか追加しておく。

* Zotero自体がもともとFirefoxのアドオンに由来している関係で、Zoteroの拡張機能の拡張子.xpiはFirefoxのアドオンのものと同一であるため、FirefoxからZoteroの拡張機能をダウンロードしようとしてクリックすると（アドオンと混同されて）「ファイルが壊れています」などと出ることがある。なので右クリックから保存を選ぶ。
* ファイルの自動命名は日本人だと苗字がLast Nameと判断されてしまうなど微妙であったが、うまく直せなさそうなのでデフォルト設定のままでよさそう。
* コレクションごとにフォルダ分けしたい場合は、”Use subfolder defined by”を\%c(linuxでもこれで大丈夫だが/%cでもよい)にする（この場合は、複数のコレクションに属するアイテムが発生しないよう気を付ける）。参考:[https://dr-kayai.hatenablog.com/entry/2020/02/09/234427 Zoteroの使い方（我流、逐次更新） - Bag of ML Words]など

=== ブラウザ拡張の使い方など ===

ブラウザ拡張はZotero起動時のみ使える。Zoteroのウインドウで論文を入れたい対象のコレクションを開いておいてからブラウザで拡張機能アイコンをクリックするとそこに入れてくれる。普通に左クリックしたときにEmbedded Metadataを使用しろみたいなエラーがでることがあるので、そういうときは右クリックしてそれっぽいのを選ぶ。

ブラウザ拡張を経由せずに（ローカルにあるpdfを）入れるときは、ZoteroのウインドウにD&D（このとき元の場所にファイルを残しておく必要がなければshiftを押せば削除される（移動になる））して取り込む。日本語論文などで文献情報がうまく読まれない場合は、Manual Entryを作成するしかない場合もあるが、J-STAGEなどから取ってきたものであれば、改めてWebでその論文を探してブラウザ拡張で入れるとうまくいくこともある（pdfエディタで注釈などを記入済みならファイルだけ後で差し替えればよい）。

ブラウザ拡張を経由しない場合、ZotFileのフォルダ内の適切なコレクションには分類されないので、適宜アイテムを選択してRename Attachmentsをする必要がある。なお（最初のサイトで推奨されている通り）”サブコレクションからアイテムを表示”がonだと特定コレクションの中身（サブコレクション内部を含め）すべてに対してRename Attachmentできて便利だが、実はonでしなくてもマイ・ライブラリを押したときは全アイテムが表示されるのでそれで十分だと思う（あと、サブコレクションから表示されてるアイテムを別コレクションに移動しようとしても正しく元の場所から削除されずコピー扱いになってしまうデメリットもこれで解決できる）。なお、前述のようにクラウドストレージのフォルダをLocation of Filesに指定して同期している場合、Rename Attachmentsすることで初めてファイルが同期されることになるので、できるだけ早めにやっておくべし。

また、Zotero内のゴミ箱に移動してもファイルは自動で移動されないし、完全に削除してもファイルは消えない。今のところの筆者の運用としては、一旦DELETEという名前のコレクションに移動してからRename and moveを実行し、適宜ゴミ箱に移動して（アイテムを）削除し、DELETEフォルダの中身も定期的に削除する、とやっている。

== dateデータのフォーマットについて ==

Zotero Connectorはサイトやpdfから論文の投稿（掲載？）日時を自動で取得してくれるが、結果の文字列はブラウザ本体の言語設定によって変わる。具体的には、日本語であれば「4月 22 , 2011」、英語であれば「April 22, 2011」のようになる。なお、そもそも日付が取得できず年と月だけあるいは年だけの論文、また日付まで取れても「2011-04-22」のような書式になる論文もあり、これはどのサイトから取得するかなどによって異なるとみられるが詳細不明。

本来はこんな言語依存の単一文字列ではなく年、月、日それぞれ明示的に別のデータとして管理するのが筋だろう。実際、この仕様のせいで、Better BibTeXの使用時に問題が発生していた（後述）。


== [https://retorque.re/zotero-better-bibtex/ Better BibTeX for Zotero] ==

まずは普通に[https://retorque.re/zotero-better-bibtex/ Better BibTeX for Zotero]からxpiをインストール、再起動すると再びdrag-and-dropを有効にするため再起動しろと言われるので再起動する。Citation keyが追加されている。設定はZotfileのような別メニューではなくZoteroの設定画面に追加されている。[https://qiita.com/skrb_hs/items/73061b7a8e39f1e73e0d Zotero+BibTeXで参考文献の出力を自動化&論文の引用で出てきた順にソートする]の通り、export→fieldsのfields to omit from exportにabstract,file,doiと書く。[https://plaza.umin.ac.jp/shoei05/wp/index.php/2020/10/31/206/ Zotero で citation keys を設定する ( zotero-better-bibtex ) - shoei05]の通りCitation keysを[auth:lower][year][shorttitle1_1]に変更する。

Citation keyは「情報」タブに表示されているほか、メイン画面に表示することもできる。また検索でも使える（これは設定で無効にできる）


==== 日本語文献のCitation Keyについて ====

[https://qiita.com/shiro_takeda/items/dfb857e69aa8ed2cc977 https://qiita.com/shiro_takeda/items/dfb857e69aa8ed2cc977]


==== yearデータの不具合(6.7.60で修正済) ====

参考文献には出版年を書く必要があり、BibTeXではyearというフィールドに書かれる。このデータはZoteroの文献情報のdateのところから取得されており、「April 22, 2011」「2011-04-22」のようなdateのデータからは正しく「2011」だけを抽出してくれるが、dateが前述の「4月 22 , 2011」のような書式になっていた場合はうまくいかず、この文字列全てがBibTeX（.bib）に出力されてしまう（報告済み: [https://github.com/retorquere/zotero-better-bibtex/issues/2449 [Bug]: Japanese date format is not parsed correctly · Issue #2449 · retorquere/zotero-better-bibtex]、6.7.61あたりで修正済み）。←の通り、Better BibTeXのエクスポート時に適用されるscript（Export → postscript）のところにデータを置換するための以下のようなコードを書いておくとよい。

<syntaxhighlight lang="vb.net">if (tex.has.year) {
tex.add({name: 'year', replace: true, value: tex.has.year.value.replace(/.* /, '')})
}</syntaxhighlight>
設定箇所はこんな感じ↓

<div class="res-img">https://turgenev.cloudfree.jp/mw1/imgs/zot-settings.jpg</div>

* 今は治っているかもしれないが、デバッグ出力を有効化して再起動してからスクリプトを一度編集しないとスクリプトが読み込まれないバグがあった（[https://github.com/retorquere/zotero-better-bibtex/issues/2447 https://github.com/retorquere/zotero-better-bibtex/issues/2447]）。


== Zotero Protocolを使用した操作 ==

{{Valuable}}

ZoteroはGUIのソフトであるが、コマンドラインからも一定の操作が可能である。具体的には、<code>zotero://</code>という形式のURL（URIスキーム）を以下のように指定してZoteroを起動することができる（既に起動していた場合は、画面に変化が起こる）。

<syntaxhighlight lang="python">zotero.exe -url "zotero://url/here"</syntaxhighlight>
URLについては、明確にAPIとして仕様が定められたものではなさそうで、全体的にあまりドキュメントは充実していない。

一例として、特定のコレクション内のアイテムが選択された状態にするということができる。コメントが不親切でわかりづらいが [https://github.com/zotero/zotero/blob/master/components/zotero-protocol-handler.js zotero/zotero-protocol-handler.js at master · zotero/zotero] の<code>scopeObject</code>などと書いてあるあたりをよく読むと、<code>zotero://select/library/collections/{collection_key}/items/{item_key}</code>という形式で指定すればよいことがわかる（groupIDなどと書いてある部分もあって紛らわしいが、groupというのはcollectionとは別の概念で、複数ユーザー間での共有のライブラリのようなものを指すようである）。<code>collection_key</code>と<code>item_key</code>はどちらも<code>1A2B3C4D</code>のような英数字による8文字の識別子である。ちなみにcollectionとitemにはそれぞれIDも割り当てられているがこちらは1～3桁くらいの数字でありkeyとは別なので注意。


== 指定されたCitation keyのアイテムをZoteroで開く ==

前述の方法を応用して実装してみる。ここではCitation keyとしてBetter BibTeXのものを使うことを仮定する。

まず、Citation keyからアイテムのキーを取得する部分を作る。Citation keyはBetter BibTeXが管理しているので（ここではデフォルトの~/Zoteroに各種データがあると仮定して）~/Zotero/better-bibtex.sqliteを読めばアイテムのkeyとの対応がわかる。次にアイテムが所属するコレクション（複数ある場合は最初のもの）のkeyをzotero.sqliteから取得する。ここではIDを一旦経由する必要がある。

Zoteroの起動中はデータベースファイルがロックされているが、[https://sqlite.org/forum/info/a2e9387b8ea1c919b2ad1ecafb417cebb15c48634c55b3abd6a9acbb2fabf797 SQLite Forum: Option to open a database as read-only despite locked.]にある通り、（Windowsなら）<code>sqlite3 "file:Zotero\\zotero.sqlite?mode=ro&nolock=1"</code>のようにしてやると読み取り専用で開くことはできる（書き込まないのでこれで充分）。今回はpythonで実装するが、pythonのsqliteでもこのパラメータが同じく使える。

コード例:

<syntaxhighlight style="margin-bottom:0.2em;" lang="python">import sqlite3
import sys
import json
import subprocess
db = sqlite3.connect('file:'+sys.argv[1]+'?mode=ro&nolock=1', uri=True)
cur = db.cursor()
cur.execute('SELECT data FROM "better-bibtex" where name="better-bibtex.citekey"')
d = json.loads(cur.fetchone()[0])
mydict = {}
for item in d["data"]:
mydict[item["citekey"]] = item["itemKey"]
myKey = mydict[sys.argv[3]]

db2 = sqlite3.connect('file:'+sys.argv[2]+'?mode=ro&nolock=1', uri=True)
cur2 = db2.cursor()
cur2.execute("SELECT itemID FROM items WHERE key=?", (myKey, ))
item_id = cur2.fetchone()[0]
cur2.execute("SELECT collectionID FROM collectionItems WHERE itemID=?", (item_id, ))
# 所属する最初のコレクションIDを取得
collection_id = cur2.fetchone()[0]
# collectionIDからcollectionKeyを取得
cur2.execute("SELECT key FROM collections WHERE collectionID=?", (collection_id,))
collection_key =cur2.fetchone()[0]
print(collection_key)
subprocess.run(f'"C:\Program Files (x86)\Zotero\zotero.exe" -url "zotero://select/library/collections/{collection_key}/items/{myKey}')
db.close()
db2.close()</syntaxhighlight>
<div style='text-align: center;'>zoto.py</div>

上記コードは以下のように起動できる。

<syntaxhighlight lang="c#">python "path\to\zoto.py" "%USERPROFILE%\Zotero\better-bibtex.sqlite" "%USERPROFILE%\Zotero\zotero.sqlite" %1</syntaxhighlight>
* [[Windowsのクリップボードを用いた選択コンテンツの取得|Windowsのクリップボードを用いた選択コンテンツの取得]]と組み合わせれば、選択文字列をCitation keyとするアイテムを一発で開くことも可能。

== その他 ==

アイテムが入っているコレクションを知りたいときはアイテムが選択された状態でCtrlキーを押すとよい。
[[Category:IT]]{{#seo:|title={{FULLPAGENAME}} - Turgenev's Wiki}}

Zotero

2025-04-02T09:33:21Z

Turgenev: Notion-MW

文献管理ソフト。Firefox界隈由来のOSSで、割と自由に何でも設定できるので、そういうのが好きな人にはおすすめ。

==初期設定==

Zoteroが提供するストレージは300MBとかしかないので外部のクラウドストレージで論文ファイルを管理するのがおすすめ。これに関しては[https://note.com/sdeso/n/n013952313c1b【令和最新版】文献管理ソフトZoteroのすゝめ｜SD｜note]nmd_mw_mark_linkが大変詳しく、これでほぼ十分であるが、いくつか追加しておく。

*Zotero自体がもともとFirefoxのアドオンに由来している関係で、Zoteroの拡張機能の拡張子.xpiはFirefoxのアドオンのものと同一であるため、FirefoxからZoteroの拡張機能をダウンロードしようとしてクリックすると（アドオンと混同されて）「ファイルが壊れています」などと出ることがある。なので右クリックから保存を選ぶ。
*ファイルの自動命名は日本人だと苗字がLastNameと判断されてしまうなど微妙であったが、うまく直せなさそうなのでデフォルト設定のままでよさそう。
*コレクションごとにフォルダ分けしたい場合は、”Usesubfolderdefinedby”を\%c(linuxでもこれで大丈夫だが/%cでもよい)にする（この場合は、複数のコレクションに属するアイテムが発生しないよう気を付ける）。参考:[https://dr-kayai.hatenablog.com/entry/2020/02/09/234427Zoteroの使い方（我流、逐次更新）-BagofMLWords]nmd_mw_mark_linkなど

===ブラウザ拡張の使い方など===

ブラウザ拡張はZotero起動時のみ使える。Zoteroのウインドウで論文を入れたい対象のコレクションを開いておいてからブラウザで拡張機能アイコンをクリックするとそこに入れてくれる。普通に左クリックしたときにEmbeddedMetadataを使用しろみたいなエラーがでることがあるので、そういうときは右クリックしてそれっぽいのを選ぶ。

ブラウザ拡張を経由せずに（ローカルにあるpdfを）入れるときは、ZoteroのウインドウにD&D（このとき元の場所にファイルを残しておく必要がなければshiftを押せば削除される（移動になる））して取り込む。日本語論文などで文献情報がうまく読まれない場合は、ManualEntryを作成するしかない場合もあるが、J-STAGEなどから取ってきたものであれば、改めてWebでその論文を探してブラウザ拡張で入れるとうまくいくこともある（pdfエディタで注釈などを記入済みならファイルだけ後で差し替えればよい）。

ブラウザ拡張を経由しない場合、ZotFileのフォルダ内の適切なコレクションには分類されないので、適宜アイテムを選択してRenameAttachmentsをする必要がある。なお（最初のサイトで推奨されている通り）”サブコレクションからアイテムを表示”がonだと特定コレクションの中身（サブコレクション内部を含め）すべてに対してRenameAttachmentできて便利だが、実はonでしなくてもマイ・ライブラリを押したときは全アイテムが表示されるのでそれで十分だと思う（あと、サブコレクションから表示されてるアイテムを別コレクションに移動しようとしても正しく元の場所から削除されずコピー扱いになってしまうデメリットもこれで解決できる）。なお、前述のようにクラウドストレージのフォルダをLocationofFilesに指定して同期している場合、RenameAttachmentsすることで初めてファイルが同期されることになるので、できるだけ早めにやっておくべし。

また、Zotero内のゴミ箱に移動してもファイルは自動で移動されないし、完全に削除してもファイルは消えない。今のところの筆者の運用としては、一旦DELETEという名前のコレクションに移動してからRenameandmoveを実行し、適宜ゴミ箱に移動して（アイテムを）削除し、DELETEフォルダの中身も定期的に削除する、とやっている。

==dateデータのフォーマットについて==

ZoteroConnectorはサイトやpdfから論文の投稿（掲載？）日時を自動で取得してくれるが、結果の文字列はブラウザ本体の言語設定によって変わる。具体的には、日本語であれば「4月22,2011」、英語であれば「April22,2011」のようになる。なお、そもそも日付が取得できず年と月だけあるいは年だけの論文、また日付まで取れても「2011-04-22」のような書式になる論文もあり、これはどのサイトから取得するかなどによって異なるとみられるが詳細不明。

本来はこんな言語依存の単一文字列ではなく年、月、日それぞれ明示的に別のデータとして管理するのが筋だろう。実際、この仕様のせいで、BetterBibTeXの使用時に問題が発生していた（後述）。

<spanid="better-bibtex-for-zotero">
==[https://retorque.re/zotero-better-bibtex/BetterBibTeXforZotero]nmd_mw_mark_link==

まずは普通に[https://retorque.re/zotero-better-bibtex/BetterBibTeXforZotero]nmd_mw_mark_linkからxpiをインストール、再起動すると再びdrag-and-dropを有効にするため再起動しろと言われるので再起動する。Citationkeyが追加されている。設定はZotfileのような別メニューではなくZoteroの設定画面に追加されている。[https://qiita.com/skrb_hs/items/73061b7a8e39f1e73e0dZotero+BibTeXで参考文献の出力を自動化&論文の引用で出てきた順にソートする]nmd_mw_mark_linkの通り、export→fieldsのfieldstoomitfromexportにabstract,file,doiと書く。[https://plaza.umin.ac.jp/shoei05/wp/index.php/2020/10/31/206/Zoteroでcitationkeysを設定する(zotero-better-bibtex)-shoei05]nmd_mw_mark_linkの通りCitationkeysを[auth:lower][year][shorttitle1_1]に変更する。

Citationkeyは「情報」タブに表示されているほか、メイン画面に表示することもできる。また検索でも使える（これは設定で無効にできる）

<spanid="日本語文献のcitation-keyについて">
====日本語文献のCitationKeyについて====

[https://qiita.com/shiro_takeda/items/dfb857e69aa8ed2cc977https://qiita.com/shiro_takeda/items/dfb857e69aa8ed2cc977]nmd_mw_mark_link

<spanid="yearデータの不具合6760で修正済">
====yearデータの不具合(6.7.60で修正済)====

参考文献には出版年を書く必要があり、BibTeXではyearというフィールドに書かれる。このデータはZoteroの文献情報のdateのところから取得されており、「April22,2011」「2011-04-22」のようなdateのデータからは正しく「2011」だけを抽出してくれるが、dateが前述の「4月22,2011」のような書式になっていた場合はうまくいかず、この文字列全てがBibTeX（.bib）に出力されてしまう（報告済み:[https://github.com/retorquere/zotero-better-bibtex/issues/2449[Bug]:Japanesedateformatisnotparsedcorrectly·Issue#2449·retorquere/zotero-better-bibtex]nmd_mw_mark_link、6.7.61あたりで修正済み）。←の通り、BetterBibTeXのエクスポート時に適用されるscript（Export→postscript）のところにデータを置換するための以下のようなコードを書いておくとよい。

<syntaxhighlightlang="python">vb.net
if(tex.has.year){
tex.add({name:'year',replace:true,value:tex.has.year.value.replace(/.*/,'')})
}</syntaxhighlight>
設定箇所はこんな感じ↓

<div class="res-img">https://turgenev.cloudfree.jp/mw1/imgs/zot-settings.jpg</div>

*今は治っているかもしれないが、デバッグ出力を有効化して再起動してからスクリプトを一度編集しないとスクリプトが読み込まれないバグがあった（[https://github.com/retorquere/zotero-better-bibtex/issues/2447https://github.com/retorquere/zotero-better-bibtex/issues/2447]nmd_mw_mark_link）。

<spanid="zotero-protocolを使用した操作">
==ZoteroProtocolを使用した操作==

{{Valuable}}

ZoteroはGUIのソフトであるが、コマンドラインからも一定の操作が可能である。具体的には、<code>zotero://</code>という形式のURL（URIスキーム）を以下のように指定してZoteroを起動することができる（既に起動していた場合は、画面に変化が起こる）。

<syntaxhighlightlang="python">python
zotero.exe-url"zotero://url/here"</syntaxhighlight>
URLについては、明確にAPIとして仕様が定められたものではなさそうで、全体的にあまりドキュメントは充実していない。

一例として、特定のコレクション内のアイテムが選択された状態にするということができる。コメントが不親切でわかりづらいが[https://github.com/zotero/zotero/blob/master/components/zotero-protocol-handler.jszotero/zotero-protocol-handler.jsatmaster·zotero/zotero]nmd_mw_mark_linkの<code>scopeObject</code>などと書いてあるあたりをよく読むと、<code>zotero://select/library/collections/{collection_key}/items/{item_key}</code>という形式で指定すればよいことがわかる（groupIDなどと書いてある部分もあって紛らわしいが、groupというのはcollectionとは別の概念で、複数ユーザー間での共有のライブラリのようなものを指すようである）。<code>collection_key</code>と<code>item_key</code>はどちらも<code>1A2B3C4D</code>のような英数字による8文字の識別子である。ちなみにcollectionとitemにはそれぞれIDも割り当てられているがこちらは1～3桁くらいの数字でありkeyとは別なので注意。

<spanid="指定されたcitation-keyのアイテムをzoteroで開く">
==指定されたCitationkeyのアイテムをZoteroで開く==

前述の方法を応用して実装してみる。ここではCitationkeyとしてBetterBibTeXのものを使うことを仮定する。

まず、Citationkeyからアイテムのキーを取得する部分を作る。CitationkeyはBetterBibTeXが管理しているので（ここではデフォルトの~/Zoteroに各種データがあると仮定して）~/Zotero/better-bibtex.sqliteを読めばアイテムのkeyとの対応がわかる。次にアイテムが所属するコレクション（複数ある場合は最初のもの）のkeyをzotero.sqliteから取得する。ここではIDを一旦経由する必要がある。

Zoteroの起動中はデータベースファイルがロックされているが、[https://sqlite.org/forum/info/a2e9387b8ea1c919b2ad1ecafb417cebb15c48634c55b3abd6a9acbb2fabf797SQLiteForum:Optiontoopenadatabaseasread-onlydespitelocked.]nmd_mw_mark_linkにある通り、（Windowsなら）<code>sqlite3"file:Zotero\\zotero.sqlite?mode=ro&nolock=1"</code>のようにしてやると読み取り専用で開くことはできる（書き込まないのでこれで充分）。今回はpythonで実装するが、pythonのsqliteでもこのパラメータが同じく使える。

コード例:

<syntaxhighlight style="margin-bottom:0.2em;"lang="python">python
importsqlite3
importsys
importjson
importsubprocess
db=sqlite3.connect('file:'+sys.argv[1]+'?mode=ro&nolock=1',uri=True)
cur=db.cursor()
cur.execute('SELECTdataFROM"better-bibtex"wherename="better-bibtex.citekey"')
d=json.loads(cur.fetchone()[0])
mydict={}
foritemind["data"]:
mydict[item["citekey"]]=item["itemKey"]
myKey=mydict[sys.argv[3]]

db2=sqlite3.connect('file:'+sys.argv[2]+'?mode=ro&nolock=1',uri=True)
cur2=db2.cursor()
cur2.execute("SELECTitemIDFROMitemsWHEREkey=?",(myKey,))
item_id=cur2.fetchone()[0]
cur2.execute("SELECTcollectionIDFROMcollectionItemsWHEREitemID=?",(item_id,))
#所属する最初のコレクションIDを取得
collection_id=cur2.fetchone()[0]
#collectionIDからcollectionKeyを取得
cur2.execute("SELECTkeyFROMcollectionsWHEREcollectionID=?",(collection_id,))
collection_key=cur2.fetchone()[0]
print(collection_key)
subprocess.run(f'"C:\ProgramFiles(x86)\Zotero\zotero.exe"-url"zotero://select/library/collections/{collection_key}/items/{myKey}')
db.close()
db2.close()</syntaxhighlight>
<divstyle='text-align:center;'>zoto.py</div>

上記コードは以下のように起動できる。

<syntaxhighlightlang="python">c#
python"path\to\zoto.py""%USERPROFILE%\Zotero\better-bibtex.sqlite""%USERPROFILE%\Zotero\zotero.sqlite"%1</syntaxhighlight>
*[[Windowsのクリップボードを用いた選択コンテンツの取得|Windowsのクリップボードを用いた選択コンテンツの取得]]nmd_mw_mark_linkと組み合わせれば、選択文字列をCitationkeyとするアイテムを一発で開くことも可能。

==その他==

アイテムが入っているコレクションを知りたいときはアイテムが選択された状態でCtrlキーを押すとよい。
[[Category:IT]]{{#seo:|title={{FULLPAGENAME}}-Turgenev'sWiki}}

AFDKOによるOpenTypeフォントの作成

2025-04-02T08:37:58Z

Turgenev: Notion-MW

筆者は[https://github.com/adobe-type-tools/afdko Adobe Font Development Kit for OpenType (AFDKO)]を用いて、[https://github.com/ge9/NazonoMincho 謎乃明朝]というフォントを作成し公開している。謎乃明朝は[http://fonts.jp/hanazono/ 花園フォント]と同じく[https://glyphwiki.org/wiki/GlyphWiki:%e3%83%a1%e3%82%a4%e3%83%b3%e3%83%9a%e3%83%bc%e3%82%b8 GlyphWiki]のデータをもとにしている完全フリーのフォントであるが、GlyphWikiデータからの漢字のパスデータの生成においてオリジナルの[https://github.com/kamichikoichi/kage-engine KAGEエンジン]を[https://github.com/ge9/kage-engine-2 改変したもの]を使用している。

改変エンジンのget_sub_path_svg_fontという関数を使用すると、[0 -120 1000 880]をバウンディングボックスとしたときに適切に表示されるようなパスがSVG形式で出力される。この記事ではそこから先のプロセスについて解説する。

他に全体を通して参考になるサイトとしては以下がある。

<ul>
<li>[https://shiromoji.hatenablog.jp/entry/20111206/1323270030 AFDKO入門《CIDキー方式のOpenTypeフォントの作り方》前篇：AFDKOのインストールとmergeFonts - しろもじメモランダム]
一通りのことが書いてある読みやすい日本語の記事はこれくらいである。筆者もこれを参考にした。</li>
<li>[https://ccjktype.fonts.adobe.com/wp-content/uploads/2012/06/afdko-lunde-20120625.pdf https://ccjktype.fonts.adobe.com/wp-content/uploads/2012/06/afdko-lunde-20120625.pdf]
ワークショップで使用した講義資料なので単体だとやや読みづらいが、ヒント情報の付加に関して唯一まともに書いてあった。</li>
<li>[https://aznote.jakou.com/prog/opentype/index.html OpenType フォント・フォーマット]
OpenTypeの仕様が日本語で記述されている。</li></ul>


== パスの統合・単純化 ==

これはAFDKOには関係ないが割と役に立つ話なのでついでに記載する。


=== Inkscapeによる統合 ===

改造エンジンで生成した漢字パスデータはそれぞれの画が別々のサブパスで表現されており、互いに重複する部分がある。これをそのままフォントに使うこともできるが、画が交差する場所（「田」の中央とか）で白い抜けが表示されてしまうなど不具合が生じる場合がある。そこで、重複がなくなるようにパス同士のUnionを取る（統合する）必要がある。

この目的で本家の花園明朝では[https://github.com/AngusJohnson/Clipper2 Clipper]が使われているが、こちらはどうやら直線のみ対応で、ベジェ曲線は扱えないようである。ベジェ曲線にも使えるフリーのものはFontforgeとInkscapeがあるがFontforgeは色々と不安定なのでInkscapeを使う。

* Fontforgeは一応試したが、閉じていないパスが発生する不具合が頻発するのと、GUIだと途中で落ちる。ところで、謎乃明朝にissue([https://github.com/ge9/NazonoMincho/issues/2 https://github.com/ge9/NazonoMincho/issues/2])が立ったが、KAGEデータの「曲げ」ストロークにおいてInkscapeの統合によって図形が消えるバグが発生していた（[https://gitlab.com/inkscape/inbox/-/issues/6886 https://gitlab.com/inkscape/inbox/-/issues/6886] に報告済）（謎乃明朝側ではストロークの図形をあらかじめ統合された状態で生成することで回避して対応済）。Inkscapeも完璧ではないようである。

コマンドとしては

<syntaxhighlight lang="vb.net">inkscape --actions="select-all;path-union" --export-type=svg input.svg</syntaxhighlight>
などとすると、input_out.svgが出力される。

ワイルドカード<code>*.svg</code>も使えるが、謎乃明朝のビルド時はかなり大量のファイルを処理するために「コマンドライン引数が長すぎる」的なことを言われてしまうのでxargsを使った（自動で分割してくれる）。

個々のsvgファイルとして処理する（出力ファイルを逐一新規作成する）ためIOが頻発して効率はあまりよくない（謎乃明朝の数万グリフに対して実行すると数十分かかる）のだが、入力ファイル単位で分ける以外で複数のパスデータをバッチ処理で統合する（例えばsvgの”path”タグごと処理するなど）方法があるのかどうかはわからなかった。分かったら誰か教えてください。


=== Fontforgeによる単純化 ===

統合を行うと、（KAGEエンジン側のデザインの都合もあり）完全な直線になるべき部分が微妙な誤差のせいでほぼ直線と変わらない微妙な折れ線になってしまうことがある。また、極めて短く直線に近似できるのにベジェ曲線で表現されてしまう場合もある。こうした箇所はデータ削減やヒント（後述）の品質向上のために制御点を除いて単純化（simplify）したい。

Inkscapeにも単純化はあるのだが、やってみたところ、単純化を行うと逆に曲線部分では無駄な制御点が挿入されてしまうというバグ（[https://gitlab.com/inkscape/inbox/-/issues/8096 報告済み]→[https://gitlab.com/inkscape/inkscape/-/issues/4419 こちら]に移動）があったので今回はスキップ。単純化に関してはFontforgeのほうが良さそうである。

FontforgeはSVGフォント（＝単一ファイルに複数のパスを入れられる）に対応しているので、先ほどInkscapeが出力したファイルを一つにまとめてからFontforgeに入力して全グリフをSimplifyするという流れになる。あとFontforgeのGUIは割と不安定（特にWindows版）なので、対象が1000個を超えるような場合はスクリプトを組んでCUIで実行することを強く推奨する。

例:

<syntaxhighlight lang="python">Open($argv[1])
SelectAll()
Simplify(128+32+8, 1.1)
Generate($argv[2])</syntaxhighlight>
* 手元では「NaN value in spline creation」というエラーが漢字10000字につき1.5文字くらいの割合で出るのだが、該当文字を見ても特に問題はなさそうだったので放置している。


== AFDKOでのフォント作成 - 基本 ==

基本的には

素材フォント→（適宜txなどで変換した上でmergefonts）→ヒント情報無しのCIDフォント→（[https://github.com/adobe-type-tools/perl-scripts/blob/master/hintcidfont.pl perl-scripts/hintcidfont.pl at master · adobe-type-tools/perl-scripts] と psautohintによるヒント情報の付加）→ヒント情報付きのCIDフォント→（makeotf）→完成品の（CIDキー方式の）OpenTypeフォント

という流れになる。

「CIDフォント」「PostScriptフォント」「CFFフォント」「Type1フォント」「OpenTypeフォント」など様々な用語があるが、いずれも正確な定義が難しいものばかりであり筆者も正確に理解しているわけではないのでそこは注意して読み進めていただきたい。今回作るものは「CIDキー方式のOpenTypeフォント（CID-keyed OpenType Font）」だが、おそらくCFFフォントでもあり、PostScriptフォントでもあるのではないかと思われる。


== txで使えるSVGデータ ==

{{Valuable}}

<s>まず、単体のSVGではフォントとして正しくtxに認識されないので、SVGフォントの形にする必要がある。具体的には、</s><s>タグが最も外側にある状態</s><s>にする。「SVGフォント」といったときには（例えばFontforgeでフォントとして開く場合）さらに外側に</s><s><code><svg><defs>…</defs></svg></code></s><s>のようなタグが必要になる場合もあるが、これだとtxには弾かれるので注意が必要である。</s>

<ul>
<li>（2023/12/21追記）改めて試したところ、<code><svg><defs>...</defs></svg></code>で囲っても問題なく動いた。ただ、FontForgeが出力するSVGフォントのヘッダーの
<syntaxhighlight lang="shell"><?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd" ></syntaxhighlight>
があると動かなかったので、上記の内容はおそらくそれを勘違いしたものと思われる。なお、このヘッダがなくてもFontForgeは正しくSVGフォントを開けるが、<code><svg><defs>...</defs></svg></code>がないと開けないので、<code><svg><defs>...</defs></svg></code>は付けてヘッダーは無しで保存しておくのが最も良さそうである。</li>
<li>txのエラーメッセージは全体的にあまり丁寧ではなく、例えば入力のsvgに何かおかしい点（※ただしtxによる主観的評価）がある場合は<code>(svr)</code>などとしか表示してくれない。デバッグモードもなさそうなので、根気強く原因を探すしかない。
<ul>
<li><code>(svr)</code>のような形式の出力については、おそらく最初の二文字（ここでは<code>sv</code>=svgだが、<code>cf</code>=cffなどもある）がフォーマットを表し、最後の一文字は<code>r</code>がerror、<code>w</code>がwarningを表すようである。</li></ul>
</li>
<li>そもそもAFDKO自体に「Adobe社内の業務用ツールが形だけ一般公開されている」ような雰囲気を感じなくもないような…</li></ul>

例えば以下は正しくtxに認識される入力のsvgである。

<syntaxhighlight style="margin-bottom:0.2em;" lang="xml">
<font-face
font-family="Untitled1"
font-weight="400"
font-stretch="normal"
units-per-em="1000"
ascent="880"
descent="-120"
bbox="0 0 1000 1000"
underline-thickness="50"
underline-position="-100"
/>
<missing-glyph horiz-adv-x="1000" d="M500 300l150 -300l-300 0zM650 760l-150 -300l-150 300l300 0zM730 760l0 -760l-190 380zM270 760l190 -380l-190 -380l0 760zM200 830l0 -900l600 0l0 900l-600 0z"/>
<glyph unicode="0" horiz-adv-x="1000" d="m-100,-100l100,0L0,100C0,200 200,0 200,200 m100,200 c 300,0 0,300 300,300 Zm-150,-150 c 200,100 -100,0 0,100 l-300,-200 l100,200 z"/>
<glyph unicode="S" horiz-adv-x="500"/>
<glyph unicode="D" horiz-adv-x="1000"/>
</syntaxhighlight>
<div style='text-align: center;'>system.svg</div>

今回はsvgを素材としてのみ使用する（フォント名などは後で設定する）のでfont-faceタグの中身はあまり気にしなくてよいと思うが、フォントの高さ範囲を決める<code>ascent</code>と<code>descent</code>は一応正しい値を入力してある。OpenTypeでは通常このようにフォントの高さは1000とする。

以降がフォント本体のデータで、パス（d属性）と水平方向の幅（horiz-adv-x属性）をそれぞれ指定する。

<code>missing-glyph</code>は普通のフォント用語でいうと<code>.notdef</code>にあたるもので、文字が無かった時に表示されるいわゆる「豆腐」のことである。他のフォント形式に変換するとこのグリフが<code>.notdef</code>に割り当てられることになる。このsvgではU+303F（〿、□の中に×が入った形）のような図形が入っている。

それ以降のglyphタグではunicode属性によりどの文字を使用するかを設定している。<code>S</code>や<code>D</code>のようにd属性がない場合は空白（スペース）を表すことになる（逆にd=””などと書くとエラーになったはず）。幅を見ればわかる通り、Sが半角スペース、Dが全角スペースである。

==== d属性の解釈について ====

{{Valuable}}

txによるd属性の解釈はものすごく行儀が悪く、エラーメッセージを出さない割に明らかに仕様を満たさない挙動を連発する。

* txの挙動を迅速に確かめるには、<code>tx -pdf input.svg > output.pdf</code>とpdfに変換して見るのがよい。
* 以下の不具合に関する具体的な報告はなさそうであるが、[https://github.com/adobe-type-tools/afdko/issues/1567 [tx/SVG] Replace homemade XML parser with LibXML2 for SVG parsing · Issue #1567 · adobe-type-tools/afdko]は関係がありそうなのでこれがfixされれば治る可能性がある。

txの1.3.0（2023年1月現在で多分最新）に関して挙動をまとめる。

まず、正しく解釈できると思われるのは以下の命令である。

* M（絶対座標によるパス開始点の指定）
* L（絶対座標による直線描画）
* l（相対座標による直線描画）
* C（絶対座標による3次ベジェ曲線描画）
* z, Z（パスを閉じる）

問題なのはc（相対座標による3次ベジェ曲線）で、本来は現在の点が(x, y)であるときに<code>c x1,y1 x2,y2 x3,y3</code>とすると(x, y)→(x+x1, y+y1)→(x+x2, y+y2)→(x+x3, y+y3)という3次ベジェ曲線が描画されるべきであるが、txでは(x,y) → (x+x1, y+y1) → (x+x1+x2, y+y1+y2) → (x+x1+x2+x3, y+y1+y2+y3) という意味に解釈される。

似たような問題として、パスの開始点（最初やzの直後で使用する）でm（相対座標指定）を使用する場合は、本来は絶対座標として解釈されるべきであるが、txでは直前の座標（zの直前）からの相対位置で計算される。なお、フォントの描画においては必ず閉じたパスを使用する（多分）のでパスの描画途中でMやmを使用することはありえないが、仮に使用した場合、（txでは）その直前にzを付加したのと同じ挙動をするようである。

そして、以下には対応していない。

* V, v, H, h（絶対/相対座標による垂直/水平な直線の描画）
* Q, q（絶対/相対座標による2次ベジェ曲線描画）

これらはそれぞれL, lとC, cに容易に変換できるので、そのようにしてから渡すべきである。

さらに、svgではデータ量の圧縮のため直前と同じ命令を使用する場合は<code>l 100,100 l 200,200</code>と書くかわりに<code>l 100,100 200,200</code>などと略することができるがこれにも対応していない（余ったパラメータは余計なものとして無視される）。

また、svgの仕様では座標データの数字において指数表現（1.2345e-6のような）が許容されているが、これにも対応していない（<code>(svr)</code>となる）。

謎乃明朝で使用したsvgに関しては、元データでM,C,Lのみ使っていたおかげかinkscapeの出力でもそれら以外が入ることはないようだったが、指数表現に関してはごく稀に（謎乃明朝全体でも10個以下程度）紛れ込んでいたので<code>sed -r "s/ -?[0-9]\.[0-9]*e-[0-9]+ / 0 /g"</code>で0に変えた。小数に直すのが筋かもしれないが、OpenTypeではそもそも座標が整数に丸められる気がするのでこれでいいはず。

* Inkscapeが相対座標を使用するかどうかは設定で変えられるらしい。参考: [https://stackoverflow.com/questions/6890685/is-there-a-tool-to-convert-svg-line-paths-from-absolute-to-relative Is there a tool to convert SVG line paths from absolute to relative? - Stack Overflow]


==== FontForgeの出力の修正 ====

FontForgeで出力されるsvgには<code>l</code>や<code>c</code>に加えて<code>h</code>や<code>v</code>なども（元データになくても）入ることがあり、これはtxが読めないので修正する。あとtxには関係ないが、PostScriptアウトラインの向きはFontForgeが出力するSVGのアウトラインの向き（＝TrueTypeのアウトラインの向き）と逆なので、この段階で修正しておくとよい。この2点の修正は謎乃明朝の生成スクリプトでは[https://github.com/thednp/svg-path-commander https://github.com/thednp/svg-path-commander]にやらせている。

== txによる変換 ==

この次で使用するmergefontsは、複数のフォントをマージするコマンドであるが、より正確には「親」となるフォントに「子」となるフォントを統合するコマンドである（ヘルプにも書いてある）。上記のようなsvg形式のフォントは「子」にはなれるが「親」にはなれない。

そこでtxコマンド（fonttoolsのttxと名前が似ているが全く異なるものなので注意）を用いてsvgを「親」として使えるフォーマットに変換する。この際の出力は、<code>-ps</code>(PostScript形式)、<code>-cff</code>(CFF形式）、<code>-t1</code>(Type1形式)などいくつかのオプションが選べるが、psautohintでヒントを付ける方法を筆者が発見できたのは<code>-t1</code>を使った場合のみであった。ヒントを付けないのであれば-cffでも問題なくこの記事の最後まで進むことができる。-psも-cffと同じだったと思う。

ちなみにmergefontsは子としてsvgが指定された場合にはそれを読むために内部的にtxを使用するため、子にしても親にしてもtxが読めるsvgを指定する必要がある。

謎乃明朝では、.notdefや空白など一部のシステムグリフ的なものだけを含むsvg（上記のsystem.svg）を親フォントとしてまずType1形式に変換したあと、子フォントとして漢字グリフを統合することにしている。

従ってコマンドとしては以下のようになる。

<syntaxhighlight lang="vb.net">tx -t1 system.svg > system.pfa</syntaxhighlight>
参考までに、system.pfaの最初のほうは以下のようになっている。

<syntaxhighlight lang="vb.net">%!FontType1-1.1: Untitled1
%ADOt1write: (1.0.35)
%%Copyright: Copyright 2023 Adobe System Incorporated. All rights reserved.
%%BeginResource: font Untitled1
12 dict dup begin
/FontType 1 def
/FontName /Untitled1 def
/FontInfo 4 dict dup begin
/FullName (Untitled1) def
end def
/PaintType 0 def
/FontMatrix [0.001 0 0 0.001 0 0] def
/Encoding 256 array
0 1 255 {1 index exch /.notdef put} for
def
/FontBBox {-100 -100 950 1050} def
end
currentfile eexec BAB431EA06BB0A1031E1AA11919E714AC6968FC4C8AFEB
5F1C717DAFACA48FA00303519D5ACA187D3A7A07245E6211EF0746489B63BDB8
0250FD69171FFE98581843A94F9CCED81A25205CD6D774793B21300079565F0A
...</syntaxhighlight>
== mergefonts ==

次にmergefontsを使ってCIDフォントを作る。CIDフォントを作る場合は、コマンドの構文は以下のようになる。

<syntaxhighlight lang="vb.net">mergeFonts -cid [cidfontinfo] [output] [font1.map] [font1] [font2.map] [font2] ...</syntaxhighlight>
cidfontinfoはフォントに関していくつかの情報を設定するファイルで、今回は以下のものを使用する。

<syntaxhighlight lang="vb.net">FontName (NazoMin)
FullName (NazoMin Unknown)
FamilyName (NazoMin)
Weight (Unknown)
version (1.000)
Registry (Adobe)
Ordering (Identity)
Supplement 0
AdobeCopyright (Public Domain)</syntaxhighlight>
細かい部分の効果はわからないが（詳しくは[https://shiromoji.hatenablog.jp/entry/20111206/1323270030 AFDKO入門《CIDキー方式のOpenTypeフォントの作り方》前篇：AFDKOのインストールとmergeFonts - しろもじメモランダム]）、とりあえずこれで問題なく先に進めるだろう。FontName（Postscript名）の「NazoMin」の部分は後で使用するので覚えておくこと。FullNameとFamilyNameについては最終的にどのように反映されるのかよくわかっていない。

* Postscript名は、フォントの名前の一種であるが、あまりユーザーが目にすることはない。Postscript名では、空白を使用してはいけない。たとえば[https://github.com/adobe-fonts/source-han-code-jp/blob/master/Normal/cidfontinfo source-han-code-jp/cidfontinfo at master · adobe-fonts/source-han-code-jp]のようにハイフンに置き換えられていることが多い。また、「+」は禁止ではないようだが、今回使用するhintcidfont.plは対応していない。フォント名に「+」が入っている代表的なフォントである「M+フォント」の一種[https://fonts2u.com/m-2m-regular.font M+ 2m regular font]においても、Postscript名は「mplus」となっているようである。

outputで指定するファイル名は何でもいいが、そのままではまだ使えない「生」のCIDフォントということで「.raw」という拡張子を使う場合もあるようである。今回であればType 1が出力されるので.pfaとしてもよいだろう。

==== mapファイルと素材フォント ====

{{Valuable}}

では、残るmapファイルと素材フォントの部分について解説する。三点リーダ<code>...</code>で示した通り、この<code>[font1.map] [font1]</code>のペアはいくらでも多く指定してよい。この部分がフォントの本体部分を形作ることになる。

最初のペアとして指定されたものが前述の「親フォント」ということになる。ここにType1フォントを指定すれば出力もType1になるし、CFFフォントを指定すればCFFになる。

今回は親フォントとして先ほどのsystem.pfaを使用する。

以下がそれに対応するmapファイルの例（system.map）である。

<syntaxhighlight style="margin-bottom:0.2em;" lang="vb.net">mergeFonts NazoMin-System
0 .notdef
1 S
633 D
8720 S</syntaxhighlight>
<div style='text-align: center;'>system.map</div>

ファイルの最初にはこのようにmergeFontsという語が必要であり、その後にFDArray要素（この用語は後のヒント情報付加のところでまた出てくる）の名前を書く。ここではcidfontinfoで使用した<code>NazoMin</code>という（任意の）識別子にハイフンを付加してさらに別の（後でも使用する任意の）識別子である<code>System</code>を追加した<code>NazoMin-System</code>という名前を指定している。このようにしないと、ヒント情報を付加するスクリプトである[https://github.com/adobe-type-tools/perl-scripts/blob/master/hintcidfont.pl https://github.com/adobe-type-tools/perl-scripts/blob/master/hintcidfont.pl]が正しく使えない。これはどこを見てもあまりはっきりとは書かれおらず、最終的にスクリプトのソースを読んでわかったことなので注意が必要である（スクリプトの説明をよく読むと一応「the CIDFontName plus a unique identifier」などと書いてあるのだが、ハイフンを間に入れるという説明は全くない）。ただし、これはそうしないとこのスクリプトが使えないというだけであって、CIDフォントの仕様上必要というわけではない（多分）。ただ実際、多くのCIDフォント（例えば源ノ角ゴシックなど）ではこのような命名がされている気がする。

2行目以降が、CIDからグリフへの対応を記述したものである。

* 以下のように、x番目のCIDという意味で「CID+x」と書くことが多い

まず2行目で、CID+0に先ほどのSVGのmissing-glyphが割り当てられる。CIDフォント（少なくともCID形式のOpenTypeフォント？）ではCID+0は必ず含める必要があり、これが「豆腐」グリフとなる。

3-5行目により、CID+1とCID+8720には半角スペース（ただし後者は縦書き用として使用する。後のmakeotfの節も参照）、CID+633に全角スペースが割り当てられる。これは[https://github.com/adobe-type-tools/Adobe-Japan1 Adobe-Japan1]に従ったものであるが、Adobe-Japan1準拠のフォントを作るのでなければ（CID+0とは違って）必ずしもこのようにする必要はないはず。ただ、（現在はリンク切れとなっているのでweb archiveのURLを貼るが）[http://web.archive.org/web/20130225051414/http://d.hatena.ne.jp/mashabow/20120306/1331028598 花園明朝OTを0.510に更新、IVD 2012-03-02版に対応 - しろもじメモランダム]において、「Windowsでは、CFFアウトラインのOpenTypeフォントのGSUBテーブルにvrt2 featureが定義されていないのにvhea/vmtxテーブルがあると、OSに不正なフォントして弾かれます。」との情報があり、[http://web.archive.org/web/20161115085209/http://shiromoji.net/font/HanaMinOT/ 花園明朝OT]ではこれに対応するためにこの3グリフを追加したとされている。そこで謎乃明朝でも一応この通りにしている（ただし謎乃明朝+では漢字と範囲を分けるためにCIDの割り当てを1, 633, 8720からそれぞれ1, 100, 101に変えている）。

このファイルを見てわかる通り、ソースフォントの同じ文字を複数のCIDで使用しても構わない（その分データは増えるはず）（[https://github.com/adobe-type-tools/Adobe-Japan1/blob/master/README-JP.md Adobe-Japan1/README-JP.md at master · adobe-type-tools/Adobe-Japan1] の「重複した漢字グリフ」もその一例）。CIDの部分は0000,00001のように先頭にいくつか0が付いていても構わない。

次に、「子」として使用するmapファイルとSVGファイル（今回は子は1つだけなので1つずつ）をそれぞれ見てみよう。謎乃明朝には数万文字の漢字が収録されているが、ここでは解説に適した6グリフのみ収録したサンプルを使用する。

<syntaxhighlight style="margin-bottom:0.2em;" lang="vb.net">mergeFonts NazoMin-Ideographs
14197 u8279-j
14198 ufa5e
14199 ufa5d
24000 u20000-jv
24001 u20000-ue0101
24002 u20000-ue0102</syntaxhighlight>
<div style='text-align: center;'>kanjisample.map</div>

<syntaxhighlight style="margin-bottom:0.2em;" lang="xml">
<font-face
font-family="Untitled1"
font-weight="400"
font-stretch="normal"
units-per-em="1000"
ascent="880"
descent="-120"
bbox="0 0 1000 1000"
underline-thickness="50"
underline-position="-100"
/>
<missing-glyph horiz-adv-x="1000" d="M50,0l900,0l0,533l-900,0 z M100,50l0,433l800,0l0,-433z"/>

<glyph glyph-name="u8279-j" d="M 321.5 247.15039 L 321.5 411.21289 L 43.25 411.21289 L 43.25 436.41211 L 321.5 436.41211 L 321.5 562.9375 L 321.5 578.6875 L 321.5 600.38867 L 383.93359 588.48633 C 415.96232 582.32437 417.82989 565.93743 384.5 555.52148 L 384.5 436.41211 L 615.5 436.41211 L 615.5 562.9375 L 615.5 578.6875 L 615.5 600.38867 L 677.93359 588.48633 C 709.96232 582.32437 711.82989 565.93743 678.5 555.52148 L 678.5 436.41211 L 843.34961 436.41211 L 893.75 486.8125 L 956.75 436.41211 L 956.75 411.21289 L 678.5 411.21289 L 678.5 272.34961 L 615.5 247.15039 L 615.5 411.21289 L 384.5 411.21289 L 384.5 272.34961 L 321.5 247.15039 z"/>
<glyph glyph-name="ufa5e" d="M 279.5 247.15039 L 279.5 411.21289 L 43.25 411.21289 L 43.25 436.41211 L 279.5 436.41211 L 279.5 562.9375 L 279.5 578.6875 L 279.5 600.38867 L 341.93359 588.48633 C 373.96232 582.32437 375.82989 565.93743 342.5 555.52148 L 342.5 436.41211 L 360.34961 436.41211 L 410.75 486.8125 L 473.75 436.41211 L 473.75 411.21289 L 342.5 411.21289 L 342.5 272.34961 L 279.5 247.15039 z M 657.5 247.15039 L 657.5 411.21289 L 526.25 411.21289 L 526.25 436.41211 L 657.5 436.41211 L 657.5 562.9375 L 657.5 578.6875 L 657.5 600.38867 L 719.93359 588.48633 C 751.96232 582.32437 753.82989 565.93743 720.5 555.52148 L 720.5 436.41211 L 843.34961 436.41211 L 893.75 486.8125 L 956.75 436.41211 L 956.75 411.21289 L 720.5 411.21289 L 720.5 272.34961 L 657.5 247.15039 z"/>
<glyph glyph-name="ufa5d" d="M 342.5 247.15039 L 342.5 415.15039 L 43.25 415.15039 L 43.25 440.34961 L 342.5 440.34961 L 342.5 564.25 L 342.5 580 L 342.5 601.70117 L 404.93359 589.79883 C 436.96232 583.63687 438.82989 567.24993 405.5 556.83398 L 405.5 272.34961 L 342.5 247.15039 z M 594.5 247.15039 L 594.5 564.25 L 594.5 580 L 594.5 601.70117 L 656.93359 589.79883 C 688.96232 583.63687 690.82989 567.24993 657.5 556.83398 L 657.5 440.34961 L 843.34961 440.34961 L 893.75 490.75 L 956.75 440.34961 L 956.75 415.15039 L 657.5 415.15039 L 657.5 272.34961 L 594.5 247.15039 z"/>
<glyph glyph-name="u20000-jv" d="M 143 -31.099609 L 143 480.25 L 201.80078 450.84961 L 473.75 450.84961 L 473.75 756.40039 L 80 756.40039 L 80 781.59961 L 806.59961 781.59961 L 857 832 L 920 781.59961 L 920 756.40039 L 536.75 756.40039 L 536.75 385.75 L 473.75 360.55078 L 473.75 425.65039 L 206 425.65039 L 206 57.099609 L 775.09961 57.099609 L 825.5 107.5 L 888.5 57.099609 L 888.5 31.900391 L 206 31.900391 L 206 -5.9003906 L 143 -31.099609 z"/>
<glyph glyph-name="u20000-ue0101" d="M 143 -36.349609 L 143 417.25 L 201.80078 387.84961 L 468.5 387.84961 L 468.5 640.90039 L 80 640.90039 L 80 666.09961 L 468.5 666.09961 L 468.5 805.75 L 468.5 821.5 L 468.5 843.20117 L 530.93359 831.29883 C 562.86375 825.15583 564.51051 808.89709 531.5 798.47656 L 531.5 666.09961 L 806.59961 666.09961 L 857 716.5 L 920 666.09961 L 920 640.90039 L 531.5 640.90039 L 531.5 322.75 L 468.5 297.55078 L 468.5 362.65039 L 206 362.65039 L 206 51.849609 L 780.34961 51.849609 L 830.75 102.25 L 893.75 51.849609 L 893.75 26.650391 L 206 26.650391 L 206 -11.150391 L 143 -36.349609 z"/>
<glyph glyph-name="u20000-ue0102" d="M 143 -43.123047 L 143 395.38281 L 201.79688 365.98438 L 473.75 365.98438 L 473.75 601.78711 L 95.75 601.78711 L 95.75 626.98828 L 817.10156 626.98828 L 867.5 677.38672 L 930.5 626.98828 L 930.5 601.78711 L 536.75 601.78711 L 536.75 300.88281 L 473.75 275.68359 L 473.75 340.7832 L 206 340.7832 L 206 45.078125 L 775.10156 45.078125 L 825.5 95.476562 L 888.5 45.078125 L 888.5 19.876953 L 206 19.876953 L 206 -17.921875 L 143 -43.123047 z M 500 706 C 469.39653 706.23029 444.875 730.37828 444.875 761.125 C 444.875 791.87172 469.39653 816.01971 500 816.25 C 530.60347 816.01971 555.125 791.87172 555.125 761.125 C 555.125 730.37828 530.60347 706.23029 500 706 z"/>
</syntaxhighlight>
<div style='text-align: center;'>kanjisample.svg</div>

先ほどと違ってsvgにおいて各グリフにunicode属性ではなくglyph-name属性を指定していることに注意。system.svgではType1への変換を経由しているのでunicodeを指定してそれをグリフ名として使う必要があったが、svgフォントを直接指定する場合はglyph-nameがかわりに使えるようである（unicodeでも探してくれるかもしれないが確かめていない）。「glyph-00001」のようにunicodeとは全く無関係の識別子でも自由に使えるので便利である。ここではglyph-nameとしてGlyphWikiでのグリフ名を使用している（例えばu8279-jは[https://glyphwiki.org/wiki/u8279-j?view=all u8279-j (艹) - GlyphWiki]の字形である）。

またmapファイルのFDArray要素の名前としては<code>NazoMin-Ideographs</code>と、先ほどの<code>System</code>とは異なり<code>Ideographs</code>という識別子を使っている。これも後で使う。

今後の説明でも必要になるので上記で例として使用している字について一通り説明しておこう。以下が<code>tx -pdf kanjisample.svg > kanjisample.pdf</code>で出力されるpdfである。

<div class="res-img">https://turgenev.cloudfree.jp/mw1/imgs/kanjisample.pdf.jpg</div>

見ての通り、最初の3文字は「くさかんむり」であるが、微妙に字形が異なる。

この3グリフは（記事執筆時点の）GlyphWikiにおいてそれぞれ以下のUnicodeコードポイントや異体字シーケンスが割り当てられている。（ここでは異体字について詳しく解説はしないが、以下の意味がすんなり理解できるようになれば異体字マスターといっても過言ではない（？）。「異体字セレクタ」「Adobe-Japan1」「CJK部首補助」などの語で適宜検索すること。）

# つながった字形…CJK部首補助<code>U+2EBE</code>（⺾）、CJK統合漢字<code>U+8279</code>（艹）、Adobe-Japan1コレクションのIVS<code>U+8279 U+E0100</code>（艹󠄀）、Moji_Joho及びHanyo-DenshiコレクションのIVS<code>U+8279 U+E0105</code>（艹󠄅）
# 「十」が2つの字形…CJK部首補助<code>U+2EBF</code>（⺿）、CJK互換漢字<code>U+FA5E</code>（艹）、それに対応するSVSである<code>U+8279 U+FE01</code>（艹︁）、Adobe-Japan1コレクションのIVS<code>U+8279 U+E0102</code>（艹󠄂）、Moji_Joho及びHanyo-DenshiコレクションのIVS<code>U+8279 U+E0104</code>（艹󠄄）
# 「T」が背中合わせの字形…CJK部首補助<code>U+2EC0</code>（⻀）、CJK互換漢字<code>U+FA5D</code>（艹）、それに対応するSVSである<code>U+8279 U+FE00</code>（艹︀）、Adobe-Japan1コレクションのIVS<code>U+8279 U+E0101</code>（艹󠄁）、Moji_Joho及びHanyo-DenshiコレクションのIVS<code>U+8279 U+E0103</code>（艹󠄃）

以上の通りこれらは全てAdobe-Japan1コレクションに含まれている字であるため、游明朝などAdobe-Japan1準拠のフォントでは、上記のうち「Moji_Joho及びHanyo-DenshiコレクションのIVS」となっているもの以外は全て正しく表示できるはずである。カッコ内をコピペして試してみるとよい。

謎乃明朝では、現時点では（2フォントに分ける前提で）グリフ数に多少余裕があるので、一応Adobe-Japan1に従ってCID+14197, CID+14198, CID+14199をそれぞれ割り当てているが、Adobe-Japan1準拠のフォントを作るのでなければこうする必要はなく、CID+1から順に漢字で埋めても構わないはず。

その次の3文字は、U+20000（𠀀）の異体字である。Unicodeの20000-2FFFFは「追加漢字面」（SIP）と呼ばれ、日本で普段使われることはない漢字が大半である（「𩸽（ほっけ）」など例外もある）。この範囲の文字を例に含めたのは、BMP外のUnicode文字はサポートが不十分なソフトも多い中で、AFDKOを使えばきちんと対応できる、ということを示すためである。

こちらの割り当ては先ほどよりはずいぶん単純である。GlyphWikiでは、最初のu20000-jvが<code>U+20000</code>と<code>U+20000 U+E0100</code>、次のu20000-ue0101が<code>U+20000 U+E0101</code>、その次のu20000-ue0102が<code>U+20000 U+E0102</code>で使われている（後の2つは名前からして当然であるが）。これらは全てMoji_JohoコレクションのIVS異体字であり、U+20000自体もAdobe-Japan1には含まれていないので、正しく表示するには謎乃明朝、花園明朝あるいはIPAmj明朝などが必要だろう。ここでは一応、Adobe-Japan1のCID（現在23059まで定義されている）と被らないよう、24000以降を割り当てている（もちろんそうする必要はない。）

なお、ここではSVS・IVSに対応したフォントを作成するが、Variation Selectorは特殊文字なので、それ自体にグリフを割り当てる必要はない。

==== 出力 ====

ここまで理解したら、以下のようにコマンドを実際に実行してみよう。

<syntaxhighlight lang="vb.net">$ mergefonts -cid cidfontinfo merged.pfa system.map system.pfa kanjisample.map kanjisample.svg
mergefonts: --- system.pfa
mergefonts: (cfw) unhinted <cid-0>
Adding font dict 0 from system.pfa.
mergefonts: --- kanjisample.svg
mergefonts: (cfw) unhinted <cid-14197>
mergefonts: (cfw) unhinted <cid-14198>
mergefonts: (cfw) unhinted <cid-14199>
mergefonts: (cfw) unhinted <cid-24000>
Adding font dict 1 from kanjisample.svg.
mergefonts: (cfw) There are 2 additional reports of 'unhinted'.

mergefonts: --- merged.pfa
mergefonts: (cfr) /BlueValues missing: FD[1]</syntaxhighlight>
<code>unhinted</code>や<code>/BlueValues missing: FD[1]</code>などとwarning/errorが出ているが、あとでヒントを追加するので無視でよい（多分）（SVGに直接BlueValuesを追加する方法があってもおかしくはないと思うが見つけられなかった）。

生成されたmerged.pfaを再びtxでpdfにしてみると以下のようになる。

<div class="res-img">https://turgenev.cloudfree.jp/mw1/imgs/merged.pdf.jpg</div>

このように、各CIDに意図した字形が割り当てられていることがわかるだろう。しかし、それらのCIDがどの文字に対応するものなのかという情報は全く含まれていないので、これはまだ実際に使用できるフォントではない。

== ヒントの付加 ==

次に、このフォントにヒントを付加する。ヒントというのは、フォントをラスタライズ（実際にピクセルに変換して描画）する際に、線の太さなどを調節して見やすくするための機能であり、特に小さいサイズで表示したときの見た目に大きく影響する。日本語情報はあまりないが、Fontforge関連でいくつか見つけることができる。またBlueValuesやStdHWなど個々の値の仕様に関しては[https://kikakurui.com/x4/X4163-1994-01.html https://kikakurui.com/x4/X4163-1994-01.html]で日本語で読める。個人的にもあまりヒントの動作についてはよくわかっていないので、ここでは最低限のやり方だけ述べる。

ちなみにこの記事では扱わないがAFDKOにはrotatefontというグリフを（ヒント情報含めて）自動で回転させてくれるコマンドがあり、これを使った場合にもその後で改めてpsautohintを実行するのが望ましいようである（参考 :[https://aznote.jakou.com/afdko/anti02.html アンチックフォントを作る: グリフの変形と合成]）。


==== hitcidfont.plを使う ====

{{Valuable}}

ヒントの付加はpsautohintというプログラムで行うが、psautohintが動作するためには、BlueValuesという値だけは最低限手動で設定しなければいけないようである。そこで、[https://github.com/adobe-type-tools/perl-scripts/blob/master/hintcidfont.pl perl-scripts/hintcidfont.pl at master · adobe-type-tools/perl-scripts]を用いて、先ほど生成したmerged.pfaにBlueValues（やその他、必須ではないパラメータ）を付加する。

このスクリプトは（今回であれば）以下のように使用する。

<syntaxhighlight lang="vb.net">hintcidfont.pl hintparam.txt < merged.pfa > merged_out.pfa</syntaxhighlight>
前述の通りpfaフォント（ファイルの先頭がああいう感じのやつ）以外には使えないようである。この<code>hintparam.txt</code>がBlueValuesなどを指定するファイルで、ここで先ほどFDArray要素の名前で使用した<code>System</code>や<code>Ideographs</code>を使用する。

<syntaxhighlight style="margin-bottom:0.2em;" lang="vb.net">System
/BlueValues [-250 -250 1100 1100] def
/StdHW [100] def
/StdVW [100] def

Ideographs
/BlueValues [-100 -200 1100 1100] def
/StdHW [70] def
/StdVW [100] def
/StemSnapH [70 80 60 90 50 40] def
/StemSnapV [80 70 90 60 100 50 110] def</syntaxhighlight>
<div style='text-align: center;'>hintparams.txt</div>

このように、FDArray要素ごとに自動ヒント付けのための情報を付加できる。

前述のようにBlueValuesは最低限必要で、これは確かフォントがラスタ化されるときの最大のバウンディングボックスを指定するものなので、該当のFDArrayに含まれるグリフのバウンディングボックスより大きければ大丈夫だと思う。今回のように1000x1000で漢字のみ入れるような場合は適当に<code>[-250 -250 1100 1100]</code>などとしておけばよいはず。

StdHWとStdVWは水平方向のステムの（垂直方向の）幅と垂直方向のステムの（水平方向の）幅の目安（？）をそれぞれ指定するものである。明朝なら横線のほうが細いということで、ここでは何となくStdHWを70、StdVWを100としているが、効果がどうなのかはよくわかっていない。StemSnapHとStemSnapVは、StdHWとStdVWと似ているが、より細かい精度でガイドラインを設定するような感じのやつである。あまり情報がなくてよくわからないので、かなり適当に設定していて、本当は小さい順に並べる必要があったりするのかもしれない。

まあ言ってしまえば、見た目を追求するなら本来は手動でヒント付けを行うべきである（多分）。他の設定例は[https://ccjktype.fonts.adobe.com/wp-content/uploads/2012/06/afdko-lunde-20120625.pdf https://ccjktype.fonts.adobe.com/wp-content/uploads/2012/06/afdko-lunde-20120625.pdf] なども参照。

上手くいけば、以下のような出力とともにこれらの値が付加されたpfaファイルが生成される。テキストエディタで開いてみると、pfaファイルの上の方に<code>/BlueValues [-250 -250 1100 1100] def</code>などと書きこまれているのがわかる。

<syntaxhighlight lang="vb.net">$ hintcidfont.pl hintparam.txt < merged.pfa > merged_out.pfa
Detected CIDFontName: NazoMin
Modifying System hinting parameters...
Modifying Ideographs hinting parameters...</syntaxhighlight>
ここまでの記事に従っていれば大丈夫かと思うが、何も出なかったらおそらくどこかが間違っているのでpfaファイルの中身やスクリプトのソースを読んでみるなどして確認すること。

==== psautohintの実行 ====

では次にpsautohintを実行する。オプションなどは筆者がよくわかっていないので、今回は以下を実行するだけである。

<syntaxhighlight lang="vb.net">psautohint merged_out.pfa -o hinted.pfa</syntaxhighlight>
今回はグリフ数が少ないのですぐに終わるが、数万グリフあるとなると数分ほどかかる処理である。

手元ではたまに<code>ERROR: cid51649: Possible loop in element that goes from 109 46 to 109 47. Please check.</code>（あるいは稀に<code>ERROR: cid45515: Check for duplicate subpath at 128 758</code>）などと出る字もあるのだが特に見た目は問題無さそうなので無視している。

== makeotfの準備 ==

ここまででグリフのデータは完成したので、実際に使えるフォントにするためのmakeotfの実行に向けて準備を行う。

基本的には、それぞれの文字（Unicode符号位置）でどのCIDを使用するかというCMapが最も重要で、これさえあれば一通り使えるフォントにはなるが、ここでは（先ほど説明した）異体字セレクタも使えるようにSequenceファイルも使用する。OpenType featureに関しては（自分があまりよくわかっていないので）フォントの高さなど最低限の設定のみ行う。他にもGSUB・GPOSをはじめ様々な面白いfeatureがあるので調べてみてほしい。また、フォント名の設定のためFontMenuNameDBというファイルも使用する。

これらについては[https://shiromoji.hatenablog.jp/entry/20111210/1323520587 AFDKO入門《CIDキー方式のOpenTypeフォントの作り方》後篇：makeotf - しろもじメモランダム]も参考になる。また[https://github.com/adobe-fonts/source-han-sans https://github.com/adobe-fonts/source-han-sans]や[https://github.com/adobe-type-tools/Adobe-Japan1 https://github.com/adobe-type-tools/Adobe-Japan1]にも例がある。


==== FontMenuNameDB ====

<syntaxhighlight style="margin-bottom:0.2em;" lang="vb.net">[NazoMin]
f=NazonoMincho
s=Regular
l=NazonoMincho Regular

f=3,1,0x411,\8B0E\4E43\660E\671D
s=3,1,0x411,Regular
l=3,1,0x411,\8B0E\4E43\660E\671D Regular

f=1,1,11,\93\E4\94\54\96\BE\92\A9
s=1,1,11,Regular
l=1,1,11,\93\E4\94\54\96\BE\92\A9 Regular</syntaxhighlight>
<div style='text-align: center;'>FontMenuNameDB</div>

このように、先ほど使用したPostScript名である<code>NazoMin</code>を先頭に書き、フォント名を設定する。

<code>\8B0E\4E43\660E\671D</code>と<code>\93\E4\94\54\96\BE\92\A9</code>はそれぞれWinとMacのエンコーディングで「謎乃明朝」を表す。少なくともWindowsに関しては、UTF-16のサロゲートペアを用いればBMP外文字でも指定できるようである（例えば先ほどのU+20000なら<code>\D840\DC00</code>）が、やめておいた方が無難だろう。


==== CMap ====

CMapは、各UnicodeのためにどのCIDを使用するかを指定するもので、フォントの根幹部分を決める重要なファイルである。日本語の「、。」のような縦と横で字形（位置）が異なる文字のために縦書き用CMapが必要なこともあるが、今回は漢字だけなので、とりあえず横書きだけ指定しておけばあとはmakeotfがやってくれる。

<syntaxhighlight style="margin-bottom:0.2em;" lang="vb.net">%!PS-Adobe-3.0 Resource-CMap
%%DocumentNeededResources: ProcSet (CIDInit)
%%IncludeResource: ProcSet (CIDInit)
%%BeginResource: CMap (NazoMinCMAP-UTF32-H)
%%Title: (NazoMinCMAP-UTF32-H Adobe Identity 0)
%%Version: 2.004
%%Copyright: -----------------------------------------------------------
%%Copyright: (省略)
%%Copyright: -----------------------------------------------------------
%%EndComments

/CIDInit /ProcSet findresource begin

12 dict begin

begincmap

/CIDSystemInfo 3 dict dup begin
/Registry (Adobe) def
/Ordering (Identity) def
/Supplement 0 def
end def

/CMapName /NazoMinCMAP-UTF32-H def
/CMapVersion 2.004 def
/CMapType 1 def

/WMode 0 def

1 begincodespacerange
<00000000> <0010FFFF>
endcodespacerange

1 beginnotdefrange
<00000000> <0000001f> 1
endnotdefrange

6 begincidchar
<00000020> 1
<00003000> 633
<00008279> 14197
<0000fa5d> 14199
<0000fa5e> 14198
<00020000> 24000
endcidchar

1 begincidrange
<00002ebe> <00002ec0> 14197
endcidrange

endcmap
CMapName currentdict /CMap defineresource pop
end
end

%%EndResource
%%EOF</syntaxhighlight>
<div style='text-align: center;'>NazoMinCMAP-UTF32-H</div>

このような感じで、unicode位置（このファイルはUTF32版である）からCIDへの対応関係を記述する。

なお、begincidrangeはbegincidcharがCID・Unicode位置ともに連続しているときに楽に指定するためのものである。また、begincidcharやbegincidrangeによる1つのブロックまでには最大100個（上記では1や6になっている）までしか情報を入れられない。従って、機械的にCMapを生成するときは、以下のように全て<code>1 begincidchar ... endcidchar</code>で指定してしまうのが楽である。

<syntaxhighlight lang="vb.net">...
1 begincidchar
<00008279> 14197
endcidchar
1 begincidchar
<00002ebe> 14197
endcidchar
...</syntaxhighlight>
その上で、サイズを削減したいときは、[https://github.com/adobe-type-tools/perl-scripts/blob/master/cmap-tool.pl perl-scripts/cmap-tool.pl at master · adobe-type-tools/perl-scripts]を使うと良い感じにbegincidrangeにした上で100個ずつにまとめてくれる。


==== Sequenceファイル ====

今回は以下のものを使用する。先ほど解説した通りに「CJK統合漢字+異体字セレクタ」の組が該当CIDを参照していることを確認せよ。

ちなみに、異体字セレクタが付けられている元の字（以下ならU+8279とU+20000）自体がフォントに含まれていないとたしか異体字も使えないはずなのでそこは注意。

<syntaxhighlight style="margin-bottom:0.2em;" lang="vb.net">8279 E0100; AJ1; CID+14197
8279 E0105; AJ1; CID+14197
8279 E0104; AJ1; CID+14198
8279 FE01; AJ1; CID+14198
8279 E0102; AJ1; CID+14198
8279 E0101; AJ1; CID+14199
8279 E0103; AJ1; CID+14199
8279 FE00; AJ1; CID+14199
20000 E0100; AJ1; CID+24000
20000 E0101; AJ1; CID+24001
20000 E0102; AJ1; CID+24002</syntaxhighlight>
<div style='text-align: center;'>sequences.txt</div>

このファイル形式はAFDKOやOpenTypeフォント自体に由来するものであるというよりは多分Unicodeの[https://www.unicode.org/ivd/data/ IVD]に含まれるSequenceファイルに由来するものであるように思われる。SourceHanSansやAdobe-Japan1のリポジトリにある例ではそれに従って中央の列に<code>Adobe-Japan1</code>や<code>Standardized_Variants</code>などと律儀に書いてあるが、AFDKOが読むのは実際には第1のシーケンスと第3列のCID番号だけと思われるので、このように適当に<code>AJ1</code>などと書いてファイル容量をケチっておいても問題はなさそうだった。

==== featureファイル ====

このファイルによって完成品のフォント名などが決められる。

ほぼ[https://shiromoji.hatenablog.jp/entry/20111210/1323520587 AFDKO入門《CIDキー方式のOpenTypeフォントの作り方》後篇：makeotf - しろもじメモランダム]を参考に、最低限の内容だけ入れている。

<syntaxhighlight style="margin-bottom:0.2em;" lang="vb.net">table head {
FontRevision 0.004;
} head;

table hhea {
CaretOffset 0;
Ascender 880;
Descender -120;
LineGap 1000;
} hhea;

table OS/2 {
FSType 0;
Panose 2 # Latin, Text
11 # Normal Sans
4 # Thin
9 # Monospaced
0 0 0 0 0 0; # Any
UnicodeRange
0 1 2 5 6 7 9
31
32 33 34 35 36 37 38 39
42 43 44 45 46 47
48
49 # Hiragana
50 # Katakana
54 55 57
59 # CJK Unified Ideographs
61 # CJK Strokes, CJK Compatibility Ideographs (Supplement)
65 68
91 # Variation Selectors
;
CodePageRange
1252 # Latin 1
1250 # Latin 2
932 # JIS/Japan
936 # Chinese: Simplified chars—PRC and Singapore
949 # Korean Wansung
950 # Chinese: Traditional chars—Taiwan and Hong Kong
1361 # Korean Johab
;
TypoAscender 880;
TypoDescender -120;
TypoLineGap 1000;
winAscent 1000;
winDescent 100;
XHeight 0;
CapHeight 0;
WeightClass 400;
WidthClass 5; # Full width
Vendor "YHVH";
} OS/2;

table vhea {
VertTypoAscender 500;
VertTypoDescender -500;
VertTypoLineGap 1000;
} vhea;

feature vrt2 {
sub \1 by \8720;
} vrt2;

feature vert {
sub \1 by \8720;
} vert;</syntaxhighlight>
<div style='text-align: center;'>features</div>

詳しくは他サイトに譲る。Ascender/Descenderによりフォントの高さ・深さを指定している（880-(-120)でちょうど1000になっていることを確認せよ）。winAscentとwinDescentはWindows限定のようだが、少なくともこれを変えると手元ではWordでのフォント高さが変わるので重要そうである（この設定例はかなり小さめである）。FontRevisionは好きに設定してよい。わからないときは、ttx（txではない）で既存フォントのテーブルを見てみるのもよいだろう。

UnicodeRangeやCodePageRangeは、フォントがどのような言語・文字集合に対応しているかの参考にされるのだと思うが、少なくともフォント名を自分で指定してこのフォントを使う分にはあまり影響しない部分かと思われる。<s>実際には一文字も収録していないUnicode範囲をこんな大量に指定するのはやめた方がよさそうである。</s>

vrt2の部分は前述の[http://web.archive.org/web/20130225051414/http://d.hatena.ne.jp/mashabow/20120306/1331028598 花園明朝OTを0.510に更新、IVD 2012-03-02版に対応 - しろもじメモランダム]を参考にしたものである。vertは勝手に同じ内容でつけてみた。

== makeotfの実行 ==

ここまでできたら

<syntaxhighlight lang="vb.net">makeotf -f hinted.pfa -ff features -o final.otf -ch NazoMinCMAP-UTF32-H -ci sequences.txt -mf FontMenuNameDB</syntaxhighlight>
としてフォントをビルドしてみよう。なお、<code>FontMenuNameDB</code>と<code>features</code>はそれぞれAFDKOが探すデフォルトの名前なので、別の名前を使わない限りは指定しなくてもよい。<code>Built development mode font "…./final.otf"</code>などと出ればめでたく成功である。ちなみに-rオプションを付けるとreleaseモードになり、”Built release mode font”と出る。多少時間がかかるもののサイズが減るなどする。

あとはインストールしてちゃんと文字が出るか確かめればよい。Wordで確かめているとインストール直後はフォントの色々な情報（特に高さなど）がうまく読み込まれない場合があるので、何かおかしいと思ったらOffice系のソフトを一旦全て終了するなどしてからまた起動するのがよい。


== TrueTypeへの変換 ==

AFDKOが生成するのはPostScriptアウトラインのOpenTypeフォントであるから、曲線データには3次ベジェ曲線が用いられる。TrueTypeでは2次ベジェ曲線しか使えないので、3次ベジェ曲線→2次ベジェ曲線の変換が必要である。これは自明な変換ではなく近似が必要であるが、AFDKOにはこれをやってくれるotf2ttfというコマンドがある。シンプルに<code>otf2ttf final.otf</code>とすれば<code>final.ttf</code>というTrueTypeフォントが出力される。

== その他参考 ==

その他、フォントに関連する記事としては、[[Webブラウザ（Chrome）|Webブラウザ（Chrome）]]と[[Wordの「検索と置換」について|Wordの「検索と置換」について]]も参考になるだろう。


== CSSで謎乃明朝 ==

IVSなどがあるので（body:{}などに書く）font-family:のところではNazoMinを先に指定すること。

<syntaxhighlight lang="css">@font-face {
font-family: "NazoMin";
src: local("謎乃明朝 Regular");
unicode-range: U+3400-U+4DFF, U+2F800-2FFFF, U+30000-3FFFF;
}

@font-face {
font-family: "NazoMin+";
src: local("謎乃明朝+ Regular");
unicode-range: U+20000-2F7FF;
}</syntaxhighlight>
[[Category:IT]]{{#seo:|title={{FULLPAGENAME}} - Turgenev's Wiki}}

Windowsでのターミナル環境

2025-04-02T08:37:48Z

Turgenev: Notion-MW

WindowsはLinuxに比べるとライトユーザー向けのOSで、端末エミュレータで文字を打ってコマンドを実行するというCUIのスタイルで使いやすいようにデザインされているとは言い難い。それでも、ある程度工夫すれば不満点を改善することはできる。


== C:\Users\USERNAME\.pathにPATHを通す ==

ユーザーフォルダ（C:\Users\USERNAME）の直下などわかりやすいところに.path（もちろん名前は好きに決めてよい）というフォルダを作り、これをユーザー環境変数のPATH（の先頭がいいかな？）に追加しておく（他ユーザーから見えないフォルダなのでシステム環境変数に追加するのは不適切）。するとPATHをいちいち書き換えなくてもこの中に入れた実行ファイルやバッチファイルはファイル名だけで呼び出せる状態になる。

これは、インストール不要（圧縮ファイル解凍のみ）、あるいはPATHを自動で通さないようなソフトウェアを使いやすくするのに有用である。実行ファイル単体で動作するならファイルを直接入れてもいいし、依存ファイルがあるなら本体の位置はそのままでそれを呼び出すプログラムを入れればいい（バッチファイルでもいいが、欠点がある。詳しくは後述）。

筆者はrclone（ファイル同期ソフト）やmpv（メディアプレイヤー）などをこの.path経由で起動できるようにしている。またLinuxでも同様の設定をしている。

== 他のコマンドを呼び出すプログラム ==

前項の目的を達するため、「自身に渡されたコマンドライン引数を（場合により多少の処理をした上で）ほぼそのまま使って他のコマンドを実行する」ようなプログラムを作成した。

[https://github.com/ge9/win-console-delegator https://github.com/ge9/win-console-delegator]

このプログラムは、「自分自身のファイル名の最後の文字と最後から3番目の文字を<code>t</code>に変更したファイル（主にexe→txtを想定しているが、com→totなどでもよい）を読み込み、その内容と自分に与えられたコマンドライン引数をつなげた文字列をコマンドとして実行する」という挙動をする。すなわち、実行ファイルは（コンパイルし直さず）そのままコピーした上で、ペアとなる.txtファイルに適切な内容を書くことで、以下のようなプログラムが実現できる。

==== 他のプログラムをそのまま実行 ====

たとえばテキストファイルに以下のように書いておけば、mpvが起動される。末尾の半角スペースも入れること。

<syntaxhighlight lang="vb.net">"C:\Users\username\Softwares\mpv\mpv.exe"</syntaxhighlight>
Windows版のmpvは、設定ファイル（mpv.conf）やプラグインなどを自身が存在するディレクトリから読み込むが、それらの動作を維持したままで、.pathにはmpv.exeという呼び出し専用のファイルだけを配置することができる。

==== 指定フォルダにあるプログラムを実行 ====

<code>myprogram somecommand arg1 arg2 ...</code>と呼び出されたときに、<code>C:\path\to\somecommand arg1 arg2 ...</code>をかわりに実行したい、ということがある。例えば複数の実行ファイルがまとまって提供されるような場合である。このときは以下のようなmycommand.txtをペアにすればよい。この場合はパスを直接引数につなげるため、末尾に半角スペースを入れてはいけない。

<syntaxhighlight lang="python">C:\path\to\</syntaxhighlight>
ところで、<code>C:\path\to\</code>の部分に空白文字が含まれている場合、このままではパスが正しく認識されない。通常はパス全体をダブルクォーテーションで囲うことでこれを回避するが、今回は与えられた引数のどこにダブルクォーテーションを挿入するかが自明ではない（<code>myprogram someprogram"</code>と入力させるという方法もあるが美しくない）ため、半角スペースを含まない別名（8.3形式）を使うのがよいだろう（短い名前については[[Windowsのパス長さ制限に関して|Windowsのパス長さ制限に関して]]も参照）。例えばProgram Filesなら普通は「PROGRA~1」になっているはずである。以下はGit Bashでのtxtファイルの例である。

<syntaxhighlight lang="vb.net">C:\PROGRA~1\Git\usr\bin\</syntaxhighlight>
これにより、PATHを変更せずとも、例えば<code>gb grep</code>などとするだけでGit Bashの<code>grep</code>を呼び出すことができるようになる。gitやnpmやbusyboxやmagick（ImageMagick）のようにサブコマンドを指定して使うプログラムは多くあるが、これと同じような使用感になる。プレフィックスを設けることでそれぞれの名前の集合を別々に管理して衝突を防ぐ、という意味では、多くのプログラム言語で採用されている名前空間（namespace）に近い発想かもしれない。（コマンドにおけるこのような手法に特に名前は付いていないと思う。）

==== pathなどの環境変数を変更して実行 ====

上記と若干似ているが、PATHをはじめとした環境変数を変えることでプログラムがうまく実行されるようにしたい、という場合もある。この場合は、テキストファイルを以下のようにすればよい（Git Bashのフォルダをパスに追加し、<code>MYVAR</code>に<code>value1</code>をセットする例）。末尾の半角スペースはあってもなくてもいい。

<syntaxhighlight lang="bash">cmd /c path C:\Program Files\Git\usr\bin;%PATH% & set MYVAR=value1 &</syntaxhighlight>
こちらは、先ほどと違って、内部でGit Bashのコマンドを使用する（Git Bashとは無関係な）プログラムを実行する際などに有用である。

また、これに類似のケースとして、環境変数の設定などを行うバッチファイルが既に用意されていてそれを使いたいという場合もある。例えば以下のようなテキストファイルを用いれば、実質的にVisual Studioの開発者コマンドプロンプト（Developer Command Prompt for VS 2022）の内部で与えられたコマンドを実行してくれるプログラムが作れる。

<syntaxhighlight lang="python">cmd /c C:\PROGRA~1\MIB055~1\2022\Community\Common7\Tools\VsDevCmd.bat &</syntaxhighlight>
* ここでも短いパスを使用している。長いパスでも引用符で囲めばある程度うまく動作するが、<code>&</code>の後にくるコマンドに引用符が含まれている場合にうまくいかない。

Linuxでも、例えば特定のvenv仮想環境の中で与えられたコマンドを実行するシェルスクリプトを全く同じ発想で作ることができる。

=== 実装について ===

* 言語はC++を使った。これはWindows APIのGetCommandLineから生のコマンドライン文字列が得られるからである。予め分割されたコマンドラインでは情報量が減ってしまう。WinMainが使えればlpCmdLineで楽にできたが、今回はコンソールアプリケーションで実装したかったので、[https://stackoverflow.com/questions/14150374/how-to-get-the-raw-command-line-arguments c++ - How to get the raw command line arguments - Stack Overflow]のようにして自身のファイルパスだけ取り除いた。
* コンソールイベント（Ctrl+Cなど）の転送に関しては、CreateProcessにCREATE_NEW_PROCESS_GROUPを指定した上で、SetConsoleCtrlHandlerによって全てのコンソールイベントを転送する方式とした。CREATE_NEW_PROCESS_GROUPを指定しない場合よりもこのほうが安定して動いている気がする。
* cmdの対話シェルには、実行するアプリケーションがコンソールアプリケーションではなくGUIアプリケーションである場合は実行終了を待たずに即座に制御を返すという仕様がある。これを模倣するため、自作プログラムにはGUIアプリケーションにしたバージョンも同梱している。

=== batとの比較 ===

上記の例は、いずれもバッチファイルを使って似たようなことが実現できる。例えばGit Bashならそれぞれ

<syntaxhighlight lang="prolog">@C:\path\to\directory\%*</syntaxhighlight>
や

<syntaxhighlight lang="vb.net">@cmd /c "path C:\path\to\directory;%PATH% & %*"</syntaxhighlight>
のようにする（<code>@</code>は、echo offを一時的に行うために必要である）。

しかし、cmd.exeには、バッチファイルの実行中にCtrl+Cを送信すると「バッチジョブを終了しますか (Y/N)?」というプロンプトを表示するという厄介な仕様がある。また、<code>%</code>で挟まれた環境変数（<code>%PATH%</code>など）が文字列として含まれていた場合に展開されてしまう。そのため、先ほどの自作プログラムを使用するほうがスマートである。


== Cygwin, MSYS/MinGW, Git Bashの違い ==

これらはいずれもWindows上でUnixライクなコマンドライン環境を整備してくれるツールだが、違いもある。

個人的な印象としては

* Cygwinは起動に若干タイムラグがあるが、最も信頼できる動作をするので、例えばシェルスクリプトを実行させるときなどはまずCygwinで試した方がいい。
* MSYS系は、C++でWindows向けに何かをコンパイルしたい時に使う。
* Git Bashは、最も手軽だが、Cygwinに比べると意外とWindowsとの互換性というか、動作が怪しいことがある。
** Git Bashからだと、cmdを起動したときに入力カーソルの位置がおかしい、Windowsのアプリケーションに<code>/</code>を引数として渡したいときは<code>//</code>と書かなければいけない、xargsの並列実行の挙動がおかしい（[https://github.com/ge9/ExecuteCommand-Pipe/issues/3 With "h" option, ][https://github.com/ge9/ExecuteCommand-Pipe/issues/3 <code>xargs -n1</code>][https://github.com/ge9/ExecuteCommand-Pipe/issues/3 creates only one process · Issue #3 · ge9/ExecuteCommand-Pipe]）という例があった。

==== 参考サイト ====

<ul>
<li>[https://www.glamenv-septzen.net/view/1422 https://www.glamenv-septzen.net/view/1422]これを見た限り（2017年のやつだけど）、MSYS2って意外と大したことなくない？という。</li>
<li>呼び方の違いがわかりやすい表[https://gist.github.com/rz7d/4e699498d339a5837f016b3108631a2b https://gist.github.com/rz7d/4e699498d339a5837f016b3108631a2b]</li>
<li>[https://opcdiary.net/%E6%B7%B7%E3%81%9C%E3%82%8B%E3%81%AA%E5%8D%B1%E9%99%BA-msys2%E3%81%A8cygwin%E3%81%A8git-for-windows%E3%82%92%E4%B8%80%E7%B7%92%E3%81%AB%E4%BD%BF%E3%81%A3%E3%81%A6%E3%81%AF%E3%81%84%E3%81%91%E3%81%BE/ 混ぜるな危険 (msys2とCygwinとGit For Windowsを一緒に使ってはいけません) | OPCDiary]
<ul>
<li>これがあるので、当サイトのように呼び出し用のコマンドを整備するのが割とおすすめ。</li></ul>
</li>
<li>[https://sites.google.com/site/toriaezuzakki/msys2?tmpl=%2Fsystem%2Fapp%2Ftemplates%2Fprint%2F https://sites.google.com/site/toriaezuzakki/msys2?tmpl=%2Fsystem%2Fapp%2Ftemplates%2Fprint%2F]
<ul>
<li>MSYS2をインストールしたときに出る複数のシェルはパスの設定が違う（だけ？）らしい:
「これらの違いはパスの設定です。MSYS2 Shellを基本として、MinGW-w64 Win32 Shellはそれに/mingw32/binが追加されており、MinGW-w64 Win64 Shellは/mingw64/binが追加されています。」</li>
<li>詳しくは、「msys2_shell.cmd」を読んでみると良さそうである。MSYSTEM環境変数というのが重要そう。</li></ul>
</li>
<li>[https://m-hiyama.hatenablog.com/entry/20151013/1444704189 Mingw-w64/MSYS2 を入れなくても Git for Windows で間に合うみたい - 檜山正幸のキマイラ飼育記 (はてなBlog)] Git BashはMinGW/MSYSベースなので、そちらと同様に、MSYSTEM環境変数を<code>MINGW64</code>に設定すると/mingw64/binがパスに入る。ここにはgit.exeが入っているが、git.exe自体は実は/cmdに入っているので、そのことによる実効的な違いはあまりない。ということらしい。
<ul>
<li>ただgit以外にもxzコマンドとか/mingw64/binにしかないものもいくつかあるので、違いが全くないわけでもない。（なぜxzがこっちに入っているんだろう？）</li>
<li>MSYSTEMに何も設定せずusr/binにあるbashに<code>--login</code>を付けて実行したところ、MSYSTEMはMSYSに設定され、パスには/mingw64/binがないかわりに/opt/binが追加されている。しかし実際には/optフォルダはGit Bashのインストール時には存在しておらず、無意味である。</li></ul>
</li></ul>

== アプリ実行エイリアスの扱い ==

wt.exeやmspaint.exeなどストアアプリ系の実行ファイルは「アプリ実行エイリアス」というやや特殊な仕組みで管理されており（例えばエクスプローラーで見るとこれらのファイルサイズは0バイトである）、Cygwin系と相性が悪い。Git BashではPermission Deniedでこれらのファイルの実行ができないという問題があった。最新リリースでは修正されている。

[https://github.com/git-for-windows/git/issues/2675 Permission Error on all App Execution Aliases in git-bash · Issue #2675 · git-for-windows/git]

Cygwinでは、実行は問題ないがwhich wtとすると見つからないと言われる（Git Bashでは大丈夫そう）（2023/08時点）。


== Cygwinのforkに関するエラーを直す ==

setupを再実行してバイナリがアップデートされた後に、以下のようなエラーが頻発するようになることがある。毎回出るわけではなく、確率的に生じるので厄介である。

<syntaxhighlight lang="shell">child -1 – forked process 9272 died unexpectedly, retry 0, exit code 0xC0000142, errno 11</syntaxhighlight>
<syntaxhighlight lang="shell">40 [main] bash 3348 fork: child -1 - forked process 4248 died unexpectedly, retry 0, exit code -1073741819, errno 11</syntaxhighlight>
解決方法はいくつかある（単に再起動などで治る場合もある？）らしいが、自分の場合は以下のようにrebaseallというのをやることで治った。

[https://stackoverflow.com/questions/9300722/cygwin-error-bash-fork-retry-resource-temporarily-unavailable/14509551#14509551 Cygwin error: "-bash: fork: retry: Resource temporarily unavailable" - Stack Overflow]（元記事は[https://cygwin.fandom.com/wiki/Rebaseall https://cygwin.fandom.com/wiki/Rebaseall]らしい）

ここには<code>rebaseall -v</code>と書いてあるが、手元ではそのようなオプションがなさそうだったので単純にrebaseallとしたら、それでうまく行ったようである。

<ul>
<li>まとめると、手順は以下。
<ul>
<li>Cygwin関連のプロセスをすべて終了させる。</li>
<li>/usr/binにあるdash.exeを管理者権限で起動させる（おそらく軽量で依存関係が少ないから？）</li>
<li><code>./rebaseall</code>を実行</li></ul>
</li>
<li>他には以下のようにWindowsのセキュリティ設定をいじる方法もあるようだが、ちょっと不安。
[https://oni-gili.org/archives/290 https://oni-gili.org/archives/290]
[https://umateku.com/archives/462 https://umateku.com/archives/462]</li></ul>


== Cygwinでcmdに<code>"</code>を出力させる ==

[https://cygwin.com/pipermail/cygwin/2020-June/245226.html change in handling quotes in cygwin package from 3.1.4-1 to 3.1.5-1]にある通り、Cygwinでcmd（を含むWindowsネイティブのプログラム？）にダブルクォーテーション単体（あるいはダブルクォーテーションを途中に含む任意の文字列など）を渡すのは難しい（難しくなった？）。環境変数に<code>"</code>を入れておいて渡すという手はあるが、衝突する可能性も考えられる。一番確実なのは、与えられた引数に含まれる指定された文字列を全て<code>"</code>に置き換えて実行するようなプログラムを別途書くことだろう（気が向いたらやるかも）。

* [https://twitter.com/e9g/status/1660590434429865984 https://twitter.com/e9g/status/1660590434429865984]も参照。


== Git Bash/Cygwinなどでbatやvbsを拡張子無しで呼ぶ ==

Windows上では、実行ファイルの拡張子（の主流）である.exe以外にもバッチファイル（.bat）やVBScript（.vbs）などが環境変数<code>PATHEXT</code>に登録され、拡張子無しで呼び出すことができる。しかし、Git Bash/Cygwinでは、exeのみが省略でき、他は明示的に付けないと呼び出せない。これは[https://qiita.com/snipsnipsnip/items/03b3bb9149954cb44bea Git Bashで.batや.lnkを使うとき拡張子を省く - Qiita]のようにbash側で設定すると解決できる（が、あまり綺麗な方法とはいえない気がする）（なおCygwinでは未確認）。また、よく使う操作をコマンド一発で呼び出したい時は、batではなくシェルスクリプトや前述のようにexeファイルを使う手もある。


== conhost.exeで文字選択中に出力がブロックされる ==

Windows コンソールホスト（conhost.exe）というのは、Windowsで従来ずっと使われてきたターミナルのことであり、この上でコマンドプロンプト（cmd.exe）やPowerShellやその他のコンソールアプリケーションが動く。conhost.exeに代わるものとして最近出てきたのがWindows Terminal（wt.exe）である。

この2つは以下の画像の通り、概ね見た目で区別できる。（Windows11以降でWindows Terminalをデフォルトにする機能が追加されるようであるが、そうしていない場合は、）cmdやPowerShell、あるいはpythonやnode.jsなどの対話コンソールを普通に開いた際にはこの上側のような感じのウインドウが表示されるはずである。

<div class="res-img">https://turgenev.cloudfree.jp/mw1/imgs/conhost.jpg</div>

<div style='text-align: center;'>conhost.exeの見た目</div>

<div class="res-img">https://turgenev.cloudfree.jp/mw1/imgs/wt.jpg</div>

<div style='text-align: center;'>Windows Terminalの見た目</div>

しかし、あまり知られていないようだが、このconhost.exeには「文字を選択した状態（ウインドウタイトルに「選択」と出る）だと一切の出力がブロックされる」という仕様があるようである（文字選択を容易にするため？参考: [https://github.com/microsoft/terminal/issues/34 https://github.com/microsoft/terminal/issues/34]）。例えば<code>ping -t localhost</code>を実行して文字を選択してみるといいだろう。方向キーや文字を入力するなどして選択状態を解除すると出力は再開する。

この仕様により、[https://stackoverflow.com/questions/8140804/how-can-i-stop-my-server-from-freezing-when-powershell-is-in-select-mode ruby on rails - how can I stop my server from freezing when powershell is in 'select' mode? - Stack Overflow] などにあるように、サーバーアプリケーションの実行が出力の際に意図せずブロックされるといった問題が起こる（筆者は[[error_private_page|error_private_page]]のサーバーを使っている際にこの問題に気付いた）。また、詳しい条件はわからないが、筆者の経験では、単にそのコンソールウインドウを長時間使わず放置するだけでも同じ現象が発生することがあり、文字選択をしないように気を付けるだけでは不十分なようである。

解決策としては、conhost.exe以外のターミナルを使えばよい。比較的新しいWindowsであればWindows Terminal、それが無理ならCygwinやGit Bashのターミナル（mintty.exeだっけ？）などでもよい（ただGit BashはCygwinと比べてWindowsアプリケーションとの互換性が微妙な気もする。例えばcmd.exeを開いて方向キーを押すと不自然な動作をする）。また、あくまでブロックされるのは出力に際してであるため、<code>> nul</code>などで出力を全て捨てればブロックはされない（ただしそれでは不便という場合も多いだろう）。

== cmd ==

あまり知られていないが、cmdでもbashなどと同じように<code>PROMPT</code>変数にエスケープ文字を入れることでプロンプト（<code>C:\Users></code>みたいなやつ）の色やスタイル（太字など）を変えられる。

[https://qiita.com/nanagami1369/items/9f6894b0759f74519f1e コマンドプロンプトのプロンプトに色をつける方法 - Qiita]

[https://chiyosuke.blogspot.com/2018/05/blog-post_7.html ちよぶろ。: コマンドプロンプトの色を変える。]

ただしVista以降～Windows 10の途中（1607より前？）ではcmd+conhostという組み合わせ（といっても多分cmdを使うとしたら事実上conhostが必要となる）だとエスケープ文字がそのまま表示されてしまい色がつかない。これは[https://github.com/adoxa/ansicon ansicon]で解決できる。

* 参考: [https://qiita.com/TsuneoNakanishi/items/a86f52a406b99d202c06 WindowsコマンドプロンプトでのANSIエスケープシーケンスの使用 - Qiita]など


== Windows Terminal ==

プロファイルを自分で追加できるなどの仕様は、Windowsにしてはなかなか偉い感じがする。

フォントは、GUIからではなく設定ファイルを変更する必要はあるが、変えられる。デフォルトのCascadia CodeよりConsolasのほうが英数字が日本語のちょうど半分のサイズになるので読みやすい。

<syntaxhighlight style="margin-bottom:0.2em;" lang="vb.net">"defaults": {
"font":{ "face": "Consolas",
"size": 12
}
},</syntaxhighlight>
<div style='text-align: center;'>設定例</div>

CSSのように複数のフォントを指定することはまだできないようである。[https://github.com/microsoft/terminal/issues/2664 https://github.com/microsoft/terminal/issues/2664] まあこれはしょうがないだろう。

== コマンドライン引数をめぐる仕様 ==

{{UnderConstruction|Windowsでのターミナル環境}}
[[Category:IT]][[Category:Windows]]{{#seo:|title={{FULLPAGENAME}} - Turgenev's Wiki}}

Zotero

2025-04-02T08:37:44Z

Turgenev: Notion-MW

文献管理ソフト。Firefox界隈由来のOSSで、割と自由に何でも設定できるので、そういうのが好きな人にはおすすめ。

== 初期設定 ==

Zoteroが提供するストレージは300MBとかしかないので外部のクラウドストレージで論文ファイルを管理するのがおすすめ。これに関しては [https://note.com/sdeso/n/n013952313c1b 【令和最新版】文献管理ソフト Zoteroのすゝめ｜SD｜note] が大変詳しく、これでほぼ十分であるが、いくつか追加しておく。

* Zotero自体がもともとFirefoxのアドオンに由来している関係で、Zoteroの拡張機能の拡張子.xpiはFirefoxのアドオンのものと同一であるため、FirefoxからZoteroの拡張機能をダウンロードしようとしてクリックすると（アドオンと混同されて）「ファイルが壊れています」などと出ることがある。なので右クリックから保存を選ぶ。
* ファイルの自動命名は日本人だと苗字がLast Nameと判断されてしまうなど微妙であったが、うまく直せなさそうなのでデフォルト設定のままでよさそう。
* コレクションごとにフォルダ分けしたい場合は、”Use subfolder defined by”を\%c(linuxでもこれで大丈夫だが/%cでもよい)にする（この場合は、複数のコレクションに属するアイテムが発生しないよう気を付ける）。参考:[https://dr-kayai.hatenablog.com/entry/2020/02/09/234427 Zoteroの使い方（我流、逐次更新） - Bag of ML Words]など

=== ブラウザ拡張の使い方など ===

ブラウザ拡張はZotero起動時のみ使える。Zoteroのウインドウで論文を入れたい対象のコレクションを開いておいてからブラウザで拡張機能アイコンをクリックするとそこに入れてくれる。普通に左クリックしたときにEmbedded Metadataを使用しろみたいなエラーがでることがあるので、そういうときは右クリックしてそれっぽいのを選ぶ。

ブラウザ拡張を経由せずに（ローカルにあるpdfを）入れるときは、ZoteroのウインドウにD&D（このとき元の場所にファイルを残しておく必要がなければshiftを押せば削除される（移動になる））して取り込む。日本語論文などで文献情報がうまく読まれない場合は、Manual Entryを作成するしかない場合もあるが、J-STAGEなどから取ってきたものであれば、改めてWebでその論文を探してブラウザ拡張で入れるとうまくいくこともある（pdfエディタで注釈などを記入済みならファイルだけ後で差し替えればよい）。

ブラウザ拡張を経由しない場合、ZotFileのフォルダ内の適切なコレクションには分類されないので、適宜アイテムを選択してRename Attachmentsをする必要がある。なお（最初のサイトで推奨されている通り）”サブコレクションからアイテムを表示”がonだと特定コレクションの中身（サブコレクション内部を含め）すべてに対してRename Attachmentできて便利だが、実はonでしなくてもマイ・ライブラリを押したときは全アイテムが表示されるのでそれで十分だと思う（あと、サブコレクションから表示されてるアイテムを別コレクションに移動しようとしても正しく元の場所から削除されずコピー扱いになってしまうデメリットもこれで解決できる）。なお、前述のようにクラウドストレージのフォルダをLocation of Filesに指定して同期している場合、Rename Attachmentsすることで初めてファイルが同期されることになるので、できるだけ早めにやっておくべし。

また、Zotero内のゴミ箱に移動してもファイルは自動で移動されないし、完全に削除してもファイルは消えない。今のところの筆者の運用としては、一旦DELETEという名前のコレクションに移動してからRename and moveを実行し、適宜ゴミ箱に移動して（アイテムを）削除し、DELETEフォルダの中身も定期的に削除する、とやっている。

== dateデータのフォーマットについて ==

Zotero Connectorはサイトやpdfから論文の投稿（掲載？）日時を自動で取得してくれるが、結果の文字列はブラウザ本体の言語設定によって変わる。具体的には、日本語であれば「4月 22 , 2011」、英語であれば「April 22, 2011」のようになる。なお、そもそも日付が取得できず年と月だけあるいは年だけの論文、また日付まで取れても「2011-04-22」のような書式になる論文もあり、これはどのサイトから取得するかなどによって異なるとみられるが詳細不明。

本来はこんな言語依存の単一文字列ではなく年、月、日それぞれ明示的に別のデータとして管理するのが筋だろう。実際、この仕様のせいで、Better BibTeXの使用時に問題が発生していた（後述）。


== [https://retorque.re/zotero-better-bibtex/ Better BibTeX for Zotero] ==

まずは普通に[https://retorque.re/zotero-better-bibtex/ Better BibTeX for Zotero]からxpiをインストール、再起動すると再びdrag-and-dropを有効にするため再起動しろと言われるので再起動する。Citation keyが追加されている。設定はZotfileのような別メニューではなくZoteroの設定画面に追加されている。[https://qiita.com/skrb_hs/items/73061b7a8e39f1e73e0d Zotero+BibTeXで参考文献の出力を自動化&論文の引用で出てきた順にソートする]の通り、export→fieldsのfields to omit from exportにabstract,file,doiと書く。[https://plaza.umin.ac.jp/shoei05/wp/index.php/2020/10/31/206/ Zotero で citation keys を設定する ( zotero-better-bibtex ) - shoei05]の通りCitation keysを[auth:lower][year][shorttitle1_1]に変更する。

Citation keyは「情報」タブに表示されているほか、メイン画面に表示することもできる。また検索でも使える（これは設定で無効にできる）


==== 日本語文献のCitation Keyについて ====

[https://qiita.com/shiro_takeda/items/dfb857e69aa8ed2cc977 https://qiita.com/shiro_takeda/items/dfb857e69aa8ed2cc977]


==== yearデータの不具合(6.7.60で修正済) ====

参考文献には出版年を書く必要があり、BibTeXではyearというフィールドに書かれる。このデータはZoteroの文献情報のdateのところから取得されており、「April 22, 2011」「2011-04-22」のようなdateのデータからは正しく「2011」だけを抽出してくれるが、dateが前述の「4月 22 , 2011」のような書式になっていた場合はうまくいかず、この文字列全てがBibTeX（.bib）に出力されてしまう（報告済み: [https://github.com/retorquere/zotero-better-bibtex/issues/2449 [Bug]: Japanese date format is not parsed correctly · Issue #2449 · retorquere/zotero-better-bibtex]、6.7.61あたりで修正済み）。←の通り、Better BibTeXのエクスポート時に適用されるscript（Export → postscript）のところにデータを置換するための以下のようなコードを書いておくとよい。

<syntaxhighlight lang="vb.net">if (tex.has.year) {
tex.add({name: 'year', replace: true, value: tex.has.year.value.replace(/.* /, '')})
}</syntaxhighlight>
設定箇所はこんな感じ↓

<div class="res-img">https://turgenev.cloudfree.jp/mw1/imgs/zot-settings.jpg</div>

* 今は治っているかもしれないが、デバッグ出力を有効化して再起動してからスクリプトを一度編集しないとスクリプトが読み込まれないバグがあった（[https://github.com/retorquere/zotero-better-bibtex/issues/2447 https://github.com/retorquere/zotero-better-bibtex/issues/2447]）。


== Zotero Protocolを使用した操作 ==

{{Valuable}}

ZoteroはGUIのソフトであるが、コマンドラインからも一定の操作が可能である。具体的には、<code>zotero://</code>という形式のURL（URIスキーム）を以下のように指定してZoteroを起動することができる（既に起動していた場合は、画面に変化が起こる）。

<syntaxhighlight lang="python">zotero.exe -url "zotero://url/here"</syntaxhighlight>
URLについては、明確にAPIとして仕様が定められたものではなさそうで、全体的にあまりドキュメントは充実していない。

一例として、特定のコレクション内のアイテムが選択された状態にするということができる。コメントが不親切でわかりづらいが [https://github.com/zotero/zotero/blob/master/components/zotero-protocol-handler.js zotero/zotero-protocol-handler.js at master · zotero/zotero] の<code>scopeObject</code>などと書いてあるあたりをよく読むと、<code>zotero://select/library/collections/{collection_key}/items/{item_key}</code>という形式で指定すればよいことがわかる（groupIDなどと書いてある部分もあって紛らわしいが、groupというのはcollectionとは別の概念で、複数ユーザー間での共有のライブラリのようなものを指すようである）。<code>collection_key</code>と<code>item_key</code>はどちらも<code>1A2B3C4D</code>のような英数字による8文字の識別子である。ちなみにcollectionとitemにはそれぞれIDも割り当てられているがこちらは1～3桁くらいの数字でありkeyとは別なので注意。


== 指定されたCitation keyのアイテムをZoteroで開く ==

前述の方法を応用して実装してみる。ここではCitation keyとしてBetter BibTeXのものを使うことを仮定する。

まず、Citation keyからアイテムのキーを取得する部分を作る。Citation keyはBetter BibTeXが管理しているので（ここではデフォルトの~/Zoteroに各種データがあると仮定して）~/Zotero/better-bibtex.sqliteを読めばアイテムのkeyとの対応がわかる。次にアイテムが所属するコレクション（複数ある場合は最初のもの）のkeyをzotero.sqliteから取得する。ここではIDを一旦経由する必要がある。

Zoteroの起動中はデータベースファイルがロックされているが、[https://sqlite.org/forum/info/a2e9387b8ea1c919b2ad1ecafb417cebb15c48634c55b3abd6a9acbb2fabf797 SQLite Forum: Option to open a database as read-only despite locked.]にある通り、（Windowsなら）<code>sqlite3 "file:Zotero\\zotero.sqlite?mode=ro&nolock=1"</code>のようにしてやると読み取り専用で開くことはできる（書き込まないのでこれで充分）。今回はpythonで実装するが、pythonのsqliteでもこのパラメータが同じく使える。

コード例:

<syntaxhighlight style="margin-bottom:0.2em;" lang="python">import sqlite3
import sys
import json
import subprocess
db = sqlite3.connect('file:'+sys.argv[1]+'?mode=ro&nolock=1', uri=True)
cur = db.cursor()
cur.execute('SELECT data FROM "better-bibtex" where name="better-bibtex.citekey"')
d = json.loads(cur.fetchone()[0])
mydict = {}
for item in d["data"]:
mydict[item["citekey"]] = item["itemKey"]
myKey = mydict[sys.argv[3]]

db2 = sqlite3.connect('file:'+sys.argv[2]+'?mode=ro&nolock=1', uri=True)
cur2 = db2.cursor()
cur2.execute("SELECT itemID FROM items WHERE key=?", (myKey, ))
item_id = cur2.fetchone()[0]
cur2.execute("SELECT collectionID FROM collectionItems WHERE itemID=?", (item_id, ))
# 所属する最初のコレクションIDを取得
collection_id = cur2.fetchone()[0]
# collectionIDからcollectionKeyを取得
cur2.execute("SELECT key FROM collections WHERE collectionID=?", (collection_id,))
collection_key =cur2.fetchone()[0]
print(collection_key)
subprocess.run(f'"C:\Program Files (x86)\Zotero\zotero.exe" -url "zotero://select/library/collections/{collection_key}/items/{myKey}')
db.close()
db2.close()</syntaxhighlight>
<div style='text-align: center;'>zoto.py</div>

上記コードは以下のように起動できる。

<syntaxhighlight lang="c#">python "path\to\zoto.py" "%USERPROFILE%\Zotero\better-bibtex.sqlite" "%USERPROFILE%\Zotero\zotero.sqlite" %1</syntaxhighlight>
* [[Windowsのクリップボードを用いた選択コンテンツの取得|Windowsのクリップボードを用いた選択コンテンツの取得]]と組み合わせれば、選択文字列をCitation keyとするアイテムを一発で開くことも可能。

== その他 ==

アイテムが入っているコレクションを知りたいときはアイテムが選択された状態でCtrlキーを押すとよい。
[[Category:IT]]{{#seo:|title={{FULLPAGENAME}} - Turgenev's Wiki}}

Windowsでエクスプローラーからフォルダを各種ターミナルで開く

2025-04-02T08:37:33Z

Turgenev: Notion-MW

Explorerの右クリックメニューやアドレスバーからフォルダを各種ターミナルで開くための設定方法の紹介。cmd.exe, powershell（pwsh含む）, Cygwin, Git Bashの4つに対応。

== 基本 ==

* [[Windowsの右クリックメニューから複数ファイルをまとめて開く|Windowsの右クリックメニューから複数ファイルをまとめて開く]] のように、レジストリでフォルダ・フォルダ背景の右クリックメニューを編集できる。
** Windows10までの右クリックメニューに戻そう。
** <code>command</code>キーの既定値に直接コマンドを書く方法と、<code>DelegateExecute</code>値（など）を使ってCOMを通じて実行する方法（このために[https://github.com/ge9/ExecuteCommand-Pipe https://github.com/ge9/ExecuteCommand-Pipe]（使い方はレポジトリの説明を参照）を作った）がある。
** HKLMにあるマシン全体の設定は、それ自体は管理者権限（あるいはTrustedInstallerなどさらに上の権限）がないと書き換えられないが、HKCUに値があればそちらが優先されるので、自分だけに関する設定変更ならユーザー権限だけで可能である。
** <code>Directory</code>や<code>Directory\Background</code>の直下に<code>runas</code>という名前でキーを作った場合は、自動的に<code>command</code>の内容が管理者権限で実行される。ただ、<code>runas</code>という固定のただ一つの名前しか使えないため、例えば管理者としてコマンドプロンプトを開くメニューとPowerShellを開くメニューを共存させることができない。そのためこの記事では<code>runas</code>キーを使用するのではなくコマンドの中で明示的に管理者としての実行を行っている。
* Explorerのアドレスバー（address bar, location barなど）にcommandと入力してEnterを押すと、そのフォルダをカレントディレクトリとして<code>command</code>というコマンドが実行される。
** このアドレスバーの仕様はおそらく「ファイル名を指定して実行」とほぼ同じ。<code>command</code>で（メインとして）指定するファイルはフルパスなら必ず動作し、Pathが通っているまたはApp Pathsに登録されているならファイル名だけでよく、さらにbatやexeの場合は拡張子も省略できる。さらに、ほとんど知られていないが実はApp Pathsの値には実行ファイル以外も書けるようである。
** つまり、パスの通っているフォルダにあるimage.pngはフルパスを打たなくても「image.png」で開けるし、さらにはApp Pathsの<code>openimage.exe</code>というキーにimage.pngのフルパスを書けば<code>openimage</code>と打つだけで（実際にはそのような実行ファイルは全く存在しないにもかかわらず）image.pngが開くようになる。当然、vbsなども拡張子無しで呼び出せることになる。

== ポイント ==

==== パス名のルール ====

* Windowsではパスの長さが260文字以下という制限がある。詳しくは[[Windowsのパス長さ制限に関して|Windowsのパス長さ制限に関して]] 参照。
** 制限を超えるような長いパスは<code>\\?\</code>というプレフィックスを付けて（UNCパスの一種として）扱われる。
*** このようなフォルダをカレントディレクトリとしてコマンドを実行することはできないので、アドレスバーに打ち込む方式は使えない（System32をカレントディレクトリとして実行される）。wt -dなどにも指定できない。
*** 右クリックメニューでは、commandの既定の値に直接書く方式の場合は、<code>NoWorkingDirectory</code>を設定しないと呼び出されなくなる。
*** シンボリックリンク/ジャンクションでパスを短くしてやれば普通に扱えるようになる
* 普通に入力できる文字でWindowsのファイル名に使えないのは、<code>\</code> <code>/</code> <code>:</code> <code>*</code> <code>?</code> <code>"</code> <code><</code> <code>></code> <code>|</code>の9個（エクスプローラーの画面で入れようとすると表示される）。
** その他、ヌル文字やタブスペースのような0x20未満の制御文字も使えない（はず）。
*** これらを含むファイルはGit Bash/Cygwinを使っても作れない。
*** NTFS自体の制限はおそらく<code>/</code>だけで、それ以外に関してはLinux上で作ってからWindowsで見ると見られることもある。中身の閲覧などは不可。
* また、末尾が空白またはピリオドのファイルも禁止で、Explorerやcmdでは作れない（自動で除去される）。
** これらはGit Bash/Cygwinなら作れる。前者はエクスプローラーで閲覧など多少の操作ができるが後者はほとんど何もできず、DelegateExecuteの右クリックメニューでもピリオドが外れた名前しか取得できない。
* 先頭が空白のファイルはExplorerだと作れないがcmdなら作れる。禁止ではないはず。


==== Git Bash/Cygwin ====

* Git BashではWindowsの実行ファイルにスラッシュ付きオプションを渡すときはスラッシュを2つにする必要がある。<code>cmd //c</code>や<code>bcdedit //v</code>など。
* printf関数の%qオプションを使うと、文字列をエスケープされた状態にして返してくれる。これはshからの呼び出し先の別のshで再びフォルダ名をcdなどの引数として利用したいときに使える。
** bash（POSIX互換ではない）の組み込みコマンドのprintfと、独立実行ファイル（GNU Coreutilsの一部）である/bin/printfがある。基本的な趣旨としては同一のコマンドだが、組み込みコマンドのほうは入力に<code>"</code>が含まれていない限り結果にも<code>"</code>が使われることはないようで、このおかげで意図しない動作を回避できることがある。今回扱う例に関しては前者が後者の上位互換であるということになる。後者を使っているものはそれでも動いたものである。
** そもそも%qは組み込みコマンドのほうにしかないという話もある。環境によって違いそう。
* <code>\\?\</code>が付くような長いパスをカレントディレクトリにしていても、Git Bash/Cygwinに付属の（というかMSYS/Cygwin向けにコンパイルされた？）exeなら実行できる。
* Git Bashの(ba)shは<code>--login</code>をつけて起動してもカレントディレクトリが維持されるが、<s>Cygwinの(ba)shは</s><s><code>--login</code></s><s>をつけると強制的にホームディレクトリに移動する。</s>
** 2024/4頃、Cygwinの挙動が変化し、カレントディレクトリが維持されるようになっていることに気付く。変わっていた方のバージョンは3.5.3、変わっていない方は3.3.6であった。
** ところで、[https://superuser.com/questions/345964/start-bash-shell-cygwin-with-correct-path-without-changing-directory Start bash shell (cygwin) with correct path without changing directory - Super User]の通り、<code>CHERE_INVOKING</code>という変数を1に設定しておけばカレントディレクトリは維持される。
* Git Bashにおいては環境変数を正しく設定するため<code>--login</code>の時点で環境変数<code>MSYSTEM</code>を<code>MINGW64</code>にしておく必要がある。[[Windowsでのターミナル環境|Windowsでのターミナル環境]] 参照。


==== powershell/pwsh ====

* バージョン5まで（Windows PowerShell）はpowershell.exe、6以降（PowerShell Core, PowerShell）はpwsh.exeと実行ファイル名が違う
** 以後、「powershell(.exe)」と「pwsh(.exe)」で呼び分ける。ただし手元ではpowershellの5.1とpwshの7.2～7.3くらいでしか試していないので、一部バージョンではまた違う可能性もある。
** pwshは必ずしもWindowsに標準では入っていないので、以下の例でもあまり依存しないように気を付ける。
** 基本、シングルクォートで囲えばほとんどの特殊文字が無効になり、シングルクォート自体を書くときは2つ並べる。ただし注意点として、驚くべきことにpowershell/pwshでは「全角のシングルクォート（U+2018-U+201B、<code>‘</code> <code>’</code> <code>‚</code> <code>‛</code>の4つ）」も通常のシングルクォートと同じ効力があるので、同じようにエスケープする必要がある（参照: [https://learn.microsoft.com/ja-jp/powershell/scripting/lang-spec/chapter-02?view=powershell-7.2 https://learn.microsoft.com/ja-jp/powershell/scripting/lang-spec/chapter-02?view=powershell-7.2]）。掲載したスクリプトでは省略しているがやることは同じ。
* powershell.exe
** -Commandがなくても付けたのと同じ扱いになる？
*** 逆に、-Commandを付けなければいけないという点を除いてはpwshがpowershellの上位互換という感覚である（新しいのでそれはそう）。
** <code>`</code>や<code>[]</code>を含むフォルダの扱いにバグがあり、cmdなどでこれらのフォルダをカレントディレクトリとした状態で5系のPowerShellを起動すると<code>C:\</code>や<code>C:\Windows\System32\WindowsPowerShell\v1.0></code>をカレントディレクトリとして起動される（たとえば<code>C:\somefolder][</code>なら前者、<code>C:\somefolder[]</code>なら後者）。
** -Fileを使用してスクリプトを実行するとき、ダブルクォーテーションで囲われていない <code>-</code> が引数に含まれているとエラーになるバグがある。
* powershell.exe・pwsh.exe共通
** 連続した<code>`</code>があるフォルダに関する挙動にバグがある。コンソールプログラムを実行しても新規ウインドウで開かれる、そこをカレントディレクトリとしたときにファイルをmvできないなど。
** <code>`</code>や<code>[]</code>を含むフォルダに関しても、絶対パス指定したりきちんとエスケープしたりすれば操作自体はできる（場合もある）。
*** エスケープはいずれも直前に<code>`</code>を付ける。
*** これらを特殊文字として扱いたくないときは<code>-LiteralPath</code>を付けると良い場合もある。
** UNCパスをカレントディレクトリにすることができるが、<code>Microsoft.PowerShell.Core\FileSystem::\\</code>とかいう謎のプレフィックスが付く。
** 末尾が空白のフォルダについてはcdできず、Cygwinなどでそのようなフォルダをカレントディレクトリとして起動したとしても<code>C:\Windows\System32\WindowsPowerShell\v1.0</code>や<code>C:\Program Files\PowerShell\7</code>に移動してしまう。
** 8.3形式のパスを強制的に長い名前に戻してcdしてしまう。その結果、長いフォルダをカレントディレクトリとして外部プログラムを実行できなくなる。
* PSModulePath環境変数の関係な気がするが、pwshの中でcmdを起動してその中でpowershellを起動したりするとPSReadLineモジュールが読み込めない（<code>PSReadline モジュールを読み込めません。コンソールは PSReadline なしで実行されています。</code>）とか言われたりする

==== 環境変数への置換 ====

cmdなどを使うと<code>%</code>で囲われた環境変数（<code>%PATH%</code>など）が置換される。<code>%</code>はファイル名にも普通に使える文字なので、注意が必要となる

* 該当の名前の環境変数が定義されていたときのみ置換が行われ、定義されていなければそのままになる。
* <code>%</code><code>VAR</code><code>%</code>の置換は必ずしもcmdだけで行われるわけではない。「ファイル名を指定して実行」、VBSのWscript.Shellのrun、conhost、wtの引数などでも行われる。しかしCreateProcessやShellExecute(Ex)やレジストリ値では行われない（無理やりREG_EXPAND_SZにしたら展開されるが、後述の<code>%V</code>との適用順などは不明）。
* 一般には、環境変数には英数字とアンダースコアしか使えないとの説明もよくあるが、実際にはほとんどの記号が有効である。従って、<code>^%PATH^%</code>のようなキャレットによるエスケープはcmd向けにはある程度有効だが、<code>PATH^</code>という環境変数が定義されているとうまく動かない。
* （そういう変数が定義されていることは現実にほとんどないだろうし、それが保証できるなら以下の部分を読む必要はない）

これを防ぐ方法はいくつかある。ちなみに、<code>%%</code>でのエスケープというのはバッチファイルの中だけの話で、今回の場面では以下より簡単なエスケープ方法は多分ないと思う。

<ol style="list-style-type: decimal;">
<li>既に定義されているかもしれない環境変数をバックアップし、一時的にその中身を<code>%</code>に変えて使用することでリテラル文字としての<code>%</code>を表現し、後で元に戻す。
すなわち、<code>MY_PERCENT</code>のような変数の中身をバックアップし、<code>MY_PERCENT</code>の中身を<code>%</code>に変え、未知の文字列中の<code>%</code>をすべて<code>%MY_PERCENT%</code>にすることでこの部分が置換によって<code>%</code>に変わるのを利用して<code>%</code>をそのまま渡すということである（環境変数の置換は左から順に行われるため、たとえば<code>%MY_PERCENT%PATH%MY_PERCENT%</code>の<code>%PATH%</code>が置換されることはない）。受け渡しが終わったら<code>MY_PERCENT</code>の中身を復元する。
これは、変数のバックアップとリストアを同じプロセス・スクリプト内で行える（呼び出した後に元に戻ってくる）場面で有用である。呼び出し先プロセスでリストアすることも不可能ではないと思うが、環境変数には任意の文字が入る可能性があることを考えるとエスケープが大変困難になることが予想される。</li>
<li>VAR1, VAR2, VAR3, …のような無限個の変数を最初からチェックし、最初の未定義の変数を上記と同様に使用し、後で未設定にする。
ほぼ上記と同じだが、内容のリストアでなく未設定にするだけなので、呼び出し先プロセスでも容易に行える。ただし実装が面倒である。</li>
<li><code>%</code>を<code>==%</code>へと置換して、置換のプロセスを抜けた段階で元に戻す。
<ul>
<li>これは、最初の文字以外に<code>=</code>が含まれる環境変数名は（実際に環境変数が設定されていたとしても絶対に）置換されないことがわかったためである。
<ul>
<li><code>%=%</code>（あるいは、<code>%=VAR%</code>など）は少なくともcmdの対話シェル上だと置換されてしまうので<code>=%</code>へのエスケープだと不十分に見えるが、実際には<code>=</code>一つでも問題なく動く場合もあった。</li>
<li>しかし、動かないときもあるので、多くの例では<code>==%</code>にエスケープしている。<code>=%</code>になっているものは、試した限りはそれでも問題なく動いているものである。</li>
<li>[https://learn.microsoft.com/en-us/windows/win32/procthread/environment-variables Environment Variables - Win32 apps | Microsoft Learn]では「<code>=</code>は環境変数に使えない」と書かれていて、ダイアログからでも設定はできないが、レジストリだと無理やり設定できる。
<ul>
<li>ユーザー環境変数に設定する分にはとりあえず問題なさそうだが、システム環境変数にレジストリから<code>=</code>（と、<code>=</code>を名前に含むいくつかの変数。どれが原因かは正確にはわからない）を無理やり追加したら0xc000021のブルースクリーンでWindowsが起動しなくなった（該当の変数を全て削除したら治った）のでこれはやってはいけない。</li></ul>
</li>
<li>ちなみに、<code>=</code>や<code>%</code>はUnix側では特殊文字ではないので、printfとの適用順はあまり気にする必要はない。</li></ul>
</li>
<li>この方法のメリットは、一度置換してしまえばその文字列を何度使いまわしても変化がないことが保証されることと、未定義の変数の探索や変数のリストアが必要ないことである。
<ul>
<li>要は<code>%(=を含まない文字列)%</code>を含まない文字列だけを値にとる単射を構成すればいいだけなので、base64エンコーディングのようにしても構わない。</li></ul>
</li>
<li>ただ、<code>==%</code>を<code>%</code>に置換するという操作はPowerShellやshにとっては容易でもcmdにとっては不可能に近いので、最終的な呼び出し先がcmdであるときには採用しづらい。</li></ul>
</li></ol>

また、今回の記事ではcmdやvbsのRunを経由してコマンドを実行しているものが多くあるが、このスクリプトの内容自体もエスケープが必要である。つまり、例えば<code>cmd /c</code>の内側に<code>$mypath.Replace('%','%MY_PERCENT%')</code>というPowershellコードが含まれるなら、<code>','</code>や<code>MY_PERCENT</code>という環境変数が定義されていた時にその部分が置換されてしまう。これを回避するのはそこまで難しくなく、この例であれば<code>$mypath.Replace('%'.Trim('='),'%'.Trim('=')+'MY_PERCENT%')</code>のように<code>=</code>を含む無意味なコードを挿入すればよい。また、<code>%</code>をいったん<code>==%</code>にしている部分に関しては、<code>==%</code>ではなく<code>==%==</code>にすることで問題を避けられるだろう。無駄に複雑になるのでスクリプト例ではそのような措置はしていない。

==== cmd ====

* UNCパス（<code>\\?\</code>だけでなく普通のUNCパスも含む）をカレントディレクトリにすることはできない（rdなど一部コマンドでの取り扱いは可能）。
* 末尾が空白のフォルダにcdすることはできないが、Cygwinなどでそのようなフォルダをカレントディレクトリとした状態でcmdを起動した場合は、そのフォルダをカレントディレクトリとして起動する（外部プログラムの起動はできないがcdなどの内部コマンドは有効で、一度でも出たら戻れない）。
* 各種のパース規則が本当に謎。特に引用符周りは地獄である。[https://thinca.hatenablog.com/entry/20100210/1265813598 cmd.exe のコマンドラインの仕様を解析してみた - 永遠に未完成]を読むとわかるが、例えば「ファイル名を指定して実行」で以下の挙動を確かめよう。
** <code>cmd /k echo "a b"c d"</code>→<code>"a b"c d"</code>と出る
** <code>cmd /k echo "a & b"c d"</code>→<code>"a & b"c d"</code>
** <code>cmd /k echo "a b"c & d"</code>→<code>echo "a b"c</code>と<code>d"</code>がそれぞれ別々に実行される
** すなわち、<code>"</code>が一見特殊文字でないかのような振る舞いをする（そのまま出力される）割に、その前後で特殊文字の扱いが切り替わっている。


==== Windows Terminal ====

* 以下、wtと略す（実行ファイル名がwt.exeなため）。パスが通っているものと仮定する。
* wtでは<code>;</code>が特殊文字になるようで、<code>\;</code>とエスケープが必要。[https://github.com/microsoft/terminal/issues/13264 https://github.com/microsoft/terminal/issues/13264] かな？
** <code>"</code>も<code>\"</code>にする必要がある。一方で、単一の<code>\</code>は（うしろに<code>;</code>や<code>"</code>などがなければ）そのまま<code>\</code>になるようである。大丈夫なのか…？
* 起動時にカレントディレクトリがユーザーフォルダ（%USERPROFILE%）になる
** <code>-d</code>オプションで明示的に指定することができる

==== 連続空白 ====

空白が連続するファイル名の対応は割と厄介である。Windows側では引数を<code>""</code>で囲うことで、またsh側では適宜<code>IFS=</code>と設定することで対処できる。


==== Unicode対応 ====

* UTF8を使おう
* <code>chcp 65001</code>が一応使えるが、一旦シェル内部に入らないと使えないのでやや不便
** 使わなくても大丈夫なときもある。あまりちゃんと理解できていないが、経験上、powershellで<code>$input</code>変数を用いて標準入力を受け取る際には<code>chcp 65001</code>が必要そう。
* /bin/printfやprintfの実行時には<code>LANG</code>を<code>en_US.UTF8</code>とかに設定する。
** Cygwinなら不要？

==== デバッグ時 ====

* 管理者権限のものを試すときでもまず<code>-Verb Runas</code>を外して動作確認するとよい。
* 後述のwaitrunも役に立つだろう。
* 特殊文字に関しては、最初は空白のないフォルダ、次に空白のあるフォルダや連続空白のあるフォルダ、次にシングルクォートや<code>%PATH%</code>を含むフォルダなどとだんだん難しくしていくとよい。
* それとは別に、Unicode対応、<code>C:\</code>（ドライブ直下）対応、259文字のフォルダ対応（後述）などをチェックする
* 難しい例は、例えば<code>z 𠮷𠮷%PATH% ' '' ` `` $PATH & && %%PATH%%[] ] [ ^ ^^ ' ; ;; 𩸽𩸽!PATH!#$%&'()=~{`+}_,.][;@^- - ‘ ’ ‚ ‛</code>のような感じ（適当）。こんなファイル名を現実に見ることはないが、エクスプローラー上で普通に入力できる内容である。
** 「𠮷」はBMP外かつJIS外の漢字としては最も変換で出しやすいのでテストに重宝する。（𩸽はBMP外だがJIS外ではない（第4水準））

==== その他 ====

* デフォルトシェルは、通常ユーザーはwtでも管理者の場合はconhostに設定されているっぽい？
* <code>C:\</code>のようなドライブ直下のパスは末尾に<code>\</code>を付けなければいけないことが多い。たとえばwt -dの引数にする場合など。またcmdでcdコマンドや<code>CD</code>環境変数を見るときもドライブ直下のときだけは<code>\</code>が付いて返ってくる。
** ただ、wt -d に<code>C:</code>が渡されるように見えるのになぜか動いているものもある。未調査。
* shやcmdなどの中に一旦入ってしまうと一部の環境変数などが書き換わってしまうかもしれないが、多少は許容することとする。
* コマンド例は網羅的でない可能性があり、色々な書き方を提示しようとあえて統一していないところもある。現実にはもっと簡単なやり方があるかもしれない。あくまで一例ということで。
* CygwinとGit Bashはほぼ同じなのでGit Bashを主に載せてCygwinは適宜差分のみ記述する。
* shは、特にベースのシェルとして使うにはエスケープの方式などでWindowsと相性が悪く使いづらい感じがする。逆にcmdは内部コマンドは地獄だがベースのシェルとしては意外と副作用が少なく、そう悪くはない。
* 以下の例ではCygwinやGit Bashの実行ファイルにはPATHを通していないことを想定している。<code>C:\cygwin64</code>あたりは適当に読み替えていただきたい。
* 2021年途中ごろまで、wtなどのストアアプリ系？の実行ファイル（Explorer上で0バイトになってるエイリアス）をGit Bashから実行できない（Permission deniedとなる）バグがあった。 [https://github.com/git-for-windows/git/issues/2675 https://github.com/git-for-windows/git/issues/2675]
* ネットワークドライブは各ユーザー対象に割り当てられているせいなのか、管理者として実行すると利用できないらしい。割り当てられる前のネットワークパス自体は有効。
* wtを管理者権限で呼び出すときに（確率的に）ウインドウが最前面にならないことがある。chcpの有無で変わったりするなど詳細不明。conhostだとならない気がする。startrunなどを介して実行すると必ず最前面に出るようになるっぽい。


== 準備: win-console-delegator ==

cmdやPowerShellやCygwinのbashなどのシェルを使えば、スクリプトを起動して複雑なコマンドを呼び出せたり、パイプ実行が可能になったりと色々便利だが、それだけのためには大仰すぎて、特殊文字の扱いなどがかえって仇になることもある。

そこで、シェル関連の操作に汎用的に使えるコマンドをいくつか作成して公開した。[https://github.com/ge9/win-console-tools https://github.com/ge9/win-console-tools]

* 以前はC++で書いていた（[https://github.com/ge9/win-console-delegator https://github.com/ge9/win-console-delegator]）が、C#のほうが文字列の扱いなどが簡明。

ただし、これはあくまで筆者が独自に作ったものであり、Windows標準のもので何とかしようとするのが面白いところでもあるので、それほど積極的には使わない。今後出てくる例はすべて、これらを一切使わなくても（余計な環境変数が設定されてしまうかもしれないという点をのぞけば）同等の機能が実現できる。

<ul>
<li>runother
与えられた引数を特定の文字列とつなげて実行してくれるプログラム。この実行ファイル自体の名前を適宜変更して使用し、「特定の文字列」は別のファイルから読ませる。使用例は[[Windowsでのターミナル環境|Windowsでのターミナル環境]] を参照。</li>
<li>runother-gui
runotherとほぼ同じだが、コンソールアプリケーションではなくWindowsアプリケーション（黒いウインドウが出ない、cmd上で実行したときに終了待ちが行われないなど）。</li>
<li>evalrun
与えられたコマンドラインを実行し、その出力をそのままコマンドラインとして実行するコンソールアプリケーション。（テキストファイルからのコマンドラインの読み込みなどに使える）</li>
<li>startrun
与えられたコマンドラインをWindowsのデフォルトシェルで起動するだけのWindowsアプリケーション。</li>
<li>waitrun
与えられたコマンドラインを実行したあとキー入力を待ってから終了するコンソールアプリケーション。一瞬でウインドウが消えてしまうときのデバッグに使いやすい。</li>
<li>hiderun
コンソールウインドウ非表示の状態で与えられたコマンドを実行するWindowsアプリケーション。（GUIアプリケーションなどを与えた場合は非表示にならないかも）
vbsのvbHideでも非表示にできるが、コンソールウインドウの表示位置をみると非表示のウインドウが一つ挟まっていることが分かるのに対して、こちらの場合はそうならない。</li>
<li>piperun
与えられたコマンドラインを最初の<code>|</code>とそれ以降の2つに区切ってそれぞれコマンドとしてパイプでつなげて実行するコンソールアプリケーション。ただし最初のコマンドのほうに<code>|</code>自体を入力したいときは<code>||</code>でエスケープする。また2つ目のコマンドの先頭の空白は除去される。</li>
<li>piperunex
piperunと似ているが、2つだけでなく3つ以上の任意個のパイプ実行を一度に行う。一見便利だが、コマンドの後ろ側に未知の文字列が渡される場合、<code>|</code>をエスケープする必要が生じる。
<code>piperun piperunex command1 || command2 || ... || commandN | unknown_commandline</code>のように外側を<code>piperun</code>で囲うと安全。</li>
<li>adminrun
与えられたコマンドラインを管理者として実行するWindowsアプリケーション。<code>ShellExecuteEx</code>では実行ファイルパスと引数は別々に指定しなければいけないので最低限の引数の解析を行っている。PowerShell経由で管理者権限で実行するときのような面倒なエスケープが全て不要になるため非常に使いやすいが、この記事ではこれに依存しないようにする。
<ul>
<li>ちなみにこういうのもある。[https://github.com/mattn/sudo mattn/sudo: sudo for windows] これは、通常のUACのように別ウインドウで実行するのではなく、localhostのランダムなポートを使い、自分自身にポート番号を渡しつつ管理者権限で呼び出すことで標準入出力を転送し、元の端末でそれを読み書きできるという点で、linuxのsudoに近い。しかし標準入出力を介しているので、<code>cmd /c for /?</code>や<code>cmd /c pause</code>の挙動が変わってしまうという問題がある。また、呼び出し元でchcp 65001をしていると文字化けする。また、コマンドライン引数を一旦配列に分割してから組み直しているので情報が一部落ちている。あと、セキュリティ的にも懸念があるかもしれないが、これはそもそもLinuxのsudo自体がまずどうなの？という気持ちになった。（未解決）（参照: [https://twitter.com/e9g/status/1687385469921931264?s=20 https://twitter.com/e9g/status/1687385469921931264?s=20]）</li></ul>
</li>
<li>uacrun
startrunと同じだが、コンパイル時のマニフェスト設定でこのプログラム自体の実行に管理者権限を要求するようにしたので、adminrunと同じように使える（管理者権限で実行する対象が渡されたコマンドではなくuacrun自体になるという違いはある）</li>
<li>pecho
与えられたコマンドライン引数をそのままコンソールに出力する。→WindowsでUnicode文字（特にU+10000以上）を正しく表示（&ファイルに書き込み）するには、「出力先がコンソールならWriteConsoleW、そうでなければWriteFileを使用する」といった非常に面倒な実装が必要であり（参照: [https://twitter.com/mattn_jp/status/542581083242364928 https://twitter.com/mattn_jp/status/542581083242364928] など）、C++やC#では扱いづらい。そこでrustを用いて実装した。→[https://github.com/ge9/pure-echo-win pure-echo-win]</li>
<li>printcd
カレントディレクトリをコンソールに出力する。（ちなみにpwdの由来はprint working directoryなのでそれに倣った）</li></ul>


== 注意: 当初は後述のNoWorkingDirectoryを知らなかったので1.の方法に頼っていたが、実際には2.の方法のほうが簡明なので、そちらを使うことを勧める。1.は残しておくが、読む必要はあまりない。 ==




== 1.標準入力から受け取る場合 ==

まず「標準入力からディレクトリのフルパスを受け取り、そのディレクトリで各種ターミナルを起動するコマンド」を紹介する。

そのようなコマンドを仮に<code>openterm</code>とすると、ExecuteCommand-Pipeを使用して、レジストリ（該当CLSIDのLocalServer32の既定の値）に以下のように書くことで、CLSIDが右クリックメニューのDelegateExecute値に使えるようになる。

<code>C:\path\to\ExecuteCommand4000.exe h openterm</code>

<code>h</code>はコンソールウインドウを非表示にするExecuteCommand-Pipeのオプションである。

また、この<code>openterm</code>の部分は非常に長くなることがあり、その場合レジストリに書いて直接編集するのは手間がかかる（操作もしづらいし、更新を即座に反映させるために「<code>LocalServer32</code>」キーの名前などを変えて戻す必要もあって面倒）。そこで、runotherを使ってtxtに<code>openterm</code>の内容をそのまま書くことで、<code>openterm</code>の部分にそのexeの名前だけを書けばよくなる。

また、いくつかはCygwin/Git Bash向けに冒頭でcygpathによる変換を入れているが、これを取り除けば、Cygwin/Git Bash用のパスを受け取って動作するコマンドということになる。

では以下で、<code>openterm</code>部分についてそれぞれ紹介する。

* 直接コマンド記入でも<code>NoWorkingDirectory</code>を指定すれば<code>\\?\</code>に対応できるというのをこのセクションの大部分を書き終えてから知ったので、このセクションは内容の多さの割には実際の必要性はそこまで大きくないかもしれない。


=== Git Bash ===


==== <code>git-bash.exe</code>で開く ====

この場合shの感覚で<code>git-bash.exe</code>に引数を渡せば勝手にminttyのウインドウで開いてくれるので最も楽である。

<code>cmd /c ""C:\Program Files\Git\usr\bin\cygpath" -f - | "C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=;/bin/env LANG=en_US.utf8 /bin/printf %q $(/bin/cat)" | "C:\Program Files\Git\usr\bin\xargs" -d '\n' -I {} "C:\Program Files\Git\git-bash.exe" -c "cd {};exec bash""</code>

* Git BashのcygpathでGit Bash用のパスに変換
* printfでエスケープ、utf8を設定
* git-bash.exeに渡す


==== デフォルトのターミナルで開く: ①startrunを使う ====

<code>cmd /c ""C:\Program Files\Git\usr\bin\cygpath" -f - | "C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=;/bin/env LANG=en_US.UTF8 /bin/printf %q $(/bin/cat)" | "C:\Program Files\Git\usr\bin\xargs.exe" -d '\n' -I {} startrun "C:\Program Files\Git\usr\bin\env.exe" MSYSTEM=MINGW64 "C:\Program Files\Git\usr\bin\bash.exe" --login -i -c 'cd {};exec bash'"</code>

* <code>git-bash.exe</code>や<code>C:\Program Files\Git\bin</code>のbashではなく/usr/binのbash.exeを使う。以後同じ。


==== デフォルトのターミナルで開く: ②cmdのstartを使う ====

<code>cmd /c ""C:\Program Files\Git\usr\bin\cygpath" -f - | "C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=;/bin/env LANG=en_US.UTF8 /bin/printf %q $(/bin/sed 's/\\^/^^/g;s/%/=%/g;s/&/^&/g')" | "C:\Program Files\Git\usr\bin\xargs.exe" -d '\n' -I {} cmd //c start "" "C:\Program Files\Git\usr\bin\env.exe" MSYSTEM=MINGW64 "C:\Program Files\Git\usr\bin\bash.exe" --login -i -c 'cd "$(echo {} ^| sed s/=%/%/g)";exec bash'"</code>

* この場合、cmdによる環境変数への置換を避ける必要があるほか、キャレットによるエスケープにも対応する必要がある。
* Git Bashからcmdを実行しているので<code>//c</code>のところのスラッシュは2つ。

==== conhostで開く ====

<code>cmd /c ""C:\Program Files\Git\usr\bin\cygpath" -f - | "C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=;/bin/env LANG=en_US.UTF8 /bin/printf %q $(/bin/sed 's/%/=%/g')" | "C:\Program Files\Git\usr\bin\xargs.exe" -d '\n' -I {} conhost "C:\Program Files\Git\usr\bin\env.exe" MSYSTEM=MINGW64 "C:\Program Files\Git\usr\bin\bash.exe" --login -i -c 'cd "$(echo {}|sed s/=%/%/g)";exec bash'"</code>

conhostによる環境変数の置換を抑制。


==== Windows Terminalで開く ====

<code>cmd /c ""C:\Program Files\Git\usr\bin\cygpath" -f - | "C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=;LANG=en_US.UTF8 printf %q $(/bin/sed 's/%/=%/g')" | "C:\Program Files\Git\usr\bin\sed.exe" "s/;/\\\\;/g" | "C:\Program Files\Git\usr\bin\xargs.exe" -d '\n' -I {} wt "C:\Program Files\Git\usr\bin\env.exe" MSYSTEM=MINGW64 "C:\Program Files\Git\usr\bin\bash.exe" --login -i -c "IFS=\\;cd $(echo {}|sed s/=%/%/g) \\;exec bash""</code>

上記に加えてセミコロンへの対応が必要なのと、こっちは/bin/printfじゃなくて組み込みのprintfでこうしないとだめだった。


==== Cygwin ====

付属のminttyを使うものだけはGit Bashと割と差があるので載せる。

<code>cmd /c ""C:\cygwin64\bin\cygpath" -f - | "C:\cygwin64\bin\sh.exe" -c "IFS=;/bin/printf %q $(/bin/cat)" | "C:\Program Files\Git\usr\bin\xargs" -d '\n' -I {} "C:\cygwin64\bin\mintty.exe" -e "C:\cygwin64\bin\bash.exe" --login -i -c "cd {};exec bash""</code>


=== PowerShell ===


==== デフォルトシェル, startrun ====

* パスのエスケープがおかしい気がするが、なぜか動いている

<code>cmd /c ""C:\Program Files\Git\usr\bin\sed.exe" "s/'/''/g" | "C:\Program Files\Git\usr\bin\xargs.exe" -d '\n' -I {} startrun powershell -noexit -command Set-Location -literalPath "'{}'""</code>


==== デフォルトシェル, cmdのstart ====

<code>cmd /c ""C:\Program Files\Git\usr\bin\sed.exe" "s/'/''/g;s/%/=%/g" | "C:\Program Files\Git\usr\bin\xargs.exe" -d '\n' -I {} cmd //c start "" powershell -noexit -command Set-Location -literalPath '\'{}\'.Replace(\'=^%\',\'%\')'"</code>


=== cmd ===


==== Windows Terminal ====

<code>cmd /c chcp 65001 & powershell -Command "$mypath=($input | ForEach-Object { return $_ });$bak=$env:MY_PERCENT; $env:MY_PERCENT = '%';if ($mypath.Length -gt 258) { $mypath = cmd /c \"for %A in (`\"$($mypath.Replace('%', '%MY_PERCENT%'))`\") do @echo %~sA\" };$env:MY_PERCENT = $bak;wt -d ($mypath -replace ';', '\;') cmd"</code>

<ul>
<li>[[Windowsのパス長さ制限に関して|Windowsのパス長さ制限に関して]] でも書いた通り、Windows側はちょうど259文字の長さのフォルダだけは（その必要があるにもかかわらず）8.3形式を使った短いパスにして渡してくれない。そこで、パス長さが258を超えていればcmdに渡して8.3形式の名前に変換する処理をPowerShell側で行う。この際はエスケープされていない正確なパス名をcmdに渡さなければならないので<code>MY_PERCENT</code>の値を一時的に<code>%</code>に設定する方法をとっている。
<ul>
<li>念のため再確認しておくが、この<code>'%MY_PERCENT%'</code>の部分は<code>'%'.Trim('=')+'MY_PERCENT%')</code>などと変えておかないと、<code>MY_PERCENT</code>が定義されていた場合に正しく動作しない。</li>
<li>cmdではちょうど258文字のフォルダでもdirが失敗するなど挙動が不自然であるため、もう少し保守的に257を超えていれば短くするという仕様でもいいかもしれない。</li></ul>
</li>
<li>（追記）8.3形式のパスを取得するのは普通にPowerShell内でもできるらしい…。以下のようになる。
<code>if ($mypath.Length -gt 258) { $mypath = (New-Object -ComObject Scripting.FileSystemObject).GetFolder($mypath).ShortPath}</code></li></ul>

259文字のフォルダを無視するなら以下のように簡潔に済む。

<code>cmd /c chcp 65001 & powershell -Command wt '-d' $input.Replace(';','\;') cmd</code>

==== デフォルトシェル ====

これは案外難しい。なぜなら、cmd内でcdさせるのは%のエスケープの関係で難しく（cmd内で=を含む文字列を置換することがどうやってもできなさそう（外部プログラムを呼び出すのも難しそうだった）なので、未定義の変数を探索するやり方しかない）、Start-Processの-WorkingDirectoryやCygwinのshは8.3形式に対応していないからである。要は「与えられたディレクトリ（8.3形式のパスが含まれるかもしれない）をカレントディレクトリとして与えられたコマンドを実行する」だけやってくれるプログラムがあればよく、これ自体はそう難しくないことのはずだが、現状、Windows標準環境でこれができるのは自前でプログラムをコンパイルする以外だと（pwshを入れていいならpwshと）vbsしかないようである。結局、この部分をついでにやってくれるWindows Terminalのほうが楽ということになる。

たとえば以下のようなvbsを用意する。

<syntaxhighlight style="margin-bottom:0.2em;" lang="vb.net">Dim objShell
Set objShell = CreateObject("WScript.Shell")
objShell.CurrentDirectory = WScript.Arguments(1)
objShell.Run(WScript.Arguments(0)),,False</syntaxhighlight>
<div style='text-align: center;'>startatdir.vbs</div>

すると以下のように書ける。

<code>cmd /c chcp 65001 & powershell -Command "$mypath=($input | ForEach-Object { return $_ });$bak=$env:MY_PERCENT;$env:MY_PERCENT = '%';if ($mypath.Length -gt 258) { $mypath = cmd /c \"for %A in (`\"$($mypath.Replace('%', '%MY_PERCENT%'))`\") do @echo %~sA\" };$env:MY_PERCENT = $bak; wscript 'C:\path\to\startatdir.vbs' cmd ('\"'+$mypath+'\"')"</code>

なお<code>startatdir.vbs</code>のパス指定はフルパスが必要そう（ただしここはcmd /cの中なので<code>%USERPROFILE%</code>とかを使って書いてもよい）


== 1.1.標準入力から受け取る場合 - 管理者権限あり ==

上記の続きで、こちらは管理者権限ありのもの。


=== Git Bash ===


==== デフォルトシェル ====

<code>cmd /c ""C:\Program Files\Git\usr\bin\cygpath" -f - | "C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=;/bin/env LANG=en_US.UTF8 /bin/printf %q $(/bin/cat)" | "C:\Program Files\Git\usr\bin\sed.exe" "s/'/''/g" | "C:\Program Files\Git\usr\bin\xargs.exe" -d '\n' -I {} powershell -Command Start-Process -Verb Runas -Filepath '"C:\Program Files\Git\usr\bin\env.exe"' -ArgumentList '"MSYSTEM=MINGW64"', '"`"C:\Program Files\Git\usr\bin\bash.exe`""' , '--login', '-i' , '-c', "'\"cd {}; exec bash\"'" "</code>

* Start-Process自体がstartみたいなものなので、引数にコンソールアプリケーションを指定したらデフォルトシェルで開かれる。
* 最後のところ、「<code>"'\"cd {}; exec bash\"'"</code>」のかわりに「<code>'\'"cd {};exec bash"\''</code>」とか「<code>'\'\"cd {};exec bash"\''</code>」でも動くのは謎。シングルクォーテーションのエスケープ規則がわからない。参考→[https://twitter.com/e9g/status/1678283164689760256 https://twitter.com/e9g/status/1678283164689760256]


==== Windows Terminal ====

<code>cmd /c ""C:\Program Files\Git\usr\bin\cygpath" -f - | "C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=;LANG=en_US.UTF-8 printf %q $(/bin/cat)" | "C:\Program Files\Git\usr\bin\sed.exe" "s/'/''/g;s/%/==%/g;s/;/\\\\;/g" | "C:\Program Files\Git\usr\bin\xargs.exe" -d '\n' -I {} powershell -Command Start-Process -Verb Runas -Filepath wt -ArgumentList "'"'"C:\Program Files\Git\usr\bin\env.exe"'"'" , '"MSYSTEM=MINGW64"' , "'"'"C:\Program Files\Git\usr\bin\sh.exe"'"'" , "'--login'", "'-c'", "'"'"IFS=\\;cd $(echo {}| /bin/sed s/==%/%/g) \\; exec bash"'"' " "</code>

==== adminrunを使う ====

<code>piperunex "C:\Program Files\Git\usr\bin\cygpath" -f - | "C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=; /bin/env LANG=en_US.UTF8 /bin/printf %q $(/bin/cat)" | "C:\Program Files\Git\usr\bin\sed.exe" "s/%/==%/g;s/;/\\\\;/g" | "C:\Program Files\Git\usr\bin\xargs.exe" -d '\n' -I {} adminrun wt "C:\Program Files\Git\usr\bin\env.exe" "MSYSTEM=MINGW64" "C:\Program Files\Git\usr\bin\sh.exe" --login -c "IFS=\\;cd $(echo {}|| /bin/sed s/==%/%/g) \\; exec bash"</code>


=== PowerShell ===


==== Windows Terminal ====

<code>cmd /c ""C:\Program Files\Git\usr\bin\sed.exe" "s/'/''''/g;s/%/==%/g;s/;/\\\\;/g" | "C:\Program Files\Git\usr\bin\xargs.exe" -d '\n' -I {} powershell -Command Start-Process -Verb Runas -Filepath wt -ArgumentList 'powershell', '-noexit', '-command', 'Set-Location', '-LiteralPath', "'''\"{}\"''.Replace(''==%'',''%'')'" "</code>

* Cygwin系なしで

<code>cmd /c "chcp 65001 & powershell -Command Start-Process -Verb Runas -Filepath wt -ArgumentList 'powershell', '-noexit', '-command', 'set-location', '-literalpath', ('\"'''+($input -replace '''', '''''' -replace '%', '==%' -replace ';', '\;' )+'''.Replace(''==%'',''%'')\"') "</code>


=== cmd ===


==== デフォルトシェル ====

再び、startatdir.vbsを使う。

<code>cmd /c chcp 65001 > nul & powershell -Command "$mypath=($input | ForEach-Object { return $_ });$bak=$env:MY_PERCENT; $env:MY_PERCENT = '%';if ($mypath.Length -gt 258) { $mypath = cmd /c \"for %A in (`\"$($mypath.Replace('%', '%MY_PERCENT%'))`\") do @echo %~sA\" };$env:MY_PERCENT = $bak; Start-Process -Verb Runas -Filepath wscript -Argumentlist '//Nologo', 'C:\path\to\startatdir.vbs', 'cmd', ('\"'+$mypath+'\"')"</code>


==== Windows Terminal ====

<code>cmd /c chcp 65001 & powershell -Command "$mypath=($input | ForEach-Object { return $_ }); $bak=$env:MY_PERCENT; $env:MY_PERCENT = '%';if ($mypath.Length -gt 258) { $mypath = cmd /c \"for %A in (`\"$($mypath.Replace('%', '%MY_PERCENT%'))`\") do @echo %~sA\" };$env:MY_PERCENT = $bak;Start-Process -Verb Runas -Filepath wt -Argumentlist '-d', ('\"'+($mypath -replace '\\$','\\\\' -replace ';', '\;')+'\"'), cmd"</code>

この場合は<code>C:\</code>のための対処（<code>-replace '\\$','\\\\'</code>）が必要である。259文字のフォルダを無視するなら以下の通り。

<code>cmd /c "chcp 65001 & powershell -Command Start-Process -Verb Runas -Filepath wt -ArgumentList '-d', ('\"'+($input -replace '\\$','\\\\').Replace(';','\;')+'\"'), cmd"</code>


== 2.直接コマンド記入の右クリックメニュー ==

レジストリの<code>command</code>キーの既定の値に直接コマンドを記入する方式である。

デフォルトでは、右クリックメニューを押した時点でのフォルダ（フォルダを右クリックするメニューからだと対象フォルダの親、フォルダ背景を右クリックするメニューなら対象フォルダ）をカレントディレクトリとしてコマンドが起動される。そのため<code>\\?\</code>を付けなければならないような長大なパスのフォルダでは動作しない。しかし、<code>shell\xxxx</code>キーに<code>NoWorkingDirectory</code>値を設定することで、カレントディレクトリが必ず<code>C:\Windows\System32</code>に設定されるようになるので動くようになる。

対象のディレクトリはどう取得するかというと、レジストリに書き込んだ値のうち<code>%V</code>という部分が対象ディレクトリに書き換えられてコマンドが実行される。この<code>%V</code>もC:などの場合は<code>C:\</code>になる。コマンドの中でそのまま%という文字を使いたい場合はバッチファイルと同様に%%とエスケープする必要があるようである（これはどこにも書いてない？）。

しかし、こうして渡される（特殊文字を含むかもしれない）ディレクトリ名を完璧に取得するのは意外と難しい。cmdに解釈させると<code>%</code><code>VAR</code><code>%</code>が置換されてしまうし、シングルクォートとバッククォートが両方含まれているのでpowershellやshに渡すのも簡単ではない。

コツは、powershell -commandやsh -cの中に直接書くのではなく、スクリプトへのコマンドライン引数として渡した上で、スクリプト内で引数として取得することである。それぞれ、基本形（そのまま出力するだけ）は以下のようになる。

<ul>
<li>powershell
<code>powershell -Command "& {echo $args[1].Trim('\"')}" --%% "\"%V\""</code>
<ul>
<li><code>--%</code>というトークンを入れることでその後のパラメータの解析を行わないようにできる。args[0]は<code>--%</code>になるのでargs[1]を使う。レジストリに書く際は<code>%</code>をエスケープして<code>--%%</code>。</li>
<li><code>--</code>でも同様のことができる？<code>powershell -Command "& {echo $args[0].Trim('\"')}" -- "\"%V\""</code>（args[0]になっていることに注意）</li>
<li>というか、<code>--%</code>で書き進めてしまったが、本当は<code>--</code>のほうが安定するかもしれない。</li></ul>

あるいは<code>$MyInvocation.Line</code>を使う方法もある。この場合、powershellへの引数が全て（この例なら<code>-noexit -Command "& {$spl = ...</code>のところから）取得されるので、目当ての部分を取り出すためにここでは最後から2番目の<code>"</code>と最後の<code>"</code>の間を取得するという風にしている。
<code>powershell -noexit -Command "& {$spl = $MyInvocation.Line -split'\"' ; Set-Location -LiteralPath $spl[$spl.Length-2]}" --%% "\"%V\""</code>
昔のPowerShell（2くらい）で試してみたらこちらでないと<code>`</code>や<code>&</code>あたりの処理がうまくいかない場合があった。argsを使うものからの書き換えは容易である。</li>
<li>sh
<code>sh -c "IFS=;echo $*" -- "%V</code>
<ul>
<li>最後が<code>"%V</code>と閉じられていないのはミスではなく、<code>"%V"</code>としてしまうと<code>C:\</code>のときに<code>C:"</code>が渡されてしまうのでそれを避けるためである（これはかなりトリッキーなのでもう少し真面目にやってもいいとは思う）。</li>
<li>UNCパスの最初の<code>\\</code>が<code>\</code>に変わってしまう（手元では、Cygwinの場合は<code>\\?\</code>のみで発生している？）という問題があり、適宜置換する必要がある。</li></ul>
</li></ul>

これらの書き方はいわゆる「ワンライナー」的なものであるが、もちろん外部にスクリプトファイルを用意してもよい。

また、外部にスクリプトを用意してよいという条件であれば、vbsも使用可能である。

<ul>
<li>この場合、まずレジストリには
<code>wscript "C:\path\to\script.vbs" "%V"</code>
などと書く。スクリプトの内容は上記のレジストリの内容をほぼそのままWscript.ShellでRunすればよいが、<code>%V</code>のかわりにWscript.Arguments(0)を挿入するのと、<code>%</code>を<code>%%</code>にエスケープしなくてよいのと、VBSなので文字列内の<code>"</code>は<code>""</code>に変えなければならない。これに加え、Runの引数に含まれる<code>%</code><code>VAR</code><code>%</code>が置換の対象となるため、対象フォルダの文字列については<code>==%</code>への置換でエスケープして、呼び出し先のpowershellなどで元に戻す。</li>
<li>必要に応じてRunのオプションでvbHideを指定する。</li>
<li>というか別に258文字を超えていたら云々みたいな処理も全部vbs側でやってしまってもよい（面倒なのでそういう例は載せていない）</li></ul>

バッチファイルに渡すのは、バッチファイルをcmdが呼び出す時点で<code>%PATH%</code>のようなファイル名の環境変数は既に展開されてしまうので、どうやっても不可能。

他には、（hiderunと）piperunとpechoを併用するという方法もあり、それらの実行ファイルを用意する必要があるという以外は綺麗にできる方法である。

いずれにしろ、一旦取得できてしまえばあとは前述の<code>openterm</code>に流し込むだけでよい。ただ、実際にはわざわざ<code>openterm</code>に流し込まなくても（パイプを使わなくても）もっと簡単に起動できることもあるのでそちらを中心に紹介する。

* commandの最初で指定する（メインの）実行ファイル（先ほどなら<code>powershell</code>や<code>sh</code>）をファイル名単体で書く場合は、それが（メニューをHKCUで設定するならHKCUの（最近のWindowsならHKLMのでも可？）、HKLMで設定するならHKLMの）App Pathsキーに登録されていなければならない（PATHは通っていなくてもいい）。登録されていない場合はフルパスで指定する必要がある。

=== 設定例 ===

==== 管理者権限なし ====

<ul>
<li>PowerShell
デフォルトターミナルで
<code>powershell -noexit -Command "& {Set-Location -LiteralPath $args[1].Trim('\"')}" --%% "\"%V\""</code>
<ul>
<li>参考までに、Windowsにもともと入っているメニューでは以下のようになっている。
<code>powershell.exe -noexit -command Set-Location -literalPath '%V'</code>
これだとシングルクォートと連続スペースに対応できない。連続スペースだけなら<code>'%V'</code>を<code>"'%V'"</code>に変えると解決できる。<code>%$[]`</code>あたりは見た感じ問題なし。
<ul>
<li>以下の解決策でもまだ不完全 [https://superuser.com/questions/1310258/open-powershell-window-here-file-explorer-context-menu-command-breaks-with-fol "Open PowerShell window here" File Explorer context-menu command breaks with folder names with apostrophes (single quotes) - Super User]</li></ul>
</li>
<li>この問題は[https://github.com/PowerShell/PowerShell/issues/6598 https://github.com/PowerShell/PowerShell/issues/6598]や[https://github.com/PowerShell/PowerShell/pull/6660 https://github.com/PowerShell/PowerShell/pull/6660] で扱われており、結局pwshでは-WorkingDirectoryというパラメータが追加された。[https://github.com/PowerShell/PowerShell/issues/14091 https://github.com/PowerShell/PowerShell/issues/14091]にある以下の文字列をレジストリに書いたところ、正しく動作したので、pwshではこれでよい。
<code>pwsh.exe -NoExit -RemoveWorkingDirectoryTrailingCharacter -WorkingDirectory "%V!" -Command "$host.UI.RawUI.WindowTitle = 'PowerShell 7 (x64)'"</code></li></ul>

wtで
<code>hiderun powershell -Command "& {wt powershell -noexit -Command Set-Location -LiteralPath ('\"'''+($args[1] -replace '''', '''''' -replace '%%', '==%%' -replace ';', '\;' )+'''.Replace(''==%%'',''%%'')\"')}" --%% "\"%V\""</code></li>
<li>cmd
wtで。標準入力のときとほぼ同じ。
<code>powershell -Command "& {$bak=$env:MY_PERCENT;$mypath=$args[1].Trim('\"'); $env:MY_PERCENT = '%%';if ($mypath.Length -gt 258) { $mypath = cmd /c \"for %%A in (`\"$($mypath.Replace('%%', '%%MY_PERCENT%%'))`\") do @echo %%~sA\" };$env:MY_PERCENT = $bak;wt -d ($mypath -replace ';', '\;') cmd}" --%% "\"%V\""</code>
<ul>
<li>デフォルトターミナルで
startatdir.vbsを使う。
<code>powershell -Command "& {$bak=$env:MY_PERCENT;$mypath=$args[1].Trim('\"'); $env:MY_PERCENT = '%%';if ($mypath.Length -gt 258) { $mypath = cmd /c \"for %%A in (`\"$($mypath.Replace('%%', '%%MY_PERCENT%%'))`\") do @echo %%~sA\" };$env:MY_PERCENT = $bak; wscript 'C:\path\to\startatdir.vbs' cmd ('\"'+$mypath+'\"')}" --%% "\"%V\""</code></li>
<li>Windowsにもともと入っているメニューでは以下。
<code>cmd.exe /s /k pushd "%V"</code>
これは（<code>\\?\</code>が付くパスを除いて）ほとんどの場合に正しく機能するが、<code>%PATH%</code>のような文字列が含まれているフォルダではうまくいかない。ちなみにpushdによりUNCパスには自動的にネットワークドライブが割り当てられる。</li></ul>
</li>
<li>Git Bash
<ul>
<li>mintty（git-bash.exe使用）
<code>"C:\Program Files\Git\git-bash.exe" -c "IFS=;cd $(echo $*|/bin/sed 's/\\\\/\\\\\\\\/'|/bin/cygpath -f -);exec bash" -- "%V</code>
<ul>
<li>Git Bashのインストーラにより設定される「Git Bash Here」メニューでは以下のようになっている。
<code>"C:\Program Files\Git\git-bash.exe" "--cd=%v."</code>
これは、特殊文字にはすべて対応しているが、（NoWorkingDirectoryをつけたとしても）<code>\\?\</code>で始まるパスではうまくいかない。最後の「.」はよくわからないがこれを付けておくと<code>--cd</code>がうまくやってくれるっぽい。</li></ul>
</li>
<li>デフォルトシェルで
<code>"C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=;cd $(echo $*|/bin/sed 's/\\\\/\\\\\\\\/'|/bin/cygpath -f -);export MSYSTEM=MINGW64;exec /bin/bash --login" -- "%V</code></li>
<li>wtで
<code>hiderun "C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=;LANG=en_US.UTF8; echo $*|/bin/sed 's/\\\\/\\\\\\\\/'|/bin/cygpath -f -|printf %%q $(/bin/sed 's/%%/=%%/g')|/bin/sed 's/;/\\\\;/g'|/bin/xargs -d '\n' -I {} -- wt \"C:\Program Files\Git\usr\bin\env.exe\" MSYSTEM=MINGW64 \"C:\Program Files\Git\usr\bin\bash.exe\" --login -i -c 'IFS=\\;cd $(echo {}|sed s/=%%/%%/g)\\;exec bash'" -- "%V</code></li></ul>
</li>
<li>Cygwin
<ul>
<li>デフォルトシェルで
<code>"C:\cygwin64\bin\sh.exe" --login -c "IFS=;cd $(echo $*|/bin/sed 's/\\\\?/\\\\\\\\?/'|/bin/cygpath -f -);exec bash" -- "%V</code>
<ul>
<li>置換の対象を<code>\\?\</code>のみとするためsedの引数に<code>?</code>が増えている</li></ul>
</li>
<li>wtで
<code>hiderun "C:\cygwin64\bin\sh.exe" -c "IFS=;echo $*|/bin/sed 's/\\\\?/\\\\\\\\?/'|/bin/cygpath -f -|printf %%q $(/bin/sed 's/%%/=%%/g')|/bin/sed 's/;/\\\\;/g'|/bin/xargs -d '\n' -I {} -- wt \"C:\cygwin64\bin\bash.exe\" --login -i -c 'IFS=\\;cd $(echo {}|sed s/=%%/%%/g)\\;exec bash'" -- "%V</code></li></ul>
</li></ul>

==== 管理者権限 ====

<ul>
<li>PowerShell
<code>powershell -Command "& {Start-Process -Verb Runas -Filepath wt -Argumentlist powershell, -noexit, -command, Set-Location, -LiteralPath, ('\"'''+($args[1].Trim('\"') -replace '''', '''''' -replace ';', '\;' -replace '%%', '==%%')+'''.Replace(''==%%'',''%%'')\"')}" --%% "\"%V\""</code>
環境変数の置換を抑止する必要がある。デフォルトシェルで起動するならこれは不要（で、wtでないので<code>;</code>のエスケープも不要）で、以下のようになる。
<code>powershell -Command "& {Start-Process -Verb Runas -Filepath powershell -Argumentlist '-noexit', '-command', Set-Location, '-LiteralPath', ('\"'''+($args[1].Trim('\"') -replace '''', '''''' )+'''\"')}" --%% "\"%V\""</code>
<ul>
<li>MyInvocationを使う例
<code>powershell -Command "& {$spl = $MyInvocation.Line -split'\"'; Start-Process -Verb Runas -Filepath powershell -Argumentlist '-noexit', '-command', Set-Location, '-LiteralPath', ('\"'''+($spl[$spl.Length-2] -replace '''', '''''' )+'''\"')}" --%% "\"%V\""</code></li>
<li>vbsの例
次の節で解説する「（自分が起動された）カレントディレクトリでの起動」にも対応している（引数がない場合）。
<syntaxhighlight lang="vb.net">Dim objShell
Dim curDir

Set ws = CreateObject("Wscript.Shell")
Dim dir
If WScript.Arguments.Count = 0 Then
dir = ws.CurrentDirectory
Else
dir = Wscript.Arguments(0)
End If
dir = Replace(dir,"%","==%")
ws.run "powershell -Command ""& {Start-Process -Verb Runas -Filepath wt -Argumentlist powershell, -noexit, -command, Set-Location, -LiteralPath, ('\""'''+($args[1].Trim('\""') -replace '''', '''''' -replace ';', '\;' )+'''.Replace(''==%'',''%'')\""')}"" --% ""\"""&dir&"\""""", vbHide

Set objShell = Nothing</syntaxhighlight></li></ul>
</li>
<li>cmd
<code>powershell -Command "& {$bak=$env:MY_PERCENT;$mypath=$args[1].Trim('\"'); $env:MY_PERCENT = '%%';if ($mypath.Length -gt 258) { $mypath = cmd /c \"for %%A in (`\"$($mypath.Replace('%%', '%%MY_PERCENT%%'))`\") do @echo %%~sA\" };$env:MY_PERCENT = $bak;Start-Process -Verb Runas -Filepath wt -Argumentlist '-d', ('\"'+($mypath -replace '\\$','\\\\' -replace ';', '\;')+'\"'), cmd}" --%% "\"%V\""</code>
この場合も<code>C:\</code>のための対処（<code>-replace '\\$','\\\\'</code>）が必要である。デフォルトシェルなら、startatdir.vbsを使う。
<code>powershell -Command "& {$bak=$env:MY_PERCENT;$mypath=$args[1].Trim('\"'); $env:MY_PERCENT = '%%';if ($mypath.Length -gt 258) { $mypath = cmd /c \"for %%A in (`\"$($mypath.Replace('%%', '%%MY_PERCENT%%'))`\") do @echo %%~sA\" };$env:MY_PERCENT = $bak;Start-Process -Verb Runas -Filepath wscript -Argumentlist '//Nologo', 'C:\path\to\startatdir.vbs', 'cmd', ('\"'+$mypath+'\"')}" --%% "\"%V\""</code></li>
<li>Git Bash
理論上はワンライナーでも書けるが、エスケープが面倒すぎるのでファイルに書いたほうがよいだろう。まずレジストリの中身は以下のようにする。
<code>"C:\Program Files\Git\usr\bin\sh.exe" "C:\path\to\gb-wt-admin.sh" "%V"</code>
で、<code>gb-wt-admin.sh</code>の中身は以下。
<syntaxhighlight lang="bash">#!/bin/sh
IFS=
LANG=en_US.UTF-8
echo $*|/bin/sed 's/\\/\\\\/'|/bin/cygpath -f -|printf %q $(/bin/cat) |/bin/sed "s/'/''/g;s/%/==%/g;s/;/\\\\;/g"|/bin/xargs -d '\n' -I {} powershell -Command Start-Process -Filepath wt -ArgumentList "'"'"C:\Program Files\Git\usr\bin\env.exe"'"'" , '"MSYSTEM=MINGW64"' , "'"'"C:\Program Files\Git\usr\bin\sh.exe"'"'" , "'--login'", "'-c'", "'"'"IFS=\;cd $(echo {}| /bin/sed s/==%/%/g) \; exec bash"'"'"</syntaxhighlight>
Cygwinも同様である。</li></ul>


==== VS Codeのメニュー（おまけ） ====

「Code で開く」メニューのcommand値は以下のように設定されている。

<code>"C:\Program Files\Microsoft VS Code\Code.exe" "%V"</code>

これは特殊文字などに関しても問題なく動作するうえ、実はそのまま<code>\\?\</code>が付いたパスにも適用可能である。従って、<code>VSCode</code>キーに<code>NoWorkingDirectory</code>値を設定する（設定の書き換えまたはHKCUによるオーバーライド）だけで、長大フォルダでもVS Codeが使えるようになる。ターミナルの起動には失敗してしまうがファイル・フォルダの作成・編集などの基本操作がGUIでできるので意外と便利（もちろん、他のBetter Explorer的なツールを使う手もあるだろう）。


== 3. エクスプローラーのアドレスバーから ==

このときは、末尾が空白のパスや<code>\\?\</code>が必要な長大パスやちょうど259文字のフォルダはそもそも対応していないので考えなくてよい。しかし通常のネットワークファイル向けのUNCパス（<code>\\192.168.1.1\disk</code>など）に対応する必要はあるので、cmdをベースにすることはできない（cmdの中に入った時点でカレントディレクトリが変わってしまう）。また<code>``</code>が含まれるパスをカレントディレクトリにできないことから、powershell.exeもベースとしては使えない。

なので、パイプを使って先ほどの<code>openterm</code>にむけて流し込もうと思ったら選択肢はpwsh.exeかpiperunかCygwin系だけである。それぞれの書き方は以下のようになる。

<ul>
<li>pwsh
<code>pwsh -Command $pwd.Path.Replace('Microsoft.PowerShell.Core\FileSystem::\\', '\\') | openterm</code></li>
<li>piperun
<code>piperun pwsh -Command $pwd.Path.Replace('Microsoft.PowerShell.Core\FileSystem::\\', '\\') | openterm</code>
上とほぼ変わっていないが、pwshはディレクトリの取得だけで使っているので<code>openterm</code>のところで環境変数が汚染されるのを防げる。</li>
<li>Cygwin/Git Bash
<code>"C:\Program Files\Git\usr\bin\sh.exe" -c "cmd //c \"chcp 65001 > nul\"| pwd | /bin/cygpath -w -f - | openterm"</code>
<ul>
<li>一つ問題があり、hiderunを使う（コンソールを非表示にする）とchcpが効かないようで、<code>openterm</code>でPowerShellの<code>$input</code>を使っているとUnicode文字が化けてしまう。</li>
<li>先ほどの<code>openterm</code>部分で先頭にcygpathが入っているものを使うときは、そちらのcygpathとこちらでのcygpath -wは打ち消し合って無駄なので消してよい。</li></ul>
</li></ul>

このほかにvbs(wscript)もカレントディレクトリの取得のところは問題なくやってくれるので、それをさっきのWscript.Arguments(0)のかわりに使えばよい。

最初に表示されるコンソールを非表示にしたければ、<code>hiderun</code>を付けてrunother経由で実行するのが手軽だが、前述の通りvbsも拡張子無しで呼び出せるように設定できるので、そうした上でvbHideで隠してもよい。


=== 管理者権限なし ===


==== cmd ====

これは普通にcmdと打てばよい。

（デフォルトシェルがconhostだとして）wtで開きたいときは、;をエスケープして-dで渡す。以下の通りbatファイルを作ってpathを通す。

<code>chcp 65001 & cd | powershell -Command wt -d $input.Replace(';','\;') cmd</code>

wtではなくconhostの場合はconhost cmdだけでよい。batにするなら<code>start "" conhost cmd</code>でよい。

コンソール非表示ならcmd /cをつけてhiderunする。runotherで、txtの中身は以下の通り。

<code>hiderun cmd /c chcp 65001 & cd | powershell -Command wt -d $input.Replace(';','\;') cmd</code>


==== powershell, pwsh ====

pwshはそのままpwshと打てばよい。powershell及びwtやconhostを明示的に指定する場合について以下で述べる。

たとえばwtでpwshなら、runotherを使って、txtの内容は以下。

<code>hiderun pwsh -Command wt -d $pwd.Path.Replace('Microsoft.PowerShell.Core\FileSystem::\\', '\\').Replace(';', '\;') pwsh</code>

powershellの場合は<code>``</code>に対応するため起動後に移動する。runotherでpiperunを使って、txtは以下。最終的に起動する方のpowershellで<code>==%</code>を<code>%</code>に戻している。

<code>hiderun piperunex cmd /c chcp 65001 | printcd | powershell -Command wt powershell -noexit -command Set-Location -LiteralPath ('"'''+($input -replace ';', '\;' -replace '''', '''''' -replace '%', '==%')+'''.Replace(''==%'',''%'')"')</code>

pwshが使えるならprintcdのかわりに<code>pwsh -Command $pwd.Path.Replace('Microsoft.PowerShell.Core\FileSystem::\\', '\\')</code>でもよい。

以下はpiperunを使わずshでやる例。前述の通りパイプからPowerShell側で<code>$input</code>を使って受け取ると文字化けするので引数として渡す。

<code>hiderun "C:\Program Files\Git\usr\bin\sh.exe" -c "WD=$(pwd | /bin/cygpath -w -f - | /bin/sed \"s/;/\\\\\\\\;/g; s/'/''/g; s/%/==%/g\"); wt powershell -noexit -command Set-Location -LiteralPath $\"'$WD'.Replace('==%','%')\"$"</code>


==== Git Bash/Cygwin ====

Git Bashは<code>--login</code>をつけてもカレントディレクトリを維持するので単純である。以下をrunotherのtxtに書く。

<code>"C:\Program Files\Git\usr\bin\env.exe" MSYSTEM=MINGW64 /bin/bash --login</code>

Cygwinは起動後にcdする。そのかわり<code>export MSYSTEM=MINGW64</code>が不要。

<code>"C:\cygwin64\bin\sh.exe" -c "IFS=;/bin/bash --login -i -c 'cd '$(/bin/printf %q `pwd`)'; exec bash'"</code>

printfで一旦エスケープしたものをcdの後につなげてそのまま渡している。

<ul>
<li>wtで
<ul>
<li>Git Bash
<code>wt "C:\Program Files\Git\usr\bin\env.exe" MSYSTEM=MINGW64 "C:\Program Files\Git\usr\bin\bash.exe" --login"</code>
<ul>
<li>あれ、wtなのにカレントディレクトリ維持されてる…？wt cmdではダメなのだが…</li></ul>
</li>
<li>Cygwin
<code>hiderun "C:\cygwin64\bin\sh.exe" -c "IFS=;WD=$(printf %q `pwd` | /bin/sed \"s/;/\\\\\\\\;/g; s/%/==%/g\"); wt \"C:\cygwin64\bin\bash.exe\" --login -c 'IFS=\\;cd $(echo '$WD'|sed s/==%/%/g)\\; exec bash'"</code></li></ul>
</li></ul>

=== 管理者権限あり ===


==== cmd ====

runotherを使って以下の通り。

<code>hiderun cmd /c "chcp 65001 > nul & cd | powershell -Command Start-Process -Verb Runas -Filepath wt -ArgumentList '-d', ('\"'+$input.TrimEnd('\\').Replace(';','\;')+'\"'), cmd"</code>

<code>TrimEnd('\\')</code>のところは<code>C:\</code>の末尾のバックスラッシュへの対応である（<code>wt -d "C:"</code>は通らないので一見ダメそうだが、なぜかこれで動く。原因不明。）。

batならそのまま以下の通り（黒い画面が一瞬出てしまう）。

<code>chcp 65001 & cd | powershell -Command Start-Process -Verb Runas -Filepath wt -ArgumentList '-d', ('\"'+$input.TrimEnd('\\').Replace(';','\;')+'\"'), cmd</code>

別解としてパイプを使わないものも載せておこう。cmdでは特殊文字ではないので<code>'</code>を<code>''</code>に変えるのは簡単である。

<code>hiderun cmd /c powershell -Command "& {Start-Process -Filepath wt -Verb Runas -ArgumentList '-d', ('\"'+$args[0].TrimEnd('\\').Replace(';','\;')+'\"'), cmd}" -- "'%CD:'=''%'"</code>

以下もうまくいく。cmdの<code>"</code>に関する仕様により、例えばStart-Processの直前に<code>echo '\"';</code>のような<code>"</code>を奇数個含む文字列を入れると動かなくなる。argsを使うとバッククォートがうまくいかなかったのでMyInvocationを使ってみる。

<code>hiderun cmd /c powershell -Command "& {$spl=$MyInvocation.Line.Split('\"'); Start-Process -Filepath wt -Verb Runas -ArgumentList '-d', ('\"'+$spl[$spl.Length-2].TrimEnd('\\').Replace(';','\;')+'\"'), cmd}" -- "\"%CD%\""</code>


==== powershell, pwsh ====

UNC非対応でよく、かつ（<code>``</code>をカレントディレクトリとして起動できる）pwshでよければ、上記のcmdをpwshに変えればよい。powershellならSet-Locationで移動が必要。以下をrunotherのtxtに書く。

<code>hiderun cmd /c "chcp 65001 & cd | powershell -Command Start-Process -Verb Runas -Filepath wt -ArgumentList 'powershell', '-noexit', '-command', 'Set-Location', '-LiteralPath', ('\"'''+($input -replace '''', '''''' -replace '%', '==%' -replace ';', '\;' )+'''.Replace(''==%'',''%'')\"')"</code>

UNC対応なら、管理者でないときと同じで、PSReadLineのエラーを回避するためpwshを一貫して使うのがいいだろう。

<code>hiderun pwsh -Command Start-Process -Verb Runas -Filepath wt -ArgumentList '-d', ('\"'+$pwd.Path.Replace('Microsoft.PowerShell.Core\FileSystem::\\', '\\').TrimEnd('\\').Replace(';','\;')+'\"'), pwsh</code>

powershellならpiperunを使う。カレントディレクトリの取得にpwshを使っているがprintcdでもよい。

<code>hiderun piperunex cmd /c chcp 65001 | printcd | powershell -Command Start-Process -Verb Runas -FilePath wt -ArgumentList powershell, -noexit, -command, Set-Location, -LiteralPath, ('\"'''+($input -replace ';', '\;' -replace '''', '''''' -replace '%', '==%')+'''.Replace(''==%'',''%'')\"')</code>

shなら以下。

<code>hiderun "C:\Program Files\Git\usr\bin\sh.exe" -c "WD=$( pwd | /bin/cygpath -w -f - | /bin/sed \"s/;/\\\\\\\\;/g; s/'/''''/g; s/%/==%/g\"); powershell -Command Start-Process -Verb Runas -Filepath wt -Argumentlist powershell, -noexit, -command, Set-Location, -LiteralPath, $\"'\\\"''$WD''.Replace(''==%'',''%'')\\\"'\"$"</code>


==== Git Bash ====

runotherとpiperunで以下。

<code>hiderun piperunex "C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=; LANG=en_US.UTF8; pwd || printf %q $(/bin/cat)" | "C:\Program Files\Git\usr\bin\sed.exe" "s/'/''/g;s/%/==%/g;s/;/\\\\;/g" | "C:\Program Files\Git\usr\bin\xargs.exe" -d '\n' -I {} -- powershell -Command Start-Process -Verb Runas -Filepath wt -ArgumentList '"C:\Program Files\Git\usr\bin\sh.exe"','-c', "'"'"IFS=\\; export MSYSTEM=MINGW64\\;cd $(echo {}|| /bin/sed s/==%/%/g)\\; exec /bin/bash --login"'"'"</code>

* <code>MSYSTEM=MINGW64</code>をもっと手前で設定して、<code>-ArgumentList</code>で<code>--login</code>を指定して、最後を<code>exec bash</code>にしてもよい。

piperunを使わずにshで頑張ることもできるが、エスケープが多く読みづらくなる。

<code>hiderun "C:\Program Files\Git\usr\bin\sh.exe" -c "IFS=; LANG=en_US.UTF8; pwd | printf %q $(/bin/cat) | /bin/sed \"s/'/''/g;s/%/==%/g;s/;/\\\\\\\\;/g\" | /bin/xargs -d '\n' -I {} -- powershell -Command Start-Process -Verb Runas -Filepath wt -ArgumentList '\"C:\Program Files\Git\usr\bin\sh.exe\"','-c', \"'\"'\"IFS=\\; export MSYSTEM=MINGW64\\;cd $(echo {}| /bin/sed s/==%/%/g)\\; exec /bin/bash --login\"'\"'\" "</code>

Cygwinも同様。

== 関連 ==

[https://qiita.com/octopath9/items/4b7fe797ae1155c69dd9 コマンドプロンプトから管理者権限のコマンドプロンプトに切り替える - Qiita]

[https://qiita.com/tmiki/items/0dab4fd17e9bed04ed91 【Windows】GitBashをcontext menuからAdministrator権限付きで実行する - Qiita]

[https://note.com/redpeak/n/n5ddc3673117b エクスプローラーから管理者権限でコマンドプロンプトを開く方法｜ひるあんどん]
[[Category:IT]][[Category:Windows]]{{#seo:|title={{FULLPAGENAME}} - Turgenev's Wiki}}

HTTP・SOCKS・透過プロキシ・UDP

2025-04-02T08:28:25Z

Turgenev: Notion-MW

HTTP・SOCKS・透過プロキシ・UDP

2025-04-02T08:04:44Z

Turgenev: Notion-MW

SOCKS・透過プロキシ・UDP-over-TCPなどを中心に、ネットワークの変更に使えるプロキシ関連の各種技術を雑にまとめた。

近年はGo製のものが多い。また検閲に対抗するためか、中国系（中国語でissueが投稿されているなど）のものが多い。gost, go-proxy, hysteria, txthinking/socks5, things-go/socks5などはいずれもその2つに当てはまる。たまにロシア系もある。


== 大規模・多機能系 ==

以下のものは機能が多くて分類できないのでソフトウェアごとに紹介する。

==== gost ====

GO Simple Tunnelの略らしい。安定版のv2系（[https://github.com/ginuerzh/gost https://github.com/ginuerzh/gost], [https://v2.gost.run/ https://v2.gost.run/]）と開発中のv3系（[https://github.com/go-gost https://github.com/go-gost], [https://gost.run/ https://gost.run/]）で大きく仕様が異なる。v3は開発中と言いつつv2系のページを見るとかなりv3推しに見える。

starはバージョン2が16k、バージョン3が5kほど。

イメージとしては、TCPによるシンプルなトンネルプロトコル（これがgost）（暗号化無し）と他の大量のプロトコルの間の相互変換を実装しているような感じと思われる。

非常に多機能で、このページで紹介している多くソフトウェアの基本機能をカバーしていると言ってもいいくらい。UDP-over-TCP系は基本これ1つで十分。機能の豊富さに比して明らかにドキュメントが不足しており、エラーメッセージも親切ではない（起動時ではなく実際にパケットが来てからエラーが出るような感じ）。

<ul>
<li>connectorとしてはsocks5も用意されているが、相手がgostでない限りUDP Associateは動かない模様。具体的には
<syntaxhighlight lang="javascript">gost -L "auto://:8480?udp=true&relay=udp" -F socks5://192.168.1.13:3129</syntaxhighlight>
などとしても、 05f3 0001 0000 0000 0000みたいなよくわからんリクエストが送られてしまう。このf3のところは下記の独自拡張っぽい。
[https://github.com/go-gost/x/blob/04d1587a77964636d8e50f5cce475ee8621bece7/internal/util/socks/socks.go#L17 https://github.com/go-gost/x/blob/04d1587a77964636d8e50f5cce475ee8621bece7/internal/util/socks/socks.go#L17]</li></ul>

==== go-proxy ====

[https://github.com/snail007/goproxy https://github.com/snail007/goproxy]

これも見た感じgostと同じくらいか一部では上回るくらい多機能に見えるが、この雰囲気にしては珍しく有料版があり、無料版だと一部機能が制限されているようなので、あまり使ったことはない。


== GFW回避 ==

中国政府の検閲システムであるグレート・ファイアウォール（GFW）に対抗することを主な目的とするもの。

==== shadowsocks ====

SOCKSに暗号化を施した独自プロトコルで、いくつかの実装がある。[https://github.com/shadowsocks/shadowsocks-rust https://github.com/shadowsocks/shadowsocks-rust]などが主流とみられる。

VPN以外のGFW回避ソフトウェアだとおそらくもっともメジャー。

サーバーとクライアントに分かれていて、クライアント側では透過プロキシにも対応している。


==== Hysteria ====

通信路がHTTP/3に偽装した形で暗号化される。shadowsocksの次世代に位置付けられるソフトウェアのように見える。

SOCKS5サーバー部分にはtxthinking/socks5を使っている。


== SNI Proxy ==

HTTP・HTTPSのリバースプロキシで、host（HTTPの場合）あるいはsni（HTTPSの場合）に基づいてアクセスを振り分けるものをSNI Proxyと呼ぶことがあるらしい。NginxやHAProxyのような汎用のプロキシサーバーでも使える機能だが、これを専門とするソフトウェアもある。

* こんな使い方もある（自分の記事）→ [https://turgenev.hatenablog.com/entry/2025/03/21/020550 【Android】NextDNSをアプリごとに有効無効切り替え+Tailscale経由の自宅鯖を使ってControl D風のトラフィック転送 - turgenev’s blog]


==== dlundquist/sniproxy ====

[https://github.com/dlundquist/sniproxy https://github.com/dlundquist/sniproxy]　starは2.6kほど。2024年に更新あり。非推奨である理由（HTTP/2とかQUICでうまくいかないとか）も書いてある。

==== tcpproxy ====

[https://github.com/inetaf/tcpproxy https://github.com/inetaf/tcpproxy]　starは1.3kほど。ライブラリ用途がメインか。


==== ameshkov/sniproxy ====

[https://github.com/ameshkov/sniproxy https://github.com/ameshkov/sniproxy]　starは70ほど。上流のSOCKS5, HTTPプロキシへの転送機能がある。


==== puxxustc/sniproxy ====

[https://github.com/puxxustc/sniproxy https://github.com/puxxustc/sniproxy]　starもほぼなく更新も9年前。


== SOCKSプロキシサーバー ==


==== Dante ====

[https://www.inet.no/dante/index.html Dante - A free SOCKS server]

企業（Inferno Nettverk A/S）によるオープンソースなSOCKS5実装で、有償サポートまであるらしい。見るからに古臭いHPで、メンテされているかどうか不安になるが、つい最近2024年末にもアップデートがあり、次期バージョンの計画についても記載されている。

Cで書かれていて、おそらく最も正確なSOCKS5実装だろう。コメントも親切で、リファレンス実装のような雰囲気がある。他の透過プロキシクライアントなどをテストする際はDanteでテストして動けば安心感がある。


==== OpenSSH ====

現実的に最もよく使われているSOCKSサーバーは間違いなくOpenSSHだろう。しかし、UDP-over-TCPの問題があるため、UDPはサポートされていない。

ssh -Dでforward方向のプロキシを建てるのが有名だが、OpenSSH 7.6からは-Rでreverse方向にも建てられるようになった。クライアント側が7.6以上であればよい。

* 参考: [https://www.openssh.com/txt/release-7.6 OpenSSH 7.6] （<code>ssh(1): add support for reverse dynamic forwarding</code>）

==== socks-with-udp-over-ssh ====

[https://github.com/ge9/socks-with-udp-over-ssh https://github.com/ge9/socks-with-udp-over-ssh]

TCP接続（あるいは任意のバイトストリーム）の上にUDP付きのSOCKS5を通すために自分が実装したツール。サーバー側とクライアント側に分かれている。しかし実装した後にgostで同じことができることに気付いた。

経緯・使い方などは[https://turgenev.hatenablog.com/entry/2024/05/12/231208 root権限のないssh上にUDPを通す方法について（ポートフォワード、SOCKS5プロキシなど） - turgenev’s blog]に書いてある。

==== 3proxy ====

[https://3proxy.ru/ 3proxy tiny free proxy server for Windows, Linux, Unix: SOCKS, HTTP, FTP proxy]

[https://github.com/3proxy/3proxy https://github.com/3proxy/3proxy]

ロシア系。エラーメッセージなどがかなり不親切だが、ちゃんと動くソフト。

==== fast-socks5 ====

[https://github.com/dizda/fast-socks5 https://github.com/dizda/fast-socks5] Rust製では最も有名か。starは500ほど。使ったことなし


==== txthinking/socks5 ====

[https://github.com/txthinking/socks5 https://github.com/txthinking/socks5]

starは700前後。hysteriaやtrojan-goなどいくつかの大きなプロジェクトで使われており、go製のSOCKS5関連ライブラリでは一番メジャーか。

クライアントもある。

自分のfork（[https://github.com/ge9/socks5 https://github.com/ge9/socks5]）ではFull Cone NATを追加した


==== armon/go-socks5 ====

[https://github.com/armon/go-socks5 https://github.com/armon/go-socks5]

starは2kだが、最終更新2016年でUDP Associateも無し。Wireproxyで以前使われていたが使われなくなった（[https://github.com/whyvl/wireproxy/issues/15 https://github.com/whyvl/wireproxy/issues/15]）。

ここからフォークされたものが複数ある。


==== things-go/go-socks5 ====

[https://github.com/things-go/go-socks5 https://github.com/things-go/go-socks5]

armon/go-socks5からのフォーク（GitHub上ではfork扱いではない）。starは400個ほど。UDP Associateはサポートしているがバグあり（自分のPRが採用されるかどうかで揉めてる[https://github.com/things-go/go-socks5/pull/63 https://github.com/things-go/go-socks5/pull/63]）。

Wireproxyで使われている。

自分のフォーク [https://github.com/ge9/go-socks5 https://github.com/ge9/go-socks5] ではFull Cone NATを追加した


==== haxii/socks5 ====

[https://github.com/haxii/socks5 https://github.com/haxii/socks5]

armon/go-socks5からのfork。UDP Associate対応。starは50個前後。最終更新2019年。


==== wzshiming/socks5 ====

[https://github.com/wzshiming/socks5 https://github.com/wzshiming/socks5]

クライアントもある。

starは90個ほど。最終更新2024年。

とりあえずredsocksと組み合わせでUDP透過プロキシ動作確認済。

Wireproxyで使用が検討された（[https://github.com/whyvl/wireproxy/issues/15 https://github.com/whyvl/wireproxy/issues/15]）が結局使用されず。


==== haochen233/socks5 ====

[https://github.com/haochen233/socks5 https://github.com/haochen233/socks5]

クライアントもある。

UDP Associateはサポートしているが、starは49とさらに少なく、最終更新も2021年。

同じくWireproxyで使用が検討された（[https://github.com/whyvl/wireproxy/issues/15 https://github.com/whyvl/wireproxy/issues/15]）が結局使用されず。

=== tun系 ===

==== tun2proxy ====

[https://github.com/tun2proxy/tun2proxy https://github.com/tun2proxy/tun2proxy]


== 透過SOCKSプロキシクライアント ==

[https://turgenev.hatenablog.com/entry/2024/03/25/160556 透過プロキシを用いて特定アプリケーションのTCP・UDP通信をSOCKS5経由にする方法（Windows・Linux（iptables TPROXY）・Androidなど） - turgenev’s blog]で扱った内容。

バックにSOCKS(SOCKS5)プロキシを用いてTCP・UDPのレイヤで透過プロキシを行うもの。基本的には管理者権限（最低でもCAP_NET_ADMIN）が必要。

==== redsocks ====

[https://github.com/semigodking/redsocks semigodking/redsocks] （fork元の[https://github.com/darkk/redsocks darkk/redsocks]はメンテされておらず、TCPのTPROXYに非対応）

*nix対応。BSD系で動かすことができたという話は[https://turgenev.hatenablog.com/entry/2024/06/10/134017 FreeBSD/OpenBSD/NetBSDで透過プロキシのredsocksを動かしてみる - turgenev’s blog]に書いた。


==== ProxiFyre ====

[https://github.com/wiresock/proxifyre https://github.com/wiresock/proxifyre] Windows用の透過SOCKSクライアント。管理者権限必要。TCP/UDP両方対応。インストールも簡単で、よくできている。

==== hev-socks5-tproxy ====

[https://github.com/heiher/hev-socks5-tproxy https://github.com/heiher/hev-socks5-tproxy] Linux向け。redsocksより若干知名度は下がるものの、きちんとメンテされている。


==== Proxifier ====

[https://www.proxifier.com/ https://www.proxifier.com/] 見た感じ機能は十分そうだが、有料なので試していない。

== ライブラリ関数ハック系 ==

ライブラリ関数レベルでの置き換えになるため厳密性・安定性に欠ける（異常終了する場合もある）ものの、root権限がない場合に有効な手法。


=== Linux（LD_PRELOAD） ===

libc依存でないプログラム（Go製のものなど）には効かない。

==== socksify ====

後述のDanteの一部。UDP/TCP両対応。唯一のUDP対応のものである。

<syntaxhighlight lang="go">route {
from: 0.0.0.0/0 to: 0.0.0.0/0 via: 192.168.1.1 port = 1080
}</syntaxhighlight>
こんな感じの<code>/etc/socks.conf</code>を作るか、<code>SOCKS5_SERVER=192.168.1.1:1080 socksify curl http://ipv4.icanhazip.com</code> とかでもよい。

Macでも動くはずだが、筆者が唯一試したMac環境ではcurlに対してさえうまく動作しなかった（socksifyを使わないのと全く同様に動作するだけだった）（<code>DYLD_FORCE_FLAT_NAMESPACE=1</code>は指定している）。


==== proxychains-ng(proxychains) ====

ngはnew generationの略で、proxychainsの後継である。ただしコマンド名はproxychains4である。

多段プロキシを構成するためのソフトウェア。

UDP非対応（[https://github.com/rofl0r/proxychains-ng/issues/336 https://github.com/rofl0r/proxychains-ng/issues/336]）。ただしDNSに対応したproxy_dnsというオプションがあり、これを有効にするとDNS以外のUDP通信が正常に機能しなくなる副作用がある（[https://github.com/rofl0r/proxychains-ng/issues/103 https://github.com/rofl0r/proxychains-ng/issues/103]）。


==== torsocks(tsocks) ====

多分、メンテされていないtsocksがTorに取り込まれてtorsocksになったような感じ。tsocksは非常に古く、多分2010年以降には更新されていないが、知名度は高く、今でも多分そこそこ使われてそう。

torsocksはアクティブなはず。ただし、Torでない普通のSOCKS5を指定しても動かないようである（やり方が悪いかも）。

tsocksはUDPには対応していない。torsocksもそうだが、まずそもそもTor自体がUDPに対応していない。


=== Windows（DLL Hijacking） ===

どのDLLを置き換えたらいいか自明ではなさそうなので、LD_PRELOADと違って対象とするソフトウェアごとに実装が必要そう。そもそも不可能なソフトウェアもLD_PRELOADの場合より多そう。よく見かけるのはDiscordを対象にしたもので、ロシア系のものが多い。筆者は使ったことがない。

==== discord-drover ====

[https://github.com/hdrover/discord-drover https://github.com/hdrover/discord-drover]

==== discord-voice-proxy ====

[https://github.com/runetfreedom/discord-voice-proxy https://github.com/runetfreedom/discord-voice-proxy]


== HTTPプロキシ ==

Squid, Privoxyなどが有名。

Squidには透過プロキシ機能があるが、redsocksなどとは動作の細かい部分が異なる。[https://turgenev.hatenablog.com/entry/2025/03/25/171736 squidで透過プロキシ（intercept, tproxy）を動かす - turgenev’s blog]に書いた。


== SOCKS関連の話題 ==


==== SOCKS5によるドメイン解決 ====

SOCKS5（SOCKS4aも？）では、クライアントがCONNECTなどの要求をする際、接続先をIPアドレスではなくホスト名（ドメイン名）で指定することができる仕様になっている。これによりクライアント側ではなくSOCKS5サーバー側でドメイン解決が行われる。

Proxifyreやredsocksを普通に使う場合、TCP/UDPレイヤでのプロキシとなるので、この機能が使われることはない（[https://turgenev.hatenablog.com/entry/2025/03/25/171736 squidで透過プロキシ（intercept, tproxy）を動かす - turgenev’s blog]）。一方、Webブラウザなどでは、この機能が使われる場合がある（参照: [https://github.com/FelisCatus/SwitchyOmega/issues/2304 https://github.com/FelisCatus/SwitchyOmega/issues/2304]、[https://stackoverflow.com/questions/33099569/how-does-sock-5-proxy-ing-of-dns-work-in-browsers How does SOCK 5 proxy-ing of DNS work in browsers?]）。


==== ブラウザのSOCKS5プロキシのWebRTC対応 ====

基本的に現在主流のブラウザ（Firefox, Chrome）のSOCKS5プロキシ機能（拡張機能で設定する場合を含む）はUDPには対応していないため、Discordの通話などWebRTC関係の機能を使うと生IPが漏洩する（またはそれを防ごうとすると単にその機能が使えない）。これは原理的に実装が不可能なわけではなく、単に需要が少ないから実装されていないだけである。

* Chromeではどれが最新か不明（最近の物は少ない）。このへんとか？[https://issues.chromium.org/issues/41180783 Chromium]
* torのバグ報告 [https://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/151 https://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/151]
* firefoxの [https://bugzilla.mozilla.org/show_bug.cgi?id=1808692 https://bugzilla.mozilla.org/show_bug.cgi?id=1808692]
** QUIC関連 [https://bugzilla.mozilla.org/show_bug.cgi?id=1882071 https://bugzilla.mozilla.org/show_bug.cgi?id=1882071]
** 新しめの包括的なバグレポート [https://bugzilla.mozilla.org/show_bug.cgi?id=1947229 https://bugzilla.mozilla.org/show_bug.cgi?id=1947229]

従って、ブラウザのWebRTCをプロキシさせたい場合はVPNや透過プロキシなどroot/管理者権限が必要な手法を使うことになる。ただしLinux+Firefoxの場合はsocksifyが使えるのでrootが無くても可能。


==== UDP AssociateリクエストのDST.ADDRとDST.PORT ====

クライアントがサーバー側にUDP Associateリクエストをするとき、この2フィールドには通信したい宛先ではなく（←というかそもそもそれが複数ある場合もある）、クライアント側がUDP Associateに使用する予定のポートを入れる。指定しない場合（例えばNATがある場合、これを予測するのは難しくなる）は、全ビットを0に設定する必要がある。

これによってサーバー側は、UDPパケットが送られてきたタイミングでそれが事前に通知されたものと一致するかどうか確認できるというわけである。

この部分に誤ってクライアント側が通信したい宛先ポートを入れるよう実装していたSOCKS5クライアントがいくつかある。

* semigodking/redsocks…自分の[https://github.com/semigodking/redsocks/issues/210 https://github.com/semigodking/redsocks/issues/210]で修正済み。
* gost…[https://github.com/ginuerzh/gost/issues/96 https://github.com/ginuerzh/gost/issues/96]で修正済み。
* txthinking/socks5…[https://github.com/txthinking/socks5/issues/15 https://github.com/txthinking/socks5/issues/15]で修正済み。
* things-go/go-socks5…これはサーバー側。[https://github.com/things-go/go-socks5/issues/29 https://github.com/things-go/go-socks5/issues/29]の通り、クライアントが必ずアドレス・ポートを通知してくれる（ゼロ埋めしない）と仮定していたが、修正された。


== VPN(tun) ==


==== tun2proxy ====

[https://github.com/tun2proxy/tun2proxy https://github.com/tun2proxy/tun2proxy]

Rust製。starは700ほど。SOCKSとHTTPをtunにしてくれる。

==== hev-socks5-tunnel ====

[https://github.com/heiher/hev-socks5-tunnel https://github.com/heiher/hev-socks5-tunnel]

hev-socks5-tproxyの作者による。Androidアプリの[https://github.com/heiher/sockstun https://github.com/heiher/sockstun]もここから。

== プロキシプロトコル間の変換 ==

==== socks-to-http-proxy ====

[https://github.com/KaranGauswami/socks-to-http-proxy https://github.com/KaranGauswami/socks-to-http-proxy]

名前の通り、socksをhttpにしてくれる。starは250ほど。

==== privoxy ====

基本的にはHTTPプロキシソフトウェア。socksプロキシをhttpプロキシとして使えるようにする機能はあるが、より大がかり（一般ユーザーでの実行がしづらい）


== UDP・Wireguard関連 ==


==== UDPでサーバー→クライアントにデータ送信 ====

[https://github.com/prof7bit/udp-reverse-tunnel https://github.com/prof7bit/udp-reverse-tunnel]

これを使うと、サーバー側だけでポートが開けられるとしても事実上クライアント側で開けられるのと同等になるのでreverseをするのが楽になる

* [https://superuser.com/questions/1737943/how-to-create-a-reverse-udp-tunnel https://superuser.com/questions/1737943/how-to-create-a-reverse-udp-tunnel]
* どっちも開放できない場合、UDPホールパンチングで何とかするしかない

==== wgslirpy ====

[https://github.com/vi/wgslirpy https://github.com/vi/wgslirpy]

Slirp（ユーザーランドで動くPPPサーバーのようなもの）のような形で実装されたWireguardサーバー。rootなしでWireguardサーバーとして動作する。

==== wireproxy ====

[https://github.com/whyvl/wireproxy https://github.com/whyvl/wireproxy]

wgslirpyの逆のような（？）ツール。Wireguardクライアントであるが、SOCKSサーバーとして動作する。

依存ライブラリのUDP Associate対応が不完全（自分がプルリクを送っている）だが、クライアントによってはうまくUDP Associateが動く（[https://github.com/whyvl/wireproxy/issues/30 https://github.com/whyvl/wireproxy/issues/30]）。

<ul>
<li>自分でカスタマイズしてCone NATを加えたthings-go/go-socks5を使えば（<code>go.mod</code>で<code>replace github.com/things-go/go-socks5 => ../../go-socks5</code>などとする）、以下のようなコードをroutine.goのsocks5.Optionのところに追加することでCone NATにできる。
<syntaxhighlight lang="go">socks5.WithDialUDP(func(laddr, raddr *net.UDPAddr) (net.PacketConn, error) { return vt.Tnet.DialUDP(laddr, raddr) }),</syntaxhighlight></li></ul>


=== Wireguard通信の確立: 各パターンでのやり方 ===

各状況に応じて、2端末間でUDPの暗号化された通信路を確立するための方法を書いた。

* forwardは「クライアント→サーバー」、reverseは「サーバー→クライアント」という意味。「サーバー」は、「ポートが開放できる方」という意味合い。

==== どっちもrootあり ====

普通にWireguardを使う

==== サーバーのみrootあり ====

forward

サーバーはWireguard、クライアントは普通にWireproxyでいける

reverse

udp-reverse-tunnelで頑張って逆にする（あるいはホールパンチング）。

その上で、wgslirpyを使うか、Hysteriaを使うか

==== クライアントのみrootあり ====

↑さっきと逆

forward

wgslirpyを使うか、Hysteriaを使うか

reverse

udp-reverse-tunnelで頑張ったうえで普通にWireguardとWireproxy

==== どっちもrootなし ====

この場合そもそもWireguardを使うメリットはあまりないかも。というのとrootがないならポート開放も無理そう

forward

Hysteriaでいけそう。

reverse

udp-reverse-tunnelしてHysteria？かな
[[Category:IT]]{{#seo:|title={{FULLPAGENAME}} - Turgenev's Wiki}}

Sandbox4moved3

2025-04-02T07:56:31Z

Turgenev: Notion-MW

a
[[Category:sandbox]]{{#seo:|title={{FULLPAGENAME}} - Turgenev's Wiki}}

Notion2mdtest

2025-04-02T07:55:54Z

Turgenev: Notion-MW

head 
ここは常に表示

== 表示1 ==

content2e

=== 表示2 ===

==== 表示3作業中 ====

{{UnderConstruction|Notion2mdtest}}

==== 表示4 ====

content4

== 表示5 ==

==== レベル3作業中 ====

{{UnderConstruction|Notion2mdtest}}

== 見出し書式 ==

=== ===


==== BOLD ====

{{UnderConstruction|Notion2mdtest}}


=== "double quote ===


==== <tag> ====

{{UnderConstruction|Notion2mdtest}}


=== ## そのまま#表示 ===

{{UnderConstruction|Notion2mdtest}}

== テンプレート ==

{{Stub}}

{{Valuable}}

{{Outdated}}

== インデント ==

test

<pre>indented

indented2</pre>
text

<pre># インデント見出し</pre>
test2

<pre>### インデント見出し2

## インデント見出し黄色</pre>

== 箇条書き・要約など ==

[https://github.com/souvikinator/notion-to-md/issues/91 https://github.com/souvikinator/notion-to-md/issues/91]への対応確認

<div style="overflow:auto;width: 100%; max-width: 1200px; white-space:nowrap; border:1px solid; padding-left: 10px; padding-right: 10px;" class="mw-collapsible">
<div>summary1</div>
<div class="mw-collapsible-content">

detail1

</div></div>

* bullet1
** bullet2

(some text)

<div style="overflow:auto;width: 100%; max-width: 1200px; white-space:nowrap; border:1px solid; padding-left: 10px; padding-right: 10px;" class="mw-collapsible">
<div>summary2</div>
<div class="mw-collapsible-content">

detail2

</div></div>

==== セル内改行 ====

<ul>
<li>リンクと箇条書き 
[https://www.google.com/ Google]
<ul>
<li>リンクと箇条書き 
[https://www.google.com/ Google] 
text
[https://www.google.com/ Google]</li>
<li>[https://www.google.com/ Google] 
[https://www.google.com/ Google]</li></ul>

[https://www.google.com/ Google]</li></ul>

[https://www.google.com/ Google]

==== 箇条書き ====

<ol style="list-style-type: decimal;">
<li>11111111111</li>
<li>2222222222222
<ol style="list-style-type: decimal;">
<li>aaaaaaaaaaa</li>
<li>bbbbbbbbbbb
<ol style="list-style-type: decimal;">
<li>iiiiiiii</li>
<li>IIIIIII</li></ol>
</li>
<li>cccccc</li>
<li>dddddddddd</li></ol>

<ul>
<li>separator</li></ul>

<ol style="list-style-type: decimal;">
<li>111111</li>
<li>22222</li>
<li>3333</li></ol>
</li>
<li>33333
<ol style="list-style-type: decimal;">
<li>aaaaaaaa</li></ol>
</li></ol>

==== デフォルト表示の設定 ====

<div style="overflow:auto;width: 100%; max-width: 1200px; white-space:nowrap; border:1px solid; padding-left: 10px; padding-right: 10px;" class="mw-collapsible mw-collapsed">
<div>デフォルトで折り畳み
改行</div>
<div class="mw-collapsible-content">

中身 
改行

</div></div>

<div style="overflow:auto;width: 100%; max-width: 1200px; white-space:nowrap; border:1px solid; padding-left: 10px; padding-right: 10px;" class="mw-collapsible">
<div>デフォルトで表示
改行</div>
<div class="mw-collapsible-content">

インデント

* a
** ed
** %&\$\\`+~

</div></div>

==== ネスト ====

<div style="overflow:auto;width: 100%; max-width: 1200px; white-space:nowrap; border:1px solid; padding-left: 10px; padding-right: 10px;" class="mw-collapsible">
<div>toggle
kaigyo</div>
<div class="mw-collapsible-content">

tog 
kaigyo

<div style="overflow:auto;width: 100%; max-width: 1200px; white-space:nowrap; border:1px solid; padding-left: 10px; padding-right: 10px;" class="mw-collapsible mw-collapsed">
<div>toggled2
kaigyo</div>
<div class="mw-collapsible-content">

lev2

<div style="overflow:auto;width: 100%; max-width: 1200px; white-space:nowrap; border:1px solid; padding-left: 10px; padding-right: 10px;" class="mw-collapsible">
<div>lev3</div>
<div class="mw-collapsible-content">

cont3

</div></div>

ciot

</div></div>

<div style="overflow:auto;width: 100%; max-width: 1200px; white-space:nowrap; border:1px solid; padding-left: 10px; padding-right: 10px;" class="mw-collapsible">
<div>lev22
s</div>
<div class="mw-collapsible-content">
<div style="overflow:auto;width: 100%; max-width: 1200px; white-space:nowrap; border:1px solid; padding-left: 10px; padding-right: 10px;" class="mw-collapsible mw-collapsed">
<div>clev3</div>
<div class="mw-collapsible-content">

aaa

</div></div>

</div></div>

</div></div>

== 表 ==

[https://github.com/souvikinator/notion-to-md/issues/86 https://github.com/souvikinator/notion-to-md/issues/86]への対応

{| class="wikitable"
|-
!
!
!
|-
|
| d
|
|-
|
| f
|
|-
|
|
|
|}

== 書式 ==

=== 文字の消滅確認 ===

textitalicBO<s>L</s><s>o</s>ld<s>a</s><s>b</s>

=== セル内改行入り ===

* 基本的に非推奨、連続改行（空行）は禁止 
先頭に空白とか特殊文字入れるとかも危なそう

test 
改行 
改行3 
改行<code>e 
a 
f</code> 
z 
aa<code>df</code> 
<code>ug</code><code>g 
f 
|aa|bb|vc|{}{|}a{a</code> 
|aa|bb|vc|{}{|}a{a{{s|aa}} 
<code>dd==aaaa== 
; bbbb</code> 
<code>; bbbb</code> 
<code>; bbbb</code> 
<s><code>; bbbb</code></s> 
<code>* bbbb 
----- 
---- 
: 一個のインデント 
:: 二個のインデント </code> 
- sdg 
* sfs 
space 
 space2 
- spacehyphen 
 - hyphen2

=== その他エスケープシーケンスの確認 ===

code<code>d`d`d</code>

（Wikipediaの書式の例から流用）

::::: 多数のインデント

# 一 

# 二 

#* 二・一 

#* 二・二 

# 三 

#; 三項目一 

#: 三定義一 

# 四 

#: 四定義一 

#: 四定義一から続いているように見えるので 

#: &lt;nowiki&gt;&lt;br /&gt;&lt;/nowiki&gt; の代わりとして &lt;br /&gt; 

#: よく使われます 

# 五 

## 五の一 

### 五の一の一 

## 五の二

&amp;lt;

&amp;amp;

&amp;#98;

'''''可能'''''

# 一 
# 二 
#* 二・一 
#* 二・二 
# 三 
#; 三項目一 
#: 三定義一 
# 四 
#: 四定義一 
#: 四定義一から続いているように見えるので 
#: <nowiki> </nowiki> の代わりとして 
#: よく使われます 
# 五 
## 五の一 
### 五の一の一 
## 五の二 
&lt; 
&amp; 
&#98; 
---- 
~~~~

あ~~a~~b~c~~d~~e~~~f~~~~g

{{stub}}

{{UnderConstruction}}

==aaaa==

&amp ^caret^ +*@*****<s>*</s>*<s>*</s>****

\\$\$%&@@`””’’a’a’’’a’’’’’a\”

[text](link) {bra'''’ck''a'’et''''’’_’} |bar|+-.!()#

- (a)..aa'''’+

斜_体で_はない

==== リンクなど ====

+ item!! [https://google.com/ li[]nk] [https://ja.wikipedia.org/wiki/%E3%82%B9%E3%82%AB%E3%83%A9%E3%83%BC_(%E6%95%B0%E5%AD%A6) li!#$-{{}}a|a|{{}s*_^””’s}a=~~~~[[[]]n[]k2]

! a | ‘’a’’ [text](http://127.0.0.1)

privateページリンク[[error_private_page|error_private_page]]

自己リンク [[Notion2mdtest|Notion2mdtest]]

ページ内へ [[Notion2mdtest#コード|コード]]

google.com

<code>google.com</code>

[https://www.google.com/ https://www.google.com/]

[https://www.rodsbooks.com/refind/installing.html#winprob https://www.rodsbooks.com/refind/installing.html#winprob]

=== 数式 ===

数式<math display="inline">d^2</math>

数式<math display="inline">\sum_{n=1}^{10}{n}=55\$\$</math>

<math display="block">
|x| = \begin{cases}a'g\\aa'\end{cases}\{aa\}
</math>

$not math$

$$ 
not math 
$$

数式ではない$\sum_{n=1}^{10}{n}=55$です

=== コード ===

両端はtrimされる

<syntaxhighlight lang="python">code ```aaaa`````aaa`a```
```
```wsss
```
{{stub}}
{{UnderConstruction}}
----
~~~~
[[link|link]]
aaa
```aaa
```bold
italic
strike
unders
```</syntaxhighlight>
`not code`

``` 
koremo not code 
```

<code><details><summary>s1s</summary></details></code>

<details><summary>2ss</summary></details>

<div></div>tilde~~tilde~

<code>code</code> <code>code</code> <code>code</code> <s><code>code</code></s>

<code>code</code> <code>code</code> <code>code</code> <s><code>code</code></s>

<s><code>code</code></s><s>df</s><s>df</s><s><code>ef</code></s><s>d</s>d<code>f</code><s><code>d</code></s><code>f</code>vf

空白入りの言語名

<syntaxhighlight lang="vb.net"><tag></svg>
\\$\$%&@@`"""'""'"
# $ $\ ss
<details><summary>2ss</div>
<div class="mw-collapsible-content"></div></div>
</div>
<div class="mw-collapsible-content">
</div></div>
[text](link) {bra'''cks''a'et''''_a_} |bar|+-.!()#
+ #
- (a)..aa'''+</syntaxhighlight>
特殊記号のあるプログラム言語名

<syntaxhighlight lang="c#">public static Type Max<Type>(Type a, Type b)
where Type : IComparable
{
return a.CompareTo(b) > 0 ? a : b;
}</syntaxhighlight>
=== その他 ===

水平線

-----

<blockquote>引用
</blockquote>
== 画像 ==

<div class="res-img">https://ja.wikipedia.org/static/images/icons/wikipedia.png</div>
[[Category:sandbox]]{{#seo:|title={{FULLPAGENAME}} - Turgenev's Wiki}}

Sandbox4moved3

2025-04-02T07:15:34Z

Turgenev: Notion-MW

<ol style="list-style-type: decimal;">
<li>11111111111</li>
<li>2222222222222
<ol style="list-style-type: decimal;">
<li>aaaaaaaaaaa</li>
<li>bbbbbbbbbbb
<ol style="list-style-type: decimal;">
<li>iiiiiiii</li>
<li>IIIIIII</li></ol>
</li>
<li>cccccc</li>
<li>dddddddddd</li></ol>

<ul>
<li>sssss</li></ul>

<ol style="list-style-type: decimal;">
<li>111111</li>
<li>22222</li>
<li>www3</li></ol>
</li>
<li>33333
<ol style="list-style-type: decimal;">
<li>aaaaaaaa</li></ol>
</li></ol>
[[Category:sandbox]]{{#seo:|title={{FULLPAGENAME}} - Turgenev's Wiki}}

Webブラウザ（Chrome）

2025-04-02T07:15:27Z

Turgenev: Notion-MW

この記事では[[利用者:Turgenev|利用者:Turgenev]]が主に使用しているGoogle Chromeを中心に、Webブラウザに関するトピックを扱う。


== PWA ==

プログレッシブウェブアプリ（PWA）というのはWebアプリがプッシュ通知などの（本来は権限の問題で使うのが難しい）機能を使えるようにする仕組みである。Google Chromeでは、任意のページをPWAとして使用できる。このためには、メニューの「その他のツール」から「ショートカットを作成」を選べばよい。

また、PWAとして使用される際の設定などを明示的にmanifestとして指定しているページもあり、例えばTwitterならソースを見ると<code><link rel="manifest" href="/manifest.json" crossOrigin="use-credentials" /></code>などとタグが設置されていることがわかる。<code>manifest.json</code>の中身も見れる。このmanifest.jsonがある場合は（←多分）、Twitterのページを開くとアドレスバーに「アプリとしてインストール」的なボタンが表示される。これを押すと、先ほどの「ショートカットを作成」と（多分）全く同じ動作をする。

* YouTubeでの表示例（出典: [https://superuser.com/questions/1623874/what-is-install-youtube-button-on-chrome windows 10 - What is install youtube button on chrome? - Super User]）

<div class="res-img">https://i.stack.imgur.com/4t8Cu.png</div>


==== IDの生成 ====

{{Valuable}}

こうして生成されたショートカットを見ると、（例えばWindowsなら）<code>"C:\Program Files\Google\Chrome\Application\chrome_proxy.exe" --profile-directory=Default --app-id=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx</code>のようなコマンドラインが設定されているのがわかるだろう。調べた結果、この<code>--app-id</code>というのは、以下のようなプロセスで生成されるようである。

# アプリのURLを決定する。この際、manifestが指定されていれば、そこにある<code>start_url</code>が使われるようである（たとえばTwitterのを見ると、<code>"start_url":"https://twitter.com/?utm_source=homescreen&utm_medium=shortcut"</code>と書いてある）。また、トップページのときは末尾に<code>/</code>を付ける？（例: <code>https://chat.openai.com/</code>）これらに該当しない場合は普通にそのページのURLがそのまま使われる。
# URLにSHA-256ハッシュを2度適用し、その前半部分（16進数で32桁）をa-pの16文字で表現する。

この2.の部分は[https://source.chromium.org/chromium/chromium/src/+/main:chrome/browser/web_applications/web_app_helpers_unittest.cc ソースコード]に書いてある[https://play.golang.org/p/VrIq_QKFjiV playground]で試すこともできる。pythonで書くと以下のようになる（URLはコマンドライン引数として渡すことを想定）。

<syntaxhighlight lang="python">import hashlib

m = hashlib.sha256()
m.update(bytes("https://chat.openai.com/".encode('ascii')))
m1 = hashlib.sha256()
m1.update(m.digest())

EXTID = ''.join([chr(int(i, base=16) + ord('a')) for i in m1.hexdigest()][:32])
print(EXTID)</syntaxhighlight>
* 参考: [https://stackoverflow.com/questions/26053434/how-is-the-chrome-extension-id-of-an-unpacked-extension-generated/26058672#26058672 How is the Chrome Extension ID of an unpacked extension generated? - Stack Overflow]

== フォント ==

=== pdfビューアのフォント ===

Chrome標準のpdfビューアは、フォントが埋め込まれていないpdfの表示に不適切なフォントを使用することがある。これを修正する方法を解説する。

==== フォント選択のしくみ ====

pdfのそれぞれの文字にはフォントが指定されているが、そのフォントがpdfに埋め込まれておらず、かつ閲覧するPC上にも存在しない場合、別のフォントで代用する必要がある。どのフォントで代用するかはソフトによって異なる。

理想的には、元のフォントと同じカテゴリ（「明朝」や「ゴシック」くらいのくくりで指定できる仕様がある）から選ぶとか、名前が似ているものを選ぶというのが望ましいが、Chromium系はそうなっておらず、名前順で最初にあるものを選ぶようである（正確には日本語フォントと認識されるフォントの中で最初のもの？）。無難な明朝やゴシックならまだいいが、「AR丸印篆B」なんかになってしまうと悲惨である。あるいは、自分はなったことがないが、そもそも日本語の文字が表示されないという場合もあるらしい。

有名なAcrobat Readerは比較的ちゃんとやってくれる（PDF-XChange Viewer、Foxit Readerあたりも問題なかった気がする）。あと同じブラウザでもFirefoxのほうが（pdfビューアーに限らず）フォントまわりはちゃんとしている印象。

==== 解決策 ====

解決策はいくつかあって、他サイトではデフォルトのpdfビューアーを使わないようにするものが多く紹介されている。必ずダウンロードする設定にしてAcrobat Readerで開くとか、pdfを閲覧できる他の拡張機能を入れるとかの類である。

ただ毎回ダウンロードするのは不便だし、拡張機能はURLが拡張機能のやつになってしまって元のがコピーしづらい（また個人的に論文pdfには[[Zotero|Zotero]] の拡張機能を使うので支障があった）。

そこで、ブラウザ側の設定はそのままで、名前順でもっと早いフォントを新たに追加するという方法が考えられる。

といっても巷にある名前順が早いフォントが好みのものかわからないので、既存のフォントの名前を変える方法を紹介する。

==== フォント名の変更 ====

[[フォント|フォント]]において、ttxを使ってフォント名を変更する方法を紹介している。

==== インストール ====

名前を変えたフォントができたらあとはインストールするだけだが、ここが実は重要で、普通のインストールではなく、「すべてのユーザーに対してインストール」をする必要がある。言い換えれば、フォントファイルがC:\Users\username\AppData\Local\Microsoft\Windows\FontsではなくC:\Windows\Fontsに入っている必要がある。

ダブルクリックで開く画面（「Windowsでコンピューターの世界が広がります。1234567890」のやつ）からは「すべてのユーザーに対してインストール」はできないので、右クリックメニューから選択すること。あるいはフォントファイルを直接C:\Windows\Fontsにコピーしてもよい。

==== 確認 ====

これで、選んだフォントでpdfがみられるようになっているはずである。各自、問題のあったファイルで試してみればよい。

==== 余談 ====

先ほどURLが変わるので微妙と評した拡張機能であるが、フォント云々とは関係なく、全てのpdfファイル（強制ダウンロードのリンクになっているものも含めて）をダウンロードせず開けること自体はなかなか便利である。

これをURLを変えずに実現できるものがないか探したところ、[https://chrome.google.com/webstore/detail/undisposition-racle-fork/bbppejejjfancffmhncgkhjdaikdgagc Undisposition [Racle fork]]という拡張機能があった。Google Driveなどでファイルを全くダウンロードできなくなるという副作用が[https://github.com/Racle/undisposition/issues/2 報告されていた]が、最近のアップデートでホワイトリスト機能が追加された。

ただ、動かないサイトもある気がするのと、拡張機能の性質上しょうがないとは思うのだが要求される権限が「すべてのウェブサイト上にある自分の全データの読み取りと変更」なので、効用の割にはリスクが…というのはあるかもしれない。


=== CSSにおけるローカルフォントの指定 ===

{{Valuable}}

こちらはよりadvancedな話題であるから簡潔に述べる。

CSSでローカルのフォントを使わせたいときは<code>@font-face</code>の<code>src: local()</code>を使って指定する。

まず、このときに使用する名前はnameテーブルの6番にあるPostScript名（これは先ほど<code>ttx -t name fontfile.ttf</code>で出力したxmlで見れる）を使わなければならないとされている。ただし手元で試した限り4番にあるような名前でも成功する場合があった。最も確実なのがPostScript名ということなのかもしれない。

で、Windows版のChromium系で使う場合に重要なのが、フォントファイルが先ほどのように「すべてのユーザーに対してインストール」されている必要があるということである。さらに、手元で試した限り、同じフォントが特定のユーザーに対してインストールされている（C:\Users\username\AppData\Local\Microsoft\Windows\Fontsにある）と正しく動かないようであるということがわかった。

というわけで、Windows版のChromeでsrc:local()が効かないという場合は、フォント名を確認した上で、該当のフォントがC:\Windows\Fontsだけにインストールされていることを確認するのがよい。
[[Category:IT]][[Category:Windows]]{{#seo:|title={{FULLPAGENAME}} - Turgenev's Wiki}}

Windowsのパス長さ制限に関して

2025-04-02T07:08:06Z

Turgenev: Notion-MW

Windowsが扱えるパスの長さは260文字（定数<code>MAX_PATH</code>）に制限され、それ以上の長さのパスをもつファイル・フォルダの操作に支障が出ることがある。

* これはあくまでWindowsの問題であってファイルシステム（NTFS）の制限ではないので、後述の通りエクスプローラ上でも例えばパス長さ260を超えるファイルを作ること自体は容易である。ネットワーク上のフォルダを閲覧する場合など、実際にWindows上で長さ260を超えるパスを扱う必要がある場面も多く、ダブルクリックで開く程度の操作はできることが多い。

以下ではこの問題に関してさらに詳細な挙動を解説する。なお動作確認に使用したのは主にWindows10である。Windows11でも少し試したが、大幅な改善はなさそうである。

関連する公式のドキュメントとしては以下が参考になる。

[https://docs.microsoft.com/windows/win32/fileio/naming-a-file?redirectedfrom=MSDN#file-and-directory-names https://docs.microsoft.com/windows/win32/fileio/naming-a-file?redirectedfrom=MSDN#file-and-directory-names]


== 正確な数え方・内訳 ==

260の内訳は以下のようになっている。

<blockquote>ドライブレター（1）＋コロン（1）＋パス本体（256）＋終端のヌル文字（1）
</blockquote>
従って我々が普段「フルパス」として認識している部分の長さ上限は実際には259ということになる。

これに加えて、カレントディレクトリ（作業ディレクトリ）のパスの上限は258のようである（コマンドプロンプトやPowerShellでcdしようとしてみた結果）。おそらくディレクトリ末尾の<code>\</code>を含めて259文字以下ということかと思われるが、確実な情報はあまりない。さらに、cmdでは、ちょうど258文字のフォルダにはcdできても中でdirできなかった。

また、この260文字というのはUTF-16で数えた値である。従って「a」や「字」などのU+FFFFまでのUnicode文字は1文字、「𩸽」などのU+10000を超える文字はサロゲートペアで表現されるため2文字とカウントする。

== 制限の解除 ==

この制限は最近のWindowsならLongPathsEnabledというレジストリの値を1に設定することで解除できるとされている。例えばPowerShell上で以下を実行すればよい。

<syntaxhighlight lang="powershell">Set-ItemProperty "Registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem" -Name LongPathsEnabled -value 1</syntaxhighlight>
また、現在の値を確認するには以下を実行する。

<syntaxhighlight lang="powershell">(Get-Item -Path "Registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem").GetValue("LongPathsEnabled")</syntaxhighlight>
しかし、制限を解除すれば全ての操作が支障なくできるというわけではない。例えば、Windows APIのマルチバイト文字方式の関数（末尾がAのもの）は長いパスに対応していない（末尾がWのワイド文字方式のものは対応している）らしく、これを使用しているアプリケーションはこの制限を解除しても正しく動かない。またエクスプローラ上での操作性もほとんど改善しない。

== パスの形式について ==

今後出てくる様々な挙動を把握するために、ファイルに短い別名を与える仕組みである「8.3形式」およびパス長さ制限の回避に有効な「”<code>\\?\</code>”プレフィックス」について紹介する。


=== 8.3形式(短いファイル名) ===

古いWindowsのファイル名には「8文字以下の名前+ピリオド+3文字以下の拡張子」という長さ制限があった。また、空白を含む一部の記号も使用できない。この制限がなくなった（緩和された）現在でも、Windowsは制限を満たさないファイルに対してこの制限に基づく別名を自動生成する。これが「8.3形式」あるいは「短いファイル名」などと呼ばれるものである。例としては”Program Files”→”PROGRA~1” などがある。8.3形式の名前はコマンドプロンプトのdir /xコマンドで表示できる。

比較的新しいWindowsでは、<code>fsutil 8dot3name</code>コマンドを使うことで、8.3形式の名前を生成するかどうかをシステム全体およびボリューム（Cドライブ、Dドライブ）ごとに設定できる。デフォルトではCドライブのみ有効になっているようである。

この別名を通常の名前のかわりに使用することで、現実的に多くの場合は長さ制限を回避できるだろう（もちろん階層が深すぎて「短いパス」でも長さ制限を超えてしまう場合などはできない）。また、パスに含まれる空白による問題も回避できる。

後述の通り一部アプリケーションはこれを積極的に使うことで長さ制限を回避しようとすることがある。この際は8.3形式を可能な限り多く使用したパス（可能な限り最も短いパス）が用いられるようである。

例えば8.3形式の名前がCでは有効、Dでは無効（つまりデフォルト設定）だったとする。Dドライブ直下に”longfoldername”という名前で”C:”へのジャンクションを作り、それを経由してC:\Program Filesにアクセスする場合は、”D:\longfoldername\PROGRA~1”が「可能な限りもっとも短いパス」ということになる。

* 「可能な限り多く」ではなく、短い名前をもつフォルダのうち一部のみを8.3形式としたパスがexplorerのアドレスバーなどで使われることもたまにあるようだが、詳しい条件は不明である。

8.3形式は基本的には普通のパスと同じ扱いであるため、多くのアプリケーションが対応しているが、PowerShellなどは強制的に長い名前に変換しようとするため支障が出ることもある（後述）。また、4文字以上の拡張子は3文字に短縮されてしまうため、例えばWordの.docxファイルが.docファイルと混同されるなどの問題が生じる。また他にもシェルの入力補完で表示されないなど、通常のパスと比べて不便であることには変わりない。


=== “<code>\\?\</code>”プレフィックス ===

公式ドキュメントでも用語の定義がはっきりしないのでよくわからないが、パスの先頭に”<code>\\?\</code>”（検索しやすさのために書いておくと、バックスラッシュ（=円記号）2つ+クエスチョンマーク+バックスラッシュ1つ）というプレフィックスを付加すると”Win32 file namespace”というものにアクセスすることになるらしい。具体的にどうなるかというとWindows APIによるパスに対する各種のチェックが行われなくなり、結果として長さ制限を超えるパスを使えるようになる。ただし対応状況はアプリケーションによってまちまちである。

このパスはネットワーク上のファイルを指定するのに使われるUNCパス（UNCはUniversal Naming ConventionあるいはUniform Naming Conventionの略）の一種とも考えられる。UNCパスは「<code>\\コンピュータ名\パス本体</code>」という形式だが、この「コンピュータ名」の部分に<code>?</code>が入っているというわけである。ちなみに、元々UNCパスだったものにこのプレフィックスを付加する場合は<code>\\?\UNC\コンピュータ名\パス本体</code>とすれば良いらしい（エクスプローラーでそのように表示されている）。

なお、クエスチョンマークの代わりにピリオドを使用した<code>\\.\</code>というプレフィックスもあり、これだと”Win32 file namespace”ではなく”Win32 device namespace”というものにアクセスすることになるらしいが、詳細は不明。長さ制限を回避するには使えないようである。

以降では便宜的に「“<code>\\?\</code>”プレフィックス」を指して単に「プレフィックス」と呼ぶ。

ちなみに今回の話題とは無関係だが、<code>con</code>や<code>nul</code>などWindows上で許容されない名前のファイルが削除できない際に、コマンドで<code>\\?\</code>や<code>\\.\</code>を付けたパスを指定すると削除できる。


== Explorerや各シェル、アプリケーションにおける挙動の変化 ==

ここから具体的な挙動の変化を見る。特に記載がないものは、レジストリ値を変更して制限を解除しても変わりがないということである。

以下で「PowerShell」と呼んでいるのはバージョン5であって、6以降（実行ファイル名がpwsh.exeになって以降）では異なるようである。


=== 8.3形式・プレフィックス付きパス等を扱えないアプリケーション ===

アプリケーションによって細かい挙動は様々だが、プレフィックス付きのものや8.3形式の名前が含まれるパスに関して不具合が出ることがある。はっきりエラーメッセージが出ることもあれば、何も起こらないこともあるし、空白の（ファイルを開いていない状態の）ウインドウが表示される場合もある。いくつか例を挙げておく。

* Windows Media Player…プレフィックス付きのものや長さ制限を超えるパスを引数に渡すと起動しない（何も起こらず終了する）。
* ペイント…プレフィックス自体は扱えるが長さ制限を超えるとプレフィックス付きであっても扱えない（引数として渡すと何も起こらず終了する）。
* Word…プレフィックス付きパスを渡すと、起動はするが新規作成の画面になる。また長さ制限を超えるパス（プレフィックス付き含む）を渡すと「パス名が長すぎる」というようなメッセージを表示した上で新規作成の画面になる。また、”.docx”は拡張子が4文字以上であるため、短いパスとして渡されると不自然な動作になることがある（”.doc”、つまりWord 97-2003文書との混同が生じる）。
* Visual Studio…8.3形式を用いて短くした.slnや.vcxprojを渡しても、元の（8.3形式を使わない）パスが制限を超えていると「パス名が長すぎる」というようなエラーが表示され開けない。


=== 長さ制限を超えるパスをカレントディレクトリとして実行できないWindowsネイティブアプリケーション（？） ===

おそらくアプリケーション側の都合で、長さ制限を超えるパスをカレントディレクトリとしての起動に対応していないことがある。具体的には、Git Bashで、長い名前をもつフォルダを開いているとき、mspaintやcmdの実行に失敗する。次のようなメッセージが出る。

<syntaxhighlight lang="latex">Error: Current working directory has a path longer than allowed for a
Win32 working directory.
Can't start native Windows application from here.

bash: /c/Windows/system32/mspaint: File name too long</syntaxhighlight>
しかし、同じ状況でgrep.exeの実行は成功する。従ってアプリケーションによって対応状況に差があるものと推測される。ただしこのエラーメッセージはGit Bashによるものであり、またGit Bash以外で違いを確認できていない（例えばcmdやPowerShellではmspaintもgrepもシェル側の都合で失敗する）ので、例えばGit Bashが必要以上に多くのプログラムを勝手に”native Windows application”に分類している可能性などは残る。またgrep.exeのようなGit Bash付属の実行ファイル以外で起動できるものは確認していないので、判定条件がよくわからない。

カレントディレクトリを8.3形式によって短くできれば起動できる。

=== explorer ===

まず、以下の挙動については全てのフォルダで同様。8.3形式で短くできるものも含まれる。

* 長さ制限を超えるファイルのリネームができない（元々超えている場合は短くすることもできない）
** 超えていない場合、制限いっぱいになるとそれ以上入力できなくなる
* 中にあるファイルのパス長が制限を超えるようにフォルダをリネーム・移動することは可能
** これにより長さ制限を超えるパスをもつファイル・フォルダをエクスプローラ上で容易に作れる。逆に、長すぎてリネームできないファイルなども、外側のフォルダをいったん短い名前に変える・短い名前の場所に移動することで操作できるようになる
* 長さ制限を超えてもフォルダを開くことは可能。

さて、explorerは、制限を超える長いパスに対しては概ね次のような原則で対処しようとするようである。

# 8.3形式の名前を使用して「可能な限り最も短いパス」を得て、これを使う。
# 8.3形式の名前がない、あるいはそれを使っても制限を超過するなどの場合は、パス先頭に”<code>\\?\</code>”プレフィックスを付加する。

例えばexplorerのアドレスバーを見ると、このように動作していることがわかるだろう。あるいは、そのフォルダおけるexplorerの挙動はアドレスバーを見れば大体予測できるということにもなる。ファイルに関して調べたければ「パスのコピー」を使うとよい。なお、手動でプレフィックスや8.3形式の名前をエクスプローラのアドレスバーに入力して移動した際は、通常のパスに変換される（それが長さ制限を超えていれば改めて上記の対処が行われる）。

<ul>
<li>ただし上記1の部分では、（末尾の<code>\</code>を含めない）パス長さが260文字以上になったときのみ8.3形式が適用される。しかし、実際にはカレントディレクトリのパス長さ上限は258文字である。よって、ちょうど259文字の長さのパスでは、アドレスバーには通常のパスが表示されるにもかかわらずアドレスバーにcmdと打っても正しく起動しないという、258文字以下または260文字以上のフォルダでは見られない挙動をする。
1とは違って、2の部分では、8.3形式を使ったとしてもパス長さが259文字以上になると<code>\\?\</code>が付加されるのでこのような問題は起こらない。</li></ul>

==== 1のとき ====

ダブルクリックでファイルを開くことができるほか、右クリックメニューの「送る」「Codeで開く」（※VS Codeを適切な設定でインストールすると表示される）なども正常動作する。なお「PowerShell ウインドウをここで開く」は、動作するが、PowerShellは強制的に通常の（長い）名前を使おうとするため、カレントディレクトリとしては通常の名前が表示される（この先の挙動はPowerShellの項目を参照）。また、PowerShellを使用するよう設定したWindows Terminalをここで開くと、制限を解除した場合は通常形式のパスをカレントディレクトリとして正しく起動するが、解除しない場合はカレントディレクトリを<code>C:\WINDOWS\System32\WindowsPowerShell\v1.0</code>として起動する。

ファイルの新規作成は可能だが、フォルダを作成しようとするとエラーが出る。ファイルやフォルダを「ごみ箱に移動」できる。

==== 2のとき ====

2に当てはまるフォルダでは、「Codeで開く」など外部プログラムを起動するような右クリックメニューの多くが動作しない（Explorer.EXEによる”ディレクトリ名が無効です。”とのダイアログが出る）。「開く」も動作せずファイルをダブルクリックで開くこともできない（例えば.txtがメモ帳に関連付けられた状態で開いてみるとよい）（※Windows11ではメモ帳の動作が改善しているのでCOM実装に変更されたようだが、一般のプログラムではうまくいかない。ただしエラーダイアログは出なくなり、無言で起動しない）。ただしCOMを用いて実装されているメニュー（レジストリにコマンドラインではなくUUIDが書かれているようなもの）は正常に動作するようである（例えば「映画 & テレビ」「フォト」のようないわゆる「アプリ」で開く場合）。

また、以下はCOMが用いられているか不明（未調査）だが一定のまともな挙動を示すためその可能性が考えられる。

* 「PowerShell ウインドウをここで開く」…正常に動作する。
* 「プログラムから開く」…「開く」とは異なり、（アプリケーション側が対応していれば）正常に動作する。
* 「送る」…Explorer.EXEのエラーは表示されない。ただし、特殊な方法（これもCOM？）で実装されている「ドキュメント」「デスクトップ (ショートカットを作成)」「圧縮 (zip 形式) フォルダー」メニューなどを除けば、選択しても何も起こらない。また、zipのメニューに関しても、最終的にzip作成には失敗する。なお、この「送る」に関しては、（2に当てはまるフォルダ内でなくとも）2に当てはまるファイルが一つでも含まれていると同様に動かないようである。

また、「新規作成」メニューにはフォルダの作成のみ表示されるが、なぜか”管理者マーク”が付いており、押しても何も起こらない。従ってファイルもフォルダも作れない。「ごみ箱に移動」は動作せず、delキーを押しただけで「完全に削除しますか？」と聞かれる（完全に削除することは可能）。

=== コマンドプロンプト ===

制限を解除した場合に限り長いパスを扱える（cdやdirが動作する）。また8.3形式の名前も普通に使える。

プレフィックスは、全く解釈できないわけではない（例えばrdコマンドの引数に使うことはできる）が、カレントディレクトリとしては許容されないようで、指定してcdしようとすると「CMD では UNC パスは現在のディレクトリとしてサポートされません。」と言われる。

外部プログラムを実行する際は、（制限が解除されていても）カレントディレクトリのパスが長いと判定したら「可能な限り最も短いパス」を代わりに使うようで、（それで制限以下の長さにできるフォルダであれば）正しく起動できる。


=== PowerShell ===

* ここに書いているのは主にPowershell 5.0あたりの話で、最近のPowerShell（PowerShell Coreと呼ばれたり、実行ファイル名がpwsh.exeだったり）では色々と改善が見られる。

制限を解除した場合に限り長いパスを扱える点はcmdと同じである。しかし前述の通り、カレントディレクトリに8.3形式が使われるのを許容しないようで、強制的に長い名前に変換するため、しばしば奇妙な挙動を引き起こす。

例えば、カレントディレクトリのパスが200文字だったとして、そこに名前が100文字のフォルダがあったとする。いずれも実体はCドライブにあって8.3形式の名前が有効とする。このとき、パス長さ制限が解除されていなくても、8.3形式の名前を使えばcd自体はできる。しかしcdが成功すると同時にカレントディレクトリは長い名前に変換されるため、カレントディレクトリは300文字程度になり制限を超えてしまい、そこでのdirコマンドなどの実行は失敗するようになってしまう。

また、長さ制限を超えるパスがカレントディレクトリであるときに外部プログラムを実行すると、制限が解除されていない場合は「可能な限り最も短いパス」を使おうとするが、解除されている場合は長いパスをそのまま使おうとする（cmdとの違い）。結果として実行に失敗する。つまり、制限を解除した結果としてむしろ実行が失敗するようになるという状況が発生している。

プレフィックスには対応していて基本的な操作ができる。カレントディレクトリに設定すると<code>Microsoft.PowerShell.Core\FileSystem::\\?\C:\Users</code>のように表示される。

またカレントディレクトリがプレフィックス付きであるときに外部プログラムを実行するときは、不要な<code>\\?\</code>や<code>\\.\</code>を除去してくれるようで、正しく起動できる。これは<code>\\?\C:\Windows</code>のようなフォルダで正しく起動できるということであって、そもそも<code>\\?\</code>を付けないと扱えないような長いパスでの実行はいずれにしても失敗する。

また、（制限を解除していない状態だとしても）この際に「最も短いパス」を使用することまではしてくれないようで、Cドライブ上の長いパスに<code>\\?\</code>を付けたものをカレントディレクトリとしてnotepadを実行してみたが失敗した。

また、なぜかCドライブ直下を対象にした<code>cd \\?\C:</code>や<code>cd \\.\C:</code>はうまくいかない（<code>cd \\?\C:\Users</code>や<code>cd \\.\C:\Users</code>は成功する）。<code>\\.\</code>に関しては一旦<code>cd \\.\C:\Users</code>などしてから<code>cd ..</code>をするとCドライブにいけるがこのときはなぜか<code>\\.\</code>が消えて<code>Microsoft.PowerShell.Core\FileSystem::C:</code>という表示になる。<code>\\?\</code>の場合はこれもできない。

<div style="overflow:auto;width: 100%; max-width: 1200px; white-space:nowrap; border:1px solid; padding-left: 10px; padding-right: 10px;" class="mw-collapsible">
<div>要らないかも</div>
<div class="mw-collapsible-content">

また、プレフィックス付きパスにいるときにcdで相対パスを使用する際は8.3形式も使えるが（強制的に長い名前に変換されるのは同じ）、<code>\\?\</code>と8.3形式を組み合わせた絶対パスを用いると失敗する場合もある。具体的には、Cドライブ直下のフォルダ（たとえば<code>cd \\?\C:\PROGRA~1</code>など）は成功したが、他ではうまくいかない。なお、<code>cd \\?\C:\PROGRA~1</code>を実行した際はなぜか通常のパスへの変換が行われず、カレントディレクトリが<code>Microsoft.PowerShell.Core\FileSystem::\\.\C:\PROGRA~1</code>となる。詳細不明。

また<code>\\?\</code>のかわりに<code>\\.\</code>を用いるとCドライブ直下以外でもcdに成功したが、前述の通り<code>\\.\</code>にはパス長さ制限を回避する効果がないようなので実用性は不明である。またCドライブ直下のフォルダのみ8.3形式が許容されるようで、<code>cd \\.\C:\PROGRA~1\INTERN~1</code>とするとカレントディレクトリは<code>Microsoft.PowerShell.Core\FileSystem::\\.\C:\PROGRA~1\Internet Explorer</code>になる。

</div></div>


=== Git Bash ===

git bashはUnix由来のシェルであるためか、それ自体で長さ制限を超えるパスを扱う能力を持っているようである。従って制限を解除しなくても長いパスを扱える。また8.3形式の名前も使える。

「可能な限り最も短いパス」を得ようとするような動作はしないため、長いパスをもつカレントディレクトリでの外部プログラム実行は失敗する（前述の通り、Git Bash内蔵のgrep.exeなどは例外）。

Git Bashでは、<code>\\?\</code>や<code>\\.\</code>や<code>//./</code>は使うとエラーになり、<code>//?/</code>を付けた場合はcdには成功するが<code>//?/</code>が除去される。

ただし、逆にWindowsにない制限として、Unixではそれぞれのファイル名の長さ上限が255バイトという制限がある（Windowsと違ってパス長さの制限は4096なので、長さ200バイトの名前のフォルダの中に長さ200バイトの名前のフォルダを作るにあたっては不自由がない）。また、エンコードはUTF-8を基準に計算されるので、3バイトで表現される通常の日本語の文字（ひらがなや漢字）だと85文字、U+10000を超えるような文字（𩸽など）だと4バイト分なので63文字しか入らない。Windows上ではこれらを超える長さのフォルダを作れるが、Git Bashではそこにcdできないということになる。


=== WebDAV ===

Windowsでは、<code>host:port</code>において稼働しているWebDAVサーバーの<code>my/folder</code>というフォルダに、<code>\\host@port\my\folder</code>あるいは<code>\\host@port\DavWWWRoot\my\folder</code>というパスでアクセスできる。ただし前者はトップディレクトリに関しては機能しない（アクセスできませんと言われる）ので注意。とはいえ後者はexplorerのアドレスバーが<code>http://host:port/my/folder</code>というHTTP形式の表示になってしまうのが扱いづらい。

そして、WebDAVに関しても（詳細は調べていないが）260文字程度以上の長さのフォルダにはアクセスできない。しかも、<code>\\?\UNC</code>や（ネットワークドライブを割り当てたとして）<code>\\?\</code>を付けてもアクセスできず、どうやっても表示する方法はわからなかった。また、260文字程度の長さになるファイルも表示されなくなるなどした。

長いパスのファイルを含むWebDAVサーバーをまともに使うのであれば、WinFSPなどでマウントした方が良さそうである。

== 結論 ==

こうしてみると長さ制限を解除しても大した改善はないというのが実情である。
[[Category:IT]][[Category:Windows]]{{#seo:|title={{FULLPAGENAME}} - Turgenev's Wiki}}

フィルターされたNotionページによるMediaWiki

2025-04-02T07:04:00Z

Turgenev: Notion-MW

「[[Notion|Notion]]のページから下書きを除去した上で[[MediaWiki|MediaWiki]]フォーマットに変換してアップロードする」というこのサイトの動作機構に関して説明する。

== 概要 ==

Notionのページを見出しによって定まる木構造データとみなす。各見出しは無色（デフォルト）である場合と、黄色背景である場合があるとする。この木構造データに対し、「無色の頂点を全て切り落とす」という変換をする。すなわち、自らを包含する見出しが全て黄色であるコンテンツだけを残す。

記事データにこのような変換を施すことで、同じページ内でも場所ごとに公開/非公開を簡便に切り替えられるようにするというのが基本的なアイデアである。

* 例外的に、最初の見出しより前に書いてあるテキストは、必ず出力させる。つまり記事の冒頭に仮想的な「レベル0」の見出しがあると考えればよい。
* Notionではブロックを選択してショートカットキー「Ctrl+Shift+H」を押すことで直近に適用されたものと同じ色を適用することができるので、複数種類の色を使い分けているのでなければキー一発で公開/非公開を切り替えられる。

さらに、このコンテンツをMediaWikiで公開することで、変更履歴を誰でも見ることができるようになる。これによりどのタイミングでどの箇所が修正されたかというメタコンテンツを「〇月〇日追記」のような形でコンテンツと混在させる必要がなくなる。

また、その他にも頻繁に使われるメタ情報はMediaWikiのテンプレートとして挿入する。例えば、

* ある見出しに属する（公開の）内容が完全に空（ほかの見出しすら含まれない）だった場合は、「作業のため一時的に非公開となっている可能性があります。[履歴]もご確認ください。」と表示するUnderConstruction‏‎テンプレートを挿入する。これにより、既に公開した内容を大幅変更のためなどで一時的に非公開にしたい場合は、該当の見出しの直後に同じレベルの無色の見出し（空でもよい）を挿入すればよいということになる。ただし、あまり使われていない。
* 内容は存在するものの完成度が低く、今後加筆予定であることを表すStubテンプレート。
* 執筆時点で古くなっている情報を表すOutdatedテンプレート。
* 他サイトにあまり書かれておらず貴重と思われる情報を表すValuableテンプレート。

== データベース部分の設計 ==

<div class="res-img">https://turgenev.cloudfree.jp/mw1/imgs/notion-mw-db.jpg</div>

このような感じで、「使うNotionページへのリンク」「スクリプトによる変換&更新の対象にするかどうか」（←これは今はもう使われていない）「MediaWikiでのID」「MediaWikiでのタイトル」「MediaWikiでのカテゴリー」「サイトの更新日時（＝スクリプトによってMediaWiki側での編集が完了したタイミング）」をデータベースとして保持している。

ページの新規作成時は「MediaWikiでのID」に<code>-1</code>を使おうと思ったが、なぜかここが<code>-</code>と<code>1</code>に分かれたrich_textの配列としてデータが返ってくることがあって困ったので<code>-</code>だけにするように変更した。

Notion側でもページの最終更新日時が取れるので、それをこの表の更新日時と比べて、反映されていない更新があったら適用するという実装にしている。（ただし変換スクリプト自体を変更したときなどは全ページ生成し直す）

== サイトマップの生成 ==

上記でsandboxタグが入っているもの以外が検索サイトにインデックスしてほしいものたちである。そこで、編集完了後に、表の更新日時を使ってxmlサイトマップをスクリプトから生成する。

== 変換コードの概説 ==

大まかな流れは以下の通り。

# 上記データベースの内容をNotion APIから取得する。以下、各行ごとに処理。
# ページの内容を取得し、黄色い見出しだけ残す変換を行う。Notionのブロックのリストができる
# notion-to-mdのblocksToMarkdownでマークダウン形式に変換する。
# いくつか前処理を行う。
# pandocを用いてMediaWikiに変換する。
# いくつか後処理（整形）を行う
# 完成した記事データをMediaWiki APIで投稿する。

その他、ページのリネーム、新規作成時のIDの反映（<code>-</code>を数字に変える）、既存の記事を新規作成しようとした場合のエラーなど、前後に多少の処理がある。

特筆すべき部分のみ以下で説明する。（おおむね処理の進行順）

=== toggle ===

detail-summaryタグではなくMediaWikiの標準の折りたたみ形式であるmw-collapsibleタグに変更。notion-to-md側を変えるのではなくpandocで変換した後のmediawikiでdetailsタグを置換している。

さらに、summary部分の文字列の先頭に<code>?</code>が付いていたら折りたたみ状態に変える。これも置換でできる。

* 完全な仕様としては例えばこんな感じ？（未実装）
** 先頭が<code>?</code>でない→折りたたまない
** 先頭が<code>?</code>
*** <code>?</code>の次が<code>?</code>→<code>??</code>を削除し、折りたたみ
*** <code>?</code>の次が<code>!</code>→<code>?!</code>を削除し、折りたたまない
*** その他→<code>?</code>だけを削除し、折りたたむ

=== pandocの実行 ===

<syntaxhighlight lang="python">cp.spawn("pandoc", ["-f","gfm","-t", "mediawiki", "--shift-heading-level-by=1"]);</syntaxhighlight>
<code>gfm</code>（Github Flavored Markdown）から<code>mediawiki</code>に変換する。<code>--shift-heading-level-by=1</code>は、[https://www.mediawiki.org/wiki/Help:Formatting/ja Help:書式整形 - MediaWiki]にもある通り、MediaWikiの記事内ではレベル1の見出しは非推奨だからである。

=== 画像 ===

キャプションが未対応（[https://github.com/souvikinator/notion-to-md/issues/63 https://github.com/souvikinator/notion-to-md/issues/63]）なので←に従ってsetCustomTransformerをする。

[https://zenn.dev/st43/articles/8e2f9c48761e59 Notion API（v0.4.4）で画像を扱う]のようにNotionの内部画像の扱いは面倒なので当サイトではすべて外部ストレージ（もっと言えばMediaWiki内部）にアップロードしている。書式も適宜変換する。


=== カテゴリ情報、seo情報 ===

データベースにあるタイトルとかtagsデータから生成する。seoについては[[MediaWiki|MediaWiki]] も参照。

=== 各種の整形処理 ===

一部コンテンツはnotion-to-mdで生成されるマークダウンそのままだと不都合があるので、専用のコードを入れて変換している。場合によってはnotion-to-md本体側にも変更を入れている（一旦特殊なエスケープシーケンスに変換しておいてpandocに触られるのを回避し、MediaWikiが返ってきてから自前で編集するようにしている箇所もある）。

具体的には以下の通り。

* 特殊文字の処理
** <code>*</code>などがマークダウンにおける特殊文字と解釈されてしまうのを防ぐためエスケープ。また、<code>{}</code>や<code>~</code>などはMediaWiki上の特殊文字であり、これもやはりエスケープする。
* ページ間リンク
** Notionでのページ間リンクをMediaWikiでのページ間リンクに変換するため、先ほどのデータベース表に従って<code>[ページタイトル](/ページタイトル)</code>という形式に変換する（するとpandocが自動で<code>[[ページタイトル|ページタイトル]]</code>に変換してくれる）

=== テンプレート挿入 ===

「!s」だけの行があったら{{Stub}}テンプレートに変換する、というような実装にしている。

== オリジナルのnotion-to-mdへの変更 ==

上記のような良い感じのMediaWikiに変換する目的と、単純にできたばかりでバグが多いため、色々変えている。

=== リポジトリ ===

[https://github.com/ge9/notion-to-md-mediawiki Githubリポジトリ]を作成したので、最新情報はそちらから。

=== 数式関連 ===

以前は変えていたが[https://github.com/souvikinator/notion-to-md/commit/fdd96ca0362663c914cd5fde62baef520dae6763 https://github.com/souvikinator/notion-to-md/commit/fdd96ca0362663c914cd5fde62baef520dae6763]で改善されたため不要


=== <code>md.ts</code>内 ===

==== 書式 ====

太字、斜体、取り消し線、コード（<code>`</code>）をそれぞれhtmlタグのstrong, em, s, codeに変更。<code>```</code>は変えていない（markdownにおける<pre>の動作が怪しかったため）。

==== ハイパーリンク ====

pandocでの変換においてハイパーリンクの後にスペースなどを開けずに文字が続くとバグることがあるので、他で使わない固定文字列のセパレータを挿入し、変換後に消す。


==== codeBlock ====

コードにおいて、言語がpythonなどの良く知られたものに設定されていると、pandocによってsyntaxhighlightタグに変えられてしまう。今回はSyntaxHightlight拡張機能が無効のMediaWikiを使っているので、言語にダミー文字列を付加する（付加ではなくダミー文字列だけにしても変わらないが、情報を落とすのは勿体ない気がしたので）。またpandoc側の問題で<code>visual basic</code>のように言語名にスペースが入っていると<code>visual</code>だけになってしまうようなので、スペースをアンダースコアに置換。

<syntaxhighlight lang="python">language = "dummy_str_"+language?.replace(" ", "_");//for MediaWiki without SyntaxHightlight extension</syntaxhighlight>

=== <code>notion-to-md.ts</code>内 ===

==== 特殊文字エスケープ ====

大きく分けて、notion-to-mdの欠点を補うための弱いエスケープ（<code>\</code>の付加）と、pandocでの変換を回避するための強いエスケープ（数値に変換して他で使わないセパレータで囲う）がある。

解説が面倒なのでコードだけとりあえず。

<syntaxhighlight lang="javascript">//`のみcodeに変え、```は```のままという仕様の場合
if (content.type === "text"){
if (type == "code"){
//```の内部では<>は無効なので本来は不要だが、detailsまわりが修正されるまで、<>を最強エスケープの対象としておく。
//無事修正されたので、対象外に
//plain_text = plain_text.replace(/[<>]/g, (c) =>"m_esc_" + c.charCodeAt(0)+"_m")
//バッククォートはmarkdownの```の中でも有害になる珍しい文字であるが、外側と対処法が異なる。
//markdownでコード内に`を書くには、両側をそれより多い`で囲うしかなく（\`や`ではそれがそのまま表示されてしまう）、その実装が面倒である。
//そこで、最強エスケープをかけて、MediaWikiに変換してから元に戻す。ちなみにMediaWikiでは`は特殊文字ではないのでエスケープ文字ではなくベタ書きに戻す。
plain_text = plain_text.replace(/`/g, (c) => "m_esc_" + c.charCodeAt(0)+"_m")

}else{//テキストエリア
//以下は、MediaWikiの特殊文字であるにもかかわらずpandocがそのままべた書きしてしまう文字。最強エスケープが必要。
//これらはMarkdownの```およびMediaWikiのpreの内側では無害である。（外側では特殊文字であるものとそうでないものがある。）
plain_text = plain_text.replace(/[=;:#*'{}~\-\[\]]/g, (c) => "m_esc_" + c.charCodeAt(0)+"_m")

//これらは、Markdownのテキストエリアでは特殊文字だが、MediaWikiの特殊文字ではないあるいはpandocがちゃんと扱えるもの。
//（ただし、"."（ピリオド）のみ、「リンクテキストもURLになっているリンク及びcode内に書かれた（リンクでない）URLがpandocの変換でおかしくなるのを防ぐ」という目的で入れている。）
//この変換は先ほどの最強エスケープより後でなければいけない。（#が最強エスケープされるのを防ぐため）（もちろん同時でもいい）
//スラッシュでのエスケープだと`<`でバグったことがあった（おそらくpandocのせい）ので、&#xx;を使用
plain_text = plain_text.replace(/[`$+&<>\\.]/g, (c) => "&#" + c.charCodeAt(0)+";")

//2つ以上の連続する空白文字は（そのように表示したい特別な理由があると考えて） に変換。これは&のエスケープより後である必要がある。
plain_text = plain_text.replace(/ {2,}/g, (c) => c.split('').map(function() { return ' '; }).join(''))

//notion-to-mdがブロック内改行に対応していないので対応。nbspへの変換より後に行う。
plain_text = plain_text.replace(/\n/g, " \n")
}
//また、"も、mediawikiでの特殊文字ではないが、pandocでは"に変換される。
//ベタ書きでも表示には影響ないが、span id=""の中身に生のダブルクォーテーションが入ってしまう副作用があるし、その他問題が起きる可能性がある。
//下記のように最強エスケープすればそのまま書けるが、"を"にしてデータ量を削減するより安全を取ったほうが良さそうである。
//ちなみに1文字減らすために最強エスケープから"に戻す方法もあるが、"のほうが自動でspan id=""の中身から除去されるようなのでそのほうが良さそう。
//plain_text = plain_text.replace(/["]/g, (c) => "m_esc_" + c.charCodeAt(0)+"_m")
}</syntaxhighlight>
==== ブロック内改行 ====

NotionではShift+Enterによりブロック内での改行が可能であるが、notion-to-mdはこれに対応していないので、Markdownの文法に従って行末に半角スペースを2つ追加する。

また、改行を連続して2つ入れると（末尾に空白2つがあっても）Markdownの改段落扱いになり、意図した表示にならないため、避ける。

==== コードブロックへのキャプション ====

notion-to-mdでは未対応である。とりあえず独自でつけている。

==== ページ間リンク ====

ページ間のメンションであれば、MediaWiki上での記事リンクにする（前述）。そのためのマーカーを付加しておく。


==== 取り消し線&下線の部分の除去 ====

取り消し線と下線が両方指定されているテキストは除去する。これは見出しごとではなく特定の文言だけ非公開にしたい場合のための措置だが、怖いのであまり使っていない。
[[Category:IT]]{{#seo:|title={{FULLPAGENAME}} - Turgenev's Wiki}}