Хз куда такое постить, поэтому сюда Имеется юзерский пост на сайте. В содержимом поста - текстовое поле. Это текстовое поле засылается в Apache Solr (но это наверно и не важно). В текстовом поле имеется последовательность байт, из-за которой Solr выдает ошибку "Invalid UTF-8 start byte 0xbf". Юзер писал "wi-fi", но вместо дефиса у него каким-то образом оказалась последовательность из трех байт: EF BF BE. Эту последовательность конечно можно просто вырезать, но нужно какое-то более общее решение, которое избавит от необходимости коллекционировать всевозможные невалидные последовательности. При этом гуглеж на тему php fix broken utf-8 выдал кучу рецептов (iconv, и прочее), и ни один из них не помог - эту последовательность они не меняют. В MySQL в JSON-поле этот текст тоже складывается без ошибок. Запрос в Solr делается через XML, то есть, возможно, последовательность является невалидной не с точки зрения UTF-8, а с точки зрения UTF-8 внутри XML. Или же у XML более строгие правила, то есть последовательность невалидна и там и там, но значимость ошибки в XML выше. Здесь видимо надо шарить в байтовой структуре UTF-8, в которой я не шарю. Кому-нибудь что-нибудь говорит эта последовательность EF BF BE? Что с ней не так?
EF BF BE? может EF BF BD? если да, то это замещающий символ, если нет, то это хз что, нет такого символа: https://apps.timwhitlock.info/unicode/inspect?s=
На википедии подробно описано как кодируется UTF-8: EF BF BE 11101111 10111111 10111110 Соответствует 1111111111111110му или 0xFFFEшному символу юникод-таблицы. А он https://unicode-table.com/ru/search/?q=FFFE ЗЫ: по всей видимости кривое тире уже было чем-то отфильтровано и выставлено совсем невалидным. --- Сообщение объединено, Sep 13, 2019 --- Кстати в пдф по ссылке в посте выше сказано "may be used to detect byte order by contrast with FEFF", https://unicode-table.com/ru/FEFF/ это и есть сигнатура, которая в начале файла может оказаться.
Нет, именно EF BF BE. f13nd, посмотрел на символы рядом. <Not a Character> еще у FFFF, то есть у EF BF BF. То есть все-таки достаточно проверять эти два частных случая?
Я ж не вебдизайнер, даже примерно не представляю как это получилось и могут ли быть другие символы. Ты сказал не шаришь как утф-8 кодируется, а он оказывается кодируется просто. Делай с этим что хочешь)
С точки зрения веб-дизайна тут думать и не надо Возможно пост был сделан автоматической тулзой. POST-запросом можно передать любые байты, а следовательно на стороне сервера можно ожидать чего угодно. Вопрос скорее в том, можно ли обойтись парой частных случаев, или же для стопроцентной надежности придется вкурить весь формат? Там же еще суррогатные codepoints, да и UNICODE-страниц несколько (вроде 16).
можно вырезать эти байты из последовательности перед передачей, но дефис пропадет. поэтому лучший вариант - найти альтернативный утф-8 код дефиса и заменять невалидный набор байт валидным.
