ну в отличие от, он собирается и работает. судя повсему он будет сразу после того как Матс решит что с продолжениями делать (continuations, как блин они по-русски правильно?).
Угу, а нормальных юникодных строк так и не будет. Определение длины не работает, выделение подстроки не работает, преобразование регистра не работает и т. д. Я пожалуй, возьму сейчас роман Л. Н. Толстого «Война и мир» в кодировке UTF-8, распечатаю на рулоне бумаге в виде последовательности шестнадцатиричных чисел, и как буду в Японии, непременно найду этого Матца, привяжу его к стулу и заставлю вручную подсчитывать количество букв в этом свитке, карандашиком млять на бумаге, пока убогий не раскается и не осознает всей глубины своего невежества.
> Если я правильно понял, есть сторонние приблуды для решения этой проблемы, нет?
Есть, но именно приблуды.
Скорее всего, определение длины и выделение подстроки со временем будет работать из коробки, хотя и несколько через жопу. Для того, чтоб количество символов в строке в кодировке UTF-8, надо прочесать всю эту строку целиком и подсчитать количество мультибайтовых последовательностей, соответствующих юникодным символам. То же самое и с выделением подстроки. Для преобразования регистра и подобных вещей надо вообще преобразовать байтовую строку в последовательность юникодных символов, потом преобразовать регистр каждого символа с помощью юникодного каталога, и полученную последовательность юникодных символов снова преобразовать в байтовую строку.
Возникает резонный вопрос: что мешает ввести такой тип данных, как юникодная строка (последовательность юникодных символов), чтоб избежать ненужных преобразований туда-сюда? Как это давным-давно сделано и в Яве, и в Питоне, и в GLib, и в Qt, например, и ещё много где.
Таблица есть, называется Unicode Character Database, http://unicode.org/ucd. Она входит в стандартную библиотеку многих языков. Обычно имеется таблица для одной кодировки с фиксированной шириной символа (обычно UCS-4, иногда UCS-2). Соответственно, эта же кодировка используется в качестве внутреннего представления юникодных строк, но это всё детали реализации, и от пользователя обычно скрыты.
> А кто мешает переопределить/сделать новый класс String с внутренним представлением в UCS? Это шибко сложно, что ли?
А кто Мацумото мешает это сделать? Такие вещи должны быть в стандартной библиотеке, а то если каждый начнёт городить свои обёртки над строками, будет бардак.
mb_strings? ну так это как раз и есть через задницу.
по теме: я посмотрел что там в коде появилось. собственно str.length для кодировки utf8, через уйму макросов, заканчивается в файлике utf8.c. что-то есть в идее своей логике для каждой кодировки, конечно.. поглядим что дальше будет.
Ну так не предназначена кодировка UTF-8 для str.length и подобных штук. Определиние длины строки в UTF-8 равнозатратно перекодировке её в UCS-4 или что-то такое. Так не лучше ли один раз это сделать и не мучиться?
Тем более, что стандартная практика работы с юникодными строками такая:
1. На входе все данные преобразуются из байтовых строк в юникодные строки.
2. Внутри программы используются только юникодные строки.
3. На выходе все юникодные строки преобразуются обратно в байтовые строки.
Кодировка ввода-вывода при этом бывает самая разная. Иногда это кодировка локали, иногда она определяется протоколом или форматом данных. Поэтому, даже если внутри программы использовать не юникодные строки, а байтовые строки с пристёгнутой к ним кодировкой, как в Руби 2, всё равно придётся перекодировать данные на входе и на выходе.
Вдобавок, надо выбрать подходящую кодировку для внутреннего представления, чтобы она содержала все юникодные символы и позволяла эффективно проделывать разные строковые операции. Такая кодировка, по-сути, одна — USC-4/UTF-32. :) Отсюда и появляется в разных языках специальный тип данных для юникодных строк. Если в Руби 2 он так и не появится, то печально.