---

Jeg står i den situation, at jeg skal lave et internationalt site. Det
skal være på flere sprog (først dansk og engelsk) - men samtidig vil
brugerne skulle indtaste nogle ting, som kan være på vidt forskellige
sprog (og ikke nødvendigvis det sprog, de har valgt - f.eks. kan en
russer godt indtaste noget russisk tekst, selv om han har valgt at se
sitet på engelsk).

Hvis brugeren på sitet vælger dansk som sprog, vil selve sidens tekst
vises på dansk - men der kan som sagt også være noget indhold fra en
anden bruger, der vises på f.eks. russisk. Altså får man blandet flere
forskellige tegnsæt.

Jeg bruger gettext til oversættelserne, og jeg vil helst undgå at lave
&etellerandet; for alle specialtegn i oversættelserne. Så løsningen må
være at lave det indhold, som brugerne kommer med, om til &etellerandet;
- men hvordan gør man det i PHP? Jeg har set på utf8_encode(), men den
enkoder kun ISO-8859-1-strenge, og jeg har brug for en funktion, der kan
tage noget f.eks. russisk tekst og omdanne specialtegnene til
&etellerandet;. Findes en sådan funktion? Hvis den ikke findes i PHP,
findes der så en sådan funktion i C/C++ (så kunne jeg jo forsøge mig med
at lave en PHP-udvidelse, der bruger den funktion)?

Hvis jeg nu holder fast i at undgå at enkode selve oversættelserne, men
til gengæld indkode brugerens tekst, så kan jeg jo i og for sig godt
holde fast i ISO-8859-1 som sidens tegnsæt (hvis sproget altså er dansk
eller engelsk) - eller hvad? Siden vil i så fald være gyldig HTML - men
får man så det problem, at almindelige ISO-8859-1-skrifttyper ikke
indeholder russiske tegn? Med andre ord: *Skal* jeg bruge utf8 som
sidens tegnsæt for at gøre det optimale forsøg på at få browseren til at
vise de rigtige russiske tegn - eller kan jeg godt bruge ISO-8859-1?

---

Hej Jonas,

"Jonas Koch Bentzen" <ingen.email@eksempel.dk> wrote in message
news:akptvu$4vi$1@sunsite.dk...
> Hvis brugeren på sitet vælger dansk som sprog, vil selve sidens tekst
> vises på dansk - men der kan som sagt også være noget indhold fra en
> anden bruger, der vises på f.eks. russisk. Altså får man blandet flere
> forskellige tegnsæt.
Dette taler klart for at du bruger UTF-8 på siden. Men du kommer
sandsynligvis i problemer på databasesiden -det er min oplevelse, at PHP
ikke har databasedrivere, som kan håndtere UTF-8 ordentligt, og derudover at
PHP internt ikke håndterer UTF-8 og tegnsætkonverteringer særligt godt via
mb_... -endnu.
Med UTF-8 får du binære karakterer, som skal overføres til basen (Unicode
karakterer betragtes som en "stream"), og det knækker halsen på nogle
databasedrivere, deriblandt mssql driveren, der kommer med PHP -dvs.
medmindre du vælger at gemme karaktererne som blob's i basen, så kan du
komme ud for mere eller mindre uforklarlige fejl i dine sql-statements ved
run-time.
Jeg har lavet en international site via PHP og MSSQL (spørg mig ikke hvorfor
denne kombination ;), og der var work-around at bruge ADO for at kunne gemme
i basen...

Tænk også på at du måske skal søge i de ting brugerne putter ind. Det ville
så måske være en idé at have engelske metadata, og så selve
beskrivelsen/sprogspecifikke data liggende for sig.

Der er en del overvejelser ifm. PHP og internationale sites -efter mine
prøvelser, vil jeg nok tænke mig om en gang eller to, om PHP er vejen, når
unicode skal håndteres. Jeg vil tro at Java ville være bedre i kombination
med andre databaser, eller også at holde sig helt i M$ verdenen og bruge ASP
+ IIS/MSSQL.

Hvis der er andre med mere positive erfaringer med PHP på dette område,
hører jeg meget gerne fra Jer!

-Jørgen

---

Jørgen Østergaard wrote:
>
> Med UTF-8 får du binære karakterer, som skal overføres til basen (Unicode
> karakterer betragtes som en "stream"), og det knækker halsen på nogle
> databasedrivere, deriblandt mssql driveren, der kommer med PHP

Jeg bruger normalt PostgreSQL, og jeg har hørt, at den skulle kunne
håndtere fremmedartede tegn rimelig godt. Ved du noget om, hvor gode
PHP's PostgreSQL-funktioner så er til at overføre værdierne uskadet til PHP?

> -dvs.
> medmindre du vælger at gemme karaktererne som blob's i basen

Men det kan jeg vel så bare gøre? Der er vel ikke så store ulemper ved det?

---

Hej Jonas,

"Jonas Koch Bentzen" <ingen.email@eksempel.dk> wrote in message
news:al0o9u$g7e$1@sunsite.dk...
> Jørgen Østergaard wrote:
> >
> > Med UTF-8 får du binære karakterer, som skal overføres til basen
(Unicode
> > karakterer betragtes som en "stream"), og det knækker halsen på nogle
> > databasedrivere, deriblandt mssql driveren, der kommer med PHP
>
> Jeg bruger normalt PostgreSQL, og jeg har hørt, at den skulle kunne
> håndtere fremmedartede tegn rimelig godt. Ved du noget om, hvor gode
> PHP's PostgreSQL-funktioner så er til at overføre værdierne uskadet til
PHP?

Kender intet til PostgreSQL basen og dennes håndtering af unicode, eller for
såvidt PHP's funktioner i den retning.

>
> > -dvs.
> > medmindre du vælger at gemme karaktererne som blob's i basen
>
> Men det kan jeg vel så bare gøre? Der er vel ikke så store ulemper ved
det?
>

Jo, der er store ulemper ved det. Du kan f.eks. ikke sortere på kolonnerne
med binært indhold, du kan ikke lave selv simple søgninger, kun operatorerne
=, != giver mening. Du kan så indvende, at du kan bruge funktioner til at
konvertere frem og tilbage mellem det binære indhold og unicode, men det er
en performance-killer.
Mange af gevinsterne ved at bruge en relationel database forsvinder.
Medmindre selvfølgelig, at unicode teksten aldrig bruges til at sortere på,
genfinde data på etc., så kan du sagtens gøre det.

vh. Jørgen

---

Jørgen Østergaard wrote:
>>>medmindre du vælger at gemme karaktererne som blob's i basen
>>
>>Men det kan jeg vel så bare gøre? Der er vel ikke så store ulemper ved
>
> det?
>
>
> Jo, der er store ulemper ved det. Du kan f.eks. ikke sortere på kolonnerne
> med binært indhold, du kan ikke lave selv simple søgninger, kun operatorerne
> =, != giver mening.

Hmm - det kan jeg godt nok ikke forstå - i min MySQL-bog står der at
forskellen på 'text' og 'blob' er at sidstnævnte kan søge case-sensitivt
i modsætning til førnævnte af de to. Det hænger ikke sammen med dit
statement hvis jeg har forstået dig rigtigt...

Jeg har også lige testet lidt, ved at ændre et felt med 'text' til
'blob', og

SELECT *
FROM `help`
WHERE tekst
like '%Privatliv%' LIMIT 0, 30

gav nydeligt det hit den skulle...

mvh

Jesper Brunholm

--
Phønix - dansk folk-musik fra unge musikere - http://www.phonixfolk.dk

---

Hej Jesper,

Venlig hilsen/Best regards Jørgen Østergaard _____ http://endjin.com
"Jesper Brunholm" <nospam@brunholm-scharff.dk> wrote in message
news:al2bln$asg$1@news.net.uni-c.dk...
> Jørgen Østergaard wrote:
> >
> > Jo, der er store ulemper ved det. Du kan f.eks. ikke sortere på
kolonnerne
> > med binært indhold, du kan ikke lave selv simple søgninger, kun
operatorerne
> > =, != giver mening.
>
> Hmm - det kan jeg godt nok ikke forstå - i min MySQL-bog står der at
> forskellen på 'text' og 'blob' er at sidstnævnte kan søge case-sensitivt
> i modsætning til førnævnte af de to. Det hænger ikke sammen med dit
> statement hvis jeg har forstået dig rigtigt...
>
> Jeg har også lige testet lidt, ved at ændre et felt med 'text' til
> 'blob', og
>
> SELECT *
> FROM `help`
> WHERE tekst
> like '%Privatliv%' LIMIT 0, 30
>
> gav nydeligt det hit den skulle...

Du har delvist ret for så vidt angår MySQL, hvor BLOBs kategoriseres som en
string-type (den var jeg faktisk ikke opmærksom på, da jeg aldrig har brugt
den til BLOBs). Men MySQL kræver jo også at du bruger en funktion på disse
kolonner for f.eks. at kunne sortere på dem.
En BLOB er normalt en type du f.eks. bruger til at gemme f.eks. billeder
eller andre binære data i -deraf navnet Binary Large OBject.
Check f.eks. MSSQL's binary/varbinary/image typer (eller læs KB Q232580 -den
gennemgår faktisk UTF-8 problemerne i forhold til MSSQL), eller Oracle's
LOB-typer.
Jeg brugte nok BLOB's for generelt i sidste post, men hovedbudskabet var at
når du beskæftiger dig med LOB's (B og C) kommer du i de fleste tilfælde
meget hurtigt ud i begrænsninger mht. den SQL du kan bruge på dem, og kan
blive nødt til at ty til funktioner, der kan håndtere indholdet.

Jørgen

---

Jørgen Østergaard wrote:
> Hej Jesper,

[snip - fin forklaring på SQL og BLOB/CLOB]

OK - takker - jeg er en del klogere


mvh

Jesper Brunholm

--
Phønix - dansk folk-musik fra unge musikere - http://www.phonixfolk.dk

---

Jørgen Østergaard wrote:
>
> du kommer
> sandsynligvis i problemer på databasesiden -det er min oplevelse, at PHP
> ikke har databasedrivere, som kan håndtere UTF-8 ordentligt, og derudover at
> PHP internt ikke håndterer UTF-8 og tegnsætkonverteringer særligt godt via
> mb_... -endnu.
> Med UTF-8 får du binære karakterer, som skal overføres til basen (Unicode
> karakterer betragtes som en "stream"), og det knækker halsen på nogle
> databasedrivere, deriblandt mssql driveren, der kommer med PHP -dvs.
> medmindre du vælger at gemme karaktererne som blob's i basen, så kan du
> komme ud for mere eller mindre uforklarlige fejl i dine sql-statements ved
> run-time.

Jeg har lige udført nogle forsøg med PostgreSQL samt browserne Mozilla,
Konqueror og Opera, og resultaterne var overmåde positive: Alle
browserne overfører dataene korrekt (i UTF-8-format), og dataene bliver
gemt korrekt i PostgreSQL (jeg bruger CHARACTER VARYING til kolonnen).
Godt nok vises tegnene i PostgreSQLs kommandolinjeklient forkert, men
når først tegnene kommer ud på websiden, hvor tegnsættet er UTF-8,
virker alt glimrende. Jeg var i stand til at gemme både æ, ø, og å samt
kinesiske og georgiske tegn, og det hele så perfekt ud, når det kom ud
på siden. Det var også muligt at søge i indholdet af databasen.

En lille, spøjs ting: I XHTML kan man angive tegnsættet på to måder - enten

<?xml version='1.0' encoding='UTF-8' ?>

eller

<meta http-equiv='Content-Type' content='text/html; charset=UTF-8'/>

Ingen af de browsere, jeg testede i, ændrede tegnsæt på siden, når jeg
angav tegnsættet i <?xml - men alle ændrede tegnsæt på siden, hvis det
stod som meta http-equiv.