invalid wide-character constant怎么解决

业界专家认证

2005-04-09 01:23:46

我想定义一个包括所有字符的字符串如下：
wchar_t* allchars = L"\x0\x1\x2\x3\x4\x5\x6\x7\x8\x9\xa\xb\xc\xd\xe\xf\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f !\"#$%&'()*+,-./0123456789:;<=>?@abcdefghijklmnopqrstuvwxyz[\\]^_`abcdefghijklmnopqrstuvwxyz{|}\x7e\x7f\x80\x81\x82\x83\x84\x85\x86\x87\x88\x89\x8a\x8b\x8c\x8d\x8e\x8f\x90\x91\x92\x93\x94\x95\x96\x97\x98\x99\x9a\x9b\x9c\x9d\x9e\x9f\xa0\xa1\xa2\xa3\xa4\xa5\xa6\xa7\xa8\xa9\xaa\xab\xac\xad\xae\xaf\xb0\xb1\xb2\xb3\xb4\xb5\xb6\xb7\xb8\xb9\xba\xbb\xbc\xbd\xbe\xbf\xc0\xc1\xc2\xc3\xc4\xc5\xc6\xc7\xc8\xc9\xca\xcb\xcc\xcd\xce\xcf\xd0\xd1\xd2\xd3\xd4\xd5\xd6\xd7\xd8\xd9\xda\xdb\xdc\xdd\xde\xdf\xe0\xe1\xe2\xe3\xe4\xe5\xe6\xe7\xe8\xe9\xea\xeb\xec\xed\xee\xef\xf0\xf1\xf2\xf3\xf4\xf5\xf6\xf7\xf8\xf9\xfa\xfb\xfc\xfd\xfe\xff";
编译时出现错误invalid wide-character constant
好像是说'\x81'以后的字符不是合法的宽字符，怎么解决？

...全文

603 回复打赏收藏转发到动态举报

写回复

用AI写文章

切换为时间正序

请发表友善的回复…

发表回复

来源： http://lua-users.org/wiki/LuaUnicode 目录： | LuaUnicode.url | +---0.13A | ICU4Lua-0.13A-src.zip | ICU4Lua-0.13A-win32-dll.zip | \---0.2B ICU4Lua-0.2B-docs.zip ICU4Lua-0.2B-src.zip ICU4Lua-0.2B-win32dll.zip 下面的来源于： http://lua-users.org/wiki/LuaUnicode This is an attempt to answer the LuaFaq : Can I use unicode strings? or Does Lua support unicode? In short, yes and no. Lua gives you the bare bones support and enough rope and not much else. Unicode is a large and complex standard and questions like "does lua support unicode" are extremely vague. Some of the issues are: Can I store and retrieve Unicode strings? Can my Lua programs be written in Unicode? Can I compare Unicode strings for equality? Sorting strings. Pattern matching. Can I determine the length of a Unicode string? Support for bracket matching, bidirectional printing, arbitrary composition of characters, and other issues that arise in high quality typesetting. Lua strings are fully 8-bit clean, so simple uses are supported (like storing and retrieving), but there's no built in support for more sophisticated uses. For a fuller story, see below. Unicode strings and Lua strings A Lua string is an aribitrary sequence of values which have at least 8 bits (octets); they map directly into the char type of the C compiler. (This may be wider than eight bits, but eight bits are guaranteed.) Lua does not reserve any value, including NUL. That means that you can store a UTF-8 string in Lua without problems. Note that UTF-8 is just one option for storing Unicode strings. There are many other encoding schemes, including UTF-16 and UTF-32 and their various big-endian/little-endian variants. However, all of these are simply sequences of octets and can be stored in a Lua string without problems. Input and output of strings in Lua (using the io library) uses C's stdio library. ANSI C does not require the stdio library to handle arbitrary octet sequences unless the file is opened in binary mode; furthermore, in non-binary mode, some octet sequences are converted into other ones (in order to deal with varying end-of-line markers on different platforms). This may affect your ability to do non-binary file input and output of Unicode strings in formats other than UTF-8. UTF-8 strings will probably be safe because UTF-8 does not use control characters such as \n and \r as part of multi-octet encodings. However, there are no guarantees; if you need to be certain, you must use binary mode input and output. (If you do so, line-endings will not be converted.) Unix file IO has been 8-bit clean for a long while. If you are not concerned with portability and are only using Unix and Unix-like operating systems, you can almost certainly not worry about the above. If your use of Unicode is restricted to passing the strings to external libraries which support Unicode, you should be OK. For example, you should be able to extract a Unicode string from a database and pass it to a Unicode-aware graphics library. But see the sections below on pattern matching and string equality. Unicode Lua programs Literal Unicode strings can appear in your lua programs. Either a UTF-8 encoded string can appear directly with 8-bit characters or you can use the \ddd syntax (note that ddd is a decimal number, unlike some other languages). However, there is no facility for encoding multi-octet sequences (such as \U+20B4); you would need to either manually encode them to UTF-8, or insert individual octets in the correct big-endian/little-endian order (for UTF-16 or UTF-32). Unless you are using an operating system in which a char is more than eight bits wide, you will not be able to use arbitrary Unicode characters in Lua identifers (for the names of variables and so on). You may be able to use eight-bit characters outside of the ANSI range. Lua uses the C functions isalpha and isalnum to identify valid characters in identifiers, so it will depend on the current locale. To be honest, using characters outside of the ANSI range in Lua identifiers is not a good idea, since your programs will not compile in the standard C locale. Comparison and Sorting Lua string comparison (using the == operator) is done byte-by-byte. That means that == can only be used to compare Unicode strings for equality if the strings have been normalized in one of the four Unicode normalizations. (See the [Unicode FAQ on normalization] for details.) The standard Lua library does not provide any facility for normalizing Unicode strings. Consequently, non-normalized Unicode strings cannot be reliably used as table keys. If you want to use the Unicode notion of string equality, or use Unicode strings as table keys, and you cannot guarantee that your strings are normalized, then you'll have to write or find a normalization function and use that; this is non-trivial exercise! The Lua comparison operators on strings (< and <=) use the C function strcoll which is locale dependent. This means that two strings can compare in different ways according to what the current locale is. For example, strings will compare differently when using Spanish Traditional sorting to that when using Welsh sorting. It may be that your operating system has a locale that implements the sorting algorithm that you want, in which case you can just use that, otherwise you will have to write a function to sort Unicode strings. This is an even more non-trivial exercise. UTF-8 was designed so that a naive octet-by-octet string comparison of an octet sequence would produce the same result if a naive octet-by-octet string comparison were done on the UTF-8 encoding of the octet sequence. This is also true of UTF-32BE but I do not know of any system which uses that encoding. Unfortunately, naive octet-by-octet comparison is not the collation order used by any language. (Note: sometimes people use the terms UCS-2 and UCS-4 for "two-byte" and four-byte encodings. These are not Unicode standards; they come from the closely corresponding ISO standard ISO/IEC 10646-1:2000 and currently differ in that they allow codes outside of the Unicode range, which runs from 0x0 to 0x10FFFF.) Pattern Matching Lua's pattern matching facilities work character by character. In general, this will not work for Unicode pattern matching, although some things will work as you want. For example, "%u" will not match all Unicode upper case letters. You can match individual Unicode characters in a normalized Unicode string, but you might want to worry about combining character sequences. If there are no following combining characters, "a" will match only the letter a in a UTF-8 string. In UTF-16LE you could match "a%z". (Remember that you cannot use \0 in a Lua pattern.) Length and string indexing If you want to know the length of a Unicode string there are different answers you might want according to the circumstances. If you just want to know how many bytes the string occupies, so that you can make space for copying it into a buffer for example, then the existing Lua function string.len will work. You might want to know how many Unicode characters are in a string. Depending on the encoding used, a single Unicode character may occupy up to four bytes. Only UTF-32LE and UTF-32BE are constant length encodings (four bytes per character); UTF-32 is mostly a constant length encoding but the first element in a UTF-32 sequence should be a "Byte Order Mark", which does not count as a character. (UTF-32 and variants are part of Unicode with the latest version, Unicode 4.0.) Some implementations of UTF-16 assume that all characters are two bytes long, but this has not been true since Unicode version 3.0. Happily UTF-8 is designed so that it is relatively easy to count the number of unicode symbols in a string: simply count the number of octets that are in the ranges 0x00 to 0x7f (inclusive) or 0xC2 to 0xF4 (inclusive). (In decimal, 0-127 and 194-244.) These are the codes which can start a UTF-8 character code. Octets 0xC0, 0xC1 and 0xF5 to 0xFF (192, 193 and 245-255) cannot appear in a conforming UTF-8 sequence; octets in the range 0x80 to 0xBF (128-191) can only appear in the second and subsequent octets of a multi-octet encoding. Remember that you cannot use \0 in a Lua pattern. For example, you could use the following code snippet to count UTF-8 characters in a string you knew to be conforming (it will incorrectly count some invalid characters): local _, count = string.gsub(unicode_string, "[^\128-\193]", "") If you want to know how many printing columns a Unicode string will occupy when you print it out using a fixed-width font (imagine you are writing something like the Unix ls program that formats its output into several columns), then that is a different answer again. That's because some Unicode characters do not have a printing width, while others are double-width characters. Combining characters are used to add accents to other letters, and generally they do not take up any extra space when printed. So that's at least 3 different notions of length that you might want at different times. Lua provides one of them (string.len) the others you'll need to write functions for. There's a similar issue with indexing the characters of a string by position. string.sub(s, -3) will return the last 3 bytes of the string which is not necessarily the same as the last three characters of the string, and may or may not be a complete code. You could use the following code snippet to iterate over UTF-8 sequences (this will simply skip over most invalid codes): for uchar in string.gfind(ustring, "([%z\1-\127\194-\244][\128-\191]*)") do -- something end More sophisticated issues As you might have guessed by now, Lua provides no support for things like bidirectional printing or the proper formatting of Thai accents. Normally such things will be taken care of by a graphics or typography library. It would of course be possible to interface to such a library that did these things if you had access to one. There is a little string-like package [slnunicode] with upper/lower, len/sub and pattern matching for UTF-8. See ValidateUnicodeString for a smaller library. [ICU4Lua] is a Lua binding to ICU (International Components for Unicode [1]), an open-source library originally developed by IBM. See UnicodeIdentifers for platform independent Unicode Lua programs.

笔记本的风扇控制 ---------------------------------------- 09 November 2006. Summary of changes for version 20061109: 1) ACPI CA Core Subsystem: Optimized the Load ASL operator in the case where the source operand is an operation region. Simply map the operation region memory, instead of performing a bytewise read. (Region must be of type SystemMemory, see below.) Fixed the Load ASL operator for the case where the source operand is a region field. A buffer object is also allowed as the source operand. BZ 480 Fixed a problem where the Load ASL operator allowed the source operand to be an operation region of any type. It is now restricted to regions of type SystemMemory, as per the ACPI specification. BZ 481 Additional cleanup and optimizations for the new Table Manager code. AcpiEnable will now fail if all of the required ACPI tables are not loaded (FADT, FACS, DSDT). BZ 477 Added #pragma pack(8/4) to acobject.h to ensure that the structures in this header are always compiled as aligned. The ACPI_OPERAND_OBJECT has been manually optimized to be aligned and will not work if it is byte-packed. Example Code and Data Size: These are the sizes for the OS- independent acpica.lib produced by the Microsoft Visual C++ 6.0 32- bit compiler. The debug version of the code includes the debug output trace mechanism and has a much larger code and data size. Previous Release: Non-Debug Version: 78.1K Code, 17.1K Data, 95.2K Total Debug Version: 155.4K Code, 63.1K Data, 218.5K Total Current Release: Non-Debug Version: 77.9K Code, 17.0K Data, 94.9K Total Debug Version: 155.2K Code, 63.1K Data, 218.3K Total 2) iASL Compiler/Disassembler and Tools: Fixed a problem where the presence of the _OSI predefined control method within complex expressions could cause an internal compiler error. AcpiExec: Implemented full region support for multiple address spaces. SpaceId is now part of the REGION object. BZ 429 ---------------------------------------- 11 Oc

当我们把工程从非Unicode切换到Unicode时可能会遇到代码：_T("/x95/0")编译后出错：error C2002: invalid wide-character constant解决办法是在该串定义前添加一句#pragma setlocale(_T("en")) 或者#pragma setlocale(_T("ch")) 即可

最近，接到一个任务要将一个软件改写为支持中方版本的。其实思路很简单，只要将工程文件从ANSI版本改为UNICODE版就可以了。不过在改写的过程中还是遇到一些个小问题，现把整个过程记录下来，以便以后再遇到方便，同时，如果其它朋友也遇到同样的问题，也好解决，不用再一个个的找原因了。 1.首先，打开工程－>重新编译。确保原工程编译通过。2.然后依次打开 projec

ORA-24280: invalid input value for parameter string Cause: The parameter has been provided a negative, out of range, or NULL input value. Action: Correct the input value such that it is valid, and

VC/MFC

16,472

社区成员

421,732

社区内容

发帖

与我相关

我的任务

社区管理员

加入社区

近7日
近30日
至今

加载中

查看更多榜单

社区公告

VC/MFC社区版块或许是CSDN最“古老”的版块了，记忆之中，与CSDN的年龄几乎差不多。随着时间的推移，MFC技术渐渐的偏离了开发主流，若干年之后的今天，当我们面对着微软的这个经典之笔，内心充满着敬意，那些曾经的记忆，可以说代表着二十年前曾经的辉煌……
向经典致敬，或许是老一代程序员内心里面难以释怀的感受。互联网大行其道的今天，我们期待着MFC技术能够恢复其曾经的辉煌，或许这个期待会永远成为一种“梦想”，或许一切皆有可能……
我们希望这个版块可以很好的适配Web时代，期待更好的互联网技术能够使得MFC技术框架得以重现活力，……

试试用AI创作助手写篇文章吧

+ 用AI写文章