Take a look at this:
http://thebekker.dk/_skole/GFeksamen/
You can see the 2nd menu item show some weird sign, instead of "Ø"
Ive set utf-8 in meta, and even tryed with AddDefaultCharset UTF-8 in .htaccess...
Still no result, if i change to ISO-8859-1 which works fine, but that makes problem when i start making ajax calls for content...
I dont get it?
How do i get it to use UTF-8 and show ÆØÅ
If you declare that your content is encoded in UTF-8 with the meta tags or default charset, then your content needs to be actually encoded in UTF-8. The fact that it shows correctly when declaring your content to be encoded in ISO-8859 means that your content is actually encoded in ISO-8859. Save your source code file as UTF-8 or otherwise make sure that your content is UTF-8 encoded.
Saving the source file in "Western European (Windows)" in EditPlus text editor did it for me + in PHP I used utf8_encode.
you can set this characters with unicode like € or so many others. In my company we work with many translations and languages like france, that has many special chars.
set your website encoding type to utf-8 and use encodings like utf8_encode in php
or manually: http://www.sql-und-xml.de/unicode-database/online-tools/
Related
I try to print pdf file from QTextDocument. Content of document is set by setHtml().
Simplified example:
QTextDocument document;
document.setHtml("<h1>My html \304\205</h1>"); // Octal encoded ą
QPrinter printer(QPrinter::HighResolution);
printer.setPageSize(QPrinter::A4);
printer.setOutputFormat(QPrinter::PdfFormat);
printer.setOutputFileName("cert.pdf");
document.print(&printer);
It does not work as expected on windows (msvc). I get pdf file with "?" in place of most polish characters. It works on ubuntu.
On windows It makes pdf with tahoma font embedded subset. How to force QPrinter or QPrintEngine to embed more characters from this (or any other) font?
As pepe suggested in comments. I needed to wrap this string one of:
QString::fromUtf8
tr() (in case of joining translated parts)
Use html escape sequence (ex. ą for ę)
My original html in program was build from tr() parts, but I forgot to octal escape some of them. (which worked on gcc, not on msvc, even with utf-8 with BOM)
I am trying to build a website using Laravel. I wanted to add Arabic language so I created a folder for it and made it the default in the config.php file.
Every time I use (trans) or (Lang::get) to load line from the Arabic file, not only the is not loaded right, but also the whole array is loaded with random letters instead of the Arabic text.
I tried changing the encoding of the file to UTF-8 or Unicode (both the Arabic file and the view) and I got really weird results (Japanes/Chinese letters sometimes).
is there something I am missing?
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
UTF-8 issue in Firefox - response header overriding meta tag?
I have a jPlayer playlist that works fine in all browsers except Firefox.
The issue is with non-standard characters, i.e. characters with accents or asian characters. I have set up a demo playlist so that you can see here.
When I enter the characters in UTF-8 form (track 1 in the playlist) they work on all browsers except for Firefox, and when I enter them in ISO Latin 1 (track 2 in the playlist) they work in Firefox but no other browsers.
So, for instance in Firefox 大å°æ¸æ¿.mp3 works, whereas 大地書房.mp3 doesn't.
When I use 大地書房.mp3 in the Firebug console I see the following error:
"NetworkError: 404 Not Found - http://monthlymixup.com/mixups/july_2012/media/simon/03%20????.mp3"
So, for some reason 大地書房.mp3 becomes %20????. When I inspect the page the link to the audio file shows as 大地書房.mp3 though.
There is a meta tag for UTF-8 on the demo page, i.e. <meta charset=utf-8 />
My understanding is that Firefox overwrites this with the response header if a default encoding isn't set in FF. I have however set UTF-8 to be the default encoder and I have checked that the page is using UTF-8 by going to Tools/Page Info (I am on a Mac and I believe this is the way to check the encoding on the page).
So, I'm at a loss as to what is going on, and would be glad of some help.
This seems to be an encoding issue in jQuery or other software used. The entry 2 is in an odd format: looking at the source as UTF-8, I see
mp3:"media/nick/Guessi-Guéré-Guessi (Pop Bariba).mp3"
This means that the letter “é” has been represented in UTF-8, as two octets, and then these octets have been interpreted as if they were ISO-8859-1 encoded, and the resulting characters have been UTF-8 encoded. Presumably the software deals with the mess by performing the opposite double decoding. In any case, it does not work with
mp3:"media/simon/03 大地書房.mp3"
which is just UTF-8 encoded.
It puzzles me how it works on any browser, but presumably the code is browser-dependent.
The software should be changed to deal with UTF-8 as such and pass it forward, if possible. All modern browsers, including Firefox, can then deal with it properly.
As a quick fix, though, you might try to use a percent-encoded form (see e.g. online percent-encoder):
mp3: "media/simon/03%20%E5%A4%A7%E5%9C%B0%E6%9B%B8%E6%88%BF.mp3"
But this is just a guess; the software might munge this, percent-encoding the “%” sign.
I'm writing a function to convert MS Word-styled text into Adobe InDesign-formatted text (it uses a kind of XML to indicate styling). The text is pasted into a TinyMCE rich text editor, which then sends the HTML-formatted code to a php function.
I've tried this function to clean up the code once it reaches my conversion code:
$text = iconv("windows-1250", "UTF-8", $html);
When I use any 'special' kind of characters, things go wrong. £ signs, é (or any other accents), and a variety of 'curly' apostrophes/quote marks seem to break things. For example, if I try to convert a £ sign, the code returns \u0141, but I get the Ł symbol displayed onscreen when the function returns.
Does anybody know what I can do to prevent Word's weird characters breaking everything I'm doing?
I seem to have fixed this. I was using escape() to pass the values, but replaced this with encodeURIComponent() instead (and removed the iconv() call in my php code), which seems to have fixed it.
In the process of editing a file encoded as UTF-8 w/o [spurious] BOM the content might become devoid of any Unicode characters outside the ASCII or ANSI ranges. At the next reopening of the file, some text editors (Notepad++) will interpret it as ASCII/ANSI encoded and open it as such. Unaware of the change the user will continue editing, now adding non-ANSI Unicode characters, rendered however useless, since saved in ANSI. A menu option can exist (Notepad++) to open ANSI files as UTF-8 w/o BOM, but leading to the reverse issue of inadvertently overriding ANSI files with Unicode encoding.
One workaround is to add a character outside the ANSI range to a comment in the file. Depending on the decoding algorithm, it might force the editor (Notepad++) to recognize the file as encoded in UTF-8 w/o BOM.
In a HTML document for example you could follow the charset definition in the header with such a Unicode comment, here the U+05D0 HEBREW LETTER ALEF:
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <!-- א -->
How would you suggest that an editor tell the difference between ASCII/ANSI and UTF-8 w/o BOM, when the files look the same?
If you want guaranteed recognition of UTF-8 as UTF-8, either add the BOM, or force the file to contain UTF-8 characters.
Configure your editor to always use UTF-8 if possible, if not, complain to the creators of your editor. Charsets not targeting unicode are, IMO, deprecated and should be treated as such.
Files using only characters in the ASCII space (the 7-bit one) would be pretty much the same in UTF-8 anyway, so if you HAVE to deliver something in ASCII encoding, just don't type any unicode characters.