Addresses
Kingsley Klosson
separate into distinct fields for address, city, state, and zip. Has
anyone written some code to do that effectively?
Paul S. Person
Not as such, no. I solved a similar problem 20 years ago. This
involved records captured in text form by a terminal program from a
minicomputer for processing on a PC. This was necessary because the
people running the minicomputer claimed that they couldn't provide the
data themsevles "because the PDP speaks FORTRAN and the PC speaks
ASCII". Which, of course, was nonsense, but it certainly gives a feel
for just how helpful they were.
The key here is: which end do you start at? for address, city, state,
and zip, it would probably be simplest to start at the end and work
backwards: the possible ZIP code formats are pretty small, and even if
state names are used sometimes instead of the standard two-letter
abbreviations, still, there are only 50 states (and, IIRC, four other
possibilities).
Separating address from city could be a problem in general. However,
if you are willing to restrict the code to "correctly formatted" input
records, then it might not be a problem at all: the most common
format, after all, is to place a comma at the end of the address, so,
so long as no commas exist within the address, the comma can be used
to separate the two. In this case, pulling the address from the front
would make sense. Then again, since commas are even less likely in
city names than in addresses, continuing to move backwards might work
better. In this case, the first comma in front of the last letter in
the city name would be the separator.
Something sensible would have to be done with "ill-formed" records.
Examining them could lead to tweaks to the program so that it could
parse some of them. Ultimately, however, it is likely that someone
would have to look at a set of very ill-formed records and parse them
manually.
--
Here lies the Tuscan poet Aretino,
Who evil spoke of everyone but God,
Giving as his excuse, "I never knew him."