Кодировка символов в таблицах для мультиязычного проекта
Re: Кодировка символов в таблицах для мультиязычного проекта
Я таких скриншотов уже много посмотрел (даже в паспортах съезжают буквы). Так что проблема существует и по-хорошему нормализация нужна, хоть и не везде проявляются такие дефекты.
Осторожно! Вы общаетесь с новичком
- samdark
- Администратор
- Сообщения: 9489
- Зарегистрирован: 2009.04.02, 13:46
- Откуда: Воронеж
- Контактная информация:
Re: Кодировка символов в таблицах для мультиязычного проекта
Хороший пример. Не задумывался об этом раньше.
Нравится Yii? Давайте сделаем его лучше!.
Re: Кодировка символов в таблицах для мультиязычного проекта
Может это можно использовать во благо? Например, как защиту текстов от копирования. )
Осторожно! Вы общаетесь с новичком
- samdark
- Администратор
- Сообщения: 9489
- Зарегистрирован: 2009.04.02, 13:46
- Откуда: Воронеж
- Контактная информация:
Re: Кодировка символов в таблицах для мультиязычного проекта
Защиту от копи-пасты сделать технически невозможно.
Нравится Yii? Давайте сделаем его лучше!.
Re: Кодировка символов в таблицах для мультиязычного проекта
https://tjournal.ru/26777-u-studentki-p ... i-referatagirmate писал(а):Может это можно использовать во благо? Например, как защиту текстов от копирования. )
Re: Кодировка символов в таблицах для мультиязычного проекта
Возникает философский вопрос: кто должен отвечать за нормализацию? Поставщик текста? Или программа, которая юзает текст? Ведь получается, что кейс воспроизводится лишь в отдельных программах. Как остальным программам (в данном конкретном случае - браузерам) удалось этого избежать?zelenin писал(а):вот кстати яркий пример почему надо нормализовывать юникод
Re: Кодировка символов в таблицах для мультиязычного проекта
изначально поставщик. но и в браузере должна быть защита от дурака.rugabarbo писал(а):Возникает философский вопрос: кто должен отвечать за нормализацию? Поставщик текста? Или программа, которая юзает текст? Ведь получается, что кейс воспроизводится лишь в отдельных программах. Как остальным программам (в данном конкретном случае - браузерам) удалось этого избежать?zelenin писал(а):вот кстати яркий пример почему надо нормализовывать юникод
Re: Кодировка символов в таблицах для мультиязычного проекта
Неясно, почему поставщик должен нормализовывать.
Денормализованный Unicode - это вполне себе преобразуемая в читабельный текст последовательность байт. Если создатель ПО берётся за отображение Unicode - его задача корректно отображать и воспринимать его даже в денормализованном виде в соответствии со стандартами. Будь это текстовый редактор или что-то ещё. Если браузер хреново отображает денормализованную форму юникода - это проблема браузера. Если текстовый редактор стирает денормализованную букву "й" по частям - это проблема текстового редактора. Это не проблема последовательности байт. Тот, кто передаёт её в браузер (создатель сайта) - не должен париться о нормализации.
Приведу более простой пример. Есть денормализованные пути к файлам. Например, C:\Windows\\User\..\ProgramData\ - было бы странно требовать от всех НЕ использовать такие пути. Поэтому общепринято, что конечная программа берёт на себя ответственность за нормализацию. Даже если мы кормим ей такой путь, файловый менеджер говорит нам: "Окей, ты скормил мне что-то странное, но я попробую это нормализовать" - и приводит это к виду: " C:\Windows\ProgramData" - соответственно, по этой нормальной форме уже можно открывать файл или сравнивать его с адресами любых других файлов. Но странно было бы требовать от всех юзать нормальную форму файловых путей. Если ПО не умеет преобразовать путь файла к нормальной форме, я бережно положу его в корзину и сразу же очищу её.
Так и с юникодом. Почему я должен в выдачах на своём сайте юзать нормальную форму? Есть стандарт, который позволяет использовать целых два вида денормализованного юникода - я скормлю денормаль браузеру и пусть он отображает по этим стандартам.
От нормализованной формы "у себя на сайте" вижу три профита (по убывания пользы):
1) безопасность при обработке данных (кейс с точкой в домене можно увидеть в вышеприведённой статье на хабре)
2) более предсказуемое сравнение строк во всех слоях системы (хотя опять же мультибайт-библиотеки должны строки сравнивать по стандартам, а не по байтам, приводя всё это к нормали перед сравнением)
3) экономия байт (нормальная форма легче)
Весомый аргумент только первый. Но он применим только при вводе каких-то критических данных (логина, мейла, пароля).
Почему ещё я должен морочиться с нормализацией?
Денормализованный Unicode - это вполне себе преобразуемая в читабельный текст последовательность байт. Если создатель ПО берётся за отображение Unicode - его задача корректно отображать и воспринимать его даже в денормализованном виде в соответствии со стандартами. Будь это текстовый редактор или что-то ещё. Если браузер хреново отображает денормализованную форму юникода - это проблема браузера. Если текстовый редактор стирает денормализованную букву "й" по частям - это проблема текстового редактора. Это не проблема последовательности байт. Тот, кто передаёт её в браузер (создатель сайта) - не должен париться о нормализации.
Приведу более простой пример. Есть денормализованные пути к файлам. Например, C:\Windows\\User\..\ProgramData\ - было бы странно требовать от всех НЕ использовать такие пути. Поэтому общепринято, что конечная программа берёт на себя ответственность за нормализацию. Даже если мы кормим ей такой путь, файловый менеджер говорит нам: "Окей, ты скормил мне что-то странное, но я попробую это нормализовать" - и приводит это к виду: " C:\Windows\ProgramData" - соответственно, по этой нормальной форме уже можно открывать файл или сравнивать его с адресами любых других файлов. Но странно было бы требовать от всех юзать нормальную форму файловых путей. Если ПО не умеет преобразовать путь файла к нормальной форме, я бережно положу его в корзину и сразу же очищу её.
Так и с юникодом. Почему я должен в выдачах на своём сайте юзать нормальную форму? Есть стандарт, который позволяет использовать целых два вида денормализованного юникода - я скормлю денормаль браузеру и пусть он отображает по этим стандартам.
От нормализованной формы "у себя на сайте" вижу три профита (по убывания пользы):
1) безопасность при обработке данных (кейс с точкой в домене можно увидеть в вышеприведённой статье на хабре)
2) более предсказуемое сравнение строк во всех слоях системы (хотя опять же мультибайт-библиотеки должны строки сравнивать по стандартам, а не по байтам, приводя всё это к нормали перед сравнением)
3) экономия байт (нормальная форма легче)
Весомый аргумент только первый. Но он применим только при вводе каких-то критических данных (логина, мейла, пароля).
Почему ещё я должен морочиться с нормализацией?
Re: Кодировка символов в таблицах для мультиязычного проекта
потому что существует проблема. А бизнес должен решать проблемы сейчас.rugabarbo писал(а):Неясно, почему поставщик должен нормализовывать.
Ты же не будешь пенять на браузеры, почему они неполноценно поддерживают стандарты css, а налепишь хаков.
Причем в данном случае это не хак, а нормализация - процесс, приводящий некую сущность к нормальной форме, что вполне себе полезно в любой области.
если бы php не понимал денормализованные пути, то ты бы написал свой нормализатор.rugabarbo писал(а):Приведу более простой пример. Есть денормализованные пути к файлам. Например, C:\Windows\\User\..\ProgramData\ - было бы странно требовать от всех НЕ использовать такие пути. Поэтому общепринято, что конечная программа берёт на себя ответственность за нормализацию. Даже если мы кормим ей такой путь, файловый менеджер говорит нам: "Окей, ты скормил мне что-то странное, но я попробую это нормализовать" - и приводит это к виду: " C:\Windows\ProgramData" - соответственно, по этой нормальной форме уже можно открывать файл или сравнивать его с адресами любых других файлов. Но странно было бы требовать от всех юзать нормальную форму файловых путей. Если ПО не умеет преобразовать путь файла к нормальной форме, я бережно положу его в корзину и сразу же очищу её.
Не предлагай класть на полочку браузеры - это странно.
потому что: а) нормализация в любой области программирования полезна, б) проблема есть, и ее надо решать, причем она легко и приятно решается (см. "а"), в) проблема не только в браузерах - я сталкивался с тем, что ПО не читает файлы с ФС, потому что в названии файла ненормализованные глифы. PhpStorm еще год назад некорректно работал с денормализованным юникодом. итд.rugabarbo писал(а):Почему ещё я должен морочиться с нормализацией?
Re: Кодировка символов в таблицах для мультиязычного проекта
Надо помнить, что Unicode - это не кодировка (если говорить формально). Кодировка - это UCS, например, который включен в Юникод для задания конкретных символов. Например, в составной букве "й" два UCS-кода. А юникод - это, собственно, стандарт, в который входит много чего: в том числе способ отображения комбинаций UCS-кодов.
Если создатель ПО говорит нам, что поддерживает Юникод, а сам при этом не умеет склеивать два UCS-кода по стандарту в одну букву, то поддерживает ли он Юникод? Нет. Он поддерживает его частично. Поэтому с философской точки зрения это вопрос кривого ПО. Это не проблема конкретного текста. Не проблема сайта, который передаёт этот текст в браузер.
Практическим аргументом к нормализации контента я вижу лишь один момент: бизнес требует отображения "й" в IE11, поэтому мы вынуждены заниматься нормализацией вместо инженеров Microsoft. Такая же история, например, с вёрсткой под старую Оперу и старые IE - мы вынуждены лепить CSS/JS-хаки, потому что отдельные виды бизнеса и под них требуют нормального отображения сайта.
Но хороши ли эти хаки с философской точки зрения? Что мы получили, не положив те браузеры в мусорку? Разношёрстные вёрстки? Удорожание FE-разработки? Зато заказчик доволен, факт.
То есть мой вывод такой:
* с практической точки зрения мы обязаны нормализовывать юникод-строки, чтобы подстроиться под конкретное кривое ПО (решить практическую проблему кривого софта вместо его создателей)
* с философской точки зрения мы ничего не обязаны, потому что это проблема конкретного софта, который не умеет работать по стандарту Unicode
Если создатель ПО говорит нам, что поддерживает Юникод, а сам при этом не умеет склеивать два UCS-кода по стандарту в одну букву, то поддерживает ли он Юникод? Нет. Он поддерживает его частично. Поэтому с философской точки зрения это вопрос кривого ПО. Это не проблема конкретного текста. Не проблема сайта, который передаёт этот текст в браузер.
Практическим аргументом к нормализации контента я вижу лишь один момент: бизнес требует отображения "й" в IE11, поэтому мы вынуждены заниматься нормализацией вместо инженеров Microsoft. Такая же история, например, с вёрсткой под старую Оперу и старые IE - мы вынуждены лепить CSS/JS-хаки, потому что отдельные виды бизнеса и под них требуют нормального отображения сайта.
Но хороши ли эти хаки с философской точки зрения? Что мы получили, не положив те браузеры в мусорку? Разношёрстные вёрстки? Удорожание FE-разработки? Зато заказчик доволен, факт.
То есть мой вывод такой:
* с практической точки зрения мы обязаны нормализовывать юникод-строки, чтобы подстроиться под конкретное кривое ПО (решить практическую проблему кривого софта вместо его создателей)
* с философской точки зрения мы ничего не обязаны, потому что это проблема конкретного софта, который не умеет работать по стандарту Unicode
Re: Кодировка символов в таблицах для мультиязычного проекта
у меня файрфокс - тут тоже есть проблема.
я бы нормализовал даже если бы не было проблем. нормализация - это хорошо.
я бы нормализовал даже если бы не было проблем. нормализация - это хорошо.
Re: Кодировка символов в таблицах для мультиязычного проекта
Ну хорошо-то хорошо, но практических аргументов за нормализацию выходит всего три:zelenin писал(а):у меня файрфокс - тут тоже есть проблема.
я бы нормализовал даже если бы не было проблем. нормализация - это хорошо.
* исключить проблемы отображения сайта в кривых браузерах (нужно бизнесу)
* обезопасить ввод (нужно владельцу сайта)
* снизить объём трафа (нужно... ежам?) http://s6.pikabu.ru/post_img/2014/10/25 ... 857519.jpg - хотя если текстового трафика реально много (как на Википедии, например), то там можно получить приличную экономию
Кстати, не замерял, сколько "кушает" нормализация через intl на больших текстах? Ну, к примеру, 100 000 знаков нормализовать.
Re: Кодировка символов в таблицах для мультиязычного проекта
кинь о чем речь. по ссылке в статье не нашелrugabarbo писал(а):* обезопасить ввод (нужно владельцу сайта)
магии никакой нет - чуть больше стандартных str_replace/preg_replacerugabarbo писал(а):Кстати, не замерял, сколько "кушает" нормализация через intl на больших текстах? Ну, к примеру, 100 000 знаков нормализовать.
Re: Кодировка символов в таблицах для мультиязычного проекта
Ну вот тут https://habrahabr.ru/post/45489/ в начале идёт пример про экзотическую точку в названии домена. Наверно, он не очень хорош для демонстрации "опасности" денормализованного ввода, но суть ясна (нетривиальные кейсы возникают при фильтрации денормализованного ввода).zelenin писал(а):кинь о чем речь. по ссылке в статье не нашелrugabarbo писал(а):* обезопасить ввод (нужно владельцу сайта)
Re: Кодировка символов в таблицах для мультиязычного проекта
Вот более наглядный пример: https://habrahabr.ru/post/183878/
Кучу таких кейсов можно придумать при обработке логинов, мейлов, паролей и т.п.
Кучу таких кейсов можно придумать при обработке логинов, мейлов, паролей и т.п.
Re: Кодировка символов в таблицах для мультиязычного проекта
ага, ну это не та нормализация, о которой мы выше говорили. Это по сути и не нормализация вообще, т.к. в случае с составными символами, у нас один символ (глиф, по-моему), из разного кол-ва кодпойнтов. В случае с точкой, это просто разные символы, пусть и выглядящие похоже, но не одинаково. Такие случаи можно обрабатывать в рантайме, канонизируя данные, но нельзя канонизировать ДО попадания в БД, т.к. будет потеря данных (кейс, аналогичный html_specialchars до попадания в БД или после).
Re: Кодировка символов в таблицах для мультиязычного проекта
Ну вот я вторым постом более подходящий пример кинул.rugabarbo писал(а):Вот более наглядный пример: https://habrahabr.ru/post/183878/
Кучу таких кейсов можно придумать при обработке логинов, мейлов, паролей и т.п.
С точкой в домене действительно немного не то.
Re: Кодировка символов в таблицах для мультиязычного проекта
на самом деле это идентичный случай. речь идет о канонизации, которая происходит с визуальным изменением контента. в кач-ве решения проблемы из статью вижу два варианта: а) хранить в БД оригинальный логин и канонический, и сравнивать с каноническим, б) в БД создать индекс, канонизирующий логин (я хз поддерживает ли что-то такое - есть поддержка индекса с выражением в постгресе, но есть ли там канонизация?)rugabarbo писал(а):Ну вот я вторым постом более подходящий пример кинул.rugabarbo писал(а):Вот более наглядный пример: https://habrahabr.ru/post/183878/
Кучу таких кейсов можно придумать при обработке логинов, мейлов, паролей и т.п.
С точкой в домене действительно немного не то.
Re: Кодировка символов в таблицах для мультиязычного проекта
Ну дальше возникают ещё более интересные вопросы безопасности: что происходит при шифровании денормализованных данных? При хэшировании? При сравнении уровня БД? Уровня PHP? Происходит ли в прикладных библиотеках нормализация mb-строк? Во всех? Во всех ли одинаково? И проч.
Вообще, любая работа с денормализованным вводом вызывает вопросы безопасности.
Вообще, любая работа с денормализованным вводом вызывает вопросы безопасности.
Re: Кодировка символов в таблицах для мультиязычного проекта
utf8mb4 и collation utf8mb4_unicode_ci - на сегодняшний день являются оптимальными mysql кодировками для мультиязычных сайтов?
http://rmcreative.ru/blog/post/utf8_uni ... general_ci
http://rmcreative.ru/blog/post/utf8_uni ... general_ci
Что насчет utf8mb4_unicode_520_ci?UPD 2016: Кодировку на сегодняшний день для MySQL рекомендую utf8mb4. Collation utf8mb4_unicode_ci потому что юникод расширился несколько и в utf8 не всё влезает.