Um cliente está reclamando que nosso código costumava gravar arquivos com caracteres japoneses no nome do arquivo, mas não funciona mais em todos os casos. Nós sempre usamos boas e antigas char * strings para representar nomes de arquivos, então me surpreendeu o fato de alguma vez ter funcionado, e não fizemos nada do que eu saiba que deveria ter feito com que parasse de funcionar. Mandei que eles me enviassem um arquivo com um nome de arquivo incorporado exportado de nosso software, e parece que as seqüências de caracteres usam caracteres hexadecimais 82 e 83 como o primeiro caractere de uma sequência de bytes duplos para representar os caracteres japoneses. Analisar on-line leva-me a acreditar que essa é provavelmente a SHIFT_JIS e / ou a página de código 932 do Windows.

Parece-me que o que está acontecendo é anteriormente aberto e ofstream :: aberto aceito nomes de arquivos usando esta página de código; agora apenas fopen faz. Verifiquei os documentos fopen do Visual Studio e não vejo nenhuma dica do que faz com que uma seqüência aceitável seja passada para fopen.

No curto prazo, espero que alguém possa lançar alguma luz sobre o problema específico do Windows fopen versus ofstream :: open para mim. A longo prazo, eu realmente gostaria de saber a maneira aceita de abrir nomes de arquivos Unicode (e outros?) Em C ++, no Windows, Linux e OS X.

Editado para adicionar: acredito que as aberturas que o trabalho são feitas no código do idioma "C", enquanto as que não funcionam são feitas no código de idioma padrão do cliente. No entanto, esse tem sido o caso há anos, e a versão antiga do programa ainda funciona hoje em seu sistema, portanto isso parece um longo caminho para explicar o problema que estamos vendo.

Atualização: enviei um pequeno programa de teste para o cliente. Verificou que o fopen funciona bem com o nome do arquivo SHIFT_JIS e o std :: ofstream não. Isso está no Visual Studio 2005 e aconteceu independentemente de eu ter usado a localidade padrão ou a localidade "C".

Ainda estou interessado se alguém tiver uma explicação para esse comportamento (e por que ele mudou misteriosamente - talvez um service pack do VS2005?) E na esperança de reunir uma abrangente "melhores práticas" para lidar com nomes de arquivos Unicode em código C ++ portátil.