← Все курсы · Курс Excel · Статья 0: порядок сборки

Имена появились как тарабарщина, а Excel ничего не сказал

Статья 15 Excel для бизнес-аналитиков · Кодировка символов для людей, которые никогда не слышали эту фразу · Часть Analyst Prep Kit

К Майкл Носито, аналитик данных · Опубликовано 7 августа 2026 г.

В этой статье вы найдете решение одной неприятной проблемы: импорта имен в качестве é, ü и ряды символов там, где должны быть буквы. Исправление при импорте — это один раскрывающийся список: Данные > Из текста/CSV установите для параметра «Происхождение файла» значение 65001: Юникод (UTF-8).. Остальная часть страницы посвящена тому, что произошло, как это обнаружить и почему все хуже, чем кажется.

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

Это третья дверь семьи из статья 4 и статья 6: Excel решает, какие у вас данные, и никогда не упоминает об этом. В сборка этой серии оно было обнаружено поздно, на готовой информационной панели: две из пятнадцати лучших игр отображались как мусор, а по данным файла, ущерб составил 4685 из 82956 названий. Никогда ничего не ошибалось.

Что произошло, простыми словами

Текстовый файл на диске представляет собой просто пронумерованные коды, по одному на символ. Алфавит, кодировка профессионального слова, представляет собой кодовую книгу, в которой указано, какое число означает какую букву. Файл не содержит видимой кодовой книги. Программа, открывающая файл, должна знать или догадываться.

CSV сборки был написан в UTF-8, современном стандарте, который охватывает все языки, затрачивая два или более кода на любую букву, выходящую за рамки простого английского. Вместо этого устаревший открытый путь Excel угадал старую западноевропейскую кодовую книгу, которая всегда считывает один код на символ. Таким образом, каждая двухкодовая буква читалась как два отдельных неправильных символа. é, сохраненный в виде двух кодов, получился как é.

Предскажите, что это сделает с названием игры на румынском языке с четырьмя буквами с диакритическими знаками. Четыре двухкодовых буквы, восемь неправильных символов, а заголовок читается как тарабарщина. Именно строка «Приключение синего ребенка» указала на проблему в пятнадцати лучших сборках.

Как это определить: трехзначная подпись

У повреждения есть отпечаток пальца, поскольку неправильная кодовая книга сопоставляет ведущие коды UTF-8 с небольшим набором символов. Чаще всего появляются три последовательности:

Каждое сопоставление в этой таблице было повторно выполнено путем фактического преобразования перед публикацией: é, прочитанное под неправильной кодовой книгой, действительно выходит é. Скажем, поиск, который вы бы провели, чтобы очистить файл для этого. Ctrl+Ф для Ã это весь аудит, и он занимает десять секунд.

Почему это потеря данных, а не глюк дисплея

Проблема со шрифтом будет означать, что сохраненное значение правильное, а пиксели неправильные. Это наоборот: пиксели точно показывают сохраненное значение, которое теперь неверно. Последствия в том порядке, в котором они обычно проявляются:

Поиск не удался. Пользователь ищет настоящее название. В камере находится искалеченный. Никакого совпадения и никаких намеков, почему.

Объединения терпят неудачу. Поиск по чистому списку источников соответствует имени. 4685 строк больше ничему не соответствуют, и за статья 2 теме, неудавшееся совпадение не является ошибкой. Строки просто опускаются или пустуют.

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

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

Исправление при импорте

1. Данные > Из текста/CSV, та же дверь, что и статья 4, и ни в коем случае не двойной щелчок.
2. В предварительном просмотре вверху слева: «Происхождение файла». Установите его на 65001: Юникод (UTF-8)..
3. Посмотрите на строку, в которой, как вы знаете, есть акценты. перед загрузкой. Предварительный просмотр — это тест: имена читаются как имена, готово.

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

Исправление постфактум

Приборная панель сборки уже была собрана, когда обнаружилось повреждение, поэтому повторный импорт всего был дорогостоящим решением. Что он сделал вместо этого и что вообще работает:

1. Вернитесь к необработанному CSV-файлу., который существовал, потому что необработанные файлы никогда не перезаписываются. Перечитайте только поврежденный столбец под нужной кодировкой.
2. Экспортируйте этот чистый столбец с отметкой порядка байтов., короткий невидимый маркер в начале файла, который сообщает Excel, какой алфавит следует за ним, поэтому источник вставки правильно открывается на любом компьютере.
3. Вставьте его поверх искажённого столбца, обновите опорные точки. Имена восстанавливаются, соединения возвращаются, и проверки подтверждают, что количество строк не изменилось.

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

Почему это сильнее всего бьет по именам

Обратите внимание, на какие столбцы попадает это семейство неудач. Числа выдерживают проблемы с кодировкой, потому что цифры находятся в простом английском диапазоне, с которым согласны все кодовые книги. Повреждения концентрируются в имена: люди, места, продукты, титулы. Колонки, к которым вы присоединяетесь, выполняете поиск и размещаете их перед читателями.

6% столбца кажутся жизнеспособными, пока в ключе соединения не будет 6% имен ваших клиентов. И затронутые строки не случайны: они систематически неанглоязычные, поэтому любой анализ, затрагивающий международные данные, незаметно теряет именно этот фрагмент. Построенная на его основе информационная панель будет недооценивать конкретную группу населения и выглядеть совершенно нормально, и к настоящему времени вы узнаете в этом повторяющегося злодея этого сериала: ошибку, которая возвращает достоверные цифры.

Запустите его в своем файле

1. Ctrl+Ф для Ã в любом импортированном наборе данных с именами. Десять секунд.
2. Обращения: найдите необработанный файл и правильно импортируйте его. Происхождение файла 65001, набор типов столбцов, согласно этой странице и статье 4.
3. Нет необработанного файла: оцените перед спасением. Сколько строк, которые анализируются, касаются столбца, затрагиваются ли ключи соединения.
4. Добавьте канареечную проверку. Сохраните одно значение с известным акцентом в контрольной ячейке: =COUNTIF(Games[Name],"*é*") или просто обратите внимание на закрепленную строку, в которой, как вы знаете, есть акценты. Если канарейка читается правильно, то и колонка, вероятно, так и делает.
5. Исправьте конвейер, а не только файл. Если экспортируемый файл попадает к вам на стол еженедельно, настройка «Происхождение файла» теперь является частью процедуры импорта, или эта статья также будет повторяться еженедельно.

Шпаргалка

Прямо сейчас запустите десятисекундный аудит самого большого импортированного файла, который вы открывали на этой неделе. Что сделало Ctrl+Ф Ã вернуться с?