Есть ли какая-либо мыслимая причина, по которой я увижу разные результаты, используя строковые литералы Unicode, по сравнению с фактическим шестнадцатеричным значением для UChar.
UnicodeString s1(0x0040); // @ sign
UnicodeString s2("\u0040");
s1 не эквивалентен s2. Почему?
Управляющая последовательность \u AFAIK определяется реализацией, поэтому трудно сказать, почему они не эквивалентны, не зная подробностей о вашем конкретном компиляторе. Тем не менее, это просто небезопасный способ ведения дел.
UnicodeString имеет конструктор, принимающий UChar и один для UChar32. Я был бы явным при их использовании:
UnicodeString s(static_cast<UChar>(0x0040));
UnicodeString также предоставляет довольно удобный метод unescape():
UnicodeString s = UNICODE_STRING_SIMPLE("\\u4ECA\\u65E5\\u306F").unescape(); // 今日は
не удалось воспроизвести на ICU 4.8.1.1
#include <stdio.h>
#include "unicode/unistr.h"
int main(int argc, const char *argv[]) {
UnicodeString s1(0x0040); // @ sign
UnicodeString s2("\u0040");
printf("s1==s2: %s\n", (s1==s2)?"T":"F");
// printf("s1.equals s2: %d\n", s1.equals(s2));
printf("s1.length: %d s2.length: %d\n", s1.length(), s2.length());
printf("s1.charAt(0)=U+%04X s2.charAt(0)=U+%04X\n", s1.charAt(0), s2.charAt(0));
return 0;
}
=>
s1==s2: T
s1.длина: 1 s2.длина: 1
s1.charAt(0)=U+0040 s2.charAt(0)=U+0040
gcc 4.4.5 RHEL 6.1 x86_64
Для всех, кто нашел это, вот что я нашел (в документации ICU).
Кодировки кодовых страниц компилятора и набора символов времени выполнения не указаны стандартами языка C/C++ и обычно не являются формой кодировки Unicode. Обычно они зависят от настроек отдельной системы, процесса или потока. Следовательно, невозможно создать экземпляр символа Юникода или строковой переменной непосредственно с помощью символьных или строковых литералов C/C++. Единственный безопасный способ — использовать числовые значения. Это не проблема для строк пользовательского интерфейса (UI), которые переведены.
[1] http://userguide.icu-project.org/strings
Проблема заключается в двойных кавычках в вашей константе \u. Это правильно оценено:
wchar_t m1( 0x0040 );
wchar_t m2( '\u0040' );
bool equal = ( m1 == m2 );
equal было true.
'\u0040' определен не лучше, чем строковый псевдолитерал "\u0040"; оба зависят от реализации и контекста и вообще не должны использоваться таким образом.
- person Kerrek SB; 16.11.2011
\uXXXX. Проблема в том, что означает '\uXXXX'? Видите ли, первое — просто абстрактное значение, а второе — значение конкретного типа. И нет универсального правила, как произвольная кодовая точка Unicode должна превратиться в char (что является типом литерала ''). Сравните это, скажем, с U"\uXXXX", где строка состоит из char32_t, а семантика стандартизирована (поэтому строка состоит из двух элементов, первый — 32-битное целое число 0x0000XXXX, а второй — ноль).
- person Kerrek SB; 16.11.2011
'\u0040' указывает символ '@', используя допустимую экранирующую последовательность универсального имени-символа.
- person Gnawme; 16.11.2011
UnicodeString-- определено ли оно отделением интенсивной терапии? - person Kerrek SB schedule 16.11.2011"\u0040"просто не определен четко (то есть он определяется реализацией). Так что я думаю, что мы не можем ответить на это в целом. Если бы это была строка UTF-8 (u8"\u0040"), мы могли бы быть в лучшей форме. - person Kerrek SB schedule 16.11.2011\uи\Uв этом контексте. Вот мой предыдущий пост на эту тему. - person Kerrek SB schedule 16.11.2011\u– это экранирующая последовательность, представляющая собой лексическую особенность грамматики C++, используемую для литеральных значений. Вы не можете прочитать его из файла. (Де)сериализация всегда требует документирования формата. - person Kerrek SB schedule 16.11.2011keyname {"some text \u0040"}, и точно отображать текст для ключа в UnicodeString. - person Ternary schedule 16.11.2011"terminate()", ваша программа останавливается... - person Kerrek SB schedule 16.11.2011UnicodeString("\u0040")иUnicodeString("\\u0040")есть принципиальная разница! - person Kerrek SB schedule 16.11.2011Since ICU is not a compiler extension, the "unescaping" is done at runtime and the backslash itself must be escaped (duplicated) so that the compiler does not attempt to "unescape" the sequence itself.Из userguide.icu-project.org/strings< /а> - person Ternary schedule 16.11.2011