simple file manager file upload
file local contains the line: box.setAttribute("placeholder", "x");
but when it has been uploaded with file Manager it is: box.setAttribute("placeholder", "â—");
does File manager force some font conversion?
does it for both .html file and separate js script file. is there a config setting to prevent this (no idea what it is doing elsewhere with these static files)
That’s not a font conversion, that’s an encoding/charset conversion, which is also a terrible (and subtle) bug.
I don’t know what “raw file” means in this context. Every file has an encoding.
Can you provide us with the file where this happened? (Or an example file that just exhibits the problem if this specific file is sensitive.)
If you’re uploading from a system that has the file command, can you show us the following (on the originating system):
file -bi name-of-file.txt
And, I guess we also want to see what it’s being converted to, so run that on the Virtualmin system, as well.
If you’re uploading from Windows, I would guess that’s where the problem is coming from and may be…challenging to resolve. You probably need a text editor that’s smart enough to use either a plain text encoding or UTF-8. Linux can usually deal with various Windows encoded files, but I’m not sure we can gracefully/safely handle it automatically.
Thank, sort of thought that but could not understand where I introduced it.
well, the files (one each of .html and one .js) were sent to me saved on my PC and I loaded them in VSCode that I use as a standard code editor (no editing), I then used File Manager too upload.
Good old Microsoft! does it again.
I have now used FileZilla and found the files work
I am NOT blaming File Manager here just that some setting in FileZilla must be picking up the difference in OS. (know not what)
didn’t get chance to try that one out, I’ll try to remember for next time.
Nothing secret about the code here (without other supporting routes it is pretty much useless) I have put it up on CodePen so you can see
I was wondering if this was a transfer problem or the basic file format encoding. I vaguely remember back when I still used FTP that it could be set to binary mode. It was always just safer to use binary because regardless of the file type it worked.
Hello, how are you? I have the same issue since updating to Webmin 2.101. When I try to save an XML in the file explorer, I select UTF-8, and it saves it in EUC encoding, Japanese, which destroys the file and causes a fatal error on the server. What can we do?
