I'm developing site in ASP.NET MVC6 with Polish letters. They work just fine when I write them in _Layout.cshtml, but I'm also using RenderBody() for rendering views.
Using Html.DisplayFor(modelItem => item.ID) inside view, displays Polish characters properly, but when I use plain html and write something, all I see on the website is "?" in place of every used Polish letter.
In _layout.cshtml I have a declaration:
<meta charset="utf-8" />
And in web.config I have:
<?xml version="1.0" encoding="utf-8"?>
I have the same problem with asp.net core aka MVC6, visual studio 2017. Especial characters like â appear � and client side validation like ViewBag.Equals("â") is not working properly.
So I change the view files (.cshtml ) codification with notepad++ from ANSI to UTF-8.
I checked my global solution settings for UTF-8, but I didn't checked single file encoding setting, so in solution explorer you have to click your .cshtml file, then:
file->advanced safe options->Unicode(UTF-8 with signature)-Codepage 65001
Now it works.
Related
I have a problem with some German's special letters (ö, ü...) in my Laravel application.
My encoding is set to UTF-8.
Everything works fine with the content from the database (where is utf8_general_ci). When I hardcode some text to Blade view files, that's fine, too. But, I'm using localization files (/app/lang/de/myFile.php) with an associative array.
German characters from that array are displayed as � � �. What is strange, when I var_dump(trans('myFile.key')) in Blade, special characters works, but when echo trans('myFile.key'), there are that question marks.
Any ideas?
Ok, after few hours :) I succeed! The point is to save localization file in UTF-8 encoding. Sublime Text by default saved it as Windows-1250.
I have had a similar problem with one of my projects; not sure if it is related though. Different web browsers handle locale and translations differently. Once in Firefox £ did not work properly unless you changed the browser's locale to UK. However, &163; worked universally. Opera seemed to work across the board but IE and Firefox had strange behavior when trying to use characters or symbols not native to the locale the browser was in.
First thing I would attempt is to change your browser's language and see if that fixes it. If so then the issue will be on how the browser is interpreting what gets returned. If this fixes it then there is a strong chance this will not be an issue for German speakers because their browser will (should) already support the language.
If not, then the problem could lay in the formatting of the files on the server. If the files are being stored on the webserver as ANSI then that could supersede the output. We had this problem as well due to an NFS mount and some windows users/editors. The most failsafe method I could suggest is changing ö and ü to &246; and &252; but I can understand where this would get tedious.
I am using translation files for translating my xpages application to turkish language.
I have set the application encoding to UTF-8 (xsp.html.page.encoding=utf-8)
Most of my languages is working fine but there is problem with Turkish and Polish
The problem I have is that the labels from the translation file do not display the correct encoding even though I have it set up correctly.
All content that is created on my site display correctly in turkish but not the labels from the translation files.
I have tried setting lang=tr, lang=tr-TR, added UTF-8 meta tags, and changed the property file encoding to UTF-8 but still it is not working,
Here is an example
This is Correct turkish entered into the translation file
FACEBOOK KİŞİLİĞİNİZ İLE GİRİŞ YAPIN
This is a sample what the browser outputs
FACEBOOK KÝÞÝLÝÐÝNÝZ ÝLE GÝRÝÞ YAPIN
This is my header settings
<html lang="tr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
You can also see a live example of this problem at http://www.intrapages.com
at the bottom of the login screen there is change language link, set it to turkish
This is a unicode issue. Designer does not convert those characters to unicode.
You can export '.properties' file, use native2ascii command line utility to convert it to unicode values (\uXXXX format).
Another easy option is using an online native2ascii converter. There are a couple of those I know (e.g. this and this)
We're working with a Classic ASP project in VS 2012. We imported the files from an old repository to a new project.
The issue is that we need to save the file as UTF-8. Some of them already are encoded in UTF-8, but others are encoded in Windows-1252. So googling a bit, we found out about the "Advanced Save Options" menu. We can change the file to UTF-8, but when we make changes to the file and save it (deleting one char, for example), VS then switches automatically to the previous enconding (Windows-1252, or ISO-8859-1, codepage 28591).
Is there a way to make VS to always save the files in UTF-8? Or are we mistaken from the beginning and should take another approach?
PS: We have already set the option "Save as Unicode when data cannot be saved as codepage"
PS2: This happens too in VS 2013 preview
Many thanks in advance
Ok, I found the solution:
I started to paste code from an old file in UTF-8 to an empty one, which was in Windows-1252 and then I changed to UTF-8.
When I pasted the part of the head, there was a
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
and VS then switched to ISO-8859-1, codepage 28591. It seems that VS 2012 / 2013 recognizes the meta tag and what charset you have chosen, and changes the file's encoding, which I find to be logical, but it could be useful to tell the user why you're switching encodings :)
I need to display an alert box in other than English language for which I am making use of bean message using Application Resource properties file. The code written in JSP works perfect in Firefox but in IE the characters are messed up and I get all box signs inside alert box.The same problem occurs for ToolTips as well. Any solutions?
Check your page encodings
FF uses UTF-8 page Encoding. View--> Character Encodings
Earlier versions of IE set character encoding according to the language on the client when the document did not specify encoding
Which IE Version are you using ?
This may help also. IE uses the wrong character set when it renders an HTML page
Is charset is utf in headers ?
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
I did found a solution for my query. Actually the issues were with the tool tips and alert boxes were getting displayed in box sign characters only in Internet Explorer and that too in Windows Xp but working properly in windows 7 and other browsers.
What i did was:
1. Right Click On Desktop
2. Properties
3. Appearence Tab
4. Click On Advanced Button
5. In the Item Combo box Select MessageBox(the font combo box should get enabled by then)
6. Select Arial MS Unicode Font instead of Tahoma(Windows XP Default) Font.
And then Check. The desired output will be seen. This is a work around solution but it seems to work fine. Thanks WouterH and Hardik for your guidance till here.
Here is the doctype I am using:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
This will happen if you have content (an HTML comment perhaps) before the DOCTYPE. White-space should be OK in IE8 - although I think even this caused problems with IE6.
(In IE6 an XML declaration before the DOCTYPE would trigger quirks mode - this was fixed in IE7, but it would seem that other content before the DOCTYPE still triggers this.)
not being funny, and I'm sure you've already checked this, but...
Have you tried pressing F12 to step into the IE Developer Console. Is there achance maybe that the "Document Mode" or "Browser Mode" is set to "Quirks Mode"
Forgive me if this isn't the case... I've simply fallen foul of this stupidity before...
It sounds like you're dealing with an Intranet page, which IE8 and IE9 treat differently. If your page is considered to be in the Intranet Zone, IE8 will default to a compatibility mode that might be borking your page up a bit.
You may be able to get around this by using the X-UA-Compatible meta element, but I haven't tested this myself.
This page is high in Google rankings for 'why page triggers ie8 quirks mode', so I will post my 2 findings (through painfull troubleshooting experience):
1) Page will triger quirks mode if you use php in general, but say on that particular page you do not have any php code in the before <html> section at all, but for compatibility you wish to write empty <?php ?> tags at the opening. Now, say, you wish to 'minimize' that code and remove all the empty spaces in between, so you write:
<?php?>
This will trigger IE8 Quirks Mode, because before <!DOCTYPE html> now you will have an extra line with something like this in IE8:
<!-- -->
and in Chrome 34.x:
<!--?php?-->
common, but deadly mistake. Just put
<?php ?>
(with space) to be safe.
2) Second reason was indeed very hard to discover. If you use UTF-8 for your documents and edit them with Notepad++, you will most probably set your character encoding as pure UTF-8 (Notepad++ > Encoding > Encode in UTF-8), and by chance you may trigger IE8 Quirks Mode!
Now, the solution is very simple: using Notepad++ just select Encoding > Convert using UTF-8 without BOM.
Quirks Mode is again gone!
Took me a while to catch all these, trying hard to find bugs in CSS, that were not CSS-related at all!