We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
stdin.read
stdin.readSync
stdin.read (and stdin.readSync) corrupt non-ASCII input on Windows.
To reproduce:
const c = new Uint8Array(6); Deno.stdin.read(c).then(() => console.log(c));
Then, enter a non-ASCII character. The resulting bytes will be corrupted on Windows.
Examples, with trailing LF/CRLF/null bytes truncated:
[195, 191]
[152]
[196, 128]
[65]
[196, 129]
[97]
[229, 149, 138]
[63]
[240, 159, 166, 132]
[63, 63]
Expected results are the UTF-8 bytes. Results on Linux are as expected.
The text was updated successfully, but these errors were encountered:
This stems from Deno reading directly from console input as a file, which uses the console's current code page rather than Unicode (see High-Level Console I/O). In the example, 'ÿ' maps to 152 in code page 437 (OEM-US).
Instead ReadConsoleW should be used, as in Rust's std::io::Stdin.
ReadConsoleW
std::io::Stdin
@dsherret Is there a reason Deno doesn't use Rust/Tokio's stdio implementation? If not, would a PR be welcome?
Sorry, something went wrong.
Yes, a PR would be welcome. I believe it should use std::io::stdin here when StdFileResourceKind::Stdin:
std::io::stdin
StdFileResourceKind::Stdin
deno/ext/io/lib.rs
Lines 398 to 400 in 3cd7abf
Similar to how it does this for write:
Lines 377 to 383 in 3cd7abf
Hey, I just stumbled across this issue having the same problem. Characters like ÄÖÜ (non ASCII) are corrupted. Any update on when this gets fixed?
ÄÖÜ
Thanks
Successfully merging a pull request may close this issue.
stdin.read
(andstdin.readSync
) corrupt non-ASCII input on Windows.To reproduce:
Then, enter a non-ASCII character. The resulting bytes will be corrupted on Windows.
Examples, with trailing LF/CRLF/null bytes truncated:
[195, 191]
[152]
[196, 128]
[65]
[196, 129]
[97]
[229, 149, 138]
[63]
[240, 159, 166, 132]
[63, 63]
Expected results are the UTF-8 bytes. Results on Linux are as expected.
The text was updated successfully, but these errors were encountered: