Починить кривой UTF-8

Тема в разделе "WASM.HEAP", создана пользователем _DEN_, 12 сен 2019.

  1. _DEN_

    _DEN_ DEN

    Публикаций:
    0
    Регистрация:
    8 окт 2003
    Сообщения:
    5.383
    Адрес:
    Йобастан
    Хз куда такое постить, поэтому сюда :)

    Имеется юзерский пост на сайте. В содержимом поста - текстовое поле. Это текстовое поле засылается в 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? Что с ней не так? :)
     
  2. Rel

    Rel Well-Known Member

    Публикаций:
    2
    Регистрация:
    11 дек 2008
    Сообщения:
    5.242
  3. f13nd

    f13nd Well-Known Member

    Публикаций:
    0
    Регистрация:
    22 июн 2009
    Сообщения:
    1.954
    На википедии подробно описано как кодируется UTF-8:
    EF BF BE
    11101111 10111111 10111110
    Соответствует 1111111111111110му или 0xFFFEшному символу юникод-таблицы.
    А он https://unicode-table.com/ru/search/?q=FFFE
    ЗЫ: по всей видимости кривое тире уже было чем-то отфильтровано и выставлено совсем невалидным.
    --- Сообщение объединено, 13 сен 2019 ---
    Кстати в пдф по ссылке в посте выше сказано "may be used to detect byte order by contrast with FEFF", https://unicode-table.com/ru/FEFF/ это и есть сигнатура, которая в начале файла может оказаться.
     
    Последнее редактирование: 13 сен 2019
  4. _DEN_

    _DEN_ DEN

    Публикаций:
    0
    Регистрация:
    8 окт 2003
    Сообщения:
    5.383
    Адрес:
    Йобастан
    Нет, именно EF BF BE.

    f13nd, посмотрел на символы рядом. <Not a Character> еще у FFFF, то есть у EF BF BF. То есть все-таки достаточно проверять эти два частных случая?
     
  5. f13nd

    f13nd Well-Known Member

    Публикаций:
    0
    Регистрация:
    22 июн 2009
    Сообщения:
    1.954
    Я ж не вебдизайнер, даже примерно не представляю как это получилось и могут ли быть другие символы. Ты сказал не шаришь как утф-8 кодируется, а он оказывается кодируется просто. Делай с этим что хочешь)
     
  6. _DEN_

    _DEN_ DEN

    Публикаций:
    0
    Регистрация:
    8 окт 2003
    Сообщения:
    5.383
    Адрес:
    Йобастан
    С точки зрения веб-дизайна тут думать и не надо :) Возможно пост был сделан автоматической тулзой. POST-запросом можно передать любые байты, а следовательно на стороне сервера можно ожидать чего угодно. Вопрос скорее в том, можно ли обойтись парой частных случаев, или же для стопроцентной надежности придется вкурить весь формат? Там же еще суррогатные codepoints, да и UNICODE-страниц несколько (вроде 16).
     
  7. trsoft

    trsoft Member

    Публикаций:
    0
    Регистрация:
    18 июл 2018
    Сообщения:
    115
    можно вырезать эти байты из последовательности перед передачей, но дефис пропадет. поэтому лучший вариант - найти альтернативный утф-8 код дефиса и заменять невалидный набор байт валидным.
     
  8. sn0w

    sn0w Active Member

    Публикаций:
    0
    Регистрация:
    27 фев 2010
    Сообщения:
    956
    ну этоже протокол не wifi а starlink, там каждый байт 17ю битами кодируется