Splitting up a string

  • Thread starter Thread starter Opettaja
  • Start date Start date
O

Opettaja

I am new to c# and I am currently trying to make a program to retrieve
Battlefield 2 game stats from the gamespy servers. I have got it so I
can retrieve the data but I do not know how to cut up the data to
assign each value to its own variable. So right now I am just saving
the data to a txt file and when I look in the text file all the data is
there.

Not sure if this matters but when I open the text file in Word pad
(Rich Text) It shows something like this.

ŽO
H D
asof 1133092198
H D
pid 43974309
nick Opettaja
scor 1459
jond 1118881320
wins 28
loss 47
.....
.....

But when I open it in notepad (Raw Text) Everything is on one line with
squares indicating linebreaks.

So if anyone has any suggestions on how I can break up each line into
its own variable that would be greatly appreciated. And sorry If im a
little vague on information, I am new to c# and still learning, If you
need more information just let me know.

Thanks.
 
So if anyone has any suggestions on how I can break up each line into
its own variable that would be greatly appreciated. And sorry If im a
little vague on information, I am new to c# and still learning, If you
need more information just let me know.
Click to expand...

This might be helpful:

http://msdn.microsoft.com/library/d...-us/cpguide/html/cpconReadingTextFromFile.asp

It reads the file a line at a time. The problem with Notepad is probably
down to the difference in linefeeds/carraige returns on *nix/Windows. It
might be that the file includes \r or \n rather than both. There's probably
a way to configure what the above code uses as as a line end.

HTH
 
Simply determine, with a hex editor if need be, what the field delimiter
and end of line characters are. I suspect you'll find that they are
tabs and line feeds, respectively.

Once you determine what delimits each field then you can use the
String.Split() method to break the fields up into an array. Read one
line, break that line into fields, process as desired, and repeat until
done.

--Bob
 
Okay I got the lines split up into individual lines, but now how do I
split up the individual lines into 2 variables using Split and spliting
by just spaces. Here is what I have right now

string[] lines = reader.ReadString().Split(new Char[] {'\r','\n'});

for (int i = 0; i < lines.Length; i++)
{
string[] output = lines.Split(new Char[]{' '});
listBox1.Items.Add(output[1]);
}

What do I put in the Char{' '} to make it split by the spaces?
 
If spaces are in fact the delimiter then what you have is fine. You
want a character array of characters to split on, and {' '} creates an
array of one character, the space.

Be aware that if there are multiple spaces on a line then you'll get
more than two fields. For example:

Foo Bar
Fu Bar

On the Foo line there are two spaces between Foo and Bar. On the 2nd
line there are three spaces. Splitting on a space will give you three
strings from the first line ("Foo", "", and "Bar") and four strings from
the second line ("Fu","","" and "Bar").

You can either account for this in your parsing of the array or
normalize the whole line before splitting, by removing adjacent spaces,
along the lines of:

while (theLine.IndexOf(" ") > -1) {
theLine = theLine.Replace(" "," ");
}

--Bob
 
if anyone wants to use regular expressions, i can offer up a solution,
but every time i post a solution using regular expressions, i get beaten
up for it. when i say 'beaten up' i mean to say that the replies are
often similar to 'regular expressions are hard to read, avoid them' and
'that's bad style'.

well i'm friggin' sorry but i grew up on Perl and regular expressions
are second nature to me.

yes i'm bitter.

*goes away*

Bob said:
If spaces are in fact the delimiter then what you have is fine. You
want a character array of characters to split on, and {' '} creates an
array of one character, the space.

Be aware that if there are multiple spaces on a line then you'll get
more than two fields. For example:

Foo Bar
Fu Bar

On the Foo line there are two spaces between Foo and Bar. On the 2nd
line there are three spaces. Splitting on a space will give you three
strings from the first line ("Foo", "", and "Bar") and four strings from
the second line ("Fu","","" and "Bar").

You can either account for this in your parsing of the array or
normalize the whole line before splitting, by removing adjacent spaces,
along the lines of:

while (theLine.IndexOf(" ") > -1) {
theLine = theLine.Replace(" "," ");
}

--Bob
Okay I got the lines split up into individual lines, but now how do I
split up the individual lines into 2 variables using Split and spliting
by just spaces. Here is what I have right now

string[] lines = reader.ReadString().Split(new Char[] {'\r','\n'});

for (int i = 0; i < lines.Length; i++)
{
string[] output = lines.Split(new Char[]{' '});
listBox1.Items.Add(output[1]);
}

What do I put in the Char{' '} to make it split by the spaces?
Click to expand...
Click to expand...
 
lol .. sorry for the "off topic" reply but, just wanted to let you know
that at 3:27 am in the middle of a tedious debugging session, you gave
me a giggle.

BTW, I totally agree. Regular expressions are like everything if you
haven't seen them before. They're not so bad once you get used to them.
They can be overkill in some situations, but in others they are by far
the best way.

Oh and if anyone is going to beat up JJ and thinks I'm guilty by
association, I wasn't here.

*tip toes away*


jeremiah said:
if anyone wants to use regular expressions, i can offer up a solution,
but every time i post a solution using regular expressions, i get beaten
up for it. when i say 'beaten up' i mean to say that the replies are
often similar to 'regular expressions are hard to read, avoid them' and
'that's bad style'.

well i'm friggin' sorry but i grew up on Perl and regular expressions
are second nature to me.

yes i'm bitter.

*goes away*

Bob said:
If spaces are in fact the delimiter then what you have is fine. You
want a character array of characters to split on, and {' '} creates an
array of one character, the space.

Be aware that if there are multiple spaces on a line then you'll get
more than two fields. For example:

Foo Bar
Fu Bar

On the Foo line there are two spaces between Foo and Bar. On the 2nd
line there are three spaces. Splitting on a space will give you three
strings from the first line ("Foo", "", and "Bar") and four strings
from the second line ("Fu","","" and "Bar").

You can either account for this in your parsing of the array or
normalize the whole line before splitting, by removing adjacent
spaces, along the lines of:

while (theLine.IndexOf(" ") > -1) {
theLine = theLine.Replace(" "," ");
}

--Bob
Okay I got the lines split up into individual lines, but now how do I
split up the individual lines into 2 variables using Split and spliting
by just spaces. Here is what I have right now

string[] lines = reader.ReadString().Split(new Char[] {'\r','\n'});

for (int i = 0; i < lines.Length; i++)
{
string[] output = lines.Split(new Char[]{' '});
listBox1.Items.Add(output[1]);
}

What do I put in the Char{' '} to make it split by the spaces?
Click to expand...
Click to expand...
Click to expand...
 
Simon said:
lol .. sorry for the "off topic" reply but, just wanted to let you know
that at 3:27 am in the middle of a tedious debugging session, you gave
me a giggle.

BTW, I totally agree. Regular expressions are like everything if you
haven't seen them before. They're not so bad once you get used to them.
They can be overkill in some situations, but in others they are by far
the best way.
Click to expand...

The trouble is that they're overkill in *many, many* situations - but
some people use them as the "default" way of performing string
manipulation.

If you want to operate on pattern, they're great. If you just want to
perform a simple replacement, or matching of an exact string, then
they're not only overkill, but they're *risky* overkill. You have to
remember all the characters which need escaping, etc. Furthermore, you
have to hope that maintenance engineers will remember those characters
too.

Want to find out whether one string starts with another? Use
String.StartsWith.
Want to replace one (exact) string with another within a third? Using
String.Replace.
Want to match or replace patterns? Use Regex.

A lot of things are "not so bad once you get used to them" - but that
doesn't mean they're the best solution to the problem. I'm sure if you
work at it hard enough, you can become quite proficient at banging in
nails with a screwdriver - that doesn't mean it's a better tool than a
hammer for that particular task though.

Jon
 
Simon said:
lol .. sorry for the "off topic" reply but, just wanted to let you know
that at 3:27 am in the middle of a tedious debugging session, you gave
me a giggle.

BTW, I totally agree. Regular expressions are like everything if you
haven't seen them before. They're not so bad once you get used to them.
They can be overkill in some situations, but in others they are by far
the best way.

Oh and if anyone is going to beat up JJ and thinks I'm guilty by
association, I wasn't here.
Click to expand...

As an addendum to my previous post - I was one of the people who "beat
up" JJ last time he suggested using a regular expression. It's an
example which demonstrates my point very well. Here's the code he
suggested:

if you're able to loop through the records in the very large files,
skip
processing when you see that the record you're on starts with "***".

using System.Text.RegularExpressions;
....

foreach (string s in records) { // example code
Match m = Regex.Match(s, "^***");
if (m.Success) { // this is a header or footer
[...]

Now, JJ, who claims that regular expressions are "second nature" to him
got the regular expression wrong. The correct expression, as specified
by Greg Bacon, is @"^\*\*\*". Compare the solution which uses regular
expressions with my suggested solution:

if (s.StartsWith("***"))

Which one is easier to write? Well, JJ got the regex version wrong on
his first attempt. I somehow doubt that my version fails.

Which one is easier to read? Well, if you read my version out loud, it
says *exactly* what it's doing. The same can certainly *not* be said
for the regular expression version.

Is it any wonder that I think JJ's being a little over-zealous with his
use of regular expressions?

Jon
 
jeremiah said:
if anyone wants to use regular expressions, i can offer up a solution,
but every time i post a solution using regular expressions, i get beaten
up for it. when i say 'beaten up' i mean to say that the replies are
often similar to 'regular expressions are hard to read, avoid them' and
'that's bad style'.
Click to expand...

It's bad style to use them when they're unnecessary and are a more
complex solution to the problem than another one. If you look at the
recent thread which talked about finding lines which start with "***",
you'll see a much simpler solution than your suggested regular
expression - and one which, somewhat importantly, *works*.

In this case, however, I believe they're absolutely the right tool for
the job, because an actual pattern is involved. Personally I'd probably
read the file line by line, and then split each line with a regular
expression. The regular expression involved would be pretty simple at
that stage.

Jon
 
errr I think we're aguing the same point???

Not only that but the same side of the same point. I was only saying
that in some situations they are the best solution (but that's only if
you like working with them).

Peace :)
 
Simon said:
errr I think we're aguing the same point???
Click to expand...

Not sure - your "total agreement" with Jeremiah gave me the impression
you thought that regular expressions are fine to use anywhere, whether
or not they're the simplest tool to do the job. What exactly were you
agreeing with?
Not only that but the same side of the same point. I was only saying
that in some situations they are the best solution (but that's only if
you like working with them).
Click to expand...

Well, I think it's worth learning about them if you run into the kind
of situation which they're well-suited to even if you're not familiar
with them already. It's just not worth using them when they're not
appropriate, however familiar you are.

Jon
 
You can either account for this in your parsing of the array or
normalize the whole line before splitting, by removing adjacent spaces,
along the lines of:

while (theLine.IndexOf(" ") > -1) {
theLine = theLine.Replace(" "," ");
}
Click to expand...

One thing to be slightly aware of (other than that this really is
somewhere that regular expressions would help) is that if you've got
bad data, the above could go into an infinite loop. I've seen a
situation where someone had exactly the above code, but in their actual
data they had a "zero-width non-joiner character" between two spaces.
IndexOf ignored it, but Replace didn't. Cue tight loop.
 
Now, JJ, who claims that regular expressions are "second nature" to him
got the regular expression wrong. The correct expression, as specified
by Greg Bacon, is @"^\*\*\*".
Click to expand...

the regular expression is ^***. to quote it properly in C#, you use
what Greg supplied, but the regular expression is the unquoted string,
"^***". I was right about the regular expression and forgot to quote
the regex properly.

Don't tell someone they're wrong unless they're wrong.
 
[Posted and mailed]

the regular expression is ^***. to quote it properly in C#, you use
what Greg supplied
Click to expand...

^ and * aren't special characters in strings - they don't need quoting
at all. Try printing out the string "^***" and you'll find it prints
just fine. Greg's change was (*after* C#'s quoting was applied - in
other words, the actual contents of the string) from "^***" to
"^\*\*\*". The @ at the front just tells the C# compiler that the
backslashes in the string are just backslashes - they shouldn't be
treated as escape sequences themselves.
but the regular expression is the unquoted string,
"^***".
Click to expand...

The right one isn't.
I was right about the regular expression and forgot to quote
the regex properly.
Click to expand...

Even if that were the case, the fact that you'd need to know more than
you do for the simple if (x.StartsWith("***")) still suggests the
latter is the better option.
Don't tell someone they're wrong unless they're wrong.
Click to expand...

Okay, I'll say it again: that's wrong. It's wrong because * has a
specific meaning in regular expressions, and that's not the meaning you
want in this case. You're looking for the '*' character, which needs to
be escaped in the regular expression itself, regardless of C#.

The correct regular expression is "^\*\*\*".
The easiest way to write that in C# is @"^\*\*\*". An alternative is
"^\\*\\*\\*".

Here's a little program to demonstrate that:

using System;
using System.Text.RegularExpressions;

public class Test
{
static void Main(string[] args)
{
try
{
Console.WriteLine
("Using regular expression: {0}", args[0]);

Regex regex = new Regex(args[0]);

Console.WriteLine
("Matches 'hello': {0}", regex.IsMatch("hello"));
Console.WriteLine
("Matches '*** hello': {0}",
regex.IsMatch("*** hello"));
}
catch (Exception e)
{
Console.WriteLine (e);
}
}
}

Now, the command line parameter certainly isn't being parsed by the C#
compiler. If the correct regular expression were indeed "^***" then I
should be able to run test.exe ^*** and get the results False, True,
correct?

Instead, I get:
System.ArgumentException: parsing "***" - Quantifier {x,y} following
nothing.


Still think it's C#'s fault? Try
http://www.fileformat.info/tool/regex.htm
You'll find that typing in ^\*\*\* as the regular expression matches
correctly, whereas ^*** doesn't - it gets a similar error.


Maybe you think it's a .NET-specific thing? Try
http://www.weitz.de/regex-coach/#install
Type ^*** into the "Regular expression" box and you'll get an error
"Quantifier '*' not allowed at position 2".


That's evidence in three different forms that your regular expression
was wrong. Do you have *any* evidence that it was right?
 
jeremiah said:
well that was the last time i ever bring up regular expressions.

you win jon, you ****ing win.
Click to expand...

There's no need to be like that. Regular expressions have their place,
but I think this was a pretty graphic demonstration of why they
shouldn't be used where they really don't help at all - in cases like
this, they hinder.

There's nothing to be ashamed of in posting some faulty code to
newsgroups. I've done it several times. It does help if you can admit
when you're wrong without sulking though.

Jon
 
Jon said:
using System;
using System.Text.RegularExpressions;

public class Test
{
static void Main(string[] args)
{
try
{
Console.WriteLine
("Using regular expression: {0}", args[0]);

Regex regex = new Regex(args[0]);

Console.WriteLine
("Matches 'hello': {0}", regex.IsMatch("hello"));
Console.WriteLine
("Matches '*** hello': {0}",
regex.IsMatch("*** hello"));
}
catch (Exception e)
{
Console.WriteLine (e);
}
}
}
Click to expand...
<snip>

I just pasted that into your online code formatter. That's pretty nifty!!

Now if you can just make it into a Thunderbird/Outlook Express(/etc.)
plugin, to make code in newsgroups more readable, you're on to a winner! ;D
 
Danny said:
<snip>

I just pasted that into your online code formatter. That's pretty nifty!!
Click to expand...

The irony here is incredible, as the code formatter depends very
heavily (and entirely properly) on regular expressions!
Now if you can just make it into a Thunderbird/Outlook Express(/etc.)
plugin, to make code in newsgroups more readable, you're on to a winner! ;D
Click to expand...

Interesting idea. No idea how practical it would be, unfortunately. My
biggest beef with bad formatting is the "leave a blank line between
each line of code" style which Outlook Express seems to generate a lot
of the time. I don't know how easy it is to fix that. My suspicion is
that the kind of people who are interested in posting nicely formatted
code already know how to do it quickly anyway... Of course, I'm happy
to share the code if you want to have a go :)

Jon
 
Jon said:
Interesting idea. No idea how practical it would be, unfortunately. My
biggest beef with bad formatting is the "leave a blank line between
each line of code" style which Outlook Express seems to generate a lot
of the time. I don't know how easy it is to fix that. My suspicion is
that the kind of people who are interested in posting nicely formatted
code already know how to do it quickly anyway... Of course, I'm happy
to share the code if you want to have a go :)
Click to expand...

I've never written plugins or anything like that before, but it might be
a good challenge (+ learning opportunity), so I'll have a look on the
web later, see how difficult it's likely to be, and maybe give it a shot :-)
 
Back
Top