vscode-remote-workspace icon indicating copy to clipboard operation
vscode-remote-workspace copied to clipboard

ISO8859-1 encoding unusable on SFTP (incl. solution approach)

Open PBProgrammer opened this issue 6 years ago • 0 comments

After a lot of trial and error, I found that the reason why opening a file with an ISO8859-1, or latin1, encoding didn't work when opening a file via SFTP, without all characters like German Umlaute and certain other special characters¹ all coming out the same way, as an identical garbled Mess. When using the SFTP protocol. there is some kind of mistake made somewhere along the way. Saving the files works perfectly fine, but when retrieving the data, the encoding fails. (verified by using the extension to save special chars, then downloading the file via FTP-Client -> displays the characters just fine).

By editing various files, I finally found a solution, although it is a very crude one. I opened the following two files and in all functions that got passed the variable "encode" or "enc", I just set those variables at the beginning of the function to "latin1". This means that no other encodings are usable until a more sophisticated solution is found, but now all files display just fine. Filepaths: \User.vscode\extensions\mkloubert.vscode-remote-workspace-0.40.0\node_modules\ssh2-sftp-client\src\index.js \User.vscode\extensions\mkloubert.vscode-remote-workspace-0.40.0\node_modules\vscode-helpers\lib\index.js

For a permanent solution, please check those passed parameters and their calling functions, make sure they accept/correctly pass the arguments given in the .workspace file settings and interpret all variations of "[iI][sS][oO]\s?8859-?1" (Regex) as "latin1", seeing as they are equivalent.

Various other information:

  • All kinds of attempts to edit the .workspace file completely and utterly failed, I tried for hours. The info section also wasn't of any help.
  • Changing the first of the two files will change the display of the characters. Before, they were all displayed as the same nonsense (see picture), afterwards, they were each displayed as different nonsense strings. So the first step allows for the correct retrieval of characters, the second as the correct displaying of them.
  • There was no workaround, we are using a very old codebase that was programmed in a different IDE, in some of them, the special characters are hardcoded, meaning you can't open, change and then save them, unless you identify and rewrite all the special characters, guessing which one should be which. Also, writing "ä" is simpler than writing "ä"

1: In particular these characters: "ÄäÖöÜüß©"

PBProgrammer avatar Feb 05 '19 11:02 PBProgrammer