Jump to content
Sign in to follow this  

Unicode in pathname

Recommended Posts


    I encounter some problem with Unicode characters in path. In the following lines, the $MyPath variable contains a directory name (full path name, including letter drive).

    When using _ArrayDisplay, the Unicode character is correctly displayed. So $MyPath variable is OK.

    But both ConsoleWrite command loose this Unicode char.

    Later, in the same code, when I try to access to a file inside such a directory, the file is not found (because the path has lost its Unicode char).

$TotDir[0] += 1
ConsoleWrite("$TotDir[1] = " & $TotDir[1] & @CRLF)
ConsoleWrite("$MyPath    = " & $MyPath & @CRLF)

     I saw that AutoIt supports Unicode, but I can't find relevant information for my case. If someone could help me, it would be great :guitar:

     For info : AutoIt under Seven x64.

Thanks in advance

Share this post

Link to post
Share on other sites

i could not reproduce your problem. however, off-hand i'd say use FileGetLongName on the path and see what you get.

next, please provide 3 screenshots: the path as displayed by 1) file manager, 2) _ArrayDisplay , and 3) ConsoleWrite

Share this post

Link to post
Share on other sites

If the characters display in the array, they will not disappear unless you modify the array contents. If you include the file name directly in your code, there is a chance it will be corrupted if not saved with the correct encoding. I tend to convert hard coded unicode to binary, but that's not meant to be a universal solution. I am wondering how you are trying to access the file.

The following test shows that a file name which includes unicode can be opened without any problem. Place the script in the same folder as your file, copy the (unicode) file name to the clipboard and then run the script.


Local $sName = ClipGet()
Local $sPath = @ScriptDir & "\" & $sName

Local $hFile = FileOpen($sPath)
If $hFile = -1 Then Exit

MsgBox(0, "Success", "This file has been opened :" & @CRLF & $sName)
Edited by czardas

Share this post

Link to post
Share on other sites

    Thnx czardas for your help. :bye:

    As you said, the Unicode characters were still in my variable, but the string was converted to regular ASCII with ConsoleWrite and through my DllCall (filename is sent to C code compiled to a DLL).

    This is a public GNU code which I have changed to receive a wchar_t instead of a char and also changed the fopen to _wfopen; the DllCall is now done with "wstr" instead of "str".

   Everything works fine now !! :thumbsup:

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Create New...