If I visit http://†.com in Chrome or Internet Explorer, it will bring me to http://xn--lvg.com.
I know it doesn't work in Opera, Safari, and Firefox.
Why does † gets translated to xn--lvg? What's the relation between them? Is there a list that maps these weird characters to their translated equivalents in Chrome or Internet Explorer?
It is the punycode representation.
Here is the relevant RFC.
Related
I have this fiddle,
but can't make ti work in safari. In every other browser it works without flaws. I have read that safari supports data URI, so , I am missing something? Or is a bug?
I am using a simple
<img src="...">
Often, data in this manner cannot have line breaks, and it appears that your fiddle has them. I would recommend trying this without any line breaks, white-space, etc. I'm not sure why that would differ in Safari, but who knows.
In Orbeon 4.5 I found following bug: when loading form in FormRunner and trying to assign value to input field from URL which contains polish characters, f.e 'Paweł', which is in UTF-8 'Pawe%C5%82', instead of actual characters there are '?'. For example:
http://localhost:8081/orbeon/fr/SZPROT/MyTestingForm/new?firstname=Pawe%C5%82
This problem only occurs while using Internet Explorer. On Chrome etc. everything works fine. Is this a well-known problem? Maybe upgrading Orbeon to newer version could help?
I have a site that lists customer letters, and when a letter's "view" button is clicked it uses JavaScript (window.open(url)) to open a new window to get the .pdf file, which I think is generated by crystal reports.
In IE8 on Windows XP it works
On Windows 7 it opens a blank page with the correct url, but it doesn't try and open the file
In any other browser on either OS it works
The machine has the latest Adobe Reader installed
In Win7/IE8 once the blank page is opened, if you then click on the url and hit enter, it will request the file again and correctly open it. I've looked at the requests with fiddler and they're exactly the same.
I'm setting the mime type to "application/pdf" and inline to true in the content-disposition header.
I can kludge it by returning a view that just sets window.location = url, but it feels awful.
Is this a known issue? Is there any way to make it work in both IE versions?
Still no idea why there's the disparity between the two versions, but instead of JavaScript I'm now using target="_blank" on the element and that's done the trick.
Currently I am working on a i18n project where users can switch languages.
Character encoding is utf-8
The problem happens only in IE8 when:
currently user is in a https page.
Going to a http page after any action - like clicking a static page link
Now clicking back button from the current (http) page
Weird characters showing up instead of original czech characters.
Working perfectly in all other browsers like chrome, firefox etc.
Anyone has faced this kind of issue ? Please help.
Have you verified that the character encoding in the page where you are seeing this problem is defined correctly?
How this should be done is described on this W3C page.
Abandon Internet Explorer 8 support?
I have a website that displays fine with IE and Firefox.
But the menus are replaced by question marks when using Safari (I have been told, not having Safari on my PC).
Here is the home page (get rid of spaces):
www.v u b r i d g e.com
Any help welcome.
BTW, is there any Safari emulation for Windows based PC?
I don't see any question mark on your web page, even on the French version. If there is a problem, it's an encoding problem. Check that all your files are encoded in iso-8859-1 (the text encoding you declared in the meta html tag on your web page). If they are, then it could be your server that say the client the content is encoded in utf-8 or any other text encoding. In order to fix it, just configure the header content-type and charset to the correct value. (I've seen your website is made out of aspx which I don't know, but in php it would be header("Content-type: text/html; charset=iso-8859-1;");, to be placed before any output)