On 10.02.2018 09:59, Thorsten Schöning wrote:
> Hi all,
>
> I'm using the PHP webapp WebSVN and ran into encoding problems with
> file names in my Linux environment when e.g. creating downloadable
> Zipr or Tars using WebSVN. I worked around those problems using a
> simple shell wrapper like the following:
>
>> #!/bin/sh
>>
>> export LC_CTYPE=de_DE.UTF-8
>> svn $*
> Other people fixed this differently by using setlocale in WebSVN
> directly and forwarding that value using LANG per shell invokation:
>
>> // Make sure that the input locale is set up correctly
>> setlocale(LC_ALL, $config->getLocale());
>> $cmd = $this->svnCommandString('blame', $path, $rev, $peg).' > '.quote($filename);
>> if ($config->getLocale() != null)
>> $cmd = "LANG=".setlocale(LC_ALL, 0)." ".$cmd;
> A command line like this doesn't work on Windows, it at least needs a
> different syntax. I know the needed syntax and all but am not sure if
> it is even necessary to handle Windows specifically the same way.
>
> I think this depends on if the svn binary honors the env var LANG on
> Windows at all? PHP itself simply executes "cmd.exe /C '...' in the
> end. So which encoding is used in this case with and without setting a
> LANG variable? I have the feeling it's that of the invoked cmd.exe
> process in both cases because APR handles that specially for Windows?
On Windows, the locale is a system-wide property and it's not defined by
environment variables. Nor does Subversion look at the environment, on
any platform; it uses the C setlocale() function to set the default
locale from the environment. On Unix, that ends up looking at
environment variables; on Windows, it uses a different mechanism.
Also, on Windows, Subversion (or rather, APR) knows that file names are
always written as Unicode, regardless of the system locale.
Since Subversion is not the tool that's creating your ZIP or TAR
packages, any encoding problems are more likely caused by the
surrounding (PHP/WebSVN) code.
-- Brane
Received on 2018-02-10 12:03:07 CET