Дивіться також Як файл з китайськими символами знає, скільки байтів використовувати на символ? - без сумніву, є й інші запитання щодо ТО, які також могли б допомогти.
В UTF-8 ви отримуєте такі типи байтів:
Binary Hex Comments
0xxxxxxx 0x00..0x7F Only byte of a 1-byte character encoding
10xxxxxx 0x80..0xBF Continuation bytes (1-3 continuation bytes)
110xxxxx 0xC0..0xDF First byte of a 2-byte character encoding
1110xxxx 0xE0..0xEF First byte of a 3-byte character encoding
11110xxx 0xF0..0xF4 First byte of a 4-byte character encoding
(Останній рядок виглядає так, ніби він повинен читати 0xF0..0xF7; однак, 21-бітний діапазон Unicode (U + 0000 - U + 10FFFF) означає, що максимально допустимим значенням є 0xF4; значення 0xF5..0xF7 не можуть дійсний UTF-8.)
Перевірка того, чи відповідає певна послідовність байтів UTF-8, означає, що вам потрібно подумати про:
- Байти продовження, що з’являються там, де не передбачається
- Байти без продовження, що з’являються там, де очікується байт продовження
- Неповні символи в кінці рядка (варіація "очікується байт продовження")
- Не мінімальні послідовності
- Сурогати UTF-16
У дійсній UTF-8 байти 0xF5..0xFF не можуть відбуватися.
Не мінімальні послідовності
Існує декілька можливих зображень для деяких символів. Наприклад, символ Unicode U + 0000 (ASCII NUL) може бути представлений:
0x00
0xC0 0x80
0xE0 0x80 0x80
0xF0 0x80 0x80 0x80
Однак стандарт Unicode чітко зазначає, що останні три альтернативи не є прийнятними, оскільки вони не є мінімальними. Так трапляється, що байти 0xC0 та 0xC1 ніколи не можуть відображатися у дійсному UTF-8, оскільки єдині символи, які можуть бути закодовані ними, мінімально кодуються як однобайтові символи в діапазоні 0x00..0x7F.
UTF-16 Сурогати
У базовій багатомовній площині (BMP) значення Unicode U + D800 - U + DFFF зарезервовані для сурогатів UTF-16 і не можуть бути закодованими у дійсній UTF-8. Якби вони були дійсними в UTF-8 (що, наголошую, вони не є), тоді сурогати були б закодовані:
- U + D800 - 0xED 0xA0 0x80 (найменший високий сурогат)
- U + DBFF - 0xED 0xAF 0xBF (найбільший високий сурогат)
- U + DC00 - 0xED 0xB0 0x80 (найменший низький сурогат)
- U + DFFF - 0xED 0xBF 0xBF (найбільший низький сурогат)
Погані дані
Отже, ваші БАД-дані повинні містити зразки, що порушують ці різні приписи.
- Байт продовження, якому не передує одне з початкових значень байтів
- Багатосимвольні початкові байти, за якими недостатньо байтів продовження
- Не мінімальні багатобайтові символи
- Сурогати UTF-16
- Недійсні байти (0xC0, 0xC1, 0xF5..0xFF).
Зверніть увагу, що позначка порядку байтів (BOM) U + FEFF, вона ж простір без розриву нульової ширини (ZWNBSP), не може відображатися в UTF-8 без кодування - байти 0xFF і 0xFE не допускаються в дійсній UTF-8. Зашифрований ZWNBSP може відображатися у файлі UTF-8 як 0xEF 0xBB 0xBF, але специфікація техніки є абсолютно зайвою в UTF-8.
У Unicode також є деякі не символи. U + FFFE і U + FFFF - два таких несимволи (і останні дві кодові точки в кожній площині, U + 1FFFE, U + 1FFFF, U + 2FFFE, U + 2FFFF, ... U + 10FFFE, U + 10FFFF - це інші ). Зазвичай вони не повинні відображатися в даних Unicode для обміну даними, але можуть відображатися в приватному користуванні. Дивіться посилання на поширені запитання Unicode, щоб отримати безліч неприємних деталей, включаючи досить складну історію несимволів в Unicode. ( Виправлення №9: Роз’яснення щодо нехарактерів , яке було опубліковане в січні 2013 року, робить те, що вказує його назва - уточнює значення несимволів )