防止使用邮政信箱地址的最佳策略？
我有一个客户通过 UPS 运送，因此无法运送到邮政信箱。 我希望能够验证客户地址字段，以防止他们输入包含邮政信箱的地址。 最好将其实现为正则表达式，以便我可以使用客户端正则表达式验证控件 (ASP.NET)。
我意识到可能没有办法获得 100% 的检测率，我只是在寻找在大多数情况下都有效的方法。
I have a client which is shipping via UPS, and therefore cannot deliver to Post Office boxes. I would like to be able to validate customer address fields in order to prevent them from entering addresses which include a PO box. It would be best if this were implemented as a regex so that I could use a client-side regex validation control (ASP.NET).
I realize there's probably no way to get a 100% detection rate, I'm just looking for something that will work most of the time.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
UPS 还拥有可以集成的工具来执行此操作...这样您就可以准确验证地址，了解是否会发货、费用是多少、时间表等。我建议访问 UPS IT 解决方案页面以了解相关信息更多信息。
UPS also has tools that you can integrate to do this... that way you can verify an address exactly as to whether or not they will ship, what the cost would be, schedules, etc. I suggest visiting the UPS IT Solutions page for more information.
这应该可以帮助您开始。 测试地址字段是否与此正则表达式匹配。
翻译为英语：行的开头有一个 P，后跟一个可选的句点和空格，然后是一个 O，后跟一个可选的句点，然后是一个空格，然后是“Box”，然后是其他任何内容。
This should get you started. Test to see if the Address field matches this regex.
Translation to English: That's a P at the beginning of the line, followed by an optional period and space, followed by an O, followed by an optional period, followed by a space, followed by "Box", followed by anything else.
您最好在页面上放置免责声明，警告您无法运送到邮政信箱，而不是验证输入。
如果您确实创建了一个捕获大多数邮政信箱场景的正则表达式，那么它很有可能也会捕获您不想要的东西（即街道名称包含字母“p”“o”的客户）和“盒子”）
You might be better off putting a disclaimer on the page warning that you can not ship to post office boxes, opposed to validating the input.
More than likely if you do create a regex that catches most of the P.O. Box scenarios, there's a good chance it'll also catch things you weren't intending (i.e. a customer with a street name containing the letters 'p' 'o' and 'box')
不幸的是，UPS 的在线软件允许邮政信箱通过，但一旦进入运输通道就会被堵塞。
在我们的例子中，当我们试图优雅地阻止邮政信箱时，我们的购物车放弃率上升了。 我们发现，不去管它、接受销售、提请客户服务人员注意并让他们解决会更具成本效益。
当然，如果您的邮政信箱出现率很高，则情况可能不适合您。
Unfortunately, UPS's online software allows P.O. Boxes to go through, but will choke on them once they're in the shipping channel.
In our case, our cart abandonment rate went up when we tried to gracefully prevent P.O. Boxes. We found it much more cost effective to leave it alone, accept the sale, bring it to the attention of customer service, and let them resolve it.
Of course, if you get a high incidence of P.O Boxes, this may not be the case for you.
我将从正则表达式 ala Lizard 开始（但使用“忽略大小写”标志:)），测试历史数据，然后在测试中看到哪些无效包含和排除时进行迭代。
I'd start with a regex ala Lizard (but use the "ignore case" flag :)), test on historical data, then iterate as you see what invalid inclusions and exclusions you see in testing.
大多数运输提供商（例如 FedEx）都会验证送货地址。 例如，对于 FedEx Web 服务，需要调用来验证送货地址并获取估计费用。 这不仅确保该地址不是邮政信箱，而且还确保该地址的其余部分有效。
Most shipping providers (for example FedEx) will validate the shipping address. For example, with FedEx web services, there is a call to validate a shipping address and get the estimated cost. This not only ensures that the address is not a PO Box, but also makes sure that the rest of the address is valid.
关于OP对Jason Coco的回答的评论：
由于您可以将正则表达式验证添加到送货地址，所以我假设您拥有应用程序的控制权（即，您拥有源代码并且可以修改它）。 如果是这种情况，那么您应该能够在收到提交的数据后，检查是否通过 USPS、FedEx 或 UPS 运送，并向相应的托运人特定地址验证器提交请求，从而获得所有信息杰森的回答中建议的好处。
通过使其特定于托运人，这还可以让您避免实施一刀切的规则，例如“没有邮政信箱，因为 UPS 不会向他们送货”，即使用户可以选择非 UPS 托运人谁送货到邮政信箱。
Regarding the OP's comment to Jason Coco's answer:
Since you're in a position to add regex validation to the shipping address, I assume that you have control of the application (i.e., you have the source and can modify it). If that's the case, then you should have the ability to, on reciept of the submitted data, check whether it is to be shipped via USPS, FedEx, or UPS and submit a request to the appropriate shipper-specific address validator, gaining all the benefits suggested in Jason's answer.
By making it shipper-specific, this would also allow you to avoid implementing one-size-fits-all rules, such as "no PO boxes because UPS doesn't deliver to them", even though the user can select non-UPS shippers who do deliver to PO boxes.
如果不是以“PO Box..”或“PO Box”开头怎么办？
示例：
约翰·施密特 |
银谷邮政信箱 3901 |
凡斯瓦尔多维尔，SI。 78946
我对地址字段使用了 onblur 事件，以使用 javascript 函数 indexOf 来识别 input.toUpperCase "PO BOX" || “PO”即>= 0。
如果这两个搜索中的任何一个都没有找到，则返回-1，否则，它将返回字符串的起始位置，该位置始终为0或更大。
这将确保延迟输入、“邮政信箱”、“邮政信箱”以及“邮政信箱”都能被识别。 我想你可以添加“po”。 盒'也是如此。
无论如何，该条件会触发一条不显眼的消息，显示“我们无法运送到邮政信箱地址。”如果它不适用于您，则不会看到它。否则，对于没有 js 的用户或者启用了 css，他们只会看到该消息。这种优雅降级的唯一失败是用户启用了 css，但未启用 js（他们根本看不到该消息）。今天的解决方案，但如果我想到更好的方法，我会回来发布在这里。
What if it doesn't start with "PO Box.." or "P.O. Box" ?
Example:
John Schmidt |
Silver Valley PO Box 3901 |
Whereswaldoville, SI. 78946
I used an onblur event for the address field to use a javascript function, indexOf, to recognize the input.toUpperCase "PO BOX" || "P.O" that is >= 0.
If either of these two searches are not found, the return is -1, otherwise, it will return the string's start position which will always be 0 or more.
This will ensure that lazy typing, 'po box,' 'p.o box,' and as well as 'p.o. box' will be recognized. I suppose you could add 'po. box' as well.
Anyway, the condition triggers an unobtrusive message to show that 'We can't ship to a PO Box address." It's a feature to not see it if it doesn't apply to you. Otherwise, for users who don't have js or css enabled, they'll just see the message. The only fail on this graceful degradation is if a user has css, but not js enabled (where they just won't see the message at all). I only came up with the solution today, but if I think of a better way, I'll come back to post it here.