npp-plugins / mimetools Goto Github PK

Base64 has this by line

If you have many lines Base64 can do it automatically for each line but the URL functions can't and if you have a lot of URLs it eill be very tedious.

Such a feature would be godsend. Highly useful.

URL Encode doesn't converting some symbols

Copied from Issue #10866

Description of the Issue
URL Encode don't converting some symbols

Steps to Reproduce the Issue

1. Type date in iso string format for parameter url : lastUpdateDate<date(2021-10-26T12:15:00.000+05:00)
2. Go to Plugins -> MIME Tools -> URL Encode

Expected Behavior
Converted string
lastUpdateDate%3Cdate%282021-10-26T12%3A15%3A00.000%2B05%3A00%29

Actual Behavior
Converted string
lastUpdateDate%3Cdate(2021-10-26T12%3A15%3A00.000+05%3A00)

Debug Information

Notepad++ v8.1.9.2 (32-bit)
Build time : Nov 21 2021 - 04:27:12
Path : C:\Program Files (x86)\Notepad++\notepad++.exe
Command Line :
Admin mode : OFF
Local Conf mode : OFF
Cloud Config : OFF
OS Name : Windows 10 Enterprise (64-bit)
OS Version : 2009
OS Build : 19043.1348
Current ANSI codepage : 1251
Plugins : ComparePlugin.dll mimeTools.dll NppConverter.dll NppExport.dll NPPJSONViewer.dll

This still seems to be an issue as of Notepad++ v8.6 (64-bit)

I'm trying to install the plugin from plugin manager but I got the following error:

Hi

Running Win10, Notepad++ 7.6.4 x64, MIME Tools 2.5.
Base64 encoding bugged itself up today, used it yesterday with no issues.

When trying for example base64 encode this text, the output is wrong. Text is UTF8.

This is a test www.google.com

VGhpcyBpcyBhIHRlc3Qgd3d3Lmdvb2dsZS5jb20

But the correct output should be:
VGhpcyBpcyBhIHRlc3Qgd3d3Lmdvb2dsZS5jb20=

To reproduce:

1. New File
2. Encoding --> ISO 8859-1
3. Enter Test String: "TEST=ÖÄÜ" and select text
4. MIME Tools - Quoted-printable Encode

Result:
"TEST=3D=C3=96=C3=84=C3=9C"
note: utf-8 encoded

Expected Result (ISO 8859-1 encoded):
"TEST=3D=D6=C4=DC"

sample.txt

   aaaaa aaaaaa &aaaaa;
   &aaaaa = aaaaaaaaaaaaaaaaaaaaaaaaaa(%maaaaa, %maaaa, aaaaaaaa.aaaaa_aaaaaaa, %maaaaaa, m.m_m, "", "")"?a_a=m.m_m&mmmmm=" | mmm_mmm_mmmmm.mmm_mmmm_mmmm_mm.mmmmm;
   
   aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

Description of the Issue
The MIME Quoted-printable Decode fails to decode a pattern that was just encoded by the Encode

Steps to Reproduce the Issue

I have taken the following three URLs as an example, and encoded them:
https://www.automationdirect.com/adc/shopping/catalog/enclosures_-z-_subpanels_-z-_thermal_management_-z-_lighting/enclosures/junction_boxes/jic040403

https://www.automationdirect.com/adc/shopping/catalog/enclosures_-z-_subpanels_-z-_thermal_management_-z-_lighting/enclosures/junction_boxes/jic0403025

https://www.automationdirect.com/adc/shopping/catalog/enclosures_-z-_subpanels_-z-_thermal_management_-z-_lighting/enclosures/junction_boxes/jic040202

When I encode them I get the following result:
https://www.automationdirect.com/adc/shopping/catalog/enclosures_-z-_subpa=
nels_-z-thermal_management-z-_lighting/enclosures/junction_boxes/jic04040=
3

https://www.automationdirect.com/adc/shopping/catalog/enclosures_-z-_subpa=
nels_-z-thermal_management-z-_lighting/enclosures/junction_boxes/jic04030=
25

https://www.automationdirect.com/adc/shopping/catalog/enclosures_-z-_subpa=
nels_-z-thermal_management-z-_lighting/enclosures/junction_boxes/jic04020=
2

Expected Behavior
When I select this text again and run the MIME Quoted-printable Decode routine I expect to get the original URLs replacing the encoded text.

Actual Behavior
Instead I get a popup message with the title "Quoted-printable decode error" and the text "It's not a valid Quoted-printable text" and an "OK" button to dismiss the popup message.

Debug Information
Notepad++ v7.7 (32-bit)
Build time : May 19 2019 - 13:08:20
Path : C:\Program Files (x86)\Notepad++\notepad++.exe
Admin mode : OFF
Local Conf mode : OFF
OS : Windows 7 (64-bit)
Plugins : ComparePlugin.dll DSpellCheck.dll mimeTools.dll NppConverter.dll NppExport.dll

Additional comments:
The file is UTF-8 encoded with Unix line endings. I would expect the plugin to recognize the line endings in the file and adapt to them. It appears to handle them well on encoding, but on decoding it chokes. It does not encode them differently so as to recognize them when decoding them, which it should if it needs to in order to recognize the difference. MIME encoding is meant to work with Unix encoded files just as well as Windows encoded files, though I don't know what the MIME specification says about how to handle the different line endings.

@donho
Have you seen this article? It claims that mimeTools has a security vulnerability associated with some corrupt PEM file.

I don't really understand much about this; the nature of the security vulnerability itself is over my head, and unfortunately the original publication of this vulnerability is written in Korean, which can't be translated by my web browser. I just wanted to make sure you knew right away.

It really sucks that the investigators just went and published the issue rather than warning you first.

Create a new document in Notepad++ and paste in the following string:
lEJk24X1wEOA5CE0hPoa/g==

Highlight the text and then right-click, and choose "Plugin commands > Base64 Decode".

Notepad++'s memory usage will quickly increase, and the program becomes unresponsive.

if I block select text (shift+alt) like so:

and then run, e.g. URL encode, the result is as follows:

i.e. it collapses into one line and also removes the prepending contents of the second line. Expectation in that case would be like so:

Currently, there is only the option to encode a single line to Base64 with padding and it removes the newline character. It's not useful for cases where you want the base64 output to stay separated by line, the same way that the ascii/utf8 input was.

The padding characters are not output when encode strings short string.

For example encoding: "ABCDE-FGHIJKLMNO" with the plug-in yields "QUJDREUtRkdISUpLTE1OTw" but with any number of online tools yields "QUJDREUtRkdISUpLTE1OTw=="

Description of the Issue

This is a feature request to add options to encode/decode XML.
Something similar to existing "MIME Tools \ URL Encode" feature, but for XML :)

https://stackoverflow.com/questions/1091945/what-characters-do-i-need-to-escape-in-xml-documents

Debug Information

Notepad++ v7.8.7 (64-bit)
Build time : Jun 5 2020 - 02:38:56
Path : C:\Program Files\Notepad++\notepad++.exe
Admin mode : OFF
Local Conf mode : OFF
OS Name : Windows 10 Pro (64-bit)
OS Version : 1903
OS Build : 18362.1110
Current ANSI codepage : 1252
Plugins : CodeAlignmentNpp.dll mimeTools.dll NppConverter.dll NppExport.dll

NPP crashes when trying to URL-encode two parentheses characters in utf-8.

Steps to reproduce:

• create or open a file
• set Encoding to UTF-8
• type empty parentheses () anywhere in the file
• select exactly these parentheses
• click on Plugins -> MIME Tools -> Full URL Encode
• NPP crashes

Environment:

• Windows 11 Enterprise, 22H2
• Notepad++ v8.5.7 (64-bit)
• Mime tools 2.9

I first encountered this issue with part of a JWT: eyJhbGciOiJub25lIn0. According to https://www.base64decode.org/, this decodes to {"alg":"none"}. However, the MIME Tools Base64 Decode removes the last character: {"alg":"none".

A little experimenting shows this is also the case for encoding. If I encode Hello world, the result is SGVsbG8gd29ybA. If I decode this with https://www.base64decode.org/, the result is Hello worl. MIME Tools gives the same result. Encoding Hello world with https://www.base64encode.org/ gives SGVsbG8gd29ybGQ=, which is is decoded correctly with MIME Tools.

If I use Hello world! as input, this encodes to SGVsbG8gd29ybGQ (the same as https://www.base64encode.org/ but without the trailing =; https://www.base64decode.org/ results in Hello world), which is then decoded to Hello worl. In other words, using just this plugin, I lose one character in encoding and one in decoding.

Notepad++ version: 8.4.1 (64bit)
MIME Tools version: 2.7

I have the word 'банк' (bank) in Ukrainian. When I try encode this word I get a result
'=D0=B1=D0=B0=D0=ㄽD0=BA'.
But correct result is
'=D0=B1=D0=B0=D0=BD=D0=BA'

Fix please.

Now this plugin supports only UTF-8 encoding for Base64 encode and decode. While UTF-16 is less frequently used in Base64, such variation still exists and is used by PowerShell encoded commands for example.

It would be nice if this plugin could properly handle it as well.

Decoding the string YQBh should produce 3 characters (second is NUL), but it only produces 1 character.
Encoding the 3 characters produces string YSBh instead of YQBh - NUL character is replaced with space.

It works correctly in version 2.1.

The samples used in the SAML 2.0 Wikipedia page don't decode correctly when using MIME Tools:

<?xml version="1.0" encoding="UTF-8"?> <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="aaf23196-1773-2113-474a-fe114412ab72" Version="2.0" IssueInstant="2004-12-05T09:21:59Z" AssertionConsumerServiceIndex="0" AttributeConsumingServiceIndex="0"> <saml:Issuer>https://sp.example.com/SAML2</saml:Issuer> <samlp:NameIDPolicy AllowCreate="true" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/> </samlp:AuthnRequest>

After Encoding and Decoding:

<?xml version="1.0" encoding="UTF-8"?> <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assert " ID="aaf23196-1773-2113-474a-fe114412ab72" V 2.0" IssueInstant 2004-12-05T09:21:59Z" Assert ConsumerServiceIndex="0" AttributeConsumConServiceIndex="0"> Index:Issuer>https://sp.example.com/ 2</ndex:Issuer> Indexp:NIssIDPolicy AllowCreate="true" Format/ 2</ndex:Issuer> Indexp:Issid-format:transient"/ / >

Contains many nul chars.

is there anyway to make a shortcut key for decode and encode!