Регулярное выражение для парсинга почтовых адресов

Я думаю, что необходимо разъяснить сценарий использования.

Если Вы не находитесь в очень, очень ограниченный сценарий, где Вы знаете, что адреса вводились в соответствии со строгой схемой, парсинг адресов для содержания является чрезвычайно тяжелой проблемой решить и, обычно, довольно бесполезный (если это не смысл существования Вашего приложения).

Если Вы ограничены конкретной страной, которая имеет очень определенные конвенции для записи адресов, то использование этих regex могло бы получить Вас 90% пути.
Однако, как только необходимо начать принимать внешние адреса, Вы завинчены.
Даже если Вы - американо-центральный сайт, существует хороший шанс, что Вам, вероятно, придется смочь принять адреса от американского гражданина, живущего за границей, например.

Снова, это может быть в порядке в очень узком поле, но это - почти всегда плохая идея проверить или разделить адреса, которые не были строго проверены и ограничены в то время, когда пользователь ввел их.
При осуществлении некоторых строгих правил для пользователей ввести их адреса они заканчивают тем, что были несоответствующими в небольшой части случаев, даже в лучших компонентах проверки адреса там.

Всего несколько вещей, которые портят парсинг адреса:

• индексы (почтовые индексы) иногда помещаются прежде, после, или не могут даже существовать вообще.
• индексы следуют строгим правилам: 10-разрядный почтовый индекс, вероятно, легко определить как недопустимый, но что относительно несуществующего? Что относительно большего количества кодов, таких как используемые в Великобритании, например?
• Что относительно места как Гонконг, где Вы могли записать адрес или в английских, Традиционных китайцах или в Мандарине?
• Что, если это прекрасно подходит, чтобы разделить Ваш адрес и записать это из последовательности?
• даже если Вы просто анализируете американские адреса, существует, по крайней мере, небольшое количество способов описать Почтовый ящик: Вы можете также использовать отдел корреспонденции до востребования, до востребования и затем должны добавить 4-разрядный код к почтовому индексу, который обычно, вероятно, не присутствовал бы вообще...

Нижняя строка

Если получение адресов в parseable формате действительно важно, на 100% уверены, что можно разобраться во всех возможных комбинациях, или Вы собираетесь иметь процент отказов, которые будут означать расстроенных пользователей и продажи потерь.
Если у Вас нет 100%-го покрытия случая, затем не осуществляют строгие правила о пользователе.
Я не могу считать количество веб-сайтов, которые я бросил покупать у того, потому что они потребуют почтового индекса, когда место, в котором я живу, не будет иметь ни одного.

Извините за напыщенную речь, но я думаю, что важно, чтобы люди, желающие сделать, проверка адреса и парсинг думали трудно о том, что они приводят себя.

Я попытался заставить это работать, но кажется, что у вас есть статический член класса StreetTypes, который не включен. Кажется, что это работает, за исключением этого, но я не могу провести много испытаний без него.

Веселитесь с адресами и регулярными выражениями, вас ждет долгая, ужасная поездка.

Вы пытаетесь навести порядок в хаосе.

Для каждого "123 простого пути" ", есть" 14 1/2 Юга ".

Тогда, для дополнительного смеха, есть Солт-Лейк-Сити:" 855 Юга 1300 Востока ".

Веселитесь с этим.

Есть больше исключений, чем правил когда дело доходит до уличных адресов.

Я согласен, что ваша строгость будет проблемой. Я пишу парсер адресов, предназначенный для удаления адресов из тематических объявлений, формат которых может быть любым. Например, при совпадении квадрантов вы полностью игнорируете пунктуацию. Мне нужно искать данные, которые могут представлять NE всеми этими разными способами:

«NE», «NE», «N E», «NE», «N.E», «North East», «Northeast»

, поэтому я использую следующий шаблон сопоставления, который должен улавливать все квалификаторы направления независимо от того, как они выражены:

\b(?:(?:[nesw]\.? ?){0,2}|(?:north|no\.|east|south|so\.|west){0,2})\b

Конечно, контекст - это также важно, так как "нет" будет соответствовать этому. Но «NE» для Небраски будет соответствовать любому, поэтому вам действительно нужно быть осторожным с тем, что находится слева и справа в вашем более широком выражении. Мне нужно составить списки слов, которые обычно встречаются в текстах адреса, которые не являются компонентами адреса, например «рядом, улица x, внутри, напротив» и т. Д.

Это очень сложная проблема, и я согласен, Солт-Лейк-Сити - сука. В дополнение к формату двойного направления / координат, они также дополняют его, ссылаясь на такие вещи, как "

Это действительно работает очень хорошо, за исключением того, что не извлекает номера квартир. Мы над этим работаем. Он также немного кашлянул, когда у нас был адрес 769 Branch Ave. Конечно, «филиал» - это один из тех типов улиц, которые он ищет. Все восходит к тому, что наведение порядка из хаоса. Мы знаем, что тут и там он сломается.