dra27.uk — если это правда, то желаю всем остальным тоже включить голову
Тут пишут что в одном красноглазом проекте за 12 лет справились с кодировками — Скачал бинари под винду. Создаю табличку: CREATE TABLE authors (author_id integer primary key, name varchar not null);
Вставляю туда запись: INSERT INTO authors (name) values ('Пупкин Василий');
Пока всё хорошо. Селект показывает по-русски, чики-пики. Далее, копирую базу под линукс, делаю там селект... в выводе кракозябры
sqlite> select * from authors;
1|ЏгЇЄЁ ‚ бЁ«Ё©
Так. Кракозяброй нас не напугаешь, всего то надо поменять кодировку, но на какую?! Издали это выглядит как UTF-8, но на деле это не он: "Пупкин Василий" в UTF-8 выглядит так: "РџСѓРїРєРёРЅ Василий"
Залез в базу фаром, там то же самое, что линуксовый клиент показывает. Ну и как это понять? Особенно учитывая, что винда всё показывает правильно.
За несколько часов я перепробовал почти все возможные и невозможные варианты, и когда провалилась бинарная запись в файл — я понял — надо что-то менять, не в данных, не во мне, а в подходе. До того момента я старался избегать "грязных" хаков, трюков, основанных на знании работы компилятора и задачи программы, за которые она /никогда/ не выйдет. Я старался абстрагироваться, делать все максимально прозрачно (насколько мне позволяла лень :Р) и грамотно. Но у меня не осталось выхода. И так, я знал три(?) вещи: 1. Итераторы не трогали данные, во всяком случае без моего приказа. 2. Итераторы предоставляли прямой доступ к данным 3. При создании итераторов я использовал метод std::basic_string c_str()/data() из описания которых следует: Modifying the character array accessed through data is *undefined behavior*. В дополнение ко всему этому я знал, что строка изменяться уже не будет, и взглотнув побольше воздуха я сделал это — получил прямой доступ к данным через итератор, нагло избавился от const модификатора, который имел место быть благодаря c_str()/data() и стал записывать туда данные. В исходном тексте замена пробельного символа на перенос стала выглядеть так: (*(xmlChar*)u8_word.base()) = '\n'; Дописав код я скомпилировал, запустил и... выдохнул. Оно работало! Данные отображались верно, без доп. копирования, проверок (ранее я пытался записывать по слову) и прочего. "Dirty hack" — то самое выражение, которое пришло в голову сразу после получения (ожидаемого?) результата. Будь у меня более свежая голова, мозг товарища и пицца, я думаю мы разделались бы с этим за 10 минут. Но это был веселый опыт разработки. Больше, пожалуй, мне добавить нечего. Пишите код правильно ребята, не давайте доводить себя до отчаянья. У меня не было ни времени ни возможности обратиьтся к товарищу, и я решил эту проблему иначе. Тем не менее, ссылки по теме: https://github.com/spumer/tenzor-test/ — исходный код, виновник торжества. http://en.cppreference.com/w/cpp/string/basic_string/data — ... through data is undefined behavior. http://utfcpp.sourceforge.net/ — utf8 C++ portable library http://www.xmlsoft.org/html/libxml-xmlstring.html#xmlChar
Сталось так, что при работе с библиотекой libxml2 понадобилось подсчитывать кол-во символов в строке, с целью ограничить длину строки в N символов и остальную ее часть перенести на новую(строку). Символы в этой строке естественно могут занимать от 1 до 6 байт, в соответствии с форматом UTF-8. Самолично парсить строку по стандарту не было никакого желания, а уж темболее проходиться по граблям желания было еще меньше. Благо это тема довольно изъезженная и решение в виде небольшой портабильной библиотеки уже было написано. Язык С++, и библиотека была написана в виде итераторов для прохода по последовательности байт и функций, которые осуществляют некоторые простые операции как с итераторами, так и с самими последовательностями. libxml2 для хранения данных использует свой собственный тип xmlChar, хотя на деле это ни что иное как unsigned char. Камнем преткновения стала запись в файл, ведь именно туда мне было необходимо выгрузить все отформатированные данные. unsigned char в принципе не хотел записываться в файл и каждый раз он получался пустым, запись же в бинарном виде либо полностью колечило данные, либо их non-ASCII составляющую. Все попытки воссоздать правильную последовательность xmlChar байт с разбивкой на N символов в строке заканчивались одним — полный бред на выходе. Немного о том, как работает UTF-8 библиотечка: созданные итераторы как и предполагается не трогают данные по которым следуют, но доступ к ним предоставляют. Доступ к символу в моем случае можно было осуществить двумя способами: operator* и метод base(), где первый возвращает данные типа unsigned int, второй же возвращает указатель на место в последовательности, в котором он в данный момент находится. Так, например, если *u8_it вернет нам 'c', то (*u8_it.base()) будет равен &("ascending"[2]). Если же вы(как и я) передавали при создании итератора константный указатель на данные (e.g. const xmlChar *) то при использовании base() для записи вам придется избавиться от const модификатора, но об этом далее.
For Qt’s own source code, we have decreed that the source should be UTF-8 only, and so I proceeded a few weeks ago to find and recode all non-UTF-8 sources. And I’m going even further than that: if you don’t use UTF-8 for your source code, you’ll be on your own. Though it’s possible to make it work, do not ask us for help and do not expect us to add convenience functions. I am also discarding any arguments of the form “my editor/IDE/OS/environment does not support UTF-8″. This is 2012 and we live in a global world, with global data. Any such editor or environment should be left where it belongs: in a museum dedicated to the 80s and 90s.macieira.org
$('#msend').click(function(){ //обнуление поля при нажатии на энтер
$('#chat').append('<div id="msg" class="msg">Я : '+$('#mtext').val()+'</div>')
$.post(
'/chat/ajax.php?act=ngmsg',
{
text : $('#mtext').val()
rid : rid
},
function(){$('#mtext').val(null)}
)
})
при нажатии текст "Я :" отображается столь же криво.
<textarea cols="50" name="text" rows="5" id="mtext"></textarea><br />
<input type="submit" value="send" id="msend">
все файлы в кодировке UTF-8 БЕЗ BOM, кодировка страницы в хедере так-же utf-8
принимается вот такого вида текст:
йцукен -> йцукен
Âñåì ïðèâåò! Êòî õî÷åò â ïåéíòáîë â ýòî âîñêðåñåíüå (29 ìàÿ) — çàïèñûâàéòåñü òóò, è/èëè çâîíèòå ìíå.
Òàì áóäó ÿ, íåñêîëüêî ìîèõ äðóçåé, èõ îäíîãðóïïíèêè, äðóçüÿ èõ îäíîãðóïïíèêîâ. È, âîçìîæíî, âû ;-)
Ãäå èìåííî — åù¸ íå ðåøèëè, ïðèíèìàþòñÿ ïðåäëîæåíèÿ =)
Текст сообщения:
п я п п п п я п я п п я я пЁп п п я п п п я п п п п п п п п я п п п п п п п я я п пЁп я я я п я п п п п п п я п п я п п я п .
п п я п п пЁп п : п п я п п я : <censored>
п п я п я п п п п я п п п я п я п я п п п я п п п пЁп п
<censored>
@rulexec'а про io:format, получилось домучать эрланг:
5> io:format(lists:map(fun(X) -> case lists:member(X, " ,") of true -> X; false -> X + 1 end end, "Хз, у меня всё работает")).
Ци, ф нжоѐ гтђ сбвпубжуok
Кодировки должны умереть. Сейчас надо было во фразе сдвинуть все буквы на 1 по алфавиту. Интерпретаторы erlang'а и haskell'а печатали мне список кодов символов, питоновый chr отказался работать, паскаль вообще неадекватные кракозяблы выдал. В итоге, с подсказки 5> io:format(lists:map(fun(X) -> case lists:member(X, " ,") of true -> X; false -> X + 1 end end, "Хз, у меня всё работает")).
Ци, ф нжоѐ гтђ сбвпубжуok
(этот пост — резюме какого-то плохо написанного и криво свёрстанного, но всё же полезного текста отсюда: surrender-zen-way.blogspot.com )
1. Использовать non-free утилиту unrar.
2. Использовать расширение для Nautilus под названием Ailurus.
3. Исправить кодировку уже распакованных файлов с помощью convmv:
$ convmv -f cp866 -t utf8 -r --notest *
4. Поставить WinRAR под Wine.
5. В большинстве случаев с работой исправно справляется p7zip-rar.
6. Если удалить rar, то file-roller (стандартный убунтовский — или гномовский? — распаковщик) будет использовать unrar, у которого нет проблем с кодировками.
balancer.ru При чём в весьма востребованной софтине...
Уж где-где, а тут не ожидалось :) — alt 1 = ☺
alt 2 = ☻
alt 3 = ♥
alt 4 = ♦
SO! а если ноут/нет-бук?? тока что пробовал и нихера не получилось..аргх!
@iglaweb клиент-серверного приложения — клиент .NET, сервер PHP — я понял, что надо учиться распознавать кодировку по типу крякозябр...
В процессе написания с text/html; cat '%s' | iconv -f %{charset} -t utf8 | w3m -dump -T text/html; copiousoutput; description=HTML Text; nametemplate=%s.html
Пишу в терминале: gedit --encoding cp1251 file.txt
Результат: cp1251: неверная кодировка.
Пишу: gedit --encoding windows-1251 file.txt
Результат: файл открылся без замечаний.
Я всегда думал что windows-1251 это и есть cp1251.
P.S.
С различными вариантами написания cp1251 экспериментировал.