标签: utf-16

我即将开始处理需要读取字节和创建字符串的事情.正在读取的字节表示UTF-16字符串.所以只是为了测试我想要将UTF-16编码的简单字节数组转换为字符串.数组中的前2个字节必须表示字节序,因此必须是0xff 0xfe或0xfe 0xff.所以我尝试按如下方式创建我的字节数组:

byte[] bytes = new byte[] {0xff, 0xfe, 0x52, 0x00, 0x6F, 0x00};

但是我收到一个错误,因为0xFF和0xFE太大而无法放入一个字节(因为字节是用Java签名的).更确切地说,错误是int无法转换为字节.我知道我可以使用强制转换显式地从int转换为byte并获得所需的结果,但这不是我的问题.

为了尝试一些东西,我创建了一个String并调用了getBytes("UTF-16")然后打印了数组中的每个字节.输出有点令人困惑,因为前两个字节是0xFFFFFFFE 0xFFFFFFFF,后跟0x00 0x52 0x00 0x6F.(显然这里的字节顺序与我上面尝试创建的不同,但这并不重要).

使用此输出我决定尝试以相同的方式创建我的字节数组:

byte[] bytes = new byte[] {0xffffffff, 0xfffffffe, 0x52, 0x00, 0x6F, 0x00};

奇怪的是,它工作得很好.所以我的问题是,为什么Java允许0xFFFFFF80或更大的整数值自动转换为没有显式强制转换的字节,但任何等于或大于0x80的东西都需要显式强制转换？

在Delphi 2007中,您可以在WideString中存储UTF-8字符串,然后将其传递给Win32函数,例如

var
  UnicodeStr: WideString;
  UTF8Str: WideString;
begin
  UnicodeStr:='some unicode text';
  UTF8Str:=UTF8Encode(UnicodeStr);
  Windows.SomeFunction(PWideChar(UTF8Str), ...)
end;

Delphi 2007不会干扰UTF8Str的内容,即它保留为存储在WideString中的UTF-8编码字符串.

但是在Delphi 2010中,我很难找到一种方法来做同样的事情,即将一个UTF-8编码的字符串存储在WideString中,而不会自动从UTF-8转换.我无法传递指向UTF-8字符串(或RawByteString)的指针,例如以下显然不起作用:

var
  UnicodeStr: WideString;
  UTF8Str: UTF8String;
begin
  UnicodeStr:='some unicode text';
  UTF8Str:=UTF8Encode(UnicodeStr);
  Windows.SomeFunction(PWideChar(UTF8Str), ...)
end;

我正在使用ASP.NET MVC,MS SQL和IIS.我有一些用户在他们的个人资料信息中使用了中文字符.但是,当我显示此信息时显示为,æŽå¼·è¯但它们在我的数据库中是正确的.目前我的HTML页面的UTF设置为UTF-8.我应该把它改成UTF-16吗？我知道有一些问题可以来自于此,但我的选择是什么？

谢谢,

亚伦

似乎SQL Server 对字段使用Unicode UCS-2,一个2字节的固定长度字符编码nchar/nvarchar.同时,C#对其字符串使用Unicode UTF-16编码(注意:有些人不认为UCS-2是Unicode,但它在Unicode子集0-0xFFFF中编码与UTF-16相同的所有代码点,并且就SQL Server而言,就字符串而言,它本身支持的"Unicode"最接近它.)

虽然UCS-2在基本多语言平面(BMP)中对与UTF-16相同的基本代码点进行编码,但它不保留UTF-16允许代理对的某些位模式.

如果我将C#字符串写入SQL Server nvarchar(UCS-2)字段并将其读回,这是否会返回相同的结果？

看来尽管UTF-16是UCS-2的意义上的超集UTF-16编码更多的代码点(例如上述0xFFFF)时,它实际上是UCS-2的2字节级的子集,因为它是限制性更强.

为了回答我自己的问题,我怀疑如果我的C#字符串包含高于0xFFFF的代码点(由字符对表示),这些将在数据库中存储和检索得很好,但如果我试图在数据库中操作它们(例如也许调用TOUPPER或试图删除所有其他字符),然后我可能会遇到一些问题,以后显示字符串...除非SQL Server具有确认代理对并有效地将nchar/nvarchar字符串视为UTF-16的函数.

我有一个可能是一个非常简单,狡猾的问题,但我无法在任何地方找到答案,我需要对此非常肯定.

我有来自不同供应商的各种XML文件.其中一个供应商为我提供了一个包含日文字符的XML文件.最初,我在处理XML文件时遇到了问题(我正在使用MSXML SDK).角色会出错.我发现如果将以下内容添加到XML文件中,一切都很有效.

<?xml version="1.0" encoding="UTF-16"?>

所以我要求供应商将其添加到他们的文件中.但是他们用小写的编码添加了它:

<?xml version="1.0" encoding="utf-16"?>

当我加载这个新文件时,使用此声明,我遇到了与此声明不存在时相同的问题.

我想弄清楚的(肯定的)是该编码属性是否区分大小写(或者是其他问题).他们把"utf-16"与"UTF-16"放在一起是否重要？

更新:在这些发布答案的人的建议下,我设置并执行了测试.一个文件的小写字母为utf-16,另一个大写字母.除此之外,文件是相同的.这没有解决问题,也不是问题.我的结论是,MSXML不区分大小写,因为规范在答案中说明.

看起来用于UTF16-LE和UTF-32LE的字节顺序标记之间存在歧义.特别是,考虑一个包含以下8个字节的文件:

FF FE 00 00 00 00 00 00

如何判断此文件是否包含:

1. UTF16-LE BOM(FF FE)后跟3个空字符; 要么
2. UTF32-LE BOM(FF FE 00 00)后跟一个空字符？

Unicode BOMs在这里描述:http://unicode.org/faq/utf_bom.html#bom4但是没有讨论这种歧义.我错过了什么吗？

我有一个Web应用程序,允许用户上传他们的内容进行处理.处理引擎需要UTF8(我正在从多个用户的文件中编写XML),所以我需要确保能够正确解码上传的文件.

因为如果我的任何用户知道他们的文件甚至被编码我会感到惊讶,我很少希望他们能够正确指定要使用的编码(解码器).因此,我的应用程序在解码前留下了检测任务.

这似乎是一个普遍的问题,我很惊讶没有找到解决方案的框架功能或一般配方.是不是我没有搜索有意义的搜索词？

我已经实现了BOM感知检测(http://en.wikipedia.org/wiki/Byte_order_mark),但我不确定文件上传的频率是多少,无需BOM表示编码,这对于大多数非UTF文件.

我的问题归结为:

1. BOM识别检测对于绝大多数文件是否足够？
2. 在BOM检测失败的情况下,是否可以尝试不同的解码器并确定它们是否"有效"？(我的尝试表明答案是"不".)
3. 在什么情况下,"有效"文件会因C#编码器/解码器框架而失败？
4. 是否有一个存储库,其中包含大量具有各种编码的文件用于测试？
5. 虽然我特别询问C#/ .NET,但我想知道Java,Python和其他语言的答案,以便下次我必须这样做.

到目前为止,我发现:

• 带有Ctrl-S字符的"有效"UTF-16文件导致编码为UTF-8抛出异常(非法字符？) (这是一个XML编码异常.)
• 使用UTF-8解码有效的UTF-16文件会成功,但会为文本提供空字符.咦？
• 目前,我只期望UTF-8,UTF-16和可能的ISO-8859-1文件,但我希望该解决方案尽可能可扩展.
• 我现有的一组输入文件不够宽泛,无法发现实时文件会出现的所有问题.
• 虽然我试图解码的文件是"文本",但我认为它们通常是用文件中的垃圾字符创建的方法.因此"有效"文件可能不是"纯粹的".哦,快乐.

谢谢.

Google App Engine使用Python 2.5.2,显然启用了UCS4.但GAE数据存储区在内部使用UTF-8.所以,如果你存储U '\ ud834\udd0c'(长2)到数据存储,当你找回它,你会得到 '\ U0001d10c'(长度为1).我试图计算字符串中unicode字符的数量,以便在存储它之前和之后给出相同的结果.因此,在收到字符串之前,我会尝试将字符串规范化(从u'\ ud834\udd0c'到'\ U0001d10c'),然后再计算其长度并将其放入数据存储区.我知道我可以将其编码为UTF-8然后再次解码,但是有更简单/有效的方法吗？

我在java中有这个字符串:

"test.message"

byte[] bytes = plaintext.getBytes("UTF-8");
//result: [116, 101, 115, 116, 46, 109, 101, 115, 115, 97, 103, 101]

如果我在javascript中做同样的事情:

    stringToByteArray: function (str) {         
        str = unescape(encodeURIComponent(str));

        var bytes = new Array(str.length);
        for (var i = 0; i < str.length; ++i)
            bytes[i] = str.charCodeAt(i);

        return bytes;
    },

我明白了:

 [7,163,140,72,178,72,244,241,149,43,67,124]

我的印象是unescape(encodeURIComponent())会正确地将字符串转换为UTF-8.这不是这种情况吗？

参考:

http://ecmanaut.blogspot.be/2006/07/encoding-decoding-utf8-in-javascript.html

我知道解决方案很简单，但我花了一个小时才解决这个问题。

在Windows 10中，如果我启动命令“ dir ”，我得到以下结果：

Il 卷 nell\'unit\xc3\xa0 D non ha etichetta。

在Node.js中中，我尝试以这种方式执行 dir 命令：

var child = exec(\'dir\', {\'encoding\': \'UTF-8\'}, (err, stdout, stderr) => {\n  console.log(stdout);\n});\n

我得到了这个结果：\n Il 卷 nell\'unit\xef\xbf\xbd C non ha etichetta。

啊，该死的带口音的信！

我尝试使用 UTF-16，然后转换为字符串：

var child = exec(\'dir\', {\'encoding\': \'UTF-16\'}, (err, stdout, stderr) => {\n  let b: Buffer = stdout;\n  let o: string;\n  o = stdout.toString(\'UTF-8\');\n  console.log(o);\n});\n

我得到了同样的诅咒结果：

“Il 卷 nell\'unit\xef\xbf\xbd C …