未被正则表达式捕获的行
Rows not being caught by regular expression
我在 TOAD V10.6 中编写我的 PL SQL 代码，然后 运行 在 Oracle 服务器上，我相信是 11g。
因为我正在处理客户广告信息，所以我实际上 post 无法得到任何结果。
我的程序的目标是将地址数据解析为正确的字段。谢天谢地，它不是整个地址。它包含的信息片段是建筑物编号、街道名称、街道类型、方向和子单元。信息并不总是在同一个演示文稿中，我按照解析信息的顺序解决了这个问题。
我解析地址字段的方式
- 我将地址数据加载到一个新的 table
- 我删除了重复的行
- 我将关键广告模式标记为错误（例如字段不足，因为地址至少需要 3 个才能有效）
- 我提取了可以出现在广告中任何地方的子单元
- 我提取了adrs中任何地方都可以出现的方向
- 我提取了楼号并确保它只有数字
- 我检查一下公寓楼号上是否有连字符
- 我检查以确保仍有足够的信息用于有效地址，因为我仍然需要街道类型和名称
- 我提取街道类型
- 剩下的就是街道名称
我有 27,000 个正在被正确解析，大约 3000 个包含错误并被排除在外，还有 2200 个没有正确处理但没有触发任何错误，这是倒数第二步。
UPDATE TEMP_PARSE_EXIST
SET V_STREET_TYPE = REGEXP_SUBSTR(ADRS, '\w+.$')
WHERE ADT_ACT IS NULL;
UPDATE TEMP_PARSE_EXIST
SET ADT_ACT = 'EMPTY STREET TYPE'
WHERE V_STREET_TYPE IS NULL AND ADT_ACT IS NULL;
我之前在解析子单元时遇到了几乎相同的问题。我从来没有弄清楚是什么原因造成的，也不知道为什么将正则表达式从 where 子句移动到不同的部分可以纠正它。
UPDATE TEMP_PARSE_EXIST
SET ADT_ACT = 'PARSE ERROR: TOO MANY S_COM_RES_TYPE '
WHERE ADT_ACT IS NULL AND V_SECOND_LINE IS NULL
AND REGEXP_COUNT(ADRS, '\s' || S_COM_RES_TYPE || '.+\s.+' || S_COM_RES_TYPE , 1, 'i') > 1;
--this looks for a space before and after the sub-unit, then anything between another example
--the space before and after are to prevent STE and FL from being matched with valid street names
--the second one is less strict about that
--if there starts to be an issue then a space before can be added
--however, adding a space after would having it miss cases where there is no space after for the unit number
--the block of code below is suspected of being where the error is happening
--the error in question is where suite is not being noticed and extracted from the adrs line
--however there are many more similar examples being correctly handled
UPDATE TEMP_PARSE_EXIST
SET V_SECOND_LINE = REGEXP_SUBSTR(ADRS, S_COM_RES_TYPE || '(\s?\w+|$)', 1, 1, 'i')
--'(\s\w+|$)' was the original expression, but the ? was added in to account for there not being a space
--so the pattern grabs the sub-unit, and allows for a possible space between it and the number, or allows the end of string as there are some cases of that
WHERE ADT_ACT IS NULL AND V_SECOND_LINE IS NULL AND REGEXP_COUNT(ADRS, S_COM_RES_TYPE, 1, 'i') = 1;
--this removes v_second_line from the adrs
UPDATE TEMP_PARSE_EXIST
SET ADRS = TRIMMER(REPLACE(ADRS, V_SECOND_LINE))
WHERE V_SECOND_LINE IS NOT NULL;
下面的代码没有和上面一样的错误
UPDATE TEMP_PARSE_EXIST
SET ADT_ACT = 'PARSE ERROR: TOO MANY S_COM_RES_TYPE '
WHERE REGEXP_like(adrs, '\s' || S_COM_RES_TYPE || '\s(|.+)' || S_COM_RES_TYPE , 'i');
--this looks for a space before and after the sub-unit, then anything between another example
--the space before and after are to prevent STE and FL from being matched with valid street names
--which is a common issue if I am not so strict about it
UPDATE TEMP_PARSE_EXIST
SET V_SECOND_LINE = trimmer(REGEXP_substr(adrs, '\s' || S_COM_RES_TYPE || '\s\w+',1,1 ,'i'))
WHERE ADT_ACT IS NULL AND V_SECOND_LINE IS NULL;
--this removes v_second_line from the adrs, this is done for both parts
UPDATE TEMP_PARSE_EXIST
SET ADRS = TRIMMER(REPLACE(ADRS, V_SECOND_LINE))
WHERE V_SECOND_LINE IS NOT NULL;
我还没弄明白为什么会这样。
我在我所在地区的一个不规则项目中，与我一起工作的人不需要使用正则表达式并且无法帮助我。
所以问题是，为什么有有效地址使其通过正则表达式？
更新：
以下是正确处理且所有部分都已成功解析的广告示例
Full example adrs Dirn Sub-unit number type name
100 Street1 Dr E E 100 Dr Street1
1000 1st Ave Suite 501 Suite 501 1000 Ave 1st
1000 100th St 1000 St 100th
1000 1st Ave N Unit 7 N Unit 7 1000 Ave 1st
以下是通过表达式
的示例
Full example adrs Dirn Sub-unit number type name
1000 1st Avenue E E 1000 1st Avenue
1000 Street1 Road 1000 Street1 Road
1000 Street2 Street 1000 Street2 Street
1000 Street3 Drive 1000 Street3 Drive
100 1st Avenue S Unit 100 S Unit 100 100 1st Avenue
上面列出的所有示例地址都是真实的（我更改了门牌号和名称）并且来自同一个数据集。没有遗漏额外的字符，例如空格或特殊字符。
Jorge Campos 是正确的，这是一个 XY 问题。
问题最终是我没有包含的一段代码，因为它太简单了我不认为它可能是原因。我有一个案例陈述，将街道类型的缩写更正为全名，没有其他陈述。所以当有一个正确的名字时，它被取消了，因为只有更正的陈述。
我在 TOAD V10.6 中编写我的 PL SQL 代码，然后 运行 在 Oracle 服务器上，我相信是 11g。
因为我正在处理客户广告信息，所以我实际上 post 无法得到任何结果。
我的程序的目标是将地址数据解析为正确的字段。谢天谢地，它不是整个地址。它包含的信息片段是建筑物编号、街道名称、街道类型、方向和子单元。信息并不总是在同一个演示文稿中，我按照解析信息的顺序解决了这个问题。
我解析地址字段的方式
- 我将地址数据加载到一个新的 table
- 我删除了重复的行
- 我将关键广告模式标记为错误（例如字段不足，因为地址至少需要 3 个才能有效）
- 我提取了可以出现在广告中任何地方的子单元
- 我提取了adrs中任何地方都可以出现的方向
- 我提取了楼号并确保它只有数字
- 我检查一下公寓楼号上是否有连字符
- 我检查以确保仍有足够的信息用于有效地址，因为我仍然需要街道类型和名称
- 我提取街道类型
- 剩下的就是街道名称
我有 27,000 个正在被正确解析，大约 3000 个包含错误并被排除在外，还有 2200 个没有正确处理但没有触发任何错误，这是倒数第二步。
UPDATE TEMP_PARSE_EXIST SET V_STREET_TYPE = REGEXP_SUBSTR(ADRS, '\w+.$') WHERE ADT_ACT IS NULL;
UPDATE TEMP_PARSE_EXIST
SET ADT_ACT = 'EMPTY STREET TYPE'
WHERE V_STREET_TYPE IS NULL AND ADT_ACT IS NULL;
我之前在解析子单元时遇到了几乎相同的问题。我从来没有弄清楚是什么原因造成的，也不知道为什么将正则表达式从 where 子句移动到不同的部分可以纠正它。
UPDATE TEMP_PARSE_EXIST
SET ADT_ACT = 'PARSE ERROR: TOO MANY S_COM_RES_TYPE '
WHERE ADT_ACT IS NULL AND V_SECOND_LINE IS NULL
AND REGEXP_COUNT(ADRS, '\s' || S_COM_RES_TYPE || '.+\s.+' || S_COM_RES_TYPE , 1, 'i') > 1;
--this looks for a space before and after the sub-unit, then anything between another example
--the space before and after are to prevent STE and FL from being matched with valid street names
--the second one is less strict about that
--if there starts to be an issue then a space before can be added
--however, adding a space after would having it miss cases where there is no space after for the unit number
--the block of code below is suspected of being where the error is happening
--the error in question is where suite is not being noticed and extracted from the adrs line
--however there are many more similar examples being correctly handled
UPDATE TEMP_PARSE_EXIST
SET V_SECOND_LINE = REGEXP_SUBSTR(ADRS, S_COM_RES_TYPE || '(\s?\w+|$)', 1, 1, 'i')
--'(\s\w+|$)' was the original expression, but the ? was added in to account for there not being a space
--so the pattern grabs the sub-unit, and allows for a possible space between it and the number, or allows the end of string as there are some cases of that
WHERE ADT_ACT IS NULL AND V_SECOND_LINE IS NULL AND REGEXP_COUNT(ADRS, S_COM_RES_TYPE, 1, 'i') = 1;
--this removes v_second_line from the adrs
UPDATE TEMP_PARSE_EXIST
SET ADRS = TRIMMER(REPLACE(ADRS, V_SECOND_LINE))
WHERE V_SECOND_LINE IS NOT NULL;
下面的代码没有和上面一样的错误
UPDATE TEMP_PARSE_EXIST
SET ADT_ACT = 'PARSE ERROR: TOO MANY S_COM_RES_TYPE '
WHERE REGEXP_like(adrs, '\s' || S_COM_RES_TYPE || '\s(|.+)' || S_COM_RES_TYPE , 'i');
--this looks for a space before and after the sub-unit, then anything between another example
--the space before and after are to prevent STE and FL from being matched with valid street names
--which is a common issue if I am not so strict about it
UPDATE TEMP_PARSE_EXIST
SET V_SECOND_LINE = trimmer(REGEXP_substr(adrs, '\s' || S_COM_RES_TYPE || '\s\w+',1,1 ,'i'))
WHERE ADT_ACT IS NULL AND V_SECOND_LINE IS NULL;
--this removes v_second_line from the adrs, this is done for both parts
UPDATE TEMP_PARSE_EXIST
SET ADRS = TRIMMER(REPLACE(ADRS, V_SECOND_LINE))
WHERE V_SECOND_LINE IS NOT NULL;
我还没弄明白为什么会这样。 我在我所在地区的一个不规则项目中，与我一起工作的人不需要使用正则表达式并且无法帮助我。
所以问题是，为什么有有效地址使其通过正则表达式？
更新： 以下是正确处理且所有部分都已成功解析的广告示例
Full example adrs Dirn Sub-unit number type name
100 Street1 Dr E E 100 Dr Street1
1000 1st Ave Suite 501 Suite 501 1000 Ave 1st
1000 100th St 1000 St 100th
1000 1st Ave N Unit 7 N Unit 7 1000 Ave 1st
以下是通过表达式
的示例Full example adrs Dirn Sub-unit number type name
1000 1st Avenue E E 1000 1st Avenue
1000 Street1 Road 1000 Street1 Road
1000 Street2 Street 1000 Street2 Street
1000 Street3 Drive 1000 Street3 Drive
100 1st Avenue S Unit 100 S Unit 100 100 1st Avenue
上面列出的所有示例地址都是真实的（我更改了门牌号和名称）并且来自同一个数据集。没有遗漏额外的字符，例如空格或特殊字符。
Jorge Campos 是正确的，这是一个 XY 问题。
问题最终是我没有包含的一段代码，因为它太简单了我不认为它可能是原因。我有一个案例陈述，将街道类型的缩写更正为全名，没有其他陈述。所以当有一个正确的名字时，它被取消了，因为只有更正的陈述。