我设法忽略了所有这些多字节字符的东西,但现在我需要做一些UI工作,我知道我在这方面的无知将赶上我!任何人都可以在几段或更少的段落中解释我需要知道什么,以便我可以本地化我的应用程序？我应该使用什么类型(我同时使用.Net和C/C++,我需要Unix和Windows的答案).
有没有理由为什么Java char原始数据类型是2字节不像C这是1字节？
谢谢
今天我醒来后觉得我的代码和我用过的每个图书馆都出现了严重问题,我认为我是对的......(或者请指出我的推理错误的地方)
让我们回到过去十年或者两年,一切都在世界上很好.我跟我的邻居说话,他讲的是同一种语言:只是简单的英语.对我来说,我的邻居和Windows似乎很明显将我们的字符串存储在8位chars中,因为我们使用的所有字符都可以存储在2 ^ 8 = 256种可用组合中.
然后奇迹般的互联网出现了,并允许我与欧洲的一些朋友(他们没有时间学习英语)交谈.这很难用我们的char格式,使用的字符数量很容易超过256,所以在我们完全简单的视觉中我们决定使用16位wchar_ts.称为UCS-2 unicode的东西.它有2 ^ 16 = 65.536种可用组合,对于世界上的每种语言都必须足够!相信我们的正确性,我们甚至还添加了16位的Windows API的W功能,如MessageBoxW和CreateWindowW.我们说服了每个程序员我们的宗教,并且不鼓励使用邪恶的8位对应物(MessageBoxA和CreateWindowA)并通过在我们的构建中定义来MessageBox自动映射调用.因此我们也应该使用函数而不是旧函数(例如,现在应该使用,或者使用自动映射).MessageBoxW_UNICODEwcsstrstrlenwcslen_tcslen
然后事情变得糟糕,事实证明世界上还有其他人使用甚至比我们更怪异的字形(没有冒犯):日本人,中国人等等.它变坏了,因为例如中国人有超过70,000个不同的字符.发生了很多咒骂,给我们留下了一种新型的unicode:UTF-16.它还使用16位数据类型,但某些字符需要两个16位值(称为代理对).这意味着我们不能在这些16位字符串上使用索引(例如,theString [4]可能不会返回第5个字符).为了修补Windows API,决定所有W函数现在应该支持UTF-16格式,这是一个简单的决定,因为所有旧的UCS-2字符串也是有效的UTF-16字符串.但是,因为我们是勇敢的程序员,所以我们现在使用这些wcs功能.遗憾的是,这些功能不具有代理意识,仍然符合UCS-2格式......
与此同时,在一个黑暗的阁楼里,开发了另一种更紧凑的unicode形式:UTF-8.使用8位数据类型,大多数西方语言可以存储在一个8位值中,就像过去一样.当存储更奇特的字形时,使用多个8位值,对于大多数欧洲语言2就足够了.但是,它可能会扩展其中4个值,实质上是创建32位存储类型.就像它的胖兄弟UTF-16一样,我们不能在这些字符串上使用索引.由于它更紧凑的格式,UTF-8现在在互联网上的各个地方广泛使用,因为它节省了带宽.
很好,你是通过我冗长的写作来实现的:)现在我有一些问题/兴趣点:
好的,我对使用UTF-8进行存储非常满意.当我读取一个文件(来自磁盘或HTTP响应)时,我检测到UTF-8签名"\xEF\xBB\xBF"并将内容放在MultiByteToWideChar我的UTF-16字符串中.我可以使用WAPI函数,没问题.但是现在我想修改字符串,替换一些字符等.好的旧wcs函数不再好了,哪些核心字符串函数是UTF-16识别的？还是有一些出色的图书馆,我不知道吗？编辑:似乎ICU是一个非常好的解决方案.我还发现这些wcs函数并不是完全无用的,你可以用来wcsstr搜索,它基本上只是比较wchar_ts.唯一的问题是字符串的长度.
当我们被迫使用16位缺陷W函数时,你是否感觉到了一个丑陋的错误.难道问题不应该在更早的阶段得到认可,并且让所有原始API函数都采用UTF-8字符串并包含适当的字符串操作例程吗？或者这已经是可能的,我可怕的错了吗？编辑:也许这是一个愚蠢的问题,后见之明确实很精彩,现在没有人放下任何人;)
为了快速索引字符,我们应该以32位值存储字符串.这是常见的吗？(我可以听到你的想法:然后我们遇到了一种需要更多组合的外星语言,并且乐趣又重新开始...)这种方法的缺点似乎是我们应该每次将字符串转换回UTF-16我们进行Windows API调用.编辑:引用Alf P. Steinbach 每个指数一个角色是一个绝望的梦想,我现在看到了.我完全错过的一件事是变音符号.我也认为在OS的本机编码中处理是一件好事(对于Windows …
检查UTF-16和UTF-8的属性,我找不到任何理由更喜欢UTF-16.
但是,检查Java和C#,它看起来像字符串和字符默认为UTF-16.我认为这可能是出于历史原因,或者出于性能原因,但无法找到任何信息.
谁知道为什么这些语言选择了UTF-16？我也有正当理由这么做吗？
编辑:同时我也找到了这个答案,这似乎是相关的,并有一些有趣的链接.
utf16或utf32？我正在尝试以多种语言存储内容.某些语言使用双宽字体(例如,日语字体通常是英文字体的两倍).我不确定我应该使用哪种数据库.有关这四个字符集之间差异的任何信息......
所以我们有这个支持UTF8数据的网络应用程序.万岁UTF8.我们可以将用户提供的数据导出为CSV没问题 - 此时它仍然是UTF8.问题是当你在Excel中打开一个典型的UTF8 CSV时,它会将其读作ANSII编码文本,并因此尝试读取两个字节的字符,如ø和ü作为两个单独的字符,最终会失败.
所以我已经做了一些挖掘(Intervals人员在这里有一个有趣的帖子),并且有一些有限的,如果有可笑的烦人选择.其中:
看起来无论如何,我可能会继续为那些不使用它的人提供一个普通的CSV文件,以及一个单独的Excel下载选项.
生成那个能正确支持UTF8的Just-For-Excel文件的最简单方法是什么,亲爱的Stack Overflowers？如果最简单的选项仅支持最新版本的Excel,那仍然是有意义的.
我在Rails堆栈上执行此操作,但很奇怪.Net-ers和任何框架上的人员如何处理这个问题.我自己在几个不同的环境中工作,这绝对是一个将再次出现的问题.
更新2010-10-22:我们在时间跟踪系统Tempo中使用Ruport gem在我第一次发布此问题时提供CSV导出.我的一个同事Erik Hollensbee为Ruport提供了一个快速过滤器,为我们提供了实际的Excel XSL输出,我想我会在这里分享其他任何红宝石:
require 'rubygems'
require 'ruport'
require 'spreadsheet'
require 'stringio'
Spreadsheet.client_encoding = "UTF-8"
include Ruport::Data
class Ruport::Formatter::Excel < Ruport::Formatter
renders :excel, :for => Ruport::Controller::Table
def output
retval = StringIO.new
if options.workbook
book = options.workbook
else
book = Spreadsheet::Workbook.new
end
if options.worksheet_name
book_args = { :name => options.worksheet_name }
else
book_args = { }
end
sheet = …更新了问题¹
关于字符类,比较,排序,规范化和排序规则,哪些.NET平台支持哪些Unicode版本？
原始问题
我记得有点模糊地读过.NET支持Unicode 3.0版,内部UTF-16编码不是真正的UTF-16,但实际上使用的是UCS-2,这是不一样的.例如,似乎U + FFFF以上的字符是不可能的,即考虑:
string s = "\u1D7D9"; // ("Mathematical double-struck digit one")
它存储字符串"?9".
我基本上是在寻找以下答案的确切参考:
¹)我随着时间的推移更新了问题,对于答案和更大的社区来说似乎更合适.我留下原来的问题来代替评论中回答了哪些部分.在现有的32位Windows版本中也使用了旧的UCS-2(没有代理),.NET一直在内部使用UTF-16(带有代理).
我想知道是否有一个推荐的'交叉'Windows和Linux方法,用于将字符串从UTF-16LE转换为UTF-8？或者每个环境应该使用不同的方法？
我设法谷歌几个引用'iconv',但对于somreason我找不到基本转换的样本,例如 - 将wchar_t UTF-16转换为UTF-8.
任何人都可以推荐一种"交叉"的方法,如果您知道参考文献或带样本的指南,我将非常感激.
谢谢,Doori酒吧
我在某些地方读过JavaScript字符串是UTF-16,而在其他地方它们是UCS-2.我做了一些搜索,试图弄清楚差异,发现这个:
问:UCS-2和UTF-16有什么区别？
答:UCS-2是过时的术语,在代理代码点和UTF-16被添加到标准的2.0版之前,它指的是Unicode 1.1之前的Unicode实现.现在应该避免使用这个术语.
UCS-2没有定义不同的数据格式,因为UTF-16和UCS-2在数据交换方面是相同的.两者都是16位,并且具有完全相同的代码单元表示.
有时在过去,实现被标记为"UCS-2"以指示它不支持补充字符并且不将代理代码点对解释为字符.这样的实现不会处理补充字符的字符属性,代码点边界,校对等的处理.
通过:http://www.unicode.org/faq/utf_bom.html#utf16-11
所以我的问题是,是因为JavaScript字符串对象的方法和索引作用于16位数据而不是字符,这使得有些人认为它是UCS-2？如果是这样,围绕字符而不是16位数据块的JavaScript字符串对象是否会被视为UTF-16？或者还有其他我想念的东西？
编辑:根据要求,这里有一些来源说JavaScript字符串是UCS-2:
http://blog.mozilla.com/nnethercote/2011/07/01/faster-javascript-parsing/ http://terenceyim.wordpress.com/tag/ucs2/
编辑:对于任何可能遇到此问题的人,请务必查看此链接:
U + 001A字符经常出现在与字符编码有关的错误消息中.什么是U + 001A角色？