Каковы различия между utf8_general_ci и utf8_unicode_ci? [дубликат]
Я знаю, что на это уже много раз отвечали, но вот мои два цента на этот вопрос.
Я нашел ответы samvermette и ribeto очень полезными, а также комментарий maxpower в ответе ribeto . , Но есть проблема с этими подходами. Проблема, о которой Мэтт упоминает в ответе samvermette , заключается в том, что если пользователь хочет вставить что-то с разрывом строки внутри, клавиатура будет скрываться без вставки чего-либо.
Таким образом, мой подход представляет собой смесь трех вышеупомянутых решений и проверяет, является ли введенная строка новой строкой, когда длина строки равна 1, поэтому мы проверяем, что пользователь печатает вместо вставки.
Вот что я сделал:
- (BOOL)textView:(UITextView *)textView shouldChangeTextInRange:(NSRange)range replacementText:(NSString *)text {
NSRange resultRange = [text rangeOfCharacterFromSet:[NSCharacterSet newlineCharacterSet] options:NSBackwardsSearch];
if ([text length] == 1 && resultRange.location != NSNotFound) {
[textView resignFirstResponder];
return NO;
}
return YES;
}
2 ответа
utf8_general_ci - это очень простая - а в Юникоде очень сломанная - сортировка, которая дает неверные результаты для общего текста Юникода. Что он делает:
- преобразует форму нормализации Unicode D для канонической декомпозиции
- удаляет любые объединяющиеся символы
- преобразует в верхний регистр
Это не работает правильно в Unicode, потому что он не понимает регистр Unicode. Сам по себе регистр Unicode намного сложнее, чем может справиться подход, ориентированный на ASCII. Например:
- Нижний регистр «» - это «ß», а верхний регистр «ß» - «SS».
- Есть две строчные греческие сигмы, но только одна прописная; рассмотрите «Σίσυφος».
- Такие буквы, как «ø», не разлагаются на «o» с диакритическим знаком, что означает, что он не будет правильно отсортирован.
Есть много других тонкостей. Немецкая буква ß (U + 00DF LETTER SHARP S) сортируется рядом с "ss" Буква Œ (U + 0152 LATIN CAPITAL LIGATURE OE) сортируется рядом с "OE".
utf8_general_ci не поддерживает расширения / лигатуры, сортирует
все эти буквы как отдельные символы, а иногда и в неправильном порядке.
utf8_unicode_ciобычно более точен для всех скриптов. Например, на кириллическом блоке:utf8_unicode_ciподходит для всех этих языков: Русский, болгарский, белорусский, македонский, сербский и украинский. Пока utf8_general_ci подходит только для русского и болгарского подмножества кириллицы. Дополнительные буквы, используемые в белорусском, македонском, сербском и украинском языках. отсортированы не очень хорошо.
Стоимость utf8_unicode_ci заключается в том, что это маленький бит
медленнее, чем utf8_general_ci . Но это цена, которую вы платите за правильность. Либо у вас может быть быстрый ответ, который неверен, либо правильный ответ немного медленнее. Твой выбор.
Очень сложно когда-либо оправдать неправильные ответы, поэтому лучше предположить, что utf8_general_ci не существует, и всегда использовать utf8_unicode_ci . Ну, если вы не хотите неправильных ответов.
Источник: http://forums.mysql.com/read.php?103,187048,188748#msg-188748
Из Наборы символов Unicode в документации MySQL :
Для любого набора символов Unicode операции выполняются с использованием
_general_ciсопоставление выполняется быстрее, чем сопоставление_unicode_ci. Например, сравнения для параметров сортировкиutf8_general_ciбыстрее, но немного менее корректны, чем сравнения дляutf8_unicode_ci. Причина этого в том, чтоutf8_unicode_ciподдерживает сопоставления, такие как расширения; то есть, когда один символ сравнивается как равный с комбинациями других символов. Например, в немецком и некоторых других языках «ß» равно «ss».utf8_unicode_ciтакже поддерживает сокращения и игнорируемые символы.utf8_general_ci- это устаревшее сопоставление, которое не поддерживает расширения, сокращения или игнорируемые символы. Он может производить только однозначное сравнение между символами.