Кодировка символов в таблицах для мультиязычного проекта

Темы, не касающиеся фреймворка, но относящиеся к программированию в целом.
Аватара пользователя
girmate
Сообщения: 1533
Зарегистрирован: 2015.10.27, 12:52

Re: Кодировка символов в таблицах для мультиязычного проекта

Сообщение girmate »

Я таких скриншотов уже много посмотрел (даже в паспортах съезжают буквы). Так что проблема существует и по-хорошему нормализация нужна, хоть и не везде проявляются такие дефекты.
Осторожно! Вы общаетесь с новичком ;)

Аватара пользователя
samdark
Администратор
Сообщения: 9336
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

Re: Кодировка символов в таблицах для мультиязычного проекта

Сообщение samdark »

Хороший пример. Не задумывался об этом раньше.

Аватара пользователя
girmate
Сообщения: 1533
Зарегистрирован: 2015.10.27, 12:52

Re: Кодировка символов в таблицах для мультиязычного проекта

Сообщение girmate »

Может это можно использовать во благо? Например, как защиту текстов от копирования. )
Осторожно! Вы общаетесь с новичком ;)

Аватара пользователя
samdark
Администратор
Сообщения: 9336
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

Re: Кодировка символов в таблицах для мультиязычного проекта

Сообщение samdark »

Защиту от копи-пасты сделать технически невозможно.

Аватара пользователя
ElisDN
Сообщения: 5563
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: Кодировка символов в таблицах для мультиязычного проекта

Сообщение ElisDN »

girmate писал(а):Может это можно использовать во благо? Например, как защиту текстов от копирования. )
https://tjournal.ru/26777-u-studentki-p ... i-referata

Аватара пользователя
rugabarbo
Сообщения: 1063
Зарегистрирован: 2015.06.21, 16:21
Контактная информация:

Re: Кодировка символов в таблицах для мультиязычного проекта

Сообщение rugabarbo »

zelenin писал(а):вот кстати яркий пример почему надо нормализовывать юникод
Возникает философский вопрос: кто должен отвечать за нормализацию? Поставщик текста? Или программа, которая юзает текст? Ведь получается, что кейс воспроизводится лишь в отдельных программах. Как остальным программам (в данном конкретном случае - браузерам) удалось этого избежать?

zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

Re: Кодировка символов в таблицах для мультиязычного проекта

Сообщение zelenin »

rugabarbo писал(а):
zelenin писал(а):вот кстати яркий пример почему надо нормализовывать юникод
Возникает философский вопрос: кто должен отвечать за нормализацию? Поставщик текста? Или программа, которая юзает текст? Ведь получается, что кейс воспроизводится лишь в отдельных программах. Как остальным программам (в данном конкретном случае - браузерам) удалось этого избежать?
изначально поставщик. но и в браузере должна быть защита от дурака.

Аватара пользователя
rugabarbo
Сообщения: 1063
Зарегистрирован: 2015.06.21, 16:21
Контактная информация:

Re: Кодировка символов в таблицах для мультиязычного проекта

Сообщение rugabarbo »

Неясно, почему поставщик должен нормализовывать.

Денормализованный Unicode - это вполне себе преобразуемая в читабельный текст последовательность байт. Если создатель ПО берётся за отображение Unicode - его задача корректно отображать и воспринимать его даже в денормализованном виде в соответствии со стандартами. Будь это текстовый редактор или что-то ещё. Если браузер хреново отображает денормализованную форму юникода - это проблема браузера. Если текстовый редактор стирает денормализованную букву "й" по частям - это проблема текстового редактора. Это не проблема последовательности байт. Тот, кто передаёт её в браузер (создатель сайта) - не должен париться о нормализации.

Приведу более простой пример. Есть денормализованные пути к файлам. Например, C:\Windows\\User\..\ProgramData\ - было бы странно требовать от всех НЕ использовать такие пути. Поэтому общепринято, что конечная программа берёт на себя ответственность за нормализацию. Даже если мы кормим ей такой путь, файловый менеджер говорит нам: "Окей, ты скормил мне что-то странное, но я попробую это нормализовать" - и приводит это к виду: " C:\Windows\ProgramData" - соответственно, по этой нормальной форме уже можно открывать файл или сравнивать его с адресами любых других файлов. Но странно было бы требовать от всех юзать нормальную форму файловых путей. Если ПО не умеет преобразовать путь файла к нормальной форме, я бережно положу его в корзину и сразу же очищу её.

Так и с юникодом. Почему я должен в выдачах на своём сайте юзать нормальную форму? Есть стандарт, который позволяет использовать целых два вида денормализованного юникода - я скормлю денормаль браузеру и пусть он отображает по этим стандартам.

От нормализованной формы "у себя на сайте" вижу три профита (по убывания пользы):
1) безопасность при обработке данных (кейс с точкой в домене можно увидеть в вышеприведённой статье на хабре)
2) более предсказуемое сравнение строк во всех слоях системы (хотя опять же мультибайт-библиотеки должны строки сравнивать по стандартам, а не по байтам, приводя всё это к нормали перед сравнением)
3) экономия байт (нормальная форма легче)

Весомый аргумент только первый. Но он применим только при вводе каких-то критических данных (логина, мейла, пароля).

Почему ещё я должен морочиться с нормализацией?

zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

Re: Кодировка символов в таблицах для мультиязычного проекта

Сообщение zelenin »

rugabarbo писал(а):Неясно, почему поставщик должен нормализовывать.
потому что существует проблема. А бизнес должен решать проблемы сейчас.
Ты же не будешь пенять на браузеры, почему они неполноценно поддерживают стандарты css, а налепишь хаков.
Причем в данном случае это не хак, а нормализация - процесс, приводящий некую сущность к нормальной форме, что вполне себе полезно в любой области.
rugabarbo писал(а):Приведу более простой пример. Есть денормализованные пути к файлам. Например, C:\Windows\\User\..\ProgramData\ - было бы странно требовать от всех НЕ использовать такие пути. Поэтому общепринято, что конечная программа берёт на себя ответственность за нормализацию. Даже если мы кормим ей такой путь, файловый менеджер говорит нам: "Окей, ты скормил мне что-то странное, но я попробую это нормализовать" - и приводит это к виду: " C:\Windows\ProgramData" - соответственно, по этой нормальной форме уже можно открывать файл или сравнивать его с адресами любых других файлов. Но странно было бы требовать от всех юзать нормальную форму файловых путей. Если ПО не умеет преобразовать путь файла к нормальной форме, я бережно положу его в корзину и сразу же очищу её.
если бы php не понимал денормализованные пути, то ты бы написал свой нормализатор.
Не предлагай класть на полочку браузеры - это странно.
rugabarbo писал(а):Почему ещё я должен морочиться с нормализацией?
потому что: а) нормализация в любой области программирования полезна, б) проблема есть, и ее надо решать, причем она легко и приятно решается (см. "а"), в) проблема не только в браузерах - я сталкивался с тем, что ПО не читает файлы с ФС, потому что в названии файла ненормализованные глифы. PhpStorm еще год назад некорректно работал с денормализованным юникодом. итд.

Аватара пользователя
rugabarbo
Сообщения: 1063
Зарегистрирован: 2015.06.21, 16:21
Контактная информация:

Re: Кодировка символов в таблицах для мультиязычного проекта

Сообщение rugabarbo »

Надо помнить, что Unicode - это не кодировка (если говорить формально). Кодировка - это UCS, например, который включен в Юникод для задания конкретных символов. Например, в составной букве "й" два UCS-кода. А юникод - это, собственно, стандарт, в который входит много чего: в том числе способ отображения комбинаций UCS-кодов.

Если создатель ПО говорит нам, что поддерживает Юникод, а сам при этом не умеет склеивать два UCS-кода по стандарту в одну букву, то поддерживает ли он Юникод? Нет. Он поддерживает его частично. Поэтому с философской точки зрения это вопрос кривого ПО. Это не проблема конкретного текста. Не проблема сайта, который передаёт этот текст в браузер.

Практическим аргументом к нормализации контента я вижу лишь один момент: бизнес требует отображения "й" в IE11, поэтому мы вынуждены заниматься нормализацией вместо инженеров Microsoft. Такая же история, например, с вёрсткой под старую Оперу и старые IE - мы вынуждены лепить CSS/JS-хаки, потому что отдельные виды бизнеса и под них требуют нормального отображения сайта.

Но хороши ли эти хаки с философской точки зрения? Что мы получили, не положив те браузеры в мусорку? Разношёрстные вёрстки? Удорожание FE-разработки? Зато заказчик доволен, факт.

То есть мой вывод такой:
* с практической точки зрения мы обязаны нормализовывать юникод-строки, чтобы подстроиться под конкретное кривое ПО (решить практическую проблему кривого софта вместо его создателей)
* с философской точки зрения мы ничего не обязаны, потому что это проблема конкретного софта, который не умеет работать по стандарту Unicode

zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

Re: Кодировка символов в таблицах для мультиязычного проекта

Сообщение zelenin »

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

Аватара пользователя
rugabarbo
Сообщения: 1063
Зарегистрирован: 2015.06.21, 16:21
Контактная информация:

Re: Кодировка символов в таблицах для мультиязычного проекта

Сообщение rugabarbo »

zelenin писал(а):у меня файрфокс - тут тоже есть проблема.
я бы нормализовал даже если бы не было проблем. нормализация - это хорошо.
Ну хорошо-то хорошо, но практических аргументов за нормализацию выходит всего три:
* исключить проблемы отображения сайта в кривых браузерах (нужно бизнесу)
* обезопасить ввод (нужно владельцу сайта)
* снизить объём трафа (нужно... ежам?) http://s6.pikabu.ru/post_img/2014/10/25 ... 857519.jpg - хотя если текстового трафика реально много (как на Википедии, например), то там можно получить приличную экономию

Кстати, не замерял, сколько "кушает" нормализация через intl на больших текстах? Ну, к примеру, 100 000 знаков нормализовать.

zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

Re: Кодировка символов в таблицах для мультиязычного проекта

Сообщение zelenin »

rugabarbo писал(а):* обезопасить ввод (нужно владельцу сайта)
кинь о чем речь. по ссылке в статье не нашел
rugabarbo писал(а):Кстати, не замерял, сколько "кушает" нормализация через intl на больших текстах? Ну, к примеру, 100 000 знаков нормализовать.
магии никакой нет - чуть больше стандартных str_replace/preg_replace

Аватара пользователя
rugabarbo
Сообщения: 1063
Зарегистрирован: 2015.06.21, 16:21
Контактная информация:

Re: Кодировка символов в таблицах для мультиязычного проекта

Сообщение rugabarbo »

zelenin писал(а):
rugabarbo писал(а):* обезопасить ввод (нужно владельцу сайта)
кинь о чем речь. по ссылке в статье не нашел
Ну вот тут https://habrahabr.ru/post/45489/ в начале идёт пример про экзотическую точку в названии домена. Наверно, он не очень хорош для демонстрации "опасности" денормализованного ввода, но суть ясна (нетривиальные кейсы возникают при фильтрации денормализованного ввода).

Аватара пользователя
rugabarbo
Сообщения: 1063
Зарегистрирован: 2015.06.21, 16:21
Контактная информация:

Re: Кодировка символов в таблицах для мультиязычного проекта

Сообщение rugabarbo »

Вот более наглядный пример: https://habrahabr.ru/post/183878/
Кучу таких кейсов можно придумать при обработке логинов, мейлов, паролей и т.п.

zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

Re: Кодировка символов в таблицах для мультиязычного проекта

Сообщение zelenin »

ага, ну это не та нормализация, о которой мы выше говорили. Это по сути и не нормализация вообще, т.к. в случае с составными символами, у нас один символ (глиф, по-моему), из разного кол-ва кодпойнтов. В случае с точкой, это просто разные символы, пусть и выглядящие похоже, но не одинаково. Такие случаи можно обрабатывать в рантайме, канонизируя данные, но нельзя канонизировать ДО попадания в БД, т.к. будет потеря данных (кейс, аналогичный html_specialchars до попадания в БД или после).

Аватара пользователя
rugabarbo
Сообщения: 1063
Зарегистрирован: 2015.06.21, 16:21
Контактная информация:

Re: Кодировка символов в таблицах для мультиязычного проекта

Сообщение rugabarbo »

rugabarbo писал(а):Вот более наглядный пример: https://habrahabr.ru/post/183878/
Кучу таких кейсов можно придумать при обработке логинов, мейлов, паролей и т.п.
Ну вот я вторым постом более подходящий пример кинул.
С точкой в домене действительно немного не то.

zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

Re: Кодировка символов в таблицах для мультиязычного проекта

Сообщение zelenin »

rugabarbo писал(а):
rugabarbo писал(а):Вот более наглядный пример: https://habrahabr.ru/post/183878/
Кучу таких кейсов можно придумать при обработке логинов, мейлов, паролей и т.п.
Ну вот я вторым постом более подходящий пример кинул.
С точкой в домене действительно немного не то.
на самом деле это идентичный случай. речь идет о канонизации, которая происходит с визуальным изменением контента. в кач-ве решения проблемы из статью вижу два варианта: а) хранить в БД оригинальный логин и канонический, и сравнивать с каноническим, б) в БД создать индекс, канонизирующий логин (я хз поддерживает ли что-то такое - есть поддержка индекса с выражением в постгресе, но есть ли там канонизация?)

Аватара пользователя
rugabarbo
Сообщения: 1063
Зарегистрирован: 2015.06.21, 16:21
Контактная информация:

Re: Кодировка символов в таблицах для мультиязычного проекта

Сообщение rugabarbo »

Ну дальше возникают ещё более интересные вопросы безопасности: что происходит при шифровании денормализованных данных? При хэшировании? При сравнении уровня БД? Уровня PHP? Происходит ли в прикладных библиотеках нормализация mb-строк? Во всех? Во всех ли одинаково? И проч.

Вообще, любая работа с денормализованным вводом вызывает вопросы безопасности.

Аватара пользователя
Faenir
Сообщения: 292
Зарегистрирован: 2010.01.06, 01:46
Откуда: Симферополь

Re: Кодировка символов в таблицах для мультиязычного проекта

Сообщение Faenir »

utf8mb4 и collation utf8mb4_unicode_ci - на сегодняшний день являются оптимальными mysql кодировками для мультиязычных сайтов?

http://rmcreative.ru/blog/post/utf8_uni ... general_ci
UPD 2016: Кодировку на сегодняшний день для MySQL рекомендую utf8mb4. Collation utf8mb4_unicode_ci потому что юникод расширился несколько и в utf8 не всё влезает.
Что насчет utf8mb4_unicode_520_ci?

Ответить