Windows-1252

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.

1. 개요

Windows-1252는 마이크로소프트 윈도우 1.0에서 처음 사용된 코드 페이지로, ISO-8859-1 표준을 기반으로 확장되었다. 윈도우 98에서 현재 형태로 완성되었으며, 유로 기호 등이 추가되었다. 1990년대에는 윈도우-1252 전용 문자를 포함하는 HTML 파일의 호환성 문제와 스마트 따옴표 기능으로 인한 문자 깨짐 현상이 발생했으나, 2000년대에 대부분의 웹 브라우저와 이메일 클라이언트가 이러한 문제를 해결하기 위해 ISO-8859-1과 US-ASCII를 윈도우-1252로 취급하게 되었다. 윈도우 NT는 유니코드를 지원했지만, 윈도우-1252는 8비트 문자열을 선호하는 응용 프로그램에서 계속 사용되었으며, 윈도우 10부터 UTF-8 지원이 강화되면서 사용 빈도가 줄어들고 있다.

Windows-1252

일반 정보

이미지 준비중입니다.

Windows-1252 문자 코드표

이름	Windows-1252
MIME	windows-1252
다른 이름	cp1252 (코드 페이지 1252)
개발	마이크로소프트
표준	WHATWG 인코딩 표준
지원 언어	ISO/IEC 8859-1에서 지원하는 모든 언어, 프랑스어 및 핀란드어 완벽 지원, 영어의 합자 형태 완전 지원. 예: 드물게 예외적인 글자를 제외한 덴마크어, 아일랜드어, 이탈리아어, 노르웨이어, 포르투갈어, 스페인어, 스웨덴어, 독일어 (대문자 ẞ 누락), 아이슬란드어, 페로어, 룩셈부르크어, 알바니아어, 에스토니아어, 스와힐리어, 츠와나어, 카탈루냐어, 바스크어, 오크어, 로토카스, 토키 포나, 로지반, 로망슈어, 네덜란드어 (IJ/ij 또는 ÿ로 대체되는 Ĳ/ĳ 문자 제외) 및 슬로베니아어 (ç로 대체되는 č 문자 제외).
확장	ISO 8859-1 (C1 제어 문자 제외)
다음	유니코드 (UTF-8, UTF-16)
인코딩	ISO 8859-15
분류	확장 ASCII, Windows-125x

📚 더 읽어볼만한 페이지

윈도우 코드 페이지 - 코드 페이지 950
코드 페이지 950은 윈도우 운영체제에서 사용되는 Big5 인코딩 기반의 문자 인코딩 방식이며, 마이크로소프트와 IBM에서 다양한 변형과 확장을 거쳐 사용된다.
윈도우 코드 페이지 - 코드 페이지 949
코드 페이지 949는 EUC-KR을 확장한 문자 인코딩으로, IBM과 마이크로소프트에서 다르게 정의되어 사용되며, 파이썬과 WHATWG에서도 각기 다른 레이블로 인식한다.

1. 개요
2. 역사
3. 코드 페이지 레이아웃
- 3.1. 상세 코드표
4. 호환성 문제
- 4.1. 인코딩/디코딩 예시
5. 관련 인코딩

2. 역사

마이크로소프트 윈도우 1.0부터 사용되기 시작하여 윈도우 98에서 현재 형태로 완성되었다. 초기에는 ISO-8859-1 표준과 거의 일치했으나, 점차 확장되어 현재는 ISO-8859-1의 상위 집합이 되었다. 윈도우에서 "ANSI 코드 페이지"라고 불렸지만, 실제로 ANSI 표준은 아니다. 역사적인 이유로 ANSI 코드 페이지라고 불린다.

1990년대에는 많은 마이크로소프트 제품들이 인코딩을 ISO-8859-1, ASCII 또는 미선언으로 표시하면서도, Windows-1252 전용 문자를 포함하는 문제가 있었다. 특히, 스마트 따옴표 기능으로 인해 마이크로소프트 워드와 같은 윈도우 응용 프로그램에서 생성된 파일에서 미국-ASCII의 표준 직선 아포스트로피와 따옴표의 굴곡 변형인 활자사 따옴표가 흔히 사용되었고, 이는 비 윈도우 운영 체제에서 문자 깨짐 현상을 유발했다.

2000년대에 들어 대부분의 웹 브라우저와 전자 메일 클라이언트가 이러한 문제를 해결하기 위해 ISO-8859-1과 US-ASCII를 Windows-1252로 취급하게 되었다. 이 동작은 현재 HTML5 사양에서도 요구된다.

윈도우 NT는 유니코드를 지원하고 프로그램에서 사용하도록 권장했지만, UCS-2/UTF-16의 16비트 코드 단위만 제공했다. 많은 응용 프로그램이 8비트 문자열을 사용하는 것을 선호했기 때문에, Windows-1252는 UTF-16에 대한 지원을 추가한 후에도 윈도우에서 가장 인기 있는 인코딩으로 남아 있었다. 윈도우의 유니코드 지원은 시간이 지남에 따라 개선되었으며, 윈도우 10부터 UTF-8 지원이 제공되었다. 유니코드(UTF-8 형식이 많은 경우)가 Windows-1252 등 8비트 "코드 페이지"를 대체하여 점차 사용되고 있다.

2.1. 윈도우 1.0 (ISO-8859-1 기반)

마이크로소프트 윈도우 1.0에서 사용된 코드 페이지의 첫 번째 버전은 ISO-8859-1 표준과 일치했다(당시 표준에 없었던 코드 포인트 0xD7과 0xF7을 정의하지 않은 것을 포함).

2.2. 윈도우 2.0

마이크로소프트 윈도우 2.0에서 도입된 두 번째 버전의 코드 페이지에서는 코드 포인트 0xD7, 0xF7, 0x91, 0x92가 정의되었다.

2.3. 윈도우 3.1

마이크로소프트 윈도우 3.1에서 코드 페이지의 세 번째 버전이 도입되었다. 이 버전은 유로 기호와 캐론이 있는 Z 문자 쌍을 제외한 최종 버전에서 사용되는 모든 코드 포인트를 정의했다.

2.4. 윈도우 98 (최종 버전)

마이크로소프트 윈도우 98에서 도입된 최종 버전은 유로 기호(€)와 캐론이 있는 Z 문자 쌍(Ž/ž)을 추가했다.

3. 코드 페이지 레이아웃

다음 표는 Windows-1252 코드 페이지의 레이아웃을 나타낸다.

👆

좌우로 밀어서 보기

]]
| ~
| DEL
|-
! 8x
| €
|
| ‚
| ƒ
| „
| …
| †
| ‡
| ˆ
| ‰
| Š
| ‹
| Œ
|
| Ž
|
|-
! 9x
|
| ‘
| ’
| “
| ”
| •
| –
| —
| ˜
| ™
| š
| ›
| œ
|
| ž
| Ÿ
|-
! Ax
| NBSP
| ¡
| ¢
| £
| ¤
| ¥
| ¦
| §
| ¨
| ©
| ª
| «
| ¬
| SHY
| ®
| ¯
|-
! Bx
| °
| ±
| ²
| ³
| ´
| µ
| ¶
| ·
| ¸
| ¹
| º
| »
| ¼
| ½
| ¾
| ¿
|-
! Cx
| À
| Á
| Â
| Ã
| Ä
| Å
| Æ
| Ç
| È
| É
| Ê
| Ë
| Ì
| Í
| Î
| Ï
|-
! Dx
| Ð
| Ñ
| Ò
| Ó
| Ô
| Õ
| Ö
| ×
| Ø
| Ù
| Ú
| Û
| Ü
| Ý
| Þ
| ß
|-
! Ex
| à
| á
| â
| ã
| ä
| å
| æ
| ç
| è
| é
| ê
| ë
| ì
| í
| î
| ï
|-
! Fx
| ð
| ñ
| ò
| ó
| ô
| õ
| ö
| ÷
| ø
| ù
| ú
| û
| ü
| ý
| þ
| ÿ
|}

* 0x00-0x7F: ASCII와 동일하다.
* 0x80-0x9F: ISO-8859-1과의 주요 차이점으로, 제어 문자 대신 추가 문자가 할당되어 있다.
* 0xA0-0xFF: ISO-8859-1과 대체로 동일하다.

코드 위치 81, 8D, 8F, 90 및 9D는 마이크로소프트와 유니코드 컨소시엄에 따르면 사용되지 않지만, Windows API 호출은 이를 해당 C1 제어 문자에 매핑한다.

3.1. 상세 코드표

다음은 Windows-1252 코드표이다. ISO-8859-1과의 차이점은 유니코드 코드 포인트 번호가 문자 아래에 표시되며, 유니코드.org의 Windows-1252 매핑을 "최적 일치"로 사용한다.

👆

좌우로 밀어서 보기

	x0	x1	x2	x3	x4	x5	x6	x7	x8	x9	xA	xB	xC	xD	xE	xF
0x	NUL	SOH	STX	ETX	EOT	ENQ	ACK	BEL	BS	TAB	LF	VT	FF	CR	SO	SI
1x	DLE	DC1	DC2	DC3	DC4	NAK	SYN	ETB	CAN	EM	SUB	ESC	FS	GS	RS	US
2x	SP	!	"	#	$	%	&	'	(	)	*	+	,	-	.	/
3x	0	1	2	3	4	5	6	7	8	9	:	;	<	=	>	?
4x	@	A	B	C	D	E	F	G	H	I	J	K	L	M	N	O
5x	P	Q	R	S	T	U	V	W	X	Y	Z	[]	\\	[]	^	_
6x	`	a	b	c	d	e	f	g	h	i	j	k	l	m	n	o
7x	p	q	r	s	t	u	v	w	x	y	z	{	\|	[[중괄호\|}

]]
125
| ~
126
| style="text-decoration:underline" title="Delete" | DEL
127
|- style="background-color:#FF7"
! style="background-color:#FFF;" | 8x
| €
128
| style="background-color:#CFC" |
129
| ‚
130
| ƒ
131
| „
132
| …
133
| †
134
| ‡
135
| ˆ
136
| ‰
137
| Š
138
| ‹
139
| Œ
140
| style="background-color:#CFC" |
141
| Ž
142
| style="background-color:#CFC" |
143
|- style="background-color:#FF7"
! style="background-color:#FFF;" | 9x
| style="background-color:#CFC" |
144
| ‘
145
| ’
146
| “
147
| ”
148
| •
149
| –
150
| —
151
| ˜
152
| ™
153
| š
154
| ›
155
| œ
156
| style="background-color:#CFC" |
157
| ž
158
| Ÿ
159
|-
! Ax
| style="text-decoration:underline" title="Non-Breaking Space" | NBSP
160
| ¡
161
| ¢
162
| £
163
| ¤
164
| ¥
165
| ¦
166
| §
167
| ¨
168
| ©
169
| ª
170
| «
171
| ¬
172
| style="text-decoration: underline" | SHY
173
| ®
174
| ¯
175
|-
! Bx
| °
176
| ±
177
| ²
178
| ³
179
| ´
180
| µ
181
| ¶
182
| ·
183
| ¸
184
| ¹
185
| º
186
| »
187
| ¼
188
| ½
189
| ¾
190
| ¿
191
|-
! Cx
| À
192
| Á
193
| Â
194
| Ã
195
| Ä
196
| Å
197
| Æ
198
| Ç
199
| È
200
| É
201
| Ê
202
| Ë
203
| Ì
204
| Í
205
| Î
206
| Ï
207
|-
! Dx
| Ð
208
| Ñ
209
| Ò
210
| Ó
211
| Ô
212
| Õ
213
| Ö
214
| ×
215
| Ø
216
| Ù
217
| Ú
218
| Û
219
| Ü
220
| Ý
221
| Þ
222
| ß
223
|-
! Ex
| à
224
| á
225
| â
226
| ã
227
| ä
228
| å
229
| æ
230
| ç
231
| è
232
| é
233
| ê
234
| ë
235
| ì
236
| í
237
| î
238
| ï
239
|-
! Fx
| ð
240
| ñ
241
| ò
242
| ó
243
| ô
244
| õ
245
| ö
246
| ÷
247
| ø
248
| ù
249
| ú
250
| û
251
| ü
252
| ý
253
| þ
254
| ÿ
255
|}

마이크로소프트와 유니코드 컨소시엄 웹사이트의 정보에 따르면 코드 위치 81, 8D, 8F, 90 및 9D는 사용되지 않는다. 그러나 코드 페이지에서 유니코드로 변환하기 위한 Windows API 호출은 이를 해당 C1 제어 문자에 매핑한다.

4. 호환성 문제

Windows-1252로 인코딩된 문서는 다른 인코딩 환경(EUC-KR, UTF-8 등)에서 열람할 때 문자 깨짐 현상이 발생할 수 있다. 예를 들어 euc-kr 환경에서 Windows-1252로 작성된 텍스트 '하천'을 리눅스 UTF-8 환경에서 열면 'Ã‡ÃÃƒÂµ'와 같이 깨진 문자가 나타난다.

1990년대부터 많은 마이크로소프트 제품들은 HTML을 생성할 때 Windows-1252 전용 문자를 포함하면서도 인코딩을 ISO-8859-1, ASCII 또는 미선언으로 표시했다. Windows-1252 전용 문자는 비 윈도우 운영 체제에서 물음표 등으로 잘못 렌더링될 수 있었다. 특히 스마트 따옴표 기능으로 인해 마이크로소프트 워드와 같은 윈도우 응용 프로그램에서 생성된 파일에서 미국-ASCII의 표준 직선 아포스트로피와 따옴표 대신 굴곡 변형인 활자체 따옴표가 사용되는 경우가 많았다.

이러한 문제를 해결하기 위해 2000년까지 대부분의 웹 브라우저와 이메일 클라이언트는 문자 집합 ISO-8859-1과 US-ASCII를 Windows-1252로 취급했다. 이는 현재 HTML5 사양에서 요구되며, HTML에서 미선언된 문자 집합도 Windows-1252로 간주된다.

많은 웹 브라우저와 전자 메일 클라이언트는 MIME charset ISO-8859-1을 Windows-1252로 취급한다. (ISO-8859-1의 여분의 제어 코드는 어차피 HTML에서는 금지되어 있다) 그 때문에 문자 코드가 ISO-8859-1이라고 선언된 웹 페이지에서 종종 Windows-1252의 부호가 발견된다. 그러나 Windows-1252의 문자 사용은, 특히 수신 측이 Linux나 Mac OS 등, Windows 이외의 시스템일 때 곤란이 따를 수 있다. 다른 시스템은 0x80부터 0x9F 범위에 의미 있는 문자를 할당하지 않았을 수도 있고, 다른 독자적인 확장 문자를 할당했을 수도 있다.

4.1. 인코딩/디코딩 예시

리눅스 UTF-8 환경에서 '하천'이 깨져 보이는 예시는 다음과 같다.

👆

좌우로 밀어서 보기

Windows-1252 (CP1252)
	x0	x1	x2	x3	x4	x5	x6	x7	x8	x9	xA	xB	xC	xD	xE	xF
0x	NUL 0	SOH 1	STX 2	ETX 3	EOT 4	ENQ 5	ACK 6	BEL 7	BS 8	TAB 9	LF 10	VT 11	FF 12	CR 13	SO 14	SI 15
1x	DLE 16	DC1 17	DC2 18	DC3 19	DC4 20	NAK 21	SYN 22	ETB 23	CAN 24	EM 25	SUB 26	ESC 27	FS 28	GS 29	RS 30	US 31
2x	SP 32	! 33	" 34	# 35	$ 36	% 37	& 38	' 39	( 40	) 41	* 42	+ 43	, 44	- 45	. 46	/ 47
3x	0 48	1 49	2 50	3 51	4 52	5 53	6 54	7 55	8 56	9 57	: 58	; 59	< 60	= 61	> 62	? 63
4x	@ 64	A 65	B 66	C 67	D 68	E 69	F 70	G 71	H 72	I 73	J 74	K 75	L 76	M 77	N 78	O 79
5x	P 80	Q 81	R 82	S 83	T 84	U 85	V 86	W 87	X 88	Y 89	Z 90	[] 91	\\ 92	[] 93	^ 94	_ 95
6x	` 96	a 97	b 98	c 99	d 100	e 101	f 102	g 103	h 104	i 105	j 106	k 107	l 108	m 109	n 110	o 111
7x	p 112	q 113	r 114	s 115	t 116	u 117	v 118	w 119	x 120	y 121	z 122	{ 123	\| 124	[[중괄호\|}

인코드(encode)	Windows-1252	Ã‡ÃÃƒÂµ
디코드(decode)	utf-8	ÇÏÃµ

디코딩 후 한 번 더 디코딩하는 예시는 다음과 같다.

👆

좌우로 밀어서 보기

인코드(encode)	Windows-1252	ÇÏÃµ
디코드(decode)	euc-kr	하천

5. 관련 인코딩

Windows-1252는 마이크로소프트 윈도우에서 사용되는 코드 페이지로, 코드 페이지 번호 1252와 IANA가 승인한 이름 "windows-1252"로 알려져 있다.

"ANSI 코드 페이지"라는 용어는 윈도우에서 비-DOS 인코딩을 지칭하는 데 사용되었는데, 이 중 대부분은 ISO-8859-1과 같은 ANSI 표준이 되도록 의도되었다. 윈도우-1252는 마이크로소프트 윈도우 용어에서 그렇게 명명된 최초이자 가장 인기 있는 코드 페이지였지만, ANSI 표준이 된 적은 없다. 마이크로소프트는 "윈도우 코드 페이지를 나타내는 데 사용된 ANSI라는 용어는 역사적인 참고 자료이지만, 현재는 윈도우 커뮤니티에서 지속적으로 사용되는 오칭(misnomer)"이라고 설명한다.

LaTeX에서는 매개변수 ansinew(최근에는 cp1252)를 사용하여 윈도우-1252 입력을 지원한다. IBM은 윈도우-1252에 코드 페이지 1252 (CCSID 1252 및 유로 기호 확장 CCSID 5348)를 사용한다. 오라클 데이터베이스에서는 "WE8MSWIN1252"라고 부른다.

1990년대부터 HTML을 생성할 수 있는 많은 마이크로소프트 제품은 Windows-1252 전용 문자를 포함했지만 인코딩을 ISO-8859-1, ASCII 또는 미선언으로 표시했다. Windows-1252 전용 문자는 비 윈도우 운영 체제에서 잘못 렌더링될 수 있었다. 특히, 미국-ASCII의 표준 직선 아포스트로피와 따옴표의 굴곡 변형인 활자사 따옴표는 스마트 따옴표 기능으로 인해 마이크로소프트 워드와 같은 윈도우 응용 프로그램에서 생성된 파일에서 흔히 사용되었으며, 이 기능은 직선 아포스트로피와 따옴표를 굴곡 변형으로 자동 변환할 수 있다. 이를 해결하기 위해 2000년까지 대부분의 웹 브라우저와 이메일 클라이언트는 문자 집합 ISO-8859-1과 US-ASCII를 Windows-1252로 취급했다. 이러한 동작은 현재 HTML5 사양에서 요구된다. HTML에서 미선언된 문자 집합도 Windows-1252로 간주된다.

윈도우 NT는 유니코드를 지원하고 프로그램에서 사용하도록 권장했지만, 다른 멀티바이트 문자 인코딩에 대한 기존 지원에도 불구하고 UCS-2/UTF-16의 16비트 코드 단위만 제공했다. 많은 응용 프로그램이 8비트 문자열을 사용하는 것을 선호했기 때문에, Windows-1252는 UTF-16에 대한 지원을 추가한 후에도 윈도우에서 가장 인기 있는 인코딩으로 남아 있었다. 윈도우의 유니코드 지원은 시간이 지남에 따라 개선되었으며, 윈도우 10부터 UTF-8 지원이 제공되었다.

5.1. ISO/IEC 8859-1

Windows 코드 페이지의 일종이다. LaTeX 패키지에서는 ansinew라고 불린다. 이 문자 코드는 ISO 8859-1의 상위 집합이지만, 0x80부터 0x9F 범위에 제어 문자가 아닌 도형 문자를 수록하고 있다는 점에서 IANA의 ISO-8859-1과 다르다. Windows에서는 코드 페이지 번호 1252 및 IANA 등록명 "windows-1252"로 알려져 있다. 이 코드 페이지는 ISO 8859-15에 포함된 인쇄 가능 문자도 모두 수록하고 있지만, 일부는 다른 코드 포인트에 매핑되어 있다.

ISO 8859-1과 비교하여 추가된 문자는 각종 서양 기호 외에, 프랑스어의 Œ, 핀란드어 등에서 사용되는 Š와 Ž, 유로 기호, ISO 8859-1에서는 소문자만 수록되어 있던 Ÿ가 있다. 이들 문자는 ISO/IEC 8859-15에서도 정의되어 있다.

많은 웹 브라우저가 MIME charset ISO-8859-1을 Windows-1252로 취급하며(ISO-8859-1의 여분의 제어 코드는 어차피 HTML에서는 금지되어 있다), 그 때문에 문자 코드가 ISO-8859-1이라고 선언된 웹 페이지에서 종종 Windows-1252의 부호가 발견된다. 이는 전자 메일 클라이언트에서도 마찬가지이다. 그러나 이러한 문자의 사용은, 특히 수신 측이 Linux나 Mac OS 등, Windows 이외의 시스템일 때 곤란이 따를 수 있다. 다른 시스템은 0x80부터 0x9F 범위에 의미 있는 문자를 할당하지 않았을 수도 있고, 다른 독자적인 확장 문자를 할당했을 수도 있다.

5.2. ISO/IEC 8859-15

Windows-1252는 ISO 8859-15에 포함된 인쇄 가능 문자를 모두 수록하고 있지만, 일부는 다른 코드 포인트에 매핑되어 있다.

ISO 8859-1과 비교하여 추가된 문자는 각종 서양 기호 외에, 프랑스어의 Œ, 핀란드어 등에서 사용되는 Š와 Ž, 유로 기호, ISO 8859-1에서는 소문자만 수록되어 있던 Ÿ가 있다. 이들 문자는 ISO/IEC 8859-15에서도 정의되어 있다.

5.3. 코드 페이지 1004 (OS/2 확장)

OS/2 운영 체제는 코드 페이지 1004 (CCSID 1004) 또는 "Windows Extended"라는 인코딩을 지원한다. 이는 일부 C0 제어 문자가 분음 부호 문자로 대체된 것을 제외하고는 코드 페이지 1252와 거의 일치한다.

👆

좌우로 밀어서 보기

코드 페이지 1004 (다른 행만)
	0	1	2	3	4	5	6	7	8	9	A	B	C	D	E	F
0_	NUL	SOH	STX	ETX	MODIFIER LETTER MACRON^영어	BREVE^영어	DOT ABOVE^영어	BEL	RING ABOVE^영어	HT	DOUBLE ACUTE ACCENT^영어	OGONEK^영어	CARON^영어	CR	SO	SI

5.4. 그래픽 확장 코드 페이지 1252 (MS-DOS 확장)

드물게 사용되지만 유용한 그래픽 확장 코드 페이지 1252는 코드 0x00부터 0x1f까지 MS-DOS 편집기 및 코드뷰와 같은 응용 프로그램에서 사용되는 상자 그리기를 허용한다. 이 코드 페이지를 사용하는 응용 프로그램 중 하나는 1995년 중/후반에 출시된 인텔 코퍼레이션(Intel Corporation)의 설치/복구 디스크 이미지 유틸리티였다. 이 프로그램은 P6 사용자 테스트 프로그램 머신(미국 예시)용으로 작성되었다. 당시 EMEA 지역(유럽, 중동 및 아프리카)에서만 독점적으로 사용되었다. 시간이 지남에 따라 이 프로그램은 코드 페이지 850을 사용하도록 변경되었다.

👆

좌우로 밀어서 보기

0_	1_

5.5. Palm OS 변형

Palm OS는 영어와 프랑스어 등 일부 언어에 대해 Windows-1252를 기반으로 하는 사용자 지정 문자 인코딩을 사용한다. Palm OS 3.1은 Windows-1252와의 호환성을 높이기 위해 몇 가지 변경 사항을 적용했다.

* 특수 Palm OS 글리프 "단축키 획"(0x9D)과 "명령 획"(0x9E)을 0x16과 0x17로 복사하여 로케일 간 일관성을 확보했다. Palm OS 3.3부터는 0x16 및 0x17이 해당 문자의 유일한 코드 포인트이며, 0x9D 및 0x9E는 정의되지 않는다.
* 숫자 공백(0x80)과 수평 줄임표(0x85)를 0x19와 0x18(각각)로 복사하여 로케일 간 일관성을 확보했다.
* 유로 기호를 0x80에 추가하여 이전의 숫자 공백을 대체했다.

다음은 영어 및 기타 여러 로케일에 대해 Palm OS 3.3 이상에서 사용되는 Windows-1252의 변형이다. 파이썬은 이를 `palmos` 레이블로 지정하여 Palm OS 3.5에 대한 인코딩으로 설명한다.

👆

좌우로 밀어서 보기

Palm OS 3.3 문자 인코딩
코드	문자	유니코드	설명
80	€	U+20AC	Palm OS 3.1 이전에는 0x80이 U+2007 숫자 공백, Palm OS 3.1부터는 0x80은 유로 기호, 0x19는 U+2007 숫자 공백.
82	‚	U+201A
83	ƒ	U+0192
84	„	U+201E
85	…	U+2026
86	†	U+2020
87	‡	U+2021
88	ˆ	U+02C6
89	‰	U+2030
8A	Š	U+0160
8B	‹	U+2039
8C	Œ	U+0152
8D	♦	U+2666
8E	♣	U+2663
8F	♥	U+2665
90	♠	U+2660
91	‘	U+2018
92	’	U+2019
93	“	U+201C
94	”	U+201D
95	•	U+2022
96	–	U+2013
97	—	U+2014
98	˜	U+02DC
99	™	U+2122
9A	š	U+0161
9B	›	U+203A
9C	œ	U+0153
9D			Palm OS 3.3 이전에는 "단축키 획", Palm OS 3.3부터는 정의되지 않음.
9E			Palm OS 3.3 이전에는 "명령 획", Palm OS 3.3부터는 정의되지 않음.
9F	Ÿ	U+0178