Что делать с кодировкой в боте для Telegram?

Question

[user0name0]

Делаю телеграм-бота. Данные принимаются в json, в кодировке cp1251 и конвертируются в utf-8. При отправлении текста "Aukštųjų" превращается в "Auk", а с urlencode в "Aukštųjų". Если просто выводить получаемые данные в браузер, копировать их и отправлять вручную, с локального сервера или через heroku, то все работает. А когда данные берутся извне, то обрезаются при отправке до первого необычного символа. Почему такое происходит и что делать?

$json= iconv('cp1251', 'utf-8', $json);
$json= json_decode($json, 1);
$text = $json[0]['text'];   // $text = Aukštųjų
$result = $url . '&text=Aukštųjų';   // Результат: Aukštųjų
$result = $url . '&text=' . $text;   // Результат: Auk
$result = $url . '&text=' . urlencode($text);   // Результат: Aukštųjų

Comments

[Дмитрий Ларин]

Стандарт json это кодировка utf-8. Если она к вам приходит в cp1251 то у вас чтото фатально не так.

[user0name0]

Дмитрий Ларин, Среди получаемых заголовков при запросе к серверу:
>content-type: text/plain; charset=windows-1251
Там до самого json есть лишний текст, который я убираю.
И если не сделать iconv, то текст нечитаем. Если правильно помню, нелатинские символы заменяются на "���".

Answer 1

[Moskus]

У вас ошибка на ошибке.
1) JSON должен быть в UTF-8. А вы пишете, что данные принимаются (откуда принимаются?) не в Unicode, а в восьмибитной win 1251. Так быть не должно.
2) Вы верите содержимому заголовка, где написано win 1251, но это ложь, потому что эта кодировка - кириллическая, она не может передавать символы š и ų - убедитесь лично: https://en.wikipedia.org/wiki/Windows-1251
3) Потому что (2), код iconv('cp1251', 'utf-8', $json) не имеет смысла. Если ваш JSON действительно передается в восьмибитной кодировке (что само по себе - ошибка, см. пункт 1), то это либо ISO 8859-10, либо ISO 8859-4.
Я не могу вам сказать, как конкретно исправить ситуацию, потому что в вопросе недостаточно данных - слишком много ошибок наложено друг на друга. Начать решать проблему нужно, очевидно, с начала, то есть с выяснения, в какой действительно кодировке передается JSON (не глядя на HTTP-header, а глядя на сами данные).

Comments

[Дмитрий Ларин]

Вот-вот. Я и говорю что косяк в кодировках.

[user0name0]

код iconv('cp1251', 'utf-8', $json) не имеет смысла.

Ладно. Удаляем эту строку.

$json = gzdecode(curl_get_contents('https://site.com/', $header, $post)); 
var_dump($json); // Выводит 8483907907285dev.css,dev.js069310{тут json}
$json = preg_replace('#*****#', '*****', $json); 
var_dump($json); // Остается только {json}. ВЕСЬ текст внутри json с нелатинскими символами выглядит так: "� �������, 11 ������ 2019 ���� �".
//$json = iconv('cp1251', 'utf-8', $json); 
echo mb_detect_encoding($json); // Почему-то UTF-8
$json = json_decode($json, 1);
var_dump($json); // NULL

Т.е. без iconv не только не читается текст, но и не работает json_decode.

Попробовал $json = iconv('ISO-8859-4', 'utf-8', $json); - кириллица становится нечитаемой, декодер Лебедева показывает: ISO-8859-4 -> CP1251. С ISO-8859-10 аналогично. В обоих случаях json_decode уже работает, кстати.

[Moskus]

user0name0, вы пытаетесь решить проблему методом тыка, а не тем, который я вам посоветовал, и действительно ожидаете результат?

[user0name0]

Moskus, Вы сказали выяснить, в какой кодировке json - я это и сделал, разве нет? И показал, что если перекодировать данные из ISO-8859-4, из ISO-8859-10 или не менять их вообще, то проблема не только не решается, она еще и усугубляется. Сайт отправляет json в кодировке cp1251, да еще и с мусорными данными в начале и упаковывает всё это с помощью gzip - что же я с этим сделаю? Может, это вообще было сделано для усложнения парсинга.

[Moskus]

user0name0, нет, вы этого не сделали.
Это делается не путем перебора кодировок в функциях, которые делают что-то с данными, и не скармливанием данных каким-то третьим инструментам.

Это делается путём того, что вы берете ваш JSON в первозданном виде (сразу после распаковки gzip, без всяких преобразований) и смотрите на него в шестнадцатиричном редакторе, выясняя, какими конкретно значениями кодируются обычные латинские символы и символы š и ų. Только в этом случае вы будете точно знать, в какой кодировке на самом деле находятся данные.

То, что сайт, который отправляет данные, вам неподконтролен, вы раньше не писали, несмотря на то, что вам на это указали два раза уже. Это критичная информация для поиска решения. Теперь вот вы, наконец, смогли это выдавить из себя.

[Moskus]

user0name0, откройте свежераспакованный JSON в любом hex-редакторе или просмотрщике, сделайте полный скриншот окна и выложите сюда.

[user0name0]

То, что сайт, который отправляет данные, вам неподконтролен, вы раньше не писали

Да, и правда стоило это сказать в самом начале.

Проблему наконец-то решил, нужно было всего лишь сделать html_entity_decode. Спасибо за помощь.

И все же, какая кодировка у json?

[Moskus]

user0name0, вот потому, такие вопросы всегда и нужно начинать с предъявления данных.

Приведенный фрагмент не содержит символов с кодами больше 76 hex (буква v), а все не-ASCII символы закодированы, как HTML numeric decimal entity (например, š). Так что кодировку этого JSON-файла можно трактовать, как просто ASCII, вероятнее всего. "Вероятнее", потому что требование сделать скриншот с полными данными вы, в лучших традициях, поигнорировали, потому непонятно, есть ли там что-то с кодами 80-FF hex.

И да, чтобы превратить это в корректный JSON, нужно сначала раскодировать html entity в символы.

[Moskus]

user0name0, уточню про ASCII. Если эти данные не содержат никаких букв, кроме латинских или html entity, которыми закодированы буквы прибалтийских языков, это можно интерпретировать как ASCII или любую восьмибитную кодировку. Если там есть незакодированные в html entity буквы балтийских языков или кириллические буквы (вдруг, я же не знаю, что это за данные), то кодировку таки нужно подбирать правильную.

[user0name0]

Moskus, Кириллица тоже встречается.

[Moskus]

user0name0, в этом случае, это действительно 1251. Так что сначала нужно это преобразовать в Unicode, а потом раскодировать html entity. Иначе информация будет потеряна, так как только в Unicode могут быть и символы кириллицы, и прибалтийских языков.

[Moskus]

user0name0, у тех, кто писал код, генерирующий эти данные, руки из жопы и обе - левые. Не удивлюсь, если решение этой задачи они выцыганили на Тостере.

[user0name0]

Moskus, Вряд ли. Сайт, из которого я получаю данные - это Вконтакте. Но глядя на их обновления после прихода Mail.ru, мне кажется, что так оно и есть.

[Moskus]

user0name0, причин боготворить "гигантов бизнеса" - нет.
Согласно стандарту, JSON должен содержать строковые данные только в Unicode, а он содержит кириллицу в 1251.
Согласно стандарту, любой символ в JSON может быть заменен его escape-кодом. Но это должен быть escape-код вида \uXXXX, а не html entity вида &#XXXX;. JSON - не HTML.
Они бы еще строковые данные в CDATA обернули, как в XML, вообще была бы красота.

Так что руки из жопы без всякого сомнения, независимо от каких-либо оправданий. Двойное нарушение стандарта остается двойным нарушением стандарта.