<div dir="ltr"><div><div><div><div>A little more playing around and a lot of reading Windows documentation reveals:<br></div>-according to James, svn translates the filenames to UTF16 when checking out on Windows 7<br></div><div>-when you scan a directory with findfiles/DIR (which calls FindFilesA) it converts the filenames to the current codepage, possibly lossly. If it's lossy then the filename is useless, it can't be used for anything.  (I couldn't find this fact stated anywhere in the Windows documentation!) But even if it's not 7-bit ASCII, if it's on the ANSI codepage, like héllo.txt on a Latin-1 (US/Western European) machine then it will work.<br></div><div>-Windows doesn't even turn combining characters into precomposed characters when converting to Latin1, e.g. À turns into A` instead of À. This doesn't matter, the filename would be broken either way<br></div>-If you ask findfiles() for subdirectories it does an additional check, which fails for unencodable filenames because the filename is invalid. So those subdirectories won't even display in the browser<br></div>-There are exactly two possible ways to allow reading files with unicode characters on Windows:<br>--replace DIR with a modified version using FindFilesW instead, encode the filename into a transport encoding (namely UTF8) so that we can store it in strings everywhere, and even properly display it in the engine by calling decode_filename** and then modify every function that gives Windows or FB a filename to convert the filename back to UTF16 first. That's not a huge amount of work, because we already have wrappers for nearly all FB file IO commands and use them nearly everywhere. You wouldn't be able to use OPEN, KILL, MKDIR directly anymore.<br>--replace DIR with a modified version using FindFilesW, and then if the file can't be encoded, get a short 8.3 compatibility filename for the file and pass that back instead. Unfortunately this means that a filename like ЦЧШЩN.txt becomes something completely nonsensical like NFE9D~1.TXT.<br></div>(Some other sources of filenames also need to be handled, like cmdline/drag-dropping .rpg files in a funky path, and I know nothing about those)<br><div><div><br></div><div>** it's my intention to switch to UTF8 internally, and potentially even fall back to a .ttf font to render characters not in the font. Making everything UTF8-aware is the same thing as making everything aware of text markup codes. Most strings in the engine can continue to be treated as 8bit at first because they can't contain either filenames or markup, but when we further want to support fonts larger than 256 characters, we will need to shift most of the rest over. That means needing to write replacements for all string functions like LEFT, MID, etc. Heck, we can just #undef the builtin versions and redefine them! wstrings won't be used anywhere.<br><br></div><div>However, I am aware that Unicodification is NOT a priority, it should be a very low priority, I think I remember just one bug report about non-ascii characters, in fact even in my previous work on unicode I never noticed that on Windows we can't open files with non-ANSI filenames. But it's nice to finally understand how it always works, and I do still want to support larger fonts and text markup everywhere, which is a far more useful goal.<br></div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On 4 November 2016 at 05:19,  <span dir="ltr"><<a href="mailto:subversion@hamsterrepublic.com" target="_blank">subversion@hamsterrepublic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">teeemcee<br>
2016-11-03 09:19:46 -0700 (Thu, 03 Nov 2016)<br>
698<br>
Add a couple test files with unicode filenames<br>
<br>
On my system I have UTF8 encoded filenames; I don't quite know<br>
what will happen after going through git and svn and ending up on<br>
a different system.<br>
<br>
The .rpg is just a blank file, with a Cyrillic filename, so shows<br>
up as just a bunch of ?????'s in Custom but works just fine<br>
under GNU/Linux. The filename appears fine when viewed in a Windows<br>
VM, but Custom under Windows can't load it.<br>
<br>
The .txt contains exported textboxes, and its filename has lots<br>
of pairs of side-by-side pre-composed Latin-1 characters and<br>
characters decomposed into ASCII base character plus modifier.<br>
It appears and works perfectly in Custom under GNU/Linux but<br>
not Windows.<br>
---<br>
A   wip/testgame/unicodetest/<br>
A   wip/testgame/unicodetest/?\<wbr>195?\128A?\204?\128?\195?\<wbr>129A?\204?\129?\195?\130A?\<wbr>204?\130?\195?\131A?\204?\131?<wbr>\195?\132A?\204?\136?\195?\<wbr>133A?\204?\138?\195?\135C?\<wbr>204?\167?\195?\136E?\204?\128?<wbr>\195?\137E?\204?\129?\195?\<wbr>138E?\204?\130?\195?\139E?\<wbr>204?\136?\195?\140I?\204?\128?<wbr>\195?\141I?\204?\129?\195?\<wbr>142I?\204?\130?\195?\143I?\<wbr>204?\136?\195?\145N?\204?\131?<wbr>\195?\146O?\204?\128?\195?\<wbr>147O?\204?\129?\195?\148O?\<wbr>204?\130?\195?\149O?\204?\131.<wbr>txt<br>
A   wip/testgame/unicodetest/?\<wbr>206?\154?\206?\177?\206?\187?\<wbr>206?\183?\206?\188?\206?\173?\<wbr>207?\129?\206?\177/<br>
A   wip/testgame/unicodetest/?\<wbr>206?\154?\206?\177?\206?\187?\<wbr>206?\183?\206?\188?\206?\173?\<wbr>207?\129?\206?\177/?\206?\186?<wbr>\207?\140?\207?\131?\206?\188?<wbr>\206?\181!.rpg<br>
______________________________<wbr>_________________<br>
Ohrrpgce mailing list<br>
<a href="mailto:ohrrpgce@lists.motherhamster.org">ohrrpgce@lists.motherhamster.<wbr>org</a><br>
<a href="http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org" rel="noreferrer" target="_blank">http://lists.motherhamster.<wbr>org/listinfo.cgi/ohrrpgce-<wbr>motherhamster.org</a><br>
</blockquote></div><br></div></div></div>