Эффективное декодирование длины символа UTF-8 для ненулевого символа в 32-битном регистре

Если вы можете предположить правильную кодировку символа, вы можете просто проверить, где самый высокий ноль находится в первой кодовой единице (благодаря свойству автосинхронизации UTF-8).

Виновником является то, что для кодовых точек одной кодовой единицы старший нуль равен 7 биту. Для кодовых точек n кодовых единиц старший бит равен 7 - n (обратите внимание на "разрыв").

Предположим, что первая кодовая единица находится в al.

not al                 ;Trasform highest 0 in highest 1
bsr al, al             ;Find the index (from bit0) of the first 1 from the left
xor al, 7              ;Perform 7 - index
                       ;This gives 0 for single code unit code points
mov ah, 1
cmovz al, ah           ;Change back to 1

Обратите внимание, что bsr не определено для ввода 0, но это может произойти только для недопустимой ведущей кодовой единицы (со значением 11111111b).

Вы можете обнаружить недопустимую кодовую единицу 0xff с помощью jz <error handler> после инструкции bsr.

Спасибо @CodyGray за указание на ошибку в оригинальной версии.
Спасибо @PeterCorders за указание на трюк XOR для выполнения 7 - AL.

Если вы настаиваете на обратном порядке байтов (по какой-то странной причине), вы все равно можете просто отсканировать первый бит, равный 1, разделить на 8 и +1, чтобы получить количество байтов.

GetReversedShiftedUtf8BytesCount:
    ; eax = UTF8 code in reversed order, by from LSB
    ; 'É' (c3 89) => eax = 0x0000c389
    bsr ecx,eax
    cmovz ecx,eax   ; needed only for eax = 0
      ; ^ if eax is never 0 on input, this "cmovz" can be removed
    shr ecx,3
    inc ecx
    ret

Когда вы помещаете первый байт символа в MSB, он будет производить количество битов 15, 23 или 31 для многобайтовых символов, для 7b ASCII что-либо от 0 до 6 будет производиться bsr. «div 8» исправит их все, в любом случае, ему все равно.

Эта процедура должна фактически работать также с действительными нормальными кодами UTF8.

Для неверного кода UTF8, заканчивающегося нулевым байтом, будет возвращено неправильное количество байтов (без нулевых).

Конечно, как и всегда, также возможно решение LUT:

    movzx  ecx,al
    shr    ecx,3
    movzx  ecx,byte [utf8lengthLUT + ecx]  ; +rcx for 64b
    ; ecx = number of bytes or 0 for invalid leading byte value
    ...

utf8lengthLUT:                     ; 32B look-up table for upper 5b of 1st byte
    db     1, 1, 1, 1, 1, 1, 1, 1  ; 00000 - 00111 ; single byte
    db     1, 1, 1, 1, 1, 1, 1, 1  ; 01000 - 01111 ; single byte
    db     0, 0, 0, 0, 0, 0, 0, 0  ; 10000 - 10111 ; not valid leading byte
    db     2, 2, 2, 2              ; 11000 - 11011 ; two bytes code point
    db     3, 3                    ; 11100 - 11101 ; three bytes code point
    db     4                       ; 11110         ; four bytes code point
    db     0                       ; 11111         ; not valid leading byte

Я не отлаживал его, просто пытался перевести с помощью nasm для проверки синтаксиса. И я не профилировал его, конечно. :) Глядя на краткость этого варианта bsr, я сомневаюсь, что он будет серьезно быстрее даже на процессорах, где bsr вредит.

Но этот обрабатывает недопустимые коды операций UTF8 по-другому, вместо того, чтобы обнаруживать ненулевой MSB и возвращать его число + 1 (не чувствительно к содержимому начального байта), он правильно декодирует информацию о начальном байте и возвращает 0, когда начальные биты неверны. Но правильные начальные биты с неправильным 2-м+ байтом (например, c3 00) все равно будут возвращать 2, тогда как первый вариант в таком случае возвращает 1.

(можно использовать только 16-битную таблицу LUT, если вас не волнует недопустимая информация о начальных 11111 байтах, и вы примете это как 4-байтовую кодовую точку)

Кстати, есть некоторые библиотеки i18n (с открытым исходным кодом), выполняющие все эти действия, такие как проверка входных данных utf8, исправление неверных, подсчет символов и т. д. Некоторые из них существуют уже более десяти лет... и все еще получают ошибки. отчеты и исправления. Что является своего рода тонким намеком на то, как сложно правильно написать этот материал (не подвергая приложение какой-либо уязвимости входных данных). :)

(плюс учитывая, сколько (исправлений) правок получили эти два ответа... :))

И еще один оффтопный совет: если вы когда-нибудь попытаетесь написать что-то на PHP, то должны обрабатывать входные данные UTF8 (которые не из доверенного источника, но даже из доверенного источника), особенно если эти входные данные из ответа GET/POST. .. только не по своему усмотрению. Никогда. Получите некоторую основу для этого. :)