2013-06-09 1 views
0

У меня есть собственное приложение WinAPI на C++, которое строго использует функции и типы данных Unicode. Т.е., CreateWindowW(), SendMessageW(), wstring, WCHAR и т. Д. Теперь я намерен расширить свое приложение для использования SQLite3.Существуют ли какие-либо ограничения с использованием функций ANSI в приложении Unicode

Моя проблема: Библиотека SQLite3 ANSI. Это означает, что я должен использовать char* как большинство параметров функции.

Существуют ли какие-либо ограничения или отрицательные последствия использования ANSI-функций в приложении Unicode?

Если есть какие-либо последствия этого воздействия?

+0

Термин «ANSI» является неправильным (и, к сожалению, общим). В этом контексте он относится к 8-битной кодовой странице Windows-1252 и ее родственникам. Эти кодовые страницы никогда не были стандартами ANSI. http://en.wikipedia.org/wiki/Windows_ANSI_code_page#ANSI_code_page –

ответ

1

Нет ограничений, вы можете использовать строки ANSI в приложениях Unicode.

Некоторые детали: Юникодное приложение является определением времени компиляции. Во время выполнения программа может работать как с Unicode, так и с ANSI-строками.

Например:

char* ptr1;  // this is always ANSI string 
wchar_t* ptr2; // this is always Unicode string 
TCHAR* ptr3; // this is generic string, which is compiled as char* or wchar_t* 

конфигурация Unicode/ANSI отличается от интерпретации общих текстовых макросов, как TCHAR. Некоторые API Windows также реализованы с использованием общих текстовых макросов. Например: SetWindowText - фактически макрос, который расширяется до SetWindowTextA в конфигурации ANSI и до SetWindowTextW в конфигурации Юникода.

Любая нестандартная строка или имя API (например, char*, SetWindowTextW и т. Д.) Работает одинаково в любой конфигурации программы.

макросов преобразования Использования ATL для преобразования между различными (общими и необщими) типами строк: http://msdn.microsoft.com/en-us/library/87zae4a3%28v=vs.80%29.aspx

+0

'char *' не всегда ANSI. (Также как «ANSI string», так и «Unicode string» являются неверными, строки ANSI не соответствуют какой-либо спецификации, созданной Американским национальным институтом стандартов, а Unicode не является конкретной строковой кодировкой.) – bames53

+1

@ bames53 - это практический вопрос, я предпочитают давать ответ и не оспаривать терминологию. –

+1

@Alex Я бы предпочел правильный ответ. Спор не о терминологии. Ошибка заключается в следующем: «char * всегда есть строка ANSI». –

0

Вы можете использовать API-интерфейсы Ансите основанный на применении Unicode. Просто конвертируйте введенные строки Unicode в Ansi при передаче их в API и конвертируйте любые выходные строки Ansi в Unicode по возвращении из API. Вы можете использовать WideCharToMultiByte() и MultiByteToWideChar() для этого, или более высокоуровневые обертки, такие как CString, преобразования ATL и т. Д.

4

SQLite не ограничен ANSI. Заблуждение состоит в том, что char* подразумевает кодированный ANSI текст. Не все функции, которые работают с данными char*, предполагают, что данные кодируются ANSI. В случае SQLite он полностью поддерживает Unicode и делает это с использованием данных char*, закодированных с использованием UTF-8.

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

Что на мой взгляд, делает этот вопрос, что вы спросили несколько спорны, но я обращусь, что в любом случае:

Существует ли какое-либо ограничение или негативные последствия от использования ANSI функций в приложении Unicode?

Наиболее очевидные недостатки использования функций ANSI являются:

  1. Сурово ограниченный набор символов.
  2. Эксплуатационные расходы при конвертации между различными наборами символов.
  3. Опасность путаницы программиста и ошибок из-за использования множества наборов символов в одной кодовой базе.
Смежные вопросы