Unicode again
in [Win32 API]
|
From: r_z_aret on 27 Apr 2010 16:46 On Tue, 27 Apr 2010 07:05:19 +0200, "Jean" <nosp-jean(a)free.fr> wrote: >Hi Robert > >>> I _think_ you are trying to support UNICODE and ASCII files in one >> program >yes, correct > >>I assumed "does not work" meant "does not compile". >no, it compiles correctly, the comparison (==) is not effective > >I use VC6 and C SDK, for XP, Vista and 7, with all the previous advices i >compile now with UNICODE and _UNICODE. This won't have any affect on the code you showed us. It affects the definitions of TCHAR and its relatives, but you are explicitly using WCHAR. And it effects the definitions of macros that look like function names (e.g. MessageBox), but you are explicitly using Unicode functions. >All my files accesses are made with _wfopen, all the readings with fread and >an unsigned char buffer. >It works fine with western, greek, chinese and russian file names :-) If you explicitly use Unicode functions and hard code explicitly Unicode names, then your code certainly should work. >For listing the files i use a _w_finddata_t structure with _wfdindfirst, >_wfindnext, it works too What about comparisons like the one that started this thread? >For displaying those file names in listviews ot statusbars, window title and >so on i use WCHAR everywhere > >Jean > ><r_z_aret(a)pen_fact.com> a �crit dans le message de news: >ni0ct5tluajljpgh319i20oo1emleu7bbi(a)4ax.com... >> On Sun, 25 Apr 2010 16:32:52 +0200, "Jean" <nosp-jean(a)free.fr> wrote: >> >> My comments may be a paraphrase of Jonware's comments. See below (in >> line). >> >>>Hello >>> >>>this code works: >>> >>>unsigned char buffer[1025]; >>>fopen("toto.bmp", "rb"); >>>fread(buffer, sizeof(unsigned char),1024, pf); >>>fclose(pf); >>> >>>if(buffer[0] == 'B' && buffer[1] == 'M') >>> ... >>> >>>this code does not work: (compiled with UNICODE and _UNICODE) >>> >>>WCHAR buffer[1025]; >>>_wfopen(L"toto.bmp", L"rb"); >>>fread(buffer,sizeof(WCHAR),1024,pf); >> >> This line will read two bytes into each of the two byte elements of >> buffer. >> >> >>>fclose(pf); >>> >>>if(buffer[0] == 'B' && buffer[1] == 'M') >>> ... >>> >>>it's the comparison that does not work. >>>(i tried if(buffer[0] == L'B' && buffer[1] == L'M') too) >>>any idea ? >> >> This will compare the two bytes in buffer[0] with the two characters >> in L'B' and the two bytes in buffer[1] with the two characters in >> L'M'. This will probably not work as you expect unless the input file >> is Unicode text (so each character takes up two bytes in the file). >> >> I _think_ you are trying to support UNICODE and ASCII files in one >> program. I don't think you can do that unless you have a separate >> section for each, and your program determines which type of file >> you're reading and chooses the right code. I believe it is very tricky >> to determine by looking at a file's contents whether it is UNCODE or >> ASCII. That is why UNICODE files are usually marked by a preceding BOM >> (Byte Order Marker). For more info about BOM, use Google to look it up >> in this newsgroup. >> >> Something of a nit pick: >> When I first read your note, I assumed "does not work" meant "does not >> compile". You might try to be more explicit in the future. >> >> >>> >>>jean >>> >> >> ----------------------------------------- >> To reply to me, remove the underscores (_) from my email address (and >> please indicate which newsgroup and message). >> >> Robert E. Zaret, MVP >> PenFact, Inc. >> 20 Park Plaza, Suite 400 >> Boston, MA 02116 >> www.penfact.com >> Useful reading (be sure to read its disclaimer first): >> http://catb.org/~esr/faqs/smart-questions.html > ----------------------------------------- To reply to me, remove the underscores (_) from my email address (and please indicate which newsgroup and message). Robert E. Zaret, MVP PenFact, Inc. 20 Park Plaza, Suite 400 Boston, MA 02116 www.penfact.com Useful reading (be sure to read its disclaimer first): http://catb.org/~esr/faqs/smart-questions.html
From: Jean on 30 Apr 2010 09:13
>What about comparisons like the one that started this thread? I convert first to char* Jean <r_z_aret(a)pen_fact.com> a �crit dans le message de news: i1det511tess58h2rhi9ttcuebkp3nn79k(a)4ax.com... > On Tue, 27 Apr 2010 07:05:19 +0200, "Jean" <nosp-jean(a)free.fr> wrote: > >>Hi Robert >> >>>> I _think_ you are trying to support UNICODE and ASCII files in one >>> program >>yes, correct >> >>>I assumed "does not work" meant "does not compile". >>no, it compiles correctly, the comparison (==) is not effective >> >>I use VC6 and C SDK, for XP, Vista and 7, with all the previous advices i >>compile now with UNICODE and _UNICODE. > > This won't have any affect on the code you showed us. It affects the > definitions of TCHAR and its relatives, but you are explicitly using > WCHAR. And it effects the definitions of macros that look like > function names (e.g. MessageBox), but you are explicitly using Unicode > functions. > > >>All my files accesses are made with _wfopen, all the readings with fread >>and >>an unsigned char buffer. >>It works fine with western, greek, chinese and russian file names :-) > > If you explicitly use Unicode functions and hard code explicitly > Unicode names, then your code certainly should work. > > >>For listing the files i use a _w_finddata_t structure with _wfdindfirst, >>_wfindnext, it works too > > What about comparisons like the one that started this thread? > > >>For displaying those file names in listviews ot statusbars, window title >>and >>so on i use WCHAR everywhere >> >>Jean >> >><r_z_aret(a)pen_fact.com> a �crit dans le message de news: >>ni0ct5tluajljpgh319i20oo1emleu7bbi(a)4ax.com... >>> On Sun, 25 Apr 2010 16:32:52 +0200, "Jean" <nosp-jean(a)free.fr> wrote: >>> >>> My comments may be a paraphrase of Jonware's comments. See below (in >>> line). >>> >>>>Hello >>>> >>>>this code works: >>>> >>>>unsigned char buffer[1025]; >>>>fopen("toto.bmp", "rb"); >>>>fread(buffer, sizeof(unsigned char),1024, pf); >>>>fclose(pf); >>>> >>>>if(buffer[0] == 'B' && buffer[1] == 'M') >>>> ... >>>> >>>>this code does not work: (compiled with UNICODE and _UNICODE) >>>> >>>>WCHAR buffer[1025]; >>>>_wfopen(L"toto.bmp", L"rb"); >>>>fread(buffer,sizeof(WCHAR),1024,pf); >>> >>> This line will read two bytes into each of the two byte elements of >>> buffer. >>> >>> >>>>fclose(pf); >>>> >>>>if(buffer[0] == 'B' && buffer[1] == 'M') >>>> ... >>>> >>>>it's the comparison that does not work. >>>>(i tried if(buffer[0] == L'B' && buffer[1] == L'M') too) >>>>any idea ? >>> >>> This will compare the two bytes in buffer[0] with the two characters >>> in L'B' and the two bytes in buffer[1] with the two characters in >>> L'M'. This will probably not work as you expect unless the input file >>> is Unicode text (so each character takes up two bytes in the file). >>> >>> I _think_ you are trying to support UNICODE and ASCII files in one >>> program. I don't think you can do that unless you have a separate >>> section for each, and your program determines which type of file >>> you're reading and chooses the right code. I believe it is very tricky >>> to determine by looking at a file's contents whether it is UNCODE or >>> ASCII. That is why UNICODE files are usually marked by a preceding BOM >>> (Byte Order Marker). For more info about BOM, use Google to look it up >>> in this newsgroup. >>> >>> Something of a nit pick: >>> When I first read your note, I assumed "does not work" meant "does not >>> compile". You might try to be more explicit in the future. >>> >>> >>>> >>>>jean >>>> >>> >>> ----------------------------------------- >>> To reply to me, remove the underscores (_) from my email address (and >>> please indicate which newsgroup and message). >>> >>> Robert E. Zaret, MVP >>> PenFact, Inc. >>> 20 Park Plaza, Suite 400 >>> Boston, MA 02116 >>> www.penfact.com >>> Useful reading (be sure to read its disclaimer first): >>> http://catb.org/~esr/faqs/smart-questions.html >> > > ----------------------------------------- > To reply to me, remove the underscores (_) from my email address (and > please indicate which newsgroup and message). > > Robert E. Zaret, MVP > PenFact, Inc. > 20 Park Plaza, Suite 400 > Boston, MA 02116 > www.penfact.com > Useful reading (be sure to read its disclaimer first): > http://catb.org/~esr/faqs/smart-questions.html |