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 :)
Related
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.
I'm building a web page that uses Google WebFonts (open sans) on a PC and it works perfectly, but when I try it on a mac computer it shows a question mark within the text. Why is this?
The character you are seeing is the replacement character, which is used when a font does not contain a particular Unicode character, in this case, "ñ" AKA U+00F1 AKA "Latin small letter n with tilde".
Google Open Sans does contain this character, so it seems that Safari is not correctly getting the font from the web. The rendering engine is then reverting to another font, and that one is missing the offending character. You will be able to check in dev tools on your mac which font is being grabbed by your script.
I checked the script annotation you posted in the comment to your question. You are returning the fonts in the woff2 format. It turns out that woff2 is not supported in Safari as of version 9, but woff is. I therefore recommend changing the format to woff and serving it to your page locally:
Download the script you posted (http://fonts.googleapis.com/css?family=Open+Sans:300,400,500,700)
Save it as a css file (e.g. fonts.css)
Find-and-replace woff2 to woff
Save the file
Add it to your web project (however you add your other files)
Replace #StyleSheet({"fonts.googleapis.com/css?family=Open+Sans:300,400,500,700";}) with a reference to this newly uploaded file.
Solved! One of the developers had its Eclipse not set to UTF-8 so the file transfer using Git wasn't working properly...to check, go to Preferences>General>Workspace>Text file encoding and set to UTF-8
As a test, I paste the following text in a .php file on the server: 颜色分类
I then save, the file.
I close, and re-open the file, and then the text appears as : 颜色分类
I then save the file again, without modifying the content, and re-open it again
The text then appears as: 颜色分类
My headers are: <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
I checked my database is also on utf8_general_ci
However, could this really be those settings? The file is individually saved on the FTP without any server or database requests or anything. Could this soley be due to the editor that is being used to save/upload the file? I use CoffeeCUP FTP.
It's highly likely that the editor is causing this. Have you tried saving it in an editor like Notepad++ (making sure the file is being saved with UTF-8 encoding) and uploading the file?
I have windows XP at home - home ed, with SP3. In any case, at College, they have windows 7. So, basically when I saved my documents and brought them here, things messed up. I was writing up a short bio.
I was coding my website, and so as usual I had used charset utf-8, the standard. But when I get home and I verify my website (locally), I see the weird characters appear! The triangle and the question mark inside it. So, then I'm like WTF? So I decide to go online and check which charset is better. So randomly, I fall onto windows-1252. Voila, it worked! But then, I decided to re-use charset utf-8, being the standard. I don't want to mess up my website lol.
So I basically go back inside my html document, just to notice that very weird characters appeared. So I delete them and replace them with the the apostrophe that were originally there. Finally, I check my website, and the apostrophes correctly appear.
So, what the hell is going on??? And should I keep using utf-8?
It sounds like the content of the webpage is actually encoded as Windows-1252 by whatever editor you are using, but you are manually writing a <meta> tag that states UTF-8 instead. That would account for the behavior you describe. An explicit charset declaration must match the actual encoding used by the data. When you tell your editor to save the document, make sure it is saving the data in the correct encoding you are expecting. Some editors do support multiple encodings, so don't just blindly use a default encoding if multiple encodings are available.
I have a simple vb6 editor type application which has a richtextbox as the editor page. It allows users to key in stuff and the store it into a file which will keep all the text in RTF stored as CDATA in xml.
When you load back the file, it will read it off the xml and load back the rtf. We allow for unicode editing, but my problem is I have a user which is using Windows XP, and they have some problems reading the chinese characters. They show up as gibberish in their pc.
It displays fine in both mine and a coworker's. I've already checked that they have the proper regional language and settings in their system. The install files for east asian language is already checked. And they can see chinese words on websites and even type them out.
I feel like I'm missing something here but I'm at a lost on what to check next? Any ideas on what I could test or check next?
my bad for the poor description skills, if anything is not clear just ask me.
thanks.
~steve
That is weird. Try confirming that your user have the same version of RICHTXT32.OCX ?
Could be a problem with font?
Try using font that supports unicode characters (Arial Unicode).
Or try going to a website with chinese characters and paste it into richtextbox, save it to a file and try loading it from the file.
Does that work?
well they should because i packed the app in vs installer setup package.
and for fonts, it's sim sun, and i've already checked with the users that they do have the sim sun fonts under window/fonts.
Btw i've already updated that the data is actually stored in xml under CDATA, although the rtf chunk is kept as it is.
okie, this seems to be the solution although i don't know why. in my msi setup file i've included the riched.dll so when i installed it in, the dll acts up and screw up my chinese character in the richtext control.
but when i repack to exclude that dll file and reinstall using that setup, it seems to work now...