我想这是一个多部分的问题。我正在建立一个会员网站，并希望帐户尽可能国际化。
在允许国际号码的表格上收集电话号码的最佳方法是什么？我不担心存储它们，只是收集和验证。我现在拥有的是一个带有国家列表的下拉列表，它将添加国家代码，然后是根据国家代码验证 us/can/uk 的号码本身，然后是扩展名。这些将作为字符串存储在 cc/number/ext 的 3 个字段中 有没有人对此有更好、更可靠的解决方案，或者可能在任何地方都看到过这种解决方案？
地址同上。最好的方法是什么？地址/城市/州/邮编/国家或只是线路？我希望能够按这些排序，因此单个文本字段不是一个很好的解决方案，尽管它是最灵活的。
这也很重要，因为我们可能会向我们的会员发送实际邮件。我想起了我在其他服务中拥有的一些成员，这些成员的地址位于我从未听说过的国家/地区，即使是邮局的女士也无法判断它们的格式是否正确。
我想在数据库中至少有国家/州的地理数据，例如在选择国家、字段标准化等后填充州下拉列表。有谁知道可以用作应用程序地理数据库的优秀数据库?
电话号码验证 - 我不确定我是否会花很多时间在这上面。编号方案经常更改（例如，在我住在英国期间，伦敦区号的电话号码至少更改了一次，在我搬到那里之前不久又更改了一次），而在德国（或至少习惯于是）通过获取旧号码并在末尾添加一两个额外数字来增加给定交换中可用电话号码的数量是很常见的。所以任何关于给定电话号码格式的假设都会改变，你最终会追赶上来。如果您坚持将电话号码拆分为国际/区号/主要号码，您可能会发现这是一种非常特定于国家/地区的信息表示方式，因此您 几乎每个国家和特定的验证规则都需要一个输入掩码。更不用说在像德国这样的地方，区号可以有两到四位数字等......
关于邮政地址，我最重要的建议是确保您可以接受非数字邮政/邮政编码，否则您将无法处理加拿大和英国（以及可能其他地方）的地址。这有点像我的爱好，因为我在其他国家/地区的网站上遇到了一些问题，这些网站根本拒绝让我输入非数字邮政编码，我不得不求助于传真我的地址信息，因为我无法填写在线申请表。在我的书中，如果你允许国际客户，那是不好的业力......
此外，假设地址的某些部分（例如州/县）存在并要求它们通常比它的价值更令人头疼。我很想提供标准门牌号+街道（将它们组合起来，不同的语言将门牌号放在不同的地方，所以恕我直言，将它们分开不是一个好主意，除非你知道如何正确地重新组合它们，而且有时你会以房屋名称而不是数字结尾），城镇和邮政编码，可能带有可选的县/州字段。如果您想对您的国际受众真正有帮助，请为那些不符合我们对地址外观的“标准”假设的地址提供一个自由格式的单一文本输入字段。并且请让它们足够大，这样地址很长的人就不会用完空间......
电话号码有一个国际标准，但它留下了很大的喘息空间。分隔符不是强制性的，但仅限于空格、句点和连字符。圆括号（又名括号）将放在可选的数字周围，具体取决于您拨号的位置。例如，区号在某些地区是可选的。我会提供一个文本字段，让用户输入他们想要的号码。
对于地址，提供很多字段，不要限制太多。门牌号码有时包含字母。道路类型有时是完整的，有时是缩写的。（St = Street，Ave = Avenue 等）我会在可能的情况下提供下拉菜单（州/省），但当您没有列表时允许自由输入。当用户输入他们的地址时，可以验证安全风险，但您可能希望稍后再进行地理验证。例如，如果用户输入邮政编码 T8N 4E3 并选择安大略省作为他们的省份，则地址无效，因为给定的邮政编码是阿尔伯塔省的。向用户显示一条友好的消息，让他们知道他们需要更正他们的地址或在正确时与您联系（您的代码中可能存在错误）。
地址 - 记住不要到处都有州和邮政编码。如果你有邮政编码，它们可以是不同的格式（[0-9]{2}-[0-9]{3}这里）。（编辑：通常邮政地址有 2 个地址行，城市、州（可选）、邮政编码（可选）和国家/地区都可以）。
地理数据也是如此 - 您可以按州和城市进行连续下拉，但猜测您不会覆盖每个城市。为什么不显示一张谷歌地图，让用户点击那里标记他们的位置？