Englische Seite auf Japanisch Betriebssystem

Question

Eine Browser-Basisanwendung, die Daten in Englisch anzeigen und Daten in Englisch erfassen möchte, muss eine UTF-8-Datenbank haben?

Gibt es ein Problem, wenn auf die Website auf einem japanischen Betriebssystem zugegriffen wird? Wenn Benutzer nur in Englisch schreiben, müssen wir besondere Vorsicht walten lassen? Wenn der Benutzer Japanisch eingibt, wie kann das System dann einen Fehler erkennen und auslösen?

Die Website wird in .Net 3.5 entwickelt.

BEARBEITEN --------------------------------------------- ------------------------------------------

Ich nicht möchte Japanisch oder jede andere Sprache erfassen. Die Seite wird komplett englisch sein und der Benutzer sollte Informationen auch in Englisch eingeben. Das Anzeigen von englischen Zeichen auf dem japanischen Betriebssystem ist ebenfalls kein Problem. Das Problem ist, wenn Benutzer auf einem japanischen Betriebssystem japanische Zeichen in Textfeld eingibt, wie kann ich das dann identifizieren und einen Fehler an den Benutzer werfen? Zweitens wäre er in der Lage, englische Buchstaben in eine Textbox einzugeben?

Answer 1

Ich glaube nicht, dass es starke Gründe gibt, UTF-8 nicht zu verwenden. Sie wissen nie, wo seltsame Zeichen eindringen können.

Alle eingehenden Daten sollten verarbeitet und neu codiert werden. HTML-Formulare Mit Ihnen den folgenden Tag liefern können:

<input type="hidden" name="_charset_" value="" /> 

Alle Browser dies mit dem charset bevölkern sollten der Benutzer mit, können Sie dann diese verwenden zu dekodieren/Re-Encoding die Eingabe.

Auch wenn Sie es nicht gelesen haben, lesen Post Joel auf Unicode: http://www.joelonsoftware.com/articles/Unicode.html

Answer 2

Nun, Sie könnten einfach für nicht-'englisch 'Zeichen leicht genug überprüfen (Regulärer Ausdruck nehme ich an), aber ich sehe nicht, warum Sie würden. Aber du könntest das tun.

Ich sehe auch nicht wirklich einen guten Grund nicht NVARCHAR für benutzerdefinierte Textfelder verwenden. Anforderungen ändern sich oft.

Answer 3

Es ist immer einfacher, Multibyte-Zeichensatzunterstützung von Anfang an in eine Anwendung zu integrieren, anstatt sie später nachzurüsten.

Abgesehen davon, dass Sie den gesamten Code erneut durchsuchen müssen, werden Sie mit Fehlern beim Konvertieren Ihrer vorhandenen Datenbank in Unicode konfrontiert, und Sie können feststellen, dass es keinen guten Weg gibt, den Zeichensatz für ein bestimmtes Datenelement zu bestimmen codiert in erster Linie.

Answer 4

japanischen Schriften und Eingabemethoden haben „zwei“ Versionen der ‚Englisch‘ Zeichen in Unicode - die normale Breite und die "Wide/Monospaced" (die nützlich sind, wenn sie von oben nach unten oder von links nach rechts gedruckt werden). Seien Sie vorsichtig, wenn Sie versuchen, nicht-englische Zeichen herauszufiltern - wenn Sie einen Fehler zum Beispiel # 2 auslösen, werden Ihre Benutzer sehr verwirrt sein!

1) korrekt

codiert

2) korrekt

Die zweite Linie ist nicht eine andere Schriftart oder ‚Codierung‘ codiert - sie sind zusätzliche feste Breite Kopien unseres Alphabets, die gut innerhalb der Blöcke von Hiragana ausrichten/Katakana/Kanji (japanische Schrift).

Ich würde definitiv UTF8 Codierung und NCHAR/NVARCHAR in der Datenbank berücksichtigen.