I'm writing a basic Chrome Extension to add suggestions in the Omnibox from a JSON feed. Nearly all queries entered will display results as expected in the suggestions dropdown.
However, it seems that whenever an ampersand (&) is returned as part of the description, Chrome throws an error.
The error thrown reads "xmlParseEntityRef: no name(...)" and is called from the parseOmniboxDescription method within Chrome.
Any help with this matter would be greatly appreciated. I'm not sure if this is the only character with that problem or if it is more widespread.
The current API for omnibox suggestions requires that they be specified as encoded XML text, not just plain text. Some characters including & will need to be appropriately encoded.
To encode an entire XML string in browser JavaScript, you may do something like this:
function encodeXml(s) {
var holder = document.createElement('div');
holder.textContent = s;
return holder.innerHTML;
}
console.log(encodeXml("Good & Bad > Bad & Good"));
// "Good & Bad > Bad & Good"
If you perform this operation on your text before passing it to the omnibox API, the error should go away.
Per the documentation you can use <url>, <match>, and <dim> to further annotate your result. However, you may want to use a more structured XML-building approach for that, rather than simply concatenating strings. (I don't know if these XML elements have any attributes, but if they do, the approach above may not be adequate for encoding attribute values.)
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}"`)
I have a dll i suspect not to be supporting UTF-8 for emojis. (its an addon for mIRC)
This dll changes mIRC (text based chat program), into a full HTML/Javascript.
My problem is, when i receive a message containing emojis, they output like this
😀
Four "stange" chars, cause they are not converted fine i suppose.
I though about make a Javascript function matching those, and changing it to correct emoji code back (maybe using a <span> or not, since the following code type is translated correctly into smileys 😈)
so, is there any way in javascript to catch/convert 😀 erroneous chars into 😈 for example? (those are not the same emoji)
for a correct example :
:grinning face: U+1F600
output this 😀
sending this 😀 finaly output a square... and not the correct smiley so its even not working for all...
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.
I'm using prototype to make Ajax requests. Occasionally the responses contain malformed XML. Prototype is using the onException callback, but the first error that is thrown is when I am trying to access a particular node.
I know Firefox recognizes the malformed response, because if I request the xml via the address bar, Firefox presents the error.
Is there a way for me to catch a "malformed xml" error in javascript?
With javascript typically you're relying on the browser to parse the XML for you. If the browser can't parse it due to it being malformed, you're going to have to tackle it manually. There appears to be a library for doing that at http://xmljs.sourceforge.net/ . I haven't used it myself, but it appears solid. Then again, it might also throw malformed xml errors at you.
What's causing the malformed xml? Maybe there's something you can do on that end?
And finally, if you're just trying to access some part of the document's data, you could consider using a regular expression:
doc = "<one><two>three</two></one>";
captures = doc.match(/<two>(.*)<\/two>/); // returns ["<two>three</two>", "three"]
data = captures[1]; // "three"