简体   繁体   English

如何使用Visual C ++将UTF-8编码数据存储到sqlite3

[英]how to store UTF-8 encoding data to sqlite3 using Visual C++

I've created a sqlite database with encoding UTF-8(default). 我已经创建了一个编码为UTF-8(默认)的sqlite数据库。

Then I use the following statement to insert data: 然后,我使用以下语句插入数据:

strcpy(sql,"insert into blog(title) values('呵呵')");
sqlite3_exec(db,sql,0,0,0);

then I open the sqlite database with tool called SQLite Developer the value of title field shows ºǺ garbage code under Data encoding: UNICODE . 然后我打开SQLite数据库用的工具,叫做sqlite的开发价值title栏显示ºǺ 在数据编码垃圾代码:UNICODE。 then I changed Data encoding to ANSI , value of title shows right. 然后我将数据编码更改为ANSItitle值显示为正确。

As I know the sqlite3_exec prototype is : 据我所知sqlite3_exec原型是:

int sqlite3_exec(
  sqlite3*,                                  /* An open database */
  const char *sql,                           /* SQL to be evaluated */
  int (*callback)(void*,int,char**,char**),  /* Callback function */
  void *,                                    /* 1st argument to callback */
  char **errmsg                              /* Error msg written here */
);

I still try to pass wchar_t type to sql ,but still won't work it out. 我仍然尝试将wchar_t类型传递给sql ,但仍然wchar_t

My Visual C++ project already defined UNOCODE & _UNICODE , So my question is: how to store UTF-8 encoding data to sqlite3 using Visual C++? 我的Visual C ++项目已经定义了UNOCODE_UNICODE ,所以我的问题是: 如何使用Visual C ++将UTF-8编码数据存储到sqlite3?


Update(question solved) 更新(问题已解决)

I use iconv to convert GBK encoding to UTF-8 inspired by msandiford. 我使用iconvGBK编码转换为msandiford启发的UTF-8 Thanks msandiford so much. 非常感谢msandiford。

char* pOut;
char* pIn;
size_t inLen,outLen=2000;
strcpy(sql,"insert into blog(title) values('呵呵')");
string strSQL = sql;
char* sql2 = (char*)malloc(2000);
memset(sql2,0,2000);
pOut = &sql2[0];
inLen = strlen(strSQL.c_str());
pIn = const_cast<char*>(strSQL.c_str());
iconv_t g2u8 = iconv_open("UTF-8","GBK");
iconv(g2u8,(const char**)&pIn,&inLen,&pOut,&outLen);
sqlite3_exec(db,sql2,0,0,0);

Collecting comments into answer form: 将评论收集到答案中:

From the question comments, apparently the source files are not encoded in UTF-8. 根据问题注释,显然源文件未使用UTF-8编码。 Converting to UTF-8 or using the UTF-8 encoding directly seems to work. 似乎可以转换为UTF-8或直接使用UTF-8编码。

Using UTF-8 encoding directly: 直接使用UTF-8编码:

    strcpy(sql,"insert into blog (title) values ('\xE5\x91\xB5\xE5\x91\xB5')");

You could avoid having to convert all your source files to UTF-8 by doing something like this: 您可以通过执行以下操作避免将所有源文件转换为UTF-8:

    sprintf(sql, "insert into blog (title) values('%s')", AnsiToUtf8("呵呵"));

Unfortunately the AnsiToUtf8() function is going to be pretty platform specific. 不幸的是, AnsiToUtf8()函数将特定于平台。


Looking further into this, it appears that Visual Studio saves source files in the default encoding for your Windows locale settings. 进一步研究,似乎Visual Studio以Windows区域设置的默认编码保存源文件。 Based on this, there could potentially be an assortment of encodings if your dev team's computers are set up for different locales. 基于此,如果您的开发团队的计算机针对不同的区域设置,则可能存在多种编码。

I think it would be quite difficult, if not impossible, to implement an AnsiToUtf8() function that would cope in all the possible cases, especially given that the locale settings for the computer that the code is developed on may not be the same as the computer that ultimately runs the code. 我认为实现AnsiToUtf8()函数AnsiToUtf8()在所有可能的情况下都可以应对AnsiToUtf8()将非常困难,即使不是不可能,尤其是考虑到要在其上开发代码的计算机的语言环境设置可能与最终运行代码的计算机。

I think the cleanest way to resolve this would be to use UTF-8 encoding uniformly in source files, assuming you want to use code points in string literals outside the areas where the default encoding and Unicode overlap. 我认为解决此问题的最干净方法是在源文件中统一使用UTF-8编码,假设您要在默认编码和Unicode重叠的区域之外使用字符串文字中的代码点。

Another way would be to internationalise the code so that the source files did not contain extended characters, and use something like GNU gettext or similar to handle translations. 另一种方法是使代码国际化,以便源文件不包含扩展字符,并使用诸如GNU gettext之类的东西来处理翻译。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM