Zeichencodierung: â?

Question

Ich versuche, die mysteriöse Zeichenkette â ???? Ich sehe einiges in unserer Datenbank - ich bin ziemlich sicher, dass dies ein Ergebnis der Konvertierung zwischen Zeichenkodierungen ist, aber ich bin nicht ganz positiv.

Die Benutzer können Text (oder Ausschneiden und Einfügen) in einen Ext-Js-Rich-Text-Editor eingeben. Die Daten werden in einem severlet geschrieben, die sie in die Datenbank weiterhin besteht, und wenn ich es in der Datenbank anzuzeigen sehe ich diese seltsamen Zeichen ...

1. ist es eine Möglichkeit, diese wieder in ihre ursprüngliche Bedeutung zu entschlüsseln, wenn ich die richtige Kodierung entdecken konnte - oder gibt es einen Verlust von Bits oder Bytes, der durch den Umwandlungsprozess aufgetreten ist?

2. Benutzer schneiden und fügen aus mehreren Versionen von MS Word und PDF. Folgt die Codierung dem Ort, von dem der Benutzer kopiert hat?

Danke

---

Website ist UTF-8 Wir MS SQL Server 2005 verwenden;

SELECT serverproperty ('Sortierung') - Serverstandardsortierung. Latin1_General_CI_AS

SELECT DATABASEPROPERTYEX ('xxxx', 'Collation') - Datenbankstandard SQL_Latin1_General_CP1_CI_AS

und die Säule:

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

Die nicht-Unicode-Äquivalente des Nchar, nvarchar und Ntext-Datentypen in SQL Server 2000 sind unten aufgeführt. Wenn Unicode-Daten in einem dieser nicht-Unicode-Datentyp Spalten durch eine Befehlsfolge eingefügt wird (andernfalls als „Sprachereignis“ bekannt), SQL Server wandelt die Daten in den Daten den Code Seite zugeordnet Verwendung mit der Kollatierung der Spalte. Wenn ein Zeichen nicht auf einer Codepage dargestellt werden, es wird durch ein Fragezeichen (?) Ersetzt, unter Angabe die Daten verloren. Aussehen von unerwarteten Zeichen oder eine Frage Markierungen in Ihren Daten zeigen, Ihre Daten von Unicode in Nicht-Unicode irgend Schicht umgewandelt wurde, und diese Umwandlung in Folge verloren Zeichen.

Das könnte also die Ursache für das Problem sein ... und nicht eine einfache Lösung für unser Ende.

Answer 1

Dies ist eine etwas erzogene Vermutung, dass Sie gerade eine naive Konvertierung von Word/PDF-Dokumenten in HTML erleben. (Windows-1252 bis utf8 am wahrscheinlichsten) Wenn das der Fall ist, sind wahrscheinlich 2/3 der mysteriösen Zeichen aus Word-Dokumenten "intelligente Zitate" und die meisten anderen sind ein Ergebnis ihrer anderen "intelligenten" Bearbeitungsfunktionen, elipsis, em strich usw. PDFs haben wahrscheinlich ähnliche Eigenschaften.

Ich würde auch vermuten, dass wenn die Formatierung nach dem Einfügen in den ExtJS-Editor OK aussieht, dann wird die Codierung weitergegeben. Abhängig von der resultierenden Verwendung des Textes müssen Sie möglicherweise nicht konvertieren.

Wenn ich noch auf der Basis bin, und wir nicht über Internationalisierungsprobleme reden, dann kann ich hinzufügen, dass es Word zu HTML-Konverter da draußen gibt, aber ich kenne die Details nicht, wie sie funktionieren, und Ich hatte gemischte Erfolge bei der Bewertung. Es ist fast sicher ein kleiner Informationsverlust/-fehler mit solchen Konvertern verbunden, da sie Vermutungen über die ursprüngliche Quelle der "intelligenten" Zeichen machen müssen. In meinem isolierten Fall war es einfacher, einfach zu den Benutzern zurückzukehren und sie die "intelligenten" Funktionen auszuschalten.

Answer 2

Sie speichern Unicode-Daten, die 2 Bytes pro Zeichen in Varchar-Spalten verwenden, die 1 Byte pro Zeichen verwenden. Jeder Text, der 2 Bytes pro Zeichen verwendet, wird 1 Byte verlieren, wenn er in der Datenbank gespeichert wird.

alles was Sie tun müssen, ist varchar Spalte in nvarchar zu ändern.
und dann sql-Parameter ändern, die Sie natürlich in Code verwenden.

Answer 3

Das Problem ist klar: Wenn der Browser gut genug ist, kann ein Formular in einer Webseite jedes Unicode-Zeichen akzeptieren, das Sie eingeben oder einfügen können. Wenn das Zeichen zum HTML-Zeichensatz gehört, wird es unverändert gesendet. Wenn dies nicht der Fall ist, wird es in eine HTML-Entität konvertiert. SQL Server führt die entsprechende Konvertierung aus und beschädigt im Hintergrund Ihre Daten, wenn ein Zeichen nicht gleichwertig ist.

Es gibt nicht viel, was Sie tun können, um es vollständig zu beheben, aber Sie können eine Umgehungsmöglichkeit schaffen: lassen Sie Ihr Servlet die Konvertierung durchführen. Auf diese Weise haben Sie die volle Kontrolle darüber. Sie können zum Beispiel eine Liste der am häufigsten verwendeten Nicht-Latin1-Zeichen erstellen, die Benutzer einfügen (intelligente Anführungszeichen, Unicode-Leerzeichen ...), die relativ einfach aus dem Kontext zu identifizieren sind, und sie durch etwas anderes besser ersetzen als ?. Oder du benutzt eine Bibliothek, die das für dich macht.

Oder Sie können Ihre DB zu Unicode wechseln :)

Answer 4

â als 0xE2 in ISO-8859-1 und windows-1252 codiert. 0xE2 ist auch ein Vorlaufbyte für eine Drei-Byte-Sequenz in UTF-8. (Speziell für den Bereich U + 2000 bis U + 2FFF, der die Fenster enthält - 1252 Zeichen –—‘’‚“”„†‡•…‰‹›€™).

Es sieht so aus, als ob Sie Text in UTF-8 codiert haben, der in Windows-1252 falsch interpretiert wird und als â gefolgt von zwei nicht druckbaren Zeichen angezeigt wird.