Кто нибудь может расписать все кодировки-перекодировки на пути текста от файла на хосте до браузера? Где в какой момент он перекодируется и какие установки редактора/апача/пхп/браузера и всего остального, если что- то забыл, на это влияют? И можно ли как- то победить, что при формировании xml, excel и ldap всегда приходится возиться с iconv('win1251', 'utf-8') и наоборот? реально заколебало.
Никаких неявных перекодировок. Потому и приходится вручную менять их =) какие приложения какие кодировки понимают - тема отдельная. Меньше всего геморроя с UTF-8.
[vs] То есть от того, какую кодировку я выберу в NetBeans ничего не зависит. И если я ее даже поменяю, ничего-ничего не изменится? на днях юзал новый NetBeans 6.7M3 со встроенной поддержкой UnitTest-ов, обратил внимание, что если файл теста сохранен в utf-8, логи непройденых тестов генерятся нормально, а если в Win-1251, то в абракадабре. Если учесть, что лог генерится из ПХПшного скрипта, запущенного консольно, получается, что кодировка даже в редакторе очень сильно влияет на выполнение кода. Вместо юнит-тестов там могла быть запись в базу. Например, если записывать в utf-8 базу из кода, сохраненного в Win-1251, получится лажа или нет? А если этот же скрипт пересохранить в utf8? Я вот эту связь никак уловить не могу.
alexey_baranov Символ - это порядок битов. В разных кодировках порядок битов для одного и того же символа разный. В CP1251 на каждый сивол - 2 байта, в UTF-8 - до 6, и маркируются они по-разному, поэтому когда записываешь текст, закодированый в CP1251 в БД, воспринимающую UTF-8, получаются кракозябры. ЕМНИП, латиница во всех кодировках - ASCII, поэтому с ней проблем быть вроде не должно.
Если Мне Не Изменяет Память В данном примере, пхп-скрипт является клиентом БД. Если ты хочешь записывать то ты говоришь серверу мускула: "Я работаю в кодировке 1251!" (SET NAMES CP1251) И мускул будет ЖДАТЬ от тебя данных в кодировке 1251, которые он получит, и ПЕРЕКОДИРУЕТ В КОДИРОВКУ, используемую для хранения данных. Как правило, УТФ-8. Если клиентом у тебя выступает виндовая консоль - ты также сообщаещь: "Я консоль, моя кодировка cp866" (SET NAMES CP866). Что будет делать мускул? будет ЖДАТЬ от тебя данных в кодировке 866, которые он получит, и ПЕРЕКОДИРУЕТ В КОДИРОВКУ, используемую для хранения данных. Как правило, УТФ-8. Так-то.
Нормальные русские буквы мы получим, независимо от кодировки на клиенте. Главное, корректно эту кодировку указать для соединения, к кодировке хранения данных сервер мускула преобразует сам(ну, или если ты шлешь UTF, и в базе хранишь UTF, то данные просто пойдут напрямую без перекодировки)
Есть еще момент, когда при загрузке файлов на сервер, FTP клиент и сервер могут не поддерживать кодировку или перекодировать файл при передаче в кодировку, какую нибудь "по умолчанию", если там есть какие либо такие настройки...
то есть если бы я с самого начала сохранял файлы в utf-8, мне не пришлось бы сейчас писать iconv(win, utf8) каждый раз, когда я обращаюсь к Ldap, excel или xml? так что-ли? Может стоит пересохранить все исходники в utf-8?
вообще то если ты работаешь с UTF-8 то надо это обязательно сделать, вот http://www.php.ru/forum/viewtopic.php?t=16467
сечешь тему Вообще, про кодировки хорошо бы расписать подробно, с картинками - но как всегда, скорее всего времени не найдется ) Только учти, что с UTF-8 не работают стандартные строковые функции, нужно пользоваться их mb_* эквивалентами, или перегрузить их в php.ini
http://www.php.net/manual/ru/mbstring.overload.php а ereg_* давно пора забыть как страшный сон. В пхп 5.3 их уже не будет. а preg_* работает с УТФ.
Единственно, что не рекомендованно устанавливать перегрузку из .htaccess. У нас боевой сервер с перегруженными функциями работает уже года полтора.
А это что за покемон у меня поселился с давних времен? setlocale(LC_ALL, "ru_RU.CP1251")? мануал читать умею. ничего не понял. делать им нечего? лучше бы они soap-ом серьезно занялись. и что теперь делать честным людям? Там жешь финд-реплейсом не обойдешься. Синтаксис все- таки разный. всякой ерундой занимаются, пока самое важное простаивает. семерку напротив мбстринга ставишь и привет. ничего сложного вроде. mbstring.func_overload = 7 пальцы большие?
Да. Но у нас не мускул. У мускула с УТФ вроде как есть проблемы с REGEXP, но подробней я не знаю, т.к. регекспами в базе не пользуюсь )
да у меня тоже не мускул давно. слабоват он. но это другая тема. посгрес у меня если что. У меня только один вопрос приходит тогда. Почему тогда говорят, что пхп не юникод? вот выйдет 6-ой, тогда будет юникод.
Именно потому, что встроенные строковые функции не обрабатыают уникод. mbstring, хоть и стандартное, но все таки расширение. PHP6 будет использовать для внутреннего представления и хранения UTF строки.