Мой вариант обработки не использует никаких внешних компонент, при этом кодирование учитывает полную спецификацию UTF-8. Таким образом, в отличие от представленных здесь аналогов, можно преобразовывать не только кириллицу, а любой текст в юникоде.
В поисках решения проблемы передачи в POST/GET-запросы не-ASCII текста из 1С, так и не смог найти универсальной и алгоритмически красивой версии. Поэтому скромно представляю на ваш суд свой вариант.
upd: Изменил способ конвертации Dec->Hex, в результате прирост скорости около 60%.
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
Осталось только оптимизировать, подозреваю что не такая уж и быстрая конвертация.
А неразрывный пробел правильно отработается? Код символа — 160.
Ну не знаю, конечно. Не успел ещё замер производительности сделать, в ближайшее время хочется сравнить.
Поскольку 1С-ка выдаёт настоящий код символа в Юникоде, а исключения из кодируемых составляют только указанные в спецификации символы (пробел, кстати, можно и исключить, но ведь стандарт подразумевает отображение в виде «+») — т.е. буквы латиницы, цифры и несколько знаков — остальные символы переводятся именно в соответствии с алгоритмом, суть которого примерно та же, что и Base64. Поэтому и неразрывный пробел должен совпасть. Вы не проверяли?
Замер производительности показал, что 40-45% времени пожирает конвертер dec->hex…
Подскажите несведущим чем Unicode отличается от UTF-8
поему у них обоих ведь 2 байта на символ, что позволяет закодировать все вариации
(4) ksb, в юникод — 2 байта на символ. в utf-8 — от 1 и выше байт на символ (английские — 1, русские — 2, азиатские вообще по 3-4 занимают)
(5) Пасиб. а ещё вопрос
а как проги разбирают, что в потоке символов utf-8 этот символ займет 1 байт а другой 4 байта, они разделены каким то маркером ?
(6) ksb, тут тема раскрыта:
🙂
А если в Base64 загнать — не вариант?
Конечно не вариант, ведь Base64 — это поток бинарной информации, тупо «порубленный» по 6 бит; с UTF-8 другая история, там зависимость нелинейная.
Изменил способ конвертации Dec->Hex (берётся прямо из строки, значение — как индекс нужной пары символов), в результате прирост скорости около 60%.
А символы @#$%#k8SjZc9Dxk&*() разве не являются безопасными? в статье из википедии пишут что сиволы 00-7F однозначно соответствуют ASCII
(11) Gida, этот конвертер написан для использования в POST-запросах и URL, поэтому и диапазон «безопасных» символов сужен до разрешённого в URL-ах.
русские символы я так понял , он не конвертирует …
(13) Наоборот, конвертирует НЕ ТОЛЬКО русские символы, но и все остальные.