Вывод PHP показывает маленькие черные ромбики с вопросительным знаком
Я пишу программу php, которая извлекает из источника базы данных. У некоторых варчаров есть кавычки, которые отображаются в виде черных ромбов с вопросительным знаком (�, ЗАМЕНА ХАРАКТЕРА, я полагаю, из текста Microsoft Word).
Как я могу использовать php для удаления этих символов?
Не снимайте их, исправьте время. См. Также «черный бриллиант» в stackoverflow.com/questions/38363566/…
Здравствуйте, разработчики! В сегодняшней статье мы рассмотрим важный аспект управления приложениями, который часто упускается из виду в суете.
Привет, читатели, сегодня мы узнаем о коллекциях. В Laravel коллекции — это способ манипулировать массивами и играть с массивами данных. Благодаря.
PHP — это популярный язык программирования, который используется для разработки веб-приложений. Если вы используете Mac и хотите разрабатывать.
Laravel Scout — это популярный пакет, который предоставляет простой и удобный способ добавить полнотекстовый поиск в ваше приложение Laravel. Он.
Ответы 21
Это может быть вызвано несоответствием кодировки Unicode или другим кодом. Попробуйте изменить кодировку в браузере, в настройках текст будет выглядеть нормально. Тогда вопрос в том, как преобразовать содержимое вашей базы данных в кодировку, которую вы используете для отображения. (На самом деле это может быть просто добавление инструкции кодировки utf-8 к вашему выводу.)
Если вы видите этот символ (U + FFFD «REPLACEMENT CHARACTER»), это обычно означает, что сам текст закодирован в некоторой форме однобайтовой кодировки, но интерпретируется в одной из кодировок Unicode (UTF8 или UTF16).
Если бы все было наоборот, это (обычно) выглядело бы примерно так: ä.
Вероятно, исходная кодировка — ISO-8859-1, также известная как Latin-1. Вы можете проверить это, не меняя свой скрипт: браузеры дают вам возможность повторно интерпретировать страницу в другой кодировке — в Firefox используйте «Просмотр» -> «Кодировка символов».
Чтобы браузер использовал правильную кодировку, добавьте заголовок HTTP, подобный этому:
header("Content-Type: text/html; charset=ISO-8859-1"); или поместите кодировку в метатег:
В качестве альтернативы вы можете попытаться прочитать из базы данных в другой кодировке (предпочтительно UTF-8) или преобразовать текст с помощью iconv() .
Пока это наиболее близкое решение. Однако теперь у меня есть мета: , и я использую iconv для преобразования из iso-8859-1 в utf- 8, символы теперь отображаются в виде прямоугольника с 0096 и 0092 соответственно special (‘или -) какие-либо другие мысли?
да, у меня есть еще одна мысль: сделайте домашнее задание . вы, вероятно, использовали неправильную исходную кодировку. 0x92 и 0x96 — это «изогнутые одинарные кавычки» и «тире» в windows-1252. это могло быть правильным? вы пробовали уловку с браузером?
Заголовок PHP исправил для меня вещи при использовании класса PDF2Text.
Разве header(«Content-Type: text/plain; charset=ISO-8859-1»); не должен быть header(«Content-Type: text/html; charset=ISO-8859-1»); ?
@ j08691: ну, это сейчас зависит от типа контента, не так ли?
очень полезно, это действительно работает также, если у вас есть сценарий PHP, который читает файл CSV, сохраненный в формате Windows CSV. Спасибо!
Это проблема с кодировкой. Таким образом, это могло пойти не так на многих разных уровнях, но, скорее всего, строки в вашей базе данных закодированы в utf-8, и вы представляете их как iso-8859-1. Или наоборот.
Правильный способ решить эту проблему — исправить набор символов. Самая простая стратегия, поскольку вы используете PHP, — использовать iso-8859-1 во всем приложении. Для этого необходимо убедиться, что:
- Все исходные файлы PHP сохраняются как iso-8859-1 (не путать с cp-1252).
- Ваш веб-сервер настроен для обслуживания файлов с charset=iso-8859-1
- В качестве альтернативы вы можете переопределить настройки веб-серверов из PHP-документа, используя header .
- Кроме того, вы май вставляете в свой HTML метатег, который указывает то же самое, но это не является строго необходимым.
- Вы май также указываете атрибут accept-charset в ваших элементах .
- Таблицы базы данных определены с кодировкой latin1
- Соединение с базой данных между PHP и базой данных установлено на latin1.
Если у вас уже есть данные в вашей базе данных, вы должны знать, что они, вероятно, уже испорчены. Если вы еще не на этапе производства, просто протрите все и начните заново. В противном случае вам придется выполнить некоторую очистку данных.
Замечание о мета-тегах, поскольку все неправильно понимают, что они собой представляют:
Когда веб-сервер обслуживает файл (HTML-документ), он отправляет некоторую информацию, которая не отображается непосредственно в браузере. Это называется HTTP-заголовками. Одним из таких заголовков является заголовок Content-Type , который определяет mimetype файла (например, text/html ), а также кодировку (также известную как кодировка). Хотя большинство веб-серверов отправляют заголовок Content-Type с информацией о charset , это необязательно. Если его нет, браузер вместо этого интерпретирует любые мета-теги с помощью http-equiv = «Content-Type» . Важно понимать, что мета-тег интерпретируется Только, если веб-сервер не отправляет заголовок. На практике это означает, что он используется только в том случае, если страница сохраняется на диск, а затем открывается оттуда.
Эта страница дает очень хорошее объяснение этих вещей.
Основываясь на вашем описании проблемы, данные в вашей базе данных почти наверняка закодированы как Окна-1252, а ваша страница почти наверняка обслуживается как ISO-8859-1. Эти два набора символов эквивалентны, за исключением того, что в Windows-1252 есть 16 дополнительных символов, которых нет в ISO-8859-1, включая левые и правые фигурные кавычки.
Если предположить, что мой анализ верен, самое простое решение — использовать вашу страницу как Windows-1252. Это будет работать, потому что все символы, которые находятся в ISO-8859-1, также находятся в Windows-1252. В PHP вы можете изменить кодировку следующим образом:
header('Content-Type: text/html; charset=Windows-1252'); Однако вам действительно следует проверить, какую кодировку символов вы используете в своих файлах HTML и содержимом своей базы данных, и позаботиться о согласованности или правильном преобразовании там, где это невозможно.
Проблема с этим предложением заключается в том, что, скорее всего, на данный момент данные представляют собой смесь разных кодировок. Если вы точно не знаете, что пошло не так, это становится еще более беспорядочным, если вы просто добавляете какие-то случайные исправления здесь и там.
Я согласен. Я немного отредактировал свой пост, чтобы отразить, что это решение не заменяет знание того, что вы делаете. Однако я пришел к выводу, что большинство разработчиков либо неспособны понять эту проблему, либо просто не заботятся. Кажется, там, где я работаю, он появляется хотя бы раз в месяц.
Это тоже в значительной степени моё наблюдение. Что мне небезразлично, они пожинают, как сеют. Но вы, наверное, правы; Скорее всего, его данные действительно cp-1252 .. По крайней мере, некоторые из них.
Я попробовал несколько решений той же проблемы. Этот был немедленно эффективен с наименьшими усилиями
Как удалить � (знак вопроса в ромбе) из текста?
Как удалить из текста символ битого UTF символа, если этот символ уже таким дали. смена кодировки ничего не дает. str_replace, preg_replace не могу по символу сделать, так как при копировании из текста он меняется на просто квадрат
Простой 4 комментария
Добрый день.
Дополните вопрос примером текста, кодом, которым Вы получаете этот текст.
Без всего этого можно долго гадать.
Для начала изучить текст и определить, а как собственно эти битые символы появились.
Если из-за того, что в некоторых местах текста между байтами символа был вставлен пробел — в таком случае можно просто удалить пробелы, которые располагаются там, где они в utf-8 невозможны (после 11xxxxxx или перед 10xxxxxx в двоичном представлении).
Я пробовал, но вот, допустим предложение
Teen, Nella, Keana Moir�
Как тут его убрать можно?
SagePtr, и мне надо его удалить. Как это можно сделать? Т.е. восстанавливать исходный символ не надо, просто зачистить «за ним»
Способ длинноватый, но простой и приемлемый для «почтичайников».
В тексте имеются символы «вопрос в черном ромбе» �. Удалить можно только вручную, по одному. Инструменты «найти» и «заменить» не помогают, они не видят этот символ. Применить макрос или код – не для всех. Вообще этот символ означает, что в исходном тексте были символы, отсутствующие в тексте с текущей кодировкой.
Создаем новый документ ворд, копируем в него символы, можно вместе с небольшим фрагментом текста, так, чтобы в будущем по положению в тексте можно было найти символ, даже если все будет заменено на абракодабру. Удобно повторить несколько символов в начале строки.
Сохраняем текст.
В настройках ворд на вкладке файл-параметры-дополнительно-группа «общие» (внизу) ставим птичку «подтверждать преобразование формата файла при открытии»
Сохраняем текст в txt. При нажатии «сохранить» появится окно «преобразование файла». По умолчанию стоит кодировка виндовс. Справа под окном кодировок будет предупреждение о том, что «текст, выделенный красным невозможно сохранить в выбранной кодировке». Ниже в окне образца, пролистав его увидите красные символы. Слева вверху три варианта кодировки. Ставим точку «Другая». Активируется окно кодировок. Находим кодировку, при которой символы в образце становятся некрасными, но текст читается. Мне помогла кодировка «Китайская упрощенная (GB 18030)». Юникод не помог, т.к. в будущем при замене инструмент «заменить» не увидел некоторых символов этой кодировки. Т.е. в китайской кодировке символы, заменившие � ромб совпали с виндовс (я так понимаю ANSI), а в Юникоде � ромб заменился на символы, часть которых отсутствует в кодировке виндовс. Жмем ОК.
Закрыть.
Открыть с помощью Ворд. При открытии в запросе выбрать обычный текст. Откроется абракодабра.
В абракодабре найти символ (скорее всего группу символов), соответствующие символу � ромб.
Инструментом «заменить» заменить найденные символы на какие-нибудь другие (потом моно будет просто менять).
Сохранить.
Закрыить.
Открыть с помощью ворд, выбрав опять кодировку «Китайская упрощенная (GB 18030)».
Сохранить как docx.
Может можно и проще. Смысл понятен. Проблема в разных символах в разных кодировках. Еще проще написать какой-нибудь код, но это не для массового пользователя.
Php вопросы в ромбе
Кодировка на движке UTF-8, если добавляю новость, то в конце текста добавляется в мозиле символ вопроса в черном ромбе, в IE пустой квадрат.
прочитал что
| Цитата |
| Если кодировка интерфейса UTF-8, SAMS не правильно обрезает кириллические строки. Такие функции как substr отрезают по 1 байту. Это приводит к тому, что последний символ в кодировке UTF-8 обрезается лишь на 1 байт (в UTF-8 кириллица занимает 2 байта), что приводит к дефектному отображению последнего символа, от которого остается только 1 байт. |
substr заменил в коде на mb_substr ситуация не изменилась.
вот тот фрагмент кода в котором производил замену
if (strlen($row['name']) > $template['category_game_chars']) $game['name'] = mb_substr($row['name'], 0, $template['category_game_chars']).". ";
>
else $game['name'] = $row['name'];
>
if (strlen($row['description']) > $template['category_game_desc_chars']) $game['description'] = mb_substr($row['description'], 0, $template['category_game_desc_chars']).". ";
>
$row[‘name’] = iconv(«UTF-8», «CP1251//IGNORE», $row[‘name’]);
$row[‘name’] = mb_substr($row[‘name’], 0, 120);
$row[‘name’] = iconv(«CP1251», «UTF-8», $row[‘name’]);
| Цитата (mcsaka @ 13.05.2010 — 12:47) |
| $row[‘name’] = iconv(«UTF-8», «CP1251//IGNORE», $row[‘name’]); $row[‘name’] = mb_substr($row[‘name’], 0, 120); $row[‘name’] = iconv(«CP1251», «UTF-8», $row[‘name’]); |