Как изменить кодировку файла?
Всем привет.
Вопрос такой. Формирую csv — файл на сервере. В настройках самого сервера и БД стоит кодировка cp-1251.
Ту же кодировку выдает meta charset из самих настроек Битрикса.
При проверке кодировки функцией echo mb_internal_encoding(); — Выводит UTF-8. Почему — не понятно.
Далее. С помощью функции mb_convert_encoding($str, «UTF-8») — я перевожу поля, которые хочу записать в csv — в нужную мне кодировку.
Данный файл я заливаю на сторонний сервис — который перекодирует мои символы в ISO-8859-1, что соотв. неверно.
Что делал?
1) Убирал подключение — header.php в скрипте и менял на подключение пролога, чтобы были доступы модули информационных блоков — и далее ставил header(‘Content-Type: text/html; charset=utf-8’);
2) Убирал подключение — header.php в скрипте и менял на подключение пролога и прям в скрипте писал свой meta utf-8
3) Убирал подключение — header.php в скрипте и менял на подключение пролога и задавал mb_internal_encoding(«UTF-8»)
Ничего из вышеперечисленного не помогло.
Вопрос вот в чем, правильно ли я понимаю, что раз файл обрабатывается (создается/перезаписывается) на сервере — ему абсолютно все равно, какой heder, meta и тд стоит именно в моем скрипте. Я в этом сомневаюсь, правда.
И второе, как сделать нужные мне действия не меняя cp на utf-8 глобально на сервере.
PS. Файл создавал как через стандартную php — функцию для работы с csv — так и через внутреннюю битриксовскую, которая лежит в модуле (/bitrix/modules/main/classes/general/csv_data.php)
- Вопрос задан более трёх лет назад
- 553 просмотра
Сменить кодировку файла на UTF-8 в Excel
Если при импорте контактов вы видите нечитаемые символы, как на скриншоте, это значит, что кодировка файла не подходит для импорта в Unisender. Файл нужно перекодировать в UTF-8. Далее мы расскажем, как это сделать в Excel.
Создаем и открываем новый Excel файл.
Переходим на вкладку «Данные», выбираем «Получение внешних данных», а далее — «Из текста».
В окне для импорта текстового файла выбираем файл с неверной кодировкой и нажимаем кнопку «Импорт».
Открывается мастер импорта текста.
С текущей кодировкой содержимое файла нечитабельное.
В поле «Формат файла» перебираем кодировки, пока не найдём ту, в которой текст отображается правильно. Вариантов много, поэтому можно начать с форматов, которые начинаются со слова «Кириллица». Находим нужный формат, нажимаем «Далее».
Выбираем символы-разделители. В нашем случае это запятая.
Нажимаем «Далее» — «Готово» — «OK»
Так выглядит импортированный текст в Excel.
Теперь нажимаем «Файл» — «Сохранить как».
Выбираем место, где будет храниться файл. Вводим название файла, тип файла выбираем CSV, ниже нажимаем «Сервис» — «Параметры веб-документа».
Переходим на вкладку «Кодировка», выбираем «Юникод UTF-8» и нажимаем «OK».
Теперь импортируем его и видим, что текст отображается корректно.
Язвы и грабли CSV и Excel: проблемы и решения
CSV является стандартом де-факто для связи между собой разнородных систем, для передачи и обработки объемных данных с «жесткой», табличной структурой. Во многих скриптовых языках программирования есть встроенные средства разбора и генерации, он хорошо понятен как программистам, так и рядовым пользователям, а проблемы с самими данными в нем хорошо обнаруживаются, как говорится, на глаз.
История этого формата насчитывает не менее 30 лет. Но даже сейчас, в эпоху повального использования XML, для выгрузки и загрузки больших объемов данных по-прежнему используют CSV. И, несмотря на то, что сам формат довольно неплохо описан в RFC, каждый его понимает по-своему.
В этой статье я попробую обобщить существующие знания об этом формате, указать на типичные ошибки, а также проиллюстрировать описанные проблемы на примере кривой реализации импорта-экспорта в Microsoft Office 2007. Также покажу, как обходить эти проблемы (в т.ч. автоматическое преобразование типов Excel-ом в DATETIME и NUMBER) при открытии .csv.
Начнем с того, что форматом CSV на самом деле называют три разных текстовых формата, отличающихся символами-разделителями: собственно сам CSV (comma-separated values — значения, разделенные запятыми), TSV (tab-separated values — значения, разделенные табуляциями) и SCSV (semicolon separated values — значения, разделенные точкой с запятой). В жизни все три могут называться одним CSV, символ-разделитель в лучшем случае выбирается при экспорте или импорте, а чаще его просто «зашивают» внутрь кода. Это создает массу проблем в попытке разобраться.
Как иллюстрацию возьмем казалось бы тривиальную задачу: импортировать в Microsoft Outlook данные из таблицы в Microsoft Excel.
В Microsoft Excel есть средства экспорта в CSV, а в Microsoft Outlook — соответствующие средства импорта. Что могло быть проще — сделал файлик, «скормил» почтовой программе и — дело сделано? Как бы не так.
Создадим в Excel тестовую табличку:
… и попробуем экспортировать ее в три текстовых формата:
«Текст Unicode» | Кодировка — UTF-16, разделители — табуляция, переводы строк — 0×0D, 0×0A, объем файла — 222 байт |
«CSV (разделители — запятые)» | Кодировка — Windows-1251, разделители — точка с запятой (не запятая!), во второй строке значение телефонов не взято в кавычки, несмотря на запятую, зато взято в кавычки значение «01;02», что правильно. Переводы строк — 0×0D, 0×0A. Объем файла — 110 байт |
«Текстовые файлы (с разделителями табуляции)» | Кодировка — Windows-1251, разделители — табуляция, переводы строк — 0×0D, 0×0A. Значение «01;02» помещено в кавычки (без особой нужды). Объем файла — 110 байт |
Какой вывод мы делаем из этого. То, что здесь Microsoft называет «CSV (разделители — запятые)», на самом деле является форматом с разделителями «точка с запятой». Формат у Microsoft — строго Windows-1251. Поэтому, если у вас в Excel есть Unicode-символы, они на выходе в CSV отобразятся в вопросительные знаки. Также то, что переводами строк является всегда пара символов, то, что Microsoft тупо берет в кавычки все, где видит точку с запятой. Также то, что если у вас нет Unicode-символов вообще, то можно сэкономить на объеме файла. Также то, что Unicode поддерживается только UTF-16, а не UTF-8, что было бы сильно логичнее.
Теперь посмотрим, как на это смотрит Outlook. Попробуем импортировать эти файлы из него, указав такие же источники данных. Outlook 2007: Файл -> Импорт и экспорт… -> Импорт из другой программы или файла. Далее выбираем формат данных: «Значения, разделенные запятыми (Windows)» и «Значения, разделенные табуляцией (Windows)».
«Значения, разделенные табуляцией(Windows)» | Скармливаем аутлуку файл tsv, с разделенными табуляцией значениями и. — чтобы вы думали. Outlook склеивает поля и табуляцию не замечает. Заменяем в файле табуляцию на запятые и, как видим, поля уже разбирает, молодец. |
«Значения, разделенные запятыми (Windows)» | А вот аутлук как раз понимает все верно. Comma — это запятая. Поэтому ожидает в качестве разделителя запятую. А у нас после экселя — точка с запятой. В итоге аутлук распознает все неверно. |
Два майкрософтовских продукта не понимают друг друга, у них напрочь отсутствует возможность передать через текстовый файл структурированные данные. Для того, чтобы все заработало, требуются «пляски с бубном» программиста.
Мы помним, что Microsoft Excel умеет работать с текстовыми файлами, импортировать данные из CSV, но в версии 2007 он делает это очень странно. Например, если просто открыть файл через меню, то он откроется без какого-либо распознавания формата, просто как текстовый файл, целиком помещенный в первую колонку. В случае, если сделать дабл-клик на CSV, Excel получает другую команду и импортирует CSV как надо, не задавая лишних вопросов. Третий вариант — вставка файла на текущий лист. В этом интерфейсе можно настраивать разделители, сразу же смотреть, что получилось. Но одно но: работает это плохо. Например, Excel при этом не понимает закавыченных переводов строк внутри полей.
Более того, одна и та же функция сохранения в CSV, вызванная через интерфейс и через макрос, работает по-разному. Вариант с макросом не смотрит в региональные настройки вообще.
Стандарта CSV как такового, к сожалению, нет, но, между тем, существует т.н. memo. Это RFC 4180 года, в котором описано все довольно толково. За неимением ничего большего, правильно придерживаться хотя бы RFC. Но для совместимости с Excel следует учесть его собенности.
Вот краткая выжимка рекомендаций RFC 4180 и мои комментарии в квадратных скобках:
- между строками — перевод строки CRLF [на мой взгляд, им не стоило ограничивать двумя байтами, т.е. как CRLF (0×0D, 0×0A), так и CR 0×0D]
- разделители — запятые, в конце строки не должно быть запятой,
- в последней строке CRLF не обязателен,
- первая строка может быть строкой заголовка (никак не помечается при этом)
- пробелы, окружающие запятую-разделитель, игнорируются.
- если значение содержит в себе CRLF, CR, LF (символы-разделители строк), двойную кавычку или запятую (символ-разделитель полей), то заключение значения в кавычки обязательно. В противном случае — допустимо.
- т.е. допустимы переводы строк внутри поля. Но такие значения полей должны быть обязательно закавычены,
- если внутри закавыченной части встречаются двойные кавычки, то используется специфический квотинг кавычек в CSV — их дублирование.
Вот в нотации ABNF описание формата:
file = [header CRLF] record *(CRLF record) [CRLF] header = name *(COMMA name) record = field *(COMMA field) name = field field = (escaped / non-escaped) escaped = DQUOTE *(TEXTDATA / COMMA / CR / LF / 2DQUOTE) DQUOTE non-escaped = *TEXTDATA COMMA = %x2C DQUOTE = %x22 LF = %x0A CRLF = CR LF TEXTDATA = %x20-21 / %x23-2B / %x2D-7E
Также при реализации формата нужно помнить, что поскольку здесь нет указателей на число и тип колонок, поскольку нет требования обязательно размещать заголовок, здесь есть условности, о которых необходимо не забывать:
- строковое значение из цифр, не заключенное в кавычки может быть воспринято программой как числовое, из-за чего может быть потеряна информация, например, лидирующие нули,
- количество значений в каждой строке может отличаться и необходимо правильно обрабатывать эту ситуацию. В одних ситуациях нужно предупредить пользователя, в других — создавать дополнительные колонки и заполнять их пустыми значениями. Можно определиться, что количество колонок задается заголовком, а можно добавлять их динамически, по мере импорта CSV,
- Квотить кавычки через «слэш» не по стандарту, делать так не надо.
- Поскольку типизации полей нет, нет и требования к ним. Разделители целой и дробной частей в разных странах разные, и это приводит к тому, что один и тот же CSV, сгенрированный приложением, в одном экселе «понимается», в другом — нет. Потому что Microsoft Office ориентируется на региональные настройки Windows, а там может быть что угодно. В России там указано, что разделитель — запятая,
- Если CSV открывать не через меню «Данные», а напрямую, то Excel лишних вопросов не задает, и делает как ему кажется правильным. Например, поле со значением 1.24 он понимает по умолчанию как «24 января»
- Эксель убивает ведующие нули и приводит типы даже тогда, когда значение указано в кавычках. Делать так не надо, это ошибка. Но чтобы обойти эту проблему экселя, можно сделать небольшой «хак» — значение начать со знака «равно», после чего поставить в кавычках то, что необходимо передать без изменения формата.
- У экселя есть спецсимвол «равно», который в CSV рассматривается как идентификатор формулы. То есть, если в CSV встретится =2+3, он сложит два и три и результат впишет в ячейку. По стандарту он это делать не должен.
Пример валидного CSV, который можно использовать для тестов:
Фамилия, Имя, Адрес, Город/штат, индекс, просто строка Иванов,Иван, Ленина 20, Москва, 08075, "1/3" Tyler, John,110 terrace, PA,20121, "1.24" "Петров ""Кул""", Петя,120 Hambling St., NJ,08075, "1,24" Смирнов,Вася,"7452 Street ""Near the Square"" road", York, 91234, "3-01" ,Миша,,Ленинград, 00123, "03-01" "Джон ""Черная голова"", Клод",Рок,"", Маями бич,00111, "0000" Сергей,,
точно такой же SCSV:
Фамилия; Имя; Адрес; Город/штат; индекс; просто строка Иванов;Иван; Ленина 20; Москва; 08075;"1/3" Tyler; John;110 terrace; PA; 20121;"1.24" "Петров ""Кул"""; Петя;120 Hambling St.; NJ;08075;"1,24" Смирнов;Вася;"7452 Street ""Near the Square"" road"; York; 91234;"3-01" ;Миша;;Ленинград; 00123;"03-01" "Джон ""Черная голова""; Клод";Рок;""; Маями бич;00111; "0000" Сергей;;
Первый файлик, который реально COMMA-SEPARATED, будучи сохраненным в .csv, Excel-ом не воспринимается вообще.
Второй файлик, который по логике SCSV, экселом воспринимается и выходит вот что:
- Учлись пробелы, окружающие разделители
- Последний столбец вообще толком не распознался, несмотря на то, что данные в кавычках. Исключение составляет строка с «Петровым» — там корректно распозналось 1,24.
- В поле индекс Excel «опустил» ведущие нули.
- в самом правом поле последней строки пробелы перед кавычками перестали указывать на спецсимвол
Если же воспользоваться функционалом импорта (Данные -> Из файла) и обозвать при импорте все поля текстовыми, то будет следующая картина:
С приведением типов сработало, но зато теперь не обрабатываются нормально переводы строк и осталась проблема с ведущими нулями, кавычками и лишними пробелами. Да и пользователям так открывать CSV крайне неудобно.
Есть эффективный способ, как заставить Excel не приводить типы, когда это нам не нужно. Но это будет CSV «специально для Excel». Делается это помещением знака «=» перед кавычками везде, где потенциально может возникнуть проблема с типами. Заодно убираем лишние пробелы.
Фамилия;Имя;Адрес;Город/штат;индекс;просто строка Иванов;Иван;Ленина 20;Москва;="08075";="1/3" Tyler; John;110 terrace;PA;="20121";="1.24" "Петров ""Кул""";Петя;120 Hambling St.;NJ;="08075";="1,24" Смирнов;Вася;"7452 Street ""Near the Square"" road";York;="91234";="3-01" ;Миша;;Ленинград;="00123";="03-01" "Джон ""Черная голова"";Клод";Рок;"";Маями бич;="00111";="0000" Сергей;;
И вот что случаеся, если мы открываем этот файлик в экселе:
- выбрать кодировку. Как правило, важно UTF-8, UTF-16, Windows-1251, KOI8-R. Чаще всего, других вариантов нет. Одна из них должна идти по умолчанию. В случае, если данные содержат символы, не имеющие аналогов в целевой кодировке, нужно предупреждать пользователя, что данные будут битые;
- выбрать разделитель между полями. Варианты — табуляция, запятая, точка с запятой. По умолчанию — точка с запятой. Не забыть, что если разделитель вводится в тексте, то будет очень непросто ввести туда табуляцию, это еще и непечатный символ;
- выбрать разделитель между строками (CRLF 0×0D 0×0A или CR 0×0D);
- выбрать разделитель целой и дробной части для числовых данных (точка или запятая).
- выбрать, выводить ли строку заголовка;
- выбрать, каким образом осуществлять квотинг спецсимволов (особенно переводов строк и кавычек). В принципе, можно отступиться от стандарта и квотировать их как \n и \», но нужно в этом случае не забыть квотировать сами \n, если они встретятся и не забыть сделать это опцией при экспорте-импорте. Но совместимость пойдет лесом, потому что любой RFC-стандартный парсер конструкцию . «abc\«»,… посчитает за ошибку;
- совсем в идеале — поставить галочку «для Excel» и учитывать там те нестандартности, которые внесла Майкрософт. К примеру, заменять значения числовых полей, «похожих на дату», на конструкцию tm-article-presenter__meta»>
Excel: Импорт .csv файлов в UTF-8 кодировке
Если у вас файл в CSV формате открывается в Excel иероглифами (кракозябрами)? Не стоит отчаиваться. Эта проблема решается в несколько простых шагов в Excel.
Как открыть CSV в Excel в UTF (или любой другой кодировке)
Открываем Microsoft Excel -> Кликаем вкладку «Данные» -> кликаем «Из текста»
Откроется окно, где необходимо выбрать файл из сервиса скачанный на компьютер, далее кодировку 65001 Юникод (UTF-8) и выбрать разделитель столбцов точка с запятой:
После этих несложных действий Excel откроет файл в нужном виде. Эксель работает со всем кодировками, необходимо просто подобрать нужную.
Отзывы пользователей (все отзывы)
Дмитрий Шахов
Основатель агентства REMARKA
Arsenkin Tools — простой, понятный и недорогой инструмент, который я много лет рекомендую всем оптимизаторам.
Андрей Буйлов
Руководитель в Муравейник
Хороший набор простых, но очень удобных инструментов. И постоянно появляются более продвинутые опции для анализа и парсинга. Успеха и развития сервису! Рекомендую! Обзор инструмента по проверке коммерциализации запроса.
Миндубаев Рамазан
Head of SEO, TRINET.Group
В инструментах ARSENKIN TOOLS собраны решения рядовых SEO задач, которые использую в ежедневной работе как я, так и мои специалисты в TRINET.Group. Ключевое отличие ARSENKIN TOOLS — удобство, быстрота работы и стабильность. Ряд уникальных авторских решений, не имеющие прямых аналогов в других сервисах заслуживает отдельного уважения.
Популярные инструменты:
Проверка коммерциализации
Инструмент, который проверить список поисковых запросов на коммерциализацию в поисковой системе Яндекс.
Выгрузка ТОП-10 сайтов
Инструмент, который поможет быстро выгрузить топ-10 сайтов по заданным запросам, в поисковой системе Яндекс и Google.
Кластеризация запросов
Инструмент, для быстрой группировки (кластеризации) поисковых запросов в поисковых системах Яндекс и Google.