D
DAXU
Hi,
Can anyone tell me how to put char like ½ to a string? Do I need to
use \u...?
Many Thanks
Can anyone tell me how to put char like ½ to a string? Do I need to
use \u...?
Many Thanks
J
Jon Skeet [C# MVP]
DAXU said:
Yes. Find out the Unicode character number, and put all four hex digits
in a \uxxxx escape sequence.
R
Rene
DAXU,
Are you adding this character to your source coed? If so, what's wrong with
just coping and pasting the character to your source file? Visual Studio
should be able to handle it no problem.
Hi,
Can anyone tell me how to put char like ½ to a string? Do I need to
use \u...?
Many Thanks
Are you adding this character to your source coed? If so, what's wrong with
just coping and pasting the character to your source file? Visual Studio
should be able to handle it no problem.
Hi,
Can anyone tell me how to put char like ½ to a string? Do I need to
use \u...?
Many Thanks
J
Jon Skeet [C# MVP]
Rene said:
In my experience it's a bad idea to have non-ASCII characters in source
code. If every tool you use understand the encoding involved, it's fine
- but often that's not the case.
J
Jeroen Mostert
Your Usenet client illustrates the problem nicely, I'd say, seeing as how itJon said:
doesn't handle Q-encoded headers properly.
Then again, conservatism is what causes these encoding problems to persist
in the first place. Programmers should demand and get tools that, at least,
handle UTF-8 correctly. And let's face it: most C# programmers will never
see any tool but Visual Studio, and the tools it runs in the background are,
as far as I've ever seen, all good Unicode citizens.
Of course, these issues are made moot if you walk the high road and put your
strings in a resource assembly. Somehow, I don't think "½" is often part of
a non-localized string.
J
Jon Skeet [C# MVP]
Jeroen Mostert said:Your Usenet client illustrates the problem nicely, I'd say, seeing as howit
doesn't handle Q-encoded headers properly.
My Usenet client is fine - it handled DAXU's original post just fine,
preserving the Q-encoded header. Rene's client, however, decided not to
use Q-encoding and just put the symbol in directly. Have a look in the
headers
Does WinDiff do the right thing? Other source control clients?
True.
J
Jeroen Mostert
Jon said:
This is the original post:
From: DAXU <[email protected]>
Newsgroups: microsoft.public.dotnet.languages.csharp
Subject: =?ISO-8859-1?Q?how_to_put_character_like_=BD_to_a_string=3F?=
Date: Thu, 14 Feb 2008 07:51:56 -0800 (PST)
Organization: http://groups.google.com
Lines: 6
Message-ID: <4ac4fed9-b0dc-4376-bc27-9c843458b069@c23g2000hsa.googlegroups.com>
Here's your first reply to that post (not Rene's):
From: Jon Skeet [C# MVP] <[email protected]>
Subject: Re: =?ISO-8859-1?Q?how_to_put_character_like_=3DBD_to_a_strin?=
=?ISO-8859-1?Q?g=3F?=
Date: Thu, 14 Feb 2008 16:00:36 -0000
Message-ID: <[email protected]>
That doesn't look right to me.
Hey, I like WinDiff, the venerable old workhorse (and its lack of Unicode
support falls on the "old" side rather than the "venerable"), but if you're
using it as a *source control client* something's seriously wrong with your
setup.
Even SourceSafe can handle Unicode (OK, so you need at least VSS 2005, but
I'm assuming you've got that if you're developing .NET), and SourceSafe
isn't exactly known as the most professional solution.
If your source control doesn't handle Unicode, then by all means send it
back for a refund. I would not accept that as an argument to forego Unicode.
You couldn't even version most XML files with such a system.
J
Jon Skeet [C# MVP]
Jeroen Mostert said:
Sorry, you're absolutely right - I was looking at a different post.
Doh.
Sorry, I realised as I hit "send" that it was inappropriate - it's part
of what is used *with* source control clients, for diffing purposes.
That's one way of putting it
I suspect many systems will be able to correctly store everything, bot
necessarily work as well as you'd like - showing differences being the
most obvious example.
Anyway, like you I'd *hope* that the tools would work appropriately -
but I've seen enough problems with encodings in source files to act
cautiously.
L
LVP
http://www.alanwood.net/demos/ansi.html
Character ANSI
Number Unicode
Number ANSI
Hex Unicode
Hex HTML 4.0
Entity Unicode Name Unicode Range
½ 189 189 0xBD U+00BD
½ ; vulgar fraction one half Latin-1 Supplement
Yes. Find out the Unicode character number, and put all four hex digits
in a \uxxxx escape sequence.
Character ANSI
Number Unicode
Number ANSI
Hex Unicode
Hex HTML 4.0
Entity Unicode Name Unicode Range
½ 189 189 0xBD U+00BD
½ ; vulgar fraction one half Latin-1 Supplement
DAXU said:
Yes. Find out the Unicode character number, and put all four hex digits
in a \uxxxx escape sequence.
C
christery
Jon Skeet [C# MVP] wrote:> Rene said:
Your Usenet client illustrates the problem nicely, I'd say, seeing as how it
doesn't handle Q-encoded headers properly.
Then again, conservatism is what causes these encoding problems to persist
in the first place. Programmers should demand and get tools that, at least,
handle UTF-8 correctly. And let's face it: most C# programmers will never
see any tool but Visual Studio, and the tools it runs in the background are,
as far as I've ever seen, all good Unicode citizens.
Of course, these issues are made moot if you walk the high road and put your
strings in a resource assembly. Somehow, I don't think "½" is often partof
a non-localized string.
I live in a country that use ÅÄÖ, they might come out as EDV or []| or
something... UTF-8/16/32 must be understood by all, unlike ansi of win
junk... just a thought.
//CY
M
Mihai N.
I like it to, but I have moved to KDiff3 for a while now, and I am ok with
it. I still like WinDiff for some operations, but KDiff3 does a good job
overall (I can set the encoding, it can ignore comments, or stuff defined
by some regular expressions, etc.)
It is source, and updated quite often.