|
| [WDM20] Problem with Chinese characters... |
| Iniciado por guest, 08,mar. 2016 14:32 - 10 respuestas |
| |
| | | |
|
| |
| Publicado el 08,marzo 2016 - 14:32 |
Hi guys,
I've got an issue with Chinese characters appearing when I read a (text) CSV file!
When I open the CSV file in the Android app in GO mode, then use fReadLine, I can't get to the bottom of why it didn't seem to be working as expected. When I added a Trace command I discovered that the Trace(sCSVRow) line of code below displays as Chinese characters: :confused:
(Note: the RETURN at the end is just so the rest of the processing doesn't execute - it's just for trying to trace this issue)
sFullFileName is string = fDataDir() + "/" + sFileName nFileNum = fOpen(sFullFileName) // Was the file opened or was there an error? IF nFileNum = -1 THEN // Display error message and go back to the button ToastDisplay("Error: File was not found in " + fDataDir(),toastLong,vaMiddle,haCenter) // Enable plane 0 (main) after error WIN_Data_Import..Plane = 0 // Return to specific screen object ReturnToCapture(BTN_Course_Material) ELSE // Read the first row and throw it away - it's just headers sCSVRow = fReadLine(nFileNum) Trace("This appears in non-Chinese chars!") Trace(sCSVRow) RETURN
I've looked at the project settings, but can't see why this would be happening. The text file, when opening notepad or Notepad++ looks fine :confused:
Any idea where I can look? |
| |
| |
| | | |
|
| | |
| |
| Publicado el 08,marzo 2016 - 14:46 |
Hi Daren
you have an ansi/unicode problem.
Windows is ansi, android is unicode, and you are declaring your string as string, instead of specifying ansi or unicode, so basically you don't know what kind of file you are dealing with and how.
Best regards |
| |
| |
| | | |
|
| | |
| |
| Publicado el 08,marzo 2016 - 15:14 |
| Thanks Fabrice! I thought it would be an ANSI/Unicode issue, but silly me... I was expecting (...more like "hoping") that WDM would realise that I was developing in Windows and deploying via an Android project :cheers: |
| |
| |
| | | |
|
| | |
| |
| Publicado el 08,marzo 2016 - 16:49 |
Hi Darren,
in android , Watch out for UTF8
UTF8 is not UNICODE
 :D:D:D:D:D:D:D:D:D |
| |
| |
| | | |
|
| | |
| |
| Publicado el 08,marzo 2016 - 17:10 |
Thanks!
I'm so used to developing in WD for Windows that I'd forgotten about specifying the format of string vars :rolleyes: |
| |
| |
| | | |
|
| | |
| |
| Publicado el 08,marzo 2016 - 21:51 |
Hi Darren,
I never specfify it at string level unless I'm interacting with something external that requires a conversion.
I specify the Unicode/Non-Unicode aspect always at configuration level.
A WD program for exemple can have a unicode/non-unicode configuration that compiel into a unicode supporting exe and a non-unicode supporting exe.
But anyway, I don't think I have create a non unicode program anymore since WX V18.
All my configurations are flagged as unicode.
When doing Windows API calls I use the ASCIIZ string type mostly but I am noticing that on the newest Windows 64 bit server platforms almost all API's hava a unicode variant as well.
Just my 2 cents,
Peter Holemans |
| |
| |
| | | |
|
| | |
| |
| Publicado el 08,marzo 2016 - 22:10 |
Thanks Peter - point taken and worth knowing. :xcool:
For this test app I've just saved the external file as Unicode and defined the string I'm reading into as Unicode also - now I'm getting somewhere :cheers: |
| |
| |
| | | |
|
| | |
| |
| Publicado el 09,marzo 2016 - 13:44 |
Hi Peter,
I think that your method is dangerous, so I always specify the type of string when declaring them. This is why:
- I'm sharing code between project (classes by example)
- some of these projects are for customers who are used to work in ansi (historical reason, no need of unicode, etc)
- some of these projects are for environments/cases where unicode can creates problem (web/web service/etc.)
- and most of the projects are very happy in unicode
So If I rely on the configuration settings and import a class from another project, I suddenly have to verify everything done in the imported class, as I cannot be sure that the original project had the same configuration settings. Instead, I use the following in my declarations:
usString is unicode string
asString is ansi string
ccsString is string
This way, I always know, when I work on a string, if it is unicode, ansi or (ccs) configuration coded. The ccs case is used for cases like the return or external function, when I know that depending on the system the code is running on, I'll get a string of a different type.
Best regards |
| |
| |
| | | |
|
| | |
| |
| Publicado el 09,marzo 2016 - 15:34 |
Hi Fabrice,
Thanks for the heads up but I am not sure I understood your remark completely as I never had the same potential issue tipping point as you describe...
I tend to manage this at configuration level (ansi or unicode excutable) rather than at the declaration point of individual variables which makes it a tedious job to alter between them for the same source code imho. (Or I don't understand what you are trying to say which is also possible...  )
I also have classes shared between unicode and ansi projects and they either compile into an executable as ansi or unicode depending on the targetted configuration I am generating to. In both cases, the class will work for me identical in ansi and unicode configurations and within different projects. And in there, strings just remain strings. Only at executable level they become ansi or unicode.
When I really need to make sure that a conversion is done because of integrating with external software or API calls I do an explicite test and declare the string types explicitely depending on the mode I am in... I need to verify my code (no WX at hand here) but I believe it something like "if InUnicodeMode() then ...". Eitehr they declarea as ansi, either as unicode...
I 'll provide an example later on if you want.
If I miss understood your point, thanks for enlightening me but I never had the issue you seem to describe.
Cheers,
Peter |
| |
| |
| | | |
|
| | |
| |
| Publicado el 10,marzo 2016 - 09:29 |
Hi Fabrice,
Thanks for the heads up but I am not sure I understood your remark completely as I never had the same potential issue tipping point as you describe...
I tend to manage this at configuration level (ansi or unicode excutable) rather than at the declaration point of individual variables which makes it a tedious job to alter between them for the same source code imho. (Or I don't understand what you are trying to say which is also possible... )
I also have classes shared between unicode and ansi projects and they either compile into an executable as ansi or unicode depending on the targetted configuration I am generating to. In both cases, the class will work for me identical in ansi and unicode configurations and within different projects. And in there, strings just remain strings. Only at executable level they become ansi or unicode.
When I really need to make sure that a conversion is done because of integrating with external software or API calls I do an explicite test and declare the string types explicitely depending on the mode I am in... Next either I declare as ansi, either as unicode...
This way a unicode configuration will compile into a unicode exe and an ansi configuration will compile into an ansi exe in WD.
If I miss understood your point, thanks for enlightening me but I never had the issue you seem to describe.
Cheers,
Peter |
| |
| |
| | | |
|
| | |
| |
| Publicado el 08,agosto 2016 - 06:05 |
Hi,
I have this problem from WDM, when sending unicode strings to socket. My data is '啤酒'
In my receiving end which is a foxpro program, the first chinese character is I received it correctly , but the second chinese character is I received a garbage data.
So I built another program which is a foxpro to foxpro sending socket data and this two characters was received correctly. So I conclude that the problem is within the WDM sending data through the socket as unicode.
Have anybody experience this? I'm using WDM20 version. I hope somebody can help me. |
| |
| |
| | | |
|
| | | | |
| | |
|