🚀 go-pugleaf

W dniu 2010-04-18 16:30, Terrmit pisze:
> Witam,
>
> Może ktoś mi podpowie.
> Potrzeba mi funkcja, która sprawdza, czy w podana nazwa
> pliku (katalogu) jest poprawna, tzn. czy nie zawiera
> niedozwolonych znaków (\ /: * ? " < > |).
> Czy we freepascalu istnieje taka funkcja?
> Pytam, bo nie mogę takiej znaleźć.
> Mogę sobie oczywiście napisać, ale jeśli taka funkcja jest
> to wolałbym ją wykorzystać, a nie wyważać otwarte drzwi.
> Jakoś nie chce mi się wierzyć, że nie ma takiego sprawdzania.

W Delphi w module SysUtils jest funkcja "IsValidIdent". Sprawdź, czy 
Lazarus też ma taką funkcję w tym module.

-- 
Pozdrawiam,

Grzegorz Skoczylas
http://gskoczylas.rekord.pl
----------------------------------------------

W dniu 18.04.2010 19:03, Grzegorz Skoczylas pisze:
> W dniu 2010-04-18 16:30, Terrmit pisze:
>> Witam,
>>
>> Może ktoś mi podpowie.
>> Potrzeba mi funkcja, która sprawdza, czy w podana nazwa
>> pliku (katalogu) jest poprawna, tzn. czy nie zawiera
>> niedozwolonych znaków (\ /: * ? " < > |).
>> Czy we freepascalu istnieje taka funkcja?
>> Pytam, bo nie mogę takiej znaleźć.
>> Mogę sobie oczywiście napisać, ale jeśli taka funkcja jest
>> to wolałbym ją wykorzystać, a nie wyważać otwarte drzwi.
>> Jakoś nie chce mi się wierzyć, że nie ma takiego sprawdzania.
>
> W Delphi w module SysUtils jest funkcja "IsValidIdent". Sprawdź, czy
> Lazarus też ma taką funkcję w tym module.
>
Jest taka funkcja, ale ona służy raczej do sprawdzania nazwy
komponentu:
"IsValidIdent returns True if Ident can be used as a component name."
http://lazarus-ccr.sourceforge.net/docs/rtl/sysutils/isvalidident.html
Owszem taka nazwa nadawałaby się też na nazwę pliku, ale gdy będzie
zawierać np. nawiasy, to już wyrzuci False, więc chyba nie o to chodzi,
bo w nazwach plików nawiasy jak najbardziej mogą być.

Jednak dzięki za odpowiedź i zainteresowanie.

Sławek

W dniu 2010-04-18 21:37, Terrmit pisze:
> W dniu 18.04.2010 19:03, Grzegorz Skoczylas pisze:
>> W dniu 2010-04-18 16:30, Terrmit pisze:
>>> Witam,
>>>
>>> Może ktoś mi podpowie.
>>> Potrzeba mi funkcja, która sprawdza, czy w podana nazwa
>>> pliku (katalogu) jest poprawna, tzn. czy nie zawiera
>>> niedozwolonych znaków (\ /: * ? " < > |).
>>> Czy we freepascalu istnieje taka funkcja?
>>> Pytam, bo nie mogę takiej znaleźć.
>>> Mogę sobie oczywiście napisać, ale jeśli taka funkcja jest
>>> to wolałbym ją wykorzystać, a nie wyważać otwarte drzwi.
>>> Jakoś nie chce mi się wierzyć, że nie ma takiego sprawdzania.
>>
>> W Delphi w module SysUtils jest funkcja "IsValidIdent". Sprawdź, czy
>> Lazarus też ma taką funkcję w tym module.
>>
> Jest taka funkcja, ale ona służy raczej do sprawdzania nazwy
> komponentu [...]

Faktycznie. Pomyliłem się.

W JEDI znalazłem taką funkcję:

function ValidFileName(const FileName: string): Boolean;

   function HasAny(const Str, Substr: string): Boolean;
   var
     I: Integer;
   begin
     Result := False;
     for I := 1 to Length(Substr) do
     begin
       if Pos(Substr[I], Str) > 0 then
       begin
         Result := True;
         Break;
       end;
     end;
   end;

begin
   Result := (FileName <> '') and (not HasAny(FileName, '/<>"?*|'));
   if Result then
     Result := Pos('\', ExtractFileName(FileName)) = 0;
end;


To oczywiście dotyczy systemu Windows. Właściwie należałoby jeszcze 
sprawdzić, czy pełna ścieżka do pliku nie przekracza 260 znaków (w 
Delphi stała MAX_PATH z modułu Windows).

Nie wiem, jakie są ograniczenia w Linux czy MacOS-X.

Jeżeli miałoby to być niezależnie od systemu, to można do tego podejść 
może niezbyt optymalnie, ale za to chyba niezawodnie:

1. Sprawdzić, czy taki plik już istnieje. Jeżeli istnieje - to jest 
poprawna nazwa pliku.
2. Spróbować utworzyć taki plik. Jeżeli się uda, to nazwa jest poprawna, 
a utworzony plik usunąć z dysku. Jeżeli się nie uda, to nazwa nie jest 
poprawna.

Powyższy algorytm będzie działać w folderach, do których aplikacja ma 
pełne prawa. Nie zadziała np. w folderze "c:\Program Files" lub 
"c:\Windows" w Windows Vista i późniejszych. Może też nie zadziałać w 
przypadku dysków sieciowych, do których aplikacja (użytkownik) nie ma 
pełnych praw.

-- 
Pozdrawiam,

Grzegorz Skoczylas
http://gskoczylas.rekord.pl
----------------------------------------------

W dniu 19.04.2010 19:51, Grzegorz Skoczylas pisze:
[ciach]
>
> Faktycznie. Pomyliłem się.
>
> W JEDI znalazłem taką funkcję:
>
> function ValidFileName(const FileName: string): Boolean;
>
> function HasAny(const Str, Substr: string): Boolean;
> var
> I: Integer;
> begin
> Result := False;
> for I := 1 to Length(Substr) do
> begin
> if Pos(Substr[I], Str) > 0 then
> begin
> Result := True;
> Break;
> end;
> end;
> end;
>
> begin
> Result := (FileName <> '') and (not HasAny(FileName, '/<>"?*|'));
> if Result then
> Result := Pos('\', ExtractFileName(FileName)) = 0;
> end;
>
>
> To oczywiście dotyczy systemu Windows. Właściwie należałoby jeszcze
> sprawdzić, czy pełna ścieżka do pliku nie przekracza 260 znaków (w
> Delphi stała MAX_PATH z modułu Windows).
>
> Nie wiem, jakie są ograniczenia w Linux czy MacOS-X.
>
> Jeżeli miałoby to być niezależnie od systemu, to można do tego podejść
> może niezbyt optymalnie, ale za to chyba niezawodnie:
>
> 1. Sprawdzić, czy taki plik już istnieje. Jeżeli istnieje - to jest
> poprawna nazwa pliku.
> 2. Spróbować utworzyć taki plik. Jeżeli się uda, to nazwa jest poprawna,
> a utworzony plik usunąć z dysku. Jeżeli się nie uda, to nazwa nie jest
> poprawna.
>
> Powyższy algorytm będzie działać w folderach, do których aplikacja ma
> pełne prawa. Nie zadziała np. w folderze "c:\Program Files" lub
> "c:\Windows" w Windows Vista i późniejszych. Może też nie zadziałać w
> przypadku dysków sieciowych, do których aplikacja (użytkownik) nie ma
> pełnych praw.
>

Właściwie to już napisałem sobie podobnie działającą funkcję jak
ta ValidFileName, którą przytoczyłeś, choć jest trochę prostsza,
bo wyskrobałem ją na szybko:

function NazwaPoprawna(const FileOrDir: string): Boolean;
var i: Integer;
const NOCHAR = ['\','/',':','*','?','"','<','>','|'];
begin
   Result := True;
   for i := 1 to Length(FileOrDir) do
     if FileOrDir[i] in NOCHAR then begin
       Result := False; Break;
     end;
end;

Nie jestem pewien, czy to zadziała, gdy w nazwie trafią się
np. polskie literki. Chyba muszę przetestować.

Program ma działać przede wszystkim w Linuksie, ale chciałbym
aby w przyszłości można go było uruchamiać także w Windows.

Metoda z tworzeniem pliku jest chyba najpewniejsza, ale przypomina
nieco sięganie prawą ręką do lewego ucha, czego wolałbym uniknąć.
I sprawdzenie długość faktycznie nie zaszkodziłoby.

Dzięki za wskazówki,
Sławek

On Mon, 19 Apr 2010 23:35:42 +0200, Terrmit wrote:
> Nie jestem pewien, czy to zadziała, gdy w nazwie trafią się
> np. polskie literki. Chyba muszę przetestować.

NTFS i wszystkie znane mi filesystemy(ext2/3 & reiserfs) 
*nixowe obsługują polskie diakrytyki bez problemu.

Jak znam życie, będą najwyżej problemy z aktualna stroną
kodową konsoli xD. Lub też z brakiem obsługi unicode
w fpc[to się nadal nie zmieniło?] - więc do stringa
sensownie nie upchniesz katakany :).

-- 
Pozdrawiam,
Łukasz 'Maly' Ostrowski.      http://l3v.pl/
ICQ: 148498663     GG: 2544385      AIM: malyzgora
GTalk: l3vi4than@gmail.com        ASTRA: L3viathan

> Lub też z brakiem obsługi unicode w fpc[to się nadal nie zmieniło?]
> - więc do stringa sensownie nie upchniesz katakany :).

FPC obsługuje widestringi i unicodestringi, ale

- plik źródłowy nie może być w UTF-16
- plik źródłowy może być w UTF-8, ale kompilator niestety nie zdekoduje 
znaków, więc przypisanie

  var s:unicodestring;
  s:='カタカナ';

  nie da tego co powinno (s będzie zawierało 'カタカナ'). Jedyne co się 
da to

  s:=#12459#12479#12459#12490;

- writeln tego na konsoli nie wyświetli. Nawet unicodestringa z polskimi 
literami prawidłowo nie wyświetla, gdyż przeprowadza konwersję na stronę 
kodową ANSI zamiast OEM.


-- 
Azarien

On Tue, 20 Apr 2010 20:09:30 +0200, Wiktor S. wrote:
> FPC obsługuje widestringi i unicodestringi, ale
> 
> - plik źródłowy nie może być w UTF-16
> - plik źródłowy może być w UTF-8, ale kompilator niestety nie zdekoduje 
> znaków, więc przypisanie
> 
>   var s:unicodestring;
>   s:='カタカナ';

Explicit deklaracja zmiennej "unicodestring" nie jest dla mnie
obsługą Unicode/UTF-8/etc ;-). string z .NET/String z Javy 
jest ;-). OP ma za dużo naleciałości czasowych.

>   nie da tego co powinno (s będzie zawierało 'カタカナ'). Jedyne co się 
> da to
> 
>   s:=#12459#12479#12459#12490;

Kombinowanie, hacki i okolice, to też nie jest Unicode :).

> - writeln tego na konsoli nie wyświetli. Nawet unicodestringa z polskimi 
> literami prawidłowo nie wyświetla, gdyż przeprowadza konwersję na stronę 
> kodową ANSI zamiast OEM.

Noo własnie, to tylko kontynuacja poprzednij punktów. =]. Obsługuje
ale... nie :).

-- 
Pozdrawiam,
Łukasz 'Maly' Ostrowski.      http://l3v.pl/
ICQ: 148498663     GG: 2544385      AIM: malyzgora
GTalk: l3vi4than@gmail.com        ASTRA: L3viathan

W dniu 20.04.2010 20:30, Łukasz 'Maly' Ostrowski pisze:
> On Tue, 20 Apr 2010 20:09:30 +0200, Wiktor S. wrote:
>> FPC obsługuje widestringi i unicodestringi, ale
>>
>> - plik źródłowy nie może być w UTF-16
>> - plik źródłowy może być w UTF-8, ale kompilator niestety nie zdekoduje
>> znaków, więc przypisanie
>>
>>    var s:unicodestring;
>>    s:='カタカナ';
>
> Explicit deklaracja zmiennej "unicodestring" nie jest dla mnie
> obsługą Unicode/UTF-8/etc ;-). string z .NET/String z Javy
> jest ;-). OP ma za dużo naleciałości czasowych.
>
>>    nie da tego co powinno (s będzie zawierało 'カタカナ'). Jedyne co się
>> da to
>>
>>    s:=#12459#12479#12459#12490;
>
> Kombinowanie, hacki i okolice, to też nie jest Unicode :).
>
>> - writeln tego na konsoli nie wyświetli. Nawet unicodestringa z polskimi
>> literami prawidłowo nie wyświetla, gdyż przeprowadza konwersję na stronę
>> kodową ANSI zamiast OEM.
>
> Noo własnie, to tylko kontynuacja poprzednij punktów. =]. Obsługuje
> ale... nie :).
>

Dzięki za wskazówki. Aż sobie to chyba posprawdzam w wolnej chwili.

Sławek

> Noo własnie, to tylko kontynuacja poprzednij punktów. =]. Obsługuje
> ale... nie :).

Interesujący art pracownika Microsoftu na temat unicode w konsoli:

http://blogs.msdn.com/michkap/archive/2010/04/07/9989346.aspx


-- 
Azarien

On pon, 19 kwi 2010 23:35:42 in article news:<hqiifa$nri$1@news.mm.pl>
Terrmit wrote:
> Właściwie to już napisałem sobie podobnie działającą funkcję jak
> ta ValidFileName, którą przytoczyłeś, choć jest trochę prostsza,
> bo wyskrobałem ją na szybko:
> 
> function NazwaPoprawna(const FileOrDir: string): Boolean;
> var i: Integer;
> const NOCHAR = ['\','/',':','*','?','"','<','>','|'];
> begin
>   Result := True;
>   for i := 1 to Length(FileOrDir) do
>     if FileOrDir[i] in NOCHAR then begin
>       Result := False; Break;
>     end;
> end;
> 
> Program ma działać przede wszystkim w Linuksie, ale chciałbym
> aby w przyszłości można go było uruchamiać także w Windows.

Na linuksie jedyny znak zabroniony to: '/' + specjalne nazwy '.' oraz '..' 
;)

W dniu 23.04.2010 18:43, Mirek pisze:
[ciach]
> Na linuksie jedyny znak zabroniony to: '/' + specjalne nazwy '.' oraz '..'
> ;)
Zgadza się, jednak wolę unikać jakichkolwiek znaków mogących sprawić
problem w różnych systemach. Dzięki temu można też łatwo przekopiować
całą strukturę katalogów na inny system.
Dziękuję za zwrócenie uwagi na pojedynczą kropkę i dwie kropki.
Małe są szanse, żeby taka nazwa wystąpiła, ale jak już robić
sprawdzanie, to do końca ;)

Sławek

W dniu 2010-04-23 19:25, Terrmit pisze:
> W dniu 23.04.2010 18:43, Mirek pisze:
> [ciach]
>> Na linuksie jedyny znak zabroniony to: '/' + specjalne nazwy '.' oraz
>> '..'
>> ;)
> Zgadza się, jednak wolę unikać jakichkolwiek znaków mogących sprawić
> problem w różnych systemach. Dzięki temu można też łatwo przekopiować
> całą strukturę katalogów na inny system.
> Dziękuję za zwrócenie uwagi na pojedynczą kropkę i dwie kropki.
> Małe są szanse, żeby taka nazwa wystąpiła, ale jak już robić
> sprawdzanie, to do końca ;)

Jak do końca, to są, jak sądzę, jeszcze inne przypadki szczególne. Na 
przykład w czasach DOS w sposób szczególny traktowane były następujące 
nazwy plików:
- com
- aux1
- aux2
- prn
- nul
- lpt1
- lpt2

Pamiętam, że najprostszym sposobem sprawdzenia, czy pliki z dyskietki 
można odczytać, było wykonanie polecenia:

   COPY *.* NUL

a wydrukowanie pliku tekstowego na drukarce można było zrealizować 
wykonując polecenie:

   COPY PLIK.TXT PRN

Nie pamiętam, czy były jeszcze jakieś inne specjalne nazwy plików, ale 
przed chwilą sprawdziłem, że w Windows Vista w trybie znakowym powyższa 
instrukcja działa tak samo, jak w czasach DOS, czyli kopiuje pliki do 
"urządzenia pustego" czyli donikąd.

-- 
Pozdrawiam,

Grzegorz Skoczylas
http://gskoczylas.rekord.pl
----------------------------------------------

W dniu 2010-04-23 21:18, Grzegorz Skoczylas pisze:
> [...]
> przed chwilą sprawdziłem, że w Windows Vista w trybie znakowym powyższa
> instrukcja działa tak samo, jak w czasach DOS, czyli kopiuje pliki do
> "urządzenia pustego" czyli donikąd.

Chodziło mi w tym miejscu o instrukcję:

    COPY *.* NUL

Przeredagowywałem trochę poprzedni list i nie zauważyłem tej pomyłki.

-- 
Pozdrawiam,

Grzegorz Skoczylas
http://gskoczylas.rekord.pl
----------------------------------------------

W dniu 23.04.2010 21:18, Grzegorz Skoczylas pisze:
> W dniu 2010-04-23 19:25, Terrmit pisze:
>> W dniu 23.04.2010 18:43, Mirek pisze:
>> [ciach]
>> Małe są szanse, żeby taka nazwa wystąpiła, ale jak już robić
>> sprawdzanie, to do końca ;)
>
> Jak do końca, to są, jak sądzę, jeszcze inne przypadki szczególne. Na
> przykład w czasach DOS w sposób szczególny traktowane były następujące
> nazwy plików:
> - com
> - aux1
> - aux2
> - prn
> - nul
> - lpt1
> - lpt2
>
> Pamiętam, że najprostszym sposobem sprawdzenia, czy pliki z dyskietki
> można odczytać, było wykonanie polecenia:
>
> COPY *.* NUL
>
> a wydrukowanie pliku tekstowego na drukarce można było zrealizować
> wykonując polecenie:
>
> COPY PLIK.TXT PRN
>
> Nie pamiętam, czy były jeszcze jakieś inne specjalne nazwy plików, ale
> przed chwilą sprawdziłem, że w Windows Vista w trybie znakowym powyższa
> instrukcja działa tak samo, jak w czasach DOS, czyli kopiuje pliki do
> "urządzenia pustego" czyli donikąd.
>
Dzięki
Faktycznie były i są takie nazwy wciąż w użyciu w Windows.
Heh, ma ktoś jeszcze jakieś wyjątki? Może coś z systemów MacOS?
Na makówkach się nie znam za bardzo, nie zażywam :)

Sławek

> Jak do końca, to są, jak sądzę, jeszcze inne przypadki szczególne. Na
> przykład w czasach DOS w sposób szczególny traktowane były następujące
> nazwy plików:
> - com
> - aux1
> - aux2
> - prn
> - nul
> - lpt1
> - lpt2

trochę odwrotnie:

aux
com1
com2

gdzie aux z definicji równa się com1, a prn=lpt1.

poza tym wcale nie "w czasach DOS". Spróbujcie pod Vistą zapisać notatnikiem 
plik o nazwie nul (nie nul.txt):

| nul
| Ta nazwa pliku jest zarezerwowana do użytku systemu Windows.

Do tego lista nie jest zamknięta. W DOS-ie CD-ROM dostawał oprócz literki 
dysku także nazwę urządzenia, najczęściej CDROM01, ale można było wpisać 
dowolną --> bez aktywnego sprawdzenia listy tych urządzeń nie da się 
przewidzieć, czy nazwa pliku jest prawidłowa.

-- 
Azarien

> Faktycznie były i są takie nazwy wciąż w użyciu w Windows.
> Heh, ma ktoś jeszcze jakieś wyjątki? Może coś z systemów MacOS?
> Na makówkach się nie znam za bardzo, nie zażywam :)

W praktyce nie robi się aż tak dokładnego sprawdzania, tylko podstawowe - 
jeśli nazwa okaże się niepoprawna z jakiegoś egzotycznego powodu, program 
powinien po prostu wyświetlić stosowny komunikat (np. błąd zapisu).
W myśl że ZAWSZE coś może pójść nie tak.


-- 
Azarien

W dniu 25.04.2010 12:36, Wiktor S. pisze:
>> Faktycznie były i są takie nazwy wciąż w użyciu w Windows.
>> Heh, ma ktoś jeszcze jakieś wyjątki? Może coś z systemów MacOS?
>> Na makówkach się nie znam za bardzo, nie zażywam :)
>
> W praktyce nie robi się aż tak dokładnego sprawdzania, tylko podstawowe
> - jeśli nazwa okaże się niepoprawna z jakiegoś egzotycznego powodu,
> program powinien po prostu wyświetlić stosowny komunikat (np. błąd zapisu).
> W myśl że ZAWSZE coś może pójść nie tak.
>
>
Wszystko prawda,

Wystąpienie takich nazw jest mało prawdopodobne i zgadzam się, że
"W praktyce nie robi się aż tak dokładnego sprawdzania", dlatego
robienie takie sprawdzania to bardziej filozofia niż praktyka ;)

Błąd (jaki by nie był) trzeba obsłużyć ręcznie lub za pomocą
dodatkowego kodu. Obsługa ręczna jest nieefektywna (po to jest
komputer, aby wyręczał człowieka), a dodatkowy kod ... tak czy
siak jakiś trzeba wtedy napisać, aby program wykonał zadanie
prawidłowo.

Taka funkcja sprawdzająca dokładnie nazwę pliku/katalogu może
być bardzo przydatna, a wpisanie paru dodatkowych linijek kodu
teraz być może zaoszczędzi nerwów w przyszłości.

Może nie jestem wybitnym programistą, ale zawsze staram się pisać
programy tak, aby były możliwie "głupotoodporne" i aby jak najmniej
wymagały od człowieka zwłaszcza że, ... sam zwykle je potem używam :)

Ech, to są tematy na które można długo filozofować :)

Wszystkim dzięki za wszelką pomoc i wskazówki :),

Sławek

On Fri, 23 Apr 2010 19:25:45 +0200
Terrmit <terrmitv@poczta.onet.pl> wrote:

> W dniu 23.04.2010 18:43, Mirek pisze:
> [ciach]
> > Na linuksie jedyny znak zabroniony to: '/' + specjalne nazwy '.' oraz '..'
> > ;)
> Zgadza się, jednak wolę unikać jakichkolwiek znaków mogących sprawić
> problem w różnych systemach. Dzięki temu można też łatwo przekopiować
> całą strukturę katalogów na inny system.
> Dziękuję za zwrócenie uwagi na pojedynczą kropkę i dwie kropki.
> Małe są szanse, żeby taka nazwa wystąpiła, ale jak już robić
> sprawdzanie, to do końca ;)

A jakich stringów używasz?
To nie jest intymne pytanie ;), tylko wskazówka, że pod Linuksem są DWA
znaki zabronione w nazwach plików. Nie może jeszcze wystąpić #0.

-- 
Tomasz Minkiewicz <tommink@gmail.com>

W dniu 27.04.2010 18:15, Tomasz Minkiewicz pisze:
> On Fri, 23 Apr 2010 19:25:45 +0200
> Terrmit<terrmitv@poczta.onet.pl>  wrote:
>
>> W dniu 23.04.2010 18:43, Mirek pisze:
>> [ciach]
>>> Na linuksie jedyny znak zabroniony to: '/' + specjalne nazwy '.' oraz '..'
>>> ;)
>> Zgadza się, jednak wolę unikać jakichkolwiek znaków mogących sprawić
>> problem w różnych systemach. Dzięki temu można też łatwo przekopiować
>> całą strukturę katalogów na inny system.
>> Dziękuję za zwrócenie uwagi na pojedynczą kropkę i dwie kropki.
>> Małe są szanse, żeby taka nazwa wystąpiła, ale jak już robić
>> sprawdzanie, to do końca ;)
>
> A jakich stringów używasz?
> To nie jest intymne pytanie ;), tylko wskazówka, że pod Linuksem są DWA
> znaki zabronione w nazwach plików. Nie może jeszcze wystąpić #0.
>
Hmm, #0 to pewnie i w Windows nie przejdzie w nazwach plików, jak
sądzę (nie sprawdzałem).
Używam UTF-8, ale biorę pod uwagę, że dane źródłowe mogę otrzymać
w ISO-8859-2 lub nawet windows-1250. Staram się wykryć rodzaj
kodowania i wówczas przeprowadzić konwersję.
Wystąpienie tam znaku #0 jest praktycznie niemożliwe chyba, że
na skutek jakiegoś błędu. Pojawienie się źródła danych w UTF-16
mogłoby mi narobić problemów, ale będę się tym martwił, jak takie
dostanę.
Jeśli chodzi Ci o typ danych, to używam String, nie PChar.
Wykrywanie, czy w tekście nie ma znaku #0 to mimo wszystko dobry
pomysł. Może uchronić przed różnymi "dziwnymi" problemami.

Dzięki,
Sławek

On Wed, 28 Apr 2010 07:16:21 +0200
Terrmit <terrmitv@poczta.onet.pl> wrote:

> W dniu 27.04.2010 18:15, Tomasz Minkiewicz pisze:
> > On Fri, 23 Apr 2010 19:25:45 +0200
> > Terrmit<terrmitv@poczta.onet.pl>  wrote:
> >
> >> W dniu 23.04.2010 18:43, Mirek pisze:
> >> [ciach]
> >>> Na linuksie jedyny znak zabroniony to: '/' + specjalne nazwy '.' oraz '..'
> >>> ;)
> >> Zgadza się, jednak wolę unikać jakichkolwiek znaków mogących sprawić
> >> problem w różnych systemach. Dzięki temu można też łatwo przekopiować
> >> całą strukturę katalogów na inny system.
> >> Dziękuję za zwrócenie uwagi na pojedynczą kropkę i dwie kropki.
> >> Małe są szanse, żeby taka nazwa wystąpiła, ale jak już robić
> >> sprawdzanie, to do końca ;)
> >
> > A jakich stringów używasz?
> > To nie jest intymne pytanie ;), tylko wskazówka, że pod Linuksem są DWA
> > znaki zabronione w nazwach plików. Nie może jeszcze wystąpić #0.
> >
> Hmm, #0 to pewnie i w Windows nie przejdzie w nazwach plików, jak
> sądzę (nie sprawdzałem).

Jak znam życie, to on założyć taki plik pozwoli, ale już nigdy więcej
się nic z niego nie odczyta, ani drania nie usunie. Windows lubi
takie dowcipy. ;>

> Używam UTF-8, ale biorę pod uwagę, że dane źródłowe mogę otrzymać
> w ISO-8859-2 lub nawet windows-1250. Staram się wykryć rodzaj
> kodowania i wówczas przeprowadzić konwersję.
> Wystąpienie tam znaku #0 jest praktycznie niemożliwe chyba, że
> na skutek jakiegoś błędu. 

Masz na myśli, że wiesz, że w danych wejściowych ich nie będzie?
Bo UTF-8 przed nim nie zabezpiecza. Całe dolne ASCII jest przecież
w nim legalne.

> Jeśli chodzi Ci o typ danych, to używam String, nie PChar.

O to pytałem. Gdyby PChary, to sprawy by w ogóle nie było.

-- 
Tomasz Minkiewicz <tommink@gmail.com>

W dniu 2010-04-27 18:15, Tomasz Minkiewicz pisze:
> On Fri, 23 Apr 2010 19:25:45 +0200
> Terrmit<terrmitv@poczta.onet.pl>  wrote:
>
>> W dniu 23.04.2010 18:43, Mirek pisze:
>> [ciach]
>>> Na linuksie jedyny znak zabroniony to: '/' + specjalne nazwy '.' oraz '..'
>>> ;)
>> Zgadza się, jednak wolę unikać jakichkolwiek znaków mogących sprawić
>> problem w różnych systemach. Dzięki temu można też łatwo przekopiować
>> całą strukturę katalogów na inny system.
>> Dziękuję za zwrócenie uwagi na pojedynczą kropkę i dwie kropki.
>> Małe są szanse, żeby taka nazwa wystąpiła, ale jak już robić
>> sprawdzanie, to do końca ;)
>
> A jakich stringów używasz?
> To nie jest intymne pytanie ;), tylko wskazówka, że pod Linuksem są DWA
> znaki zabronione w nazwach plików. Nie może jeszcze wystąpić #0.

Skoro tak, to moim zdaniem należałoby odrzucić wszelkie znaki ze zbioru 
[#0..#31, #127]. Nie jestem pewien znaku o kodzie #255. W DOS chyba nie 
był dopuszczany w nazwie pliku. W Windows i innych systemach - nie 
jestem pewien.

-- 
Pozdrawiam,

Grzegorz Skoczylas
http://gskoczylas.rekord.pl
----------------------------------------------