Насколько опасно применение юникода в продакшн?

Шёл 2012 год...

Да, UTF-8 очень глючный и приводит постоянно к багам на сайтах. Используй ASCII - очень удобно и без багов.

Даже не знаю с чем сравнить. А! Вот: ASCII - это как PHP: удобно, минималистично, быстро. UTF-8 - Это как Python: некрасиво, неочевидно, костыльно.

В общем, все правильно, не используй юникод нигде.

если пишете на QBasic под DOS - используйте ascii

современные языки и операционные системы замечательно работают с уникодом - с ними используйте уникод

Вставлю свои 5 копеек:

а сайт с юникодом еще и в ~2 раза «тяжелее»...

А я слышал, что в ПХП проблемы с юникодом. Это правда?

точнее так: «сайт с utf-8, на котором все символы (включая разметку) отличаются от ASCII, в два раза тяжелее (без учёта http заголовков)»

Если он будет для англоязычных пользователей - то столько же будет весить.

Ну так мы-то на русскоязычном сайте. Так что, если сайт с юникодом и содержит в основном текстовую информацию, он будет примерно в 2 раза «тяжелее», чем на нормальной восьмибитной кодировке.

не, если сайт будут делать те, у кого до сих пор проблемы с «обработкой utf-8 строк», то сайт в любом случае будет весить больше на ту кирпичную стенку, которую они высрут пока будут разбираться с этой самой «обработкой utf-8 строк»

А если с картинками, то вообще пофиг.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-2939 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-2932 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-1192 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-5017 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-5016 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-3870 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-1666 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-3009 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-2705 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-1633

Учитывая всё это и многое другое возникает мнение что весьма сомнительно использовать юникод на сайте рассчитанном исключительно на англоязычных пользователей. Слишком он сложный, слишком много правил => как следствие много багов в реализации работы с ним. Хочется минимизировать security risks.

вы про какой уникод? их много

юзай UTF8 Люк.

и если уж совсем клиника ознакомся w3 и rfc на тему кодировок

[spam]ユニコードちやんはよいこだ[/spam]

Поясните в чём различие между UTF8 Люк и юникод. Где можно подробнее об этом почитать? Какой конкретно rfc?

в интернете. у пайка с томпсоном про utf8 rfc вроде не было , про кодировки были.

если коротко UTF8 правильный уникод остальные уникоды нет ;) баги при парсинге utf8 менее летальны чем при парсинге UTF16,32 etc

UTF8 это 00-127 коды совпадают с аски , если байт с ведущим 1 то это часть мультибайта (смотри вику там просто и крассиво)

краCCиво

кстати, ты не тот самый китаец «Нннада»?

Поясните в чём различие между UTF8 Люк и юникод. Где можно подробнее об этом почитать? Какой конкретно rfc?

http://local.joelonsoftware.com/wiki/Абсолютный_Минимум,_который_Каждый_Разра...

Поясните в чём различие между UTF8 Люк и юникод.

ссылка

Какой конкретно rfc?

Скорее всего этот хотя не уверен.

Интересный ресурс, взял на заметку.

А я слышал, что в ПХП проблемы с юникодом.

Иногда выскакивают при хитрой обработке строк.

баги при парсинге utf8 менее летальны чем при парсинге UTF16,32 etc

Достаточно спорное утверждение учитывая:

UTF-8 uses one byte for any ASCII characters, which have the same code values in both UTF-8 and ASCII encoding, and up to four bytes for other characters. UCS-2 uses two bytes for each character but cannot encode every character in the current Unicode standard. UTF-16 extends UCS-2, using four bytes to handle each of the additional characters.

Работать с потоком в котором каждый character может занимать разное количество байт сложнее и более error-prone чем с потоком символов где каждый character занимает определённое кол-во байт. К примеру что бы escape текст для SQL query код может неправильно интерпретировать длину какого то символа либо на стороне веб приложения либо на стороне DB, как результат - SQL injection.

сайт с utf-8, на котором все символы (включая разметку) отличаются от ASCII, в два раза тяжелее (без учёта http заголовков)

Чито? Ты цифиры ни какие нигде не перепутал?

когда есть уровни абстракций которые нужно учитывать - вместо воспринимают как сложный монолитный механизм - тады Ой.

в мульти байт постояной длины есть следующие глюки при байт-шинковке среды передачи : неправильный порядок кусочков; сбой границы мультибайта.

выж не работаете с потоком на уровне битов , ниблов?

либо вы работаета на уровне байтов

либо вы работаете на уровне символов(рун)

если у вас аксиома символ это байт (в чём PHP помогает) тада у вас течёт абстракция символ - и праздник с безопасностью.

сайт с utf-8, на котором все символы (включая разметку) отличаются от ASCII, в два раза тяжелее (без учёта http заголовков)

Чито? Ты цифиры ни какие нигде не перепутал?

Вообще если говорить о производительности основная проблема не в этом. А в том что к примеру вычисление длины строки в UTF-8 намного медленнее чем ASCII строки. Операция string - намного медленнее с UTF-8 особенно если i большое число.

если у вас аксиома символ это байт (в чём PHP помогает) тада у вас течёт абстракция символ - и праздник с безопасностью.

К примеру если MySQL ожидает строку в UTF-8 а в PHP mysql_real_escape_string неправильно определит длину символа стоящего в строке перед '\' тогда '\' станет частью этого символа => SQL injection. Я уже не говорю о возможных buffer overflow в C коде работающем с UTF-8.

не храните внутрение данные во внешнем формате.

Вам лединец?

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

и без utf8 в 80тых с танцем и плясками переполняли буфера .

у вас то фобия на utf8 ?

Речь и не идёт о том что баг в самом UTF8 (это как вообще?). Речь идёт о том что больше возможностей напутать с тем же буфером при использовании UTF8. Конечно программист ошибся, но от этого не легче будет когда багом кто то воспользуется. Тем более учитывая что программисты щас легкомысленные пошли.

не храните внутрение данные во внешнем формате.

Хранить BINARY в DB. А как же ORDER BY?

Я просто оставлю это здесь.

чел советующий utf16 при байториентированой(8бит) системе передачи данных - неадекват и писатель своего идеального мира.

факт 7битная кодировка(ascii) - обмена данными на протяжении 60(борьба с эдсак) 70x(рост и тотализация 000-177) поэтому ascii так много следовательно utf8.

не перепутал

для не аски символов utf-8 обычно использует 2 байта (для наиболее часто употребляемых)

Человек, предлагающий UTF-8 для worldwide приложений - неадекват и не видел ни разу индусокода, который работает со строками бинарно и по правилу «1 байт - 1 символ». Живительный UTF-16 таких криворучек лечит принудительно.

это

Быдлокодер-неадекват по ссылке какой-то.

драйвер MySQL для Perl ВООБЩЕ всегда) просто напросто наплюет на все ваши старания и вернет вам те самые строки, которые - ну вы поняли - обычные

Да ну?

mysql_enable_utf8
This attribute determines whether DBD::mysql should assume strings

stored in the database are utf8. This feature defaults to off.

When set, a data retrieved from a textual column type (char, varchar,

etc) will have the UTF-8 flag turned on if necessary. This enables
character semantics on that string

Но ведь только для не аски! При чем тут разметка?

Заюзаю iso-8859-1 и всё. Ну и нафиг этот зоопарк непонятных символов на англоязычном сайте.

Живительный UTF-16 таких криворучек лечит принудительно.

Как раз таки нифига не лечит. Они просто начинают считать, что символ==2 байта и всё. Так уж либо utf-32, либо utf-8, а utf-16 это какие-то ненужные полумеры.

Э... Для этого внутри интерпритаторов юзается свое представление строк. А на выход отдается как надо. Да и не всякая операция string медленнее.

Покажите блин UTF-16 разрабам ActiveState - хай запилят адекватное автодоплонение в Komodo для файлов в UTF-#, для Tcl. А то для PHP работает нормально, а для Tcl определяет длину файла по количеству символов.

разметка тоже текст и тоже занимает место

я лишь уточнил высказывание другого пользователя:

«сайт с юникодом еще и в ~2 раза „тяжелее“»

до такого:

«сайт с utf-8, на котором все символы (включая разметку) отличаются от ASCII, в два раза тяжелее (без учёта http заголовков)»

т.е. если разметка в аски, то двух раз не получим

Как раз наоборот. UTF8 в том числе расчитан и на то, что он будет корректно обработан программы, не знающими про UTF8. Все технические операции - копирование, поиск подстроки - выполняются одинаково (разве что поиск 1 символа тоже становится поиском подстроки). Различия начинаются только когда речь идёт про количество (например, для вычисления длины строки, чтобы расположить её по центру экрана) и индексы символов. Но это нужно уже реже. UTF8 имеет чёткие правила по извлечению символов (хотя и требует больше операций). Но надо просто использовать функции стандартной библиотеки, а не городить собственные костыли.

живительный любитель utf16- бондажа и повелительниц .

если и использовать постоянодлинный формат представления то тогда уж 4 байтный ибо не все размера алфавита уникода больше 70тыс. так что utf16 не решая проблемы мультибайта переводит в вопрос один или два слова занимает символ

очередное подтверждение что Java очень адекватен своим пользователям.

клиника.

Перепиши еще раз, но на русском языке, а то парсер сегфолтится.

Ссылка выше. Там как раз рассказано к чему приводит позволение считать «иногда» символ за 1 байт.

Откуда «англоязычный» сайт, если я тебе говорил про worldwide?

А... ну тогда я тебя не допонял. Сорри.

Работать с потоком в котором каждый character может занимать разное количество байт сложнее и более error-prone чем с потоком символов где каждый character занимает определённое кол-во байт.

2 байта недостаточно для представления всех символов, поэтому считать 2 байта = 1 символ это плохое решение в случае UTF-16. А UTF-32 это overkill.

SQL injection

Плох тот язык (или библиотека), в котором приходится данные запихивать в строку запроса и эскейпить.

юникод не обязан помещатся в 16 бит .

следовательно если использовать кодирование постояной длины то 4 байта .

следовательно Java решение палиатив.

В utf-8, в отличии от ASCII, есть неправильные последовательности. Всякие пыхыпы обычно относятся к utf-8 как к потоку байт. В результате такая невалидированная последовательность может попасть в БД и позже вызвать сбой при попытке её обработки. Это в теории.

ээээ там неединственность отображение кодепоинта в битовую последовательность и как следстивие нерегламентрованое поведение софта если последовательность не стандартна(а имеено имеется более короткая для этого же кодепоинта)

а если уж изгалятся то и контролсимволы(00-31 и 127) тоже не всегда и везди одинково обрабатываются и что после этого тока 32-126 использовать? + \n ?