No File/Foldername Unicode support at all?
BlitzMax Forums/BlitzMax Programming/No File/Foldername Unicode support at all?
| ||
| I got a email from a person who want to translate my application to russia, but I have ran into big troubles. It seen no file commands can read any of Cyrillic chars in files and folder names. I have not looked it does this on Linux, but it does these quicks in Windows. All it does it just translate any letter to ? I'm use Vista can fine can see the chars I got from that email. |
| ||
bwt this code does not work and still shot the same dir as the first:
ChangeDir("D:\Musik\temp")
Print CurrentDir$()
ChangeDir("D:\Musik\temp\Предыдущая")
Print CurrentDir$()
Look like BlitzMax filesystem do not work with unicode at all? Why do it so support unicode strings? |
| ||
| Hi, No, there is no filesystem level unicode support and none is planned. |
| ||
| :-(. My App is not been arviable to translate to this language. The problem is I have created a Mp3 jukebox application with not needing to use ID3 tags (which I by now even wont passable with same reason). |
| ||
| Does this mean if I allow a player to enter their name using Unicode, then I save their profile using that name, it won't work? |
| ||
| Does this mean if I allow a player to enter their name using Unicode, then I save their profile using that name, it won't work? Seems to be exact what qould happen. |
| ||
| @Grey: This was mentioned in another thread about safe file name characters, some of them just won't work and don't throw error out, but the file won't be actually saved if the name contains some special characters. |
| ||
| OK thanks, looks like I'll have to rethink how my profile saving code works... |
| ||
| The problem is quite simple here: BM supports stone age windows (Win98 / ME) Good thing many might think. Bad thing here is that both only support Unicode through an extra patch and Win98 even only if you had the SE or updated to it. As both are abandonned you can't get this patch any further. Without that, unicode aware software just bombs out. (experience from Torque, annoying and hard to overcome. Either you have UC or you don't have it, point) If BM was simply put up to Windows 2000 minimum requirements (heck it asks for OSX 10.3 which would mean WinXP on the Windows side), adding unicode would be less of a problem. |
| ||
| It could been checking which OS and testing if unicode is in system or not? Example Vista seen to been support unicode in the box, while XP need to install addiation lanuage in most chase. This is simple because it might used for example music files, which they typically used thier own language. I have instead in my own software support romanization, so you can translate latin letters to a other alphabet. For data files, this should never been happen. I of course never use unicode letters to make sure it work on all machines. But it something other when I have created a jukebox application (MultiJuke) with language support. And what about Linux. I have not tested on this chase, how it does. |
| ||
| Grey Alien: You cant save unicode based filenames, so if they do it, it wont work. even requestDir didden't work with unicode..... So use number as savegame files, or use md5 or such hash based code to change the string into a latin filename freidly file using latin letters. |
| ||
| Thanks, yeah I'm going to have to swap to using a number and then reading them all in and reading the player names to fill up my profile list. |
| ||
| There is a dll to support unicode on win98: unicows.dll So I hope I see a day to support unicode filenames, so my app can use the same way as Media Player and Winamp (which both nothing have anything problems with them). Reading Unicode (UTF-8) text files is not a problem. There is code for it on this forum. |
| ||
| Once again, its not the OS that is the problem. BM does not support it in low level and it is not planned to come as you can see above in Marks post. Since first Win2k Release, Windows has had Unicode Support but Blitz never got any further than supporting unicode at String level. Something not happening in the last 6 years won't happen now just out of the nowhere. |
| ||
| Is it anyway to change the codepage than the standard one (I remember Latin use 437)? Example if you are in an russia codepage, the english chars are not available, and if you are in an english codepage, then the russia will not be available. |
| ||
| @Space Fractal Did you tried Win32API like SetCurrentDirectoryW()? However it'll become non-cross-platform. |
| ||
| No Not yet. MultiJuke was ported to Linux, so I might hold it cross platform. But I guess I got a workaround, but I wait for the report on the work from the email. It seen the Russia Windows actually used ascii table on filename with this charset used: http://www.ascii.ca/cp1251.htm Hence I have copy paste from the page (not source code) over to notepad (which seen support unicode in Vista) and save it as UTF-8. Then I used the table to convert the ascii filenames to unicode, so it show the currect codes: Type TCodebase Field Alphabet$ Field Char:String[]=New String[256] Global List:TList=New TList Global Count=0 Global current:String[]=New String[256] Global currentAlphabet$ Function Init() Local files$[] Local Path$=CurrentDir()+"/alphabet/" files=LoadDir(Path$, True) For Local t$ = EachIn files Local in:TTextStream=TextFileReader.CreateStream(path$+T$) If in<>Null Local s:TCodebase = New TCodebase While Eof(In)=0 Local TXT$=ReadLine(in) If Left$(TXT$,2).toInt()>0 Local Number=Left$(TXT$,3).toInt() TXT$=Right$(TXT$,Len(TXT$)-6) If Left$(TXT$,1)=" " Then TXT$=Right$(TXT$,Len(TXT$)-1) TXT$=Trim$(TXT$) Local Letter$=Left$(TXT$,2) Letter$=Trim$(Letter$) If Number>32 s.Char$[Number]=Letter$ Else s.Char$[Number]=" " EndIf EndIf EndWhile s.Alphabet$=StripAll$(t$) Count:+1 List.AddLast(s) EndIf Next EndFunction Function Set:Int(Alphabet$) currentAlphabet$="" current:String=New String[256] For Local s:TCodebase = EachIn List If Alphabet$=s.Alphabet$ For Local i=0 To 255 current[i]=s.Char[i] Next currentAlphabet$=s.Alphabet$ Return 1 EndIf Next EndFunction Function Name$(Number) If Number=>CountList(List) Then Return "" Return TCodebase(List.ValueAtIndex(Number)).Alphabet$ EndFunction Function Translate$(txt$) Local Result$="" For Local i=1 To Len(Txt$) Local char:Int=Asc(Mid$(Txt$, i,1)) Result$=Result$+Current[char] Next Return Result$ EndFunction EndType I hope that one works. For hiscore and general translating, I recommered to UTF-8 based text files and no not use unicode filename (this make sure it work on all OS when moving). There are a code on this forum to read them correctly (or use readtext() and savetext()). |
| ||
| I finally got some unicode file level support to work with using Pure Basic commands for files and send it to BlitzMax. Pure Basic seen to support unicode, but was a bit hidden and need to been enabled first and it stated in help it diddent support it and in other place it state fully supported. Otherwice I use some thing like this to get the dll to work when created:
Global WRAPPER_DLL
WRAPPER_DLL=LoadLibraryA("purebasicdll.dll")
Global ReadUnicodeDir$w(dir:Byte Ptr) "Win32" = GetProcAddress(WRAPPER_DLL,"ReadDir")
Global CheckFile:Int(dir$w) "Win32" = GetProcAddress(WRAPPER_DLL,"CheckFile")
Make sure to use the orignal blitz max commands when using Linux, since the above might break combatible. ..... Now I need to see I can get blitzmax to read files from memory using a pointer, returned from Pure Basic (might been only that way to get streams to work when it using unicode files). Here I might create a new thread. Lock this thread, if you wich. |
   |