blocks|key|51416|text|我会说除了邮政编码和状态之外的所有内容--并且认为‘street_line_2’更像是postal+codes而不是邮政编码--正如你可以从基于原产国的各种格式中看出的那样，这应该有一个相当开放的格式。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|51417|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Postal_code^0|17|C|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

I would say everything except street_line_2 and state- and think of 'zip' as more of a <a href="http://en.wikipedia.org/wiki/Postal_code" rel="nofollow noreferrer">postal codes</a> instead of zip code - as you can tell from the variety of format based on the country of origin, this should have a pretty open format.

blocks|key|1455636|text|您可能只需要一个字段:+country。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1455637|但你真正应该做的是让逻辑依赖于国家。请查看Address+Formats+by+Country以获得全面的列表。这也不仅仅是关于必填字段。这也是关于正确的格式。美国地址可能是：|offset|length|1455638|主街8031号|1455639|Springfield+OH+12345|1455640|使用|1455641|而在瑞士：|1455642|Bodenstr.173|1455643|8043苏黎世|1455644|施韦兹|1455645|注：瑞士的街道号码和邮政编码的顺序是相反的(与英语国家使用的相反)。|style|BOLD|1455646|此外，您的数据类型需要足够广泛，以涵盖其他国家/地区使用的数据。邮政编码应该绝对为，而不是为数字类型。例如，"EC2R+8AH“是有效的英国邮政编码。|1455647|这又回到了这个原则:如果你不对它进行算术运算，它就不是数值类型。这是文本。|1455648|此外，尽量不要将其称为最终用户的邮政编码。这是美国独有的术语。几乎在其他任何地方它都叫邮政编码，邮政编码或邮政编码。另请注意，英国的邮政编码是字母数字的，并且包含一个空格。|1455649|entityMap|0|LINK|mutability|MUTABLE|url|http://www.addressdoctor.com/en/countries_data/addressformats.asp^0|0|L|Q|0|0|0|0|0|0|0|0|0|0|2|0|15|4|0|0|0^^$0|@$1|2|3|4|5|6|7|1B|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1C|8|@]|9|@$D|1D|E|1E|1|1F]]|A|$]]|$1|F|3|G|5|6|7|1G|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|1H|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|1I|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|1J|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|1K|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|1L|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|1M|8|@]|9|@]|A|$]]|$1|T|3|U|5|6|7|1N|8|@$D|1O|E|1P|V|W]]|9|@]|A|$]]|$1|X|3|Y|5|6|7|1Q|8|@$D|1R|E|1S|V|W]]|9|@]|A|$]]|$1|Z|3|10|5|6|7|1T|8|@]|9|@]|A|$]]|$1|11|3|12|5|6|7|1U|8|@]|9|@]|A|$]]|$1|13|3|-4|5|6|7|1V|8|@]|9|@]|A|$]]]|14|$15|$5|16|17|18|A|$19|1A]]]]

You can probably only require one field: country.

But what you should really be doing is making the logic dependent on country. Take a look at <a href="http://www.addressdoctor.com/en/countries_data/addressformats.asp" rel="noreferrer">Address Formats by Country</a> for a comprehensive list. That isn't just about required fields either. It's also about correct formatting. A US address might be:

8031 Main Street 
Springfield OH 12345 
USA

whereas in Switzerland:

Bodenstr. 173 
8043 Z&uuml;rich 
Schweiz

Note: the street numbers and post codes are in the "reverse" order for Switzerland (compared to what English speaking countries use).

Also, your data types need to be broad enough to cover data used in other countries. Zip/post code should absolutely not be a numeric type. For example, "EC2R 8AH" is a valid UK postcode.

That goes back to this principle: if you don't perform arithmetic on it, it's not a numeric type. It's text.

Also, try not to call it Zip Code to end users. That's a US only term. Pretty much everywhere else its call a Postcode, Post code or Postal Code. Also note that the UK postal codes are alphanumeric and include a space.

blocks|key|1591009|text|如果您不打算执行任何特定的查找，例如按邮政编码或按城市进行搜索，我会建议您将所有地址组合到一个字段中。这样，您就可以支持来自不同国家的不同地址。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1591010|您还将支持奇怪的地址。|1591011|如果您担心需求会发生变化，那么可以将地址存储为Xml字段。现代数据库，如Sql+Server2005和2008，只要使用模式，就可以在Xml列中的Xml节点上建立索引。|1591012|这一切都可以归结为需求。如果客户端需要按国家对网格中的数据进行分组，那么您需要一个国家列。|1591013|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

If you are not going to do any specific lookup, like searching by postal code or by city, I'd say to all combine the address in a single field. This way you will support the different address from different countries.

You will also support address oddities.

If you fear that the requirements are going to change, you could store the address as a Xml field. Modern database like Sql Server 2005 and 2008 can have an index on a Xml node inside a Xml column as long as you are using a schema.

It all come down to requirements. If the client need to group the data inside a grid by country, then you need a country column.

blocks|key|291326|text|新西兰没有州，所以它绝对应该是可选的。所以我认为你的问题有正确的答案。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|291327|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

There are no states in New Zealand, so it should definately be optional. So I think you have the right answer in your question.

blocks|key|51578|text|并非所有国家都使用邮政编码，例如，在2006年左右之前，新西兰很少使用邮政编码。我认为爱尔兰根本不使用它们。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|51579|如果你是真正国际化的人，像新加坡这样的城市国家实际上不需要City字段。|51580|在用户界面中，您可以(也许应该)为您已经知道需要邮政编码的国家/地区设置邮政编码，因为这不太可能改变。而且，如果您的UI足够动态，如果选择的国家是美国，则可以将其称为“邮政编码”，对于加拿大，可以称为“邮政编码”，对于英国，可以称为“邮政编码”，等等。|51581|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Not all countries even use postal codes, for example they were rarely used in New Zealand prior to 2006 or so. I think Ireland doesn't use them at all.

If you're truly international, city-states such as Singapore don't actually need a City field.

In the user interface, you can (and perhaps should) make the postcode required for countries where you already know it's required, since that isn't likely to change. And, if you make the UI dynamic enough, you can call it "Zip code" if the selected country is the United States, "Postal code" for Canada, "Postcode" for the UK, etc.

blocks|key|291361|text|什么都不做呢？如果用户想要联系他们，他们会输入足够的信息。或者，输入单个文本字段并让他们输入自由格式的信息。他们比您更清楚邮递需要哪些字段才能送到他们的门口。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|291362|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

How about making none required? If the user wants to be contacted they'll enter enough information. Or, enter a single text field and let them enter free form information. They know better than you what fields are required for postal deliveries to make it to their door.

blocks|key|1455831|text|即使在美国，大多数地址也不是必需的。美国有很大一部分邮政编码被分配给不同的企业和组织--任何寄往这些邮政编码之一的邮件都将以相同的方式递送，而不管地址的其余部分是什么。例如：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1455832|通用电气|1455833|纽约州Schenectady，邮编:+12345|1455834|美国国税局|1455835|德克萨斯州奥格登，邮编:+84201-0027|1455836|城市和州很好，但邮件可能会在没有邮局的情况下送达。|1455837|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|P|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Q|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|R|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|S|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|M|$]]

Even in the U.S., most of the address is not required. A large fraction of U.S. zip codes are allocated to various businesses and organizations - any mail to one of those zips will be delivered the same regardless of the rest of the address. For instance:

General Electric 
Schenectady, NY 12345

Internal Revenue Service 
Ogden, UT 84201-0027

The city and state are nice, but the mail will probably get delivered without.

blocks|key|51686|text|我发现解决这个问题的最好方法是在应用程序层而不是持久层中抽象逻辑。我见过的最干净/最简单的方法之一是将值对象中的用户数据(创建一个易于验证的公共接口)传递给具有当前国家代码的验证器，这将确保在该地区的值对象中正确设置所有必需的属性。假设它通过了验证，将值对象传递到应用程序的持久化端进行存储。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|51687|这里的关键是值对象-您正在创建一个公共接口，您的应用程序的多个部分可以与之对话、验证和读取/写入。然后，您还可以在显示地址时使用相同的值对象:让持久层获取信息，将其放在值对象中，将其传递给具有当前区域设置的工厂，该工厂返回所需的地址格式，并将输出发送到前端。|51688|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

The best way that I have found to solve this problem is by abstracting the logic in your application layer, and not the persistence layer. One of the cleanest/simplest ways I've seen this done is by passing the user's data in a value object (creating a common interface that's easy to validate against) to a validator with the current country code, which makes sure all the required attributes are set properly in the value object for that locale. Assuming it passes validation, pass the value object along to the persistence side of your application for storage.

The key here is the value object - you're creating a common interface that multiple pieces of your application can talk to, validate, and read/write from. You can then also use that same value object when displaying the address: have your persistence layer get the information, put it in the value object, pass it to a factory with the current locale which returns the desired address format, and send that output to the front end.

blocks|key|291417|text|创建必填字段始终是一种权衡。如果这个人不想填写信息，那么他们就不会--他们会填上句号，或者是垃圾信息，以越过“必填栏”保姆。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|291418|我只需要在我的应用程序中使用street_address_1。此外，对于美国和许多国家/地区，您可以购买邮政编码和标准城市/州之间的映射。它并不贵。(单个街道地址和邮政编码之间的映射要昂贵得多。)有关美国，请参阅http://www.usps.com/ncsc/addressinfo/citystate.htm|offset|length|291419|如果你包含一个Ajax网页界面，首先询问国家，然后是邮政编码。如果在美国，则使用Ajax从zip中获取并填充用户的城市/州。|291420|一些非美国国家，例如英国，如果你要求人们填写他们的“首选地址”，可以有3行街道地址，例如：|291421|Mirassou++++++++++(You+can+register+a+building's+name+with+the+post+office
High+Street++++++++as+an+alternative+to+its+street+number)
Old+Town
City,+Bucks+postal_code|code-block|syntax|javascript|291422|拉里|291423|entityMap|0|LINK|mutability|MUTABLE|url|http://www.usps.com/ncsc/addressinfo/citystate.htm^0|0|2Y|1E|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Z|8|@]|9|@$D|10|E|11|1|12]]|A|$]]|$1|F|3|G|5|6|7|13|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|14|8|@]|9|@]|A|$]]|$1|J|3|K|5|L|7|15|8|@]|9|@]|A|$M|N]]|$1|O|3|P|5|6|7|16|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|17|8|@]|9|@]|A|$]]]|R|$S|$5|T|U|V|A|$W|X]]]]

Making fields required is always a tradeoff. If the person doesn't want to fill in the info then they won't -- they'll put in a period, or garbage to get past the "required field" nanny. 

I only require street_address_1 in my apps. Also, for the US and many countries, you can buy the mapping between the postal/zip code and the canonical city/state. It's not expensive. (The mapping between individual street addresses and zip is much more expensive.)
For the US, see <a href="http://www.usps.com/ncsc/addressinfo/citystate.htm" rel="nofollow noreferrer">http://www.usps.com/ncsc/addressinfo/citystate.htm</a>

If you're including an Ajax web interface, ask for the country first, then the post code. If in the US, then use Ajax to fetch and fill in the city/state for the user from the zip.

Some non-US countries, eg UK, can have 3 lines of street addresses if you're asking people to fill in their "preferred address" Eg:

<pre><code>Mirassou (You can register a building's name with the post office
High Street as an alternative to its street number)
Old Town
City, Bucks postal_code
</code></pre>

Larry

blocks|key|1591165|text|实际上，在美国，城市甚至不是必需的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1591166|许多人在州和县的公路上有农村地址。邮政服务网站上的出版物28有详细信息。不同的公司最终使用“城市”字段来存储其他信息。这也适用于军事基地地址。|1591167|Publication+28+link|offset|length|1591168|entityMap|0|LINK|mutability|MUTABLE|url|http://pe.usps.com/text/pub28/welcome.htm^0|0|0|0|J|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@$F|S|G|T|1|U]]|A|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]]]

Actually, city isn't even required in the US.

Many people have rural addresses on state and county roads. Publication 28 at the postal service web site has details. Different companies end up using the "city" field to store other information. This also applies to military base addresses.

<a href="http://pe.usps.com/text/pub28/welcome.htm" rel="nofollow noreferrer">Publication 28 link</a>

Say I am storing addresses in a DB table, in this fairly common break down:

<pre><code>address_street_line_1,
address_street_line_2,
address_city,
address_state,
address_zip,
address_country_id
</code></pre>

(Note: I have read the questions on splitting down further, street type, house number, etc. and for this application I think it would unnecessarily complicate things.)

To work best with international users, which of these fields should NOT be required?

I'm thinking this:

<pre><code>address_street_line_1 REQUIRED
address_city REQUIRED
address_country_id REQUIRED
</code></pre>

Should I require state or zip?

Thanks!
Xavier

Which parts of an address should be required?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

假设我将地址存储在一个DB表中，这是一个相当常见的分解：address_street_line_1,address_street_line_2,address_city,address_state,address_zip,address_country_id(注意:我已经阅读了关于进一步拆分、街道类型、门牌号等的问题，...

问地址的哪些部分应该是必填项？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问地址的哪些部分应该是必填项？EN