Ruby-Mysql2 Client возвращает пустые результаты

Это проблема в источнике. живой пример , который вы указали, начинается со следующих байтов (то есть они появляются перед ): 0xE2 0x80 0x8B. Это можно видеть, например, используя HTTP-просмотрщик Rex Swain , выбрав «Hex» в разделе «Формат отображения». Также обратите внимание, что , подтверждающий страницу с W3C Markup Validator, дает информацию о том, что в начале документа есть что-то очень неправильное, особенно сообщение «Строка 1, Столбец 1: не видя сначала doctype ».

Что происходит в валидаторе и в инструментах Chrome, а также, например, в Firebug - это то, что байты 0xE2 0x80 0x8B берутся как символьные данные, которые неявно запускают элемент body (поскольку символьные данные не могут корректно отображаться в элементе head или перед ним), подразумевая пустой элемент head до это.

Решение, конечно же, состоит в том, чтобы удалить эти байты. Браузеры обычно игнорируют их, но вы не должны полагаться на такую ​​обработку ошибок, а байты предотвращают полезную проверку HTML.

Поскольку страница объявлена ​​(в заголовках HTTP) как кодированная UTF-8, эти байты представляют собой ZERO WIDTH SPACE (U + 200B). У него нет видимого глифа и нет ширины, поэтому вы не заметите ничего в визуальном представлении, даже если браузеры рассматривают его как данные в начале элемента body. Обозначение ​ является ссылкой на символ для него, предположительно используемой средствами браузера, чтобы указать на наличие обычно невидимого символа.

Возможно, программное обеспечение, которое создало документ HTML, предназначалось для вставки ZERO WIDTH NO-BREAK SPACE (U + FEFF). Это было бы действительно, поскольку по специальному соглашению кодированные данные UTF-8 могут начинаться с этого символа, также известного как знак порядка байтов ( BOM ), когда они появляются в начале данных. Использование U + 200B вместо U + FEFF звучит как ошибка, которую программное обеспечение вряд ли сделает, но люди могут ошибаться таким образом, если они думают об именах Unicode символов .