mapper
oz7aik
jeg bliver itvil om at m� v�re mellerum mellem 2 ord eller skal der v�re _
f.eks om klubber eller om_klubber
Jpb
Bertel Lund Hansen
> jeg bliver itvil om at m� v�re mellerum mellem 2 ord eller skal der v�re _
> f.eks om klubber eller om_klubber
Brug kun websikre tegn til mapper og filer der skal ligge p�
nettet. Websikre tegn er
1. sm� engelske bogstaver
2. de ti cifre
3. understreg
Livet er for kort til at spekulere over om man m� bruge det ene
eller det andet tegn - og p� om det m�ske virker p� system A men
ikke p� system B eller s�gar system C som dukker op senere.
--
Bertel
http://bertel.lundhansen.dk/ FIDUSO: http://fiduso.dk/
Stig Johansen
> 1. sm� engelske bogstaver
> 2. de ti cifre
> 3. understreg
>
> Livet er for kort til at spekulere over om man m� bruge det ene
> eller det andet tegn - og p� om det m�ske virker p� system A men
> ikke p� system B eller s�gar system C som dukker op senere.
Enig, men man kan ogs� bruge .
Jeg er begynd at synes bedre om f.eks "om.klubber" frem for "om_klubber",
men det er nok en smagssag.
Muligvis kan det have betydning for s�gemaskiner, for jeg synes de skriver
noget om, at man skal bruge 'sigende' filnavne.
--
Med venlig hilsen
Stig Johansen
Erik Olsen
Jeg har i nogle tilf�lde anvendt bindestreg i filnavne, men jeg har ikke
pr�vet at bruge det i mappenavne.
--
Venlig hilsen/Best regards
Erik Olsen
http://www.modelbaneteknik.dk/
Stig Johansen
> Jeg har i nogle tilf�lde anvendt bindestreg i filnavne, men jeg har ikke
> pr�vet at bruge det i mappenavne.
Det kan man sikker ogs� bruge (sikkert) i dag.
Men jeg har gennem tiderne v�ret ude for operativsystemer, hvor - blev
opfattet som en operator, s� derfor undg�r jeg dem.
oz7aik
"Stig Johansen" <wop...@gmaill.com> skrev i meddelelsen
news:4b392873$0$283$1472...@news.sunsite.dk...
1000 tak for jeres hj�lp
fortsat god nat
Jbp
Bertel Lund Hansen
> Enig, men man kan ogs� bruge .
Der er flere andre tegn der vist ogs� kan bruges. Og hvad s�?
Fil- og mappenavne er ligegyldige. Man klikker bare p� det man
skal bruge, og man l�ser p� siden - ikke i adresseboksen.
> Muligvis kan det have betydning for s�gemaskiner, for jeg synes de skriver
> noget om, at man skal bruge 'sigende' filnavne.
Hvis s�gemaskiner ikke kan tolke understreg som mellemrum, s� er
det v�rst for dem selv.
Stig Johansen
> Der er flere andre tegn der vist ogs� kan bruges.
Ja, (stort set) alle tegn kan bruge i moderne filsystemer, s� hvad er
pointen?
> Og hvad s�?
> Fil- og mappenavne er ligegyldige. Man klikker bare p� det man
> skal bruge, og man l�ser p� siden - ikke i adresseboksen.
Ja, men nu har jeg s�dan set en filoversigt p� min egen maskine, og der kan
jeg bedre finde rundt med fil/mappenavne med . i stedet for _
S� min pointe var, at det er lige s� vigtigt at bevare den interne
overskuelighed (for mit vedkommende).
Pr�v f.eks. at t�nke med filnavne som:
om.klubber
mine.klubber
vores.klubber
og lav en ls (dir i DOS) *.klubber
osv.
Det kan man ikke g�re med _ eller - (i DOS/Linux)
Bertel Lund Hansen
> Ja, men nu har jeg s�dan set en filoversigt p� min egen maskine,
Jeg citerer lige mig selv:
Brug kun websikre tegn til mapper og filer
der skal ligge p� nettet.
--
JbP
"Bertel Lund Hansen" <splittemi...@lundhansen.dk> skrev i meddelelsen
news:igojj5lg9rhf8gk3s...@news.stofanet.dk...
> Stig Johansen skrev:
>
>> Ja, men nu har jeg s�dan set en filoversigt p� min egen maskine,
>
> Jeg citerer lige mig selv:
>
> Brug kun websikre tegn til mapper og filer
> der skal ligge p� nettet.
>
> --
Anders Wegge Keller
> og lav en ls (dir i DOS) *.klubber osv.
> Det kan man ikke gøre med _ eller - (i DOS/Linux)
*_klubber ville nok være et bedre valg. Jeg ved ikke om du har en
anden pointe, men . er ikke et magisk tegn i et filnavn.
--
/Wegge
Leder efter redundant peering af dk.*,linux.debian.*
Bertel Lund Hansen
> Hvad er websikre tegn?
Det fremg�r af mit f�rste svar i tr�den.
Stig Johansen
> Jeg citerer lige mig selv:
>
> Brug kun websikre tegn til mapper og filer
> der skal ligge p� nettet.
Og jeg reciterer mig selv:
(stort set) alle tegn kan bruge i moderne filsystemer
Der er *ikke* noget der hedder 'websikre tegn' - det afh�nger alene af
filsystemet p� webserveren.
Men jeg medgiver at man p� *nix systemer b�r holde sig til (upper eller)
lowercase, da de uvist af hvilken �rsag har valgt at lave filsystemet case
sensitivt.
Nu bryder Anders nok ind, men i min optik er det at p*sse ved siden af
potten.
Stig Johansen
> Der er *ikke* noget der hedder 'websikre tegn' - det afh�nger alene af
> filsystemet p� webserveren.
Men hvis vi snakker _browsere_, s� kan der godt v�re differens om de encoder
URI'er med UTF-8 eller anden encoding, men det er *browserne* der
differerer, og ikke serverne.
Bertel Lund Hansen
> Men jeg medgiver at man p� *nix systemer b�r holde sig til (upper eller)
> lowercase, da de uvist af hvilken �rsag har valgt at lave filsystemet case
> sensitivt.
Du tror at Microsoft definerer it-verdenen? Det er *dem* der har
indf�rt systemer der ikke kan kende forskel p� sm� og store
bogstaver. De er fra starten (og internt i M$-systemerne) tildelt
forskellige koder - naturligvis.
Jens Peter Karlsen
efter filendelsen og det vil jo v�re htm eller lignende s� din s�gning
skal laves om til *.klubber.* og s� holder dit argument om at det
skulle v�re lettere ikke, da det jo er lige s� let at skrive
*-klubber.* eller *_klubber.*
At man efter dit udsagn ser bort fra en filendelse i en LS i *nix
synes jeg er bekymrende.
Regards Jens Peter Karlsen.
On Tue, 29 Dec 2009 11:56:40 +0100, Stig Johansen <wop...@gmaill.com>
wrote:
Anders Wegge Keller
> Nu bryder Anders nok ind, men i min optik er det at p*sse ved siden
> af potten.
Det handler i høj grad om hvad man er blevet vænnet til som værende
"naturligt". Men medmindre DOS også case-folder ã, â, á og ä til et
rent a, vil jeg betragte det som en halv implementation.
Stig Johansen
> Du tror at Microsoft definerer it-verdenen? Det er *dem* der har
> indf�rt systemer der ikke kan kende forskel p� sm� og store
> bogstaver.
Der tager du ganske fejl.
Jeg er 'opflasket' med det her:
<http://en.wikipedia.org/wiki/HP_3000>
Som ikke er(var) case sensitiv p� filnavne.
At tro at MS har 'defineret' IT verdenen er meget naivt (bortset fra
PC'ere).
Stig Johansen
> I DOS eller Windows vil det virke med .. I dit eksempel vil man lede
> efter filendelsen og det vil jo v�re htm eller lignende s� din s�gning
> skal laves om til *.klubber.* og s� holder dit argument om at det
> skulle v�re lettere ikke, da det jo er lige s� let at skrive
> *-klubber.* eller *_klubber.*
Ja ja, lad os ikke t�rske langhalm p� det - jeg skrev ikke det var
_lettere_, men (citat):
> Jeg er begynd at synes bedre om f.eks "om.klubber" frem for "om_klubber",
> men det er nok en smagssag.
Dvs. _jeg_ synes bedre om ., men som sagt er det en _smagssag_.
Jeg synes ikke jeg har pr�vet at promovere en endegyldig sandhed.
oz7aik
hej igen
P� min udbyders server har jeg en mappe _private,
Kan man have flere mapper med _ foran s� man kan snyde s�ge robotterne
Jeg vil have nogle mapper hvor jeg vil have nogle file som kun skal bruges
til inds�tning p� mine sider, som andre bruger ellers ikke kan bruge til
noget fornuftigt og for at minimere snavs p� nettet
eller er der en anden mulighed.?
JbP
Philip Nunnegaard
> P� min udbyders server har jeg en mappe _private,
> Kan man have flere mapper med _ foran s� man kan snyde s�ge robotterne
> Jeg vil have nogle mapper hvor jeg vil have nogle file som kun skal
> bruges til inds�tning p� mine sider, som andre bruger ellers ikke kan
> bruge til noget fornuftigt og for at minimere snavs p� nettet
>
> eller er der en anden mulighed.?
Nu ved jeg ikke hvem du vil holde mapperne v�k fra, men hvis det bare er
s�gemaskinerne, kan du smide en robots.txt ude i roden (samme mappe som
din f�rste index-fil).
Denne fil kan indeholde:
User-agent: *
Disallow: /mappe1/
Disallow: /mappe2/
osv.
--
Philip - http://www.chartbase.dk | http://www.hitsurf.dk
Rune Jensen
> Denne fil kan indeholde:
>
> User-agent: *
> Disallow: /mappe1/
> Disallow: /mappe2/
>
> osv.
Men man skal tage i betragtning bes�gende, som har onde hensigter, og
v�lge sine disallows med omtanke f.eks. er dette m�ske ikke smart:
---
Disallow: /passwords/
---
robots.txt kan l�ses af alle. Det samme kan i�vrigt en sitemap, hvis det
er (men OK, et dynamisk sitemap kan man nok holde mere lukket end som s�
med lidt testing).
I stedet for at bruge robots.txt til at skjule private ting, skal man
hellere unders�ge, om hosteren tillader filer udenfor scope. Der er
mindst �t s�dant bibliotek, nemlig DB-biblioteket.
MVH
Rune Jensen
oz7aik
"Philip Nunnegaard" <nunne...@hitsurf.dk> skrev i meddelelsen
news:4b3a387c$0$56796$edfa...@dtext02.news.tele.dk...
hej igen,
f.eks. p� nogen sider har jeg Include en fil
<!--webbot bot="Include" U-Include="../../_Menuer/medlems_menu.htm"
TAG="BODY" startspan -->
den fil menu.htm fra mappen Menuer er der ingen der har gl�de af, kun som
indsat fil.
http://www.oz7aik.dk/faglig/index.htm
JbP
Bertel Lund Hansen
> den fil menu.htm fra mappen Menuer er der ingen der har gl�de af, kun som
> indsat fil.
Hvorfor s� s�tte en borgerkrig i v�rk for at 'skjule' dem - hvor
man jo alligevel kan se dem p� normalsiden?
Rune Jensen
> oz7aik skrev:
>
>> den fil menu.htm fra mappen Menuer er der ingen der har gl�de af, kun som
>> indsat fil.
>
> Hvorfor s� s�tte en borgerkrig i v�rk for at 'skjule' dem - hvor
> man jo alligevel kan se dem p� normalsiden?
Hvis du bruger ASP, kan du g�re dette for at sikre at UDELUKKENDE din
side kan kalde inkluderede scripts:
if instr( request.servervariables("SCRIPT_NAME"), ".inc.asp") then
Response.Status = "404 Go play somewhere else, not here"
Response.Write "Congratulations - you've found an EASTER EGG!"
Response.End
end if
Det kr�ver, dine inklude-filer ligger med endelsen .inc.asp.
Bliver filen kaldt fra (inkluderet i) et af dine egne scripts, udf�res
IF-s�tningen ikke, men bliver den kaldt direkte fra address baren
f.eks., f�r man teksten:
Congratulations - you've found an EASTER EGG!
Jeg bruger det selv, efter jeg fandt ud af, at visse inklude filer r�g
p� Google, og det er ret sk�g at se, hvor lidt interesse der har v�ret i
de filer efter det, selv om de bare l� frit fremme... nu er de
efterh�nden ikke at finde mere, men koden beholder jeg.
MVH
Rune Jensen
oz7aik
"Rune Jensen" <runeof...@gmail.com> skrev i meddelelsen
news:4b3a454d$0$4819$456a...@news.cirque.dk...
1000 tak for svare alle
ps. hvorfor skal det v�re s� sv�rt
Godt Nyt�r til all
JbP
Philip Nunnegaard
> Men man skal tage i betragtning bes�gende, som har onde hensigter, og
> v�lge sine disallows med omtanke f.eks. er dette m�ske ikke smart:
>
> ---
>
> Disallow: /passwords/
>
> ---
S�dan noget ville jeg heller ikke turde s�tte ind - netop fordi det nok
ligefrem ville *tiltr�kke* ondsindede botter.
Men nu gik jeg ud fra at det udelukkende var s�gemaskiner af den venlige
slags vi talte om her.
> I stedet for at bruge robots.txt til at skjule private ting, skal man
> hellere unders�ge, om hosteren tillader filer udenfor scope. Der er
> mindst �t s�dant bibliotek, nemlig DB-biblioteket.
Det kommer nok an p� udbyderen.
PHP-hoteller har i udgangspunktet ikke et DB-bibliotek som man kan tilg�
(MySQL gemmes jo ikke som .mdb-filer ligesom Access). Jeg har dog
mulighed for at gemme forskellige ting udenfor scope p� mit webhotel.
Men jeg husker ikke om man f.eks. kunne hos one.com.
Frank Damgaard
> Bertel Lund Hansen wrote:
>
>> Jeg citerer lige mig selv:
>>
>> Brug kun websikre tegn til mapper og filer
>
> Og jeg reciterer mig selv:
> (stort set) alle tegn kan bruge i moderne filsystemer
>
> filsystemet på webserveren.
Men der er tilladte, reserverede tegn og dem man ikke må bruge i URI
selvom filsystemet tillader dem.
De er faktisk defineret i de relevante RFC'ere.
Se http://www.ietf.org/rfc/rfc3986.txt
(og http://tools.ietf.org/html/rfc2616 )
her er følgende reserverede / ikke tilladte i filnavne/pathnavne :
% / ? #
hex 01-31, blanktegn, \ " & < > [ ] ^ ` { | } ~
En del er dog tilladte hvis de %encodes.
chars 128-255 har tidligere også været forbudt, men jeg syntes ikke
længere det står i seneste RFC version af URI.
Problemet med URL og non-ASCII tegn (populært dem med bit "8 sat") er at det
ikke er defineret i standarden, udover ved %encoding.
For hvordan skal den stakkels webserver vide hvilke tegnsæt det er når
det ikke er defineret hvordan denne tegnsæt-information skal overføres?
Er det IBM codepage 865 ?, er det ISO-8859-15 ?, et det UTF-16, eller UTF-8 eller
EBDIC.... ?
I givet faldt overføres nogle andre bytes-sekvenser, og så får man nok 404 svar tilbage.
>
> Men jeg medgiver at man på *nix systemer bør holde sig til (upper eller)
> lowercase, da de uvist af hvilken årsag har valgt at lave filsystemet case
> sensitivt.
sådan har ASCII da været altid? dvs: a != A
Jeg ved ikke hvorfor DOS/Windows begyndte på dette, måske et levn fra CP/M ?
eller fordi man havde et 64 nit tegnsæt med kun store bogstaver?
eller teletype?
For os Unix-folk er det en syg tanke at filnavne ikke er case-sensitive ;)
(og Unix er ældre end CP/M og DOS)
Men egentlig er det filstystenet, for en FAT system i linux vil opfører
sig på samme måde som i DOS/windows.
Men egentlig er det lidt ligegyldig om filsystemet er case sensitive eller ej,
bare man som server-bruger ved det når man lægger filer op og laver URL til filerne.
(men det kan så give problemer hvis man flytter sine filer mellem
forskellige filsystemer/OS)
Og man bør være klar over hvilke tegn er tilladt og hvilke ikke er tilladt, for her
kan der også væe lidt flere restriktioner end dem der er angivet i URL-RFC'eren .
Stig Johansen
> chars 128-255 har tidligere ogs� v�ret forbudt, men jeg syntes ikke
> l�ngere det st�r i seneste RFC version af URI.
Sidst jeg kiggede stod der bare at URIer skal encodes i UTF-8, men det vil
nok give lidt b�vl med IE/IIS.
Der g�r nok flere �r f�r man kan v�re rimelig sikker p� det virker
crossbrowser og server.
> Er det IBM codepage 865 ?, er det ISO-8859-15 ?, et det UTF-16, eller
> UTF-8 eller EBDIC.... ?
Det er da HP Roman8 :-)
> Jeg ved ikke hvorfor DOS/Windows begyndte p� dette, m�ske et levn fra CP/M
> ? eller fordi man havde et 64 nit tegns�t med kun store bogstaver?
> eller teletype?
Det er ikke DOS/windows der 'begyndte' med det.
> For os Unix-folk er det en syg tanke at filnavne ikke er case-sensitive ;)
For os Mainframe/Cobol/Pascal folk er det en syg tanke at
filsystem/programmeringssprog er case sensitive ;)
Det er faktisk seri�st ment, for det giver alt for mange fejlmuligheder.
> (og Unix er �ldre end CP/M og DOS)
Det er mainframe sogs�.
> Men egentlig er det lidt ligegyldig om filsystemet er case sensitive eller
> ej, bare man som server-bruger ved det n�r man l�gger filer op og laver
> URL til filerne.
Jo, og det er ogs� derfor Bertel (og jeg) anbefale at bruge udelukkende sm�
bogstaver og undg� 'specialtegn'.
Det er jo effekten at, at skidtet er case sensitivt.
For at undg� fejl bliver man n�dt til at lave alt med sm�t, hvilket i mine
�jne ikke fremmer l�sbarheden.
Men som du nok kan se, s� kan vi starte en relifgionskrig, hvor vi absolut
ikke er enige.
Stig Johansen
> Det handler i h�j grad om hvad man er blevet v�nnet til som v�rende
> "naturligt". Men medmindre DOS ogs� case-folder �, �, � og � til et
> rent a, vil jeg betragte det som en halv implementation.
Nu er vi nok lidt ude over web_design_, men du har ret i hvad der er
'naturligt'.
N�r man snakker administrativ EDB, is�r i st�rre organisationer, herunder
ogs� statslige institutioner, s� har man traditionelt 2 'drev'.
(Windows har det med at operere med 'drev' i stedet for mount points).
Udgangspunktet er, at alle PC'ere er Windows, og det tror jeg faktisk det
vil vedblive at v�re, m�ske for tid og evighed pga. Linux folkets forkerte
tilgang til bla. compatibility.
N�, men disse 2 'drev' er typisk et 'f�llesdrev' og et 'homedrev'.
'home drev' er ens eget, og er placeret p� en server af hensyn til backup.
'f�lles drevet' siger n�sten sig selv, for der ligger de filer/dokumenter,
der er f�lles for alle.
Herudover er der selvf�lgelig andre 'drev', til forskellige grupper af
personer.
Her kommer problemstillingen med case sensitivity, for man kan ikke forvente
at almindelige d�delige brugere skal forholde sig til store og sm�
bogstaver.
I disse scenarier er det filnavnet, der b�rer informationen til oversigter.
T�nk p� f.eks.
"Jubil�um.2009.12.doc"
Her kan 'd�delige brugere' se hvad det handler om.
Ud over �'et, s� giver det jo ingen mening at en bruger skal forholde sig
til om det er Jubil�um.. eller jubil�um.. - i det menneskelige �je er det
en og samme sag.
P� samme m�de hvis regnskabsdirekt�ren l�gger regnskab ud - hvad er
forskellen p�
Regnskab..,regnskab..,RegnSkab...
Den konvention man gemmer under er subjektiv, og b�r ikke influere p�
resultatet.
N�r man opererer med case sensitive filer, s� er ovenst�ende reelt 3
forskellige filer, uagtet at betydningen, og dermed indholdet er det
_samme_.
Det er en 25+ �r kendt problemstilling (sikkert l�ngere, men jeg har 'kun'
kendt den i 25+ �r), men sikkert ikke for *nix n�rderne, og netop derfor
tror jeg ikke *nix vil vinde indpas p� det omr�de.
Som tidligere n�vnt, s� n�r vi snakker web, s� handler det egentlig kun om
at der er konsistens mellem links og target, da disse angives.
Men der er det aberdabei, at hvis man _taster_ links ind, s� har det
pludselig betydning om man skriver med stort eller sm�t (p� *nix).
T�nk bare hvis det skrevne ord havde samme skelnen, som f.eks:
Han sagde...
Idet han sagde...
Her ville 'Han' og 'han' v�re to forskellige personer, selvom der er den
samme vi snakker om.
Nu n�vner du nogle vokaler med umlaud, circonflex og accent de gu
(det er 35+ �r siden jeg havde Fransk, s� det er sikert forkert), men jeg
vil g� st�rkt ud fra at samme problemstilling eksisterer i s�vel Tyskland
(eller var der Svensk) som Frankrig.
S� jeg vil g�tte p�, at Windows ogs� laver korrekt case p� disse tegn.
MS har jo s�dan set haft unicode siden Win95, dog i starten UCS2, men jeg
ved faktisk ikke om der er nogle codepoints (den dag i dag), der falder
inden for surrogate pairs i UTF-16 - m�ske Klingon, som der er rygter om
har f�et reserveret sine egne codepoints.
Dermed f�lger, at MS har haft i omegnen af 15 �r til at f� styr p�
upper/lowecase, s� mon ikke de har det?
Erik Ginnerskov
> Men som du nok kan se, s� kan vi starte en relifgionskrig, hvor vi
> absolut ikke er enige.
Hvorfor religionskrig? Hver is�r har opridset nogle historiske
kensgerninger, som ingen af jer alligevel kan lave om p�. Og fakta idag er,
at case er uden betydning i Windows mens Unix/Linux er url'er
case-sensitive.
Vi ved derfor alle, at p� en Win/IIS er Frokost.Jpg og frokost.jpg den samme
fil, mens det p� Nix/Apache er to forskellige filer, alts� er der nogen
fornuft i at anbefale konsekvent at bruge sm� bogstaver til alt hvad der
skal p� nettet - s� opst�r der ikke forvirring og brugerne undg�r en 404.
--
Med venlig hilsen
Erik Ginnerskov
http://ginnerskov.dk - http://html-faq.dk
Rune Jensen
> Her kommer problemstillingen med case sensitivity, for man kan ikke forvente
> at almindelige d�delige brugere skal forholde sig til store og sm�
> bogstaver.
<SNIP>
> Den konvention man gemmer under er subjektiv, og b�r ikke influere p�
> resultatet.
Det lyder som valid synspunkt i mine �rer.
> N�r man opererer med case sensitive filer, s� er ovenst�ende reelt 3
> forskellige filer, uagtet at betydningen, og dermed indholdet er det
> _samme_.
Et sp�rgsm�l i den forbindelse:
Vil
minhjemmeside.dk/minside.asp
opfattes som samme side som
MinHjemmeside.dk/MinSide.asp
p� nettet? F.eks. af s�genotter?
N�r jeg skriver en URL med blanding af store og sm� boigstaver, bliver
resultatet, at alle konverteres til sm� bogstaver i adresselinjen. Men
jeg kunne da godt forestille mig, det kan skabe problemer?
Hvad med
og
?
MVH
Rune Jensen
Bertel Lund Hansen
> > N�r man opererer med case sensitive filer, s� er ovenst�ende reelt 3
> > forskellige filer, uagtet at betydningen, og dermed indholdet er det
> > _samme_.
> Et sp�rgsm�l i den forbindelse:
> Vil
> minhjemmeside.dk/minside.asp
> opfattes som samme side som
> MinHjemmeside.dk/MinSide.asp
> p� nettet? F.eks. af s�genotter?
Nej, heller ikke af din browser uanset system.
MinHjemmeside.dk
er versaluf�lsomt, men filnavnene er ikke.
Bertel Lund Hansen
> Det er en 25+ �r kendt problemstilling (sikkert l�ngere, men jeg har 'kun'
> kendt den i 25+ �r), men sikkert ikke for *nix n�rderne, og netop derfor
> tror jeg ikke *nix vil vinde indpas p� det omr�de.
Du overser ganske at Unix *har* vundet indpas og s�tter
standarden - for netfiler.
Jeg kan forst� p� dig at du ikke tiltror den almindelige bruger
evnen til at hitte ud af at bruge kodeord. Der skal man skelne
mellem store og sm� bogstaver, og resultatet er katastrofalt hvis
man ikke kan.
Rune Jensen
> Jeg kan forst� p� dig at du ikke tiltror den almindelige bruger
> evnen til at hitte ud af at bruge kodeord. Der skal man skelne
> mellem store og sm� bogstaver, og resultatet er katastrofalt hvis
> man ikke kan.
Hvem gemmer da kodeord som en del af et filnavn?
;)
Som jeg ser det, er det ikke, at det ene er bedre end det andet, selv om
jeg synes, det giver mening, hvad Stig skriver. Problemet er, de ikke er
_enige_ om hvordan det skal v�re. Det kan p�virke SEO ogs�, og det er skidt.
MVH
Rune Jensen
Bertel Lund Hansen
> s�dan har ASCII da v�ret altid? dvs: a != A
> Jeg ved ikke hvorfor DOS/Windows begyndte p� dette, m�ske et levn fra CP/M ?
Eller blot Bill Gates' m�de at lave det hele 'nemt' p�?
> For os Unix-folk er det en syg tanke at filnavne ikke er case-sensitive ;)
Ogs� for en del Windowsbrugere. Det er mig en stadig kilde til
irritation.
> Men egentlig er det filstystenet, for en FAT system i linux vil opf�rer
> sig p� samme m�de som i DOS/windows.
Forh�bentlig. Du ville vel heller ikke bryde dig om en Linux
filsystemimplementation til Windows som var ligeglad med store og
sm� bogstaver?
Programming is like sex: One mistake and you have to support
it for the rest of your life.
> Men egentlig er det lidt ligegyldig om filsystemet er case sensitive eller ej,
> bare man som server-bruger ved det n�r man l�gger filer op og laver URL til filerne.
> (men det kan s� give problemer hvis man flytter sine filer mellem
> forskellige filsystemer/OS)
Det er alt det man er fri for at spekulere over hvis man bruger
mit r�d.
Bertel Lund Hansen
> Vi ved derfor alle, at p� en Win/IIS er Frokost.Jpg og frokost.jpg den samme
> fil,
Kan du give mig adressen p� en netserver som ikke er versalf�lsom
hvad filnavne ang�r?
Erik Ginnerskov
> Bertel Lund Hansen skrev:
>
>> Jeg kan forst� p� dig at du ikke tiltror den almindelige bruger
>> evnen til at hitte ud af at bruge kodeord. Der skal man skelne
>> mellem store og sm� bogstaver, og resultatet er katastrofalt hvis
>> man ikke kan.
>
> Hvem gemmer da kodeord som en del af et filnavn?
> ;)
Forh�bentlig ingen. Men Stig h�vdede, at almindelige brugere ikke evner at
skelne mellem sm� og store bogstaver. Bertel minder bare om, at netop til
passwords er forskellen vigtig - p� mange systemer fordres direkte, at der
foruden tal og tegn b�de bruges sm� og store bogstaver.
Rune Jensen
> Rune Jensen wrote:
>> Hvem gemmer da kodeord som en del af et filnavn?
>> ;)
>
> Forh�bentlig ingen. Men Stig h�vdede, at almindelige brugere ikke evner
> at skelne mellem sm� og store bogstaver.
Jeg tror, han brugte ord som "man kan ikke forlange, de skal vide det".
Skal det v�re brugervenligt, kan man heller ikke - efter min mening. Men
s� taler vi nok om alm. PCer, ikke servere. Som man alligevel f�rst
opererer, hvis man har viden (forh�bentlig).
Jeg synes dog, der j�vnligt dukker sp�rgsm�l op om dette i grupperne, s�
helt sikre er folk alts� ikke.
> Bertel minder bare om, at netop
> til passwords er forskellen vigtig - p� mange systemer fordres direkte,
> at der foruden tal og tegn b�de bruges sm� og store bogstaver.
Jojo, men min pointe var s�, at det er to forskellige ting. Passwords
opfattes som "sikkerhed", det g�r filnavne ikke (n�dvendigvis).
Det er to forskellige situationer, man bruger det i.
I�vrigt er ikke alle tegn i et password n�dvendigvis tilladte i et
filnavn og omvendt. Der er SVJV ingen standard for passwords, kun
guidelines for "strenght" *)
MVH
Rune Jensen
*)
Der er faktisk nogle, som laver en lcase af passwordet, det er jo
dejligt nemt at h�ndtere serverside, men giver mindre styrke.
Visse kr�ver s� minimum �t stort bogstav og minimumsl�ngde, det g�r man
n�ppe i et filsystem.
Erik Ginnerskov
> Kan du give mig adressen p� en netserver som ikke er versalf�lsom
> hvad filnavne ang�r?
Ja, hos Azero p� en Win/IIS:
Det er helt ligegyldigt, hvilken du beder om:
http://ginnerskov.dk/files/wpg.zip
http://ginnerskov.dk/files/wpg.ZIP
Det er den samme fil, du f�r (kun f�rste link svarer til faktisk filnavn p�
serveren).
Frank Damgaard
> Frank Damgaard wrote:
>
>> længere det står i seneste RFC version af URI.
>
> Sidst jeg kiggede stod der bare at URIer skal encodes i UTF-8, men det vil
pas på ikke at blande URI docs sammen med html og lign.
jeg kan ikke finde noget med at det skal encodes i UTF-8.
den gamle http://www.ietf.org/rfc/rfc2396.txt
skriver:
..snip...
For original character sequences that contain non-ASCII characters,
however, the situation is more difficult. Internet protocols that
transmit octet sequences intended to represent character sequences
are expected to provide some way of identifying the charset used, if
there might be more than one [RFC2277]. However, there is currently
no provision within the generic URI syntax to accomplish this
identification. An individual URI scheme may require a single
charset, define a default charset, or provide a way to indicate the
charset used.
...snip...
i http://www.ietf.org/rfc/rfc3986.txt
står der lidt om andre tegn, og lidt vagt
at man kan bruge UTF-8 i nogle sammenhænge
med at det så SKAL %-encodes hvis det ikke er
i US-ASCII området.
..snip..
The reg-name syntax allows percent-encoded octets in order to
represent non-ASCII registered names in a uniform way that is
independent of the underlying name resolution technology. Non-ASCII
characters must first be encoded according to UTF-8 [STD63], and then
each octet of the corresponding UTF-8 sequence must be percent-
encoded to be represented as URI characters.
..snip..
Lidt underligt tales om "reg-name", som egentlig kun berører hostname-del.
For domæner nævnes at IDNA bør anvendes, ikke %-encoding.
For "path" del er der ikke explicit angivet noget med charsets.... ;(
men generelt står der i 2.2:
..snip..
URI producing applications should percent-encode data octets that
correspond to characters in the reserved set unless these characters
are specifically allowed by the URI scheme to represent data in that
component. If a reserved character is found in a URI component and
no delimiting role is known for that character, then it must be
interpreted as representing the data octet corresponding to that
character's encoding in US-ASCII.
....snip..
Den gamle http://www.ietf.org/rfc/rfc1738.txt skriver:
...
No corresponding graphic US-ASCII:
URLs are written only with the graphic printable characters of the
US-ASCII coded character set. The octets 80-FF hexadecimal are not
used in US-ASCII, and the octets 00-1F and 7F hexadecimal represent
control characters; these must be encoded.
...
Så vidt jeg kan se er nyere RFC ikke så explicit, men non-US-ASCII
skal stadigvæk %-encodes.
Og udover URI RFC's så kan bestemte schemes som http, https, ftp,...
sætte yderligere begrænsninger, f.eks.:
http://tools.ietf.org/html/rfc2616
denne henviser til rfc2396 og nævner så vidt
jeg kan se ikke noget om tegnsæt.
Men jeg faldt lige over noget andet, i
http://tools.ietf.org/html/rfc2616#section-3.2.3 :
..snip...
3.2.3 URI Comparison
When comparing two URIs to decide if they match or not, a client
SHOULD use a case-sensitive octet-by-octet comparison of the entire
URIs, with these exceptions:
- A port that is empty or not given is equivalent to the default
port for that URI-reference;
- Comparisons of host names MUST be case-insensitive;
- Comparisons of scheme names MUST be case-insensitive;
- An empty abs_path is equivalent to an abs_path of "/".
Characters other than those in the "reserved" and "unsafe" sets (see
RFC 2396 [42]) are equivalent to their ""%" HEX HEX" encoding.
For example, the following three URIs are equivalent:
http://abc.com:80/~smith/home.html
http://ABC.com/%7Esmith/home.html
http://ABC.com:/%7esmith/home.html
..snip..
så der står at man bør sammenligne "path"-del "case-sensitive" for at afgøre
om 2 URL er ens.
dvs. http://Abc.com/Kapitel.html og http://Abc.com/kaptiel.html er forskellig URL
men de kan jo evt. godt returnere samme fil...
til gengæld skal scheme og domæne-del være case-insensitive.
Så en robot der følger ovenståede bør håndtere fundne links med
forksellig store/små bogstaver som hver sin unique URL, og
ikke samme fil.
> Der går nok flere år før man kan være rimelig sikker på det virker
> crossbrowser og server.
>
>> Er det IBM codepage 865 ?, er det ISO-8859-15 ?, et det UTF-16, eller
>> UTF-8 eller EBDIC.... ?
>
> Det er da HP Roman8 :-)
Det er for netop at præcisere at du kan ikke vide hvilket
tegnsæt der anvendes når du tænker på danske tegn.
>
>> Jeg ved ikke hvorfor DOS/Windows begyndte på dette, måske et levn fra CP/M
>> ? eller fordi man havde et 64 nit tegnsæt med kun store bogstaver?
>> eller teletype?
>
> Det er ikke DOS/windows der 'begyndte' med det.
>
>> For os Unix-folk er det en syg tanke at filnavne ikke er case-sensitive ;)
>
> For os Mainframe/Cobol/Pascal folk er det en syg tanke at
> filsystem/programmeringssprog er case sensitive ;)
nogle mainframe havde kun 64 tegns tegnsæt, på univac1100 kunne
man vælge mellem et 6 bit tegnsæt eller et 9 bits tegnsæt...
og med 64 tegn var der kun store bogstaver, og ingen danske.
syntes heller ikke nogle af de gamle hulkortterminaler havde små bogstaver
men jeg mener at standarden for hulkort tillod små bogstaver.
For at andre tegn end US-ASCII skal virke, så skal det være angivet
i diverse standarder og anvendes på de fleste browsere og servere.
Pt. er det kun US-ASCII samt nogle få specialtegn der virker,
og vil man bruge non-US-ASCII, så skal de %-encodes.
Derudover kan serverens filsystem sætte nogle begrænsninger
med tegn der ikke er tilladt.
Så om det er . - eller _ eller blanktegn burde ikke have betydning.
FAT32, NTFS og diverse linux filsystemer har i hvert fald ikke
problemer med disse tegn.
Kun er kravet at blanktegn %-encodes til URI (%20 eller evt. "+").
(URI: unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" )
Rune Jensen
<SNIP: ASP-kode>
>> Congratulations - you've found an EASTER EGG!
> 1000 tak for svare alle
>
> ps. hvorfor skal det v�re s� sv�rt
Jeg ved ikke, om ovenst�ende gav svar p� dit sp�rgsm�l, for det kunne
ligne, du bruger noget Frontpage?
Men det som g�r, at de filer efterh�nden ryger af Google, det er den 404
- Not found, som sendes med. N�r filen ikke kan findes i l�ngere tid, s�
gider Google ikke indeksere den (der er jo ikke links til de includes
fra andre sider - den r�g p� via forkert konfigurering af sitemap fra
min side i sin tid, og er fjernet nu fra sitemappet).
Man kan nok sende andet, jeg ved ikke om der er en "Permanently Closed"
kode, som det vil g� hurigere med, men jeg synes id�en om et easter egg
var sk�g.
> Godt Nyt�r til all
ILM
MVH
Rune Jensen
Stig Johansen
> Det er for netop at pr�cisere at du kan ikke vide hvilket
> tegns�t der anvendes n�r du t�nker p� danske tegn.
Ja, og min ponte var at _du_ ikker er lig med _mig_
> og med 64 tegn var der kun store bogstaver, og ingen danske.
Ganske korrekt.
> syntes heller ikke nogle af de gamle hulkortterminaler havde sm� bogstaver
> men jeg mener at standarden for hulkort tillod sm� bogstaver.
Nu har du ligesom presset mig til at tage et 'walk down memory lane', og
lede i mine gemmer, men jeg fandt nogle gamle hulkort frem (dog ICL).
S�dan s� de ud 'dengang':
<http://w-o-p-r.dk//images/hulkort.jpg>
Stig Johansen
> Kan du give mig adressen p� en netserver som ikke er versalf�lsom
> hvad filnavne ang�r?
_Alt_ andet end *nix servere.
Stig Johansen
> Men Stig h�vdede, at almindelige brugere ikke evner at
> skelne mellem sm� og store bogstaver.
Lad v�re med at l�gge ord i min mund.
Jeg mener ikke at brugere ikke 'evner' at skelne, men at brugere ikke skal
'tage stilling til skelnen'.
Der er himmelvid til forskel p� disse to ting.
> Bertel minder bare om, at netop til
> passwords er forskellen vigtig - p� mange systemer fordres direkte, at der
> foruden tal og tegn b�de bruges sm� og store bogstaver.
Hvor kommer passwords ind i billedet?
Naturligvis skal passwords v�re case sensitive, for ellers giver det jo
ingen mening.
Filnavne har ikke noget at g�re med passwords.
Bertel Lund Hansen
> > Bertel minder bare om, at netop til
> > passwords er forskellen vigtig - p� mange systemer fordres direkte, at der
> > foruden tal og tegn b�de bruges sm� og store bogstaver.
> Hvor kommer passwords ind i billedet?
Du skrev f�r:
> for man kan ikke forvente at almindelige d�delige brugere skal
> forholde sig til store og sm� bogstaver.
Man kan ikke benytte en pc i dag uden at kunne h�ndtere kodeord.
Det beviser at alle pc-brugere sagtens kan skelne mellem store og
sm� bogstaver, og langt hovedparten g�r det da ogs� rigtigt n�r
de skriver indl�g p� nettet.
Det ville v�re langt det nemmeste hvis man altid kunne v�re
sikker p� at standarden var den samme overalt. Derfor ville det
v�re bedre hvis alle systemer var versalf�lsomme.
> Filnavne har ikke noget at g�re med passwords.
Skriveteknikken er den samme.
oz7aik
"oz7aik" <ozx...@xxxxx.dk> skrev i meddelelsen
news:4b3a332f$0$36579$edfa...@dtext01.news.tele.dk...
> "Stig Johansen" <wop...@gmaill.com> skrev i meddelelsen
> news:4b3a157d$0$275$1472...@news.sunsite.dk...
>> Jens Peter Karlsen wrote:
>>
>>> I DOS eller Windows vil det virke med .. I dit eksempel vil man lede
>>> efter filendelsen og det vil jo v�re htm eller lignende s� din s�gning
>>> skal laves om til *.klubber.* og s� holder dit argument om at det
>>> skulle v�re lettere ikke, da det jo er lige s� let at skrive
>>> *-klubber.* eller *_klubber.*
>>
>> Ja ja, lad os ikke t�rske langhalm p� det - jeg skrev ikke det var
>> _lettere_, men (citat):
>>> Jeg er begynd at synes bedre om f.eks "om.klubber" frem for
>>> "om_klubber",
>>> men det er nok en smagssag.
>>
>> Dvs. _jeg_ synes bedre om ., men som sagt er det en _smagssag_.
>>
>> Jeg synes ikke jeg har pr�vet at promovere en endegyldig sandhed.
>>
>> --
>> Med venlig hilsen
>> Stig Johansen
>
>
> P� min udbyders server har jeg en mappe _private,
> Kan man have flere mapper med _ foran s� man kan snyde s�ge robotterne
> Jeg vil have nogle mapper hvor jeg vil have nogle file som kun skal bruges
> til inds�tning p� mine sider, som andre bruger ellers ikke kan bruge til
>
> eller er der en anden mulighed.?
>
> JbP
>
> http://www.oz7aik.dk/faglig/
>
hej igen
kan man s�tte mapperne i Chmod
Erik Olsen
> Man kan ikke benytte en pc i dag uden at kunne h�ndtere kodeord.
> Det beviser at alle pc-brugere sagtens kan skelne mellem store og
> sm� bogstaver, og langt hovedparten g�r det da ogs� rigtigt n�r
> de skriver indl�g p� nettet.
Stort set alle mine passwords er med sm� bogstaver og tal. Jeg kan ikke
se at det skulle v�re nogen hindring.
Nogle brugere p� usenet har tydeligvis problemer med at bruge store
bogstaver, men det forhindrer dem ikke i at kommunikere.
--
Venlig hilsen/Best regards
Erik Olsen
http://www.modelbaneteknik.dk/
Stig Johansen
> Stig Johansen skrev:
>> Hvor kommer passwords ind i billedet?
>
> Du skrev f�r:
>
>> for man kan ikke forvente at almindelige d�delige brugere skal
>> forholde sig til store og sm� bogstaver.
>
Ja ja, bare tag det ud af kontext.
> Man kan ikke benytte en pc i dag uden at kunne h�ndtere kodeord.
> Det beviser at alle pc-brugere sagtens kan skelne mellem store og
> sm� bogstaver, og langt hovedparten g�r det da ogs� rigtigt n�r
> de skriver indl�g p� nettet.
Jeg har jo ikke postuleret, at brugere ikke _kan_ kende forskel p� sm� og
store bogstaver.
Jeg snakker om filnavne og filoversigter i f.eks. explorer.
Her er der ingen forskel p� dennefil.noget og Dennefil.noget eller
Dennefil.Noget - osv.
Mener du selv at administrative brugere sidder omhyggeligt og s�rger for at
alle fil(dokumentnavne) er skrevet med f.eks sm�t?
Eller har du bev�get dig rundt i virksomheder med flere hundrede ansatte og
set det med selvsyn?
Philip Nunnegaard
>> for man kan ikke forvente at almindelige d�delige brugere skal
>> forholde sig til store og sm� bogstaver.
>
> Man kan ikke benytte en pc i dag uden at kunne h�ndtere kodeord.
> Det beviser at alle pc-brugere sagtens kan skelne mellem store og
> sm� bogstaver, og langt hovedparten g�r det da ogs� rigtigt n�r
> de skriver indl�g p� nettet.
Eller ogs� skyldes det bare at de skriver alle kodeord med sm� bogstaver.
Det er der sikkert mange der g�r, med mindre systemet tvinger brugerne
til andet.
<ot>
Her har jeg dog set systemer der har s� strenge kodeordskrav at folk
skriver kodeordet ned i en bog eller p� en gul lap som de klistrer p� et
sted i n�rheden af tastaturet (f.eks. p� sk�rmens nederste kant).
P� den m�de kan overdrevet sikkerhed efter min mening v�re en trussel
mod sikkerheden.
Bare tag Vistas UAC som var s� aggressiv at vi var flere der slog den
fra. Det er Peter og ulven om igen.
Sammenlign da med Windows 7's UAC som er mere diskret og kun brokker sig
n�r der sker noget der virkelig er en trussel.
Stig Johansen
> <ot>
> Her har jeg dog set systemer der har s� strenge kodeordskrav at folk
> skriver kodeordet ned i en bog eller p� en gul lap som de klistrer p� et
> sted i n�rheden af tastaturet (f.eks. p� sk�rmens nederste kant).
Ja, pr�v at g� rundt i et kontorlandskab hvor man kr�ver skift af kodeord
hver m�ned, samt ingen genbrug af de sidste 5-10 kodeord.
> P� den m�de kan overdrevet sikkerhed efter min mening v�re en trussel
> mod sikkerheden.
Det er det ogs�, men det kr�ver dog fysisk adgang til omr�det, s� det er
nogenlunde begr�nset til ansatte og reng�ring/nattevagter.
Bertel Lund Hansen
> Eller ogs� skyldes det bare at de skriver alle kodeord med sm� bogstaver.
> Det er der sikkert mange der g�r, med mindre systemet tvinger brugerne
> til andet.
Se bare - de f�lger helt naturligt mit r�d ...
> <ot>
> Her har jeg dog set systemer der har s� strenge kodeordskrav at folk
> skriver kodeordet ned i en bog eller p� en gul lap som de klistrer p� et
> sted i n�rheden af tastaturet (f.eks. p� sk�rmens nederste kant).
> P� den m�de kan overdrevet sikkerhed efter min mening v�re en trussel
> mod sikkerheden.
Helt klart.
> Bare tag Vistas UAC som var s� aggressiv at vi var flere der slog den
> fra.
Ideen er taget fra *nix-verdenen hvor brugerne er vant til pr�cis
den opf�rsel. Men vi Windowsbrugere kan ikke v�nne os til det af
to grunde: Vi er vant til at vi ikke beh�ver angive et kodeord
for at f� skidtet til at g� ned, og vi installerer alt for mange
programmer der roder p� systemniveau s� det i praksis er umuligt
at arbejde med den sikring sl�et til.
> Sammenlign da med Windows 7's UAC som er mere diskret og kun brokker sig
> n�r der sker noget der virkelig er en trussel.
Okay. Jeg er i �jeblikket af den holdning at jeg ikke l�ngere
gider skifte system, men jeg kan selvf�lgelig blive tvunget hvis
min pc bryder ned og en ny har for meget hardware som XP ikke
kender. .
Erik Ginnerskov
> Ja, pr�v at g� rundt i et kontorlandskab hvor man kr�ver skift af
> kodeord hver m�ned, samt ingen genbrug af de sidste 5-10 kodeord.
Og forskellige kodeord til forskellige systemer. Sikkerhed er OK og kravet
om sikkerhed forst�eligt. Men at skulle huske 4-5 forskellige kodeord en
m�ned hvorefter hele puljen skal skrottes og erstattes af nyt, der _skal_
best� af mendst et lille bogstav, mindst et stort bogstav, mindst et tal og
mindst et af tegnene -_!/\ og mindst 8 tegn, det er hjernegymnastik for
viderekomne - og et kodeord nedskrevet p� et stykke tilg�ngeligt papir var
fyregrund.