TLDR;
FIXED AS FOLLOWS
selectedValue = selectedValue.replace(/\s+/g, '')
Thanks to: Richard Macarthy and Aaron Digulla for the answer, which led me down the poath to the correct answer.
Just tp be clear, it seems Grunt was adding this whitespace for some reason. The fix is very simple...
ORIGINAL QUESTION
I have an JSON request, which get the contents of a JSON file to be used for data visualisations using d3.js.
This all works fine locally, but when I run grunt build the URL string gets an %20 injected into it from nowhere...
Here is how the string looks before I run Grunt:
d3.json("json/wards-info/"+selectedValue+"-wards-data.json", function(error, newDatas) {
newData = newDatas;
newWardsData = newWardsDatas;
drawMap(newData, newWardsData);
});
Which computes to:
http://localhost:8080/app/json/wards-info/liverpool-ward-data.json
After I run Grunt build the computed URL string changes to:
http://localhost:8080/dist/json/wards-info/liverpool%20-ward-data.json
As you can see, it appears to be adding %20 between liverpool-ward
Is this because of grunt, or due to something else?
%20 usually represents a space in HTML URL Encoding, try to make sure there are no spaces in your output.
You can use something like this to help:
string.replace(/ /g,'') to strip the white spaces out. Where string is your URL.
Either that or try this:
.replace(/%20/g,'')
Simply check your selectedValue value. There is a space before - character. Either remove it, or call trim before using it.
Should solve your problem.
It's probably because of something else. %20 is added because of URL escaping rules (which d3.json() probably applies; Grunt shouldn't have an effect here) but what it means is that selectedValue ends with a space character. I've read in your comments that you're 100% sure that there isn't one but if that was true, then there wouldn't be a %20 in the URL. Computers don't add things just for fun, there is always a reason.
So my suggestion is to debug the code as it runs to see what the variable contains, then search your whole code base for -wards-data.json (because maybe there is a second place in the code that you forgot about).
If that doesn't work, then you'll have to tell us more about the Grunt config (are you compressing scripts, obfuscating? Do you have plugins installed?) Also show us the code which Grunt generates out of your input.
Related
I use browserless.js (headless Chrome) to fetch the html code of a website, and then use a regular expression to find certain image URLs.
One example is the following:
https://vignette.wikia.nocookie.net/moviepedia/images/8/88/Adrien_Brody.jpg/revision/latest/top-crop/width/360/height/450?cb\u003d20141113231800\u0026path-prefix\u003dde
There are unicode characters such as \u003d, which should be decoded (in this case to =). The reason is that I want to include these images in a site, and without decoding some of them cannot be displayed (like that one above, just paste the URL; it gives broken-image.webp).
I have tried lots of things, but nothing works.
JSON.parse(JSON.stringify(...))
String.prototype.normalize()
decodeURIComponent
Curiously, the regular expression for "\u003d" (i.e. "\\u003d" in js) does not match that string above, but "u003d" does.
This is all very weird, and my current guess is that browserless is responsible for some weird formatting behind the scenes. Namely, when I console log the URL and copy paste it somewhere else, every method mentioned above works for decoding.
I hope that someone can help me on this.
Just to mark this one as answered. Thomas replied:
JSON.parse(`"${url}"`)
Trying to read CSV formatted data into javascript using the jquery-csv library, but am getting a CSVDataError: Illegal Data error from the ^M character at the end of each line.
It seems no matter how a CSV is saved, I get this ^M. I can only ever see the ^M if I open the CSV file in vim, even in a text editor or my IDE the data looks fine. I don't get this problem when working in other languages either such as Python or R.
I am working on a Mac environment.
How can I fix this and avoid this problem in the future?
Use dos2unix to convert.
It's false that "no matter how it is saved" the CR (^M is a carriage return) is appended. For instance, echo 'a,b,c' > letters.csv does not append a CR. Check your text editor settings.
Take a look at the splitlines algorithm on the jquery-csv page, it seems to provide a function that will clean these problematic carriage returns for you.
Assuming ^M indicates a mac-style carriage return, support for carriage return was included in a previous release so your code should just work.
Source: I'm the author of jquery-csv
I have a scenario where I want hubot to parse something. The command would be hubot parse this thing <the content>
The problem is, the content will generally be a long piece of text pasted in and it usually contains newline characters (line breaks). Here's my regex:
/parse this thing (.*\s*)/i
I'm able to get a response just fine, but only the first line of the content is being read in. Is there any way to get him to read the entirety of the pasted content, including all lines?
EDIT:
Adding a + makes it read the entire pasted content, but only saves the last line:
/parse this thing (.*\s*)+/i
Figured it out! For future reference (I'm bad at regular expressions):
/parse this thing ((.*\s*)+)/i
This would also work:
/parse this thing ((.|\s)+)/i
One or more of any character or whitespace
As outlined in How to use JavaScript regex over multiple lines? it seems to be a better solution to use
/parse this thing ([\s\S]+)/i
I am using some JavaScript code in SSRS to open a link in a new window on a report. The report links point to file locations on a server. The code I am using within Reporting Services for the link is:
="javascript:void(window.open('"+ "file:" & Replace(Fields!FilePath.Value,"\","/") + "','_blank'))"
This code works just fine when the file name is something 'normal' such as:
\\myserver\images\Files\1969\1-000-002_SE 82ND AVE 1_1969.pdf
However, when there are special characters (at least # for sure), I get an error message. This is what happens. An example file name would be:
\\myserver\images\Files\1978\1-001-003_SE 82nd AVE #12 1_1978.pdf
In this case what gets returned as the URL is:
\\myserver\images\Files\1978\1-001-003_SE 82nd AVE
As can be seen, the URL is cut off at the first instance of the number sign. If I copy the shortcut for the offending link, this is what I get:
javascript:void(window.open('file://myserver/images/Files/1978/1-001-003_SE%2082nd%AVE%20#12%201_1978.pdf','_blank'))
It appears that the JavaScript is encoding the file path correctly but something is getting lost in translation between the JavaScript code and the URL.
I am unable to change the file names so I need to come up with a way to work with the special characters. I have tried using EncodeURI() but could not figure out how to format it correctly in SSRS to work with the existing JavaScript.
Any ideas would be welcomed.
URLs will recognize the HTML character numbers. So, outside of your JavaScript, use an SSRS replace function for each special character you expect to find, replacing each with its corresponding HTML number code. For instance, a pound sign is %23; and a space is %20.
Note, I have some pages that use pound signs to split out URL parameters, and this does NOT seem to work in those cases. However, it might work in your situation. To try this, change your function to the following:
="javascript:void(window.open('"+ "file:" & Replace(Replace(Fields!FilePath.Value,"\","/"),"#","%23") + "','_blank'))"
In case this does work for you, you can find more of these codes here.
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.