I'm having a problem with UTF-8 character on the page title,
I want to add this on the title of the page --> ♫ <--- (the Music symbol)
The thing is, sometimes it works (on Google Chrome) and sometimes it doesn't (when it doesn't work, it appears a square that is supposed to be an error of encoding) weirdly.
And in firefox, it always work when you look to the title in the top of the window (the title that appears up in your page) but the title that appears in the bar below appears the square thing again. :/
What do I do to fix this?
I'm defining the title via Javascript by a js file which I'm using PHP to define it utf-8 as well.
var title = "♫ My Music";
document.title = title;
by the way, it seems to work always on Linux, but on Windows, it does those stuff. =/
Thanks in advance.
This is a font problem rather than an encoding problem; a small rectangle in place of a character typically means that the character is not present in the font(s) used.
Browsers typically use some specific fonts when they render title element contents (somewhere outside the page itself). These fonts may depend on the settings in the operating systems. On Windows 7 for example, the default for them is 9pt Segoe UI, a relatively rich font, whereas older systems have more limited fonts. Anyway, that’s outside an author’s hands.
So the conclusion is that special symbols should be avoided in title elements. Their rendering is not guaranteed, and they probably have no value as far as search engines are considered.
Have you added the meta tag for charset to your HTML?
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
sometimes it works (on Google Chrome) and sometimes it doesn't (when it doesn't work, it appears a square that is supposed to be an error of encoding) weirdly
This is most likely down to the font used by your browser, and your Operating System. If the character is defined in the font, it will show up. If it isn't, it won't.
There isn't much you can do about this, unfortunately - both these things are outside of your control.
Somewhat related: Unicode support in Web standard fonts
I resolve this problem (year in Spanish) with this notation:
title="A & # 241 ; o"
IMPORTANT: I insert blanks spaces between characters for adequate renderization.
Related
I am using the Instagram API and below is an example of two characters I get back from IG that represent a user's name.
💛🌻
In the HTML of my web page they are displaying as question marks, but if you copy and paste them into any text editor they display as a heart and a flower.
How can I get these and other symbols to display correctly in the HTML?
The characters are U+1F49B YELLOW HEART and U+1F33B SUNFLOWER. They are relatively new as coded characters (though somewhat older as emoji symbols implemented using other techniques), and few fonts contain them: Segoe UI Symbol, Segoe UI Emoji, Quivira, Symbola, and maybe some other, very new or specialized fonts. The Segoe UI fonts are available in new versions of Windows, possibly depending on the installation of updates (Microsoft nowadays delivers some fonts and extensions to fonts via Windows update mechanisms). The other two are free fonts that users may download and install, but they are probably not pre-installed in any computer.
Thus, if the user’s system lacks those fonts, the characters do not appear; instead, some indicator of an unrepresentable character is shown.
There is an additional problem. Although browsers are expected to scan through all the installed fonts to find a glyph for a character, they often fail to do this properly, especially for more or less exotic characters. Testing on Win 7 without any font settings in the test document, I observed that these characters are displayed by IE and Firefox, but not by Chrome. This issue can be fixed by specifying a list of fonts explicitly:
.emoji {
font-family: Segoe UI Emoji, Segoe UI Symbol,
Symbola, Quivira;
}
<span class=emoji>💛🌻</span>
To cover user systems that lack these fonts, you would need to use a downloadable font via #font-face, in practice using Symbola or Quivira. They are rather large fonts, so using images may be a more viable option—especially because then you can use color images. (In principle, you can use Variation Selector control characters to ask rendering software to use emoji-style color glyphs for the characters, but the fonts don’t seem to contain such glyphs, and besides browsers might be unable to use them, i.e. might lack support to Variation Selectors.)
Since you cant get them to show correctly since its browser specific, you can download the Chrome plugin, Emoji Plugin
Edit: Another solution would be to get the unicode of the emoji that comes in, and then display an image instead. This would require you do download the emojis as images.
Sadly, there's nothing you can do. You have to wait for all browsers to adopt these HTML5 entities.
IE 11 is currently the only browser that displays all HTML5 entities. I viewed this page in IE 11 and they show up. In Chrome, for example, they don't show.
I'm working on a music related website, and frequently use the HTML special characters for sharps (♯) and flats(♭) to keep things pretty, e.g.:
♯
♭
However, I've noticed that in some browsers (IE6, Safari for PC) those characters aren't supported. I've created a conditional javascript that serves up plain, supported characters in place of the special ones ( G# for G♯ and Bb for B♭ ). But I'm having a hard time figuring out how to detect which browsers lack those characters.
I know I could test for the browser (e.g. ie6), but I was hoping to do things right and test for character support itself.
Does anyone know of a good way to do this using either javascript, jQuery, or rails? (The page is served by a rails app, so the request object and any other Rails magic is on the the table.
If you create two SPANs, one containing the character you want, and the other containing an unprintable character U+FFFD (�) is a good one, then you can test whether they have the same width.
<div style="visibility:hidden">
<span id="char-to-check">♯</span>
<span id="not-renderable">�</span>
</div>
<script>
alert(document.getElementById('char-to-check').offsetWidth ===
document.getElementById('not-renderable').offsetWidth
? 'not supported' : 'supported');
</script>
You should make sure that the DIV is not styled using a fixed font.
"Browser support" is not the problem here. You should be serving your files as UTF-8*, and use the appropriate characters rather than the HTML entities.
Unicode sharp symbol: ♯ (U+266F)
Unicode flat symbol: ♭ (U+266D)
You should also make sure to save your files in UTF-8 (and not, say, ASCII or ISO-8859-1).
See also: the must-be-mentioned Joel on Software: The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!).
*I'm not a Rails guy, but I think it does this by default.
Rather than mucking around with JavaScript, what you should be doing instead is using css's unicode-range:
#font-face {
font-family: 'MyWebFont'; /* Define the custom font name */
src: local("Segoe UI Symbol"),
local("Symbola"),
url('myfont.woff2') format('woff2'),
url('myfont.woff') format('woff'); /* Define where the font can be downloaded */
unicode-range: U+266F, U+266D; /* Define the available characters */
}
body {
font-family: 'MyWebFont', Arial;
}
♯
♭
Normal text
In the local blocks, define fonts that people might have installed locally and contain the symbols you want (like Window's Segoe UI Symbol). Then define a web font (I suggest Symbola) containing the symbol you want to show.
The unicode-range directive tells supporting browsers (IE9 and up) not to download the font unless the specified symbols are present on the page (You can find their unicode number by searching Unicode-Tables.)
If they have the font already, they won't download it. If the symbol(s) aren't present on the page and your browser isn't older than dirt, the font won't be downloaded. It'll only be downloaded when it is needed.
(If you still want to support old IE, use fontsquirrel to generate your initial #font-face statement, then add the local and unicode-range parts yourself.
Add this to your HTML
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
</head>
And check to see if IE and Safari render the page right.
I've been trying to embed some hebrew characters in Thom Sander's free html5 template (download link).
For example, I've tried to change a left-side menu item text to Hebrew, i.e.,
Home Page => עמוד הבית
For some reason the hebrew characters are not shown at all.
When I add hebrew in other places in the document, it is shown correctly. At first I thought this may be an encoding issue but the head encoding seems to be valid: UTF-8. I think there might be some JS code ignoring the Hebrew text, but I'm not sure.
Any ideas?
Seems like someone already found a solution for that. I didn't try to implement the whole solution but tested it with your files and it works.
You can find the solution here
Basicaly you just need to use CufonRTL.js to be able to use Hebrew & Cufon.js together.
You may find CufonRTL.js at the begining of the blog post or just download the file from here
Then you ll have to load CufonRTL.js and execute something like:
CufonRTL.RTL('#menu a');
So the menu links would support Hebrew while using the Cufon library & custom font.
The reason you cannot embed Hebrew characters into your website is beacuse the template is using the cufon technique, which doesn't support right to left languages.
Planned features:
Support for right-to-left and bi-directional text
However, it looks like there is a way around it:
Using Cufon with Right-To-Left Text
Try adding this rule to the CSS
html { unicode-bidi: embed; }
http://www.w3schools.com/jsref/prop_style_unicodebidi.asp
The unicodeBidi property is used with the direction property to set or
return whether the text should be overridden to support multiple
languages in the same document.
Be sure to use:
<meta http-equiv='Content-Type' content='Type=text/html; charset=utf-8'>
Or (as a new HTML5 standard):
<meta charset='utf-8'>
And try adding this property in your CSS:
unicode-bidi: embed;
You can also try to display something, using HTML Entities instead of Unicode characters: ֑ ֒ #1427;
I'm working on a music related website, and frequently use the HTML special characters for sharps (♯) and flats(♭) to keep things pretty, e.g.:
♯
♭
However, I've noticed that in some browsers (IE6, Safari for PC) those characters aren't supported. I've created a conditional javascript that serves up plain, supported characters in place of the special ones ( G# for G♯ and Bb for B♭ ). But I'm having a hard time figuring out how to detect which browsers lack those characters.
I know I could test for the browser (e.g. ie6), but I was hoping to do things right and test for character support itself.
Does anyone know of a good way to do this using either javascript, jQuery, or rails? (The page is served by a rails app, so the request object and any other Rails magic is on the the table.
If you create two SPANs, one containing the character you want, and the other containing an unprintable character U+FFFD (�) is a good one, then you can test whether they have the same width.
<div style="visibility:hidden">
<span id="char-to-check">♯</span>
<span id="not-renderable">�</span>
</div>
<script>
alert(document.getElementById('char-to-check').offsetWidth ===
document.getElementById('not-renderable').offsetWidth
? 'not supported' : 'supported');
</script>
You should make sure that the DIV is not styled using a fixed font.
"Browser support" is not the problem here. You should be serving your files as UTF-8*, and use the appropriate characters rather than the HTML entities.
Unicode sharp symbol: ♯ (U+266F)
Unicode flat symbol: ♭ (U+266D)
You should also make sure to save your files in UTF-8 (and not, say, ASCII or ISO-8859-1).
See also: the must-be-mentioned Joel on Software: The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!).
*I'm not a Rails guy, but I think it does this by default.
Rather than mucking around with JavaScript, what you should be doing instead is using css's unicode-range:
#font-face {
font-family: 'MyWebFont'; /* Define the custom font name */
src: local("Segoe UI Symbol"),
local("Symbola"),
url('myfont.woff2') format('woff2'),
url('myfont.woff') format('woff'); /* Define where the font can be downloaded */
unicode-range: U+266F, U+266D; /* Define the available characters */
}
body {
font-family: 'MyWebFont', Arial;
}
♯
♭
Normal text
In the local blocks, define fonts that people might have installed locally and contain the symbols you want (like Window's Segoe UI Symbol). Then define a web font (I suggest Symbola) containing the symbol you want to show.
The unicode-range directive tells supporting browsers (IE9 and up) not to download the font unless the specified symbols are present on the page (You can find their unicode number by searching Unicode-Tables.)
If they have the font already, they won't download it. If the symbol(s) aren't present on the page and your browser isn't older than dirt, the font won't be downloaded. It'll only be downloaded when it is needed.
(If you still want to support old IE, use fontsquirrel to generate your initial #font-face statement, then add the local and unicode-range parts yourself.
Add this to your HTML
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
</head>
And check to see if IE and Safari render the page right.
Why is it that when I use Firefox to enter: 漢, the GET will transform to:
q=%E6%BC%A2&start=0
However, when I use IE8 and I type the same chinese character, the GET is:
q=?&start=0
It turns it into a question mark.
Mark the encoding of the page as UTF-8 and this problem will go away. Firefox will fail to autodetect your encoding without this hint sometimes, too. And you may have manually changed the encoding in IE once, so that becomes the new default for unmarked pages.
put this in your <HEAD>:
<META http-equiv="Content-Type" content="text/html; charset=utf-8">
If your content isn't really in UTF-8, then you'll need to use an alternate method. There's an html attribute on FORM that hints to IE that you want non-ANSI codepage characters to be sent as UTF-8, but it's far nicer to just use the correct content type.
Also, the address bar may not be the best place to look at the resulting text, as the last time I checked, it didn't reliably work with non-ACP characters. Make sure you're looking at the actual request data.
If you're talking about entering text into the address bar or search box in the browser, and not a specific web page, I don't reproduce this problem on English Windows 7. Perhaps you're using a very old version of Windows and your system ANSI code page does not contain that character; Win95/Win98/WinME would certainly have that problem.
Edited to add:
In IE 8, entering the character you specified on a page containing this content works exactly as expected for me. I've verified this with Fiddler. Whatever problem you are having is probably different than what you have described so far.
<HTML>
<HEAD>
<META http-equiv="Content-Type" content="text/html; charset=utf-8">
</HEAD>
<BODY>
<form accept-charset="utf-8" method="get" action="http://www.example.com/something">
<input type="text" name="q">
<input type="submit">
</form>
</BODY>
</HTML>
You actually don't need the accept-charset unless you are using an alternate encoding for the page itself. But I am leaving it in for illustrative purposes. For it to be actually useful, at least in earlier versions of IE (things may have changed; a colleague of mine specified the behavior back in IE5 or so), you need a hidden "_charset_" field with no value to encourage the browser to mark what charset it actually used, but that's superfluous in a utf-8 page).
It can either be font installation or URL encoding issue
One of main issue which I have seen when dealing with CJK characters is the installation of East Asian Language fonts not done by default when OS is installed. These characters show up properly in MS Word even without installation being done.
To make sure all applications in OS can deal with CJK (Chinese, Japanese and Korean), doing the below exercise is better
Go To Control Panel
Select Regional And Language Options
Go to language tab
Select checkbox to install fonts for East Asian Languages
Hopefully you have the windows CD with you to proceed with this.
After that IE8 hopefully would show characters properly.
Also in case you are doing any url encoding make sure you always use UTF-8 as the character encoding when dealing with non ASCII characters.
To begin with, IE believes that Chinese characters can be sent 'as is' in UTF-8, while Firefox thinks they need to be URL-encoded.
Have you watched the GET request on the wire? I bet that it's really a three-byte sequence and that the tool you are using to display it is reducing it to a ?.