I'm very new to C# and I need your help.
I have a file named myData.txt with the following data in it.
Johnson 85 83 77 91 100
Aniston 80 90 95 93 48
Chen 78 81 11 90 73
Gupta 92 83 30 69 87
Blair 23 45 96 38 59
Lamah 100 100 100 100 100
The first three scores are 'Assignments' and the last two scores are 'Exams'.
All the names should go into a 1-dimensional array
Assignments into a 2-dim array
also Exams into a 2-dim array
My ultimate aim is to find out the average of assignments & exams for each student.
This is a homework assignment, so I'll just give you hints:
You can use StreamReader to open the file: StreamReader
Looks like each line ends with a new line. You can loop through the file and read each line via
StreamReader's ReadLine method: ReadLine
It looks like each line is delimited by tab. You can split the string returned by ReadLine on tab by using String's split method: Split. The char code for tab is '\t'. Splitting the string will put it into an array.
Convert the scores to a number, add, and then divide at the end to get the mean.
Related
I'm reading an IES file, here is a little blurb about them...
"The photometric data is stored in an ASCII file. Each line in the file must be less than 132 characters long and must be terminated by a carriage return/line-feed character sequence. Longer lines can be continued by inserting a carriage return/line-feed character sequence."
after a bunch of header information, the line i'm after is 14 lines down. But it can extend any number of lines down from there because of the 123 character restriction. And if you end and continue lines with a carriage return, how can I tell where to stop reading the data? And the following chunk of data is the exact format, a series of angles. Each set may or may not begin and/or end with 0, 90 & 180. What am I missing, how can I collect this data? Below is an example, starting at line 14. Thanks.
0 2.5 5 7.5 10 12.5 15 17.5 20 22.5 25 27.5 30 32.5 35 37.5
40 42.5 45 47.5 50 52.5 55 57.5 60 62.5 65 67.5 70 72.5 75
77.5 80 82.5 85 87.5 90
[no space]
0 22.5 45 67.5 90 112.5 135 157.5 180 202.5 225 247.5
270 292.5 315 337.5 360
Google and the amazing people that post their open source code are your friends :)
https://github.com/kmorin/IESparser/blob/master/IESParser.cs
I am trying to create a byte array that has a certain BCC (Block Check Character) result (=0).
The array will have the preamble of:
32 02 31 1F 31 1E 32 1F T E S T :
32 02 31 1F 31 1E 32 1F 54 45 53 54 3A 20
With a variable text message (msg) in the middle:
T e s t 2
54 65 73 74 32
Followed by a postamble of:
1E 37 1F 33 03
The BCC I get for this string is: 0x11
Here's the algorithm that returns this value (C++):
unsigned char bcc=0;
int index = block.Find(0x03); //ETX
for (int i=0; i<= index;i++)
bcc ^= block[i];
return bcc;
I'm trying to come up with a method of finding a middle message section that will result in the BCC of 0.
I am currently using trial and error, but I'm pretty sure there's a better way to do this - I just haven't come up with one that works. I've taken a swing at a tool that replicates the BCC method in use above (in C#) and that disagrees with the results I get (sigh).
You can set the checksum to zero by replacing any single character with the character xor ed with the current checksum.
For example, change test2 to test#
0x32(#) = 0x23(2)^0x11
You may need to take care to avoid certain special characters (it looks like 0x03 is significant in some way, and often 0x00 should also be avoided in case strings are using null termination). For example, if you wanted to make a character into 0x03 you might instead prefer to add two characters whose xor is 0x03, such as 'a' and 'b'
I'm parsing a file (which I don't generate) that contains a string. The string is always preceded by 2 bytes which tell me the length of the string that follows.
For example:
05 00 53 70 6F 72 74
would be:
Sport
Using a C# BinaryReader, I read the string using:
string s = new string(binaryReader.ReadChars(size));
Sometimes there's the odd funky character which seems to push the position of the stream on further than it should. For example:
0D 00 63 6F 6F 6B 20 E2 80 94 20 62 6F 6F 6B
Should be:
cook - book
and although it reads fine the stream ends up two bytes further along than it should?! (Which then messes up the rest of the parsing.)
I'm guessing it has something to do with the 0xE2 in the middle, but I'm not really sure why or how to deal with it.
Any suggestions greatly appreciated!
My guess is that the string is encoded in UTF-8. The 3-byte sequence E2 80 94 corresponds to the single Unicode character U+2014 (EM DASH).
In your first example
05 00 53 70 6F 72 74
none of the bytes are over 0x7F and that happens to be the limit for 7 bit ASCII. UTF-8 retains compability with ASCII by using the 8th bit to indicate that there will be more information to come.
0D 00 63 6F 6F 6B 20 E2 80 94 20 62 6F 6F 6B
Just as Ted noticed your "problems" starts with 0xE2 because that is not a 7 bit ASCII character.
The first byte 0x0D tells us there should be 11 characters but there are 13 bytes.
0xE2 tells us that we've found the beginning of a UTF-8 sequence since the most significant bit is set (it's over 127). In this case a sequence that represents — (EM Dash).
As you did correctly state the E2 character is the problem. BinaryReader.ReadChars(n) does not read n-bytes but n UTF-8 encoded Unicode characters. See Wikipedia for Unicode Encodings. The term you are after are Surrogate Characters. In UTF-8 characters in the range of 000080 – 00009F are represented by two bytes. This is the reason for your offset mismatch.
You need to use BinaryReader.ReadBytes to fix the offset issue and the pass it to an Encoding instance.
To make it work you need to read the bytes with BinaryReader and then decode it with the correct encoding. Assuming you are dealing with UTF-8 then you need to pass the byte array to
Encoding.UTF8.GetString(byte [] rawData)
to get your correctly encoded string back.
Yours,
Alois Kraus
I want to create a very simple piece of software in C# .NET that I can pass a folder's path to and detect all files with a frequency of below a given threshold. Any pointers on how I would do this?
You have to read mp3 files. To do that you have to find specifications for them.
Generally mp3 file is wrapped into ID3 tag, so that you have to read it, find its length and skip it. Let's take ID3v2.3 for example:
ID3v2/file identifier "ID3"
ID3v2 version $03 00
ID3v2 flags %abc00000
ID3v2 size 4 * %0xxxxxxx
so bytes 6,7,8,9 store header length in big-endian form. Here is sample of some file:
0 1 2 3 4 5 6 7 8 9 A B C D E F
49 44 33 03 00 00 00 00 07 76 54 43 4f 4e 00 00
07 76 - is the size. You need to shift left first byte so that actual size is 3F6. Then add 10 (A) to get the offset = 400. This is address of start of mp3 header.
Then you take description of mp3 header:
bits are: AAAAAAAA AAABBCCD EEEEFFGH IIJJKLMM, we need FF , sampling frequency and convert t to actual frequency:
bits MPEG1 MPEG2 MPEG2.5
00 44100 22050 11025
01 48000 24000 12000
10 32000 16000 8000
11 reserv. reserv. reserv.
You can use UltraID3Lib to get mp3 metadata (bitrate, frequency)
Check value of frequency bits in a file. There is some info about mp3 format.
I'm trying to interface with a hardware device via the serial port. When I use software like Portmon to see the messages they look like this:
42 21 21 21 21 41 45 21 26 21 29 21 26 59 5F 41 30 21 2B 21 27
42 21 21 21 21 41 47 21 27 21 28 21 27 59 5D 41 32 21 2A 21 28
When I run them thru a hex to ascii converter the commands don't make sense. Are these messages in fact something different than hex? My hope was to see the messages the device is passing and emulate them using c#. What can I do to find out exactly what the messages are?
Does the hardware device specify a protocol? Just because it's a serial port connection it doesn't mean that it has to be ASCII/Readable english Text. It could as well be just a sequence of bytes where for example 42 is a command and 21212121 is data to that command. Could be an initialization sequence or whatever.
At the end of the day, all you work with is a series of bytes. The meaning of them can be found in a protocol specification or if you don't have one, you need to manually look at each command. Issue a command to the device, capture the input, issue another command.
Look for patterns. Common Initialization? What could be the commands? What data gets passed?
Yes, it's tedious, but reverse engineering is rarely easy.
The ASCII for the Hex is this:
B!!!!AE!&!)!&Y_A0!+!'
B!!!!AG!'!(!'Y]A2!*!(
That does look like some sort of protocol to me, with some Initialization Sequence (B!!!!) and commands (AE and AG), but that's just guessing.
The decive is sending data to the computer. All digital data has the form of ones and zeroes, such as 10101001010110010... . Most often one combines groups of eight such bits (binary digits) into bytes, so all data consists of bytes. One byte can thus represent any of the 2^8 values 0 to 2^8 - 1 = 255, or, in hexadecimal notation, any of the numbers 0x00 to 0xFF.
Sometimes the bytes represent a string of alphanumerical (and other) characters, often ASCII encoded. This data format assigns a character to each value from 0 to 127. But all data is not ASCII-encoded characters.
For instance, if the device is a light-intensity sensor, then each byte could give the light intensity as a number between 0 (pitch-black) and 255 (as bright as it gets). Or, the data could be a bitmap image. Then the data would start with a couple of well-defined structures (namely this and this) specifying the colour depth (number of bits per pixel, i.e. more or less the number of colours), the width, the height, and the compression of the bitmap. Then the pixel data would begin. Typically the bytes would go BBGGRRBBGGRRBBGGRR where the first BB is the blue intensity of the first pixel, the first GG is the green intensity of the first pixel, the first RR is the red intensity of the first pixel, the second BB is the blue intensity of the second pixel, and so on.
In fact the data could mean anything. Whay kind of device is it? Does it have an open specification?