Эта статья имеет рейтинг List-class по шкале оценки контента Википедии . Она представляет интерес для следующих WikiProjects : | |||||||||||||||||||||||||||||||
|
| |
This page has archives. Sections older than 730 days may be automatically archived by Lowercase sigmabot III when more than 3 sections are present. |
Большая часть текста вокруг заменяющих символов представляет собой очень однобокое мнение. Википедия не должна быть местом, где можно пытаться навязать программистам текстовых редакторов свою точку зрения. А предложение «просто сохраните файл как есть» полностью игнорирует проблемы пользователей, изменяющих или копирующих и вставляющих эту часть файла из одной точки в другую. Если редактор редактирует его в UTF-8, то он должен предполагать, что пользователь создал текст в UTF-8, даже если редактор изначально предоставил mojibake.
Однако это все не имеет значения, поскольку «как вводятся заменяющие персонажи» — это лишь малая часть «что такое заменяющий персонаж».
Предложение сделать вид, что базовые данные были Windows-1252, является еще одной точкой зрения, ориентированной на США, и не поможет, если в ваших данных уже есть U+FFFD. — Предыдущий неподписанный комментарий добавлен Krestadroxefotk (обсуждение • вклад ) 18:28, 19 октября 2022 (UTC)
Точно: Заменяющий символ � (часто отображается как черный ромб с белым вопросительным знаком) — это символ, который находится в стандарте Unicode в кодовой точке U+FFFD в таблице Specials. Он используется для указания проблем, когда система не может отобразить поток данных в правильный символ.[4] Обычно он виден, когда данные недействительны и не соответствуют ни одному символу:
Хороший пример, но это не единственная причина. Рассмотрим текстовый файл, содержащий немецкое слово für (что означает «для») в кодировке ISO-8859-1 (0x66 0xFC 0x72). Теперь этот файл открыт в текстовом редакторе, который предполагает, что входные данные — UTF-8. Первый и последний байты являются допустимыми кодировками UTF-8 ASCII, но средний байт (0xFC) не является допустимым байтом в UTF-8. Поэтому текстовый редактор может заменить этот байт на символ замены, чтобы создать допустимую строку кодовых точек Unicode. Вся строка теперь отображается так: «f�r».
Дополнительные возможности: Неправильные подстроки могут привести к недопустимым UTF-8 или UTF-16, которые могут превратиться в заменяющие символы. Например, если für в кодировке UTF-8 находился позже в предложении, и приложение использовало первые 16 байт для выполнения какой-то работы, возможно, что оно может получить неполный фрагмент ü в кодировке UTF-8.
Другая возможность — повреждение данных во время передачи. Измененный бит или усеченный пакет могут содержать нелегально закодированный Unicode, который может быть изменен на U+FFFD для указания ошибки.
Неуместные домыслы. Это не учитывает, что произойдет, если пользователь «исправит» некоторые случаи и/или переместит текст, или многие другие соображения. Мусор на входе, мусор на выходе. Плохо реализованный текстовый редактор следует исправить, используя правильную кодировку при чтении файла. Плохо реализованный текстовый редактор может сохранить замену в форме UTF-8; тогда данные текстового файла будут выглядеть так: 0x66 0xEF 0xBF 0xBD 0x72, что будет отображаться в ISO-8859-1 как «f�r» (это называется mojibake). Поскольку замена одинакова для всех ошибок, это делает невозможным восстановление исходного символа. Лучший (но более сложный в реализации) дизайн — сохранить исходные байты, включая ошибку, и преобразовывать в замену только при отображении текста. Это позволит текстовому редактору сохранить исходную последовательность байтов, при этом по-прежнему показывая пользователю индикатор ошибки.
Разумный В свое время заменяющий символ часто использовался, когда в шрифте не было глифа для этого символа. Однако большинство современных систем рендеринга текста вместо этого используют символ .notdef шрифта, который в большинстве случаев представляет собой пустой квадрат (или "?" или "X" в квадрате[5]), иногда называемый "tofu" (этот браузер отображает �). Для этого символа нет кодовой точки Unicode.
Первое предложение из следующего верно. Остальное — предположение и рассматривает только один возможный способ внесения ошибок. Предлагаемый обходной путь не только не является глобальным, но и полностью игнорирует многие другие возможные причины поврежденного потока данных. Что может усугубить, а не улучшить проблему. В некоторых контекстах это может быть интересно, но это широкое обобщение недействительно и не должно так настойчиво поощряться в Википедии.
Таким образом, символ замены теперь виден только для ошибок кодировки, таких как недопустимый UTF-8. Некоторое программное обеспечение пытается скрыть это, транслируя байты недопустимого UTF-8 в соответствующие символы в Windows-1252 (поскольку это наиболее вероятный источник этих ошибок), так что символ замены никогда не виден. — Предыдущий неподписанный комментарий добавлен Krestadroxefotk (обсуждение • contribs ) 18:39, 19 октября 2022 (UTC)
Почему заменяющий символ описан как черный ромб с белым вопросительным знаком , когда это квадрат? Конечно, все квадраты являются ромбами… Но тогда почему бы не назвать его прямоугольником? Или четырехугольником? Или даже многоугольником? Aeron -- 2A01:CB1D:2E8:D000:223B:609C:AD60:6D0 (обсуждение) 09:06, 10 июня 2022 (UTC)
Раздел «История версий Unicode» в информационном поле содержит сведения о том, сколько символов было назначено в каждом выпуске. Я думаю, что повторять это в тексте бессмысленно. Я предлагаю полностью удалить предложение « Из этих 16 кодовых точек, пять были назначены после Unicode 3.0» . Если это неприемлемо, нам нужно прояснить формулировку этой избыточной детали. Я против «по состоянию на Unicode 3.0», потому что это создает впечатление, что статья устарела. Аналогично я против последней формулировки «с Unicode 3.0», потому что с момента выпуска версии 3.0 не было назначено ни одной кодовой точки. « Из этих 16 кодовых точек, пять были назначены» — это точно, но снова избыточно, поскольку информационное поле дает более подробную информацию. Я предпочитаю удалить это предложение. DRMcCreedy ( talk ) 22:08, 21 октября 2024 (UTC)