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 :-)
Related
I am trying to split a cell/string simply in MS365 using Labscript.
Split() or LEFT does not exist in Labscript which is another reason why I am not sure why MS claims that javascript is the language of use for Labscript.
Thanks!
I just realised that substr() works (or maybe even split). These commands do not show up as options though as you write the code unless the code is executed first and the string is verified as a string (I was reading a cell that I wanted to split).
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)))
I am passing an object via the url using:
encodeURIComponent(JSON.stringify(myObject))
"ä" is encoded as "%C3%A4" on my local server.
Unfortunately it is encoded as "a%CC%88" on the webserver.
Which breaks my app because it is part of the name of a database field which isn't found when wrong encoded. And I can't control that there are no ä's in field names because the app allows users to upload their own data.
How can I make sure that "ä" is always encoded correctly?
SORRY. To make this clear: The encoding happens both times client-side in the browser. But when the web-app is served from the webserver the "ä" is encoded as "%C3%A4" instead of "a%CC%88" (I've tested both in the same chrome browser)
Thanks for all your help. It got me to dig deeper:
I have code that runs on an event. It loops through checkboxes and creates an array of objects containing (also) the field names. The code gets the field names from an attribute named "feld" of the checkbox:
<div class="checkbox">
<label>
<input class="feld_waehlen" type="checkbox" dstyp="Taxonomie" datensammlung="SISF Index 2 (2005)" feld="Artname vollständig">Artname vollständig
</label>
</div>
running this code:
console.log("this.getAttribute('feld') = " + this.getAttribute('feld'));
gives as expected: $(this).attr('feld') = Artname vollständig
If while looping, I run:
console.log('encodeURIComponent("Artname vollständig") = ' + encodeURIComponent("Artname vollständig"));
the answer is correct: encodeURIComponent("Artname vollständig") = Artname%20vollst%C3%A4ndig
But if I run:
console.log("encodeURIComponent(this.getAttribute('feld')) = " + encodeURIComponent(this.getAttribute('feld')));
the answer is: encodeURIComponent(this.getAttribute('feld')) = Artname%20vollsta%CC%88ndig
This happens all in the browser. But the issue only appears, when the web-app is served from the webserver (a couchapp running on cloudant.com).
How can it be that the method "getAttribute" returns a different encoding?
The following code has been tested on Chrome 29 OS X, IE 8 Windows XP.
encodeURIComponent("ä") //%C3%A4"
decodeURIComponent("%C3%A4") //ä
so basically "%C3%A4" should be the expected output.
I think the issue here might be encodeURIComponent require a UTF-8 encoding while your server-side language returns something other than this.
encodeURICompoent - MDN
just a follow up in case somebody runs into this issue later.
It seems to be unique to cloudant.com where my couchapp was hosted.
This is the answer I got from their very helpful support:
OK - I think I've found the culprit. The issue is that, due to internal optimisations (which are not present in CouchDB), the form of unicode strings can get changed. In this case, ä is represented as:
U+0061 LATIN SMALL LETTER A character
U+0308 COMBINING DIAERESIS character (̈)
instead of
U+00E4 LATIN SMALL LETTER A WITH DIAERESIS character (ä)
Both are semantically equivalent, so the fix is to normalize your unicode strings before comparison. Unfortunately, JavaScript has no built-in unicode normalization, but you can use a library such ashttps://github.com/walling/unorm.
It's not an issue for me any more as I changed to a virtual server running on digitalocean.com with vanilla couchdb (and am very happy with it).
But I do think this could hit others developing couchapps in German or other languages needing utf8 and hosting them on cloudant.com
Thanks for your great help.
Alex
I've been training heavily in JS obfuscation, starting to know my way around all advanced concepts, but I recently found an obfuscated code, I believe it is some form of "Native Javascript Code", I just can't find ANY documentation on this type of obfuscation :
Here is a small extract :
'\141\75\160\162\157\155\160\164\50\47\105\156\164\162\145\172\40'
It is called this way :
eval(eval('\141\75\160\162\157\155\160\164\50\47\105\156\164\162\145\172\40'))
Since the code is the work of another and I encoutered it in a JS challenge I'm not posting the full code, so the example I gave won't work, but the full code does work.
So here is my question:
What type of code is this? And where can I learn more about it?
Any suggestions appreciated :)
It's just a string with the characters escaped. You can read it in the JavaScript console in any browser:
console.log('\141\75\160\162\157\155\160\164\50\47\105\156\164\162\145\172\40')
will print:
"a=prompt('Entrez "
It's just escaped characters, one part outputting the string of a query and another actually running the returned string - try calling it in a console.
eval('\160\162\157\155\160\164\50\47\105\156\164\162\145\172\47\51')
Might help?
These numbers is the ascii codes (http://www.asciitable.com/index/asciifull.gif) of characters (in Octal representation).
You can convert it to characters. This is used when somebody wants to make an XSS attack, or wants to hide the js code.
So the string what you written represents:
a=prompt('Entrez
The js engines, browsers can translate the octal format to the 'real' string. With eval function it could run. (in case the 'translated' code has no syntax errors)
I'm using JSON.Stringify and JSON.parse everywhere and it works fine with Firefox. It's working no more with IE9 nor does it work in IE8. What can I do?
JSON.stringify starts with a lower-case s. Both stringify and parse are available in IE8+, but only in standards mode.
Prepend your document with <!DOCTYPE html> if you're currently using quirks mode. Also, watch the capitalization of the JavaScript methods you call - all built-in ones start with a lower-case character.
why do you want to depend on the browser having the object instead just include the script file by Douglas Crockford.. You can find the minifed file here: http://www.json.org/js.html
Once imported you dont have to worry abt the method existing in a browser.
For an alternative, in a scenario where you might need to run in strict mode for whatever reason (I have another library that includes "use strict"), you can look here: https://github.com/douglascrockford/JSON-js. I modified this to check first if JSON is undefined, and only generate the function JSON.parse if it is:
if (typeof JSON === "undefined") {
var JSON = {
parse: <insert value of json_parse from library here>
};
}
My issue was application code not working in IE9 (strict mode being used by a participating library, I believe). That solved the problem for me.
the mere issue is, that sending UTF-8 headers will invalidate the JSON (IE doesn't/didn't like that). as the issue is described, that might still apply for IE9... once wrote a how to, a few years ago. adding JSON support to a browser which can parse native JSON is probably not the optimal solution, since it produces useless overhead - only because failing to deliver the JSON in the expected format.