delphi - Håndtering af udvidede tegn i Windows-kommandoer?

Indlæg af Hanne Mølgaard Plasc

Problem



Jeg fejler en Windows-batch-kommandofil. Det fejler, når udvidede tegn (> 0x7f) bruges i stier eller filnavne. Problemet synes at være relateret til passerer parametre til en kommandofil, der er CALLed fra en anden.


For eksempel fungerer denne kommando som forventet:


xcopy "Pezuñero1 - 001.wav" 	emp


Dette gør ikke:


call another.cmd "Pezuñero" 


Indholdet af 'another.cmd':


xcopy "\%~11 - 001.wav"    	emp


\% ~ 1 syntaksen udvider en parameter og fjerner citater. Dette er nødvendigt, fordi stier i enten kaldet eller kaldet kommandofil i de rigtige kommandofil kan have mellemrum.


Resultatet af det andet eksempel (kopieret fra CMD-vinduet) er dette:


C:>call another.cmd "Pezu±ero"    

C:>xcopy "Pezu±ero1 - 001.wav"    	emp
File not found - 1 - 001.wav
0 File(s) copied


Bemærk at tegnet 'ñ' (0xF1) er blevet ændret til en '±' (0xB1).


Kan nogen forklare, hvad der sker, og hvordan man arbejder rundt om dette?

Bedste reference


Scriptet skal skrives i samme kodning cmd.exe anvendelser.


Skriv chcp ved prompten og se, hvad du får. Åbn derefter filen med en editor, der understøtter denne kodning. For mig chcp outputs kodepage 850 , så jeg redigerer mit script i JEdit vælger IBM850 som filkodningen. Jeg får det samme resultat at redigere filen i PSPad med Format indstillet til OEM . [9] [10]


PS: Jeg har testet dine trin i min maskine, og ñ -tegnet, som jeg skriver i notepad.exe (ved hjælp af standard ANSI-kodning) konverteres også til en ± , når du læser fra kommandoprompten, så det ser ud til, at din maskine bruger lignende ANSI- og OEM-kodninger. For sikker skal du prøve at erstatte ñ med en ¤ (med notepad.exe ). Det gør scriptet til at fungere korrekt for mig, når det løber fra kommandoprompten (fordi bytesværdien af ​​ANSI'erne ¤ er den samme som OEM'erne ñ ).

Andre referencer 1


Takket være McDowell og Romulo for at pege mig i den rigtige retning. Jeg indså, at jeg skulle ændre min ansøgning (i Delphi), der genererer partiet, så det bruger den korrekte (OEM) kode side, der er kompatibel med kommandoprocessoren i Windows. Jeg fandt ikke noget at konvertere codepage strings, men jeg fandt Windows API funktioner SetFileApisToOEM og SetFileApisToOnI;


Jeg lægger disse i begyndelsen og slutningen af ​​mit program som sådan:


{main procedure}
begin
  SetFileApisToOEM;
  {all the rest of the program}
  SetFileApisToANSI;
end.


Nu genereres batch-filer med OEM-kodesiden, og de fungerer korrekt, når de kører fra en CMD-prompt.

Andre referencer 2


Jeg har set på behandling af tegn i cmd.exe, og jeg tror, ​​at Romulo har ramt neglen på hovedet. Som standard bruger prompten gamle DOS (OEM) -kodesider (sandsynligvis for kompatibilitet med DOS-programmer). Du skriver din fil ved hjælp af (sandsynligvis) standard Windows-kode side (sandsynligvis 1252), som er anderledes. Brug edit.com til at redigere batchfilen. [11]


Hvis jeg skriver chcp ved prompten, rapporterer den kodesiden 850.


Så hvis jeg for eksempel bruger Notesblok for at skrive dette:


DIR Pezuñero


... dette er kodet som 1252 med de binære værdier: [13]


                        ñ
44 49 52 20 50 65 7A 75 F1 65 72 6F


Hvis jeg bruger redigering til at skrive filen, er den kodet som 850 med de binære værdier: [14] [15]


                        ñ
44 49 52 20 50 65 7A 75 A4 65 72 6F


En ting, jeg ikke har set på, bruger cmd/U -knappen, men jeg er helt sikker på, at det kun er for indbyggede shellkommandoer og vil ikke hjælpe dig med XCOPY.

Andre referencer 3


Kodesider er et problem i batch-filer, da de ikke må indeholde Unicode. Den nemmeste måde at undgå dette problem på vil helt sikkert være at bruge WSH eller Powershell. Jeg har ikke fundet en løsning for batch-filer hidtil, som virkelig generer mig, da jeg betragter mig selv en Unicode-fanatiker :)

Andre referencer 4


Du skal muligvis indstille kodesiden til en, der har n'en med ~ på toppen.