Wie Zugriff auf files und ordnern, die ASCII im Namen haben?

[Kyro]

Ich hab probleme beim Zugriff auf dateien welche im namen ASCII Zeichen haben
(leider) ist es in windows möglich einen solchen ordner oder datei zu erstellen (zumindest unter NTFS)...
(in dem beispiel(attachement) ascii code des blocks:219)
Mit allen prozeduren mit denen ich arbeite bekomme ich keinen zugriff auf die datei, möglich weil auch selbst
der Code Editor in delphi keine ascii zeichen annimmt sondern das zeichen in ANSI 166 umwandelt?

Irgendeinen ansatz wie ich darauf zugreifen könnte?
den ordner/datei händisch umzubenennen bringt mir nichts!

[rantanplan99]

Versuchsmal so:

Delphi-Quellcode:

sFN := 'a' + chr(219);

und dann ganz normal die Datei öffnen.

rantanplan

[runger]

Hallo,

das halte ich für ein Gerücht.
Ein ASCII Zeichen ist nur eine Konvention wie einem Bytewert ein Zeichen zugeordnet wird.
Also z.B. der 0 die 30H.
Mach folgendes:

Delphi-Quellcode:

   assignfile(f,'c:\test.txt');
   reset(f);
      ...tue was
   closefile(f);

wobei f eine Textvariable dartsellt. Dabei sind die Zeichen in 'c:\test.txt' ASCII Zeichen und werden auch als solche weitergegeben.

Sollte ich dich falsch verstanden haben, so teils mir bitte mit. Dein download funktioniert nicht.

Rainer

[runger]

Hallo,

jetzt hab ich kapiert was du willst. Machs wie rantanplan vorschlägt.
Der Ausdruck ASCII-Zeichen ist sehr missverständlich. ASCII ist alles
du meinst aber nur die Zeichen oberhalb 128.

Rainer

[Olli]

#219 oder #$DB sind ebenfalls Äquivalente für chr(219) bzw. chr($DB).

ASCII ist übrigens nur #0..#127, alles von #128..#255 nennt sich EASCII und stimmt in der US-Codepage exakt mit ANSI überein. Nur als Hinweis.

[Kyro]

mit chr(219) kann ich leider auch nicht zugreifen....

sorry, merke selbst gerade dass ich zu allgemein mit ascii war... ja alle zeichen oberhalb von 127 gehen nicht!

um das ganze zu rekonstruieren....
textdatei erstellen auf C:\ mit ABCD+Zeichen:(Alt+219)+.txt

in delphi kann ich dann nicht die datei zum beispiel mit:
winexec('notepad C:\ABCD'+chr(219)+'.txt',SW_NORMAL) öffnen

[Olli]

Welches OS? Welche Codepage (wenn Win9x)?

Wenn du die gleiche Codepage verwendest wie beim Erstellen, sollte es nie ein Problem geben. Werde es gleich mal testen ... sowohl auf Win9x als auch auf NT.

[Kyro]

Windows XP/Windows 2003 Server - NTFS Partition

[Olli]

Mache bitte mal folgendes:

Lade dir mein Uniconv runter und starte es. Danach gehst du mit dem Explorer zu der Datei und drückst F2 (wie zum umbenennen) um den Namen in die Zwischenablage zu kopieren. Von dort in Uniconv einfügen und konvertieren ... danach hier in [code]-Tags posten. Danke!

Auf XP sollte sowas nicht auftreten, daher eine Befürchtung, die ich überprüfen möchte.

[Kyro]

Ey, nice tool!! vielleicht werd ich ja aus dem source deines tools schlau!
Das kommt raus:(nur der ordner): █X█
die datei: abcd█.txt

[Olli]

Auweia ... dann haben wir es.

Das kann nicht gut gehen. Oben versuchst du mit ANSI-APIs auf einen Namen zuzugreifen, dessen Zeichen jenseits von ÿ liegen ... also über 255. Deshalb bewegst du dich mit ANSI-APIs im Unicodebereich. Das kann ohne Umschaltung der Codepage (wenn überhaupt) nicht gut gehen. Benutze die Unicode-APIs (GetWindowsPathW statt GetWindowsPathA usw ...).

Wenn du dein komplettes Programm auf Unicode trimmen willst, nimm die TNT Unicode Controls.

Übrigens: Ab Windows NT4 sind die Eingaben über Alt+Zahlenblock vierstellig, nämlich Unicode!!!

[Kyro]

verdammt! verdammt verdammt..... :duck:

Könntest du mir ein beispiel geben wie ich eine solche datei kopiere?
Bzw. wie kann ich meiner applikation sagen dass er die datei kopieren soll wenn ich nicht einmal unicode zeichen in den code explorer eingeben kann!?

[Olli]

Locker bleiben ... kannst du doch ;) ... mit Typecasts:

Delphi-Quellcode:

var
s: WideString;
s2: WideString;
begin
  s := 'C:\Ottokar'+WideChar(12345)+'.txt';
  s2 := 'D:\bla.txt';
  CopyFileW(@s[1], @s2[1], False {nicht überschreiben});
end;

... ist halt nur umständlich. Aber es geht ;) ... ansonsten immer die Unicode-APIs benutzen in solchen Fällen. Ist in Delphi zwar ätzend, wir arbeiten aber dran ;)

[runger]

Danke Olli,

hab viel dazugelernt!

Rainer

[Kyro]

Danke vorerst einmal, ist aber echt umständlich, dumm dass mir das erst im nachhinein aufgefallen ist!

dieses "Alt+219" Zeichen, welchen wert hätte dieses als widechar(?)

[Olli]

Bitte auch den folgenden Beitrag beachten: http://www.delphipraxis.net/internal...=415625#415625

Zitat:

Zitat von Kyro

dieses "Alt+219" Zeichen, welchen wert hätte dieses als widechar(?)

Bleibt sich gleich, sollte mit 219 funktionieren, also

Delphi-Quellcode:

WideChar(219)

wenn es denn ein Dezimalwert war. Allerdings kannst du bei den Zeichen unter Wert 256 auch durchaus noch die Syntax mit #255 (oder #$FF) benutzen (zu dem Thema weiterlesen ...).

Also paß' auf, welche Zahlen du castest, ist egal, solange du bei 16bittigen Zahlen bleibst (0..$FFFF), wobei natürlich nicht alle gültige Unicodezeichen sind. Was du wissen mußt, ist daß Windows nach außen nur 2bytige (also 16bittige) Unicodezeichen unterstützt - irgendjemand hier im Forum meinte letztens, daß es ab mind. XP sogar intern Unterstützung für 32bittige Unicodezeichen gibt - konnte ich aber noch nirgends verifizieren, die Native APIs arbeiten noch immer mit 16bittigen Zeichen (außer vielleicht in Win64?!?).

Weiterhin mußt du dir klarmachen, daß die unteren 256 Zeichen im Unicodezeichensatz ja eine 0 im oberen Byte haben, also z.B. hexadezimal $00FF (sie passen also in 1 Byte ohne daß Bits verlorengehen) - dadurch und durch die Tatsache, daß diese ersten 256 Zeichen exakt in den ANSI-Zeichen entsprechen, gibt es bei diesen Zeichen eine Kompatibilität. Hast du also Zeichen wie 'a'..'z', so sind diese eindeutig innerhalb dieses Bereiches und können im Codeeditor normal (als literale Strings) eingetippt werden (der Compiler macht in der EXE literale WideStrings daraus). Alle Zeichenketten aus Ordinalwerten über 255 ($FF) müssen in den mir bekannten Delphiversionen extra durch Aneinanderkettung von WideChar-Casts erzeugt werden. Wenn Delphis Codeeditor Unicode unterstützen würde (vielleicht tun dies neuere Versionen ja doch schon?), dann könntest du diese Zeichen direkt eingeben. Wenn du den Dateinamen allerdings nicht hardcoden mußt, gibt's ja noch die entsprechenden Unicode-APIs zu den ANSI-APIs, welche dir eben ermöglichen direkt die Namen im Unicodeformat zu erhalten.
Unicode wird "a bisserl" unter Win9x unterstützt, allerdings mehr schlecht als recht: MSLU.

@runger: Das freut doch, wenn es noch anderen außer dem Fragesteller etwas bringt :thumb:

[edit=Admin]Auf Wunsch von Oliver den Link am Anfang dieses Beitrages eingefügt. Mfg, Daniel[/edit]

[Bernhard Geyer]

Vergiss MSLU!

Dies ist nur eine DLL wogegen dein Programm gelinkt wird und das dann intern unter Win9x/ME automatisch die Ansi-Version der API-Funktionen verwendet. Damit wird keine einzige API-Funktion unter Win9x/ME Unicode-Enabled.

Du kommst einfacher ans ziel mit den TNTWare-Controls

[Olli]

Zitat:

Zitat von Bernhard Geyer

Dies ist nur eine DLL wogegen dein Programm gelinkt wird und das dann intern unter Win9x/ME automatisch die Ansi-Version der API-Funktionen verwendet. Damit wird keine einzige API-Funktion unter Win9x/ME Unicode-Enabled.

... aber man braucht nur noch eine Version seiner Software, nämlich Unicode, schreiben und unterstützen. IMO ein großer Vorteil. Auf NT läuft's ja genau umgekehrt, da werden die Unicode-APIs gewrappt ;)

Wir haben letztens auch herausgefunden, daß viele NT-Funktionen der ADVAPI32.DLL als leere Stubs auf 9x existieren. Ist doch wunderbar, so spart man sich das dynamische Laden von DLLs und Funktionsadressen.

Daß MSLU keinen echten Unicode-Support bringt, wußte ich nicht sicher, dachte es mir aufgrund der Paketgröße aber fast schon.

[Bernhard Geyer]

Zitat:

Zitat von Olli

Zitat:

Zitat von Bernhard Geyer

Dies ist nur eine DLL wogegen dein Programm gelinkt wird und das dann intern unter Win9x/ME automatisch die Ansi-Version der API-Funktionen verwendet. Damit wird keine einzige API-Funktion unter Win9x/ME Unicode-Enabled.

... aber man braucht nur noch eine Version seiner Software, nämlich Unicode, schreiben und unterstützen. IMO ein großer Vorteil. Auf NT läuft's ja genau umgekehrt, da werden die Unicode-APIs gewrappt ;)

Na und? Macht die TntWare-Komponenten und das ElPack intern auch. Und du benötigst keine DLL. Und das Elpack kann 100% Unicode-Oberflächen auch unter Win9x/ME was mit MSLU nicht möglich ist.

[Kyro]

Also ich hab mir mal die TNTControls angesehen, bei denen funktioniert zwar das anzeigen von unicode zeichen... bringt mir aber nicht all zu viel.... aber danke für den tipp!

Wie kann ich zum beispiel ein verzeichnis auf der hdd in TNTChecklistbox laden MIT unicode zeichen?
Mit findfirst und TSearchRec kann das ja nicht klappen nachdem die ja die namen als string ausgeben!?

ebenso das kopieren mit filestream ist von dateien die im namen unicode zeichen enthalten nicht möglich, oder?
Mit CopyFileW klappt das kopieren generell zwar mit diesen dateien, kann aber zum beispiel kein resuming oder statusanzeige ermöglichen.

Danke für eure Hilfe!!!!

[Olli]

Zitat:

Zitat von Kyro

Wie kann ich zum beispiel ein verzeichnis auf der hdd in TNTChecklistbox laden MIT unicode zeichen?
Mit findfirst und TSearchRec kann das ja nicht klappen nachdem die ja die namen als string ausgeben!?

Back to the roots: FindFirstFileW(), FindNextFileW(), FindClose() direkt als API-Funktionen benutzen.

Zitat:

Zitat von Kyro

ebenso das kopieren mit filestream ist von dateien die im namen unicode zeichen enthalten nicht möglich, oder?

Theoretisch schon, einziges Problem ist, daß du keine Unicodenamen übergeben kannst. Habe mir die Klasse noch nicht angeschaut, sollte man aber umprogrammieren können. Das Handle ist danach ein Handle, egal ob durch die ANSI- oder Unicode-API erlangt.

Zitat:

Zitat von Kyro

Mit CopyFileW klappt das kopieren generell zwar mit diesen dateien, kann aber zum beispiel kein resuming oder statusanzeige ermöglichen.

Mit Statusanzeige kannst du's haben (Shellstil): SHFileOperation()

[Bernhard Geyer]

Zitat:

Zitat von Kyro

Also ich hab mir mal die TNTControls angesehen, bei denen funktioniert zwar das anzeigen von unicode zeichen... bringt mir aber nicht all zu viel.... aber danke für den tipp!

Wie kann ich zum beispiel ein verzeichnis auf der hdd in TNTChecklistbox laden MIT unicode zeichen?
Mit findfirst und TSearchRec kann das ja nicht klappen nachdem die ja die namen als string ausgeben!?

ebenso das kopieren mit filestream ist von dateien die im namen unicode zeichen enthalten nicht möglich, oder?
Mit CopyFileW klappt das kopieren generell zwar mit diesen dateien, kann aber zum beispiel kein resuming oder statusanzeige ermöglichen.

Danke für eure Hilfe!!!!

Für viele der Probleme sollte es Wide-Versionen in den TntWare-Units geben.

[Kyro]

Danke!!!!!!

Verzeichnis auflisten hab ich schon mal zusammenbekommen...
hoffe dass das mit dem kopieren auch noch klappt...
vor allem so dass ich nicht wieder alles umschreiben muss

Aber warum steht denn auch nicht sowas als große fette Warnung in der delphi hilfe neben den ANSI prozeduren !!! :-D (kleiner scherz)

[Olli]

Zitat:

Zitat von Kyro

Aber warum steht denn auch nicht sowas als große fette Warnung in der delphi hilfe neben den ANSI prozeduren !!! :-D (kleiner scherz)

Leider stammt Delphi aus Zeiten, wo Windows 9x populärer war als die NT-Linie ... deswegen. Schade, aber es ist so.

[Olli]

Zitat:

Zitat von Olli

Alle Zeichenketten aus Ordinalwerten über 255 ($FF) müssen in den mir bekannten Delphiversionen extra durch Aneinanderkettung von WideChar-Casts erzeugt werden.

So kann man sich täuschen. Ich habe es mir vor 2 Tagen im Disassembler angeschaut und es ist so, daß der Compiler (D3 und D4) zwar einen echten Literalstring in Unicode erzeugt, leider wird aber alles bis auf das untere Byte des WideChars abgeschnitten (d.h. das obere Byte wird $00).
Fazit, es geht nicht wie oben geschildert ... offenbar gibt es keine normale Methode um in Delphi einen Unicode-String einzufügen (es sei denn über eine Ressourcendatei - extern - oder über das UTF-8-Format) :? ...

Wäre schön, wenn sich Leute finden würden um das mit späteren Versionen zu testen (D5 aufwärts).

[Kyro]

@Olli ... leider versteh ich dein letztes posting zwar nicht ganz aber wenn du damit andeuten willst dass man mit der funktion "WideChar(n)" nicht alle Unicode-Zeichen replizieren kann, kann ich dir nur recht geben, hatte damit nicht viel erfolg, mit den TNT Components allerdings schon, also ich kann endlich dateien kopieren die im namen unicode zeichen enthalten..... :gruebel:

Allerdings gibt es nicht für alle Prozeduren alternativen die unicode unterstützen, oder ich kann sie nicht finden.... wie sieht es zum beispiel mit den Parametern aus
Normalerweise hab ich die über "Paramstr(n)" abgerufen... aber darüber bekommt man eben nur wie der funktionsname schon vermuten lässt ein String und kein widestring, und soetwas wie ParamWideStr(n) gibt es wohl zumindest in Delphi 7 nicht?!?? :wall:

Falls ich das mit dem Parameter auch noch hinbekomme hab ich glaub ich alles "notewendigste" für meinen unicode support für mein app.... und ich glaub das wird so ziemlich das letzte prog sein was ich mit D7 mache, da sieht man schon dass es ziemlich "altert". :(

[jfheins]

http://www.delphipraxis.net/internal...ect.php?t=8873 ;)

[Olli]

Zitat:

Zitat von Kyro

@Olli ... leider versteh ich dein letztes posting zwar nicht ganz aber wenn du damit andeuten willst dass man mit der funktion "WideChar(n)" nicht alle Unicode-Zeichen replizieren kann

Im Grunde meine ich genau dies. Kannst du auch irgendwie Unicodestrings, wie zB diesen: "Сніжок.txt" in deinen Quellcode einbauen und auf eine im Explorer (!) so benannte Datei zugreifen?

Zitat:

Zitat von Kyro

Allerdings gibt es nicht für alle Prozeduren alternativen die unicode unterstützen, oder ich kann sie nicht finden.... wie sieht es zum beispiel mit den Parametern aus

Dazu habe ich vor langer Zeit etwas im DF verfaßt:
http://www.delphi-forum.de/topic_die...sen_15503.html

Edit:
Holla die Waldfee, da hat jfheins wohl ein besseres Gedächtnis als ich. Habe es wohl auch nochmal hier in der DP gepostet. :mrgreen: ... und exakt zur gleichen Zeit :lol:

[Kyro]

Zitat:

Zitat von Olli

Kannst du auch irgendwie Unicodestrings, wie zB diesen: "Сніжок.txt" in deinen Quellcode einbauen und auf eine im Explorer (!) so benannte Datei zugreifen?

Also bis jetzt nur über die TNTComponents, also wenn ich zum beispiel TNTEdit1.text auf Сніжок.txt setze dann kann ich auch mit der datei die so im explorer benannt wurde arbeiten....

Delphi 7 speichert das so: Text = #1057#1085#1110#1078#1086#1082'.txt'

Danke olli und jfheins .. werde mir das mit den parametern anschaun, schaut aber schon mal verdammt gut aus!! :thumb:

[Olli]

Zitat:

Zitat von Kyro

Delphi 7 speichert das so: Text = #1057#1085#1110#1078#1086#1082'.txt'

Cool, dann können neuere Delphiversionen also doch mit Unicode-Zeichenliteralen umgehen. Jetzt wäre noch interessant herauszufinden ab welcher Version das möglich ist. Als übliche Verdächtige bleiben nur noch Version 5-7 (wir können ja nicht ausschließen, daß 7 die erste mit dieser Unterstützung war). Bei Delphi 4 wird aus #1057 in der kompilierten Datei ein #33, weil #1057 = #$0421 ... und der (rote) obere Teil "abgeschnitten" wird, dadurch erhalten wir #33 = #$21.

Das mit den beiden oben verlinkten Themen (mit gleichem Inhalt) sollte auch mit WideStrings zusammenpassen. Versuche mal eine Zuweisung. Sollte ohne weiteres gehen. Du kannst dir natürlich auch deine eigenen Wide-Versionen für ParamStr() usw. schreiben ;)

@Daniel: Danke für die Anpassung oben im Beitrag :thumb:

[Kyro]

also was aber nicht klappt ist die Zuweisung
TNTEdit1.text:=#1057#1085#1110#1078#1086#1082'.txt ';
da kommt was anderes raus, aber teste es mal selbst.

[Olli]

Zitat:

Zitat von Kyro

also was aber nicht klappt ist die Zuweisung
TNTEdit1.text:=#1057#1085#1110#1078#1086#1082'.txt ';
da kommt was anderes raus, aber teste es mal selbst.

Geht leider nicht. Selbst wenn ich diese Form von Zeichenliteralen benutze, passiert das gleiche was ich oben zu WideChar-Casts geschildert habe. Bis auf das untere Byte wird alles abgeschnitten. Daher kann ich es nicht nachvollziehen - bräuchte dazu wohl eine neuere Version von Delphi.

[Kyro]

Zitat:

Zitat von Olli

bräuchte dazu wohl eine neuere Version von Delphi.

Glaub die bräuchte ich schön langsam auch!

Aber ich komm erstmal für mein momentanes Projekt weiter dank eurer hilfe! nochmals danke!! :thumb:

[Kyro]

Habe da eine echte alternative gefunden zu dem problem, und zwar... (zumindest fürs lesen, bzw. für schon existierende dateien und ordner) kann man den alternativnamen (DOS Namen) der datei ermitteln

zum beispiel:
C:\dokumente und einstellungen\administrator\ntuser.dat
=
C:\dokume~1\admin~1\ntuser.dat

oder (unicode beispiel)
C:\NULL\O█\t.txt
=
C:\NULL\O8847~1\t.txt

hat man den namen kann man die meisten prozeduren verwenden die nur mit string arbeiten

[Olli]

Zitat:

Zitat von Kyro

Habe da eine echte alternative gefunden zu dem problem, und zwar... (zumindest fürs lesen, bzw. für schon existierende dateien und ordner) kann man den alternativnamen (DOS Namen) der datei ermitteln

Wow. Das ist eine coole Idee. Wieder was dazugelernt :thumb:

[Kyro]

Verdammt!!! Das mit den DOS-Namen klappt leider auch nicht immer, da die selbst auch unicode zeichen enthalten können :((((

Kann mir vielleicht einer sagen wie ich Dateien (eben solche die unicode zeichen enthalten) in die zwischenablage speichern kann?

Habe schon versucht die prozedur "CopyFilesToClipboard" abzuändern, hatte aber leider nicht viel erfolg damit.

hier die "String-version"

Code:

procedure CopyFilesToClipboard(FileList: String);
var
  DropFiles: PDropFiles;
  hGlobal: THandle;
  iLen: Integer;
begin
  iLen := Length(FileList) + 2;
  FileList := FileList + #0#0;
  hGlobal := GlobalAlloc(GMEM_SHARE or GMEM_MOVEABLE or GMEM_ZEROINIT,
    SizeOf(TDropFiles) + iLen);
  if (hGlobal = 0) then raise Exception.Create('Could not allocate memory.');
  begin
    DropFiles := GlobalLock(hGlobal);
    DropFiles^.pFiles := SizeOf(TDropFiles);
    Move(FileList[1], (PChar(DropFiles) + SizeOf(TDropFiles))^, iLen);
    GlobalUnlock(hGlobal);
    Clipboard.SetAsHandle(CF_HDROP, hGlobal);
  end;
end;