а вот в ruby2 будут (наконец-то) кодировки на строках :-)

Когда он ещё будет, этот ruby2? Раньше perl6? :)

ну в отличие от, он собирается и работает. судя повсему он будет сразу после того как Матс решит что с продолжениями делать (continuations, как блин они по-русски правильно?).

Угу, а нормальных юникодных строк так и не будет. Определение длины не работает, выделение подстроки не работает, преобразование регистра не работает и т. д. Я пожалуй, возьму сейчас роман Л. Н. Толстого «Война и мир» в кодировке UTF-8, распечатаю на рулоне бумаге в виде последовательности шестнадцатиричных чисел, и как буду в Японии, непременно найду этого Матца, привяжу его к стулу и заставлю вручную подсчитывать количество букв в этом свитке, карандашиком млять на бумаге, пока убогий не раскается и не осознает всей глубины своего невежества.

Если я правильно понял, есть сторонние приблуды для решения этой проблемы, нет?

Ура! Уникод фтопку!

>Определение длины не работает,

А чего ты хотел от переменной длины символа?

>преобразование регистра не работает

Составь таблицу, всего 64К значений

> Если я правильно понял, есть сторонние приблуды для решения этой проблемы, нет?

Есть, но именно приблуды.

Скорее всего, определение длины и выделение подстроки со временем будет работать из коробки, хотя и несколько через жопу. Для того, чтоб количество символов в строке в кодировке UTF-8, надо прочесать всю эту строку целиком и подсчитать количество мультибайтовых последовательностей, соответствующих юникодным символам. То же самое и с выделением подстроки. Для преобразования регистра и подобных вещей надо вообще преобразовать байтовую строку в последовательность юникодных символов, потом преобразовать регистр каждого символа с помощью юникодного каталога, и полученную последовательность юникодных символов снова преобразовать в байтовую строку.

Возникает резонный вопрос: что мешает ввести такой тип данных, как юникодная строка (последовательность юникодных символов), чтоб избежать ненужных преобразований туда-сюда? Как это давным-давно сделано и в Яве, и в Питоне, и в GLib, и в Qt, например, и ещё много где.

> Составь таблицу, всего 64К значений.

Unicode != UCS-2. Значений гораздо больше.

Таблица есть, называется Unicode Character Database, http://unicode.org/ucd. Она входит в стандартную библиотеку многих языков. Обычно имеется таблица для одной кодировки с фиксированной шириной символа (обычно UCS-4, иногда UCS-2). Соответственно, эта же кодировка используется в качестве внутреннего представления юникодных строк, но это всё детали реализации, и от пользователя обычно скрыты.

А кто мешает переопределить/сделать новый класс String с внутренним представлением в UCS? Это шибко сложно, что ли?

> Определение длины не работает, выделение подстроки не работает, преобразование регистра

немного не понял, откуда такая информация?

> а нормальных юникодных строк так и не будет.

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

> А кто мешает переопределить/сделать новый класс String с внутренним представлением в UCS? Это шибко сложно, что ли?

А кто Мацумото мешает это сделать? Такие вещи должны быть в стандартной библиотеке, а то если каждый начнёт городить свои обёртки над строками, будет бардак.

> для восьмибитных кодировок

Восьмибитные кодировки не нужны.

>>Определение длины не работает,

>А чего ты хотел от переменной длины символа?

В голимом PHP всё работает. И длина, и подстроки, и регистр... А потом удивляются, что PHP захавал весь web-рынок :D

>Составь таблицу, всего 64К значений

RTFM на тему utf-8.

> В голимом PHP всё работает

mb_strings? ну так это как раз и есть через задницу.

по теме: я посмотрел что там в коде появилось. собственно str.length для кодировки utf8, через уйму макросов, заканчивается в файлике utf8.c. что-то есть в идее своей логике для каждой кодировки, конечно.. поглядим что дальше будет.

> str.length для кодировки utf8

Ну так не предназначена кодировка UTF-8 для str.length и подобных штук. Определиние длины строки в UTF-8 равнозатратно перекодировке её в UCS-4 или что-то такое. Так не лучше ли один раз это сделать и не мучиться?

Тем более, что стандартная практика работы с юникодными строками такая:

1. На входе все данные преобразуются из байтовых строк в юникодные строки.

2. Внутри программы используются только юникодные строки.

3. На выходе все юникодные строки преобразуются обратно в байтовые строки.

Кодировка ввода-вывода при этом бывает самая разная. Иногда это кодировка локали, иногда она определяется протоколом или форматом данных. Поэтому, даже если внутри программы использовать не юникодные строки, а байтовые строки с пристёгнутой к ним кодировкой, как в Руби 2, всё равно придётся перекодировать данные на входе и на выходе.

Вдобавок, надо выбрать подходящую кодировку для внутреннего представления, чтобы она содержала все юникодные символы и позволяла эффективно проделывать разные строковые операции. Такая кодировка, по-сути, одна — USC-4/UTF-32. :) Отсюда и появляется в разных языках специальный тип данных для юникодных строк. Если в Руби 2 он так и не появится, то печально.

>mb_strings? ну так это как раз и есть через задницу.

И чем оно через задницу? Стандартная фишка в официальной реализации, отлично работает уже далеко не один год.

> есть сторонние приблуды для решения этой проблемы, нет?

Да есть, причём уже не совсем сторонние а включённые в Rails Core, но всё таки эта прибулуда...

> И чем оно через задницу? Стандартная фишка в официальной реализации, отлично работает уже далеко не один год.

Ну если это не через задницу, тогда в руби тоже всё ок. точно так же.