|
Jeff Varszegi wrote:
System.Text.Encoding.UTF8
UTF8 is an RFC[^] so it wouldn't make much sense to change the case.
-Nick Parker
DeveloperNotes.com
|
|
|
|
|
AFAIK, whether something describes part of an RFC or not has nothing to do with the Microsoft casing guidelines. I'm not trying to be curt, I just don't think that your criterion applies. I could easily be wrong-- I'm not a walking encyclopedia of Microsoft documentation.
If it were me, I would never have cased XML as 'Xml' either, so I agree with your design ethic for sure! There are lots of other naming inconsistencies besides the ones I posted, too. I just picked a handful.
Thank you.
Jeff Varszegi
|
|
|
|
|
Jeff Varszegi wrote:
AFAIK, whether something describes part of an RFC or not has nothing to do with the Microsoft casing guidelines.
I agree, what I was suggesting was simply why change the name of something that is actually described as an acronym somewhere else, in this case it is an RFC. Who knows the exact reasoning behind some of this; maybe someone from Microsoft will read this thread and offer some insight?
-Nick Parker
DeveloperNotes.com
|
|
|
|
|
If they do, it'll break all code. So no, they won't (at least they better not, and they're smart enough not to).
BTW, Cc and Bcc do not conflict: in most cases in the .NET Framework BCL, they use camel case even when using acronyms. Bcc and Cc both start with upper-case characters and proceed to use lower case.
As someone that's followed the .NET Framework since early beta days, I can tell you the case changed a couple times. System.Xml used to be System.XML . Almost all acronyms were completely upper-case. Perhaps they felt that developers didn't want to hold down the shift key for so long. Why they didn't remain consistent on everything, I don't know.
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
|
I agree with you. What I'm really fumbling my way to saying, I guess, is that they should ditch this dumb two-letter-is-always-uppercase rule that they seem to have invented just to explain the name of the System.IO namespace. The standard should be heads-up camel, all the time. Of course, this would require them to admit that they made a few mistakes.
I also don't see Microsoft deprecating whole classes and namespaces in an effort to clean up the mess, and it's best that they don't!
Regards,
Jeff Varszegi
|
|
|
|
|
I am trying to take a byte array and cast it to a string.
The closest I have come is:
<br />
ASCIIEncoding.GetString Method (Byte[])<br />
However, there is a restriction:
"Any element of the bytes array that is greater than
hexadecimal 0x7F is translated to a Unicode question mark
('?')."
I need to keep that extra bit.
Tym!
|
|
|
|
|
Where are you getting the byte array from? If it involves multi-byte characters, shouldn't you be using a char[] array instead?
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma Gandhi
|
|
|
|
|
I am creating the byte array from individual bytes that don't represent chars, simply 8-bit values. They are being put in a struct as a string and the struct is sent by reference to a win api function (interop).
|
|
|
|
|
Take a look at cultures and globalization. I assume you need an 8 bit encoder/decoder using some codepage.
--
I am of The Clan of Xymox. I wear a pink kilt!
|
|
|
|
|
I'm not too familiar with the encoders/decoders or how unicode particularly works, but my concern here is that if i have for example:
byte b1=0x85;
byte b2=0x7f;
the data i want to actually send should be:
0x857f
which I believe would be a valid unicode char.
first of all, i don't want and encoder to "pad" my bytes when building a string (0x0085007f), nor do I want a decoder interpretting the bytes and apparent chars... thereby messing up the raw bits.
I tried forgetting about building the array as a string and just defining it as a byte[] in the struct, but I couldn't get the marshalling right (unable to marshal struct as unmanaged type; cannot determine size...) When using a string, I am not getting a runtime error, I am just not building the string properly because I am getting incorrect results.
I am open for any and all suggestions!
Thanks
|
|
|
|
|
Well.. what is the byte array made of? Do you know what character set it is made of?
The ASCII character set is 7-bit only, therefore anything above 0x7f is "invalid" and not representable by using that character set.
Please see Encoding.GetEncoding() it should solve your problem.
--
I am of The Clan of Xymox. I wear a pink kilt!
|
|
|
|
|
The byte array is made of bytes. They do not represent characters.
|
|
|
|
|
Then... uhm. why, if I may ask, on earth are you trying to cast an array of bytes into a string?
--
I am of The Clan of Xymox. I wear a pink kilt!
|
|
|
|
|
Well, that is not necessarily my ultimate solution, but I have gotten runtime errors when trying to pass the data as arrays. I may be able to, but I can't quite get everything right.
I chose a string at first because it is in a struct that mimics an unmanaged struct and the original, unmanaged struct defines it as a string. The whole struct is then passed by reference in an interop call to a windows API function. When I use a string, the code runs, but the data in the string is incorrect and I get incorrect results.
When I have used byte[] or char[] or even StringBuilder, I got runtime errors, saying the struct cannot converted to unmanaged.... the size cannot be determined.
I might be able to do it both ways, I just need to figure out what I'm missing...
|
|
|
|
|
Tym! wrote:
Well, that is not necessarily my ultimate solution, but I have gotten runtime errors when trying to pass the data as arrays. I may be able to, but I can't quite get everything right.
I'm still confident though that this is the right way to do it. God knows what the .NET runtime does to strings when you're not watching...
--
I am of The Clan of Xymox. I wear a pink kilt!
|
|
|
|
|
While it is counter-intuitive, what you want in this case is UnicodeEncoding.GetString(byte[]) . Because the data inside a string is natively stored using that UnicodeEncoding, it is a null transform, leaving your bytes alone.
(I suspect you'd better have an even number of bytes in your array if you want this to work. Herein lies a subtle inconsistency between BSTR's and System.Strings. BSTR's kind of admit to being used to pass random data around, and hence support odd numbers of bytes even though they are supposedly a strings of 16bit values. Your API hopefully won't care if you pad an extra null on the end if the length was odd.)
-Blake
|
|
|
|
|
yeah, it's always going to be a multiple of 4 bytes, so I don't need to worry about padding. I used the UnicodeEncoding and get a different, yet still incorrect, result.
I wonder if I am not declaring the struct correctly or I don't know, I feel that I am so close, but am just missing something...
Thanks for your help.
|
|
|
|
|
What about something like this? I didn't test, so it might have a typo, but would this sort of approach work? I don't know how you want the ordering. -Jeff
private const string blankString = "";
public static string ConvertToString(byte[] bytes) {
if (bytes == null) {
return blankString;
}
int length = bytes.Length;
if (length == 0) {
return blankString;
}
else if ((length % 2) == 0) {
length /= 2;
char[] chars = new char[length];
for(int charIndex = 0, byteIndex = 0; charIndex < length; charIndex++, byteIndex += 2) {
chars[charIndex] = (char)((((int)bytes[byteIndex]) << 8) + ((int)bytes[byteIndex + 1]));
}
return new string(chars);
}
else {
length /= 2;
char[] chars = new char[length + 1];
for(int charIndex = 0, byteIndex = 0; charIndex < length; charIndex++, byteIndex += 2) {
chars[charIndex] = (char)((((int)bytes[byteIndex]) << 8) + ((int)bytes[byteIndex + 1]));
}
chars[length] = (char)(((int)bytes[bytes.Length - 1]) << 8);
return new string(chars);
}
}
|
|
|
|
|
Like Jorgen said u need to get your codepage.
Get it with Encoding.Default . that should fix the issue.
leppie::AllocCPArticle("Zee blog"); Seen on my Campus BBS: Linux is free...coz no-one wants to pay for it.
|
|
|
|
|
Thanks everyone for your help. Just to let you know, i ended up using encoding.default to get it working. Got a little lesson on .net text...
Thanks again!
|
|
|
|
|
Hi!
I have just begun lerning C#, so I still don’t know about it clearly!
I want to ask:
Are there any ways to put some codes into an event of a control similar to ClassWizard of VC++ 6.0? or do we have to create a delegate, then add it to event collection of the control? I think the latter is difficulty and complex!
Thanks!
xyz
|
|
|
|
|
I'm not sure I follow. The event system for the C# language works as follows:
someControl.Click += new EventHandler(MyHandleMethod);
someControl.Click -= new EventHandler(MyHandleMethod) If you think this is difficult or complex, try the "event" system in Java!
This code is automatically translated by the C# compiler into something else that does amount to creating a new delegate and adding it to a collection. Internally, class events essentially become a table with collections keys (the table key is the event name, the value is a collection of delegate), but - again - you don't need to worry about doing this in your source code (unless you really want to)! Just type event [EventHandlerDelegate Type] [EventName] . There's plenty of documentation on the event system in C# and VB.NET in the .NET SDK docs, which is always a good place to check-out for newbies (especially, IMO, at least glancing over the entirety of the base class library to see what's available).
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
|
...and in the Whidbey release, it'll be even easier, less code to write.
The graveyards are filled with indispensible men.
|
|
|
|
|
I'm not sure about that myself. Seems like they're starting to victimize C# as VB was from the start by making too many shortcuts for lazy programmers! Besides, think about answers in the forums. Some n00b asks how to do something, someone answers him one way using the delegate short-form. The n00b disagrees (that always makes me laugh!) because he saw it using the long-form. I think we're going to have lots of cases where typical answer-providers are going to have to explain that quite a bit.
There's already way too many lazy programmers in this field - just look at the VB forum!
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
|
Heath Stewart wrote:
There's already way too many lazy programmers in this field - just look at the VB forum!
-Nick Parker
DeveloperNotes.com
|
|
|
|