国际电话和地址数据？
我想这是一个由多个部分组成的问题。 我正在建立一个会员网站，并希望帐户尽可能国际化。
在允许输入国际号码的表单上收集电话号码的最佳方式是什么？ 我不担心存储它们，只担心收集和验证。 我现在拥有的是一个包含国家/地区列表的下拉菜单，其中将添加国家/地区代码，然后是号码本身，并根据国家/地区代码对美国/加拿大/英国进行验证，然后是扩展名。 这些将作为字符串存储在 cc/number/ext 的 3 个字段中。是否有人对此有更好、可靠的解决方案，或者可能在任何地方看到过一个正在运行的解决方案？
地址也是如此。 最好的方法是什么？ 地址/城市/州/邮政编码/国家或只是行？ 我希望能够按这些进行排序，因此单个文本字段并不是一个很好的解决方案，尽管它是最灵活的。
这也很重要，因为我们可能会向我们的会员发送实际的邮件。 我想起了我在其他服务中遇到的一些会员，这些会员的地址位于我从未听说过的国家/地区，甚至邮局的女士也无法判断这些地址的格式是否正确。
我想在数据库中拥有地理数据，至少是国家/州，用于选择国家后填充州下拉列表、字段标准化等。有谁知道可以用作地理数据库的优秀数据库一个应用程序？
I guess this is a multi-part question. I am building a membership site and want to have the accounts as international as possible.
What is the best way to collect phone numbers on a form that allows for international numbers? I'm not worried about storing them, just collection and validation. What I have now is a drop down with a country list that will add the country code, and then the number itself with validation for us/can/uk based on the country code, and then the extension. These will be stored as strings in 3 fields for cc/number/ext Does anyone have a better, solid solution for this, or perhaps seen one in action anywhere?
Ditto for addresses. What is the best way to go? Address/City/State/Zip/Country or just lines? I would like to be able to sort by these, so a single text field isn't a very good solution, though it is the most flexible.
This is also important because we may be sending actual mail to our members. I am put in mind of a few members I've had for other services that had addresses in countries I had never heard of, that even the woman at the post office couldn't tell if they were formatted correctly.
I want to have geodata in the db, at least country/state, for things like populating a state dropdown after selecting a country, field standardization, etc. Does anyone know of a great database that can be used as the geodata base of an app?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
电话号码验证 - 我不确定是否会在这方面花费大量时间。 编号方案经常变化（例如，在我住在英国期间，伦敦区号的电话号码至少更改过一次，在我搬到那里之前不久又更改过一次），而在德国也是如此（或至少习惯于通过使用旧号码并在末尾添加一两个额外的数字来增加给定交换机上的可用电话号码数量是很常见的。 因此，关于给定电话号码格式的任何假设都将发生变化，您最终将迎头赶上。 如果您坚持将电话号码拆分为国际/区号/主号码，您可能会发现这是一种非常特定于国家/地区的信息表示方式，因此您几乎需要针对每个国家/地区和特定验证的输入掩码规则。 更不用说在像德国这样的地方，区号可以有两位到四位数字等...
关于邮政地址，我最重要的建议是确保您可以接受非数字邮政编码，否则您将无法处理加拿大和英国（可能还有其他地方）的地址。 这是我的一个爱好，因为我在其他国家/地区的网站上遇到了一些问题，这些网站只是拒绝让我输入非数字邮政编码，我不得不诉诸传真来传递我的地址信息，因为我无法填写在线申请表。 在我的书中，如果你允许国际客户，那是不好的业力......
此外，假设地址的某些部分（例如州/县）存在并要求它们通常比其价值更令人头痛。 我很想提供标准的门牌号+街道（将它们组合起来，不同的语言将门牌号放在不同的地方，因此将它们分开并不是一个好主意，恕我直言，除非您知道如何正确地重新组合它们，而且有时您会最后是房屋名称而不是数字）、城镇和邮政编码，可能还有可选的县/州字段。 如果您想真正为国际受众提供帮助，请为那些不符合我们对地址外观的“标准”假设的地址提供自由格式的单一文本输入字段。 并且请让它们足够大，这样地址很长的人就不会耗尽空间......
Phone number validation - I'm not sure if I'd spend a lot of time on this. Numbering schemes change quite often (for example, during the time I lived in the UK, the phone numbers for London area codes changed at least once, with another change shortly before I moved there) and in Germany it is (or at least used to be) quite common to increase the number of available phone numbers on a given exchange by taking an old number and tacking an extra digit or two at the end. So any assumption about a given phone number format will change and you'll end up playing catch-up. If you insist on splitting the phone number into international/area code/main number you'll probably find that this is a very country-specific way of representing the information so you'll need an input mask pretty much for every country and specific validation rules. Not to mention that in places like Germany, an area code can have between two and four digits etc...
Regarding postal addresses, the most important suggestion I have is to ensure that you can accept non-numeric post/zip codes, otherwise you won't be able to handle addresses in Canada and the UK (and possibly other places). This is a bit of a hobby horse of mine as I've had a few issues with websites in other countries that simply refused to let me put in a non-numeric post code and I had to resort to faxing over my address information as I couldn't fill in the online application form. In my book that's bad karma if you allow international customers....
Also, assuming the existence of certain parts of the address (state/county, for example) and requiring them is usually more of a headache than it's worth. I'd be tempted to offer the standard house number + street (combine them, different languages put the house number in different places so separating them out is not a good idea IMHO unless you know how to reassemble them correctly, plus sometimes you'll end up with a house name instead of a number), town and zip/post code, possibly with an optional county/state field. If you want to be really helpful to you international audience, offer a free-form, single text entry field for those addresses that don't conform to our "standard" assumptions of how an address looks. And please make them big enough so people with quite long addresses don't run out of space...
有一个电话号码国际标准，但它留下了很大的喘息空间。 分隔符不是强制性的，但仅限于空格、句点和连字符。 圆括号（又名圆括号）用于将数字括起来，这些数字是可选的，具体取决于您拨打的位置。 例如，在某些地区，区号是可选的。 我将提供一个文本字段，让用户根据需要输入号码。
对于地址，提供大量字段并且不要限制太多。 门牌号码有时包含字母。 道路类型有时会写完整，有时会写缩写。 （St = 街道，Ave = 大道等）我会在可能的情况下提供下拉菜单（州/省），但当您没有列表时允许自由格式输入。 当用户输入他们的地址时，可以验证安全风险，但您可能希望将地理验证留到以后进行。 例如，如果用户输入邮政编码 T8N 4E3 并选择安大略省作为其省份，则该地址无效，因为给定的邮政编码适用于艾伯塔省。 向用户显示友好消息，让他们知道他们需要更正地址，或者如果地址正确则与您联系（代码中可能存在错误）。
There is an international standard for telephone numbers, but it leaves a lot of breathing room. Separators are not mandatory, but are restricted to space, period, and hyphen. Round brackets (aka parentheses) are to be put around digits which are optional depending on where you are dialling from. For example, the area code is optional in some areas. I would provide a text field and let the user enter their number however they want.
For addresses, provide lots of fields and don't restrict too much. House numbers sometimes contain letters. Road types are sometimes written in full, and other times abbreviated. (St = Street, Ave = Avenue, etc.) I would provide drop-downs where possible (state/province), but allow freeform input when you don't have a list. When the user is entering their address, it's ok to validate for security risks, but you might want to leave geographical validation until later. For example, if the user enters a postal code of T8N 4E3 and selects Ontario as their province, the address is not valid because the given postal code is for Alberta. Display a friendly message to the user letting them know that they need to correct their address or contact you if it's correct (possible bug in your code).
地址 - 只是记住不是所有有州和邮政编码的地方。 如果您有邮政编码，它们可能采用不同的格式（此处为
[0-9]{2}-[0-9]{3}）。 （编辑：通常邮政地址有 2 行地址，城市、州（可选）、邮政编码（可选）和国家/地区即可）。地理数据也是如此 - 您可以对州和城市进行连续下拉，但我猜您不会覆盖每个城市。 为什么不显示一张谷歌地图并允许用户点击那里来标记他们的位置呢？
Address - just remember not everywhere you got states and ZIP codes. and if you got ZIP codes they can be in diffrent format (
[0-9]{2}-[0-9]{3}here). (edit: usually postal address with 2 address lines, city, state (optional), zip code (optional) and country is ok).So is with geodata - you can make sequential dropdowns with states and cities but guess you won't cover every city. Why not show a piece of google maps and allow the users to click there to mark their position?