Interações página de código do Windows com padrão C / C ++ nomes de arquivos?

votos
5

Um cliente está reclamando que o nosso código usado para escrever arquivos com caracteres japoneses no nome do arquivo, mas não funciona em todos os casos. Sempre usei apenas o bom e velho char * cordas para representar nomes, por isso veio como um pouco de um choque para mim que ele já trabalhou, e nós não fizemos nada Estou ciente de que deveria ter feito parar de trabalhar. Eu tinha-lhes me enviar um arquivo com um nome de arquivo embutido nele exportados do nosso software, e parece que as cordas utilizar caracteres hexadecimais 82 e 83 como o primeiro caractere de uma seqüência de dois bytes para representar os caracteres japoneses. Bisbilhotando on-line me leva a acreditar que este é provavelmente Shift_JIS e / ou Windows página de código 932.

Parece-me que o que está acontecendo é anteriormente tanto fopen e ofstream :: open nomes de arquivos aceitos usando esta página de códigos; agora só fopen faz. Eu verifiquei a documentação fopen Visual Studio, e não vejo nenhum indício de que faz uma cadeia aceitável para passar para fopen.

No curto prazo, eu estou esperando que alguém pode lançar alguma luz sobre Windows fopen contra ofstream :: questão aberta específica para mim. No longo prazo, eu realmente gostaria de saber a forma aceita de abertura Unicode (e outros?) Nomes de arquivos em C ++, no Windows, Linux e OS X.

Editado para acrescentar: Eu acredito que o abre esse trabalho é feito na localidade C, enquanto que os que não trabalham são feitas em qualquer localidade padrão do cliente é. No entanto, isso tem sido o caso há anos, e a versão antiga do programa ainda funciona hoje em seu sistema, de modo que este parece uma possibilidade remota para explicar a questão que estamos vendo.

Update: eu expulso um pequeno programa de testes para o cliente. Ter verificado que fopen funciona bem com o nome do arquivo SHIFT_JIS, e std :: ofstream não. Isto é, em Visual Studio 2005, e aconteceu independentemente de eu usei a localidade padrão ou a localidade C.

Eu ainda estou interessado se alguém tem uma explicação para este comportamento (e por que misteriosamente mudou? - talvez um service pack do VS2005) e esperando para montar um abrangente melhores práticas para lidar com nomes de arquivo Unicode em C ++ portáteis código.

Publicado 26/01/2009 em 19:25
fonte usuário
Em outras línguas...                            


6 respostas

votos
0

Estou quase certo de que no Linux, a seqüência de nome de arquivo é uma string UTF-8 (no sistema de arquivos EXT3, por exemplo, os caracteres única proibidos são corte e NULL), armazenada em um normais char *. A página man não parece mencionar codificação de caracteres, que é o que me leva a acreditar que é o padrão do sistema de UTF-8. OS X provavelmente usa o mesmo, uma vez que vem de raízes semelhantes, mas eu sou menos certeza sobre isso.

Respondeu 26/01/2009 em 19:41
fonte usuário

votos
0

Você pode ter que definir a localidade linha para a localidade padrão do sistema. Veja aqui para uma possível razão para os seus problemas: http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=100887

Respondeu 26/01/2009 em 20:37
fonte usuário

votos
2

Eu não estou ciente de qualquer maneira portátil de usar arquivos unicode usando bibliotecas de sistema padrão. Mas existem algumas estruturas que fornecem funções portáteis, por exemplo:

  • para C: simplista utiliza nomes de ficheiros em UTF-8;
  • para C ++: glibmm também utiliza nomes de ficheiros em UTF-8, requer superficial;
  • para C ++: boost pode usar wstring para nomes de arquivo.

Tenho certeza estruturas .NET / mono também contêm funções filesystem portáteis, mas eu não os conheço.

Respondeu 03/02/2009 em 09:42
fonte usuário

votos
0

Mac OS X usa Unicode como sua codificação de caracteres nativa. Os objetos básicos de cordas são CFString e NSString. Eles armazenar matriz de caracteres como Unicode.

Respondeu 05/02/2009 em 11:30
fonte usuário

votos
3

Funções como fopen ou ofstream :: open levar o nome do arquivo como char *, mas que é interpretado como sendo na página de código do sistema.

Isso significa que ele pode ser um personagem japonesa representada como Shift-JIS (cp932) ou chinês simplificado (Big 5 / cp936), coreano, árabe, russo, o nome dele (contanto que corresponde à página de código do sistema OS).

Isso também significa que ele pode usar nomes de arquivos japoneses em um sistema japonês somente. Alterar a página de código do sistema e da aplicação "pára de funcionar" Eu suspeito que isso é o que acontece aqui (há grandes mudanças no Windows desde o Windows 2000, nesta área).

Isto é como você alterar a página de código do sistema: http://www.mihai-nita.net/article.php?artID=20050611a

No longo prazo, você pode considerar a mudança para Unicode (e usando _wfopen, wofstream).

Respondeu 09/02/2009 em 10:36
fonte usuário

votos
0

É alguém ainda vendo isso? Acabei pesquisado esta questão e não encontrou respostas em qualquer lugar, para que eu possa tentar explicar minhas descobertas aqui.

No VS2005 a manipulação fstream arquivo é o homem impar para fora: ele não usa a codificação padrão do sistema, o que você começa com GetACP e definir no Painel de Controle / Região e Idioma / Administrativo. Mas sempre CP 1252 - Eu acredito.

Isso pode causar grande confusão, e Microsoft removeu esta peculiaridade em versões posteriores VS.

Todas as soluções alternativas para VS2005 têm suas desvantagens:

  1. Converter seu código para usar Unicode em todos os lugares

  2. Jamais fstreams abertas usando nomes de personagens estreitas, sempre converter a eles para Unicode usando o padrão sistema de codificação mesmo, o uso de largura filename caráter aberto / ctor

  3. Recupere a página de código usando GetACP (), em seguida, fazer uma

setlocale de harmonização:

setlocale (LC_ALL, ("." + lexical_cast<string> (GetACP())).c_str())
Respondeu 09/08/2013 em 20:41
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more