I have just transferred a site from iss on a windows 2003 to a 2008 server.
Everything is working as before, except some pages in Japanese and Korean, where the text comes out like a garbled mess:
‰‹ã®ãƒ‡ã‚¤ãƒ ・ジョーン・サザーランドã€ã‚µãƒ¼ãƒ»ãƒˆãƒ¼ãƒžã‚¹ãƒ»ã‚¢ãƒ¬ãƒ³ã€ã‚¢ãƒ«ãƒ•ã‚£ãƒ¼ãƒ»ãƒœãƒ¼ã‚„楽器演å¥å®¶ã‚¸ã‚§ãƒ¼ãƒ ズ・ゴールウェイã€ã‚¸ãƒ§ãƒ³ãƒ»ãƒªãƒ«ã€ãƒŠã‚¿ãƒªãƒ¼ãƒ»ã‚¯ãƒ©ã‚¤ãƒ³ã¨ã„ã£ãŸé¡”ã¶ã‚Œã§ã™ã€‚
It looks like this.
The character encoding is set to UTF-8 as it was before. Is there a server setting that needs to be changed?
I worked out why this was happening - even though the meta tag set the page to be encoded in utf-8. An incorrect setting in IIS caused the mangling of the Japanese and Korean characters.
I fixed this in the following way:
Went to IIS Manager
Went to .NET Globalization settings
Made sure that the File encoding was set to utf-8
Then everything started working as expected.
Related
I have a web API that is hosted in Azure. Because of the fact that after 20 minutes of inactivity IIS goes to sleep, I also added a startup script that removes this timeout, so that IIS stays awake. As specified, this file should be saved as UTF-8 without signature, otherwise it is not run on Azure during deployment.
This all works fine the first time.
The problem is that every time we close Visual Studio and reopen it, it seems to forget that the startup file is saved as 'UTF-8 without signature'; it always reverts it to 'UTF-8 with signature'.
I have tried is as described here (advanced save options) and also the fix file encoding extension, but nothing helps. The file is always back to 'UTF-8 with signature'. My collegue has exact the same issue.
As a result, before each deploy we first save the file again as 'UTF-8 without signature' explicitely, which is annoying.
In case it's relevant, our source code is hosted in Visual Studio Online.
Anyone has another idea we can try?
EDIT: just stumbled on Azure Web Role "warm up" strategies, maybe I can try one of these alternatives.
I have a web.config file that references a rewrites.config file that is used by the inbuilt IIS Rewrite module. However my rewrites.config file is larger than 250kb, so i have followed the advise on this post. However it appears that in IIS 8.5 (Windows Server 2012) these keys are ignored. I've search the interwebs and haven't been able to find much on IIS 8.5, anyone got any advice on how to increased the maximum.config size? Or alternatively split rewrites.config into smaller files?
You can just create the key.
Right click on the parent node in REGEDIT - add a new Key called Configuration. Then add a new DWORD for MaxWebConfigFileSizeInKB (you'll probably want to switch to the decimal view) and set the value in KB.
I've just tested this on a rewritemap.config file 753kb in size on a server running IIS8.0 on Windows Server 2012 (I'm making an assumption here that this won't be terribly different from IIS 8.5). You'll need to set the appropriate key depending on whether this is 64bit or 32bit (see here). If in doubt set both. I can confirm that this value is being used since turning the value down to (for example) 10 triggers the error again.
Don't forget to restart the app pool.
Does anyone have dbsight running successfully on linux under tomcat?
It works fine on windows, on linux however all the pages spit out garbage characters. In itself, the app appears to deploy normally.
The tomcat uri encoding is set to utf-8 on both windows and linux.
the lang is set to en_US.UTF-8
I notice you also posted this question on the DBSight web page - good. That was smart :)
You say you set $LANG to "en_US.UTF-8" in your environment, and in server.xml. That's good. Please note that Linux is case-sensitive: the variable must be spelled "LANG", not "lang", or "lAnG", or anything else.
One other issue might be "LC_ALL" - this can override the value of "$LANG":
http://publib.boulder.ibm.com/infocenter/wmbhelp/v7r0m0/index.jsp?topic=%2Fcom.ibm.etools.mft.doc%2Fae19494_.htm
If you're still having a problem, please specify what kind of Linux (Redhat Enterprise? Ubuntu? etc) and version (e.g. Ubuntu Server 11.1).
I am experiencing an extremely strange problem with IIS 7.5 on Windows Server 2008 R2 64 bit.
Any file (no matter the extension, could be .txt, .htm, .js, or anything) that has an http:// on any line, and a on any subsequent line, cannot be fully downloaded from IIS. You get a partial download that just hangs.
This fails with static content compression on or off, with output caching on or off.
The issue doesn't occur on a local dev environment running IIS 7.5 on Windows 7.
Any thoughts as to the cause?
Websense Proxy was the cause. APparently is used by spammers to disguise their spam, and an overaggressive rule was put in place by our security team.
I recently switched from Vista to Windows 7 (with IIS 7.5). But i can't seem to get it fully working.
My problem: I run Visual Studio 2008 (sp1) (run as administrator) and i see my WebSite (webforms).
I publish my website, and all seems well, except my layout is wasted.. why? i get a 404 on my CSS and javascript file.
I read an article that you need content server (service?) installed. After some translation i figured that should be "Statische inhoud" (dutch.. translated static content).
I triple checked that the .js and .css files are in te folder i'm pointing to (tried root folder of the website), but all in veighn...
Here is my IIS-component list that is installed (in dutch).
Anyone able to figure out why i get 404's? or even beter, how do i fix it?
http://img69.imageshack.us/img69/4026/iis.png
I had this problem and spent 6 hours doing research and trying out many suggested solutions.
We resolved this by granting the default IIS user access to the application folder.
Well, i finally figured it out :)
Hope some else will be helped by this answer:
It was related to the Static File Module.
Microsoft has a solution which did not work for me.
http://support.microsoft.com/kb/942052/
It was already configured this way.
But i deleted it, added it again, i could access my CSS... but ASPX didn't work anymore. The Fix for that issue: Make the list Sorted, and move your static filehandler to the bottom (or a least after aspx, but probably the best is at the bottem).
Thanxs everyone for the pointers though!