Generisk spørgsmål om projekter

[NickyThomassen]

Jeg overvejer at lave et projekt, hvor menneske-tekst (dansk, svensk osv) bliver gemt i en database fra en hjemmeside / app via PHP, og som så kan hentes frem igen senere. Det siger selv at UTF-8 er valgt på forhånd.

Det kan lyde ret trivielt, hvilket jeg også selv gik ud fra.

Under en gennemgang af noget PHP database dokumentation på en tilfældig blog, var der en sidebemærkning om, at "husk nu at bruge utf8mb4" i MySQL. Så ud af nysgerrighed slog jeg UTF-8 op hos Oracle og lagde mærke til "3-Byte UTF-8 Unicode Encoding" i overskriften.

Og det er jo lidt underligt, da UTF-8 bruger op til 4 bytes, og ikke kun op til 3. utf8mb4 er MySQL's egentlige UTF-8 lagringsmetode, som så tilgengæld bruger 4 bytes lige meget hvad. Sådan da. Dokumentationen er lidt rodet.

OK.

Så UTF-8 i MySQL er altså ikke kompatibelt med UTF-8. Og det får mig jo til at tænke, om der måske er andet der ikke er som jeg tror det er, hvilket jo selvfølgelig ikke er nemt at svarer på.

Mit spørgsmål er derfor, hvordan undgår I problemer af den type som ville være opstået, hvis jeg ikke have opdaget det her?

Jeg vil i hvert fald nødig skulle prøve mig frem. Omfattende testing er tydeligvis et must, sammen med en grundig gennemgang af den officielle dokumentation. Og i dette tilfælde tror jeg endda at MySQL bliver skrottet som database til projektet, for noget så hjernedødt har jeg da sjældent set.

[AJenbo]

Test om du kan lave en lort http://www.fileformat.info/info/unicode ... /index.htm
Hvis du kan det er der korrekt UTF8 undersøttelse.

Jeg har set nogle mellemstore firmaer omgåes MySQL UTF8 begrænsningen ved at dobbelt enkode UTF8 hvilket for mig blot viste at de ikke har læst dokumentationen da de stødte på problemet. Samtidig hade de også godkendelse af bruger login med sammenligningen af HASH i MySQL uden at have sat kolonden til case-sensitive. Kort sagt kan det altid lykkes at lave nogen dårlige løsninger hvis man vil.

I ældre udgaver af UTF8 var der kun defineret symboler for de første 3 bytes, hvilket er hvad der har ført til problemet med MySQL's oprindelige UTF8 implementering.

PHP har i øvrigt heler historisk den bedste UTF8 understøttelse, men det gælder nærmest alle systemer og sprog på et vist tidspunkt.

[NickyThomassen]

Test om du kan lave en lort

Må jo nok indrømme at det tog nogle forsøg at forstå dén sætning

Men det er en god idé, og helt klart noget der er skrevet på listen over tests der skal gennemføres jævnligt. Egentlig regner jeg med at udvide ideen til at bruge en test-skabelon, som indeholder en række tegn fra alle 4 bytes.

Det næste problem bliver så at vælge nogen som Firefox / systemet kan vise. Lorten virker fint, men der er en del UTF-8 tegn jeg ikke kan se.

[AJenbo]

Så skal du have nogle bedre skrift typer

[NickyThomassen]

Eller det vil sige, det gør den ikke

1F4A9.png (36.77 KiB) Vist 513 gange

Det var de server-generet billeder jeg havde haft kigget på

[NickyThomassen]

Så skal du have nogle bedre skrift typer

Meget bedre, åbenbart