[SQL] Japanse tekst

[Urk]

Wij zijn bezig met een webapplicatie die wereldwijd draait.
De applicatie is verdeeld in 6 regio's waaronder Japan.

Japan wil graag met eigen karakters werken, dus input van japanse taal/karakters.
We krijgen dan wel te maken met problemen in de database, hoe kan ik ervoor zorgen dat zowel engelse tekst (ook tekens met interpunctie/leestekens) EN japanse tekst goed word opgeslagen in SQL en weergegeven op de site??

Heeft iemand hier daar wat meer algemene informatie over? Hoe gaat dat in zijn werk en wat is de beste manier om dat aan te pakken?

We zijn zelf al bezig geweest met ASP Codepage en META tags zoals bijv: <meta http-equiv="Content-Type" CONTENT="text/html; charset=shift_jis"> die wel japanse tekens goed weergeeft maar dan niet meer de leestekens (bijv ÿ)
Maar dit heeft nog niet het gewenste en perfecte resultaat opgeleverd.

Hopelijk kan iemand een stukje hierover vertellen...

Alvast

[Erkens]

Welke SQL server?

en is unicode niet wat je nodig hebt als je allebei wilt

[whoami]

Je zult je teksten enzo alleszins in unicode moeten opslaan (NVARCHAR gebruiken bv. ipv VARCHAR, etc...)
Ik heb onlangs nog eens een interessant document gevonden op MSDN hieromtrent. Ik zal het eens opzoeken.

Ik geloof dat het ditwas.

[ Voor 26% gewijzigd door whoami op 03-09-2004 10:21 ]

[Urk]

We gebruiken MS SQL Server 2000.
En wat zijn precies de voordelen van Unicode, wat houd het precies in. Dat het een charset is weet ik maar verder...

Tevens heb ik sommige velden in SQL 2000 al van varchar omgezet naar nvarchar, maar wat is precies het verschil?

[ Voor 9% gewijzigd door Urk op 03-09-2004 10:35 ]

[Soultaker]

The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)

[Banpei]

Dit heeft mij bij mijn vorige baan ook heel erg veel hoofdpijn bezorgd. Wat ik uiteindelijk heb gedaan (ook omdat de teksten weer in pdf moesten) is bij de formtag ook de content type specificeren (utf), in browsers die dit ondersteunen krijg je dan de html-entities terug (dus

code:

輢

bijvoorbeeld) en deze kan je dan eventueel of zelf parsen, of worden onafhankelijk van jouw content-type altijd goed weergegeven in de browser indien er voor dat charcter een unicode font beschikbaar is. Unicode fonts zijn vaker op systemen aanwezig dan regionale fonts (zoals bijvoorbeeld shift_JIS, BIG5, windows-xxx en iso-8869-x).

edit:
Essentie van mijn verhaal is dat html-entities wel opgeslagen kunnen worden in elke database...

[ Voor 11% gewijzigd door Banpei op 03-09-2004 11:29 ]

[Verwijderd]

Urk schreef op 03 september 2004 @ 10:22:
We gebruiken MS SQL Server 2000.
En wat zijn precies de voordelen van Unicode, wat houd het precies in. Dat het een charset is weet ik maar verder...

Tevens heb ik sommige velden in SQL 2000 al van varchar omgezet naar nvarchar, maar wat is precies het verschil?

uit BOL:
nvarchar(n)
Variable-length Unicode character data of n characters. n must be a value from 1 through 4,000. Storage size, in bytes, is two times the number of characters entered. The data entered can be 0 characters in length. The SQL-92 synonyms for nvarchar are national char varying and national character varying

het enige veschil met varchar is dat hier non- voor Unicode is weggehaald, en dat je maar de helft van het aantal chars kwijt kunt, omdat Unicode nou eenmaal dubbele ruimte inneemt...