Комментарии 51
Спасибо, интересно, конечно.
Но последнее заблуждение не было развенчано: было показано, что кроме Юникода есть много других тяжелых и плохо спроектированных технологий, и, косвенно, было подтверждено, что Юникод находится с ними в одном ряду. Так что, скорее, миф в тексте был обоснован и подтверждён.
Тут, скорей, как в "Собачьем сердце" – "так ведь других-то нет". Нет сейчас никакой разумной альтернативы юникоду...
кроме Юникода есть много других тяжелых и плохо спроектированных технологий
Тут я немного с Вами не согласен. Дело в том, что Юникод нельзя описать как единожды спроектированную систему. И в статье об этом явно написано. Проблема в том, что Юникод формировался постепенно "пластами" если можно так выразиться. И это проблема не только Юникода, а и многих других систем существующих сколько-нибудь продолжительное время.
Развитие стандарта шло не по прямой, а блуждало, что можно отследить в нарушенных принципах построения.
Теперь я на шаг ближе к пониманию почему на youtube такая странная сортировка каналов по алфавиту
aA-zZ А-Яа-я
Спасибо, много нового открыл для себя
Спасибо за статью!
T-Index указывает, что если продукт переведён на английский, испанский и упрощённый китайский, то получены 50 % потенциала мировых продаж. Чтобы получить 90 %, нужно перевести продукт на 16 языков. ImminentАга, а 15-ая строка таблицы «индийские языки», которых, к слову, кроме упомянутых в таблице хинди и английского еще 21 (!) штука :-)
В заблуждении 5 органично бы вписалась ссылочка на ICU MessageFormat
Заблуждение 8. Регистров два, их легко поменять
Заблуждение 8.2: Текст после toLowercase(toUppercase(x)) будет иметь ту же длину в байтах, если символы после преобразования совпадают.
недавно столкнулся с этим при работе с армянским языком. У них есть буква "ев" - և. Она не имеет заглавного написания, и предлагается использовать буквы, составляющие её: Ե - "е" и Ւ - "в". При этом Ւ из официального алфавита даже исключена.
Код:
<?php
$source_string = 'և';
$uppercase = mb_strtoupper($source_string);
$lowercase = mb_strtolower($uppercase);
// печатаем строки
var_dump($source_string, $uppercase, $lowercase);
// печатаем их представление
var_dump(bin2hex($source_string), bin2hex($uppercase), bin2hex($lowercase));Результат в php 8.2.1:
string(2) "և"
string(4) "ԵՒ"
string(4) "եւ"
string(4) "d687"
string(8) "d4b5d592"
string(8) "d5a5d682" Удивительно, что способ кодирования одной и той же строки поменялся при визуальном сохранении написания. Вижу здесь простор для багов на сравнение строк.
Так это тот же случай, что описан в статье о немецкой ß. ToUpper(ß) = SS, ToLower(SS) = ss.
Или я что-то не понял?
скорее да, чем нет.
Тут я акцентирую внимание на том, что визуально всё осталось тем же самым.
попробуйте в текстовом редакторе соединить буквы ե ւ без пробела между ними, и увидите, что они заменяются на одну исходную букву եւ, для которой в рамках этого же алфавита вообще-то заведён отдельный символ. Более того, в середину եւ даже можно воткнуть курсор, а в середину և - нет.
при визуальном сохранении написания
У меня на телефоне это не так
Этот мир ещё страшнее, чем я думал.
Потому что вот как оно выглядит на маке
Спойлер
добрался до компьютера, проверил хром и фф под линуксом, яб под виндой — все показывают два символа.
как правильнее — не знаю, сходу придумываются аргументы за оба варианта
А потому что мак "знает лучше" и по умолчанию шрифты там хитрые. Некоторые комбинации символов подменяются одним единым "более красивым", оказывая вам медвежью услугу.
Проблемы бывают в неожиданных местах. Например, с русским языком.
Символы ё и й могут быть представлены по-разному. Один вариант - это кодирование символа одним код-поинтом, второй вариант - двумя (первый базовая буква е/и, второй - модификация).
При этом, на системах от Apple используется второй вариант, а на Windows - первый. Но обе системы отображают оба варианта. Разница заметна только если копаться в байтовых представлениях (или например Far Manager не в курсе про второй вариант, показывает разорванные буквы иногда).
Теперь про сравнение строк. Есть несколько уровней сравнения: первый - accent insensitive, второй - case insensitive. В режиме сравнения без учета акцента буквы е и ё, а также и и й считаются одинаковыми. Поэтому с точки зрения механизмов сортировки довольно удобно сделать так, как делает Apple, как раз из-за наличия режима accent insensitive.
Сравнение строк. Есть равно/неравно, а есть больше/меньше. Со вторым куда больше проблем. Например, русский алфавит заканчивается: Ы Ь Э Ю Я. Украинский алфавит заканчивается: Ш Щ Ю Я Ь. Код-поинты одинаковые. Не существует порядка, удовлетворяющего двум языкам. Поэтому для сортировки нужно знать язык сортировки (локаль).
Только «е» и «ё» спутать сложнее, имея контекст из стоящих рядом слов, потому «ё» вообще чаще не используется в печатном тексте, но «и» и «й» - более существенная разница и ни разу не видел современной книги где бы вместо «й» было «и». Кстати, просто пример: «По дорожке бежала заика.» и «По дорожке бежала зайка». В случае детской сказки у ребёнка будут вопросы откуда взялась заика и кто её напугал? )
В случае детской сказки у ребёнка будут вопросы откуда взялась заика и кто её напугал?
Аналогичное возражение «не будет понятно где миръ, а где міръ» в своё время выдвигалось, но не помогло букве і
У вас какие-то ну очень устаревшие данные.
До 1993 р. буква ь (м’який знак) стояла останньою в алфавіті, тепер її переставлено на третє місце від кінця.
(Источник.)
Проблемы с порядком сортировки в зависимости от локали/культуры есть, но не в этом случае, а когда, например, lj и nj считаются одной буквой (хорватский), ŀl (каталанский)…
например Far Manager не в курсе про второй вариант, показывает разорванные буквы иногда
Да и не только он
Для тех, кто догадался в Юникод притащить цветные смайлы, должен быть заготовлен отдельный котёл в аду.
Ну, у юникода идея превосходная. Особенно UTF-8. Но исполнение так себе. Они себе поставили задачу включить все особенности всех письменностей, что по определению невозможно. Надо было упрощать до разумного предела, чтобы было "достаточно хорошо", хоть и не совсем правильно.
Но сложность правил компенсируется необязательностью их соблюдения. Так что жизнь поставит всё на своих местах и все поймут что «café» действительно стоит на последнем месте а не на первом.
упрощать до разумного предела
При таком подходе нельзя будет передать текст в юникодной кодировке и придётся выдумывать новую, особенную кодировку. Это нехорошо.
Не такая уж и прекрасная, если говорить об эффективности работы с текстом.
Такая же «гениальная» идея, как нуль-терминированные строки в Си в противовес строкам с префиксированной длиной. Чтобы взять N-ный символ нужно пробежаться в цикле по всей строке.
Я полностью поддерживаю UTF-8 как формат для хранения текстов в файлах, как формат обмена текстами между разнородными программами, разными компьютерами.
Но когда за достижение и за прогресс человеческой мысли выдают принятие UTF-8 в качестве способа представления текстов внутри программ и на уровне системных API, я недоумеваю.
Чтобы взять N-ный символ нужно пробежаться в цикле по всей строке.
Вы удивитесь, но это задача, которая встречается крайне редко. В 99% случаев приходится так или иначе сканировать всю строку. А если знаем адрес N-го символа, адрес N+1-го находится довольно эффективно.
Но когда за достижение и за прогресс человеческой мысли выдают принятие
UTF-8 в качестве способа представления текстов внутри программ и на
уровне системных API, я недоумеваю.
Альтернативы? Тратить по 4 байта на символ? Память конечно дешёвая, но не резиновая. А кеш процессора и не резиновый, и не дешёвый одновременно. Если нужен случайный доступ (что на самом деле не такой и частый случай) UTF-8 легко перекодируется в такой формат
Кстати, интересным велосипедом строки реализованы под капотом в CPython. Если в строке только ASCII — будет использоваться один байт на символ. Если добавить туда кириллицы — вся строка перекодируется под самый широкий, и будет занимать два байта на символ. Получается компромисс между экономией памяти и скоростью случайного доступа. Правда, может выйти забавный казус, когда добавление одного символа в строку внезапно раздует её в 4 раза :D
Альтернативы?
Альтернатива — остановиться на UCS-2 в свое время и не педалировать совершенно утопическую идею, что нам нужна поддержка египетских иероглифов, древнешумерского письма, письменности клингонов (!!!) и цветных смайликов.
То есть я не против UTF-8 в файлах (тексты, XML, исходники), в HTTP и сетевых протоколах вообще, а только за. Но внутри программ и на уровне API ОС — UCS-2.
Как и сделали люди из Microsoft с самых первых годов существования Windows NT.
Но внутри программ и на уровне API ОС — UCS-2.
А потом выясняется, что пользователю очень нужно создать файл с именем на клинкогском языке с добавлением цветных смайликов но нет, ОС этого не умеет. Почему, спрашивается, если в файле все можно писать спокойно?
Потом появится расширение которое такое позволяет, и будет ситуация ещё хуже чем была
Когда то считалось, что всему миру (мир тогда ограничивался США) хватит US-ASCII, к чему это нас привело можно посмотреть на стандарты того времени. Юникод в них всё равно вставили, но адскими костылями, и до сих пор полноценно не работает и поддерживается не везде
Компьютеры на самом деле быстрые, очень быстрые. Да, может электрон это уже слишком, но работающий без проблем и лишних вопросов текст — однозначно маст-хев за свои деньги, это прям фунтаментальная вещь которая должна работать надёжно
Как и сделали люди из Microsoft с самых первых годов существования Windows NT.
Забавно читать, когда весь зоопарк с кодировками который вообще случается у меня в жизни имеет корни в продуктах майкрософт :p
С линуксом я вообще забыла, что бывают разные кодировки и какие-то проблемы с их совместимостью. Но периодически приходится взаимодействовать с форточным миром, и вот оттуда уже прилетает что попало
Компьютеры на самом деле быстрые, очень быстрые.
И узкое место очень часто не процессор, а размер оперативной памяти/кеша. Если мы можем срезать размер ~70% строк в два раза, ценой чуть-чуть более сложной обработки в некоторых случаях — это однозначно окупится. Zram — окупается, и позволяет запускать то, что на компьютере иначе бы физически не запустилось. Сжатие указателей в джаве, которое требует делать сдвиги на каждое разыменование — окупается и включено по умолчанию. Потому что пара инструкций для сдвига — ничто, по сравнению с тем, какой буст даёт попадание в кеш
Я сочувствую всем любителям и особенно носителям клингонского, но есть гораздо более важный символ, который нельзя использовать в именах файлов. Это косая черта (/). Он популярен во многих сферах, например, в бухгалтерии. Он используется во многих культурах как разделитель в датах. Наконец, была целая операционная система OS/2, которая не могла в честь себя назвать свою же директорию. И всем пофиг, всем нужны цветные смайлики...
Использовать можно свободно, но побочный эффект — файлы сгруппируются по датам, или чему-то ещё :D
Это не баг, это фича!
Хм, а на что бы его можно было заменить? Кажется, любой символ имеет какую-то культурную нагрузку. Даже обратная косая, которая тут напрашивается в качестве первого (очевидного, но в итоге неправильного) ответа.
(Да, отсутствие такого символа это очевидная недоработка ASCII. Но кто ж знал, когда его создавали...)
Unicode-enabled functions are described in Conventions for Function Prototypes. These functions use UTF-16 (wide character) encoding, which is the most common encoding of Unicode and the one used for native Unicode encoding on Windows operating systems. Each code value is 16 bits wide, in contrast to the older code page approach to character and string data, which uses 8-bit code values. The use of 16 bits allows the direct encoding of 65,536 characters. In fact, the universe of symbols used to transcribe human languages is even larger than that, and UTF-16 code points in the range U+D800 through U+DFFF are used to form surrogate pairs, which constitute 32-bit encodings of supplementary characters. See Surrogates and Supplementary Characters for further discussion.
Ооппаньки…
На самом деле переход от UCS-2 к UTF-16 там случился ещё в 1990-х. [irony] Видимо, вам не доложили.[/irony]
Ну и там же сразу про кодпункты-модификаторы и прочее, из-за чего проблемы суррогатного представления юникода в UTF-16 мгновенно теряют значимость.
«Résumé» позволяет избегать путаницы с другими значениями слова «resume».
Не могу не придраться, отметив, что résumé и resume это вообще разные слова, с разным произношением и разной этимологией. Не совсем корректно их называть «значениями слова».
Греческий вопросительный знак ; визуально выглядит как обычная точка с запятой, но компилятор языков семейства C его не примет.
Вот это интересно, пользуюсь греческой раскладкой, и был уверен, что там обычная точка с запятой.
Заблуждение-0:
- строки можно сравнить
- ну или хотя бы "в мире хоть кто-то знает как можно сравнить две строки на равенство".
Ответ: нет и нет.
Unicode предполагает 4 формы нормализации строк (для сравнение на равенство), все 4 нужны в разных случаях именно потому, что не существует "технического", способа сравнить строки на равенство.
И без вникания в "бизнес логику" непонятно какой способ вам подходит.
Ещё интересные картинки тут:
https://www.unicode.org/reports/tr15/#Canon_Compat_Equivalence
Несколько слов в английском пишутся с буквами, которых в обычном алфавите языка нет. Поскольку на клавиатуре эти символы отсутствуют, «façade», «naïve» и «piñata» постепенно всё сильнее проигрывают более простым вариантам «facade», «naive» и «pinata» в популярности
В английском языке нет букв ç, ï, ñ. Следовательно, и слов, содержащих эти буквы, в английском языке нет и быть не может. Это слова какого-то другого языка, которые могут присутствовать в английском (а также в русском, китайском и любом другом) тексте, но они не становятся словами этого языка. А вот будучи позаимствованными, что неизбежно ведёт к подгонке под алфавит, они могут и войти в язык. Поэтому слово facade вполне может быть и есть в английском языке, пусть и является заимствованным, а вот слова façade в английском языке нет и быть не может. Также как в русском языке нет слова computer, а компьютер есть.
Для чисел от 2 по 4 нужно существительное в единственном числе родительного падежа («3 вакансии»), для чисел от 5 до 9 нужны существительные во множественном числе родительного падежа («5 вакансий»).
На практике, для упрощения, в таких случаях делается одно наиболее универсальное склонение. Получаются немного неправильные конструкции типа "2 вакансий", но это допустимый дефект перевода - и смысл, и причины его появления довольно очевидны. В некоторых случаях можно использовать вполне грамотную конструкцию "Вакансий: 2".
MR: название лица, то есть форма обращения
Не очень понятно, зачем это вообще нужно. Выглядит как ВКонтакте с настройкой на дореволюционный язык интерфейса.
«façade», «naïve» и «piñata»
Затем вы говорите так, будто я не дал контрпримеров:
В английском языке нет букв ç, ï, ñ. Следовательно, и слов, содержащих эти буквы, в английском языке нет и быть не может.
Заимствованные слова становятся частью языка, в который попадают.
Допустим, это не так. Тогда что получится: когда американец на письме использует слово «façade», он переходит на французский, а когда «piñata» — на испанский? Очевидно, что он продолжает говорить на английском. Выходит, что эти слова — часть английского языка. В том числе частью английского языка становятся используемые в них буквы.
вот слова façade в английском языке нет и быть не может
Вот это слово в Кембриджском словаре. Кстати, попробуйте набрать на этом сайте в строке поиска «facade» — будет перенаправление на страницу «façade».
Надо бы развеять заблуждения по этому поводу:
- Хотя формально в английском алфавите 26 букв, на письме встречаются символы с диакритическими знаками. Если их опустить, ошибки не будет, но желательно иметь возможность для их записи.
- Эти знаки встречаются не только в редких заимствованных словах. Пример: «fiancé» (жених) и «fiancée» (невеста) — слова популярные, какие бы не бушевали в нашем мире попытки гендерно-отнейтралить язык.
- Нет, даже цифровизация процесс ухода от диакритики подстегнула слабо (если это вообще произошло). Вообще-то типографский станок изобрели в XV веке, но за шестьсот лет книгопечатания вопрос до сих пор не разрешился. А сейчас текст набирают на тач-клавиатурах смартфонов, где умные алгоритмы сами подменяют «cafe» в «café».
- Эти знаки встречаются не только в заимствованных словах. Речь про диарезис, который ставят для указания, что две идущие подряд гласные произносятся как два звука. Ну ладно, «coöperate» вместо «cooperate» пишут разве что журнал «Нью-Йоркер» и несколько зануд.
Если вы хотите посмотреть, как дела обстоят в реальном мире, то вот: ради интереса я набрал в «Уорде» четыре слова в локали софта
en-US теми буквами, что есть на обычной клавиатуре. Для трёх из них сработала автозамена.
При этом текстовый процессор ничего не спросил и не вывел никаких уведомлений о содеянном. Тем не менее если от автозамены отказаться, то «Уорд» красненьким ничего не выделит, поскольку написание «попроще» ошибкой не является.
Заблуждения программистов о тексте