I moved my site server and the new server uses comma instead of period when using decimals.
Locally i set my machine to use comma so that i could work out a code fix.
I added <globalization culture="af-ZA" uiCulture="af-ZA" /> to my web.config and found that it then apply's the period to separate decimals, which is what i was looking for.
When i place <globalization culture="af-ZA" uiCulture="af-ZA" /> onto my site web.config hosted on new server it does not change the decimal separator to period, it says as comma?
Could the server force a format standard that is stopping me from changing it?
You can use CultureInfo.InvariantCulture Property
MSDN Link.
this way, the server will ignore the settings, and will use the "default" value.
in your case, it will use comma.
Related
I am developing an addon for Mozilla Thunderbird, and I need to set a custom header on outgoing emails. I have noticed an anomaly in the way headers are set.
The call: gMsgCompose.compFields.setHeader('x-test', 'multiple spaces');
will set the x-test header to: multiple spaces - notice how the double spaces were transformed into a single space.
My addon depends on being able to retrieve the exact value, including double spaces. It is not an option to replace double spaces with something else. How can I make Thunderbird stop this transformation? Is the source code available somewhere so I can examine why and how this happens? I suspect the problem might lie with how line folding is implemented.
Cheers.
It's a feature, apparently. Here is the source code in question. This is to comply with RFC-2047 about replacing linear-white-spaces with a single space.
So I guess Thunderbird does as its supposed to, and I have to find another way around that limitation.
This week we upgraded to JasperReports Server 4.7 (Professional) and iReport 4.7. I have several reports that I created in iReport 4.5.1 and successfully used in JasperReports Server 4.5.1.
After the upgrade, all of my dollar signs are now little boxes. The pattern for my currency fields is ¤ #,##0.00. JasperReports Server is not replacing the box with a dollar sign when the report is generated. Everything looks ok in the pattern sample. My percentage symbols are all still working. I tried removing and applying the currency pattern to the fields again, but this didn't fix the problem.
Any thoughts on how I can fix this?
This is Java operating as intended... but not as you want it to operate. Your locale does not specify a currency, so you get that "¤" symbol.
You could workaround it by changing your locale from "en" to "en_US". I just did this last week. As a side note, I found one tweak that I needed to make. After changing the locale to en_US I needed to copy one file like this:
cp .../jasperserver-pro/scripts/jquery/js/jquery.ui.datepicker-en.js .../jasperserver-pro/scripts/jquery/js/jquery.ui.datepicker-en-US.js
Alternatively, I usually find it's better to work around it by setting your format mask to use a hard-coded dollar sign. If you are displaying "$50.00" to a user in the United States, it would be nonsensical to display "€50,00" to a European user or "¥50.00" to a Japanese user for the same value. There are lots of times when the hard-coded currency symbol is more appropriate.
We restored from a backup in a different format to a new MySQL structure (which is setup correctly for UTF-8 support). We have weird characters showing in the browser, but we're not sure what they're called so we can find a master list of what they translate to.
I have noticed that they do, in fact, correlate to a specific character. For example:
â„¢ always translates to ™
— always translates to —
• always translates to ·
I referenced this post, which got me started, but this is far from a complete list. Either I'm not searching for the correct name, or the "master list" of these bad-to-good conversions as a reference doesn't exist.
Reference:
Detecting utf8 broken characters in MySQL
Also, when trying to search via MySQL query, if I search for â, I always get MySQL treating it as an "a". Is there any way to tweak my MySQL queries so that they are more literal searches? We don't use internationalization much so I can safely assume any fields containing the â character is considered to be a problematic entry, which would need to be remedied by our "fixit" script we're building.
Instead of designing a "fixit" script to go through and replace this data, I think it would be better to simply fix the issue directly. It seems like the data was originally stored in a different format than UTF-8 so that when you brought it into the table that was set up for UTF-8, it garbled the text. If you have the opportunity, go back to your original backup to determine the format the data was stored in. If you can't do that, you will probably need to do a bit of trial and error to figure out which format the data is in. However, once you know that, conversion is easy. Read the following article's section on Repairing:
http://www.istognosis.com/en/mysql/35-garbled-data-set-utf8-characters-to-mysql-
Basically you are going to set the column to BINARY and then set it to the original charset. That should make the text appear properly (a good check to know you are using the correct charset). Once that is done, set the column to UTF-8. This will convert the data properly and it will correct the problems you are currently experiencing.
HI,
[background]
We currently build files for many different companies. Our job as a company is basically to sit in between other companies and help with communication and data storage. We have begun to run in to encoding issues where we are receiving data encoded in one format but we need to send it out in another. All files were prevsiously built using the .net framework default of UTF-8. However we've discovered that certain companies cannot read utf-8 files. I assume because they have older systems that require something else. This becomes apparent when sending certain french charaters in particular.
I have a solution in place where we can build a specific file for a specific member using a specific encoding. (While I understand that this may not be enough, unfortunately this is as far as I can go at the moment due to other issues.)
[problem]
Anyways, I'm at the testing stage and I want to input utf-8 or other characters into management studio. Perform an update on some data and then verify that the file is built correctly from that data. I realize that this is not perfect. I've already tried programatically reading the file and verifying the encoding by reading preambles etc. So this is what I'm stuck with. According to this website http://www.biega.com/special-char.html ... I can input utf-8 characters by clicking ALT+&+#+"decimal representation of character" or ALT+"decimal representation of character" but when I use the data specified by the table I get completely different characters in management studio. I've even saved the file in a utf-8 format using management studio by clicking the arrow on the save button in the save dialog and specifying the encoding. So my question is how can I accurately specify a character that will end up being the character I'm trying to input and actually put it in the data that will then be put in a file.
Thanks,
Kevin
I eventually found the solution. The website doesn't specify that you need to type ALT+0+"decimal character representation". The zero was left out. I'd been searching for this for ages.
I have an MVC route that is giving me hell on a staging server running IIS. I am running Visual Studio 2010's development server locally.
Here is a sample URL that actually works on my dev box:
Root/CPUBoards/Full+Size
Results
Server Error404 - File or directory not found.
The resource you are looking for might have been removed, had its name changed, or is temporarily unavailable.
Here is the complete behaviour I am seeing.
Localhost:
Root/CPUBoards/Full Size - Resolves
Root/CPUBoards/Full%20Size - Resolves
Root/CPUBoards/Full+Size - Resolves
Staging Server with IIS 7.0:
Root/CPUBoards/Full Size - Resolves
Root/CPUBoards/Full%20Size - Resolves
Root/CPUBoards/Full+Size - 404 Not Found Error.
Any ideas? I need to work with the encoded version for several reasons... won't waste your time with them.
HttpUtility.UrlEncode("Full Size") returns the version with the plus sing... Full+Size. This works on my dev box, but not on the staging server. I would prefer to just get it working on the server, since I already have everything else tested and working locally, but I have no idea where to start looking on the server configuration to get it to behave the same way.
Thanks!
This is an IIS security setting. There is a standard request filter that rejects URLs containing + (plus) characters.
You can disable it for your web, adding this to your web.config:
<configuration>
...
<system.webServer>
...
<security>
<requestFiltering allowDoubleEscaping="true" />
</security>
</system.webServer>
...
</configuration>
+ only has the special meaning of being a space in application/x-www-form-urlencoded data such as the query string part of a URL.
In other parts of the URL like path components, + literally means a plus sign. So resolving Full+Size to the unencoded name Full Size should not work anywhere.
The only correct form of a space in a path component is %20. (It still works when you type an actual space because the browser spots the error and corrects it for you.) %20 also works in form-URL-encoded data as well, so it's generally safest to always use that.
Sadly HttpUtility.UrlEncode is misleadingly-named. It produces + in its output instead of %20, so it's really a form-URL-encoder and not a standard URL-encoder. Unfortunately I don't know of an ASP.NET function to “really URL-encode” strings for use in a path, so all I can recommend is doing a string replace of + to %20 after encoding.
Alternatively, avoid using spaces in path parts, eg. by replacing them with -. It's common to ‘slug’ titles being inserted to URLs, reducing them to simple alphanumerics and ‘safe’ punctuation, to avoid filling the URL with ugly %nn sequences.
System.Web.HttpUtility.UrlPathEncode(string str) encodes a + to a %20
Totally agree with #bobince, the problem is in the wrong encoding to %2b instead of %20
Sadly HttpUtility.UrlEncode is misleadingly-named. It produces + in its output instead of %20, so it's really a form-URL-encoder and not a standard URL-encoder. Unfortunately I don't know of an ASP.NET function to “really URL-encode” strings for use in a path, so all I can recommend is doing a string replace of + to %20 after encoding.
this is the important part, which is to replace the + sign with %20