So you are looking for three or more lines together, the last ending in something that looks like a post code...
$letter =~ m/((?:[^\n]+\n){2,}[^\n]*?[a-zA-Z]+[0-9]+\s+[0-9]+[a-zA-Z]+\s*?\n)\s*?\n/
...seemed to do the trick, where the entire letter was read into $letter. Obviously this will miss addresses with no post code or really rubbish post codes. You could just extract all groups of 3 or more lines, and then apply some more cunning address recogniser to the result -- perhaps from one of the modules recommended elsewhere.
(I haven't tried to figure out how much work this is asking the regex engine to do on difficult input. I'd worry about that only if it becomes a problem.)
| [reply]
[d/l]
[select] |
| [reply] |
I have little to add to the other suggestions already made. I think it is unlikely you can home in on the address without it being delimited in some way.
The example above clearly delimits with "VAT No:" and "DESCRIPTION". I think you'll need to know what variations the invoices have had over the years and code for all of them.
Other tricks might help, e.g. is there always a titled name (Mr,Mrs,Miss,Ms etc.) at the start of the address ?, If so analyze all the names in your dataset to identify all unique titles. 177 Elm Road, is the only line that starts with a number so the address is in that block Address lines are the only ones that end with a comma, so use that block The address is always in the first n lines of the invoice ? The address always has a county in it ? etc.
Also if you have access to postcode validation (database ?) that could help
Whatever, I assume you will end up with many invoices that can't be correctly handled, so you'll need to agree how to handle those exceptions.
| [reply] |
This idea looks like it is in the right direction.
If the address you seek is between a VAT line and a DESCRIPTION line, and that's the way that it always is, then, something like this might help?
This code looks for non-blank lines between and including lines starting with VAT and DESCRIPTION. So throw away those lines and any blank lines. The "trick" then comes down to figuring out when the address ends. If it is possible to write a simple regex that fits a UK postal code, then no state machine is required (when you see the postal code, the address record is done). Below I threw in an extra line feed when I see the postal code. Many variations are possible! Anyway, just an idea for you... Maybe this doesn't work if postal code is too variable and of course you'll have to refine my regex... But maybe this will spark another idea?
while (<DATA>)
{
if (( /^VAT/.../^DESCRIPTION/) && (!/^s*$/))
{
next if /^VAT/;
next if /^DESCRIPTION/;
print; #these are the address lines
print "\n" if (/\w+\d \d/); #the trick is to see
#when address is done, eg a postal code
}
}
__END__
prints:
Miss Carol Hocker
177 Elm Road,
Brighton
East Sussex
BN2 7HB
Mr Whatever
177 Elm Road,
Brighton
East Sussex
BN2 7HB
__DATA__
Invoice
Invoice No: C0331-2008
Invoice Date:27/02/2008
VAT No: 679 7113 03
Miss Carol Hocker
177 Elm Road,
Brighton
East Sussex
BN2 7HB
DESCRIPTION
blah..blah
Invoice No: C0331-2008
Invoice Date:27/02/2008
VAT No: 679 999 03
Mr Whatever
177 Elm Road,
Brighton
East Sussex
BN2 7HB
DESCRIPTION
...something here....
| [reply]
[d/l] |
e.g. is there always a titled name (Mr,Mrs,Miss,Ms etc.) at the start of the address ?, If so analyze all the names in your dataset to identify all unique titles.
177 Elm Road, is the only line that starts with a number so the address is in that block
Address lines are the only ones that end with a comma, so use that block
The address is always in the first n lines of the invoice ?
The address always has a county in it ?
I would assume that there isn't always a title - invoices are often addressed to a company, or to "The Mumble officer".
Addresses don't always include a number. Some houses only have names. eg, Mumble Farm, Mumblevillage, Kent
Address lines don't always end in a comma - although that at least should be consistent in any particular version of an application. Should. Unless addresses were entered manually in a multi-line text box.
Addresses don't always have a county in them. The county is no longer required.
And you won't have a post code for all addresses.
The solution *in this case* is to look for whatever is between "Vat No: blahblah" and "description". In the general case, you're buggered, because you can't tell the difference between this:
My new address is as follows. Please send all correspondence to: Tottenham Hotspur, Edinburgh Rd, Bexhill. Blah blah blah blah
(yes that's a real address - someone who lives near my parents named his house after the football club.
and this:
In my address to the society I looked at the apparent links between: Tottenham Hotspur, Edinburgh Road, Bexhill. I used them to demonstrate the difference between correlation and causation.
The solution we adopt where I work to a somewhat similar problem is to have the machine look for the data and attempt to parse it, but to show a person the data *in context* before committing it to the database. This is much quicker than having a person find/highlight/cut/paste the data, while still having reasonable quality control. Where the computer gets it right, it's a lot faster than a person, and where the computer gets it wrong, a person can fix it.
| [reply] |