Hej!

Har en filnedladdningsrutin som skriver filen direkt till http-strömmen, ungefär såhär:

Response.ContentType = "application/octet-stream";
Response.AddHeader("Content-Disposition", "attachment; filename=" + '"' + strFileName + '"');
Response.WriteFile(strOpenFile);

Dessvärre visas filnamn med svenska tecken fel i Spara som-dialogen. Om jag ersätter dem med URL-encodade motsvarigheter funkar det. Tyvärr kan jag inte använda Server.UrlEncode(strFileName) eftersom andra tecken flippar då. T.ex. encodas ju mellanslag till plustecken, och de visar tyvärr sedan Spara som-dialogen som just plustecken. Kvarstår alltså att med RegExp ersätta svenska tecken, men det känns ju som att det bara borde vara att sätta charset eller code page på lämpligt ställe. Men var...?

Har provat att sätta charset till UTF-8 med Repsonse.Charset och Response.AddHeader, genom att lägga till charsetet som en custom http header i iis och i web.config står responseEncoding på utf-8 också.

Idéer, tips?

mvh
/Jonas

response.encoding/responseencoding ellernågot sådant borde det vara

Response.ContentEncoding kanske? Men den är read only...
Finns Response.Charset, men den hade jag som sagt provat. Samt att explicit lägga till encodingen som header mha Response.AddHeader (två tekniker som funkar utmärkt om contentet är html/text, men inte här tyvärr).

mvh
/Jonas

Jonas,

Det tog lite trixande ska du veta, men jag kom fram till en lösning som funkar som det skall. Jag blev överraskad när fileEncoding inställning för globalization i web.config inte hade någon inverkan.

string fname =
	Server.MapPath("Hallå.mp3");
FileInfo f = new FileInfo(fname);			
string fname = HttpUtility.UrlEncode(f.Name).Replace("+", " ");

Response.AddHeader("Content-Disposition", "attachment; filename=" + fname);
Response.AddHeader("Content-Length", f.Length.ToString());
Response.AddHeader("Content-Transfer-Encoding","binary");
Response.ContentType = "application/octet-stream";
Response.WriteFile(f.FullName);

Hej Andreas och tack för att du tar dig tid!

Nu verkar jag förstås otacksam och det är inte min mening, men för att citera min egen post ovan:

"Tyvärr kan jag inte använda Server.UrlEncode(strFileName) eftersom andra tecken flippar då. T.ex. encodas ju mellanslag till plustecken"

(Resultatet av Server.UrlEncode är såvitt jag kan bedöma ekvivalent med HttpUtility.UrlEncode.)

Visst kan jag replaca plustecknen, men då replacar jag ju också plustecken som kanske faktiskt ingår i filnamnet.

Man kan förstås tycka att folk borde veta bättre än att hålla på med svenska tecken och plustecken i filnamn, men den här applikationen ska användas av s.k. "användare" och sådana kan som bekant bete sig fullständigt irrationellt! ;-)

Måste jag fixa det här med en workaround så föredrar jag nog att "hand-url-encoda" svenska tecken mha regexp och skippa UrlEncode. Men jag försöker vänja mig av med workarounds, det blir lite si och så med kodens förutsägbarhet och framtidssäkerhet.

Det skulle vara intressant att veta om det här beteendet är "by design" eller beror på en bug.

mvh
/Jonas

Nu är det här inget svar på ditt problem, utan ett tips till andra som kanske funderar på att bygga en liknande applikation.

Tillåt inga "konstiga" tecken i filuppladdningsfunktionaliteten, t.ex. svenska tecken, mellanslag och annat. Gör en replace eller lägg in en koll och ge användarna en varning och säg att de måste ändra. Alternativt ge filen ett helt nytt namn baserat på idnummer eller annat.

Ursäkta inlägget. :)

/pD
www.pdc.se
www.pdc.se/blog
www.patrik-dahlen.nu

Inlägget ursäktat! :-)

Håller dock inte med om att man ska stoppa användare från att köra med tecken som är tillåtna i filnamn i deras OS. Jag håller rätt hårt på den gamla klyschan om att vi ska anpassa våra applikationer efter användarna, inte tvärtom.

Din lösning nr 2 håller jag däremot med om. Jag försöker av olika anledningar minimera databasuppslagen i min app, men annars skulle jag nog döpt om filen ungefär som du föreslog. Jag skulle nog gjort ungefär såhär:
1) Genererat ett GUID.
2) Lagrat filens originalnamn samt GUID:et från punkt 1 i en db-tabell.
3) Döpt om filen till GUID.filsuffix.
Vid fillistningar samt filnedladdning skulle jag sedan s.a.s backat processen så att filen återfick sitt originalnamn.

Det finns bara ett fel med den lösningen - mitt originalproblem skulle kvarstå... :-)

Däremot så löser nåt i stil med ovanstående en massa andra potentiella problem och är nog en ganska vanlig lösning.

mvh
/Jonas

En snabbis till. ;)

"Håller dock inte med om att man ska stoppa användare från att köra med tecken som är tillåtna i filnamn i deras OS. Jag håller rätt hårt på den gamla klyschan om att vi ska anpassa våra applikationer efter användarna, inte tvärtom."

Det här är just anledningen till att jag inte vil godkänna dessa tecken. De kanske är tillåtna i deras OS, men det finns ju andra OS där de kanske inte är tillåtna. Så när de användare som har ett annat OS vill ha filen så har den ett otillåtet namn i deras OS.
Man ska definitivt anpassa applikationerna till användarna, men då helst till så många användare som möjligt.
Så när det gäller filnamn håller jag rätt hårt på "Endast standardtecken tillåts i filnamnet". :)

/pD
www.pdc.se
www.pdc.se/blog
www.patrik-dahlen.nu

Nu ska vi väl inte gräva ner oss i just detta, men i vilka moderna (persondator-)OS är svenska tecken otillåtna i filnamn?
Jag är ärligt intresserad. I just den här appen är det en icke-fråga, den ska köras i en homogen W2K-miljö, men det händer ju att jag gör grejer för externt bruk också.

mvh
/Jonas

När det gäller svenska tecken så tänkte jag nog mest på internationella applikationer. De är tillåtna men som jag skrev, jag vill anpassa applikationen till så många användare som möjligt.
Jag jobbar mest med webbapplikationer och då känns det även dumt att chansa vad gäller andra tecken som kanske inte funkar så bra i en webbläsare. Så för min del handlar det inte bara om OS utan jag måste även tänka på webbläsare och andra länder. Då känns det bäst att hårddra det hela redan från grunden.

/pD
www.pdc.se
www.pdc.se/blog
www.patrik-dahlen.nu

Jonas,

Har du vägt sannolikheten för att ett filnamn innehåller t.ex + och andra "ovanliga" tecken (då inte inräknat åäö) mot hur lång tid det tar dig att hitta en lösning? Det är absolut inte det optimala men om det inte handlar om ett givet namngivningssystem för filer så är det juh otroligt ovanligt att t.ex ett + förekommer i ett filnamn.

Det sagt så skulle jag själv vilja se att tråden får ett "funkerande svar" då jag blev troligen lika förvånad som dig där man inte kunde använda sig av varesig Globalization/fileEncoding, Charset eller ContentsEncoding ... noll inverkan på filnamnet =/

//Andreas

Hej Andreas!

Jo, tidsaspekten har slagit mig - och jag måste nog ta och jobba lite nu! :-)
Dessvärre är +-tecknen en realitet i flera dokument jag vet kommer att läggas upp. Jag har en chef som gillar att använda det istället för " och " i filnamn... Chefer är som vi alla vet den besvärligaste formen av användare! ;-)

Men att s.a.s. hand-url-encoda svenska tecken mha av t.ex. regexp (eller replace för den delen) och lämna mellanslagen därhän är ju inte så knepigt, så det får det bli om det ska bli en "fuling".

mvh
/Jonas

Hej Patrik!

Jag håller på sätt och vis med dig och har skrivit en och annan filnamnstvättarrutin själv, men inte i det här fallet. För några problem i webbläsare kan jag inte föreställa mig, Microsoft har ju varit vänliga nog att ge mänskligheten Server.HtmlEncode och Server.URLEncode - och motsvarande Decode.

Och jag kan hursomhelt inte hindra mina användare att från skriva på svenska *inuti* dokumenten ifråga, så de blir inte så internationellt gångbara oavsett filnamnen... ;-)

Det jag håller på med är en webb-baserad intranät-app för åtkomst av arbetsdokument, huvudsakligen Office-dokument, det borde jag kanske sagt från första början.

Så vore det inte för den här jäkla Spara som-dialogen så... :-/

mvh
/Jonas

Jonas,

Hehe det är vääääldigt många som vill kunna trolla bort "Spara" dialogen och jag kan hålla med om att det kan verka frestande i ett Intranet scenario men även där skulle det kunna ha en inverkan på säkerheten. Då skulle det vara möjligt att ställa om den med en domain-policy eller något =)

//Andreas

Ja, nu pratar jag inte om att trolla bort den, bara att få den att visa åäö korrekt!
mvh
/Jonas

Det är ofta bättre och effektivare att söka svar i källan än att testa sig fram.

RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1 (http://www.faqs.org/rfcs/rfc2616.html):
<info>
15.5 Content-Disposition Issues

RFC 1806 [35], from which the often implemented Content-Disposition (see section 19.5.1) header in HTTP
is derived, has a number of very serious security considerations. Content-Disposition is not part of the HTTP
standard, but since it is widely implemented, we are documenting its use and risks for implementors. See RFC 2183
[49] (which updates RFC 1806) for details.
</info>

RFC 2183 - Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field (http://www.faqs.org/rfcs/rfc2183.html):
<info>
2. The Content-Disposition Header Field

Content-Disposition is an optional header field. In its absence, the
MUA may use whatever presentation method it deems suitable.

It is desirable to keep the set of possible disposition types small
and well defined, to avoid needless complexity. Even so, evolving
usage will likely require the definition of additional disposition
types or parameters, so the set of disposition values is extensible;
see below.

In the extended BNF notation of [RFC 822], the Content-Disposition
header field is defined as follows:

disposition := "Content-Disposition" ":"
disposition-type
*(";" disposition-parm)

disposition-type := "inline"
/ "attachment"
/ extension-token
; values are not case-sensitive

disposition-parm := filename-parm
/ creation-date-parm
/ modification-date-parm
/ read-date-parm
/ size-parm
/ parameter

filename-parm := "filename" "=" value

creation-date-parm := "creation-date" "=" quoted-date-time

modification-date-parm := "modification-date" "=" quoted-date-time

read-date-parm := "read-date" "=" quoted-date-time

size-parm := "size" "=" 1*DIGIT

quoted-date-time := quoted-string
; contents MUST be an RFC 822 `date-time'
; numeric timezones (+HHMM or -HHMM) MUST be used

NOTE ON PARAMETER VALUE LENGHTS: A short (length <= 78 characters)
parameter value containing only non-`tspecials' characters SHOULD be
represented as a single `token'. A short parameter value containing
only ASCII characters, but including `tspecials' characters, SHOULD
be represented as `quoted-string'. Parameter values longer than 78
characters, or which contain non-ASCII characters, MUST be encoded as
specified in [RFC 2184].

`Extension-token', `parameter', `tspecials' and `value' are defined
according to [RFC 2045] (which references [RFC 822] in the definition
of some of these tokens). `quoted-string' and `DIGIT' are defined in
[RFC 822].
</info>

RFC 2184 - MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations (http://www.faqs.org/rfcs/rfc2616.html):
<info>
3.2. HEADER FIELD DEFINITIONS

These rules show a field meta-syntax, without regard for the
particular type or internal syntax. Their purpose is to permit
detection of fields; also, they present to higher-level parsers
an image of each field as fitting on one line.

field = field-name ":" [ field-body ] CRLF

field-name = 1*<any CHAR, excluding CTLs, SPACE, and ":">

field-body = field-body-contents
[CRLF LWSP-char field-body]

field-body-contents =
<the ASCII characters making up the field-body, as
defined in the following sections, and consisting
of combinations of atom, quoted-string, and
specials tokens, or else consisting of texts>

August 13, 1982 - 9 - RFC #822

Standard for ARPA Internet Text Messages

3.3. LEXICAL TOKENS

The following rules are used to define an underlying lexical
analyzer, which feeds tokens to higher level parsers. See the
ANSI references, in the Bibliography.

; ( Octal, Decimal.)
CHAR = <any ASCII character> ; ( 0-177, 0.-127.)
ALPHA = <any ASCII alphabetic character>
; (101-132, 65.- 90.)
; (141-172, 97.-122.)
DIGIT = <any ASCII decimal digit> ; ( 60- 71, 48.- 57.)
CTL = <any ASCII control ; ( 0- 37, 0.- 31.)
character and DEL> ; ( 177, 127.)
CR = <ASCII CR, carriage return> ; ( 15, 13.)
LF = <ASCII LF, linefeed> ; ( 12, 10.)
SPACE = <ASCII SP, space> ; ( 40, 32.)
HTAB = <ASCII HT, horizontal-tab> ; ( 11, 9.)
<"> = <ASCII quote mark> ; ( 42, 34.)
CRLF = CR LF

LWSP-char = SPACE / HTAB ; semantics = SPACE

linear-white-space = 1*([CRLF] LWSP-char) ; semantics = SPACE
; CRLF => folding

specials = "(" / ")" / "<" / ">" / "@" ; Must be in quoted-
/ "," / ";" / ":" / "\" / <"> ; string, to use
/ "." / "[" / "]" ; within a word.

delimiters = specials / linear-white-space / comment

text = <any CHAR, including bare ; => atoms, specials,
CR & bare LF, but NOT ; comments and
including CRLF> ; quoted-strings are
; NOT recognized.

atom = 1*<any CHAR except specials, SPACE and CTLs>

quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or
; quoted chars.

qtext = <any CHAR excepting <">, ; => may be folded
"\" & CR, and including
linear-white-space>

domain-literal = "[" *(dtext / quoted-pair) "]"

August 13, 1982 - 10 - RFC #822

Standard for ARPA Internet Text Messages

dtext = <any CHAR excluding "[", ; => may be folded
"]", "\" & CR, & including
linear-white-space>

comment = "(" *(ctext / quoted-pair / comment) ")"

ctext = <any CHAR excluding "(", ; => may be folded
")", "\" & CR, & including
linear-white-space>

quoted-pair = "\" CHAR ; may quote any char

phrase = 1*word ; Sequence of words

word = atom / quoted-string
</info>

RFC 2047 - MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text (http://www.faqs.org/rfcs/rfc2047.html):
<info>
2. Syntax of encoded-words

An 'encoded-word' is defined by the following ABNF grammar. The
notation of RFC 822 is used, with the exception that white space
characters MUST NOT appear between components of an 'encoded-word'.

encoded-word = "=?" charset "?" encoding "?" encoded-text "?="

charset = token ; see section 3

encoding = token ; see section 4

token = 1*<Any CHAR except SPACE, CTLs, and especials>

especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "
<"> / "/" / "[" / "]" / "?" / "." / "="

encoded-text = 1*<Any printable ASCII character other than "?"
or SPACE>
; (but see "Use of encoded-words in message
; headers", section 5)

Both 'encoding' and 'charset' names are case-independent. Thus the
charset name "ISO-8859-1" is equivalent to "iso-8859-1", and the
encoding named "Q" may be spelled either "Q" or "q".

An 'encoded-word' may not be more than 75 characters long, including
'charset', 'encoding', 'encoded-text', and delimiters. If it is
desirable to encode more text than will fit in an 'encoded-word' of
75 characters, multiple 'encoded-word's (separated by CRLF SPACE) may
be used.

While there is no limit to the length of a multiple-line header
field, each line of a header field that contains one or more
'encoded-word's is limited to 76 characters.

The length restrictions are included both to ease interoperability
through internetwork mail gateways, and to impose a limit on the
amount of lookahead a header parser must employ (while looking for a
final ?= delimiter) before it can decide whether a token is an
"encoded-word" or something else.

IMPORTANT: 'encoded-word's are designed to be recognized as 'atom's
by an RFC 822 parser. As a consequence, unencoded white space
characters (such as SPACE and HTAB) are FORBIDDEN within an
'encoded-word'. For example, the character sequence

=?iso-8859-1?q?this is some text?=

would be parsed as four 'atom's, rather than as a single 'atom' (by
an RFC 822 parser) or 'encoded-word' (by a parser which understands
'encoded-words'). The correct way to encode the string "this is some
text" is to encode the SPACE characters as well, e.g.

=?iso-8859-1?q?this=20is=20some=20text?=

The characters which may appear in 'encoded-text' are further
restricted by the rules in section 5.
</info>

Den sista referensen var där jag fann informationen du behöver. Vilket talar om hur du skall koda dina text.

/Mvh, Andreas Hillqvist - An expert in information mining

Man tackar!
Ja, det ante mig att det fanns ett "riktigt" svar nånstans därute. :-)
Tack Andreas, nu slipper jag göra en "fuling" och kan med gott samvete markera tråden löst!

mvh
/Jonas

Jag har sett problemen ett antal gånger och det är riktigt mycket strul speciellt i grafiska branschen där Mac OSX används i rätt stor utsträckning... Så problemet finns verkligen. Dock inte i en homogen PC miljö kanske men när kunderna inte kör PC blir det aktuellt att hitta en lösning.

/Per

hmmm inte riktigt med på hur man ska implentera beskrivningarna ovan

Får man fråga hur den färdiga koden blev?

Ingen aning! :-)
Det ligger på min att göra-lista, men rätt långt ner (vart tar all projekttid vägen?).

mvh
/Jonas

Ok,

Jag testa lite men fick det inte att lira. Du kan väl skicka in koden om du fixar det så gör jag det samma. Dock inte prio 1 för mig heller för tillfället ;-)

Will do.
mvh
/Jonas

Bump. Väldigt gammal tråd, men jag har stött och blött det här problemet ett tag nu.

Med encode och ersättning funkar det finfint att visa svenska tecken i själva nedladdningsrutan. Dock uppstår problem när man väljer att öppna filen direkt, det vill säga mha "Öppna"-knappen.

Säg att jag laddar ner Åäö.doc, och öppnar den, så visas filnamnet i Word som "en hel radda teckenkoder".doc.

Jag använder ISO-8859-1, svensk "lokalisering" i globalt för webbapplikationen.

Hur går detta att komma förbi?

Koden ser ut som vanligt vid nedladdning, men jag visar ändå ;)

int intStartFilnamn = strDocUrl.LastIndexOf("/") + 1;
string strFilnamn = strDocUrl.Substring(intStartFilnamn);

strFilnamn = HttpUtility.UrlEncode(strFilnamn).Replace("+", " ");
string strFiltyp = strDocUrl.Substring(strDocUrl.Length - 4);

Response.Clear();

switch (strFiltyp)
{
case ".doc":
Response.ContentType = "application/msword";
break;
default:
Response.ContentType = "application/octet-stream";
break;
}

Response.AppendHeader("content-disposition", "attachment; filename=" + strFilnamn + "\"");
Response.WriteFile(strDocUrl);

Hjälp med detta skulle vara mycket uppskattat, då 95 % av användarna utnyttjar Öppna-knappen. Utöver det får itne filerna döpas om då dokumenthanteringen i applikationen då blir redundant.

Tackar på förhand!

Man skall MIME-encode:a det, se:
http://www.codeproject.com/aspnet/NonUSASCII.asp