Java UTF-8 Испорченный тестовый пример подходит?

Question

Я прошёл тестовый код JDK, чтобы увидеть, как они проверяют, работает ли их UTF8.encode (), как и ожидалось, поскольку у нас есть похожие случаи. Некоторые тестовые случаи, которые я не до конца понимаю, почему это неверно.

1. (byte)0xC0, (byte)0x80}, // неверный первый байт

https://github.com/frohoff/jdk8u-jdk/blob/master/test/sun/nio/cs/TestUTF8.java#L276

двоичный файл 11000000 10000000, который подходит для формата 2 байта utf8: 110xxxxx 10xxxxxx

(байт) 0xE0, (байт) 0x80, (байт) 0x80}, // U + 0000 с нулевым заполнением

https://github.com/frohoff/jdk8u-jdk/blob/master/test/sun/nio/cs/TestUTF8.java#L287

Binary - это 11100000 10000000 10000000, который также выглядит как хороший 3-байтовый кодированный utf8.

Может кто-нибудь помочь мне понять это?

Answer 1

Я полагаю, что возражение состоит в том, что это не канонично.

C0, 80 приводит к 11 битам нуля для символа Unicode, который равен U + 0000. Это должно быть закодировано как один байт нуля.

Аналогично для второго примера.

Стандарт UTF-8 требует кодирования самой короткой длины.

Answer 2

UTF-8 требует, чтобы кратчайшая возможная последовательность использовалась для кодовой точки.

Все, что начинается с 0xc0, представляет кодовую точку, которая находится в диапазоне 00000 000000–00000 ffffff, который составляет 0–63 десятичного числа, что означает, что это может быть выражено как один байт. Другими словами, любая кодировка 11000000 10yyyyyy должным образом кодируется как просто 00yyyyyy.

То же самое относится к 0xe0 0x80 0x80.

Из спецификации UTF-8 :

Реализации вышеописанного алгоритма декодирования ДОЛЖНЫ защищать от декодирования недопустимых последовательностей. Например, наивная реализация может декодировать сверхдлинную последовательность C0 80 UTF-8 в символ U + 0000 или суррогатную пару ED A1 8 C ED BE B4 в U + 233B4. Декодирование недопустимых последовательностей может иметь последствия для безопасности или вызывать другие проблемы.