тексты на японском

[timoshenkov]

тексты на японском

Подскажите как лучше выкрутиться из ситуации

Есть сайт на 9 языках, один из них японский из-за него проблема

Все храню в utf-8, но когда я попытался внести в базу текст на японском вот он
то он обрезался

Поставил этому полю бинарный тип, все стало зашибись, но тогда у меня не смогут работать поиски по текстам

Когда я поставил сравнение этому полю big-5 то текст туда прекрасно залетел, но часть символов при выводе поехала (страница у меня вся выводиться в utf-8)
Тогда я после этого конвертнул это поле назад в uft-8 и все заработало

Тоесть мескалин может хранить внутри эти данные в utf-8 и выдавать их, вот только как их туда засунуть?
Может есть способ какой хитрый что бы определить если данные на японском то конвертнуть их и засунуть в базу

В описании uft-8 написанно что он должен поддерживать какойто японский диапозон символов

Спасибо

(сорри админы что дублирую тему, в этой категории наверное больше шансов что ответят )

 

[magic]

А текст до импорта в какой кодировке находится?

 

[timoshenkov]

echo mb_detect_encoding($edit['text']);

возвращает UTF-8 да и копирую я текс со страницы которая в UTF-8
вставляю в WYSWYG редактор который тоже в UTF-8

Перед и после засовывания текста в базу вывожу переменную все символы на месте

Все доказательства на лицо что текст который мне нужно вставлять на японском всостоянии жить в UTF-8 , но так по тупому он в мескалин не залазит

Хотя как я писал выше вытажить его из базы в кодировке UTF-8 возможно
Может там пару глючных символов просто появляются?

-~{}~ 29.11.06 00:41:

Глюк нашелся оказывается что я все SQL запросы провожу через "свой" класс
который перепроверяет запросы и выводит их с помощью функции sprintf

$db->db_query("DELETE FROM mytable WHERE id='%d' ",$id);

как оказалось функция sprintf не может корректно работать с многобайтовыми строками

об этом есть комент в мануале
вот он

но как там и пишет человек, что за работоспособность не ручается, я проверил и правда
кто-нибудь решал эту проблему?

Переделывать в коде все SQL запросы не возможно, да и тогде увеличивается вероятность что "подсунут" что то в запрос

можите что то подсказать?

-~{}~ 29.11.06 08:21:

оказался ни причем !

sprintf

сорри за панику
Но проблему решил

добавил на всячкий случай в код подсоединения с базой

define('DB_COLLATION_CONNECTION','utf8_bin');
$db->db_query("SET collation_connection ='%s'",DB_COLLATION_CONNECTION);

хотя это не отражается на результате
главная проблема была в том как обрабатываются входные данные

было вот так

function pr_all($str,$l,$words) {
$str=preg_replace("/[^\x20-\xFF,\x0A]/","",@strval($str));
$str=trim($str);
$str = wordwrap($str, $words, " ", 1);
$str = substr($str, 0, $l);
$str=stripslashes($str);
return $str;
}

заменил на

function pr_all($str,$l,$words) {

$mbEncod=mb_detect_encoding($str);
mb_regex_encoding($mbEncod);
$str=mb_ereg_replace("/[^\x20-\xFF,\x0A]/","",@strval($str));
$str=trim($str);

$str = $this->utf8_wordwrap($str,$words," ");
$str = mb_substr($str, 0, $l,$mbEncod);

if (!get_magic_quotes_gpc())	{$str=stripslashes($str);}

return $str;
}

Обработка сказывалась только на японском и только при вводе текста в базу, при выводе переменных на экран как HTML текста ни каких заметных расхождений не было
Хотя конечно глядя на японские ироглифи легко пропустить пару штук
Мескалину мешали наверное наполовину обрезанные символы , которые у меня получались припервом методе обрабодки, а зрительно эти "недобайты" были не заметны