.net 全球化在国际和英语系统上的可靠性
我有一个应用程序在安装了国际 Windows XP 的客户处运行，该客户向我报告，一些客户无法使用其国家/地区日期分隔符 (.) 输入日期。系统配置正确。我的应用程序从 System.Globalization.DateTimeFormatInfo.CurrentInfo.DateSeparator 获取分隔符。 .net的版本是3.5SP1。
我观察到的另一个问题是在向另一位客户演示我的另一个应用程序时。应用程序在应用程序运行时更改了日期输出格式。在大约 1.5 小时的演示后，它不再显示 dd.mm.yyyy，而是更改为美国格式 mm/dd/yyyy。因为是在演示过程中，所以我看不到问题出在哪里。我只重新启动了应用程序，一切又恢复正常了。演示笔记本电脑上的操作系统是 W7 en。这里我使用DateTime.ToShortDateString。
我的问题是，其他程序员是否也遇到了国际系统全球化方面的此类模糊问题，如果是，是否有一些该做和不该做的事情。或者是否有一个我不知道的键盘快捷键可以更改区域设置（不是键盘布局，我知道这个）。
I have an app runing at a customer with international windows xp installations and the client reported to me that a few clients can not enter dates with their countries date-separator (.). The system is configured correctly. My app takes the separator from System.Globalization.DateTimeFormatInfo.CurrentInfo.DateSeparator. The version of .net is 3.5SP1.
Another issue that I have observed was during a presentation of another app of mine for another customer. The app changed the date output format during app runtime. Instead of showing dd.mm.yyyy, it changed to the us format mm/dd/yyyy after approximatively 1.5 hour of presentation. Because it was during presentation, I could not look what the problem was. I only restarted the app and all was fine again. The os on the presentation laptop was W7 en. Here I use DateTime.ToShortDateString.
My question is if, if also other programmers experiencing such obscure issues with globalization on international systems and if yes, if there are some does and donts. Or is there maybe a keyboard shortcut I'm not aware about, that changes the regional settings (not the keyboard layout, this one I'm aware about).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
永远不要依赖最终环境以及安装配置来解决此类问题。 100% 确保正确的全球化（以及本地化）的最佳方法是将所有检查放在代码本身中。当我知道我的应用程序将在不同的区域设置中使用时，我通过代码显式获取/设置当前的文化信息。此外，几乎所有常见类型（如数字、日期时间等）的解析方法都有一个重载，可让您在解析特定于区域性的数据时指定要使用的区域性信息。你能确保这一点吗？
最后但并非最不重要的一点是，请确保您的数据库服务器以及 sps 已正确配置和编码，以便在不同区域设置中输入数据。例如，sql server 有很多用于日期时间解析/保存的选项（包括 ISO 标准）。 sql server 2008 也为同样的目的为您提供了更简单、更好的选项
，日期时间的黄金法则是始终以 UTC 格式保存它们，但根据当前时区/区域设置格式显示它们。程序员犯的一个非常常见的错误是不在数据库中以 UTC / GMT 格式保存日期时间信息。例如：他们不保存 DateTime.UTCNow，而是保存 DateTime.Now。当应用程序处理多种文化/语言环境/时区时，我已经看到花费了几天甚至几周的时间来尝试找出此类错误/问题。处理数字时也是如此。例如：以多个国家和货币进行销售的电子商务网站上商品的价格
never ever rely on the final environment as well as configuration of installations for such issues. the best way to be 100% sure of the correct globalization (as well as localization) is to put all the checks in the code itself. when i know my app is going to be used in different locales, i explicitly get / set the current culture info via code. also, almost every parse method on common types (like numbers, datetime, etc) has an overload which lets you specify the culture info to be used while parsing culture specific data. are you ensuring this?
last but not the least, make sure your db server AS WELL AS your sps are correctly configured and coded for data input in different locales. for eg, sql server has plenty of options (including ISO standards) for date-time parsing / saving. sql server 2008 offers you much easier and better options for the same purpose
also, the golden rule with datetime is to ALWAYS SAVE THEM in UTC but display them based on current timezone / locale format. one very common mistake programmers make is to NOT save datetime info in UTC / GMT format in the db. for eg: instead of saving DateTime.UTCNow, they save DateTime.Now. i have seen days if not weeks spent on trying to figure out such bugs / issues when an app deals with multiple cultures / locales / timezones. and ditto while dealing with numbers. for eg: price of an item on an ecommerce site which deals which sells in multiple countries and currencies
以下答案包含有关如何使用 CultureInfo 类的宝贵指示：
如何在WinForm应用程序中尊重/继承用户的语言设置？
The following answer contains valuable pointers on how the CultureInfo class can be utilized:
How to honor/inherit user's language settings in WinForm app?