Кодировка символов: â?

Question

Я пытаюсь собрать вместе загадочную строку символов â ?? Я вижу совсем немного в нашей базе данных - я уверен, что это результат преобразования кодировок символов, но я не совсем уверен.

Пользователи могут вводить текст (или вырезать и вставлять) в текстовый редактор Ext-Js. Данные размещены на severlet, которая сохраняется в базу данных, и когда я его просмотра в базе данных я вижу эти странные символы ...

1. есть ли способ, чтобы расшифровать их обратно к их первоначальному смыслу, если бы я смог найти правильное кодирование - или есть потеря бит или байтов, которые произошли в процессе преобразования?

2. Пользователи режут и вставляют из нескольких версий MS Word и PDF. Выполняется ли кодировка, с которой пользователь скопировал?

Спасибо

---

сайт UTF-8 Мы используем MS SQL Server 2005;

SELECT serverproperty ('Collation') - сортировка по умолчанию сервера. Latin1_General_CI_AS

ВЫБРАТЬ databasepropertyex ('хххх', 'Collation') - База данных по умолчанию SQL_Latin1_General_CP1_CI_AS

и колонка:

Column_name Type Computed Length Prec Scale Nullable TrimTrailingBlanks FixedLenNullInSource Collation 
text varchar no -1     yes no yes SQL_Latin1_General_CP1_CI_AS 

Не-Unicode эквиваленты NCHAR, nvarchar и ntext в SQL Server 2000 перечислены ниже. Когда данные Unicode, вставляется в одну этих колонн не-Unicode, типа данных через командную строку (в противном случае известен как «событие языка»), SQL- сервер преобразует данные в данные типа с использованием кодовой страницы, связанной с сортировкой столбца. Когда символ не может быть изображен на кодовой странице , заменен значком вопроса (?) с указанием данных был утерян. Появление неожиданных персонажей или вопрос знаков в ваших данных указывает на данные были преобразованы из Unicode в не-Unicode в некотором слое, и это преобразование привело к потере символов.

Так что это может быть основной причиной проблемы ... и нелегко решить на нашей стороне.

Answer 1

Это что-то вроде образованного предположения, что вы просто испытываете наивное преобразование документов Word/PDF в HTML. (скорее всего, Windows-1252 до utf8). Если это так, вероятно, 2/3 таинственных символов из документов Word являются «умными кавычками», а большинство остальных - результатом их других «умных» функций редактирования, elipsis, em dashes и т. д. PDF-файлы, вероятно, имеют схожие функции.

Я бы также предположил, что если форматирование после вставки в редактор ExtJS выглядит в порядке, то кодировка проходит. В зависимости от результата использования текста вам может не понадобиться конвертировать.

Если я все еще нахожусь на базе, и мы не говорим о проблемах интернационализации, то могу добавить, что есть конвертеры Word для HTML, но я не знаю подробностей о том, как они работают, и Я оценил их с успехом. Есть почти наверняка некоторые небольшие потери/ошибки информации, связанные с такими преобразователями, поскольку они должны делать предположения об исходном источнике «умных» символов. В моем изолированном случае было проще просто вернуться к пользователям и заставить их отключить «умные» функции.

Answer 2

Вы сохраняете данные Unicode, которые используют 2 байта на charcter в столбцы типа varchar, которые используют 1 байт на символ. любой текст, который использует 2 байта на символы, будет иметь 1 байт, потерянный при сохранении в db.

все, что вам нужно сделать, это изменить колонку varchar на nvarchar.
, а затем сменить параметры sql, которые вы используете в коде, конечно.

Answer 3

Проблема очевидна: если браузер достаточно хорош, форма на веб-странице может принимать любой символ Юникода, который вы можете ввести или вставить. Если символ принадлежит HTML-кодировке, он будет отправлен как есть. Если это не так, оно преобразуется в объект HTML. SQL Server выполнит соответствующее преобразование и автоматически испортит ваши данные, если у символа нет эквивалента.

Существует мало что можно сделать, чтобы полностью исправить это, но вы можете сделать обходное решение: пусть ваш сервлет выполняет преобразование. Таким образом, вы полностью контролируете это. Например, вы можете скомпилировать список наиболее распространенных папок для пользователей, не являющихся латинскими, (умные кавычки, пробелы в Юникоде ...), которые довольно легко идентифицировать из контекста и заменить их чем-то еще лучше, чем ?. Или вы используете библиотеку, которая делает это для вас.

Или вы можете переключить DB в Unicode :)

Answer 4

â кодируется как 0xE2 в ISO-8859-1 и Windows-1252. 0xE2 также является ведущим байтом для трехбайтовой последовательности в UTF-8. (В частности, для диапазона U + 2000 до U + 2FFF, который включает в себя символы Windows-1252 –—‘’‚“”„†‡•…‰‹›€™).

Таким образом, похоже, что у вас есть текст, закодированный в UTF-8, который неправильно интерпретируется как находящийся в windows-1252 и отображается как â, за которым следуют два непечатаемых символа.