История изменений

Да он бред пишет. Насколько мне известно, Python, JavaScript и даже Java строки внутри хранят как 4-байтные кодепоинты (с таблицей юникода вроде совпадает). Так что для определения длины строки достатчоно ее длину в байтах поделить на 4. В UTF-8 и другие кодировки строки конвертируются только при выводе [в файл]. Базы данных такие как MySQL так же строки хранят в 4-х байтной кодировке (или 3-х, точно не помню). Об этом можно было и догадаться: смена кодировки баз или таблиц проходит мгновенно без перезаписи всех файлов с данными. Таким образом, использование однобайтных кодировок уменьшит лишь вес страниц, которые отдаются пользователю, но никак не скажется на размере тех же баз данных… Он еще упомянул что для определения длины строки нужно ее всю прочитать. Это верно только для PHP (функции с преффиксом mb_, например, mb_strlen) создатели которого решили не заморачиваться со всеми этими кодировками и строки у них - это просто байты (сишный char), тот же strlen там покажет sizeof(char[])/sizeof(char)

Да он бред пишет. Насколько мне известно, Python, JavaScript и даже Java строки внутри хранят как 4-байтные кодепоинты (с таблицей юникода вроде совпадает). Так что для определения доины строки достатчоно ее длину в байтах поделить на 4. В UTF-8 и другие кодировки строки конвертируются только при выводе [в файл]. Базы данных такие как MySQL так же строки хранят в 4-х байтной кодировке (или 3-х, точно не помню). Об этом можно было и догадаться: смена кодировки баз или таблиц проходит мгновенно без перезаписи всех файлов с данными. Таким образом, использование однобайтных кодировок уменьшит лишь вес страниц, которые отдаются пользователю, но никак не скажется на размере тех же баз данных… Он еще упомянуд что для определения длины строки нужно ее всю прочитать. Это верно только для PHP (функции с преффиксом mb_, например, mb_strlen) создатели которого решили не заморачиваться со всеми этими кодировками и строки у них - это просто байты (сишный char)