/FPS/Pollo/Pluto.txt
/fps/Pollo/Pluto.txt
/Fps/pollo/Pluto.txt
Mai provata ma sembra essere quello che cerchi:Grazie.
https://www.freepascal.org/docs-html/rtl/sysutils/expandfilenamecase.html (https://www.freepascal.org/docs-html/rtl/sysutils/expandfilenamecase.html)
{--------------------------------------------------------------------------}
Uses sysutils;
{--------------------------------------------------------------------------}
Const
PATH_SEP=#92;
{--------------------------------------------------------------------------}
Var
FName,TName:String;
{--------------------------------------------------------------------------}
Function TrueName(F:AnsiString):AnsiString;
var
u,v:Unicodestring;
a,z:AnsiString;
m:TFilenameCaseMatch;
{----------------------------------------}
Function DueSlash(Sh:AnsiString):Boolean;
begin
// delete(Sh,1,pos(PATH_SEP,Sh)); e' sempre 3
delete(Sh,1,3);
if pos(PATH_SEP,Sh)>0 then DueSlash:=True else DueSlash:=False;
end; // Function DueSlash
{----------------------------------------}
Function StripEnd(Se:AnsiString):AnsiString;
begin
if AnsiLastChar(Se)=PATH_SEP then delete(Se,length(Se),1);
StripEnd:=Se;
end; // Function StripEnd
{----------------------------------------}
begin
z:='';
u:=f;
v:=ExpandFileNameCase(u,m);
a:=v;
while DueSlash(a) do
begin
if z='' then z:=ExtractFileName(a) else z:=ExtractFileName(a)+PATH_SEP+z;
a:=StripEnd(ExtractFilePath(a));
u:=a;
v:=ExpandFileNameCase(u,m);
a:=v;
end;
z:=copy(a,1,3)+ExtractFileName(a)+PATH_SEP+z;
TrueName:=z;
end;
{--------------------------------------------------------------------------}
Begin
FName:=paramstr(1);
TName:=TrueName(FName);
WriteLn;
WriteLn('Input : ',FName);
WriteLn('Truename: ',TName);
End.
{--------------------------------------------------------------------------}
ti direi di abbandonare FindFirst/FindNext per la funzione/procedura FindAllFiles che trovi nella unit FileUtil.Grazie del suggerimento, studierò.
La trovi documentata in: https://wiki.freepascal.org/FindAllFiles (https://wiki.freepascal.org/FindAllFiles)
Credo che con un po' di fortuna potrebbe risolvere il tuo problema.Ho postato il codice della funzione TrueName() che ho scritto utilzzando la funzione ExpandFileNameCase dell'unit sysutils, suggerita da quack.
Facci sapere.
Comunque credo di aver capito che da Ansi a Unicode non ci dovrebbero essere problemi (allora perché esce il warning?) mentre da Unicode ad Ansi si potrebbero perdere i caratteri "strani". Trattandosi di nomi di file i caratteri strani non ci dovrebbero essere, a meno di non lavorare con nomi di file Russi, o peggio, Cinesi. Non credo che mi succederà mai. Hint: vengo dall’ 8+3.
[...]
Ho postato il codice della funzione TrueName() che ho scritto utilzzando la funzione ExpandFileNameCase dell'unit sysutils, suggerita da quack.
Se hai tempo fammi sapere cosa ne pensi, grazie.
[...]
Ho postato il codice della funzione TrueName() che ho scritto utilzzando la funzione ExpandFileNameCase dell'unit sysutils, suggerita da quack.
Se hai tempo fammi sapere cosa ne pensi, grazie.
ok, appena ho modo gli do un'occhiata
Per esempio:Così dice la documentazione, ma non è questo ciò che accade, almeno nel mio sistema (Win 10 e Fpc 3.2.2, ho provato sia compilato a 32 bit che a 64).
la directory corrente è "/pippo" e contiene solo il file "pluto.pas"
ExpandFileNameCase('PLUTO.pas', match) restituirà "/pippo/pluto.pas" e mkSingleMatch
ExpandFileNameCase('pluto.pas', match) restituirà "/pippo/pluto.pas" e mkExactMatch
ExpandFileNameCase('Mucca.pas', match) restituirà "/pippo/Mucca.pas" e mkNone.
PS: prova ad usare il tipo string invece di ansistring.Avevo già provato, con poca convinzione, ed infatti non cambia nulla.
[
Così dice la documentazione, ma non è questo ciò che accade, almeno nel mio sistema (Win 10 e Fpc 3.2.2, ho provato sia compilato a 32 bit che a 64).
Anche se il case è diverso, TFilenameCaseMatch restituisce sempre mkExactMatch oppure mkNone se il file non c’è; mkSingleMatch e mkAmbiguous non escono mai.
Perchè la conversione AnsiString genera quell'avviso ? Perchè essendo il carattere legato ad un codepage non definito (qualunque sia non è "scritto" nella stringa) la conversione in Unicode potrebbe non avere senso.Ti ringrazio per la lunga spiegazione. Ho capito qualcosa in più, anche se non posso dire di padroneggiare l’argomento, tutt’altro.
Per convertire le AnsiString in Unicode occorrerebbe usare le funzioni specifiche che consentono di eseguire correttamente l'operazione. Ovviamente è peggio l'incontrario (UNICODE string -> AnsiString).
Alla fine avevo usato "expandfilenamecase", partendo dal nome del file, ed andando a ritroso per i domi delle varie cartelle del percorso.Grazie per l’attenzione.
Ti ringrazio per la lunga spiegazione.....
credo sia scritto con windows in mente (mi riferisco a copy(a,1,3) ), forse dovresti mettere qualche direttiva per fare in modo che negli OS *nix non ci siano risultati anomaliGrazie. Immaginavo che ci sarebbero stati dei problemi su Linux.
3 per Win 1 per Linux.
La conversione non avviene correttamente neanche da ANSI a Unicode se non si usa la esatta "formula". Per convertirlo devi esattamente sapere quale è il codepage che stai usando.Temo che questa faccenda dell’Unicode sia scappata di mano, almeno a me. Non sono preparato per approfondire la questione, mi interesserebbe ma ho molte altre lacune che desiro colmare e l’Unicode è proprio l’ultima. Ne ho parlato perché sono usciti i warning di compilazione, altrimenti nemmeno me ne accorgevo.
Se scrivi un carattere in Portoghese, quel carattere sarà letto correttamente ovunque. E' per questo che puoi vedere un sito cinese, senza capire niente, ma correttamente dal punto di vista formattazione e caratteri oppure uno russo o arabo: viene usato UTF-8.Si’, vabbe’ (l’ho scritto apposta: "i" ed "e" accentate a 7 bit, ai più farà schifo (a me no) ma vuoi mettere la semplificazione) … Comunque: sì vabbe’, ma si potrebbe evitare di esagerare. Passi per il Cinese ma dici che se scrivi “Ci vediamo a Munchen” con la u normale senza la dieresi un Tedesco non capisce? Gira per tutta la Germania finché non trova un posto che si chiama uguale ma senza i due punti?
Quando apri Notepad e "salvi con nome" vedrai che ci sono delle opzioni (vedi allegato): ecco scegliendo quella strada puoi scambiare dati universalmente, altrimenti se salvi in ANSI non c'è speranza.L’avevo intuito e mi pare di averci anche provato, ma Scite non legge l’Unicode (almeno la versione che uso) per cui ho lasciato perdere, quei due o tre caratteri sbagliati li correggo a mano e finisce lì.
Non dare per scontato ciò che appare ovvio. Le PATH e i nomi dei file non sono solo espressi in "C:" e "/" ... ci sono i percorsi UNC (come i percorsi di rete), e tralasciamo i riferimenti a file su servizi vari leggibili con le normali API.Capisco e ringrazio per la segnalazione, ma preciso che scrivo programmi (Pascal e Lisp) che uso solo io, quindi scrivere programmi universali sarebbe uno spreco, ammesso che ne sia in grado. Comunque “\?\" oppure "\.\" li ho visti i giro, ma non ho mai capito a cosa si riferiscano.
In alcune modalità, i file si accedono solo ed esclusivamente con definizioni vari (mai usato "\?\" oppure "\.\" ) e così vanno "memorizzati" ...
Per cortesia confermami o meno solo se ho capito bene: a 7-bit (cioè sino ad ASCII 127) Ansi e Unicode sono identici. Se è così posso ignorare i warning. Per i nomi file vado, tassativamente, a 7-bit.
...c'è una nota nella documentazione della funzione che suggerisce di non utilizzare le wildcard proprio per il malfunzionamento che segnali.
mkExactMatch esce anche se metti una wildcard, e viene restituito anche il nome esatto (il primo che trova con quella wildcard).
PS: prova ad usare il tipo string invece di ansistring...Si è stata una mia svista, non avevo visto che assegnavi alla stringa ansi il valore della unicode, il warning nasce da lì ... come ha spiegato DragoRosso.