adamhartford / vscode-base64 Goto Github PK

Hi there,

We decided to remove this extension from the https://github.com/open-vsx/publish-extensions repository, since it has not had any activity for a while and we try to make the list of published extensions shorter.

This means that new versions of the extension will not be available on the OpenVSX registry, but feel free to enable automatic publishing yourselves, we made a pretty easy guide in our repo [1].

Feel free to close this, just wanted to let you know :)

Sir, ask for help.
I need to put a string to decode（ the string is base64 format），and display it by hex format。But your tool conversion differs from the notepad++ conversion。notepad++ is right for me.
egg.
string is 9PUAQCkAAAEB/gEAAGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHP9Ps=
your tools convert result is (base64 decode)
3F3F004029000001013F010000650000000000000000000000000000000000000000000000000000000000000000013F3F3F
notepad++ is (base64 decode)
F4F500402900000101FE01000065000000000000000000000000000000000000000000000000000000000000000001CFF4FB

Can you say why? thank you

CMD + E is the default shortcut for "Find with selection" on Mac OS (and VS Code), and the default shortcuts for this extension conflict with that.

I know I can remap the shortcut, but I think in general an extension should not want to override any of the (system) defaults.

On loading an XML file that has an embedded PDF file as base64 encoded string, this plugin might produce wrong results.

Consider this PDF as example, which contains a simple data table and nothing more. While Notepad++ is fine on converting the PDF or its base64 string representation back and forth, VSCode and/or this plugin produce wrong results. The original PDF is 66 KB while the PDF after conversion is 110 KB in size.

I assume this is an issue of the Buffer class itself as I already tried a similar approach before leading to the same issues. It seems that the string is stored as uft-16 instead of utf-8 somehow, which would explain the almost doubling in size, I guess.