Proceeding using windows 1252

Опытный

Профиль
Группа: Участник
Сообщений: 392
Регистрация: 30.12.2008

Репутация: нет
Всего: нет

Привет,
При сабмите формы в консоле выскакивает ошибка

mstdmstd	Дата 14.8.2014, 17:11 (ссылка) | (нет голосов) Загрузка .

Цитата

POST http://local-ci22.com/admin/hostel/edit/15 [HTTP/1.1 500 Internal Server Error 23ms] The character encoding of the HTML document was not declared. The document will render with garbled text in some browser configurations if the document contains characters from outside the US-ASCII range. The character encoding of the page must be declared in the document or in the transfer protocol.

В заголовке страницы:

Форма описана как:

[ Время генерации скрипта: 0.0968 ] [ Использовано запросов: 20 ] [ GZIP включён ]

Why is this HTML5 document invalid?

I’m getting pretty confused about an error message I’m getting when I try to validate any simple HTML document without a meta encoding like this:

The W3C validator http://validator.w3.org reluctantly accepts the document as valid with just a few warnings when it is pasted into the direct input form, but when the document is uploaded or loaded by URI, validation fails with this error message

The character encoding was not declared. Proceeding using windows-1252.

There are two things I don’t understand about this error:

• Why is a missing character encoding considered an error, when fallback rules exist?
• Why is the validator assuming windows-1252 instead of UTF-8, like any browser would?

Can someone explain these two points please? I’m pretty new to this stuff, so please bear with me.

4 Answers 4

Well, it depends on what you are using.

• if you are using the File Upload option, it depends on which encoding the HTML file was saved with.
• if you are using the Direct Input option, it depends on the navigator.

If you don’t want the validator to guess, and use UTF-8, you can add the following line

It is the «Direct Input» mode of the validator that defaults to UTF-8. User-agents (browsers) will default to other encodings based on a number of things:

If a user agent reads a document with no character encoding information, it can fall back to using some other information. For example, it can rely on the user’s settings, either browser-wide or specific for a given document, or it can pick a default encoding based on the user’s language. For Western European languages, it is typical and fairly safe to assume Windows-1252, which is similar to ISO-8859-1 but has printable characters in place of some control codes.

W3C validator said:

The validator checked your document with an experimental feature: HTML5 Conformance Checker. This feature has been made available for your convenience, but be aware that it may be unreliable, or not perfectly up to date with the latest development of some cutting-edge technologies.

So take some results with a pinch of salt.

Also, there is no useful ‘fall back’, the validator just needs to pick something/anything so it can try to validate for you. W3C can’t determine/decide what encoding you want/need to use. You must declare it yourself based on what characters you need to serve on your web page(s), and then ask W3C to validate your document based on that.

What editor/WYSIWYG are you using to make web pages? Can we have the URL you are trying to validate?

When you use Validate by URI, the server is supposed to announce the character encoding in HTTP headers, more exactly in the charset parameter of the Content-Type header value. In this case, this apparently does not happen. You can check the situation e.g. using Rex Swain’s HTTP Viewer.

According to clause 4.2.5.5 Specifying the document’s character encoding in HTML5 CR, “If an HTML document does not start with a BOM, and its encoding is not explicitly given by Content-Type metadata, and the document is not an iframe srcdoc document, then the character encoding used must be an ASCII-compatible character encoding, and the encoding must be specified using a meta element with a charset attribute or a meta element with an http-equiv attribute in the Encoding declaration state.” This is a bit complicated, but the bottom line is: there are several ways to declare the encoding, but if none of them is used, the document is non-conforming.

Why it specifies so is somewhat speculative, but the general idea is that such rules promote reliability and robustness. When the rule is not obeyed, different browsers may use different defaults or guesswork.

The validator assumes windows-1252, because that’s what HTML5 rules lead to. The processing rules are in 8.2.2.1 Determining the character encoding. They are fairly complicated, but they largely reflect the way modern browsers do (and aims at making it a standard). The rules there are meant to deal with non-conforming documents, too, but this does not make those documents conforming; error processing rules are not really “fallbacks” and should not be relied on, especially since old browsers do not always play by the rules.

The error rules get somewhat loose when it comes to a situation where everything else fails and an “implementation-defined or user-specified default character encoding” is to be used. There are just “suggestions” on what browsers might do (again, reflecting what modern browsers generally do), and this may involve using the “user’s locale”, an obscure concept. The validator uses windows-1252 then, perhaps because that’s the default for English and the validator “speaks” English, or maybe just because it’s the guess that is expected to be correct more often than any other single alternative.

Окна-1252 — Windows-1252

Окна-1252

Windows-1252 или CP-1252 ( кодовая страница 1252) является однобайтная кодировка символов в латинице , используемой по умолчанию в старых компонентов Microsoft Windows на английском и многих европейских языках , включая испанский, французский и немецкий языки.

Это наиболее часто используемая кодировка однобайтовых символов в мире. По состоянию на март 2021 года 0,3% всех веб-сайтов заявили об использовании Windows-1252, но в то же время 1,4% использовали ISO 8859-1 (в то время как только 0,8% веб-сайтов из топ-1000), что по стандартам HTML5 следует считать та же кодировка, так что 1,7% веб-сайтов эффективно используют Windows-1252. Страницы, объявленные как US- ASCII , также будут считаться этим набором символов. Неизвестное (но, вероятно, большое) подмножество других страниц использует только часть ASCII UTF-8 или только коды, соответствующие Windows-1252 из их объявленного набора символов, и также может быть подсчитано.

В зависимости от страны использование может быть намного выше, чем в среднем в мире, например, для Германии (включая ISO-8859-1) на 6,4%.

СОДЕРЖАНИЕ

Подробности

Эта кодировка символов является подмножеством из ISO 8859-1 в терминах печатаемых символов, но отличается от IANA по ISO-8859-1 с помощью отображаемых символов , а не управляющие символы в 80-9F ( шестнадцатеричный ) диапазоне. Примечательные дополнительные символы включают фигурные кавычки и все печатаемые символы, которые находятся в ISO 8859-15 (в местах, отличных от ISO 8859-15). Он известен Windows по номеру кодовой страницы 1252 и по утвержденному IANA названию «windows-1252».

Очень часто неправильно маркировать текст Windows-1252 меткой кодировки ISO-8859-1. Обычным результатом было то, что все кавычки и апострофы (созданные с помощью «умных кавычек» в текстовых редакторах) были заменены вопросительными знаками или квадратами в операционных системах, отличных от Windows, что затрудняло чтение текста. Большинство современных веб-браузеров и клиентов электронной почты обрабатывают кодировку типа мультимедиа ISO-8859-1 как Windows-1252, чтобы учесть такую ​​неправильную маркировку. Теперь это стандартное поведение в спецификации HTML5, которое требует, чтобы документы, рекламируемые как ISO-8859-1, фактически анализировались с кодировкой Windows-1252.

Исторически фраза «Кодовая страница ANSI» использовалась в Windows для обозначения кодировок, отличных от DOS; Предполагалось, что большинство из них будут стандартами ANSI, такими как ISO-8859-1 . Хотя Windows-1252 была первой и, безусловно, самой популярной кодовой страницей, названной так на языке Microsoft Windows, кодовая страница никогда не была стандартом ANSI. Microsoft объясняет: «Термин ANSI, используемый для обозначения кодовых страниц Windows, является исторической справкой, но в настоящее время это неправильное название, которое продолжает сохраняться в сообществе Windows».

В пакетах LaTeX CP-1252 упоминается как «ответный».

IBM использует кодовую страницу 1252 ( CCSID 1252 и расширенный CCSID 5348 для знака евро ) для Windows-1252.

В Oracle он называется WE8MSWIN1252 .

Набор символов

В следующей таблице показан Windows-1252. Каждый символ отображается с его эквивалентом в Юникоде на основе сопоставления Unicode.org Windows-1252 с «наилучшим соответствием». Десятичные числа (в стиле 0123 ) представляют собой альтернативный код, который можно использовать для их ввода в системах Windows. Отличия от ISO-8859-1 показаны более темным оттенком поверх цветов легенды.

MIME / IANA	окна-1252
Язык (и)	В основном все поддерживается ISO / IEC 8859-1, например, английский , ирландский, итальянский, норвежский, португальский, испанский, шведский. Плюс еще немецкий, финский, исландский и французский. И голландский, кроме символа. И словенский, кроме символа č .
Создано	Microsoft
Стандарт	Стандарт кодирования WHATWG
Классификация	расширенный ASCII , Windows-125x
Расширяется	ISO 8859-1 (кроме элементов управления C1)
Преобразует / кодирует	ISO 8859-15

Окна-1252 (CP1252)

_0	_1	_2	_3	_4	_5	_6	_7	_8	_9	_A	_B	_C	_D	_E	_F
0_ 0	NUL 0000 0	SOH 0001 01	STX 0002 02	ETX 0003 03	EOT 0004 04	ENQ 0005 05	ACK 0006 06	БЕЛ 0007 07	BS 0008 08	HT 0009 09	LF 000A 010	ВТ 000Б 011	FF 000C 012	CR 000D 013	SO 000E 014	SI 000F 015
1_ 16	DLE 0010 016	DC1 0011 017	DC2 0012 018	DC3 0013 019	DC4 0014 020	NAK 0015 021	SYN 0016 022	ETB 0017 023	CAN 0018 +024	EM 0019 025	SUB 001A 026	ESC 001B 027	FS 001C 028	GS 001D 029	RS 001E 030	США 001F 031
2_ 32	SP 0020 32	! 0021 33	« 0022 34	# 0023 35	$ 0024 36	% 0025 37	& 0026 38	‘ 0027 39	( 0028 40	) 0029 41	* 002A 42	+ 002B 43	, 002C 44	— 002D 45	. 002E 46	/ 002F 47
3_ 48	0 0030 48	1 0031 49	2 0032 50	3 0033 51	4 0034 52	5 0035 53	6 0036 54	7 0037 55	8 0038 56	9 0039 57	: 003A 58	; 003B 59	003C 60	= 003D 61	> 003E 62	? 003F 63
4_ 64	@ 0040 64	A 0041 65	В 0042 66	С 0043 67	D 0044 68	E 0045 69	F 0046 70	G 0047 71	В 0048 72	Я 0049 73	J 004A 74	К 004В 75	L 004C 76	M 004D 77	№ 004E 78	O 004F 79
5_ 80	П 0050 80	Q 0051 81	R 0052 82	С 0053 83	Т 0054 84	U 0055 85	V 0056 86	W 0057 87	X 0058 88	Y 0059 89	Z 005A 90	[ 005B 91	\ 005C 92	] 005D 93	^ 005E 94	_ 005F 95
6_ 96	` 0060 96	а 0061 97	b 0062 98	c 0063 99	d 0064 100	e 0065 101	f 0066 102	г 0067 103	h 0068 104	я 0069 105	j 006A 106	k 006B 107	l 006C 108	м 006D 109	№ 006E 110	o 006F 111
7_ 112	п 0070 112	в 0071 113	р 0072 114	с 0073 115	т 0074 116	u 0075 117	v 0076 118	ж 0077 119	х 0078 120	г 0079 121	z 007A 122	< 007B 123	| 007C 124	> 007D 125	007E 126	DEL 007F 0127
8_ 128	€ 20AC 0128	‚ 201A 0130	ƒ 0192 0131	„ 201E 0132	… 2026 0133	† 2020 0134	‡ 2021 0135	02C6 0136	‰ 2030 0137	Š 0160 0138	‹ 2039 0139	Œ 0152 0140	Ž 017D 0142
9_ 144	‘ 2018 0145	‘ 2019 0146	« 201C 0147	” 201D 0148	• 2022 0149	— 2013 0150	— 2014 0151	˜ 02DC 0152	™ 2122 0153	š 0161 0154	› 203A 0155	œ 0153 0156	ž 017E 0158	Ÿ 0178 0159
A_ 160	NBSP 00A0 0160	¡ 00A1 0161	¢ 00A2 0162	£ 00A3 0163	¤ 00A4 0164	¥ 00A5 0165	¦ 00A6 0166	§ 00A7 0167	¨ 00A8 0168	© 00A9 0169	ª 00AA 0170	« 00AB 0171	¬ 00AC 0172	SHY 00AD 0173	® 00AE 0174	¯ 00AF 0175
B_ 176	° 00B0 0176	± 00B1 0177	² 00B2 0178	³ 00B3 0179	´ 00B4 0180	µ 00B5 0181	¶ 00B6 0182	· 00B7 0183	¸ 00B8 0184	¹ 00B9 0185	º 00BA 0186	» 00BB 0187	¼ 00BC 0188	½ 00BD 0189	¾ 00BE 0190	¿ 00BF 0191
C_ 192	À 00C0 0192	Á 00C1 0193	Â 00C2 0194	Ã 00C3 0195	Ä 00C4 0196	Å 00C5 0197	Æ 00C6 0198	Ç 00C7 0199	È 00C8 0200	É 00C9 0201	Ê 00CA 0202	Ë 00CB 0203	Ì 00CC 0204	Í 00CD 0205	Î 00CE 0206	Ï 00CF 0207
D_ 208	Ð 00D0 0208	Ñ 00D1 0209	Ò 00D2 0210	Ó 00D3 0211	Ô 00D4 0212	Õ 00D5 0213	Ö 00D6 0214	× 00D7 0215	Ø 00D8 0216	Ù 00D9 0217	Ú 00DA 0218	Û 00DB 0219	Ü 00DC 0220	Ý 00DD 0221	Þ 00DE 0222	ß 00DF 0223
E_ 224	à 00E0 0224	á 00E1 0225	№ 00E2 0226	ã 00E3 0227	ä 00E4 0228	å 00E5 0229	æ 00E6 0230	ç 00E7 0231	è 00E8 0232	é 00E9 0233	ê 00EA 0234	ë 00EB 0235	ì 00EC 0236	№ 00ED 0237	î 00EE 0238	• 00EF 0239
F_ 240	ð 00F0 0240	ñ 00F1 0241	ò 00F2 0242	ó 00F3 0243	ô 00F4 0244	х 00F5 0245	ö 00F6 0246	÷ 00F7 0247	ø 00F8 0248	ù 00F9 0249	ú 00FA 0250	û 00FB 0251	ü 00FC 0252	ý 00FD 0253	þ 00FE 0254	ÿ 00FF 0255

Письмо Число Пунктуация Символ Другой Неопределенный

Согласно информации на сайтах Microsoft и Консорциума Unicode позиции 81, 8D, 8F, 90 и 9D не используются; однако Windows API MultiByteToWideChar сопоставляет их с соответствующими управляющими кодами C1 . Отображение «наилучшего соответствия» также документирует это поведение.

История

• В первой версии кодовой страницы 1252, используемой в Microsoft Windows 1.0, не были определены позиции D7 и F7. Все символы в диапазонах 80–9F также не были определены.
• Для второй версии, используемой в Microsoft Windows 2.0, были определены позиции D7, F7, 91 и 92.
• В третьей версии, используемой с Microsoft Windows 3.1, были определены все современные позиции, кроме знака евро и Z с парой символов caron .
• Последняя версия, указанная выше, дебютировала в Microsoft Windows 98 и была перенесена на более старые версии Windows с обновлением символа евро.

Расширения OS / 2

OS / 2 Операционная система поддерживает кодировку по имени кода страницы 1004 ( CCSID 1004) или «Windows Extended». Это в основном соответствует кодовой странице 1252, за исключением некоторых управляющих символов C0 , замененных диакритическими символами. Отличия от ISO-8859-1 показаны более темным оттенком поверх цветов легенды.

Кодовая страница 1004 (только разные строки)

_0	_1	_2	_3	_4	_5	_6	_7	_8	_9	_A	_B	_C	_D	_E	_F
0_ 0	NUL 0000	SOH 0001	STX 0002	ETX 0003	ˉ 02C9	˘ 02D8	˙ 02D9	BEL 0007	˚ 02DA	HT 0009	˝ 02DD	˛ 02DB	02C7	CR 000D	SO 000E	SI 000F

Расширения MSDOS [редко]

Существует редко используемая, но полезная графическая расширенная кодовая страница 1252, где коды от 0x00 до 0x1f позволяют рисовать блоки, как это используется в таких приложениях, как MSDOS Edit и Codeview. Одним из приложений, использующих эту кодовую страницу, была утилита для установки / восстановления образа диска корпорации Intel, выпущенная в середине / конце 1995 года. Эти программы были написаны для компьютеров с пользовательской тестовой программой P6 (пример для США). Он использовался исключительно в тогдашнем регионе EMEA (Европа, Ближний Восток и Африка). Со временем программы были изменены, чтобы использовать кодовую страницу 850.