std :: wstring VS std :: string

Связь Ajax между клиентом и сервером часто включает данные в формате JSON. В то время как JSON хорошо работает для строк, чисел и логических значений, он может создавать определенные трудности для дат из-за того, как они преобразуются в ASP.NET. Поскольку у них нет специального представления для дат, они сериализуются как простые строки. В качестве решения механизм сериализации по умолчанию ASP.NET Web Forms и MVC сериализует даты в специальной форме - / Date (ticks) / - где тики - это число миллисекунд с 1 января 1970 года.

Эта проблема может быть решена двумя способами:

клиентская сторона

Преобразование полученной строки даты в число и создание объекта даты с использованием конструктора класса даты с параметрами ticks as.

function ToJavaScriptDate(value) {
  var pattern = /Date\(([^)]+)\)/;
  var results = pattern.exec(value);
  var dt = new Date(parseFloat(results[1]));
  return (dt.getMonth() + 1) + "/" + dt.getDate() + "/" + dt.getFullYear();

}

серверная сторона

В предыдущем решении используется сценарий на стороне клиента для преобразования даты в объект JavaScript. Вы также можете использовать код на стороне сервера, который сериализует экземпляры .NET DateTime в выбранном вами формате. Для выполнения этой задачи вам необходимо создать свой собственный ActionResult и затем сериализовать данные так, как вы хотите.

ссылка: http://www.developer.com/net/dealing-with-json -dates-в-asp.net-mvc.html

700
задан Rapptz 31 January 2013 в 21:33
поделиться

8 ответов

  1. , когда Вы хотите использовать строки Unicode и не только ASCII, полезный для интернационализации
  2. да, но и это не играет хорошо с 0
  3. не знающий ни о ком, которые не делают
  4. , широкий символ является особенным методом компилятора обработки представления фиксированной длины unicode символа для MSVC, это - 2-байтовый символ для gcc, я понимаю, что это - 4 байта. и +1 для http://www.joelonsoftware.com/articles/Unicode.html
1
ответ дан Greg Domjan 31 January 2013 в 21:33
поделиться

Я часто использую станд.:: представьте в виде строки для содержания utf-8 символов без любых проблем вообще. Я сердечно рекомендую делать это при взаимодействии через интерфейс с API, которые используют utf-8 в качестве собственного строкового типа также.

, Например, я использую utf-8 при взаимодействии через интерфейс с моим кодом с интерпретатором Tcl.

главный протест является длиной станд.:: представьте в виде строки, больше не количество символов в строке.

5
ответ дан 31 January 2013 в 21:33
поделиться

1), Как упомянуто Greg, wstring полезен для интернационализации, именно тогда Вы будете выпускать свой продукт на языках кроме английского языка

, 4) Проверяют это для широкого символа http://en.wikipedia.org/wiki/Wide_character

0
ответ дан Raghu 31 January 2013 в 21:33
поделиться
  1. , Когда Вы хотите сохранить 'широкие' символы (Unicode).
  2. Да: 255 из них (исключая 0).
  3. Да.
  4. Вот вводная статья: http://www.joelonsoftware.com/articles/Unicode.html
3
ответ дан ChrisW 31 January 2013 в 21:33
поделиться
  1. , Когда Вы хотите сохранить широкие символы в Вашей строке. wide зависит от реализации. Значения по умолчанию Visual C++ к 16 битам, если я помню правильно, в то время как значения по умолчанию GCC в зависимости от цели. Это 32 бита длиной здесь. Обратите внимание, что wchar_t (тип широкого символа) не имеет никакого отношения к unicode. Просто гарантируется, что это может сохранить всех членов самого большого набора символов что поддержка внедрения его локалями, и по крайней мере настолько же долго как символ. Вы можете хранилище строки unicode, прекрасные в std::string использование utf-8 кодирование также. Но это не поймет значение unicode кодовых точек. Так str.size() не даст Вам количество логических символов в Вашей строке, но просто сумму символа или wchar_t элементов, сохраненных в этом string/wstring. По этой причине gtk/glib люди обертки C++ разработали Glib::ustring класс, который может обработать utf-8.

    , Если Ваш wchar_t 32 бита длиной, то можно использовать utf-32 в качестве кодирования unicode, и можно сохранить , и дескриптор unicode строки с помощью фиксированного (utf-32 фиксированная длина), кодирование. Это означает Ваш wstring's s.size(), функция будет тогда , возвращают правильную сумму wchar_t элементов и логические символы.

  2. Да, символ всегда по крайней мере 8 битов длиной, что означает, что он может сохранить все значения ASCII.
  3. Да, все главные компиляторы поддерживают его.
25
ответ дан Johannes Schaub - litb 31 January 2013 в 21:33
поделиться

string? wstring?

std::string basic_string шаблонные на char, и std::wstring на wchar_t .

char по сравнению с [1 110]

char, как предполагается, содержит символ, обычно 8-разрядный символ.
wchar_t, как предполагается, содержит широкий символ, и затем, вещи становятся хитрыми:
На Linux, wchar_t 4 байта, в то время как в Windows, это - 2 байта.

Что относительно [1 149] Unicode, тогда?

проблема состоит в том, что ни char, ни wchar_t непосредственно связывается с unicode.

На Linux?

Позволяют нам взять ОС Linux: Моя система Ubuntu уже unicode знающая. Когда я работаю с символьной строкой, она исходно кодируется в [1 150] UTF-8 (т.е. строка Unicode символов). Следующий код:

#include <cstring>
#include <iostream>

int main(int argc, char* argv[])
{
   const char text[] = "olé" ;


   std::cout << "sizeof(char)    : " << sizeof(char) << std::endl ;
   std::cout << "text            : " << text << std::endl ;
   std::cout << "sizeof(text)    : " << sizeof(text) << std::endl ;
   std::cout << "strlen(text)    : " << strlen(text) << std::endl ;

   std::cout << "text(ordinals)  :" ;

   for(size_t i = 0, iMax = strlen(text); i < iMax; ++i)
   {
      std::cout << " " << static_cast<unsigned int>(
                              static_cast<unsigned char>(text[i])
                          );
   }

   std::cout << std::endl << std::endl ;

   // - - - 

   const wchar_t wtext[] = L"olé" ;

   std::cout << "sizeof(wchar_t) : " << sizeof(wchar_t) << std::endl ;
   //std::cout << "wtext           : " << wtext << std::endl ; <- error
   std::cout << "wtext           : UNABLE TO CONVERT NATIVELY." << std::endl ;
   std::wcout << L"wtext           : " << wtext << std::endl;

   std::cout << "sizeof(wtext)   : " << sizeof(wtext) << std::endl ;
   std::cout << "wcslen(wtext)   : " << wcslen(wtext) << std::endl ;

   std::cout << "wtext(ordinals) :" ;

   for(size_t i = 0, iMax = wcslen(wtext); i < iMax; ++i)
   {
      std::cout << " " << static_cast<unsigned int>(
                              static_cast<unsigned short>(wtext[i])
                              );
   }

   std::cout << std::endl << std::endl ;

   return 0;
}

выводы следующий текст:

sizeof(char)    : 1
text            : olé
sizeof(text)    : 5
strlen(text)    : 4
text(ordinals)  : 111 108 195 169

sizeof(wchar_t) : 4
wtext           : UNABLE TO CONVERT NATIVELY.
wtext           : ol�
sizeof(wtext)   : 16
wcslen(wtext)   : 3
wtext(ordinals) : 111 108 233

Вы будете видеть, что "olГ©" текст в [1 116] действительно создается четырьмя символами: 110, 108, 195 и 169 (не подсчет конечного нуля). (Я позволю Вам учиться эти wchar_t код как осуществление)

Так, при работе с char на Linux, необходимо обычно заканчивать тем, что использовали Unicode, даже не зная это. И как [1 119] работы с [1 120], таким образом std::string уже unicode-готово.

Примечание, что std::string, как API струны до, будет полагать, что строка "olГ©" имеет 4 символа, не три. Таким образом, необходимо быть осторожными при усечении/игре с unicode символами, потому что некоторая комбинация символов запрещается в UTF-8.

В Windows?

В Windows, это несколько отличается. Win32 должен был поддержать много приложения, работающего с [1 123] и на различном наборы символов / кодовые страницы произведенный во всем мире перед появлением Unicode.

, Таким образом, их решением было интересное: Если приложение работает с [1 124], то символьные строки закодированы/распечатаны/показаны на маркировках GUI с помощью локального набора символов/кодовой страницы на машине. Например, "olГ©" был бы "olГ©" в локализованном французами Windows, но будет чем-то другим в локализованном кириллицей Windows ("olР№", если Вы используете Windows 1251 ). Таким образом, "исторические приложения" будут обычно все еще работать тот же старый путь.

Для основанных на Unicode приложений, использование Windows wchar_t, который 2 байта шириной, и кодируется в [1 154] UTF-16, который является Unicode, закодированным на 2-байтовых символах (или по крайней мере, главным образом совместимый UCS-2, который является почти тем же самым IIRC).

Приложения с помощью [1 126] сказаны "многобайтовые" (потому что каждый глиф состоит из одного или нескольких char с, в то время как приложения с помощью [1 128] сказаны "widechar" (потому что каждый глиф состоит из один или два wchar_t. См. MultiByteToWideChar и API WideCharToMultiByte Win32 преобразования для большего количества информации

Таким образом, если Вы работаете над Windows, Вы плохо хотите использовать wchar_t (если Вы не используете платформу, скрывающую это, как [1 157] GTK + или QT...). Факт - то, что негласно, работы Windows с [1 131] строки, поэтому даже историческим приложениям преобразуют их char строки в [1 133] при использовании API как [1 134] (низкоуровневая API-функция для установки маркирования на Win32 GUI).

Проблемы памяти?

UTF-32 составляет 4 байта на символы, таким образом, существует не очень для добавления, если только, что текст UTF-8 и текст UTF-16 будут всегда использовать меньше или тот же объем памяти, чем текст UTF-32 (и обычно меньше).

, Если существует проблема памяти, то необходимо знать, чем для большинства западных языков, текст UTF-8 будет использовать меньше памяти, чем тот же UTF-16 один.

однако, для других языков (китайский язык, японский язык, и т.д.), используемая память будет или тем же, или немного больше для UTF-8, чем для UTF-16.

, В целом, UTF-16 будет главным образом использовать 2 и иногда 4 байта на символы (если Вы не будете иметь дело с некоторыми тайными глифами языка (Klingon? Волшебный?), в то время как UTF-8 потратит от 1 до 4 байтов.

Видят http://en.wikipedia.org/wiki/UTF-8#Compared_to_UTF-16 для большего количества информации

Заключение

  1. , Когда я должен использовать станд.:: wstring по станд.:: строка?

    На Linux? Почти никогда (В§).
    В Windows? Почти всегда (В§).
    На межплатформенном коде? Зависит от Вашего инструментария...

    (В§): если Вы не используете инструментарий/платформу, говорящий иначе

  2. , Может std::string содержать весь набор символов ASCII включая специальные символы?

    Уведомление: std::string подходит для содержания 'двоичного' буфера, где std::wstring не!

    На Linux? Да.
    В Windows? Только специальные символы, доступные для текущей локали пользователя Windows.

    Редактирование (После комментария от [1 160] Johann Gerell ):
    std::string будет достаточно для обработки всего char - базирующиеся строки (каждый char являющийся числом от 0 до 255). Но:

    1. ASCII, как предполагается, идет от 0 до 127. Выше char с НЕ являются ASCII.
    2. char от 0 до 127 будет сохранен правильно
    3. char от 128 до 255, будет иметь значение в зависимости от Вашего кодирования (unicode, non-unicode, и т.д.), но оно будет в состоянии содержать все глифы Unicode, пока они кодируются в UTF-8.
  3. std::wstring поддерживаются почти всеми популярными компиляторами C++?

    Главным образом, за исключением GCC основывал компиляторы, которые портированы к Windows.
    Это работает над моим g ++ 4.3.2 (в соответствии с Linux), и я использовал API Unicode на Win32 начиная с Visual C++ 6.

  4. , Что такое точно широкий символ?

    На C/C++, это - тип символов, записанный wchar_t, который больше, чем простое char тип символов. Это, как предполагается, используется для вставления символов, индексы которых (как глифы Unicode) больше, чем 255 (или 127, завися...).

950
ответ дан user1741137 31 January 2013 в 21:33
поделиться
  • 1
    Это хорошо работает в 4.4.1. Удостоверьтесь, что файлы имеют правильный номер и не, например, .txt. В предпочтениях Средства поиска, Усовершенствованных, включают " Покажите все имя файла extensions" в случае, если ОС скрывает расширение (или просто используйте терминал). – Andy 5 September 2012 в 11:38

Когда НЕ следует использовать расширенные символы?

Когда вы пишете код до 1990 года.

Очевидно, я заблужусь, но на самом деле сейчас 21 век. 127 знаков давно перестали быть достаточными. Да, вы можете использовать UTF8, но зачем беспокоиться о головной боли?

-6
ответ дан 22 November 2019 в 21:33
поделиться

Я рекомендую избегать std::wstring на Windows или где-либо еще, за исключением случаев, когда этого требует интерфейс, или где-либо вблизи вызовов Windows API и соответствующих кодировок, как синтаксический сахар.

Мое мнение обобщено в http://utf8everywhere.org, соавтором которого я являюсь.

Если ваше приложение не ориентировано на API, например, в основном на UI, предлагается хранить строки Unicode в std::string и кодированные в UTF-8, выполняя преобразование рядом с вызовами API. Преимущества, описанные в статье, перевешивают явное раздражение от преобразования, особенно в сложных приложениях. Это вдвойне важно при разработке мультиплатформенных и библиотечных приложений.

А теперь, отвечая на ваши вопросы:

  1. Несколько слабых причин. Она существует по историческим причинам, когда считалось, что видотехники являются правильным способом поддержки Юникода. Теперь он используется для интерфейсных API, предпочитающих строки UTF-16. Я использую их только в непосредственной близости от таких вызовов API.
  2. Это не имеет никакого отношения к std::string. Он может содержать любую кодировку, которую вы в него вставите. Вопрос только в том, как Вы обращаетесь с его содержимым. Моя рекомендация - UTF-8, так что он сможет корректно удержать все символы Юникода. Это распространенная практика в Linux, но я думаю, что Windows программы тоже должны это делать.
  3. Нет.
  4. Широкий символ - это запутанное имя. В ранние времена Юникода существовало убеждение, что символ может быть закодирован в два байта, отсюда и название. Сегодня это означает "любую часть символа длиной в два байта". UTF-16 рассматривается как последовательность таких пар байтов (также известная как Широкие символы). Символ в UTF-16 занимает одну или две пары.
64
ответ дан 22 November 2019 в 21:33
поделиться
Другие вопросы по тегам:

Похожие вопросы: