On my local server, a certain page content displays this character : “ (quotation mark). But exactly the same page on my online server displays : ? (question mark). How can I fix that ?
Make sure that either the server is sending the encoding or you have a meta tag in the <head> section as described here: http://www.w3.org/TR/html4/charset.html (or both).
Related
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.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed last year.
The community reviewed whether to reopen this question last year and left it closed:
Original close reason(s) were not resolved
Improve this question
When I copy a UTF-8 URL from the browser's address bar (almost any browser on any os), then try to paste it in another text field (to post it on facebook or twitter for example), it gives only the decoded URL, which makes it ugly. For example, in the address bar, the URL appears like this one:
https://www.chaino.com/وذكر
But when trying to copy and paste it in any other place, it gives the following ugly url:
https://www.chaino.com/%D9%88%D8%B0%D9%83%D8%B1
& if I wanted to get the original URL to use it in any place, I used to decode it in this Raw URL Decoder - Online Tool
Question is: is there a short direct way to copy these kind of URLs, and paste it without this hideous process? (may be using chrome extensions or something)
You can add a 'space' at the end of the URL in the address bar, then you can select it all and copy it directly.
You can select URL without selecting scheme (e.g. http://), and copy it. This will give you what you expected.
P.S. The point is to select only part of the link. E.g. you can select whole URL without first character and than add it manually.
In Firefox 53+ you can set browser.urlbar.decodeURLsOnCopy about:config option to true.
The URI you get by copying from the address bar is the only valid URI the browser can give you.
From the RFC 3986 (and other URL RFCs):
A URI is a sequence of characters from a very limited set: the
letters of the basic Latin alphabet, digits, and a few special
characters.
So: https://www.chaino.com/وذكر
Is an invalid URI, yet a valid IRI (International Resource Identifier), that your browser will convert to a valid URI while requesting the server over HTTP (HTTP does not allow IRI, only URI).
TL;DR: Your browser is giving you what you expect: A valid URI that you can use everywhere, not an IRI only supported here and here.
PS If "facebook or twitter for example" are kind, they may display a readable form to their users, so don't worry about giving an encoded form.
You can use Chrome Extensions like below:
https://chrome.google.com/webstore/detail/copy-unicode-urls/fnbbfiapefhkicjhecnoepbijhanpkjp
https://chrome.google.com/webstore/detail/copy-cyrilic-urls/alnknpnpinldhpkjkgobkalmoaeolhnf
Create a bookmark with this url: javascript:console.log(prompt('copy (Control+C) this link:', decodeURIComponent(window.location))).
Click this bookmark on that page.
Example page: https://www.google.com.hk/search?q=中文
The best answer I found tell now is using this Chrome extension:
https://chrome.google.com/webstore/detail/copy-cyrilic-urls/alnknpnpinldhpkjkgobkalmoaeolhnf?hl=en-US
which enables me to copy the url (in a decoded state) with only one click :)
You can use Chrome and FireFox extension called "Copy Unicode URLs", which I created.
It is:
Open source.
Gives you an option to leave URL terminators encoded so, e.g., links that end with a dot will have that dot encoded and email clients won't wrongly recognize this dot as a sentence/URL terminator.
If you love my work then, please, donate some sum here.
Copy addres without 'h' in http...
And past addres without 'h' and sum first addres with 'h'
I have a site that is replicated in many languages. The site itself display characters correctly but when viewing source the meta tags show the "unknown character" question mark instead of the foreign character.
What do I need to do differently for meta tags?
I have this tag already:
<meta http-equiv="content-type" content="application/xhtml+xml; charset=utf-8" />
I changed the charset to iso-8859-1 and it works now.
Then it means that you have saved the file as ISO-8859-1 (or possibly as CP-1252 when on windows) instead of UTF-8. In a bit decent text editor / IDE you should be able to configure the default file encoding and/or use the Save As option to set the desired encoding. Also, don't forget to set the HTTP response headers accordingly. How to do this depends on the webserver used and/or the server side language in question (if any).
By the way, you really don't want to use ISO-8859-1 when you want to go for World Domination. It doesn't cover all characters the world is aware of. It only covers Latin, not Hebrew, Cyrillic, Arabic, Chinese/Korean/Japanese, etc..etc..
First of all, I'm not a web designer, I'm a programmer, so I'm working a bit out of my knowledge area. However, as the person in my office who has some working knowledge of French, I'm stuck with this issue.
The Problem:
Sharepoint Designer is replacing all French accented characters with the � (square box or diamond-? �) character.
It doesn't appear to matter if I enter the 'é' character as alt-130 (in either design or source or as é
Everything works fine when editing, but when the file is saved and loaded into a browser, it replaces the characters. When reloading into designer, the file shows the 65533 symbol.
EDIT: More info.
I use é and save, close SP designer,
Reloading SP designer will show the é (instead of the code) in source.
Next reload will have replaced it with �
Question 1: (more important) HOW DO I STOP THIS!?
Question 2: (more interesting) Why does this happen?
Charset is iso-8859-1
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
fixed it and stopped sharepoint from modifying the source.
Try this charset :
windows-1252
For me - the solution was to change the system locale: http://windows.microsoft.com/en-us/windows/change-system-locale#1TC=windows-7
EDIT:
Now I see that the link does not work anymore,
So briefly - the solution is to change the system locale.
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&y=2
Normally the & 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. & gets converted to & 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.