Предлагаю уточнить формулировку: кодировка настоящего, а не будущего. Будущее без нее не наступит :)

Простые факты для тех, кто знает, что русский и английский языки не единственные в мире. И еще для тех, кто любит красивый текст.

№1. Кодировка utf-8 позволяет не опасаться за слом???????ный текст, битые

ну вот видите - win1251 и все обрезалось :(

Вот статья, где просто и доходчиво объяснено, что любой программист должен знать о различных кодировках и особенно Unicode:
http://www.joelonsoftware.com/articles/Unicode.html

Ещё полезно читать википедию:
http://en.wikipedia.org/wiki/Utf-8

Вот интересная библиотечка:
Правда, я сомневаюсь, что в ней есть utf8-аналог preg_replace()...
http://sourceforge.net/projects/phputf8/

А есть ли utf8-плагин для редактора far'а?

Юлик Тарханов популярно и однозначно высказывается о юникоде и utf-8: http://live.julik.nl/unicode

(Там же: как лечили и вылечили юникод в Ruby on Rails.)

Вторая, после Джоэля, must-have статья о тексте, клавишах и юникоде:
Юкка Корпела, http://www.cs.tut.fi/~jkorpela/chars.html (english)

Клуб любителей паровозов я, правда, уже покинул, и этот, наверно, вскоре оставлю. Но я не мог не признаться в любви кодировке UTF-8. О, божественная кодировка UTF-8! Как совершенна твоя раскладка! Как прекрасны твои символы! Разве могут жалкие win-1251 или koi8 уподобиться тебе!

Мне понятен ваш сарказм. Но жизнь такова, что вокруг куча говнософта и глупых инженеров. Да еще и китайцы с японцами обороняют свою ShiftJIS.
В школе на информатике мне про текст не рассказывали, равно как и в институте. Приходится самим выкручиваться.

Занятно - сайт www.gost.ru сейчас использует utf-8, а не windows-1251, как раньше.
Мне вспоминается, как нам как-то пришлось в одном программном проекте использовать одновременно cp866, windows-1251 и koi8-r - потому что сервер под unix, клиент под windows, и вообще все запущенно...
Поетому я и предлагаю внедрять везде utf-8, а остальные кодировки запретить.

Насчет китайцев, корейцев и японцев (CJK). В юникоде придумали унифицировать идеографы из упомянутых культур таким образом, что похожие по смыслу или начертанию символы получают один номер (code-point), когда в кодировке Shift-JIS - это разные символы. Можно догадаться, что нашлись активные протестующие против унификации, причем, довольно уважаемые люди. Причем не менее уважаемые люди с пеной у рта борятся за унификацию.

Активная борьба между Unicode и классическими CJK-кодировками затормаживает победное шествие utf-8 по планете.
Читайте подробности на Википедии:
http://en.wikipedia.org/wiki/Han_unification

По поводу запрета кодировок. Некоторые разработчики уже выработали правило:
1. Хранить, обрабатывать и выдавать информацию только в UTF-8
2. Принимать в UTF-8 и, при необходимости, декодировать из других кодировок.

Проблема-то не в этом, а в том, что приходится взаимодействовать с другими программами и операционной системой. А в windows с utf-8 все не слишком здорово. Да и в UN*X'ах не фонтан...

В Win32API, Java и C-sharp используется Юникод, но в виде UCS-2/UTF-16 (видимо, решили, что так будет удобнее). Обратите внимание, что UTF-16 не гарантирует двухбайтовость всех символов (более 90000 просто не поместятся). Поэтому существуют комбинированные символы, состоящие из двух пар обычных, т.е. длиной 4 байта.

В UTF-8 символы комбинированные изначально (1-, 2-, 3-байтовые и больше), но зато нет проблемы с неоднозначностью порядка прочтения пары байт (big-endian vs. little-endian) и, как бонус, 7-битный ASCII является подмножеством UTF-8.

Я про юниксы знаю, только то, что там гнилой кои-8 и что многие разработчики девелоперского софта клали на кодировки вообще. Вспомнить, хотя бы инструкцию по установке клавиатурной раскладки с русскими буквами под FreeBSD 5.6.

Утешает, что Mac OS X использует везде нативный юникод (хотя и utf-16, если не ошибаюсь).

Статьи о кодировках в Java:
http://skipy.dev.juga.ru/technics/encodings.html
http://skipy.dev.juga.ru/technics/encodings_webapp.html
Может кому пригодятся? Начальное понимание они дают неплохо.

Думаю, понимание проблемы big-endian/little-endian ухудшается тем, что пишущие слева на право, цифры пишут справа на лево (по-арабски). Никогда не задумывались?
Для арабских языков, идиша и еврита "1234" идет в нормальном порядке - по возрастанию разрядов. Нам же нужно сосчитать количество цифр, разбить на тройки и только после этого прочитать.

тут скорее дело в удобстве: число располагается по убыванию значимости цифр.

Олег, как заставить прототайр работать при правильной кодировке? :) спасибо.

2 Алексей:
Прототайп ни при чем. Проверьте, что ваш php-скрипт возращает текст в UTF-8, и HTML-страничка тоже в UTF-8. Тогда все будет ок.
Если вы хотите другую кодировку, то она должна быть одна и та же везде.

В чем у вас конкретно проблема?

Это не сарказм, это ирония :)
ютф я вполне даже уважаю :yes:

в пхп фаиле, который я запрашиваю использую прототайп, у меня написано echo "превед медведъ"; вот этот текст приходит в левой кодировке. я все попробывал, не получается поправить :(

Еще раз:
1) В какой кодировке php-файл?
2) В какой кодировке HTML?
3) Прописан ли <meta http-equiv="content-type" content="text/html; charset=ВАША_КОДИРОВКА" /> ?

я пробовал по разному, и прописывал утф-8 и 1251, и просто ничего не писал. все равно ничего не получилось. мне кажется, что это прототайп глючит с кодировкой.

Помнится, при реализации AJAX'а на этом сайте в какой-то момент пришлось встраивать свою php-функцию для перекодирования utf-8 в windows-1251. Или наоборот...
Хотя, конечно же, есть определенная разница - здесь в заголовке страниц прописана кодировка windows-1251.

Еще раз спрашиваю: что получается на выходе? Скриншот, файлы скриптов пришлите. Я уверен, что проблема ерундовая.

И это точно не прототайп, так как его дело просто передать информацию. Он конвертированием или интерпретацией текста не занимается, уж поверьте.

В чем преимущества UTF-8?

Преимущества utf-8:

0. Это международный промышленный стандарт
1. Кодирует все символы на свете
2. Нет неоднозначностей (как BE/LE в UTF-16)
3. Позволяет быстро находить строки в произвольной части текста
4. Легко распознается эвристически
5. Компактнее UTF-7, UTF-16, UTF-32
6. Является надмножеством ASCII (чистый, 7-битный ASCII - это тоже UTF-8)

А чем отличаются UTF-7,8,16,32?

1. UTF-7 - это дикобраз, призванный соответствовать набору ASCII (младшие 7 бит). Небольшая часть символов передается как есть, еще небольшая часть хитро кодируется эскейп-последовательностями, а остальные тысячи символов - это UTF-16, закодированный в base-64. Эта кодировка сейчас очень редко используется.

2. UTF-32 кодирует каждый символ 4-мя байтами, которых хватит на 4 млрд символов. Пока в базе юникода около 100 тысяч. UTF-32 почти не используется в виду своего размера.

3. UTF-16 кодирует часть символов 2-мя байтами, а, те, что не помещаются - 4-мя. Популярная кодировка, но имеет проблемы: если текст появился незнамо откуда (или промежуточный модуль обрезал какие-нибудь пробельные символы), то может случиться так, что будет перепутан порядок байт (BE vs. LE) и текст будет декодирован неверно. Маркер вида кодировки (BE/LE) - это символ "неразрывный пробел" в начале текста. Если его вырезать, вы не поймете что ж там был за текст.

UTF-8 лучше UTF-16 и UTF-32 тем, что она не бинарная (используются более-менее печатные символы в смысле однобайтовых codepages), следовательно можно с высокой вероятностью её угадать. Нет проблем с порядком байт, он задан жестко.

Есть еще utf-1, но она медленно кодируется и текст нельзя читать с середины (в отличие от всех вышеперечисленных).

Как перевести приложение на UTF-8, что нужно для этого на стороне сервера и на стороне клиента? Какие сложности работы чистого ajax (не prototype, а прямо через api) с utf-8?

Приложение, в смысле, php-движок, например.

1. Перевести все исходники в utf-8 (.php, .html, .js). Конвертировать с помощью iconv или любого другого инструмента (которому можно доверять).
2. Перевести таблицы БД на utf-8. Как сделать это в MySQL:
1) Выставить в свойствах самой БД, каждой таблицы и всех текстовых полей utf-8.
2) Уже существующие данные сконвертировать в utf-8. См. http://dev.mysql.com/doc/refman/5.0/en/charset-conve...

В каком порядке проделать эти два шага - зависит от объема данных. Лучше всего сделать вторую БД с теми же таблицами, но с utf-8 полями. И несколькими sql-запросами скопировать данные из старой БД в новую с конверсией (см. ссылку). Если данных очень много, то нужно конвертировать на месте, но я такими извращениями еще не занимался. До или после ALTER TABLE tablename charset='utf8'; по-моему, все равно.

Насчет аякса. Сложностей быть не должно, т.к. известные мне нормальные библиотеки (prototype.js и jQuery) с текстом ничего дурного не делают.
JSHttpRequest в этом смысле отличается истинно русской нелюбовью к стандартам. Как избежать проблем написал сам Дима Котеров: http://dklab.ru/lib/JsHttpRequest/#cont12 (раздел про кодировки). Еще смотрите в гугле "JSHttpRequest utf-8 проблема".

Не доверяйте либам, сайты или исходники которых не в utf-8. Если текст все-таки ломается, проверьте форматтеры, rich-text-editor-ы и прочие процессоры. По большому счету, если вы вообще не преобразуете текст, то вам (с некоторыми допущениями) все равно, в какой он кодировке.

Результаты конверсий регулярно проверять hex-viewer-ом на вшивость.
И забудьте о windows-1251, как о кошмарном сне :)

По теме: как вчера переводили Trac dev.rubyonrails.org на utf-8:

Jeremy K. - I'm taking Trac down for a bit to convert to UTF-8
8:20 PM
Jeremy K. - back up
Marcel M. - thanks Jeremy
Jeremy K. - np it wasn't as bad as it looked
Jeremy K. - pg_dump trac | iconv -f 8859-1 -t utf-8 - | psql trac_utf8
Jeremy K. - looking that shit up took an hour though :p

http://project.ioni.st/post/1036#post-1036

Спасибо за ответы. Возможно глупый вопрос, но все версии php интерпретируют php код в кодировке utf-8?

Для php сам код в utf-8 - это код в ASCII 40-летней давности (т.е. младшие 7 бит). Почему это так, читайте ниже и в доках по синтаксису ПХП.

А комментарии и строковые литералы с произвольным текстом ASCII-байт не содержат (т.е. не может получится так, что внутри буквы Зю будет байт "обратный-слеш" или "нуль-терминатор", который будет неправильно истолкован парсером).

Совместимость с ASCII, о которой я говорил, придумана для того, чтобы любые исходные коды в utf-8 остались полностью рабочими и в старых, и новых системах.

Пардон, ПХП парсер - редкостное дерьмо, оказывается.

В доках сказано, что идентификаторы (имена переменных) могут содержать и некоторые старшие байты: [0-9a-zA-Z_\x7f-\xff] (внимание на 7F..FF: это от байта 0111.1111 и до упора).
Типа, в каком-нибудь кириллическом code-page вы можете назвать переменную $по_русски.

При перекодировании в utf-8 русские буквы станут двухбайтовые: 110x.xxxx.10xx.xxxx. И код все равно останется рабочим.

Хотя, советую писать и документировать код по-английски.

Как я уже где-то говорил, если взять все исходники скриптов и сконвертировать в utf8, почти все будет работать, за исключением кода, использующего регулярные выражения с русскими буквами, поскольку регулярное выражение /[аеия]/ перестанет означать то, что оно означало. Так что не так все и просто...

Точно, у ПХП с регэкспами все туго. Там нет юникод-модификатора? Я нашел только спец-символы \p{xx}.

Кстати, а что за заморочка с AJAX'ом и кодировками? У меня такая проблема - я могу получить из php скрипта ответ в любой кодировке, а вот отправлять.. в какой не отправляй (читай прописывай в хттп заголовок) все равно php скрипт получает текст в utf-8?

Прописывание в хттп-заголовке и реальная кодировка, в которой летит текст - разные вещи. Как правило, если страница пришла пользователю в utf-8, то форму он заполняет тоже в utf-8.

Эксплорер (какой версии - не знаю) может поступить так: если ты вводишь в форму текст, который не ложится на ту кодировку, в которой пришла страница, то вся форма отсылается в utf-8. Например, прислал в iso-8859-1, а пишешь по-русски. Эксплорер сохранит содержимое формы в utf-8.

Если ты используешь JSHttpRequest, то он кодирует строки в юникод-формате %uXXXX по-любому.
http://dklab.ru/lib/JsHttpRequest/#cont12

Советую переехать на utf-8 вместо того, чтобы расставлять кривые костыли.

Пасиб. Я в общем то думал над этим вопросом. просто у меня скрипт должен распознавать заголовки (title) различных сайтов и отображать их. И они все ясное дело в разных кодировках. Приходится переводить. Ну а большинство пока как ни прискорбно использует windows-1251 чем и мне приходится заниматься.

Если кодировку не указывают или указывают неверно, нужно угадывать. Для русскоязычных текстов это делать несложно.

Кто-нибудь может компетентно объяснить, нахрена в UTF-8 BOM?

Ответы вроде: он маркирует то, что это юникод мне не нравятся :)
Нигде до этого кодировка не указывалась и жили нормально.
А то иногда этот BOM приводит к весьма интересному времяпрепровождению. Олег знает =)

In order to allow the automatic detection of the byte order, it has become customary on some platforms (notably Win32) to start every Unicode file with the character U+FEFF (ZERO WIDTH NO-BREAK SPACE), also known as the Byte-Order Mark (BOM). Its byte-swapped equivalent U FFFE is not a valid Unicode character, therefore it helps to unambiguously distinguish the Bigendian and Littleendian variants of UTF-16 and UTF-32.

//utf-8.com

хм.. я надеюсь не один считаю, что это была плохая затея? :)

Для определения "в потоке", что поток - UTF-8. Но хорошие ребята информацию о кодировке хранят в заголовках протоколов, а не портят пользовательские данные.

Из википедии:

While UTF-8 does not have byte order issues, a BOM encoded in UTF-8 may be used to mark text as UTF-8. Quite a lot of Windows software (including Windows Notepad) adds one to UTF-8 files. However in Unix-like systems (which make heavy use of text files for configuration) this practice is not recommended, as it will interfere with correct processing of important codes such as the hash-bang at the start of an interpreted script. It may also interfere with source for programming languages that don't recognise it.

Т.е. в винде любят втыкать BOM почем зря, а в юниксах не любят, т.к. там все сломается нахрен, а мы потом будем искать источник проблемы два часа.

Выводы:
1. Винду - нах.
2. Все кодировки, кроме UTF-8 - нах.
3. BOM - нах.
4. Тупых программистов - на кол.

UTF полюбил когда начал ковырятся с Аяксом! Хвала и почет этой кодировке и мега-зач()t !!! =)

Обычно, ковыряясь с аяксом, 1251-народ ненавидит utf-8 :)

чё-т нифига не понял пост. знаки припинания наверное нужно расставить =) аля "казнить нельзя помиловать"

17 апреля на конференции Российские Интернет Технологии (РИТ-2007), в Москве я рассказываю о кодировках вообще и UTF-8 в частности.

Программка:
http://www.rit2007.ru/files/RIT-2007-timesheet.pdf

Будете в Москве - заходите (регистрация - 5000 руб.) Материалы доклада будут выложены в открытый доступ как только так сразу.

(16 апреля, там же, я рассказываю о Ruby on Rails)

Если получится посещу твою секцию ;)

Как известно, xmpp использует только utf-8, по каковой причине предлагаю администрации добавить в дружественные группы таковую о Jabber (club32075)
И ещё было бы неплохо картинку какую-нибудь группе приклепать. Скажем, просто понатыкать на белый фон букв разных алфавитов (-:Е
А то как-то безлико...

Открылся клуб, посвященный Python:
club26227
Группа 'utf-8', естественно, во френдах.

Кто-то спрашивал зачем нужен BOM (Byte of Order Mark). Поясняю. Существует стандарт кодирования UTF-8 символов UCS (Unicode). Для символов, не попадающих в первые 256 необходимо 2 байта. НЕ существует стандартного расположения байтов, всё зависит от архитектуры. Существует 3 стандарта: UTF-8BE, UTF-8LE и просто UTF-8. В первых двух название стандарта указывает на порядок, а в последнем, универсальном, в начале строки передаётся этот самый BOM, который указывает на порядок. Теперь вопрос: чем он плох? По-моему, это лучше, чем мучиться с двумя версиями UTF-8!

А вообще, читайте английскую Википедию, и ваши волосы будут гладкими и шелковистыми! =)

Миша, ты что-то напутал. Стандартов UTF-8LE и UTF-8BE не существует. А если где-то они и упоминаются, то по ошибке. Дело в том, что BE/LE проблемы появились, когда шибко умные программисты пары байт UCS-2 (aka UTF-16) записывать в таком порядке, какой удобней для их процессора. Поскольку текст в UTF-8 кодируется не парами байт, а цепочками байт различной длины, то и проблемы BE/LE не стоит. Порядок байт в цепочке задан в стандарте и, более того, нет разумного способа перепутывать их, чтобы какая-нибудь машина лопала их быстрее.

Выводы:
1. 3-байтовый BOM в утф-8 иногда используется лишь для идентификации того, что текст — в утф-8 (и не определяет никакой «OM»)
2. BOM в утф-8 использовать не следует, т.к. он портит пользовательские данные. Вместо этого, кодировку нужно указывать отдельно от текста (например, в HTTP-заголовках или тегах meta в HTML).

Может быть, потому что сам я стандард не читал. Однако источник информации надёжный: http://en.wikipedia.org/wiki/Byte_Order_Mark

Мда, всё-таки немного напутал... По ссылке из таблицы всё понятно будет

Википедия никогда не будет надежным источником информации.

Олег, раскроете свои _надёжные_ источники информации?

Таким популярным статьям, как эта, в Википедии можно доверять. Их просматривает огромное количество людей, и все ошибки быстро исправляются. Между прочим, в классических энциклопедиях тоже много ошибок, и они корректируются заметно медленнее.

Я сам пользуюсь википедией, но нужно подходить ко всем источникам с изрядной долей критики. «Надежный» источник по кодировкам — это стандарт, размещенный на unicode.org. Все остальные источники могут помочь понять какие-то отдельные проблемы, но нужно читать стандарт («официальную информацию»), чтобы не оказаться заложником UTF-8 BE/LE.

А насчет «просматривает огромное количество людей», не забывайте, что из них большинство — те, кто не рубит в вопросе, а потому исправить не может. «Коллективный разум» — это очень-очень особенная штука, к ней нельзя подходить однобоко. В каких-то случаях она работает, в каких-то — нет. Be careful surfin' the web, there're a lotta h/-\X0rs 'round.

ХЗ, ХЗ...
Мне конечно нравится Юникод, но другие его реализации (а точнее UTF-16 BE) я считаю более прогрессивными. Основной "+" UTF8 в её совместимости со старыми технологиями, в остальном же ИМХО это временное решение и будующее за UTF16/32.

И в чём же, по-вашему, заключается прогрессивность UTF-16/32 перед UTF-8?

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

С UTF-16 всё просто - один символ = два байта. А вот с UTF-8 сложнее - тут уж как я понимаю аски идёт прям так, а "не аски" (типа нашкй с вами кириллицы) уже записывается цифрами. Посему "вес" текста достаточно сильно зависит не только от количества используемых в нём симвоолов, но и от самих символов - аски они или не аски.
К томуж 16/32 бита соответствует машинному слову на многих процессорах.

К сожалению, ты процитировал почти все мифы и ошибки, какие только можно услышать о юникоде и его кодировках. Предлагаю почитать предыдущие сообщения на стене, чтобы понять почему:

1. В utf-16 не 2 байта на символ.
2. "не аски в утф-8 записывается цифрами" — чушь (не путай с utf-7, вот уж точно устаревшая кодировка)
3. "соответствует машинному слову" — не дает ни грамма ускорения при обработке текста, зато порождает веселуху с BE/LE, от которой все прогрессивное человечество страдает по сей день.
4. И, наконец, почему устаревшие именно утф16 и утф32, а утф8 — промышленный стандарт, который закрепляется во всех новых форматах данных и транспортных протоколах.

В таком случае извиняюсь =)

Олег Андреев > И в чём же, по-вашему, заключается прогрессивность UTF-16/32 перед UTF-8?

C UTF-32 AFAIK можно писать полноценные математические формулы безо всяких MathML. А также писать на эльфийских (Tengwar и Cirth) и клингонском языках ;-) Подозреваю что Китайские и Японские алфавиты тоже там.

Иван - не запутывайте общественность. В utf-8 можно записать любой символ из набора Unicode. Насчет "полноценных математических формул" - запишите, пожалуйста, хотя бы формулу для решения квадратного уравнения. Которая еще $x_{1,2} = \frac{-b+\sqrt{b^2-4ac}}{2a}$.

Николай Дуров > В utf-8 можно записать любой символ из набора Unicode.

Здорово, а зачем тогда, действительно, нужны 16 и 32?

BTW, предлагаю логотип для группы:
http://img510.imageshack.us/img510/1846/unicodelogoc...

"Здорово, а зачем тогда, действительно, нужны 16 и 32?"

В жизни всякое бывает =) Это устаревшие стандарты. Хотя. Например, в Джаве в уникод-строках применяется обрезанный утф-16 (basic multilingual pane) — действительно 2 байта, но без поддержки кучи экзотичных буковок типа старославянского алфавита. Такой подход (поддерживать не все буквы) мне кажется граничащим с фашизмом, если учесть, что речь идет не о галимой устаревшей компактной кодировке типа вин-1251, а о УНИКОДе, т.е. универсальном коде, на который можно положиться: "любой введенный текст будет сохранен, передан и обработан без потерь". В этом смысле, лингвисты-русисты, юзающие джава-приложение, потеряют все свои старославянские тексты, если только джава-программисты не придумали нестандартных, обходных, решений лишь для того (!) чтобы буквы не пропали и были отображены на экране как положено. По-моему, это маразм.

> то устаревшие стандарты. Хотя. Например, в Джаве в уникод-строках применяется обрезанный утф-16

Более того, в Java 1.5 введена (в каком виде - не знаю, не пробовал) поддержка UTF-32, что сопровождалось комментарифми на посвящённом выходу Tiger (Java 1.5) Java day что теперь в Java-программах можно писать по-клингонски, по-эльфийски и по-математически.

В .Net 2.0 (на котором я немало программировал), на сколько я понял тоже используется UTF-16, и текстовые потоки/файлы по-умолчанию пишутся именно в ней.

случайно наткнулся на интересную статейку по UTF-8
http://drdaeman.livejournal.com/86120.html
p.s.: юзаю с недавнего времени как дефолтовую локаль, в общем-то все впорядке. до этого вообще корявый koi8-r юзал - ужасный гемор.

Николай Дуров > В utf-8 можно записать любой символ из набора Unicode.

У меня в "О себе" указано моё имя по-английски. Я планирую также написать моё имя ещё на нескольких языках. В том числе, прикола ради, хотел бы написать на эльфийском (я знаю как оно пишется и могу написать на бумаге). Если в utf-8 можно писать все символы Unicode, то должно быть можно Вконтакте писать по-эльфийски. Как бы это сделать? У меня нет эльфийской клавиатуры, подскажите, plz, какие есть способы.

Либо достать где-нибудь эльфийскую клавиатуру, либо воспользоваться "Таблицей Символов" из Windows. Еще можно откопать где-нибудь таблицы Unicode и вбить коды символов вручную.

Чего-то не нашёл в таблице символов символов алфавита Tengwar. Смотрел шрифты Arial, Times new roman и Tahoma - там дофига всего, а этого вроде нет, по крайней мере в глаза не бросается.

Нашёл вот такую таблицу: http://jrgraphix.net/research/unicode_blocks.php

Но там тоже Tengwar нема. И здесь тоже http://unicode.org/charts/

Странно, а говорили что он есть.

Сейчас на вконтакте полноценный юникод. Как минимум, у меня в религиозных взглядах "الله أكبر". А UTF-8 не позволяет, не то что такое, но даже умляуты писать. Так что нафиг...

вся википедия на утф-8, все буквы нарисованы отлично.

В UTF-8 можно записать *любой* символ, который есть в Unicode. А вконтакте сейчас использует win-1251, а все, что туда не влезает, кодирует через &#NNNN;

> В UTF-8 можно записать *любой* символ

Тем, кто пока этого не понял, статья, рекомендованная Александром чуть ниже, явно пойдёт на пользу.

> А вконтакте сейчас использует win-1251, а все, что туда не влезает, кодирует через &#NNNN;

Обалдеть какой изврат.

Не знаю, изврат или нет, но в итоге самые часто используемые символы кодируются одним байтом, что положительно сказывается на размере страниц и особенно таблиц.

Таблицы — да. А страницы сжимаются гзипом так, что нет никакой разницы, был ли символ двухбайтовым или однобайтовым. Причем, большая часть страницы — первая половина ASCII, которая в кодовой странице и утф-8 выглядит одинаково.

На самом деле после сжатия этой страницы разница процентов в 10. Это, конечно, не так принципиально, как размер таблиц. Зато различного рода регулярные выражения и код для склонения имен проще сделать в win-1251. Хотя в php и есть функции для регулярных выражений в utf-8, но они не слишком удобные...

http://absurdopedia.wikia.com/wiki/Unicode