HTML 4.01 Entities Reference

ISO 8859-1 Symbol Entities

Result	Description	Entity Name	Entity Number
	non-breaking space	 	 
¡	inverted exclamation mark	¡	¡
¤	currency	¤	¤
¢	cent	¢	¢
£	pound	£	£
¥	yen	¥	¥
¦	broken vertical bar	¦	¦
§	section	§	§
¨	spacing diaeresis	¨	¨
©	copyright	©	©
ª	feminine ordinal indicator	ª	ª
«	angle quotation mark (left)	«	«
¬	negation	¬	¬
­	soft hyphen	­	­
®	registered trademark	®	®
™	trademark	™	™
¯	spacing macron	¯	¯
°	degree	°	°
±	plus-or-minus	±	±
²	superscript 2	²	²
³	superscript 3	³	³
´	spacing acute	´	´
µ	micro	µ	µ
¶	paragraph	¶	¶
·	middle dot	·	·
¸	spacing cedilla	¸	¸
¹	superscript 1	¹	¹
º	masculine ordinal indicator	º	º
»	angle quotation mark (right)	»	»
¼	fraction 1/4	¼	¼
½	fraction 1/2	½	½
¾	fraction 3/4	¾	¾
¿	inverted question mark	¿	¿
×	multiplication	×	×
÷	division	÷	÷
À	capital a, grave accent	À	À
Á	capital a, acute accent	Á	Á
Â	capital a, circumflex accent	Â	Â
Ã	capital a, tilde	Ã	Ã
Ä	capital a, umlaut mark	Ä	Ä
Å	capital a, ring	Å	Å
Æ	capital ae	Æ	Æ
Ç	capital c, cedilla	Ç	Ç
È	capital e, grave accent	È	È
É	capital e, acute accent	É	É
Ê	capital e, circumflex accent	Ê	Ê
Ë	capital e, umlaut mark	Ë	Ë
Ì	capital i, grave accent	Ì	Ì
Í	capital i, acute accent	Í	Í
Î	capital i, circumflex accent	Î	Î
Ï	capital i, umlaut mark	Ï	Ï
Ð	capital eth, Icelandic	Ð	Ð
Ñ	capital n, tilde	Ñ	Ñ
Ò	capital o, grave accent	Ò	Ò
Ó	capital o, acute accent	Ó	Ó
Ô	capital o, circumflex accent	Ô	Ô
Õ	capital o, tilde	Õ	Õ
Ö	capital o, umlaut mark	Ö	Ö
Ø	capital o, slash	Ø	Ø
Ù	capital u, grave accent	Ù	Ù
Ú	capital u, acute accent	Ú	Ú
Û	capital u, circumflex accent	Û	Û
Ü	capital u, umlaut mark	Ü	Ü
Ý	capital y, acute accent	Ý	Ý
Þ	capital THORN, Icelandic	Þ	Þ
ß	small sharp s, German	ß	ß
à	small a, grave accent	à	à
á	small a, acute accent	á	á
â	small a, circumflex accent	â	â
ã	small a, tilde	ã	ã
ä	small a, umlaut mark	ä	ä
å	small a, ring	å	å
æ	small ae	æ	æ
ç	small c, cedilla	ç	ç
è	small e, grave accent	è	è
é	small e, acute accent	é	é
ê	small e, circumflex accent	ê	ê
ë	small e, umlaut mark	ë	ë
ì	small i, grave accent	ì	ì
í	small i, acute accent	í	í
î	small i, circumflex accent	î	î
ï	small i, umlaut mark	ï	ï
ð	small eth, Icelandic	ð	ð
ñ	small n, tilde	ñ	ñ
ò	small o, grave accent	ò	ò
ó	small o, acute accent	ó	ó
ô	small o, circumflex accent	ô	ô
õ	small o, tilde	õ	õ
ö	small o, umlaut mark	ö	ö
ø	small o, slash	ø	ø
ù	small u, grave accent	ù	ù
ú	small u, acute accent	ú	ú
û	small u, circumflex accent	û	û
ü	small u, umlaut mark	ü	ü
ý	small y, acute accent	ý	ý
þ	small thorn, Icelandic	þ	þ
ÿ	small y, umlaut mark	ÿ	ÿ
Œ	capital ligature OE	Œ	Œ
œ	small ligature oe	œ	œ
Š	capital S with caron	Š	Š
š	small S with caron	š	š
Ÿ	capital Y with diaeres	Ÿ	Ÿ
ˆ	modifier letter circumflex accent	ˆ	ˆ
˜	small tilde	˜	˜
	en space	 	 
	em space	 	 
	thin space	 	 
‌	zero width non-joiner	‌	‌
‍	zero width joiner	‍	‍
‎	left-to-right mark	‎	‎
‏	right-to-left mark	‏	‏
–	en dash	–	–
—	em dash	—	—
‘	left single quotation mark	‘	‘
’	right single quotation mark	’	’
‚	single low-9 quotation mark	‚	‚
“	left double quotation mark	“	“
”	right double quotation mark	”	”
„	double low-9 quotation mark	„	„
†	dagger	†	†
‡	double dagger	‡	‡
	horizontal ellipsis	…	…
‰	per mille	‰	‰
‹	single left-pointing angle quotation	‹	‹
›	single right-pointing angle quotation	›	›
€	euro	€	€

Category: References

Table UTF-8 Unicode Character Set - for HTML UTF-8 enabled pages.

Reference Table UTF-8 Unicode Character Set - (for HTML UTF-8 enabled pages)

You MUST use  the META tag : <meta http-equiv=Content-Type content="text/html; charset=UTF-8"> in Your HTML header







3

3

L

L

e

e

~

~

—

—

°

°

É

É

â

â

û

û

Ĕ

Ĕ

ĭ

ĭ

ņ

ņ

ş

ş

Ÿ

Ÿ









4

4

M

M

f

f





˜

˜

±

±

Ê

Ê

ã

ã

ü

ü

ĕ

ĕ

Į

Į

Ň

Ň

Š

Š

Ź

Ź







5

5

N

N

g

g

€

€

™

™

²

²

Ë

Ë

ä

ä

ý

ý

Ė

Ė

į

į

ň

ň

š

š

ź

ź







6

6

O

O

h

h



�

š

š

³

³

Ì

Ì

å

å

þ

þ

ė

ė

İ

İ

ʼn

ʼn

Ţ

Ţ

Ż

Ż







7

7

P

P

i

i

‚

‚

›

›

´

´

Í

Í

æ

æ

ÿ

ÿ

Ę

Ę

ı

ı

Ŋ

Ŋ

ţ

ţ

ż

ż







8

8

Q

Q

j

j

ƒ

ƒ

œ

œ

µ

µ

Î

Î

ç

ç

Ā

Ā

ę

ę

IJ

IJ

ŋ

ŋ

Ť

Ť

Ž

Ž





 

9

9

R

R

k

k

„

„



�

¶

¶

Ï

Ï

è

è

ā

ā

Ě

Ě

ij

ij

Ō

Ō

ť

ť

ž

ž





!

!

:

:

S

S

l

l

…

ž

ž

·

·

Ð

Ð

é

é

Ă

Ă

ě

ě

Ĵ

Ĵ

ō

ō

Ŧ

Ŧ

ſ

ſ

	

"

"

&#59;

;

T

T

m

m

†

†

Ÿ

Ÿ

¸

¸

Ñ

Ñ

ê

ê

ă

ă

Ĝ

Ĝ

ĵ

ĵ

Ŏ

Ŏ

ŧ

ŧ

ƀ

ƀ




#

#

<

<

&#85;

U

&#110;

n

&#135;

‡

&#160;

&#185;

¹

&#210;

Ò

&#235;

ë

&#260;

Ą

&#285;

ĝ

&#310;

Ķ

&#335;

ŏ

&#360;

Ũ

&#385;

Ɓ

&#11;

&#36;

$

&#61;

=

&#86;

V

&#111;

o

&#136;

ˆ

&#161;

¡

&#186;

º

&#211;

Ó

&#236;

ì

&#261;

ą

&#286;

Ğ

&#311;

ķ

&#336;

Ő

&#361;

ũ

&#386;

Ƃ

&#12;

&#37;

%

&#62;

>

&#87;

W

&#112;

p

&#137;

‰

&#162;

¢

&#187;

»

&#212;

Ô

&#237;

í

&#262;

Ć

&#287;

ğ

&#312;

ĸ

&#337;

ő

&#362;

Ū

&#387;

ƃ

&#13;

&#38;

&

&#63;

?

&#88;

X

&#113;

q

&#138;

Š

&#163;

£

&#188;

¼

&#213;

Õ

&#238;

î

&#263;

ć

&#288;

Ġ

&#313;

Ĺ

&#338;

Œ

&#363;

ū

&#388;

Ƅ

&#14;



&#39;

'

&#64;

@

&#89;

Y

&#114;

r

&#139;

‹

&#164;

¤

&#189;

½

&#214;

Ö

&#239;

ï

&#264;

Ĉ

&#289;

ġ

&#314;

ĺ

&#339;

œ

&#364;

Ŭ

&#389;

ƅ

&#15;



&#40;

(

&#65;

A

&#90;

Z

&#115;

s

&#140;

Œ

&#165;

¥

&#190;

¾

&#215;

×

&#240;

ð

&#265;

ĉ

&#290;

Ģ

&#315;

Ļ

&#340;

Ŕ

&#365;

ŭ

&#390;

Ɔ

&#16;



&#41;

)

&#66;

B

&#91;

[

&#116;

t

&#141;

�

&#166;

¦

&#191;

¿

&#216;

Ø

&#241;

ñ

&#266;

Ċ

&#291;

ģ

&#316;

ļ

&#341;

ŕ

&#366;

Ů

&#391;

Ƈ

&#17;



&#42;

*

&#67;

C

&#92;

\

&#117;

u

&#142;

Ž

&#167;

§

&#192;

À

&#217;

Ù

&#242;

ò

&#267;

ċ

&#292;

Ĥ

&#317;

Ľ

&#342;

Ŗ

&#367;

ů

&#392;

ƈ

&#18;



&#43;

+

&#68;

D

&#93;

]

&#118;

v

&#143;

�

&#168;

¨

&#193;

Á

&#218;

Ú

&#243;

ó

&#268;

Č

&#293;

ĥ

&#318;

ľ

&#343;

ŗ

&#368;

Ű

&#393;

Ɖ

&#19;



&#44;

,

&#69;

E

&#94;

^

&#119;

w

&#144;

�

&#169;

©

&#194;

Â

&#219;

Û

&#244;

ô

&#269;

č

&#294;

Ħ

&#319;

Ŀ

&#344;

Ř

&#369;

ű

&#394;

Ɗ

&#20;



&#45;

-

&#70;

F

&#95;

_

&#120;

x

&#145;

‘

&#170;

ª

&#195;

Ã

&#220;

Ü

&#245;

õ

&#270;

Ď

&#295;

ħ

&#320;

ŀ

&#345;

ř

&#370;

Ų

&#395;

Ƌ

&#21;



&#46;

.

&#71;

G

&#96;

`

&#121;

y

&#146;

’

&#171;

«

&#196;

Ä

&#221;

Ý

&#246;

ö

&#271;

ď

&#296;

Ĩ

&#321;

Ł

&#346;

Ś

&#371;

ų

&#396;

ƌ

&#22;



&#47;

/

&#72;

H

&#97;

a

&#122;

z

&#147;

“

&#172;

¬

&#197;

Å

&#222;

Þ

&#247;

÷

&#272;

Đ

&#297;

ĩ

&#322;

ł

&#347;

ś

&#372;

Ŵ

&#397;

ƍ

&#23;



&#48;

0

&#73;

I

&#98;

b

&#123;

{

&#148;

”

&#173;

­

&#198;

Æ

&#223;

ß

&#248;

ø

&#273;

đ

&#298;

Ī

&#323;

Ń

&#348;

Ŝ

&#373;

ŵ

&#398;

Ǝ

&#24;



&#49;

1

&#74;

J

&#99;

c

&#124;

|

&#149;

•

&#174;

®

&#199;

Ç

&#224;

à

&#249;

ù

&#274;

Ē

&#299;

ī

&#324;

ń

&#349;

ŝ

&#374;

Ŷ

&#399;

Ə

&#25;



&#50;

2

&#75;

K

&#100;

d

&#125;

}

&#150;

–

&#175;

¯

&#200;

È

&#225;

á

&#250;

ú

&#275;

ē

&#300;

Ĭ

&#325;

Ņ

&#350;

Ş

&#375;

ŷ

&#400;

Ɛ

Category: References

Useful XHTML Character Entities

Useful reference table  when developing XHTML or Java Server Faces (JSF) of facelets...

nbsp		 	no-break space = non-breaking space,
iexcl	¡	¡	inverted exclamation mark, U+00A1 ISOnum
cent	¢	¢	cent sign, U+00A2 ISOnum
pound	£	£	pound sign, U+00A3 ISOnum
curren	¤	¤	currency sign, U+00A4 ISOnum
yen	¥	¥	yen sign = yuan sign, U+00A5 ISOnum
brvbar	¦	¦	broken bar = broken vertical bar,
sect	§	§	section sign, U+00A7 ISOnum
uml	¨	¨	diaeresis = spacing diaeresis,
copy	©	©	copyright sign, U+00A9 ISOnum
ordf	ª	ª	feminine ordinal indicator, U+00AA ISOnum
laquo	«	«	left-pointing double angle quotation mark
not	¬	¬	not sign, U+00AC ISOnum
shy	­	­	soft hyphen = discretionary hyphen,
reg	®	®	registered sign = registered trade mark sign,
macr	¯	¯	macron = spacing macron = overline
deg	°	°	degree sign, U+00B0 ISOnum
plusmn	±	±	plus-minus sign = plus-or-minus sign,
sup2	²	²	superscript two = superscript digit two
sup3	³	³	superscript three = superscript digit three
acute	´	´	acute accent = spacing acute,
micro	µ	µ	micro sign, U+00B5 ISOnum
para	¶	¶	pilcrow sign = paragraph sign,
middot	·	·	middle dot = Georgian comma
cedil	¸	¸	cedilla = spacing cedilla, U+00B8 ISOdia
sup1	¹	¹	superscript one = superscript digit one,
ordm	º	º	masculine ordinal indicator,
raquo	»	»	right-pointing double angle quotation mark
frac14	¼	¼	vulgar fraction one quarter
frac12	½	½	vulgar fraction one half
frac34	¾	¾	vulgar fraction three quarters
iquest	¿	¿	inverted question mark
Agrave	À	À	latin capital letter A with grave
Aacute	Á	Á	latin capital letter A with acute,
Acirc	Â	Â	latin capital letter A with circumflex,
Atilde	Ã	Ã	latin capital letter A with tilde,
Auml	Ä	Ä	latin capital letter A with diaeresis,
Aring	Å	Å	latin capital letter A with ring above
AElig	Æ	Æ	latin capital letter AE
Ccedil	Ç	Ç	latin capital letter C with cedilla,
Egrave	È	È	latin capital letter E with grave,
Eacute	É	É	latin capital letter E with acute,
Ecirc	Ê	Ê	latin capital letter E with circumflex,
Euml	Ë	Ë	latin capital letter E with diaeresis,
Igrave	Ì	Ì	latin capital letter I with grave,
Iacute	Í	Í	latin capital letter I with acute,
Icirc	Î	Î	latin capital letter I with circumflex,
Iuml	Ï	Ï	latin capital letter I with diaeresis,
ETH	Ð	Ð	latin capital letter ETH, U+00D0 ISOlat1
Ntilde	Ñ	Ñ	latin capital letter N with tilde,
Ograve	Ò	Ò	latin capital letter O with grave,
Oacute	Ó	Ó	latin capital letter O with acute,
Ocirc	Ô	Ô	latin capital letter O with circumflex,
Otilde	Õ	Õ	latin capital letter O with tilde,
Ouml	Ö	Ö	latin capital letter O with diaeresis,
times	×	×	multiplication sign, U+00D7 ISOnum
Oslash	Ø	Ø	latin capital letter O with stroke
Ugrave	Ù	Ù	latin capital letter U with grave,
Uacute	Ú	Ú	latin capital letter U with acute,
Ucirc	Û	Û	latin capital letter U with circumflex,
Uuml	Ü	Ü	latin capital letter U with diaeresis,
Yacute	Ý	Ý	latin capital letter Y with acute,
THORN	Þ	Þ	latin capital letter THORN,
szlig	ß	ß	latin small letter sharp s = ess-zed,
agrave	à	à	latin small letter a with grave
aacute	á	á	latin small letter a with acute,
acirc	â	â	latin small letter a with circumflex,
atilde	ã	ã	latin small letter a with tilde,
auml	ä	ä	latin small letter a with diaeresis,
aring	å	å	latin small letter a with ring above
aelig	æ	æ	latin small letter ae
ccedil	ç	ç	latin small letter c with cedilla,
egrave	è	è	latin small letter e with grave,
eacute	é	é	latin small letter e with acute,
ecirc	ê	ê	latin small letter e with circumflex,
euml	ë	ë	latin small letter e with diaeresis,
igrave	ì	ì	latin small letter i with grave,
iacute	í	í	latin small letter i with acute,
icirc	î	î	latin small letter i with circumflex,
iuml	ï	ï	latin small letter i with diaeresis,
eth	ð	ð	latin small letter eth, U+00F0 ISOlat1
ntilde	ñ	ñ	latin small letter n with tilde,
ograve	ò	ò	latin small letter o with grave,
oacute	ó	ó	latin small letter o with acute,
ocirc	ô	ô	latin small letter o with circumflex,
otilde	õ	õ	latin small letter o with tilde,
ouml	ö	ö	latin small letter o with diaeresis,
divide	÷	÷	division sign, U+00F7 ISOnum
oslash	ø	ø	latin small letter o with stroke,
ugrave	ù	ù	latin small letter u with grave,
uacute	ú	ú	latin small letter u with acute,
ucirc	û	û	latin small letter u with circumflex,
uuml	ü	ü	latin small letter u with diaeresis,
yacute	ý	ý	latin small letter y with acute,
thorn	þ	þ	latin small letter thorn,
yuml	ÿ	ÿ	latin small letter y with diaeresis,
fnof	ƒ	ƒ	latin small f with hook = function
Alpha	Α	Α	greek capital letter alpha, U+0391
Beta	Β	Β	greek capital letter beta, U+0392
Gamma	Γ	Γ	greek capital letter gamma,
Delta	Δ	Δ	greek capital letter delta,
Epsilon	Ε	Ε	greek capital letter epsilon, U+0395
Zeta	Ζ	Ζ	greek capital letter zeta, U+0396
Eta	Η	Η	greek capital letter eta, U+0397
Theta	Θ	Θ	greek capital letter theta,
Iota	Ι	Ι	greek capital letter iota, U+0399
Kappa	Κ	Κ	greek capital letter kappa, U+039A
Lambda	Λ	Λ	greek capital letter lambda,
Mu	Μ	Μ	greek capital letter mu, U+039C
Nu	Ν	Ν	greek capital letter nu, U+039D
Xi	Ξ	Ξ	greek capital letter xi, U+039E ISOgrk3
Omicron	Ο	Ο	greek capital letter omicron, U+039F
Pi	Π	Π	greek capital letter pi, U+03A0 ISOgrk3
Rho	Ρ	Ρ	greek capital letter rho, U+03A1
Sigma	Σ	Σ	greek capital letter sigma,
Tau	Τ	Τ	greek capital letter tau, U+03A4
Upsilon	Υ	Υ	greek capital letter upsilon,
Phi	Φ	Φ	greek capital letter phi,
Chi	Χ	Χ	greek capital letter chi, U+03A7
Psi	Ψ	Ψ	greek capital letter psi,
Omega	Ω	Ω	greek capital letter omega,
alpha	α	α	greek small letter alpha,
beta	β	β	greek small letter beta, U+03B2 ISOgrk3
gamma	γ	γ	greek small letter gamma,
delta	δ	δ	greek small letter delta,
epsilon	ε	ε	greek small letter epsilon,
zeta	ζ	ζ	greek small letter zeta, U+03B6 ISOgrk3
eta	η	η	greek small letter eta, U+03B7 ISOgrk3
theta	θ	θ	greek small letter theta,
iota	ι	ι	greek small letter iota, U+03B9 ISOgrk3
kappa	κ	κ	greek small letter kappa,
lambda	λ	λ	greek small letter lambda,
mu	μ	μ	greek small letter mu, U+03BC ISOgrk3
nu	ν	ν	greek small letter nu, U+03BD ISOgrk3
xi	ξ	ξ	greek small letter xi, U+03BE ISOgrk3
omicron	ο	ο	greek small letter omicron, U+03BF NEW
pi	π	π	greek small letter pi, U+03C0 ISOgrk3
rho	ρ	ρ	greek small letter rho, U+03C1 ISOgrk3
sigmaf	ς	ς	greek small letter final sigma,
sigma	σ	σ	greek small letter sigma,
tau	τ	τ	greek small letter tau, U+03C4 ISOgrk3
upsilon	υ	υ	greek small letter upsilon,
phi	φ	φ	greek small letter phi, U+03C6 ISOgrk3
chi	χ	χ	greek small letter chi, U+03C7 ISOgrk3
psi	ψ	ψ	greek small letter psi, U+03C8 ISOgrk3
omega	ω	ω	greek small letter omega,
thetasym	ϑ	ϑ	greek small letter theta symbol,
upsih	ϒ	ϒ	greek upsilon with hook symbol,
piv	ϖ	ϖ	greek pi symbol, U+03D6 ISOgrk3
bull	•	•	bullet = black small circle,
hellip		…	horizontal ellipsis = three dot leader,
prime	′	′	prime = minutes = feet, U+2032 ISOtech
Prime	″	″	double prime = seconds = inches,
oline	‾	‾	overline = spacing overscore,
frasl	⁄	⁄	fraction slash, U+2044 NEW
weierp	℘	℘	script capital P = power set
image	ℑ	ℑ	blackletter capital I = imaginary part,
real	ℜ	ℜ	blackletter capital R = real part symbol,
trade	™	™	trade mark sign, U+2122 ISOnum
alefsym	ℵ	ℵ	alef symbol = first transfinite cardinal,
larr	←	←	leftwards arrow, U+2190 ISOnum
uarr	↑	↑	upwards arrow, U+2191 ISOnum-->
rarr	→	→	rightwards arrow, U+2192 ISOnum
darr	↓	↓	downwards arrow, U+2193 ISOnum
harr	↔	↔	left right arrow, U+2194 ISOamsa
crarr	↵	↵	downwards arrow with corner leftwards
lArr	⇐	⇐	leftwards double arrow, U+21D0 ISOtech
uArr	⇑	⇑	upwards double arrow, U+21D1 ISOamsa
rArr	⇒	⇒	rightwards double arrow,
dArr	⇓	⇓	downwards double arrow, U+21D3 ISOamsa
hArr	⇔	⇔	left right double arrow,
forall	∀	∀	for all, U+2200 ISOtech
part	∂	∂	partial differential, U+2202 ISOtech
exist	∃	∃	there exists, U+2203 ISOtech
empty	∅	∅	empty set = null set = diameter,
nabla	∇	∇	nabla = backward difference,
isin	∈	∈	element of, U+2208 ISOtech
notin	∉	∉	not an element of, U+2209 ISOtech
ni	∋	∋	contains as member, U+220B ISOtech
prod	∏	∏	n-ary product = product sign,
sum	∑	∑	n-ary sumation, U+2211 ISOamsb
minus	−	−	minus sign, U+2212 ISOtech
lowast	∗	∗	asterisk operator, U+2217 ISOtech
radic	√	√	square root = radical sign,
prop	∝	∝	proportional to, U+221D ISOtech
infin	∞	∞	infinity, U+221E ISOtech
ang	∠	∠	angle, U+2220 ISOamso
and	∧	∧	logical and = wedge, U+2227 ISOtech
or	∨	∨	logical or = vee, U+2228 ISOtech
cap	∩	∩	intersection = cap, U+2229 ISOtech
cup	∪	∪	union = cup, U+222A ISOtech
int	∫	∫	integral, U+222B ISOtech
there4	∴	∴	therefore, U+2234 ISOtech
sim	∼	∼	tilde operator = varies with = similar
cong	≅	≅	approximately equal to, U+2245 ISOtech
asymp	≈	≈	almost equal to = asymptotic to,
ne	≠	≠	not equal to, U+2260 ISOtech
equiv	≡	≡	identical to, U+2261 ISOtech
le	≤	≤	less-than or equal to, U+2264 ISOtech
ge	≥	≥	greater-than or equal to,
sub	⊂	⊂	subset of, U+2282 ISOtech
sup	⊃	⊃	superset of, U+2283 ISOtech
nsub	⊄	⊄	not a subset of, U+2284 ISOamsn
sube	⊆	⊆	subset of or equal to, U+2286 ISOtech
supe	⊇	⊇	superset of or equal to,
oplus	⊕	⊕	circled plus = direct sum,
otimes	⊗	⊗	circled times = vector product,
perp	⊥	⊥	up tack = orthogonal to = perpendicular,
sdot	⋅	⋅	dot operator, U+22C5 ISOamsb
lceil	⌈	⌈	left ceiling = apl upstile,
rceil	⌉	⌉	right ceiling, U+2309 ISOamsc
lfloor	⌊	⌊	left floor = apl downstile,
rfloor	⌋	⌋	right floor, U+230B ISOamsc
lang	〈	〈	left-pointing angle bracket = bra,
rang	〉	〉	right-pointing angle bracket = ket,
loz	◊	◊	lozenge, U+25CA ISOpub
spades	♠	♠	black spade suit, U+2660 ISOpub
clubs	♣	♣	black club suit = shamrock,
hearts	♥	♥	black heart suit = valentine,
diams	♦	♦	black diamond suit, U+2666 ISOpub
quot	"	"	quotation mark = APL quote,
amp	&	&	ampersand, U+0026 ISOnum
lt	<	&#60;	less-than sign, U+003C ISOnum
gt	>	&#62;	greater-than sign, U+003E ISOnum
OElig	Œ	&#338;	latin capital ligature OE,
oelig	œ	&#339;	latin small ligature oe, U+0153 ISOlat2
Scaron	Š	&#352;	latin capital letter S with caron,
scaron	š	&#353;	latin small letter s with caron,
Yuml	Ÿ	&#376;	latin capital letter Y with diaeresis,
circ	ˆ	&#710;	modifier letter circumflex accent,
tilde	˜	&#732;	small tilde, U+02DC ISOdia
ensp		&#8194;	en space, U+2002 ISOpub
emsp		&#8195;	em space, U+2003 ISOpub
thinsp		&#8201;	thin space, U+2009 ISOpub
zwnj	‌	&#8204;	zero width non-joiner,
zwj	‍	&#8205;	zero width joiner, U+200D NEW RFC 2070
lrm	‎	&#8206;	left-to-right mark, U+200E NEW RFC 2070
rlm	‏	&#8207;	right-to-left mark, U+200F NEW RFC 2070
ndash	–	&#8211;	en dash, U+2013 ISOpub
mdash	—	&#8212;	em dash, U+2014 ISOpub
lsquo	‘	&#8216;	left single quotation mark,
rsquo	’	&#8217;	right single quotation mark,
sbquo	‚	&#8218;	single low-9 quotation mark, U+201A NEW
ldquo	“	&#8220;	left double quotation mark,
rdquo	”	&#8221;	right double quotation mark,
bdquo	„	&#8222;	double low-9 quotation mark, U+201E NEW
dagger	†	&#8224;	dagger, U+2020 ISOpub
Dagger	‡	&#8225;	double dagger, U+2021 ISOpub
permil	‰	&#8240;	per mille sign, U+2030 ISOtech
lsaquo	‹	&#8249;	single left-pointing angle quotation mark,
rsaquo	›	&#8250;	single right-pointing angle quotation mark,
euro	€	&#8364;	euro sign, U+20AC NEW

Category: References

Content-Disposition header

Useful if you want to send dynamic content to the browser: a generated PDF for example...




Network Working Group                                          R. Troost
Request for Comments: 2183                           New Century Systems
Updates: 1806                                                  S. Dorner
Category: Standards Track                          QUALCOMM Incorporated
                                                        K. Moore, Editor
                                                 University of Tennessee
                                                             August 1997


               Communicating Presentation Information in
                           Internet Messages:
                  The Content-Disposition Header Field

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   This memo provides a mechanism whereby messages conforming to the
   MIME specifications [RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC
   2049] can convey presentational information.  It specifies the
   "Content-Disposition" header field, which is optional and valid for
   any MIME entity ("message" or "body part").  Two values for this
   header field are described in this memo; one for the ordinary linear
   presentation of the body part, and another to facilitate the use of
   mail to transfer files.  It is expected that more values will be
   defined in the future, and procedures are defined for extending this
    set of values.

   This document is intended as an extension to MIME.  As such, the
   reader is assumed to be familiar with the MIME specifications, and
   [RFC 822].  The information presented herein supplements but does not
   replace that found in those documents.

   This document is a revision to the Experimental protocol defined in
   RFC 1806.  As compared to RFC 1806, this document contains minor
   editorial updates, adds new parameters needed to support the File
   Transfer Body Part, and references a separate specification for the
   handling of non-ASCII and/or very long parameter values.







Troost, et. al.             Standards Track                     [Page 1]

RFC 2183                  Content-Disposition                August 1997


1.  Introduction

   MIME specifies a standard format for encapsulating multiple pieces of
   data into a single Internet message. That document does not address
   the issue of presentation styles; it provides a framework for the
   interchange of message content, but leaves presentation issues solely
   in the hands of mail user agent (MUA) implementors.

   Two common ways of presenting multipart electronic messages are as a
   main document with a list of separate attachments, and as a single
   document with the various parts expanded (displayed) inline. The
   display of an attachment is generally construed to require positive
   action on the part of the recipient, while inline message components
   are displayed automatically when the message is viewed. A mechanism
   is needed to allow the sender to transmit this sort of presentational
   information to the recipient; the Content-Disposition header provides
   this mechanism, allowing each component of a message to be tagged
   with an indication of its desired presentation semantics.

   Tagging messages in this manner will often be sufficient for basic
   message formatting. However, in many cases a more powerful and
   flexible approach will be necessary. The definition of such
   approaches is beyond the scope of this memo; however, such approaches
   can benefit from additional Content-Disposition values and
   parameters, to be defined at a later date.

   In addition to allowing the sender to specify the presentational
   disposition of a message component, it is desirable to allow her to
   indicate a default archival disposition; a filename. The optional
   "filename" parameter provides for this.  Further, the creation-date,
   modification-date, and read-date parameters allow preservation of
   those file attributes when the file is transmitted over MIME email.

   NB: The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in [RFC 2119].

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.




Troost, et. al.             Standards Track                     [Page 2]

RFC 2183                  Content-Disposition                August 1997


   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].




Troost, et. al.             Standards Track                     [Page 3]

RFC 2183                  Content-Disposition                August 1997


2.1  The Inline Disposition Type

   A bodypart should be marked `inline' if it is intended to be
   displayed automatically upon display of the message.  Inline
   bodyparts should be presented in the order in which they occur,
   subject to the normal semantics of multipart messages.

2.2  The Attachment Disposition Type

   Bodyparts can be designated `attachment' to indicate that they are
   separate from the main body of the mail message, and that their
   display should not be automatic, but contingent upon some further
   action of the user.  The MUA might instead present the user of a
   bitmap terminal with an iconic representation of the attachments, or,
   on character terminals, with a list of attachments from which the
   user could select for viewing or storage.

2.3  The Filename Parameter

   The sender may want to suggest a filename to be used if the entity is
   detached and stored in a separate file. If the receiving MUA writes
   the entity to a file, the suggested filename should be used as a
   basis for the actual filename, where possible.

   It is important that the receiving MUA not blindly use the suggested
   filename.  The suggested filename SHOULD be checked (and possibly
   changed) to see that it conforms to local filesystem conventions,
   does not overwrite an existing file, and does not present a security
   problem (see Security Considerations below).

   The receiving MUA SHOULD NOT respect any directory path information
   that may seem to be present in the filename parameter.  The filename
   should be treated as a terminal component only.  Portable
   specification of directory paths might possibly be done in the future
   via a separate Content-Disposition parameter, but no provision is
   made for it in this draft.

   Current [RFC 2045] grammar restricts parameter values (and hence
   Content-Disposition filenames) to US-ASCII.  We recognize the great
   desirability of allowing arbitrary character sets in filenames, but
   it is beyond the scope of this document to define the necessary
   mechanisms.  We expect that the basic [RFC 1521] `value'
   specification will someday be amended to allow use of non-US-ASCII
   characters, at which time the same mechanism should be used in the
   Content-Disposition filename parameter.






Troost, et. al.             Standards Track                     [Page 4]

RFC 2183                  Content-Disposition                August 1997


   Beyond the limitation to US-ASCII, the sending MUA may wish to bear
   in mind the limitations of common filesystems.  Many have severe
   length and character set restrictions.  Short alphanumeric filenames
   are least likely to require modification by the receiving system.

   The presence of the filename parameter does not force an
   implementation to write the entity to a separate file. It is
   perfectly acceptable for implementations to leave the entity as part
   of the normal mail stream unless the user requests otherwise. As a
   consequence, the parameter may be used on any MIME entity, even
   `inline' ones. These will not normally be written to files, but the
   parameter could be used to provide a filename if the receiving user
   should choose to write the part to a file.

2.4 The Creation-Date parameter

   The creation-date parameter MAY be used to indicate the date at which
   the file was created.  If this parameter is included, the paramter
   value MUST be a quoted-string which contains a representation of the
   creation date of the file in [RFC 822] `date-time' format.

   UNIX and POSIX implementors are cautioned that the `st_ctime' file
   attribute of the `stat' structure is not the creation time of the
   file; it is thus not appropriate as a source for the creation-date
   parameter value.

2.5 The Modification-Date parameter

   The modification-date parameter MAY be used to indicate the date at
   which the file was last modified.  If the modification-date parameter
   is included, the paramter value MUST be a quoted-string which
   contains a representation of the last modification date of the file
   in [RFC 822] `date-time' format.

2.6 The Read-Date parameter

   The read-date parameter MAY be used to indicate the date at which the
   file was last read.  If the read-date parameter is included, the
   parameter value MUST be a quoted-string which contains a
   representation of the last-read date of the file in [RFC 822] `date-
   time' format.

2.7 The Size parameter

   The size parameter indicates an approximate size of the file in
   octets.  It can be used, for example, to pre-allocate space before
   attempting to store the file, or to determine whether enough space
   exists.



Troost, et. al.             Standards Track                     [Page 5]

RFC 2183                  Content-Disposition                August 1997


2.8  Future Extensions and Unrecognized Disposition Types

   In the likely event that new parameters or disposition types are
   needed, they should be registered with the Internet Assigned Numbers
   Authority (IANA), in the manner specified in Section 9 of this memo.

   Once new disposition types and parameters are defined, there is of
   course the likelihood that implementations will see disposition types
   and parameters they do not understand.  Furthermore, since x-tokens
   are allowed, implementations may also see entirely unregistered
   disposition types and parameters.

   Unrecognized parameters should be ignored. Unrecognized disposition
   types should be treated as `attachment'. The choice of `attachment'
   for unrecognized types is made because a sender who goes to the
   trouble of producing a Content-Disposition header with a new
   disposition type is more likely aiming for something more elaborate
   than inline presentation.

   Unless noted otherwise in the definition of a parameter, Content-
   Disposition parameters are valid for all dispositions.  (In contrast
   to MIME content-type parameters, which are defined on a per-content-
   type basis.) Thus, for example, the `filename' parameter still means
   the name of the file to which the part should be written, even if the
   disposition itself is unrecognized.

2.9  Content-Disposition and Multipart

   If a Content-Disposition header is used on a multipart body part, it
   applies to the multipart as a whole, not the individual subparts.
   The disposition types of the subparts do not need to be consulted
   until the multipart itself is presented.  When the multipart is
   displayed, then the dispositions of the subparts should be respected.

   If the `inline' disposition is used, the multipart should be
   displayed as normal; however, an `attachment' subpart should require
   action from the user to display.

   If the `attachment' disposition is used, presentation of the
   multipart should not proceed without explicit user action.  Once the
   user has chosen to display the multipart, the individual subpart
   dispositions should be consulted to determine how to present the
   subparts.








Troost, et. al.             Standards Track                     [Page 6]

RFC 2183                  Content-Disposition                August 1997


2.10  Content-Disposition and the Main Message

   It is permissible to use Content-Disposition on the main body of an
   [RFC 822] message.

3.  Examples

   Here is a an example of a body part containing a JPEG image that is
   intended to be viewed by the user immediately:

        Content-Type: image/jpeg
        Content-Disposition: inline
        Content-Description: just a small picture of me

        

   The following body part contains a JPEG image that should be
   displayed to the user only if the user requests it. If the JPEG is
   written to a file, the file should be named "genome.jpg".  The
   recipient's user might also choose to set the last-modified date of
   the stored file to date in the modification-date parameter:

        Content-Type: image/jpeg
        Content-Disposition: attachment; filename=genome.jpeg;
          modification-date="Wed, 12 Feb 1997 16:29:51 -0500";
        Content-Description: a complete map of the human genome

       

   The following is an example of the use of the `attachment'
   disposition with a multipart body part.  The user should see text-
   part-1 immediately, then take some action to view multipart-2.  After
   taking action to view multipart-2, the user will see text-part-2
   right away, and be required to take action to view jpeg-1.  Subparts
   are indented for clarity; they would not be so indented in a real
   message.















Troost, et. al.             Standards Track                     [Page 7]

RFC 2183                  Content-Disposition                August 1997


        Content-Type: multipart/mixed; boundary=outer
        Content-Description: multipart-1

        --outer
          Content-Type: text/plain
          Content-Disposition: inline
          Content-Description: text-part-1

          Some text goes here

        --outer
          Content-Type: multipart/mixed; boundary=inner
          Content-Disposition: attachment
          Content-Description: multipart-2

          --inner
            Content-Type: text/plain
            Content-Disposition: inline
            Content-Description: text-part-2

            Some more text here.

          --inner
            Content-Type: image/jpeg
            Content-Disposition: attachment
            Content-Description: jpeg-1

           
          --inner--
        --outer--

4.  Summary

   Content-Disposition takes one of two values, `inline' and
   `attachment'.  `Inline' indicates that the entity should be
   immediately displayed to the user, whereas `attachment' means that
   the user should take additional action to view the entity.

   The `filename' parameter can be used to suggest a filename for
   storing the bodypart, if the user wishes to store it in an external
   file.










Troost, et. al.             Standards Track                     [Page 8]

RFC 2183                  Content-Disposition                August 1997


5.  Security Considerations

   There are security issues involved any time users exchange data.
   While these are not to be minimized, neither does this memo change
   the status quo in that regard, except in one instance.

   Since this memo provides a way for the sender to suggest a filename,
   a receiving MUA must take care that the sender's suggested filename
   does not represent a hazard. Using UNIX as an example, some hazards
   would be:

   +    Creating startup files (e.g., ".login").

   +    Creating or overwriting system files (e.g., "/etc/passwd").

   +    Overwriting any existing file.

   +    Placing executable files into any command search path
        (e.g., "~/bin/more").

   +    Sending the file to a pipe (e.g., "| sh").

   In general, the receiving MUA should not name or place the file such
   that it will get interpreted or executed without the user explicitly
   initiating the action.

   It is very important to note that this is not an exhaustive list; it
   is intended as a small set of examples only.  Implementors must be
   alert to the potential hazards on their target systems.

6.  References

   [RFC 2119]
        Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", RFC 2119, March 1997.

   [RFC 2184]
        Freed, N. and K. Moore, "MIME Parameter value and Encoded Words:
        Character Sets, Lanaguage, and Continuations", RFC 2184, August
        1997.

   [RFC 2045]
        Freed, N. and N. Borenstein, "MIME (Multipurpose Internet Mail
        Extensions) Part One: Format of Internet Message Bodies", RFC
        2045, December 1996.






Troost, et. al.             Standards Track                     [Page 9]

RFC 2183                  Content-Disposition                August 1997


   [RFC 2046]
        Freed, N. and N. Borenstein, "MIME (Multipurpose Internet Mail
        Extensions) Part Two: Media Types", RFC 2046, December 1996.

   [RFC 2047]
        Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
        Three: Message Header Extensions for non-ASCII Text", RFC 2047,
        December 1996.

   [RFC 2048]
        Freed, N., Klensin, J. and J. Postel, "MIME (Multipurpose
        Internet Mail Extensions) Part Four: Registration Procedures",
        RFC 2048, December 1996.

   [RFC 2049]
        Freed, N. and N. Borenstein, "MIME (Multipurpose Internet Mail
        Extensions) Part Five: Conformance Criteria and Examples", RFC
        2049, December 1996.

   [RFC 822]
        Crocker, D., "Standard for the Format of ARPA Internet Text
        Messages", STD 11, RFC 822, UDEL, August 1982.

7.  Acknowledgements

   We gratefully acknowledge the help these people provided during the
   preparation of this draft:

        Nathaniel Borenstein
        Ned Freed
        Keith Moore
        Dave Crocker
        Dan Pritchett


















Troost, et. al.             Standards Track                    [Page 10]

RFC 2183                  Content-Disposition                August 1997


8.  Authors' Addresses

   You should blame the editor of this version of the document for any
   changes since RFC 1806:

        Keith Moore
        Department of Computer Science
        University of Tennessee, Knoxville
        107 Ayres Hall
        Knoxville TN  37996-1301
        USA

        Phone: +1 (423) 974-5067
        Fax: +1 (423) 974-8296
        Email: This email address is being protected from spambots. You need JavaScript enabled to view it.


        The authors of RFC 1806 are:

        Rens Troost
        New Century Systems
        324 East 41st Street #804
        New York, NY, 10017 USA

        Phone: +1 (212) 557-2050
        Fax: +1 (212) 557-2049
        EMail: This email address is being protected from spambots. You need JavaScript enabled to view it.


        Steve Dorner
        QUALCOMM Incorporated
        6455 Lusk Boulevard
        San Diego, CA 92121
        USA

        EMail: This email address is being protected from spambots. You need JavaScript enabled to view it.


9. Registration of New Content-Disposition Values and Parameters

   New Content-Disposition values (besides "inline" and "attachment")
   may be defined only by Internet standards-track documents, or in
   Experimental documents approved by the Internet Engineering Steering
   Group.







Troost, et. al.             Standards Track                    [Page 11]

RFC 2183                  Content-Disposition                August 1997


   New content-disposition parameters may be registered by supplying the
   information in the following template and sending it via electronic
   mail to This email address is being protected from spambots. You need JavaScript enabled to view it. :

     To: This email address is being protected from spambots. You need JavaScript enabled to view it.
     Subject: Registration of new Content-Disposition parameter

     Content-Disposition parameter name:

     Allowable values for this parameter:
          (If the parameter can only assume a small number of values,
          list each of those values.  Otherwise, describe the values
          that the parameter can assume.)
     Description:
          (What is the purpose of this parameter and how is it used?)

10. Changes since RFC 1806

   The following changes have been made since the earlier version of
   this document, published in RFC 1806 as an Experimental protocol:

   +    Updated references to MIME documents.  In some cases this
        involved substituting a reference to one of the current MIME
        RFCs for a reference to RFC 1521; in other cases, a reference to
        RFC 1521 was simply replaced with the word "MIME".

   +    Added  a section on registration procedures, since none of the
        procedures in RFC 2048 seemed to be appropriate.

   +    Added new parameter types: creation-date, modification-date,
        read-date, and size.


   +    Incorporated a reference to draft-freed-pvcsc-* for encoding
        long or non-ASCII parameter values.

   +    Added reference to RFC 2119 to define MUST, SHOULD, etc.
        keywords.

Troost, et. al.             Standards Track                    [Page 12]


Comments

Category: References

Published Date

Written by Administrator

Hits: 10988

• 
•