Risposta breve
Il problema sta nel dot.exe
. GraphViz può aprire file con percorsi Unicode in Linux ma non in Windows, a meno che (forse) se compilato con Visual Studio 2005.
Ricerca
La tabella codici è impostata su 850
, codifica Vim su UTF-8
.
Non dà lo stesso errore esatto, ma dot.exe
sembra ricevere un argomento sbagliato. Ho provato a passare lo stesso nome file all'altro programma.
E ha funzionato perfettamente. L'esecuzione di entrambi dot.exe
e type
direttamente da cmd.exe
dà lo stesso risultato, quindi né la console di Windows né Vim sono il problema. La cosa successiva che poteva causare quell'errore era dot.exe
se stessa. Il mio sospetto era che non sapesse come gestire correttamente gli argomenti codificati Unicode, come nemmeno tutti i comandi della console fanno:
https://ss64.com/nt/chcp.html
Se hai bisogno del pieno supporto Unicode usa PowerShell. C'è ancora un supporto MOLTO limitato per Unicode nella shell CMD, piping, reindirizzamento e la maggior parte dei comandi sono ancora solo ANSI. Gli unici comandi che funzionano sono DIR, FOR / F e TYPE, questo permette di leggere e scrivere file (UTF-16LE / BOM) e nomi di file, ma non molto altro.
Ho cercato sul web se c'è supporto per Unicode in GraphViz e ho scoperto che supporta i file Unicode ma nulla riguardo al supporto Unicode per i nomi dei file. Né ho trovato alcun report sul tracker di bug GraphViz né post sul forum su chiunque fosse interessato a leggere un file denominato Unicode. Quindi ho cercato nella fonte. Ecco dot.exe
come appare il punto di ingresso:
graphviz-2.40.1\cmd\dot\dot.c
int main(int argc, char **argv)
{
. . .
/* --------------------> ARGS ARE BEING PASSED HERE */
gvParseArgs(Gvc, argc, argv);
. . .
Seguendo la argv
tana del coniglio:graphviz-2.40.1\lib\common\args.c
int gvParseArgs(GVC_t *gvc, int argc, char** argv)
{
int rv;
if ((argc = neato_extra_args(gvc, argc, argv)) < 0) return (1-argc);
if ((argc = fdp_extra_args(gvc, argc, argv)) < 0) return (1-argc);
if ((argc = memtest_extra_args(gvc, argc, argv)) < 0) return (1-argc);
if ((argc = config_extra_args(gvc, argc, argv)) < 0) return (1-argc);
/* --------------------> HERE GO ALL NON-FLAG ARTUMENTS */
if ((rv = dotneato_args_initialize(gvc, argc, argv))) return rv;
if (Verbose) gvplugin_write_status(gvc);
return 0;
}
graphviz-2.40.1\lib\common\input.c
int dotneato_args_initialize(GVC_t * gvc, int argc, char **argv)
{
for (i = 1; i < argc; i++) {
if (argv[i] && argv[i][0] == '-') {
. . .
/* --------------------> JUST CASUALLY COPYING CHAR POINTERS */
} else if (argv[i])
gvc->input_filenames[nfiles++] = argv[i];
}
E infine graphviz-2.40.1\lib\common\input.c
graph_t *gvNextInputGraph(GVC_t *gvc)
{
. . . .
/* --------------------> OPENING THE FILES FOR READ WITH FOPEN */
while ((fn = gvc->input_filenames[fidx++]) && !(fp = fopen(fn, "r"))) {
. . .
}
Come afferma l'MDSN:
La funzione fopen apre il file specificato dal nome file. _wfopen è una versione a caratteri larghi di fopen ; gli argomenti di _wfopen sono stringhe di caratteri ampi. _wfopen e fopen si comportano in modo identico altrimenti. Il semplice utilizzo di _wfopen non ha alcun effetto sul set di caratteri codificati utilizzato nel flusso di file.
In Visual C ++ 2005, fopen supporta flussi di file Unicode.
Purtroppo, l'unica opzione è quella di rinominare il file.
cmd
accetti il nome del file, ma ottenere un ambiente simile a Unix sarebbe la mia gestione preferita.