Баг локализации результата поиска

[pavel-pimenov]

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

[pavel-pimenov]

From zzzxzzzy...@gmail.com on August 05, 2013 08:46:13

Точнее: http://www.airdcpp.net/forum/viewtopic.php?f=7&t=4038&sid=8ea53f89b6b15c0c0c2e2689e2d23a7d

[pavel-pimenov]

From zzzxzzzy...@gmail.com on August 05, 2013 08:57:06

Т.к. уже забанили гугло-аккаунт - если возникнут вопросы, и если и тут забанят что скорее всего, спрашивайте по приведённой ссылке.

[pavel-pimenov]

From tret2...@gmail.com on August 15, 2013 09:00:17

У меня не повторяется, я что-то делаю не так ? https://www.dropbox.com/s/y8iq8eh483rn8fg/Pic54346.PNG Проверьте настройки кодировки в избранных хабах у данного хаба.

[pavel-pimenov]

From zzzxzzzy...@gmail.com on August 19, 2013 02:01:09

Проверьте настройки кодировки в избранных хабах у данного хаба.
Точно ничего, с дефолта, не менял. +проверял это.

У меня не повторяется, я что-то делаю не так ?

1. Возможно сказывается "XPsp3+ w/o MUI(GUI_language=ENG), but with installed RU-fonts and locatisation tables (it visible in second type result - not '?')."
2. возможно(и помоемому помоемому) у Вас пользователь - не тот, тот вроде был с Израиля, жаль не указал ник сейчас не вспомню, но Ваш не тот - ?вроде.
3. в данный момент ничего проверить не могу - пользователь отключён, и был в таком же состоянии всю неделю на момент написания issue, подозреваю надо вылавливать именно по выходным :( ...

[pavel-pimenov]

From entry....@gmail.com on August 19, 2013 05:23:20

Сталкивался с этим когда тестил RPC взаимодействие под WS/xhr

Проблема, по сути не в принимающей стороне, а в передающей, т.е. при формировании SR. Проблем не должно возникать с нашей кодовой страницей, т.к. трансформация идет в нее, но вот с подобным - ハルヒの消失 соответственно будут неполадки, т.к. логично что символ 失 не будет найден в заданном представлении

Все это сделано весьма странно, т.е. проще передавать мультибайтовую последовательность и с не уже работать в любом кодовом пространстве, а в итоге формирование SR для nmdc построено на трансформации из utf8 в соответствии с определениями в client, а полученный результат - трансформация обратно.

по сути решение это убрать ненужную трансформацию - проверял, все начинает работать как надо для ansi/ut8, но подобное изменение без обратной совместимости, т.е. в старых версиях от нового клиента в результатах будет двойная трансформация

надо будет еще раз глянуть как сохранить совместимость, если не забуду напишу

[pavel-pimenov]

From zzzxzzzy...@gmail.com on August 19, 2013 06:04:58

1. Ну, а тогда - почему 50:50, точнее и так и этак возможно(в том конкретном случае)?
   Если дело - только в кодировке клиентов,
   скорее - нужно рыть в область различия хаб-софта...

2. В любом случае можно сделать автодетект и автоконверсию, но только на приёме.
   PS: Автодетект значительно упрощается при наличии хотя бы одного правильно-кодированного
   результата поиска через иной хаб с пользователя,
   (конечно если его 100%-верно детектить на разных хабах как одного и того же...)

[pavel-pimenov]

From entry....@gmail.com on August 19, 2013 06:46:03

-> 1.
это не 50/50 я написал что фишка с кодовым пространством

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, накладывающий ряд ограничений на текстовые данные.
Надо смотреть детальнее, я тогда отложил это из-за совместимости. Команда флая с этим кодом знакома дольше, поэтому "почему так, а не так" им виднее