В строку попадает нехороший символ с точки зрения UTF-8, ну и соответственно идет исключение.
Механизма для перехвата и замены символа конечно же нет. Вот она расширяемость
Вариант замены не очень нравится, т.к. получается лишняя работа.
Как сказать WCF , чтобы отсылал все как есть, т.е. в UTF-16 без преобразований ?
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, _NN_, Вы писали:
S>Может вот это или это поможет?
Я пользуюсь WCF через именные каналы.
NetNamedPipeBinding создает сам BinaryMessageEncodingBindingElement, а он похоже всегда сначала сериализует в UTF-8 а потом отсылает.
Можно конечно создать TextMessageEncodingBindingElement , но мне нужна скорость
Здравствуйте, _NN_, Вы писали:
_NN>В строку попадает нехороший символ с точки зрения UTF-8, ну и соответственно идет исключение. _NN>... _NN>Как сказать WCF , чтобы отсылал все как есть, т.е. в UTF-16 без преобразований ?
Если символ нехороший с точки зрения UTF-8, то он будет нехорошим и с точки зрения UTF-16
Вы уверены, что в строке у вас вообще валидный текст? Может, это на самом деле бинарные данные, которые нужно и передавать как бинарные, а не как строку?
Здравствуйте, vmpire, Вы писали:
V>Если символ нехороший с точки зрения UTF-8, то он будет нехорошим и с точки зрения UTF-16
Это меня не смущает
V>Вы уверены, что в строке у вас вообще валидный текст? Может, это на самом деле бинарные данные, которые нужно и передавать как бинарные, а не как строку?
Я беру заголовок окна. Так уж вышло, что кто-то написал неправильные символы.
Это ведь не значит, что у меня все должно упасть
Здравствуйте, _NN_, Вы писали:
V>>Вы уверены, что в строке у вас вообще валидный текст? Может, это на самом деле бинарные данные, которые нужно и передавать как бинарные, а не как строку? _NN>Я беру заголовок окна. Так уж вышло, что кто-то написал неправильные символы. _NN>Это ведь не значит, что у меня все должно упасть
В UTF-8 представимы все символы UTF-16, поэтому есть шанс, что вы неправильно этот заголовок получаете.
Не исключено что, вы ошибочно интерпретируете последовательность каких-то двухбайтовых символов как UTF-16, хотя это не UTF-16.
В Windows По факту много где используется UCS-2, а не UTF-16. А в UCS-2 все символы валидны.
Здравствуйте, vmpire, Вы писали:
V>В UTF-8 представимы все символы UTF-16, поэтому есть шанс, что вы неправильно этот заголовок получаете.
V>Не исключено что, вы ошибочно интерпретируете последовательность каких-то двухбайтовых символов как UTF-16, хотя это не UTF-16.
Так это не я , а WCF.
Я просто получаю строку, что в ней меня не особо волнует и не должно волновать транспорт WCF.
Валидно или невалидно у меня есть объект string который нужно передать.
V>В Windows По факту много где используется UCS-2, а не UTF-16. А в UCS-2 все символы валидны.
Наверное из-за UCS-2.
Здравствуйте, _NN_, Вы писали: _NN>Я просто получаю строку, что в ней меня не особо волнует и не должно волновать транспорт WCF.
Такого не может быть. Вы обратили внимание на то, что по вашей ссылке описан случай, когда ССЗБ режут строку посредине суррогата?
Очевидно, что заголовок окна не может содержать пол-суррогата, если вы его корректно получаете.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, vmpire, Вы писали:
V>А в UCS-2 все символы валидны.
Всё не так просто. UCS-2 есть кодировка для Unicode 1.1.x и ниже. И UCS-2 поток именно относительно этих версий стандарта и надо декодировать, и проверять корректность.
А для Unicode 2.0 и выше UCS-2 просто не существует.
Здравствуйте, drol, Вы писали:
V>>А в UCS-2 все символы валидны. D>Всё не так просто. UCS-2 есть кодировка для Unicode 1.1.x и ниже. И UCS-2 поток именно относительно этих версий стандарта и надо декодировать, и проверять корректность. D>А для Unicode 2.0 и выше UCS-2 просто не существует.
Это как-то противоречит сказанному?
И потом, "Unicode 1.1.x и ниже" тут ни при чём. UCS-2 действительно устарел, но это изменение было зафиксировано в другом стандарте: ISO/IEC 10646:2011, который соотвестсвует Unicode 6.0. Иными словами, до Unicode 6.0 UCS-2 официально существовал. А так как большая часть кода современных операционных систем была написана до 2011 года, то UCS-2 де факто широко используется и сейчас.
Например, MS SQL Server умеет обрабатывать только UCS-2, по крайней мере в версии 2005. Да и в формате XML UCS-2 вполне поддерживается многими, если не всеми, библиотеками.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, _NN_, Вы писали: _NN>>Я просто получаю строку, что в ней меня не особо волнует и не должно волновать транспорт WCF. S>Такого не может быть. Вы обратили внимание на то, что по вашей ссылке описан случай, когда ССЗБ режут строку посредине суррогата? S>Очевидно, что заголовок окна не может содержать пол-суррогата, если вы его корректно получаете.
Ну почему же.
Вот кто-то написал в браузере 'window.alert("\uD948")' .
Я взял этот текст и хочу его передать.
По вашему мне надо проверять каждый раз текст, который я получаю ?
Мне проще взять другой транспорт тогда уж.
Здравствуйте, _NN_, Вы писали:
_NN>Вот кто-то написал в браузере 'window.alert("\uD948")' . _NN>Я взял этот текст и хочу его передать.
В Unicode 2.0+ "\uD948" текстом не является.
_NN>По вашему мне надо проверять каждый раз текст, который я получаю ?
Вы не с текстом работаете. Вы работаете с некоторой кодировкой текста. И в этой кодировке далеко не все последовательности значений являются корректными\допустимыми\согласованными.
Здравствуйте, drol, Вы писали:
D>Здравствуйте, _NN_, Вы писали:
_NN>>Вот кто-то написал в браузере 'window.alert("\uD948")' . _NN>>Я взял этот текст и хочу его передать.
D>В Unicode 2.0+ "\uD948" текстом не является.
А вот по мнению Windows это вполне нормальный текст.
Выводится сообщение и ничего не падает.
_NN>>По вашему мне надо проверять каждый раз текст, который я получаю ?
D>Вы не с текстом работаете. Вы работаете с некоторой кодировкой текста. И в этой кодировке далеко не все последовательности значений являются корректными\допустимыми\согласованными.
Я получаю текст в виде юникодной строки. Как у Windows мне узнать про кодировку этой строки ?
Здравствуйте, drol, Вы писали:
D>Здравствуйте, _NN_, Вы писали:
D>>>В Unicode 2.0+ "\uD948" текстом не является.
_NN>>А вот по мнению Windows это вполне нормальный текст.
D>Это личные проблемы Windows.
Как мне это не помогает решить проблему ?
_NN>>Выводится сообщение и ничего не падает. D>Нам только исключений на каждый чих при операциях со строками не хватало для полного счастья
Ну так, раз Windows выводит текст, почему можно его получить но нельзя его передать через WCF ?
_NN>>Я получаю текст в виде юникодной строки.
D>Что значит "получаю текст" ? Какую функцию WinAPI\какой метод какого класса .NET Вы вызываете ?
Простой GetWindowTextW.
Здравствуйте, _NN_, Вы писали:
D>>Нам только исключений на каждый чих при операциях со строками не хватало для полного счастья
_NN>Ну так, раз Windows выводит текст, почему можно его получить но нельзя его передать через WCF ?
Потому что, в отличии от большинства функций WinAPI, WCF требует корректности передаваемых данных. Это, собственно, одна из базовых идей WCF как концепции — сильная типизация, все дела...
D>>Что значит "получаю текст" ? Какую функцию WinAPI\какой метод какого класса .NET Вы вызываете ?
_NN>Простой GetWindowTextW.
GetWindowTextW отдаёт текст заголовка окна в виде последовательности WCHAR в кодировке UTF-16.
Однако, как уже было сказано выше, функции WinAPI не требуют корректности таких UTF-16 строк. Можно как установить заголовок окна в кривую UTF-16 строку, так и получить её обратно.
В этом плане, понятие кодировки содержимого (LP)WSTR в Windows односторонне. Функции WinAPI, занимающиеся отображением и прочими интерпретациями текста, работают с (LP)WSTR как с UTF-16. Но они игнорируют ошибки в них. Это можно спокойно делать, потому что в UTF-16 один некорректный элемент влияет максимум на один символ.
Отсюда следует, что на самом деле в (LP)WSTR можно хранить строки в любой кодировке однозначно представимой в виде последовательности WCHAR'ов. Да, соответствующие функции WinAPI будут рисовать фигню. Но содержимое строк от этого не изменится и не испортится.
Здравствуйте, drol, Вы писали:
_NN>>Ну так, раз Windows выводит текст, почему можно его получить но нельзя его передать через WCF ? D>Потому что, в отличии от большинства функций WinAPI, WCF требует корректности передаваемых данных. Это, собственно, одна из базовых идей WCF как концепции — сильная типизация, все дела...
Остаётся вопрос — почему одним можно безбожно ставить replacement char на всё что не понимают, а другим нет, и как это конфигуриться?
Эх, правду говорят — Windows Complication Framework. Говно, а не фреймворк. Я правда на него зуб точу по другому вопросу, но сути не меняет. ТС плавненько подходит, что не нужен ему WCF...
Здравствуйте, drol, Вы писали:
D>Здравствуйте, _NN_, Вы писали:
D>>>Нам только исключений на каждый чих при операциях со строками не хватало для полного счастья
_NN>>Ну так, раз Windows выводит текст, почему можно его получить но нельзя его передать через WCF ?
D>Потому что, в отличии от большинства функций WinAPI, WCF требует корректности передаваемых данных. Это, собственно, одна из базовых идей WCF как концепции — сильная типизация, все дела...
Это хорошо, но где это можно конфигурировать ? Скажем, заменять плохие символы на '?'.
_NN>>Простой GetWindowTextW. D>Отсюда следует, что на самом деле в (LP)WSTR можно хранить строки в любой кодировке однозначно представимой в виде последовательности WCHAR'ов. Да, соответствующие функции WinAPI будут рисовать фигню. Но содержимое строк от этого не изменится и не испортится. D>Стало яснее ? Или ещё хуже ?
То, что WinAPI работает не совсем корректно меня как-то не сильно интересует.
В итоге приходим к изначальному количеству вариантов
1. Все проверять, а только потом отсылать.
2. Использовать массивы вместо строк, надеюсь тут никто не придерется
3. Заменить WCF на другое.
