Странная сортировка таблиц Mysql

[GOsha]

Есть MySQL Таблица:

Region_ID smallint(5) UNSIGNED NotNull auto_increment
Region_Parent_Country smallint(5) UNSIGNED NotNull
Region_Name_Ru varchar(50)
Region_Name_En varchar(50)

Все просто - в таблице области. Привязанные к парент-кантри ИД = 2. Т.е. любимая наша РБ. )))

Region_ID | Region_Parent_Country | Region_Name_Ru | Region_Name_En
________________________________________
| 1 | 2 | Гродненская область | Grogno region |
--------------------------------------------------------
| 2 | 2 | Брестская область | Brest region |
--------------------------------------------------------
| 3 | 2 | Витебская область | Vitebsk region |
--------------------------------------------------------
| 4 | 2 | Гомельская область | Gomel region |
--------------------------------------------------------
| 6 | 2 | Минская область | Minsk region |
--------------------------------------------------------
| 7 | 2 | Могилевская область | Mogilev region |
--------------------------------------------------------

Таблица получена запросом:
SELECT * FROM `geo_regions` ORDER BY `Region_Name_Ru` ASC LIMIT 0 , 30

Теперь объясните мне, пожалуйста, каким образом Гродненская область оказалась впереди планеты всей, када сортировка задана по русскому полю в прямом порядке. Обратите внимание, что Гомель - после Витебска и Бреста. Т.е. правильно

Та же ситуация и с таблицей городов - всю голову сломал. )))
Подскажите, куда копать. А?

 

[Vovochka]

Если в общем и целом сортировка работает правильно, но за редким исключением, то скорее всего стоит присмотреться к этим исключениям.
Может какой-нибудь левый нечитаемый символ затисался в ряды буков?
Попробуй сделать UPDATE опять вручную (не копируя) набрав область. Или DELETE + INSERT, но не копируя название области, а забивая руками.

 

[GOsha]

А вот фокус в том, что "Гордненская" - ортирует правильно. А вот "Гродненская" нет. Никаких символов там нет - все запросы писал вручную.

 

[GOsha]

Дело было в кодировках таблиц MySQL.
mysql_query("SET NAMES cp1251");
ПОсле коннекта.

 

[Vovochka]

И когда народ перейдет на utf-8

 

[GOsha]

Никогда. )))
ПОчитайте тут:

Ссылка скрыта от гостей

- Много интересного по кодировкам.
А вообще win-1251 используется потому что самая распространенная.
+ к этому прошу поругать Кирилла и Мефодия за изобретение кириллицы, заставляющей нас:
- Переключать раскладки
- Мучаться с кодировками
- Пользоваться Пунто-свитчером
- ПИсать транслитом
- Мучаться со шрифтами
...... и ты ды....

 

[etc]

Vovochka А лучше уйдет от MySQL.

 

[GOsha]

Интересно, что ты предлагаешь взамен?

 

[etc]

Т.е. вы хотите сказать что MySQL - единтвенная в мире?
А если в "общеобразовательском" плане, то все от задачи зависит. PostgreSql например получше будет.

 

[Kmet]

Никогда. )))
ПОчитайте тут:

Ссылка скрыта от гостей

- Много интересного по кодировкам.
А вообще win-1251 используется потому что самая распространенная.

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

 

[Vovochka]

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

+1

Да и сего бы это MySQL не поддерживала utf8?
Все время работаю с этой кодировкой.

А из-за таких товарищей как некоторые здесь, доблестная эра юникода еще долга не наступит

 

[GOsha]

2 etc: Я не говорил, что единственная в мире. Вы когда-нибудь пытались посадить цветок в горшок с помощью экскаватора? )))
Для тех задач, которые приходится решать - мускуль самое удобное средство не требующее экзотики. Достаточно хостинга за 4-7 УСД/мес.

2 Vovochka: Скорее всего вы просто любитель никсовых систем. ПОэтому для вас и Юникод в радость. ))) Просто я говорю, что у каждого на это своя религия. Позвольте мне остаться при моей. )))
Я не говорю, что УТФ8 не поддерживается. Все там поддерживается. Просто если мы имеем БД с кодировкой вин-1251 а пришлем данные утф-8, то получим крякозяблы в базе. И наоборот. Поэтому выхода 2 - либо проверять и конвертить данные на входе, либо использовать на сервере и отправлять данные в кодировке такойже как и Мускуль. Я выбрал второе. Хотите первое - пожалуйста.
По поводу доблестной эры. Я не вижу объективных причин отказываться от цп1251, но и не вижу причин привязываться к утф8.

Кстати:
Некоторые модули не готовы работать с unicode, взять для примера smarty. Функция «trancate», которая урезает строку не N-символов (удобно использовать для вывода абзаца новости, например), не умеет работать с многобайтовыми кодировками. Если сказать ей вырезать первые 30 символов от русской строки, то она вернет 15 по понятным причинам;
*Конечно вопрос решается. Приделыванием "костылей".

Цитата с php.net: Строка — это набор символов. В PHP символ это то же самое, что и байт, это значит, что возможно ровно 256 различных символов. Это также означает, что PHP не имеет встроенной поддержки Unicode’а. Некоторую поддержку Unicode’а обеспечивают функции utf8_encode() и utf8_decode().

Все минусы UTF-8 - это издержки создания PHP и прочих языков до создания UTF-8. Так что это временное явление.

*Купил бы ты сейчас электромобиль? Экологично, дешево. НО! Где ты его заряжать будешь? Хотя все знают, что в будущем они будут прекрасны.

В итоге имеем единственный вопрос = "То, что за утф-8 будущее - это точно. Уже переходить или еще подождать? )))".