[Implemented] Unicode support

[Blade]

I've a computer (win 2000) that displays correctly the files with japanese characters.

The filesystem demo (examples/sources/FileSystem.pb) can'd display those filename correctly, and the "ReadFile()" function can't open those files too.

Is there a way to "activate" unicode, perhaps one of the many API functions?

[plouf]

thats a limitation of PureBasic at the moment it opens only ansi (8bit)
it has been discussed in the past , and sometime it will added but i think it has not a high priority in ToDO list

btw if i am not wrong it should open them but incorrect .
i use this procedure to transform Unicode to Ansi but dunno if works with japanese

Code: Select all

Procedure.s UniCode2Ansi(UniString.s)
  AnsiString.s = Space(Len(Unistring)/2)
  WideCharTOMultiByte_(0,0,UniString,Len(UniString)/2,AnsiString,Len(UniString)/2,0,0)
  ProcedureReturn AnsiString
EndProcedure

tranformaedstring.s = Unicode2Ansi(StringreadedwithReadfile.s)

p.s. i would interest to know if work with japanese

[Blade]

btw if i am not wrong it should open them but incorrect .
i use this procedure to transform Unicode to Ansi but dunno if works with japanese

tranformaedstring.s = Unicode2Ansi(StringreadedwithReadfile.s)

p.s. i would interest to know if work with japanese

Well, I used this way:

Code: Select all

text.s=UniCode2Ansi(DirectoryEntryName())

The variable was then used to fill an IconTextGadget...

All I could see was a lot of ????????????????

Do a .s handles correctly Ansi strings?
if yes, do Gadgets handle correctly Ansi strings?

Perhaps the gadget should be filled with another API function...

(And if a filename is simple ASCII, the function will destry it?)

I think your function works with greek characters... how do you pass them to a gadget?

[Num3]

Check for the alternative Purebasic Editor: JaPbe

I think it supports unicode!!!

[Blade]

Check for the alternative Purebasic Editor: JaPbe

I think it supports unicode!!!

I like it very much, but the problem here is not what you type in the editor, but how filenames, strings and gadgets work together...
I don't need any unicode in the program source, actually the function for disk access don't like to behave with unicode...

[oldefoxx]

Unicode was going to be the next big thing some year ago, and Microsoft
pledged support for it.

But as I see it, people have come to realize that their is no common alphabet, word, or sentence structure between the many diverse languages that exist. So the question is, how do you cope with the many
sumbols that are there, such as finding equivalents in other alphabets and
languages, and how do you cope with the many symbols that are not there, such as the even greater number of symbols or word signs that have not been included.

I think you are seeing instead, a rise in the number of programs that try to convert one language to another, and in the development of fonts, which allow sumbols to be constructed specific to each language and to each designated alphabet. So in a sence, based on my impressions of how the field has shifted, Unicode has proved to be inadequate for the many issues involved. True, with 65,535 symbols made available with double-byte code, one might believe that you could support 256 different alphabets, each with 255 symbols -- but there are a number of pictorial languages that requre thousands of ideograms to represent not only letters or numbers, but even whole phrases or concepts.

Setting aside two bytes instead of just one for each character is trivial, but what code value needs to go there? Where are you going to find a common representation that various applications and file managers are going to work with, as well as finding appropriate symbolic representations for the characters when you try to display them on the screen or send them to a printer?

The fact that many people are addressing this issue means that some progress is being made, but it also means that it is fragmented and not towards any form of unity. Certainly various software concerns, which include Microsoft, have made some gains, but I am sure that this has been in large part to a staff of humans that work on translation issues between various languages. And if a giant like Microsoft has yet to make it happen though automation, and cannot support it within their operating system as a feature, then small companies, like most of the rest, are just going to have to wait until that threshold is crossed, if ever.

That's my take on it. You have trouble with Japanese -- heck, I have trouble just trying to get a bit of german translated into english so that I can understand a program - and english has a strong kinship to german!

[plouf]

Check for the alternative Purebasic Editor: JaPbe

I think it supports unicode!!!

I like it very much, but the problem here is not what you type in the editor, but how filenames, strings and gadgets work together...
I don't need any unicode in the program source, actually the function for disk access don't like to behave with unicode...

try this its specify the codepage 932 is the japanese ansi codeset (under windows at least) also be sure that you use a font for gadgets that supports
japanese i.e. Arial

Code: Select all

Procedure.s UniCode2Ansi(UniString.s)
  AnsiString.s = Space(Len(Unistring)/2)
  WideCharTOMultiByte_(932,0,UniString,Len(UniString)/2,AnsiString,Len(UniString)/2,0,0)
  ProcedureReturn AnsiString
EndProcedure

as oldefoxx said some languanges need more than 127 chars to represent their full glyphs i think japanese fell to that category but theorically
API functions should be able to cope with that ,
greek as you said works but greek alphabet needs 24*2 + 21 chars
if i remember correct ,at least in past, some special font engines used for japanese (in amiga there were a couple)

[Blade]

try this its specify the codepage 932 is the japanese ansi codeset (under windows at least) also be sure that you use a font for gadgets that supports
japanese i.e. Arial

Nope... now I see some more alien character, but nothing that can remember some asian charset...

as oldefoxx said some languanges need more than 127 chars to represent their full glyphs i think japanese fell to that category but theorically
API functions should be able to cope with that ,
greek as you said works but greek alphabet needs 24*2 + 21 chars
if i remember correct ,at least in past, some special font engines used for japanese (in amiga there were a couple)

A japanese can know about 4000-8000 characters (ideograms), so the real amount should be much more than 8000...

I've found some programs that handle japanese well, (i.e. WinMX,eMule) but the DivX Player is unable to load movies named in japanese, so I have to fully rename the files, or use the Mediaplayer (Microsoft!) that handles them correctly...
This to say the CAN BE DONE

I wonder if RapidQ (the nice free basic no more developed) , that was developed by a japanese, could handle unicode natively...

Perhaps I should dig more in Msdn...