程序员为什么会忽略ISO标准？[关闭]

我经常遇到的一件事是由不符合ISO标准的程序引起的问题。

一个示例不是使用ISO国家/地区表，而是自己编写简写，这对于美国（US）或荷兰（NL）来说还可以，但对于英国（GB，而不是英国）或西班牙来说则明显错误（ES，而不是SP）和许多其他国家/地区。

另一个示例是内部日期符号。为什么会有人将日期存储为01/02/2014？目前尚不清楚是2月1日还是1月2日，而如果使用ISO标准，则只存储2014-02-01 *，而2月1日则是明确的。

我的问题：有ISO标准可用时，程序员什么时候以及为什么要自己构造结构？

_{*存储2014-02-01，并在将其显示给最终用户时相应地格式化日期。}

切勿将愚蠢充分解释为恶意。- 罗伯特J汉隆。

那，并且缺乏沟通。

因此，这不是反ISO情绪的阴谋，使人们认为“我知道，我会用英国代替GB”，也不是说“他们知道得更多”，甚至不是说该标准不好的感觉。 。这完全是因为他们只是不知道它在那里，所以他们应该使用它。

我的意思是，对于某些人来说，如果未将其捆绑到Visual Studio中，则它也可能不存在。对于另一些人，也许他们只是不想要完整的清单，或者获取最终清单太困难了，所以他们只是组成自己的子集来解决当前情况。对于其他用户，默认使用的是默认格式-因此日期格式不是“采用ISO格式，甚至不是国家/地区语言环境设置”，而是“采用任何格式设置的格式”，如果适合他们，则工作就完成了（通常是对美国程序员的批评）。

当我使用Ruby编程时，我通常总是忽略ISO Ruby标准。为什么？因为这是难以置信的限制！ISO Ruby是Ruby 1.8和Ruby 1.9交集的最小子集。当前所有版本的Ruby（或至少即将推出）都支持Ruby 2.1，它具有许多使编程更容易的功能。使用ISO Ruby编程是一种PITA。

当我使用C＃编程时，我也忽略了ISO C＃，它是C＃2.0的子集（更重要的是，ISO类库是.NET BCL的一个很小的子集），而我却使用C＃5.0进行编程，不限制自己仅使用ISO CLI中指定的库，而是使用.NET 4.5.2和Mono 3.4.0中可用的库的公共子集。

同样，在进行网页设计时，我非常喜欢使用HTML5而不是ISO HTML（这是HTML 4.01 Strict的一小部分），因为HTML5比功能强大的旧版HTML子集具有更多的功能。

因此，有充分的理由忽略ISO标准。

根据您的示例，“ GB”是英国的国家/地区代码。但是，“ UK”曾经是MARC（美国国会图书馆）的标准代码，尽管我认为已经过时了。IANA .uk用于英国的顶级域名。

因此，如果某项不符合ISO标准，则并不意味着不使用任何标准。这可能仅表示正在使用其他标准。（正如@Jörg在评论中指出的那样，关于标准的好处是可以选择的标准太多。）在哪种情况下，问题实际上变成哪种标准最适合给定的问题领域，环境等。

对这个问题的回答可能很大程度上是基于观点的，很快就会演变成一场“宗教”辩论。但是，符合ISO标准不一定总是最好的答案。例如，如果某个软件需要与图书馆数据库接口，则MARC标准可能比ISO更合适。如果您组织的大多数软件都以某种方式执行操作，那么您可能要坚持使用这种方法，至少在短期内如此—毕竟这是组织的“标准”。

此外，标准的确会发展/变化。昨天的合规可能不是今天。

而且，尽管我不想排除无知和/或懒惰是导致您指出问题的原因……开发人员可能根本没有足够的时间来解决这些问题。

符合ISO标准并不总是一项免费活动。如果正在使用的工具包中尚未实现某个特定标准，那么程序员将面临一个必要的选择：现在正确实施该标准还是不实施该标准并稍后处理转换会更便宜？

说“嘿，您应该始终执行该标准”很容易，但是一切都有代价。程序员可能不想实施ISO标准有很多充分的理由。

• 客户可能遵循专有或非ISO标准。更好地满足客户期望的标准，而不是通过隐藏除了客户所需和您的语言要求之外的其他实现方式，为继任者带来意想不到的麻烦。
• 可能存在大量现有数据，并且转换或格式中断可能尚不可行。如果您有二十年的客户联系方式和以本地日期时间为键的合同，那么您不一定要将所有数亿个字段都更改为ISO标准日期，直到您正确地做。
• 遵守该标准可能会带来比提供的好处更大的成本。例如，如果您要处理完全在美国境内的条目，则五个字符的ISO-3166-2代码（US-NY）是标准美国邮政编码（NY）上不需要的三个字符。

对于没有经验的程序员/数据库设计师，这是因为不知道。他们倾向于重新发明轮子，因为他们不认识跨行业的一群人，他们已经讨论了这个问题，并提出了所有参加者都认可的标准，通常是经过很长时间的讨论，修订等。最近，一位同事当我告诉他关于某周是一年的最后一周还是次年的第一个星期时，我的一个人表现出一种怀疑的态度（ISO 8601）。他不相信针对如此具体的事物存在标准。我告诉他，许多应用程序的正确性取决于该标准。

对于经验丰富的程序员/数据库设计人员而言，它是由于“了解更好”，此处未发明的综合症和/或过分雄心引起的。他们不信任ISO或任何其他标准机构，因为他们认为ISO代码“不够稳定”，这意味着它有一天会发生变化。因此，他们创建了自己的，在此处发明的或自动递增的代码/标识符，从而阻碍了互操作性，他们也忽略了它们。看到这个类似的问题，高度数据库设计倾斜。他们给出如下原因：

我可能不一定希望我的数据库设计依赖于一堆第三方（IATA，ISO），无论它们的标准多么稳定。或者，我可能根本不想依赖特定的标准。

奇怪的是，那些不遵守标准的人使用标准USB端口，购买标准尺寸的DVD和BluRays，并使用符合标准的轮胎驾驶汽车。

嗯，人们倾向于忽略ISO标准：例如，您写了

如果您使用ISO标准，则只需存储20140201 *，就可以毫无疑问地存储在2月1日。

但实际上完全符合ISO8601标准的格式是2014-02-01。（另请参见xkcd 1179）

原因之一是应用程序域和用户可能自己未使用这些标准。即使某些领域使用某些标准，但出于历史原因，其中某些领域可能会做出与ISO标准不同的选择。

如果您的用户已经在其现有过程^（1）中使用“英国” 来指代“大不列颠及北爱尔兰联合王国”，则在其数据结构中使用“ GB”并不一定有意义（尤其是如果您表示按国家/地区划分的国家并不是完全“ ISO”国家/地区，例如将英国国家分开或与海峡群岛有细微差别等等。当然，您可以在内部存储和演示文稿之间建立映射，但是有时，它有点过头了。您很少出于编程的目的而进行编程，而通常必须适应您的环境。^（2）

您还必须记住，这些标准是与软件并行发展的。您通常必须在其他软件的上下文中进行开发，其中某些软件可能设计不完善，而某些软件仍可能受旧式决策的影响。

即使您查看内部数据存储格式，也很难解决一些歧义。例如，据我所知，Excel使用十进制数字表示时间戳：它使用整数作为自参考日期以来的天数，然后小数之后的数字表示24小时中的分数。 ..问题是，这使您无法考虑时区或夏时制（一天中的23h或25h），并且Excel默认会将任何日期/时间转换为该内部格式。如果您要使用的其他软件没有选择余地，则是否要使用ISO格式无关紧要。

_{（1）在这里我不是指“编程过程”。}

_{（2）不要问我为什么人们在日常生活中也不使用这些标准。我的意思是YYYYmmdd清晰，dd / mm / YYYY清晰，但是订购具有中，小，大粒度的日期（例如mm / dd / YYYY），这没有意义：-)。}

为什么我不使用ISO 3166-1 alpha-2国家/地区代码？

因为我使用的是STANAG 1059国家/地区代码，因此，英国是英国的代码（而不是根据ISO 3166-1的GB）。

另外，我可以使用FIPS国家代码-再次，英国是英国的国家代码。

有许多标准（ISO和非ISO），有时特定领域会使用/要求与ISO标准不兼容的标准。

存储20140201一点也不明确。仅当您包含遵循ISO标准的知识时，它才变得明确。2014年1月2日也是如此：当您包含格式为mm / dd / yyyy的知识时，它也是完全明确的。

只要该应用程序不必与其他应用程序接口，任何记录良好的标准都可以正常工作。

对于人类（我倾向于使用1-2-2014）和计算机（使用二进制表示法而不是ISO更好的计算机）之间存在权衡。新手程序员倾向于坚持他们容易理解的内容，更多的经验使程序员开始看到面向计算机的存储的优点。

到目前为止尚未提出的一点是国际标准的文化适用性。

考虑测量的国际标准。让我们向美国用户展示这些内容。我不确定您所有的美国用户是否会对公里，千克和升感到满意。

考虑到国际标准是政府制定的。如果西班牙政府选择不承认巴斯克语，那么它将如何获得ISO规范？边缘化群体的方言和克里奥尔语尤其如此。

甚至国家代码也可能会出现问题：克里米亚现在是否拥有自己的国家代码？最终会找到公式（例如，“前南斯拉夫的马其顿共和国”），但是您的申请可能需要一定的支持，直到外交或战争结束。

考虑到编写国际标准时要考虑到特定的应用。这些可能并不完全适合您的应用程序。例如，如果您存储语言以发送信件，那么您可能希望对盲人进行清晰编码，即使他们精通美国英语。统计机构充分意识到有必要指定变量的确切含义（又称变量的“元数据”），因为它们在人口普查期间遇到了每种可能的边缘情况。对于数据库字段而言，其中一些严格的条件非常值得。

最后一点是，在做出这些选择时，您的程序可能会做出政治声明。这种现实可能会干扰最好的代码（例如，对于一种语言，您可能需要多个语言名称）。

以我的经验，由于各种原因，程序员无法使用ISO标准，例如：

• “我不知道有ISO标准”（一旦被告知，这就是一个正当理由！）
• “无法访问该标准（找不到/ afford副本）”（真的吗？）
• “标准太严格了”（通常，如果标准说“不要”，那是有充分理由的。忽略它会对您和您的客户造成危险！）
• “该标准不包含最新的功能/库”（任何标准都不包含您将要使用的每个库，因此请遵守该标准中包含/覆盖的所有事物，并与该事物的标准保持一致它没有）
• “该标准难以实施”（过度使用的借口，但请参见下文）

我从我的工作人员那里接受的唯一理由不是“ me脚的借口”，这是“标准确实不是一个很好的'合适'”-有证据支持。有时，适用的ISO标准的复杂性与问题/解决方案不成比例。有时，您将要实现解决方案的环境与标准所假定的环境大不相同。有时可以改进标准-这就是进展的方式。

通常，未能使用ISO标准的原因可能是缺乏经验，懒惰或自大。我很遗憾地说，说英语的程序员在国际化方面特别懒惰，我们的美国同事倾向于将ISO视为“无关紧要的欧洲事情”（对对此不适用的少数人表示歉意）。

ISO有很多标准。CCITT / ITU也是如此。这些标准中的一些是“理想的”标准，而另一些是最低要求的功能。经常不清楚哪个是哪个。

我记得在1980年代问过为什么某些设备供应商实施标准的一个子集，而其他供应商实施另一种子集。从那时起，通常是在某些工作奏效之前就制定了标准。而且，供应商经常故意选择不实施标准，以便他们妨碍互操作性，从而为他们带来优势。

这就是为什么我喜欢IETF RFC。直到有RFC的3个独立实现，它们才成为RFC。

如果要构建Oracle数据库，并且要存储日期，则将使用Oracle DATE数据类型。我不知道或不在乎Oracle是否符合ISO标准。这确实是我符合其他标准（Oracle标准）的一种情况，与ISO标准的差异不大。请参阅@David的回复。

在某些情况下，当我意识到自己设计的东西已经有了ISO标准时，退回和重新设计的成本本来是过高的，或者至少可以这样看。

在短期内，通过仔细研究现有标准，通过使用可用的标准或通过发明新的标准，可以产生更多的工作代码。当大规模集成需要互操作性时，就会出现不利的一面。这几乎总是在以后的项目中发生。