[Статья]

1: Настройка кодировок в сервисе MySQL
Все нижесказанное, по пункту 1, касается только тех случаев когда Вы располагаете собственной хост площадкой, или поднимаете локальный (тестовый) сервис MySQL.
Большинство проблем с кодировками отгребается именно на этапе работы (взаимодействия) MySQL и WEB сервиса (Апач и т.п.). Именно некорректная настройка самого MySQL может в конечном итоге и дать нечитаемые дампы, и даже при нормальном отображение кириллицы на форуме - дать нечитаемые крякозябры при прямом редактировании данных в таблицах базы и т.п.
В этой статье OldEr дал очень хорошее сравнение китайцев с шотландцами говорящими вроде бы на одном англицком языке, вот примерно об этом но применительно к самому MySQL сервису и пойдет речь.
Если сервис MySQL у вас настроен правильно, т.е. так как надо. То в самом движке форума уже можно ничего и не менять, всё будет работать вполне корректно.



По умолчанию в файле настроек mysql.ini (Те самые инструкции для сервиса MySQL согласно которым он и будет работать) не так много настроек касающихся кодировок.
Поэтому Нам придется руками дописать недостающие, и исправить существующие.

В частности нас будут интересовать следующие параметры:
[client] - параметры сервисов которые по отношению к серверу баз данных (MySQL) являются клиентскими.
default-character-set=utf8 и
character-sets-dir=C:/MySQL/share/charsets/ - Путь к инструкциям кодировок

[mysql] - тут описываются общие инструкции сервера MySQL
default-character-set=utf8

[mysqld] - а тут инструкции непосредственно сервиса MySQL, параметров касающихся кодировок нужно указать три:
collation-server=utf8_general_ci
init-connect="SET NAMES utf8"
character-set-server=utf8

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

И последней инструкцией, которую тоже неплохо будет указать это:
[mysqldump] - тут нужно задать кодировку в которой по умолчанию будет делаться дамп баз данных с помощью встроенных средств MySQL.
default-character-set=utf8

Больше о кодировках в файле инструкций можно ничего не писать. Указанного уже вполне достаточно для корректной работы сервиса.

P.S.
Все вышесказанное описано для кодировки UTF-8 (как самой, на мой взгляд, правильно используемой для наших целей). Но параметр UTF-8 с успехом можно заменить на latin1 или на cp1251.

N.B.
Только следует помнить что при работе БД в latin1 несмотря на то что кодировка форума у Вас хоть и будет cp1251, и вроде бы все будет хорошо и чудесно отображаться кириллицей как на форуме, так и в БД, но никакие функции поиска по кириллице у Вас работать НЕ будут !!!



2: Кодировки файлов форума
Зачастую при использовании кодировки UTF-8 иногда и сами php скрипты (файлы) перекодируют из ANSI в UTF-8.
Особо большой пользы в этом нет, но многие (и я в том числе) любят оставлять в файлах комментарии на Русском языке. А корректно это только в том случае если сама кодировка файла - UTF-8.
Тут начинающего кодера ждет засада, о которой лучше знать заранее, а не ломать себе мозг в поисках решения выплывших проблем.

Причина ВСЕХ ошибок вызванных использованием скриптов сохраненных в UTF-8, называется - BOM (Byte Order Mark), не поленитесь и почитайте WIKI чтобы понимать, что такое BOM.

В общем, основная суть в том, что файлы сохраненные с BOM заголовком, имеют в самом начале три байта (0xEF, 0xBB, 0xBF) которые никак не видны в текстовых редакторах !!!
В частности, зарекитесь использовать для редактирования файлов сохранённых в UTF-8 - Блокнот Windows. Эта сволочь дописывает BOM заголовок даже туда где его не было.
Все нормальные текстовые редакторы запишут файл так как он лежал. Был в UTF-8 с BOM, значит перезапишем с BOM, был без оного, значит так и запишем...

Чем вообще чреват этот заголовок и как он себя проявляет.
Прежде всего тем, что PHP - это скриптовый язык. И соответственно, прежде чем в браузер пользователю будет отдан конечный HTML код, обработается множество файлов PHP и если хоть в одном из них окажутся эти самые три лишних байта в заголовке... а окажутся они естественно до сепаратора "<?php"... то очень просто представить (а зачастую и увидеть) что происходит когда хоть один байт оказывается раньше чем: <!doctype html...

Тут и непонятое съезжание дизайна... и отказ сервера отобразить страницу т.к. с куками возникла проблема... и т.д. и т.п.

Резюмируя:
1) Используйте для верстки хорошие, продвинутые текстовые редакторы. Даже если Вам всего на минуточку нужно только файлик открыть и всего-то один символ поменять...
2) Конвертируя файлы из ASCI в UTF-8 убедитесь что Ваш конвертор имеет опцию - Запись с BOM/ Запись без BOM.

И еще. Ни в коем случае запуская пакетную обработку файлов из ANSI в UTF-8 не включайте в нее ВЕСЬ каталог /forum т.к. там окажутся и файлы XML и JS и CSS. И если последним двум конвертация в UTF-8 не слишком навредит, то раскуроченный XML заставит Вас биться в нервной истерике. Так что относитесь к процессу конвертации внимательно и подходите к этому с умом.