Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
pavel-pimenov opened this issue Aug 25, 2015 · 7 comments

Comments

Projects
None yet
1 participant
@pavel-pimenov
Copy link
Owner

commented Aug 25, 2015

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

This comment has been minimized.

Copy link
Owner Author

commented Aug 25, 2015

@pavel-pimenov

This comment has been minimized.

Copy link
Owner Author

commented Aug 25, 2015

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

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

@pavel-pimenov

This comment has been minimized.

Copy link
Owner Author

commented Aug 25, 2015

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

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

@pavel-pimenov

This comment has been minimized.

Copy link
Owner Author

commented Aug 25, 2015

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

This comment has been minimized.

Copy link
Owner Author

commented Aug 25, 2015

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

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

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

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

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

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

@pavel-pimenov

This comment has been minimized.

Copy link
Owner Author

commented Aug 25, 2015

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

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

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

@pavel-pimenov

This comment has been minimized.

Copy link
Owner Author

commented Aug 25, 2015

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.