Open s5bug opened 5 days ago
At first I thought the JNI could be a problem. However on a UTF-8 enabled machine, the "non-Unicode" ANSI functions do work properly with Unicode characters:
PS > Add-Type -TypeDefinition @"
using System;
using System.Diagnostics;
using System.Runtime.InteropServices;
public static class FileApi {
[DllImport("Kernel32.dll", CharSet=CharSet.Ansi)]
public static extern bool CreateDirectoryA(
string pathName,
nuint securityAttributes);
}
"@
PS > mkdir newEmptyDir; cd .\newEmptyDir\
PS newEmptyDir> [FileApi]::CreateDirectoryA("newEmptyDir/渝", 0)
True
PS newEmptyDir> ls
Mode LastWriteTime Length Name
---- ------------- ------ ----
d---- 2024-11-23 09:55 渝
so I don't know where all of this stuff could be coming from.
Argument UTF-8 bytes are mistakenly interpreted as Windows-1252:
In some scenarios, i.e. when running the auxiliary executable directly, the bytes seem to be interpreted as Windows-1252, then as some form of Extended ASCII (
?
appears instead of�
when you ask windows for an A-string with invalid characters):Using the installer set-up shows this off a bit more prominently: when using a Unicode user directory, the new
PATH
variables are created with?
s: And so are launcher scripts: