我的桌面C#应用程序获取各种文件从用户,可能在不同的编码。内部编码
我需要向用户展示现有的文件,允许操纵他们在我的UI,并将其存储以备将来使用。
添加“编码”到每一个步骤的概念看似复杂我。我正在考虑在内部始终将用户输入文档转换为UTF-8,因此我的UI和数据存储不需要担心。然后,当用户希望将文档作为文件返回时,我会询问用户使用哪种编码。
这是否有意义?编码是否可以互操作?如果我只支持unicode怎么办?
我的桌面C#应用程序获取各种文件从用户,可能在不同的编码。内部编码
我需要向用户展示现有的文件,允许操纵他们在我的UI,并将其存储以备将来使用。
添加“编码”到每一个步骤的概念看似复杂我。我正在考虑在内部始终将用户输入文档转换为UTF-8,因此我的UI和数据存储不需要担心。然后,当用户希望将文档作为文件返回时,我会询问用户使用哪种编码。
这是否有意义?编码是否可以互操作?如果我只支持unicode怎么办?
编码是不能互通的,因为有一些别人没有的字符。
Unicode的内部表示是因为它具有更广泛的字符集是一个好主意,但我的意见,将文档保存回原来的编码,如果添加的字符仍然在所述编码。如果没有,请提示用户保存在Unicode中以正确编码这些字符。
所以utf-8和utf-16可以互操作吗?假设我只关心unicode,我可以立即将每个输入文档转换为utf-8,并且我所有的内部UI控件和数据库都将使用它。然后,当用户想要导出时,我可以再次询问要使用哪种编码(或将来通过“原始编码”字段保存用户的一小部分工作)。这有意义吗? – 2011-06-06 15:31:11
但utf8和utf16是可互操作的。如果您将文档转换为unicode,这意味着您知道它们的编码,所以可以将它保存在“原始编码”字段中。 – CharlesB 2011-06-06 15:34:17
“可互操作”并不完全正确,因为需要进行明确的转换。但它们都是可循环的,因为每个有效的UTF-8流都可以转换为UTF-16并返回而不会丢失,反之亦然。 – 2014-01-15 13:34:14
在你的应用程序,你应该使用原生支持Unicode(什么平台用来存储Unicode)。在Windows和OS X上,这是一种UTF-16
,但在Linux上是UTF-8
。
当涉及到保存/加载文件或与外部系统进行沟通,去UTF-8
。
此外,不要混淆代码页与编码。
关于代码页,今天我想是不是那么重要,以支持他们了。至少它不应该是你的优先事项。因为对于ANSI编码,您没有BOM,所以很难猜测文件的编码(实际上不可能完美)。
刚刚解码所有文件String
。 .Net中的字符串始终是Unicode(utf-16)。只有在阅读或写入文件时才使用编码。
当你转换为Unicode前,可让你应该知道ANSI代码页的文件。 G。创建一个utf-16字符串,否则从128到255的字节可能导致错误的unicode码点。当您想将unicode字符串存储到ANSI文件时,您可能会遇到麻烦,因为高达0x10ffff的代码不能放入单个字节。
只有两个原因中的交换格式(也就是一个被从A发送到B)曾经使用UTF-16:
除非这种情况下,只有两个原因,曾经使用以外的任何其他UTF-8的交换格式:
如果你特别讨厌外国人和不使用自己的语言的人,但是如果你一般只是讨厌别人,那么你会对足够多的人产生足够的头痛以至于你应该找到锻炼令人满意的。
现在,如果由其他人设计的给定文档格式允许使用UTF-8,并且您可以期望处理它的所有现代软件都能够处理UTF-8,那么有两个原因请执行以下操作:
对于您的内部存储,这只是一个对您最有用的问题。作为一项规则,.NET往往当内存(焦炭和串与工作)和UTF-8写入和读取的字符串时,默认为UTF-16。如果你的后备存储是SQL Server,然后UTF-16是你的朋友(的“NCHAR”,“nvarchar的”,“焦”,“VARCHAR”,“文本”,以避免出现问题如果字符集显的“NTEXT”变种设置为UTF-8以外的任何其他数据库),其他数据库或者有自己的处理现代字符的方式,或者可以使用UTF-8。
虽然在一般,使用UTF-8,除非有人强逼你不这样做(因为他们要么被迫从上世纪90年代应对代码或更早版本,或者是因为他们讨厌的人)。
utf8everywhere.org。没有什么可以说关于编码。 – 2012-09-08 23:17:07