Баг локализации результата поиска #1261
Comments
From zzzxzzzy...@gmail.com on August 05, 2013 08:46:13 Точнее: http://www.airdcpp.net/forum/viewtopic.php?f=7&t=4038&sid=8ea53f89b6b15c0c0c2e2689e2d23a7d |
From zzzxzzzy...@gmail.com on August 05, 2013 08:57:06 Т.к. уже забанили гугло-аккаунт - если возникнут вопросы, и если и тут забанят что скорее всего, спрашивайте по приведённой ссылке. |
From tret2...@gmail.com on August 15, 2013 09:00:17 У меня не повторяется, я что-то делаю не так ? https://www.dropbox.com/s/y8iq8eh483rn8fg/Pic54346.PNG Проверьте настройки кодировки в избранных хабах у данного хаба. |
From zzzxzzzy...@gmail.com on August 19, 2013 02:01:09
|
From entry....@gmail.com on August 19, 2013 05:23:20 Сталкивался с этим когда тестил RPC взаимодействие под WS/xhr Проблема, по сути не в принимающей стороне, а в передающей, т.е. при формировании SR. Проблем не должно возникать с нашей кодовой страницей, т.к. трансформация идет в нее, но вот с подобным - ハルヒの消失 соответственно будут неполадки, т.к. логично что символ 失 не будет найден в заданном представлении Все это сделано весьма странно, т.е. проще передавать мультибайтовую последовательность и с не уже работать в любом кодовом пространстве, а в итоге формирование SR для nmdc построено на трансформации из utf8 в соответствии с определениями в client, а полученный результат - трансформация обратно. по сути решение это убрать ненужную трансформацию - проверял, все начинает работать как надо для ansi/ut8, но подобное изменение без обратной совместимости, т.е. в старых версиях от нового клиента в результатах будет двойная трансформация надо будет еще раз глянуть как сохранить совместимость, если не забуду напишу |
From zzzxzzzy...@gmail.com on August 19, 2013 06:04:58
|
From entry....@gmail.com on August 19, 2013 06:46:03 -> 1. nmdc реализация для RS у клиента построена на Text::fromUtf8 (обертка под Text::acpToUtf8), трансформация идет с кодовой таблицей Text::g_code1251 (получаемая от клиента c.getEncoding()), поэтому кириллица трансформируется как надо, другие же символы (на примере японского иероглифа 失) разуемеется отсутствует, поэтому и просиходит ошибка. Подробнее можно ознакомится в RFC 3629 а вот Adc реализация построена как есть, без преобразований - что в прочем не мудрено, т.к. "All text must be sent as UTF-8 encoded Unicode in normalization form C." http://adc.sourceforge.net/ADC.html -> 2. Можно, но вся соль не в этом... я не в курсе откуда это тянется (с каких конкретно клиентов и вообще с каких времен), но если изменить выдачу SR, то принимающая сторона (инициатор поиска), получит уже целостные данные, но из-за двойной трансформации(сколько и какие клиенты построены с Text::toUtf8 я не в курсе), уже с не правильным отображением, и при этом, этот "эффект" уже будет распространяться повально на всю мультибайтовую последовательность, т.к. в SR более не будет трансформаций скорей всего проблема тянется изначально к самому протоколу nmdc, накладывающий ряд ограничений на текстовые данные. |
From zzzxzzzy...@gmail.com on August 05, 2013 17:45:09
Отослал обнарженный сегодня баг вашим конкурентам,
но обнаружилось что он и у Вас тоже наблюдается,
можете глянуть: http://www.airdcpp.net/forum/viewtopic.php?f=7&t=4038&p=7728&sid=8ea53f89b6b15c0c0c2e2689e2d23a7d#p7728
Original issue: http://code.google.com/p/flylinkdc/issues/detail?id=1224
The text was updated successfully, but these errors were encountered: