Ausführung einer Batch-Datei vs Befehl in Konsole

[Perlsau]

Mein Programm erzeugt eine Batch-Datei zur Ausführung. Gestern hat noch alles funktioniert, jetzt eben plötzlich nicht mehr. In der Batch-Datei steht folgendes:

D:\Coding\2009A\Recherche\Debug\BIN\osmconvert.exe D:\Coding\OSM\PBF\Länder\Afrika\botswana-latest.osm.pbf >D:\Coding\2009A\Recherche\Debug\BIN\OSM\Botswana. osm

Da wird also das Konsolenprogramm osmconvert mit zwei Parametern gestartet. Füge ich den Text der Batch-Datei in ein Konsolenfenster ein und drücke dann Enter, wird der Befehl ausgeführt und ich erhalte in Nullkommanix eine OSM-Datei mit ca. 128 MB. Führe ich im Explorer jedoch einen Doppelklick auf die Batch-Datei aus, wird die Zieldatei zwar erstellt, aber die Größe ist 0.

Das Space am Ende zwischen Botswana. und osm ist ein Darstellungsfehler des hiesigen Editors ...

[Perlsau]

Nach einer frühen Tasse Kaffee ist mir klargeworden, daß die Batch-Datei irgendwie mit den Umlauten nicht klarkommt. Nachdem ich daraufhin den Order Länder in Staaten umbenannt habe, funktioniert die Batchdatei tadellos.

[hoika]

Hallo


Ansi <> OEM

also AnsiToOem benutzen.

Heiko

[p80286]

Ist es nicht immer wieder schön, über die eingebauten Inkompatibilitäten zu stolpern?
Solange bei Umlauten das Problem des Datenhackfleisches besteht, beschränkt man sich halt auf A..Z und _

Gruß
K-H

[Sherlock]

Man braucht sich nicht beschränken, AnsiToOEM macht was es soll, so lange man keine "uneuropäischen" Zeichen verwendet.

Sherlock

[himitsu]

Oder den kurze 8.3-Namen dieses Verzeichnisses oder im ganzen Pfad verwenden.

Wenn es im OEM-Zeichensatz das gewünschte Zeichen nicht gibt, dann lässt es sich sowieso nicht umwensen.
Und er hat ein Unicode-Delphi, womit ANSI sowieso nicht direkt geht, da er dann nocheine zweite Umwandlung hätte. (aka Google-Translate: deutsch->chineisch->englisch )

AnsiToOem ist nicht so gut und selbt Microsoft sagt dazu.
[OH="MSDN (.Net)"]Wird nur aus Gründen der Abwärtskompatibilität bereitgestellt. Verwenden Sie stattdessen die GETCP( )-Funktion[/OH]

In der WinAPI wäre es CharToOem (CharToOemW) und auch da sollte man etwas aufpassen.

Zitat von MSDN:

Warning Do not use. See Security Considerations.

[add] AnsiToOemBuffW, CharToOemBuffW


Man könnte auch mit SetFileApisToOEM rumspielen und schauen was dabei in der Datei landet,
oder man nimmt den aktuellen Weg, um die Codepage umzuwandeln. (WideCharToMultiByte mit CP_OEMCP)