German Umlauts + btoa(unescape( encodeURIComponent( ...

[stefanibus]

Hi! saving the encoded URL causes a severe encoding issue when the Notepadlet get saved and then displayed via my localhost.

This is the issue : German Umlauts will no loger be displayed propperly.

The solution to this issue might be to apply unsecape before encoding the window.url.

I can imagine this solution to improove the Notepadlet generally. I can only see an improovement and no downside in applying unescape.

Please find the enhanced line of code below. The creator of this Notepadlet might decide whether or not this shall be included to the notepadlet .

setTimeout(function() { window.location = 'data:text/html;charset=utf-8;base64,' + btoa(unescape( encodeURIComponent( document.documentElement.outerHTML ))); }, 200); });

[jehna]

Hey, thanks for adding this issue

How can I reproduce this bug? On which browser?

[jehna]

On chrome and firefox at least äöåü seems to work just fine

[stefanibus]

Hey, it is not easy to replicat this issue. Please run through the following process on your windows operating machine via chrome browser and let me know your result: open notepadlet, write some german umlauts or any other special characters I suppose, then save the document locally. Open it and you might realize the result eventually still looks good. Then display it on your local or on your public server and you might witness the special characters might not display propperly. I played around with different charset encoding a lot until I finally grasped the characters need to do be escaped before they get encoded.

Let me know once you had the time to digg into this interesting issue and verify this. Please find two links below, they will help you get started. Especially the first one:

http://forums.enyojs.com/discussion/427/please-please-please-dont-use-atob-btoa

http://www.keynotesupport.com/websites/special-characters-international-letters.shtml

Am 11. März 2017 20:10:08 MEZ schrieb Jesse Luoto [email protected]:

Hey, thanks for adding this issue

How can I reproduce this bug? On which browser?

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/jehna/notepadlet/issues/5#issuecomment-285892525

-- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

MFG Stefan Brück

Make-Mobile | Die Onlineagenten Agentur für digitale Transformation Stefan-Oliver Brück Heckscherstrasse 28 20253 Hamburg Germany Telefon: +49 (0)40 / 98 67 15 - 11 Web: www.make-mobile.de

USt-ID-Nr.: DE212443387

[jehna]

Hey. I tested with the following process with windows 7 + chrome (latest) and could not reproduce the bug:

How I tried to reproduce

1. Open notepadlet
2. Write äöäöä
3. Save file to disk
4. Run python -m SimpleHTTPServer in the directory where you saved the file
5. Open http://localhost:8000/ and select the file you just saved

Result:

The string äöäöä reads out just fine.

[jehna]

My best guess currently is, that your web server sets charset header that conflicts with the charset that's set when you save the file.

There's a couple of things you could do:

1. Send a link to malformed file

If you have some public server where you can reproduce the bug, it'd be great to see it in order to have a look at the headers the web server is sending. That might help to find the bug.

2. Write a more detailed reproduce steps

I'd need to be able to reproduce the bug so I can validate what the unescape(encodeURIComponent(...)) is doing in your case and whether it is the correct fix for the problem.

[jehna]

In addition to the number 2 in the previous comment: This is a good template that I've used to describe the issue:

How to reproduce:

1. Write all necessary steps to reproduce the bug, like
2. Open ...
3. Click ...

(include all versions of software you were using)

Expected result:

What do you expect to happen after your "how to reproduce" steps

Actual result:

What actually happened?

[stefanibus]

The following URL will describe the issue in full detail. It is the exact same URL I already enclosed to my above post. You will find the issue your notepadlet is currently facing descibed there in full detail. All you need to know is mentioned there. Along with the problem description comes a detailed suggestion on how to solve the issue. Once you studied the content of that document closely, please let me know if any further questions remain open.

http://forums.enyojs.com/discussion/427/please-please-please-dont-use-atob-btoa

Am 12. März 2017 13:03:49 MEZ schrieb Jesse Luoto [email protected]:

In addition to the number 2 in the previous comment: This is a good template that I've used to describe the issue:

How to reproduce:

1. Write all necessary steps to reproduce the bug, like
2. Open ...
3. Click ...

(include all versions of software you were using)

Expected result:

What do you expect to happen after your "how to reproduce" steps

Actual result:

What actually happened?

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/jehna/notepadlet/issues/5#issuecomment-285940132

-- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

MFG Stefan Brück

Make-Mobile | Die Onlineagenten Agentur für digitale Transformation Stefan-Oliver Brück Heckscherstrasse 28 20253 Hamburg Germany Telefon: +49 (0)40 / 98 67 15 - 11 Web: www.make-mobile.de

USt-ID-Nr.: DE212443387

[jehna]

@stefanibus I understand from the forum that there is an issue with btoa/atob with characters outside Latin-1 range. I've opened the issue #6 to check it out, thanks for pointing it out.

However Latin-1 does include all German language characters, so this does not explain how your scenario is not displayed correctly.

Could you provide more detailed information about the web server you are using or provide a more detailed info about how to reproduce this issue?

I want to point out that "display it on your local or on your public server" is not detailed enough, as I did try to display the page with SimpleHTTPServer and it worked just fine. So any info about your server or other way to reproduce this bug would be appreciated.

[stefanibus]

feel free to either encode or not encode. Encryption issues are sometimes very hard to track down. I played my part by suggesting to encode the html before encrypting it. Either you coose to encode or you don't. Can you see any negative side-effect if you choose to encode before you encrypt?
Regretfully I will not find the time to fully documentate the issue I ran into.

You may just keep this issue in mind, and watch out for further users eventually confirming this issue in future. And take aktion somewhen in the future.

Thank you again for the Notepadlet Sstem - it is a little dream come true for me ; ) I will use it frequently !