| 項目 | 値 |
|---|---|
| 窓 | conhost.exe で新しく開いた cmd（開始時 932）。chcp 932 は実行しない |
| bun | 1.4.2+744846f84 ／ 1.4.3-canary.1+bb35d1b81 |
| OS | Windows 11 Home 10.0.26300 |
| スクリプト | tests/manual/issue-43660-repro.cmd <bun> <ログ> |
スクリプトは次の 2 本を順に流す。2 本の窓（安定版・canary 版）は同時に開いた。
bun -e "console.log('bun 2 bun 日本語')" | bun -e "process.stdin.pipe(process.stdout)"
bun -e "console.log('bun 2 bun 日本語')" | bun -e "process.stdin.pipe(process.stdout)" > ログ.bytes
1・2 回目は chcp の値をログにだけ書いた。3 回目は画面とログの両方に書き、見出しを ASCII にした。
この 3 回の後、スクリプトの文字列を abc 東京大阪 xyz に変えた（化けても壊れたバイトが残らず、改行も消えないため。計画の T5 を参照）。この資料の結果は、変える前の bun 2 bun 日本語 で取ったもの。
結果は回の順に並べる（1 回目・2 回目・3 回目）。✅ 期待どおり ／ ❌ 期待と違う ／ ⚠️ 入力側だけ 932 に戻った（chcp の数字は 932 だがメッセージが英語） ／ ⬜ 未確認（2 回目の画面は見ていない）。
| 確かめたこと | 1.4.2 | 1.4.3-canary.1 |
|---|---|---|
| 画面の表示 | ❌⬜❌ | ❌⬜✅ |
| 画面に出したあとのコードページ | ❌❌✅ | ⚠️❌✅ |
| ファイルに出したあとのコードページ | ❌❌✅ | ❌❌❌ |
| ファイルに届いたバイト列 | ❌❌✅ | ❌❌✅ |
1.4.2+744846f84
[1] before
現在のコード ページ: 932
--- bun to bun, output to console ---
bun 2 bun 譌･譛ｬ隱・[2] after console run
現在のコード ページ: 932
--- bun to bun, output to file ---
[3] after file run
現在のコード ページ: 932
--- end ---
続行するには何かキーを押してください . . .
1.4.3-canary.1+bb35d1b81
[1] before
現在のコード ページ: 932
--- bun to bun, output to console ---
bun 2 bun 日本語
[2] after console run
現在のコード ページ: 932
--- bun to bun, output to file ---
[3] after file run
Active code page: 65001
--- end ---
Press any key to continue . . .
| 回 | 日本語の部分 |
|---|---|
| 1・2 回目（両版） | ef bf bd ef bf bd ef bf bd 7b ef bf bd ef bf bd（U+FFFD と {） |
| 3 回目（両版） | e6 97 a5 e6 9c ac e8 aa 9e（正しい UTF-8） |
1・2 回目でファイルに届いたバイト列が壊れていたのを、当初は「bun のパイプを流れるデータが壊れる」と読んだ。これは誤りだった。
日本語 は UTF-8 として読めず、bun には U+FFFD が渡った壊れたバイト列は、bun が残したコードページで 同じ窓の cmd がスクリプトを読み違えた ことの証拠である。1・2 回目に日本語の見出しが化けた理由も同じ。
未検証。各 bun が「起動時に今の値を控えて 65001 にし、終了時に控えた値へ戻す」と仮定すると、観測をすべて説明できる。
1.4.2 の 3 回目の 譌･譛ｬ隱・ は、UTF-8 の e6 97 a5 e6 9c ac e8 aa 9e を CP932 として読んだ形である。最後の 9e が 2 バイト文字の先頭と見なされ、続く改行を巻き込んで ・ になったため、改行も消えた。受け手の bun は画面に UTF-8 のバイト列をそのまま書いている（WriteConsoleW を使っていない）と考えられる。
pause のメッセージ）まで巻き込む