У меня есть таблица данных, закодированная в кодировке latin5, и все столбцы в таблице также latin5. С консоли mysql, когда я ввожу «SET NAMES 'latin5'» и запрашиваю результаты таблицы, все в порядке. Когда я пытаюсь удалить или вставить / обновить, все новые кодировки данных идеальны. Но когда я пытаюсь вставить данные Iso-8859 (также проверьте это с помощью mb_detect_encoding) в базу данных, и я пытаюсь вставить данные без "SET NAMES", они не вставляют / обновляют / выбирают правильные кодировки или когда я использовал "SET NAMES 'latin5' "он не вставляет / обновляет должным образом, но выберите, все в порядке. Данные latin5 поступают в правильной кодировке только с установленными именами 'latin5'. Когда я использую набор имен 'utf8', запросы выбора плохо закодированы, но вставка / обновление в порядке.
Причина, по которой я спросил, что мы пойдем в производство. И это заставляет задуматься о возможных будущих проблемах.






mb_detect_encoding не знает, в какой кодировке находится ваша строка. Он делает квалифицированное предположение, но нет никаких гарантий, что он будет угадывать правильно. Особенно, если все кандидаты представляют собой однобайтовые кодировки, как в случае latin1 и latin5.
На самом деле нет замены знанию того, что вы делаете, если вы хотите получить правильные кодировки. Я предлагаю вам хотя бы пару раз прочитать эти страницы:
В частности, обратите внимание, что веб-страница обслуживается с заголовком http, который указывает кодировку, с помощью которой закодирована страница. Если вы явно не указали это в своем php-скрипте, вы будете использовать веб-серверы по умолчанию, которые могут отличаться от сервера к серверу.
Кроме того, будьте осторожны, чтобы понять, что происходит, вместо того, чтобы делать проб и ошибок. Последний может легко дать вам что-то, что работает в определенном контексте, но не во всех контекстах.
И наконец. Если у вас вообще есть выбор, я серьезно предлагаю вам использовать utf-8 для всего. latin5 доставит вам много горя.