Factfinder

Thank you for the reply.

The thing is that removing something from the problematic script could correct the issue and the part that is removed contains normal ASCII characters. The strange thing is that I had no issues with x86 version of the script until yesterday. The script I'm using has worked for many years without issues. What would be the downside if my script contained "High ASCII" character and I used UTF-8 encoding?

Thank you for the reply. I have installed the latest SciTE (4.4.6) as I mentioned earlier. I added those values to SciTEUser.properties, made a new file, and copied the content to the new file. The Encoding under File menu reverts to "Code Page Property" if I close and open the file. The positive change is that the German characters are displayed correctly (I think because we set the codepage to 65001).

If I open the Autoit script I have made, under File -> Encoding choose UFT-8 (not UTF-8 with BOM) everything looks okay and the German characters look okay, but when I close the file and open it or compile it, the Encoding under File reverts to "Code Page Property" and the German characters are misformed. BTW, I thought it was related to the x64 wrapper as I had this issue with the x64 version of a file. But yesterday I had the same issue with the x86 version of the same script and I had to make some changes in order to get the encoding stay to UTF-8. I can't make head nor tale of it. Could you please explain why there was a problem with BOM?

Yes, I recognize the embarrassment. Ideally, we should live with the fact that we are human and make mistakes and it is okay.

Thank you for the clarification and rectification. No apologies are needed. You were trying to help and I appreciate the effort anyway.:)

Thank you for your detailed reply. Those characters that are detected by your script are part of German words. The characters show normally when the encoding is set to UTF-8 and are misformed when set to Code Page Property.

My problem is resolved and I can't say what exactly triggered the issue. I had backups and I went back and examined those backups and found the file with which the issue started to act. I replaced some scripts and the issue was resolved. I understand that a test file is needed but unfortunately I can not provide that. If I put the lines I replaced together with the parametre I mentioned in a new file it doesn't recreate the issue. So there should be different things that interact together and I replaced one of them. I will keep an eye on it and in case it comes back, I will try to put some script together for testing. Thank you for your time.

The SciTE was installed separately. I had installed Autoit with the latest Autoit3 installer. Then installed latest version of SciTE. I did the same this morning again with no result.

Sure it is strange. I compiled your script as x64 bit and ran it. Nothing happened. BTW I don't know if it makes any sense but including the line in this script did not reversed the encoding and the encoding remained on UTF-8. It means the line and the content of my script interact somehow. #AutoIt3Wrapper_UseX64=y Edit: according to the script there are many lines with invalid UTF-8 character. But in fact they are valid none English characters. I gues the reason is that your script opens the file as ANSI.

I have tried many thing with no effect, but now I see it has something to do with the x64 Wrapper. When I remove the following entry, the encoding remains on the selected optiond (UTF-8) as expected: #AutoIt3Wrapper_UseX64=y

Thank you for your reply. The version is 4.4.6.

I have recently have reinstalled Autoit and noticed that every time I close one of my files and open it again, or compile it, the Encoding under File reverts to "Code Page Property". This only happens to one file. Other Autoit files keep UTF-8 encoding as expected. I found another topic here where a similar situation is described. There the issue is resolved bij adding the following to the SciTEUser.properties: NewFileEncoding=UTF8 utf8.auto.check=4 I have tried this with no effect. Also the second line already exists in SciTEGlobal.properties. The file is too big to post it here. I appriciate if someone kan advise me how turn of automatic checking and keep the encoding on UTF-8.

Hi Sven, Yes, I did. I tried many different flags. The closest size was with 1 and it seems that on my main system, it works like 4.

I explained in the previous post that the files have no issues and the hashes are correct. The content of both files is opened directly, they are the same. It is the content of $fcontent string that differs on the two systems. It is all about the BinaryToString() function that causes the inconsistency on my main PC. I guess BinaryToString() is based on a MS function that for some reason is not working on my main system. I have tried FileOpen() with various flags with no success. Thank you for the link.

Thank you. But I think the point was not clear. The files are the same and that is no issue. The issue is that when we look at the content, we don't directly look at the content of the files but what we see is the content that is provided by _HexEncode($fcontent). In fact, BinaryToString($fcontent, 1) works differently on two systems. On my main PC it is working like BinaryToString($fcontent, 4) while on another system with the same file, it is working as expected.

Thank you for taking time. I did another test to see if the issue was related to combining data. $fpath = @SystemDir & "\userinit.exe" $hopen = FileOpen($fpath, 16) $fcontent = FileRead($hopen) $fcontent = BinaryToString($fcontent, 1) MsgBox(0, FileGetSize($fpath), BinaryLen($fcontent)) The size on my system is not the same. So the file shrinks when I use BinaryToString($fcontent, 1). FileGetEncoding($fpath) returns 1024 on both systems. So the file on Windows 10 is Unicode UTF16 Little Endian (without BOM) encoded. I can see the content of the files on both systems with Notepad++. Also using your script makes it even more visible. The files have the same size and hash on both systems but the content differs a little.

In fact, I'm already using $fcontent = BinaryToString($fcontent, 1) as when using $fcontent = BinaryToString($fcontent) the default flag (1) is used. I have used BinaryToString($fcontent, 1) too but no change. It should be related to my main system as it works on other systems.

My own OS is English, but it works on another English language. It worked on a OS with a native language correctly. The string is made as a string, I have used different files and the results are the same. Only on my main macine the results are inconsistent.

Yes, I have tested it too. Thanks for the confirmation.

It is not a redirection issue FileGetSize() and FileOpen() would work on the same file. Running the compiled x64 bit doesn't redirect either and the result for compiled x64 is the same. It is probably something on my main system. On any other machine I have tried the script, it works as expected and the result is as it should be. Only on my main machine the result is inconsistent.

I use BinaryLen() because I need the size in byte. If you run the file script as 32bit on both x86 and x64 machines or you run a 64bit compiled script on the x64 machine, the result is the same. It is definitely not a redirection issue. The script for reading the file size and the file content would go to the same file.

This could be a challenge. I have used the following code to debug a size issue when combining data to upload a file: $fpath = @SystemDir & "\userinit.exe" $hopen = FileOpen($fpath, 16) $fcontent = FileRead($hopen) $fcontent = BinaryToString($fcontent) $filename = StringRegExpReplace($fpath, ".+\\", "") $token = 'qpqpqpqpqp' $boundary = "----158082776" $data1 = '--' & $boundary & @CRLF & 'Content-Disposition: form-data; name="scanToken"' & @CRLF & @CRLF & $token & @CRLF $data1 &= '--' & $boundary & @CRLF & 'Content-Disposition: form-data; name="file"; filename="' & $filename & '"' &@CRLF $data1 &= 'Content-Type: application/x-msdownload' & @CRLF & @CRLF $data2 = @CRLF & '--' & $boundary & '--' $data = $data1 & $fcontent & $data2 MsgBox(0, FileGetSize($fpath)+ BinaryLen($data1&$data2), BinaryLen($data)) I run the script in x32 mode and get a smaller size for BinaryLen($data) on my PC (40900 bytes) while the size of FileGetSize($fpath)+ BinaryLen($data1&$data2) shows the expected size (41701 bytes). I ran the same script on my laptop; both sizes are correct and the same. Both the machines have Windows 10 Home Edition. I ran it on another machine with Windows 11 and the sizes are correct and equal. I need the exact size to be able to upload the file and it seems that on my main computer combining data can lead to distortion. To make sure I have made a clean install of Autoit on my PC but it didn't help. I would appreciate it if anyone has seen this before or could advise me. Thank you in advance.

Also for fun but with StringRegExpReplace: #include <Array.au3> Local $string = "<a>1</a><b>2</b><c>3</c><d>4</d><e>5</e>|<a>1-1</a><b>2-1</b><c>3-1</c><d>4-1</d><e>5-1</e>|<a>1-2</a><b>2-2</b><c>3-2</c><d>4-2</d><e>5-2</e>|" $ret = StringRegExpReplace($string, ".*<a>([^<]+)</a>[^\|]+<e>5-1</e>.*", "$1") MsgBox(0, '', $ret)

$hWnd = "" ; assuming you have no GUI, otherwise this will be the handle to your GUI _Timer_SetTimer($hWnd, 3000, doit) $i = 1 While 1 $i+= 1 WEnd Func doit($hWnd, $iMsg, $iIDTimer, $iTime) #forceref $hWnd, $iMsg, $iIDTimer, $iTime MsgBox(0, "", "Done",1) Exit EndFunc