IE is messing with my GET parameters - url

One of my GET parameters was named &ordf, and today when I was expecting to test the rendering of a page in IE9 vs Chrome, I found instead that IE9 wouldn't even load the right data because it was converting &ordf to "ª"(no quotes) which is &ordf HTML special character.
Is there anything I can do to prevent IE from doing this? Chrome and Firefox don't have any problems with the URL and display it fine. The only fix I could think of was changing it from &ordf to something else, but I was hoping there was something easier or quicker.

You probably need to escape the & in the url in the HTML file as &

Related

How to pass special parameters from the CLI to the browser URL bar

I have a problem passing special parameters from a bash script to a browser URL bar.
I would like to open a PDF file on a certain page, and with a certain zoom factor, and at a certain position (relative to a page corner, I think that's called "focus") in Brave, from the command line.
I thought that should work like this:
$ brave-browser file:/home/user/foo.pdf#page=5&zoom=150,50,50
(the ",50,50" would be the "focus") but it doesn't. It just provokes an error message.
Copy/pasting the entire line with all the special characters manually to the URL bar works fine, but I would like to do that without the mouse or keyboard, from the CL. In other words, copying the string
file:/home/user/foo.pdf#page=5&zoom=150,50,50
and pasting that straight into the URL bar will open the file the way I want in Brave.
This shortened command works from the CL:
$ brave-browser file:/home/user/foo.pdf#page=5
but adding the &zoom=150,50,50 provokes an error message from Brave.
I just can't get my head around how to format the rest of the line so that the file opens in the browser as intended (zoomed and focussed), when called from the CL.
I begin to wonder if that is possible at all.
I have tried everything that was suggested here:
Shell script to open a URL
and a couple of other ideas I had (mainly, creative use of quotation marks)
I also read this, but I am not sure if it refers to the same question - and the post is 11 years old. Was hoping that things changed:
Can a website pass focus to the browsers url field?
Thanks a lot for any help!
Just found out that all it takes is a backslash in front of the ampersand...
Strange: no matter how I do write that here, with the *** before and after the code, or without the three *** , I can never see the backslash in the post's preview!
browser file:/home/user/foo.pdf#page=5 \ &zoom=150,50,50
I have to type blanks before and after the hash to make it visible in this post as above. Looks wrong but this is the only way I can show what I mean. Also strange: the hash # works without the backslash \
Thanks, should someone have looked into this in the meantime!

encode quotes for xss prevention are not displayed in HTML

I am scripting an element as <span>"carbon</span> in HTML(encoded the quotes) . However, when i inspect the HTMl in chrome/FF, it looks like <span>"carbon</span> (even tried by edit as HTMl option too). How can i prove that the double quotes " are encoded. Please guide me.
Thank you
Quotes in that location don't need to be escaped, they have no ambiguous meaning there.
Use the "View Source" feature to look at the raw source code; the Element Inspector gives you a view of the live DOM, which may be completely different than the raw source code you initially sent to the browser.

Parameters in plain html in jsf 2 application

I am making an JSF 2 application. Sometimes I want to do simple things that are easy to do using plain HTML but I get error messages that I don't understand.
For example I sometimes want to write:
Test
But this makes the page break because of "?test1=ee&test2=oo". Having only one parameter seems to be fine but if I try to add more parameters using "&" it complains and says I need to use a ';'-delimiter.
Any explanations why this happens and maybe how to get around it?

getJSON dosen't work on IE during typing special characters

I am using $.getJSON to autocomplete control and everything is fine for chrome browser.
On IE, only plain text (without special characters like 'ż','ł' etc.) work fine.
Probbably it is cause by encoding but I don't know in which place I should do something. I tried to do this on controller which return JSON object, in javascript ($.ajaxSetup), on Layout (meta charset in head section) but result was the same.
Where I done mistake ?
Wesley Skeen - thanks for advice.
I used encodeURI on Url pass to getJSON:
I paste solution, maybe it will be helpful for someone.
$.getJSON(encodeURI("#Url.Action("Action", "Controller")?parameter="+valueOfParameter),function(data){ .... });

Encoding of XHTML and & (ampersand)

My website is XHTML Transitional compliant except for one thing: the & (ampersand) in the URL are written as it is, instead of &
That is, all the URLs in my pages are usually like this:
Foo
But XHTML validator generates this error:
cannot generate system identifier for general entity "y"
... and it wants the URL to be written like this:
Foo
The problem is that Internet Explorer and Firefox don't handle the URL correctly and ignore the y parameter. How can I make this link work and validate correctly?
It seems to me that it is impossible to write XHTML pages if the browsers don't work with strict encoded XHTML URLs.
Do you want to see in action? See the difference between these two links (copy and paste them as they are):
http://stackoverflow.com/search?q=ff&sort=newest
and
http://stackoverflow.com/search?q=ff&sort=newest
I have just tried this. What you attempted to do is correct. In HTML if you are writing a link the & characters should be encoded as & You would only encode the & as %26 if you wanted a parameter value to contain an ampersand. I just wrote a simple HTML page that contained a link: Click me
and it worked fine: default2.aspx received the parameters intended and the source passed validation.
The encoding of & as & is required in HTML, not in the link. When the browser sees the & in the HTML source for a link it will interpret it as an ampersand and the link target will be as intended. If you paste a URL into your browser address bar it does not expect it to be HTML and does not try to interpret any HTML encoding that it may contain. This is why your example links that you suggest we should copy/paste into a browser don't work and why we wouldn't expect them to work.
If you post a bit more of your actual code we might be able to see what you have done wrong, but you appear to be heading the right direction by using & in your anchor tags.
It was my fault: the hyperlink control already encoded &, so my URL http://foo?x=1&y=2 was encoded to http://foo?x=1&amp;y=2
Normally the &amp inside the URL is correctly handled by browsers, as you stated.
You could use & instead of & in your URL within your page.
That should allow it to be validated as strict XHTML...
Foo
Note, if used by an ASP.NET Request.QueryString function, the query string doesn't use XML encoding; it uses URL encoding:
/mypath/mypage?b=%26stuff
So you need to provide a function translating '&' into %26.
Note: in that case, Server.URLEncode(”neetu & geetu”), which would produce neetu+%26+geetu, is not what you want, since you need to translate & into %26, not just '&'. You must add a replace() call applied to URLEncode result, in order to replace '%26amp;' by '%26'.
To be even more thorough: use &, a numeric character reference.
Because & is a character entity reference:
Character entity references are defined in the markup language
definition. This means, for example, that for HTML only a specific
range of characters (defined by the HTML specification) can be
represented as character entity references (and that includes only a
small subset of the Unicode range).
That's coming from the wise people at W3C (read this for more).
Of course, this is not a very big deal, but the suggestion of W3C is that the numeric one will be valid and useable everywhere and always, while the named one is 'fine' for HTML but nothing more.
The problem is worse than you think - try it in Safari. &amp; gets converted to &#38; and the hash ends the URL.
The correct answer is to not output XHTML - there's no reason that justifies spending more time on development and alienating Mac users.

Resources