UTF8, ISO-8859-x или 7-битный ASCII и сущности

Question

Что вы думаете о кодировании акцентированных и специальных символов в XHTML и XML.

• Преобразуете ли вы каждый не-US-ASCII символ в именованный объект?
• Вы используете ISO-8859-x или Win-125x и кодируете в сущности что-нибудь еще?
• Или вы прямо все пишете в UTF-8, не заботясь о сущностях?

Пожалуйста, уточните, на что и почему .

Answer 1

Я не могу точно сказать, почему это происходит, но в моем 5-летнем опыте использования UTF-8 для каждой веб-страницы (я в основном использую символы кириллицы и балтики), я еще не видел ни одного отображаемого неправильно символа.

Answer 2

UTF-8.

Он был разработан именно с целью решения проблем, которые упоминаются в UTF-16, и делает это фантастически. Сегодня практически каждый редактор (включая Блокнот) поддерживает UTF-8, а также является кодировкой по умолчанию для XML.

Answer 3

Не связывайтесь с именованными сущностями. Они хороши для случаев, когда вам нужно вручную редактировать HTML-файлы и иметь возможность читать символы, и у них нет редактора UTF-8. Но в остальном UTF-8 - это путь.

Answer 4

Я всегда пишу непосредственно в utf8. Единственной проблемой, с которой я столкнулся в этот период, был сервер, который заставлял iso-кодирование заголовков.

Answer 5

Всегда используйте UTF-8 для своего сайта

1. Нет возражений / проблем в поддержке UTF-8 современными платформами и серверами баз данных.

2. Вы избежите проблем, когда кто-то поместит текст на языке, отличном от ожидаемого, и вы получите ?????? вместо некоторых символов Юникода или еще хуже, когда шаблон страницы даже не отображается.

3. Даже если ваш сайт переведен на один язык без многоязычного интерфейса (в будущем также), кто-то может опубликовать на вашем сайте материалы и получить комментарии от своих друзей на своем родном языке.

С уважением, Павел

Answer 6

Первые 128 символов Unicode совместимы с ASCII. Текст, написанный с этими 128 символами, является действительным документом ASCII и UTF-8. Юникод является стандартом и должен использоваться всеми. Носители английского языка не увидят разницы, но не англоговорящие. Лично я очень разочарован программным обеспечением и его создателями, если оно не может правильно хранить и отображать даже мою фамилию.

Я также должен заметить, что кодировка символов - это только первая из целого ряда проблем, связанных с интернализацией. Это особенно заметно в небольших программных продуктах, которые обычно не предназначены для решения различных проблем, связанных с грамматикой не на английском языке.

Answer 7

Если я работаю над веб-сайтом, главным образом, в пространстве ASCII (английский, большинство романских языков), я преобразую все, что не ASCII, в именованные или пронумерованные объекты. Это позволяет мне или другим людям без соответствующих шрифтов работать над этим. Это может показаться маловероятным, но однажды вы в конечном итоге будете использовать какой-то богом забытый терминал через SSH, который не поддерживает UTF-8, и даже если это произойдет, в хост-системе не будут установлены нужные шрифты.

Если я пишу текст, который в основном отсутствует в ASCII, я буду использовать UTF-8. Если текст - это все сущности, которые так или иначе не читаются как блоки замены Юникода.

Answer 8

Я лично всегда использую UTF-8. Он хорошо поддерживается, и каждый язык, ОС и браузер так или иначе поддерживают его. Сущности хороши для отображения, но они являются болью в шее для редактирования. Именованные объекты могут ссылаться на множество символов, но будут охватывать только случайные наборы символов. Для азиатских языков вам придется вернуться к шестнадцатеричным сущностям, и это не очень красиво. Шестнадцатеричные сущности также должны быть в любом случае декодированы или закодированы с использованием таблиц Unicode, так что вы можете использовать кодировку Unicode для кодирования текста в первую очередь.

Если ваша основная аудитория - англичанка, вы можете подумать, что можете избавиться от ISO-8859-1 или cp1252, но это будет ошибкой. Рано или поздно кто-нибудь напишет ударные или другие иностранные символы, и когда это произойдет, уже слишком поздно исправлять вашу кодировку: какой-то текст уже испорчен.

Вот еще несколько статей, которые избавили меня от головной боли при игре с кодировками:

Каждый разработчик программного обеспечения должен абсолютно точно знать о юникоде и наборах символов (без оправданий!) Подробное введение в наборы символов, их использование и различия от joelonsoftware.com. Информация там довольно общая, но полезна, чтобы помочь выяснить, какую кодировку выбрать.

Наборы символов из браузера в базу данных - это очень практичная и прагматичная статья от SUN, в которой много говорится о различных местах, где вы должны убедиться, что ваша кодировка не преобразована во что-то еще.

Что такое UTF-8 и почему это важно? - это еще одна статья SUN, которая углубляется в тонкость UTF-8 и должна иметь возможность ответить на любой вопрос, который у вас есть на подробности о UTF-8 после прочтения первых двух статей.

Answer 9

Говоря с американской точки зрения: там, где почти весь текст является US-ASCII, с несколькими символами и акцентированными символами, я настоятельно рекомендую использовать числовые или именованные объекты.

Причина проста: беспокоиться не о чем. Вам не нужно гарантировать, что ваш веб-сервер настроен на рекламу той же кодировки, что и ваш контент. Потому что рано или поздно вы получите кого-то, редактирующего страницы в Windows, используя кодировку Cp1252, и кто-то еще работающий в Linux с ISO-8859, и хотя они близки, они не одинаковы. И если веб-сервер настроен как UTF-8, они оба сломаны.

Тем не менее, я дал Сергею +1, потому что вам не нужна масса сущностей, если вы работаете с текстом, который не является в основном ASCII.