I'm currently rewriting an angular1 app to angular5.
The authentication service calls this line:
btoa(unescape(encodeURIComponent(password)))
Unescape seems to be depreciated but without it some passwords don't work (don't ask me why, I think it has something to do with some special characters, the testpassword contained a §)
What would be the best way to handle this? Can I throw this function out somehow? My Editor doesn't even know it and shows this line as faulty (Intellij).
That seems odd.
Anyways unescape has been replaced with decodeURI.. For verbosity you can try:
btoa(decodeURI(encodeURIComponent(password)))
Related
Trying to create a simple 'mailto' function using javascript. I just need to be able to send some links (like: See this article bla bla).
Some of the links I need to send include spaces, danish chars. So I've been using the
encodeURI() function.
The problem arises when I try to mail the link (sample code below)
var _encodedPath = encodeURI(path);
var _tempString = "mailto:someemail#somewhere.dk?subject=Shared%20from%20some%20page&body=" + _encodedPath;
If I output the _tempString to the console I get the correct encoded string. However when using the same string in 'mailto' the string loses it's encoding and returns to the way it was before.
Any clue as to why this is?
Thanks in advance :)
The link is decoded when you click it - that's normal. Since you have an http link within a mailto link, it should be encoded twice.
Email clients do their best to make things that look like links clickable. They typically decide where the link ends in a somewhat arbitrary and unpredictable manner.
In email, the best way to keep a link contiguous is to enclose it in angle-brackets like this:
<http://www.example.com/url with spaces>
But this isn't foolproof. Email is fragile and you can't control the content well enough with a mailto link. It might be better to try to reduce the complexity of the url - perhaps by providing or utilizing a url-shortener service. Any url longer than 74 or so characters is likely to be mangled by some email clients.
You should use encodeURIComponent instead of encodeURI.
More information here.
this site helped me solving any troubles with mailto links:
http://www.1ngo.de/web/formular.html
may be it's not the nicest way, but it always works with every browser i know. And it also has very cool algorithm implemented to format the content so that everything should be alright. Just try it and play around a little with code by quoting out parts of the code and you will understand very fast what exactly happens there and how to modify it for your wishes. Althoug it's a little late I hope this one helps anybody checking this question.
althoug it's in german, you just need to copy the code shown there and run it and experiment with it.
So I am trying to decode a string that was previously urlencoded with php in Node. About a month ago I had it working with:
querystring.unescape(str.replace(/\+/g, '%20'));
Then it just stopped working - not sure if it was some Node upgrade or what. After playing around it seems I can just use 'unescape()' but I am not sure it if it's foolproof yet.
unescape(str.replace(/\+/g, '%20'));
My question is what is the best way and has anyone else noticed this issue. Note that the first line works with simple strings but breaks down with odd characters - so maybe some encoding issue I am not seeing.
Here's a string:
%E6.%82%CCI-T%8C%01+A
Now go to http://www.tareeinternet.com/scripts/unescape.html and decode it. That is my original (it's an RC4 encrypted string). I want Node to return that string.
If you just use the unescape function that's built in into Node.js, your result should be what you want.
Using Node.js 0.10.1 and running
unescape('%E6.%82%CCI-T%8C%01+A');
on the interactive shell, I get
'æ.ÌI-T\u0001+A'
as result which looks pretty much like what you would like to get.
Hope this helps :-)
When I look at the source code of the dojo 1.7 amd dependency list, i see the following:
define(["./_base/kernel", "./has", "./dom", "./on", "./_base/array",
"./_base/lang", "./selector/_loader", "./selector/_loader!default"],
The only use of an exclamation mark I know is for plugins, I haven't seen this "!default" before.
I read this page "https://github.com/amdjs/amdjs-api/wiki/AMD" and googled about it, but I did not find any answer.
Can anybody help me with that!
Thanks
Wolfgang
Update:
Thank you, Ates Goral, for your answer.
Now everything is clear to me.
Then, the irritating thing for me with this special case was, that "./selector/_loader" occurs twice in the above line, one time without parameters and the next time with a parameter. I saw people writing "dojo/domReady!", so I thought it was mandatory to write an exclamation mark for a plugin, even without parameters. Now I have learned that plugins don't need an "!" and I will write "dojo/domReady".
Another Update:
Today I found the following interesting statement (main.js of https://github.com/csnover/dojo-boilerplate):
The “!” after the module name indicates you want to use special plugin functionality; if you were to require just “dojo/domReady”, it would load that module just like any
other module, without any of the special plugin functionality.
I don't know if this statement is correct. It it is correct, then "./selector/_loader" would have some kind of hybrid functionality?
http://livedocs.dojotoolkit.org/loader/amd
When a module identifier passed to require or define contains an "!",
the loader splits the string in two at the exclamation point. The
string to the left of "!" is treated like a normal module ID and is
used as the identifier for the desired plugin; the string to the right
of "!" is passed to the plugin for processing.
In your case, "default" is being passed to the plugin.
I always have noticed this, including in versions before as well. About half way through jQuery's compressed version you'll see some regex:
[^[\]]*\]|['"][^'"]*['"]|[^[\]'"]+)+\]|\\.|[^
The error appears to be at ['"]
I'm sure it's not really a syntax error, but all my code editors recognize it as one, which makes development a pain if I try to combine JavaScript files. Does anyone know what's going on here?
It's a character entity in a regular expression, as specified by the square brackets. There are no restrictions on quote characters in them. All that's going on is buggy syntax highlighting. Ask the developer of your editor.
your code editor sucks, this isnt a syntax error if its inside of a regex literal, which i suspect it is.
the code editor you use probably doesnt support regex literals properly, and that its a string , which would cause the error
When we write in a Javascript expression :
expression < <%=variableJsp%>
the double "<" seems to be a problem and the JSP is not interpreted ?
Is it a fault of the other servers that should not accept this type of expression ? Or WebSphere that bugs ?
Your small code-sample looks like something we do without problems.
Try creating a JSP that illustrates the problem, and nothing else. Either create a new from scratch, or remove everything not relevant to the problem.
Chances are, you will find that the error is not in your code-sample. But if you can make a small JSP-file (a few lines) that illustrates the problem, please show it to us.
I find it generally a bad idea to inline javascript on jsp pages.Your problem is only one of the reasons to make javascript functions external.
Although I do not know websphere, this has happened to me on other containers.
If you insist on keeping it inline, you can probably use
expression < <%=variableJsp%>