Recensubs HQ

Problema batch patch con xdelta3, Lettere accentate nei titoli degli episodi

« Older   Newer »
  Share  
view post Posted on 17/9/2015, 05:54     +1   -1

Member

Group:
Utente abilitato
Posts:
732
Reputation:
+1
Location:
Lugo, Ravenna, Emilia-Romagna

Status:


Mi stavo cimentando per la prima volta con l'utilizzo di xdelta3, tutto molto facile e semplice da usare, tuttavia mi sono imbattuto in un problema che non riesco a risolvere.
Quando vado a patchare un gruppo di episodi, tutti gli episodi che hanno dei caratteri accentati nel titolo, come à e ì non vengono patchati, e il messaggio d'errore restituito nel cmd è "file open failed", ovvero non riesce ad aprire i file degli episodi da patchare, che nel titolo hanno delle lettere accentate.

Consigli? Soluzioni? Un rimedio che vorrei evitare, è quello di allegare un file txt con scritto "rinonima gli episodi con lettere accentate così e così".
Allego uno screen con i due episodi "incriminati":
5ODpCtQ

Pensavo di rimediare scrivendo il codice ASCII corrispondente (in questo caso 133 e 141), ma mi sfugge qualcosa, non posso scrivere il numero e basta, insieme al codice cosa ci andrebbe?
 
Web Contacts  Top
view post Posted on 17/9/2015, 05:59     +1   +1   -1
Avatar

Bimbosp

Group:
Administrator
Posts:
9,780
Reputation:
+929
Location:
Gallarate (VA)

Status:


Beh, xdelta3 non è UTF-8, mi pare. Anche titoli in giapponese creano problemi, e vari altri simboli. Bisogna rinominare i file prima di patcharli, e rinominarli nuovamente dopo. È uno dei motivi per cui tendenzialmente si evita di mettere titoli tradotti nei filename.
 
Web  Top
view post Posted on 17/9/2015, 06:19     +1   -1

Member

Group:
Utente abilitato
Posts:
732
Reputation:
+1
Location:
Lugo, Ravenna, Emilia-Romagna

Status:


Capisco, purtroppo non ero a conoscenza di questo limite di xdelta3, peccato. Speravo ci fosse un modo tramite i codici ASCII, ma ero troppo ottimista. Perciò l'unico rimedio è la pezza che avevo immaginato, va beh, pazienza.

P.S. Grazie per la risposta immediata, ne sono rimasto impressionato, così evito di impazzirci sopra e mi metto subito il cuore in pace (mi ero già messo a googlare come un folle).
 
Web Contacts  Top
view post Posted on 17/9/2015, 13:46     +1   +1   -1
Avatar

Member

Group:
Utente abilitato
Posts:
735
Reputation:
+116
Location:
localhost

Status:


CITAZIONE (Disillusion @ 17/9/2015, 07:19) 
Capisco, purtroppo non ero a conoscenza di questo limite di xdelta3, peccato.

Infatti non è un limite di xdelta3, sebbene sp abbia scritto erroneamente il contrario.
Il mancato supporto ad UTF-8 è a livello di console, ovvero cmd.exe.
 
Top
view post Posted on 17/9/2015, 15:40     +1   +1   -1
Avatar

Bimbosp

Group:
Administrator
Posts:
9,780
Reputation:
+929
Location:
Gallarate (VA)

Status:


E vabbè, lo sapete che sono scemo quando si tratta di 'ste cose. Sapevo che il problema con UTF-8 c'era e non son mai stato ad indagare oltre.
 
Web  Top
view post Posted on 17/9/2015, 15:47     +1   +1   -1
Avatar

Member

Group:
Utente abilitato
Posts:
843
Reputation:
+38

Status:


Anche la powershell snobba L'utf-8?
 
Top
view post Posted on 17/9/2015, 17:16     +1   +1   -1
Avatar

Member

Group:
Utente abilitato
Posts:
735
Reputation:
+116
Location:
localhost

Status:


CITAZIONE (Danielys @ 17/9/2015, 16:47) 
Anche la powershell snobba L'utf-8?

PowerShell in sé è un interprete, non una console.

Tecnicamente PowerShell è il prompt "PS:>" che vedi a lato.
Tuttavia se non c'è una sessione attiva, allora l'eseguibile powershell.exe sfrutta le API di Windows per generare un buffer della console, trascinandosi quindi le stesse limitazioni di cmd.exe.

Ma non è una limitazione di PowerShell in sé, attenzione.
Avresti la stessa situazione se usassi "irb" per richiamare una shell interattiva Ruby o "python" per una shell interattiva Python.
In breve, è ciò che sta alla base il problema.

cmd.exe ha un supporto veramente precario ad UTF-8, perlopiù legato ad hack. Quindi da un punto di vista pratico è inesistente.

Questo perché Microsoft non ha mai voluto migliorare la piattaforma base per evitare rotture di retrocompatibilità.
Difatti si porta dietro anche altri problemi diversi dall'UTF-8, tipo una gestione del numero di colonne inefficiente (fa ancora distinzione tra buffer e finestra, per dire), il famoso problema del copia-incolla (risolto in parte su Windows 10) o il non avere il supporto ai 256 colori.

E queste purtroppo sono tutte funzioni che persino gli emulatori di terminale più di merda su UNIX, come XTerm, hanno da secoli.

C'è da dire comunque che molti dei problemi legati ad UTF-8 vanno via smettendo di usare font Bitmap e mettendo font TrueType tipo Consolas.
Tuttavia non sempre si risolve, in quanto ci sono i suddetti problemi architetturali che andrebbero risolti riscrivendo completamente lo strumento.

È da una vita che lo si chiede a MS insieme ad un emulatore di terminale decente al pari di ConsoleZ, ma fino ad ora non si è mai fatto nulla su questo fronte.
 
Top
6 replies since 17/9/2015, 05:54   1167 views
  Share