UTF-8 and ë vs ë UTF-8 and ë vs ë
 

News:

cpg1.5.48 Security release - upgrade mandatory!
The Coppermine development team is releasing a security update for Coppermine in order to counter a recently discovered vulnerability. It is important that all users who run version cpg1.5.46 or older update to this latest version as soon as possible.
[more]

Main Menu

UTF-8 and ë vs ë

Started by ff, November 20, 2006, 09:50:15 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

ff

I made changes to the language file dutch.php because the special characters didn't show up right.
I was said that 'ë' was a standard, but I always learned that you had to use ë or ë, just to prevent problems.

UTF-8 is the standard at which CPG works and within that everything will work alright.

My server is set at : en_US.iso885915
Checking the files and index.php I get : iso-8859-1

In my opinion, the browser will automatically show iso-8859-1 and not UTF-8?
This will also be the reason that I won't get the right character, but something like 'A~'?

In my opinion it is better to always use the encoding than the special character.

Joachim Müller

Quote from: ff on November 20, 2006, 09:50:15 AM
My server is set at : en_US.iso885915
What do you mean by that? A server can't be set to a particular encoding. Coppermine's output can be set to a particular encoding (config -> Language & Charset settings -> Character encoding -> Unicode (recommended) ( utf-8)). The database collation can be set to a particular encoding.
For a start, please post a link to your coppermine-driven gallery and what you have set above mentioned settings to. Also post if you upgraded a previous version of coppermine (if yes: which version did you upgrade from) or if you performed a fresh install.

Quote from: ff on November 20, 2006, 09:50:15 AM
but I always learned that you had to use ë or ë, just to prevent problems.
True for iso8859-1 encoding, wrong for utf-8

ff

Quote from: GauGau on November 20, 2006, 10:02:59 AM
What do you mean by that? A server can't be set to a particular encoding. Coppermine's output can be set to a particular encoding (config -> Language & Charset settings -> Character encoding -> Unicode (recommended) ( utf-8)). The database collation can be set to a particular encoding.

I'm running a Linux computer with 'LANG=en_US.iso885915'.
phpinfo() returns : HTTP Response Headers text/html; charset=ISO-8859-15

Configuration of CPG:
Selected language : Dutch
Selected characterset : Western (iso-8859-1)

Quote
For a start, please post a link to your coppermine-driven gallery and what you have set above mentioned settings to. Also post if you upgraded a previous version of coppermine (if yes: which version did you upgrade from) or if you performed a fresh install.

Site at : http://www.ff.fm/fotoalbum/
Upgraded from 1.4.5 to 1.4.10 . In 1.4.5 I also made changes tot dutch.php

Quote
True for iso8859-1 encoding, wrong for utf-8

So if I put the characterset to Unicode, everything will work fine?
Why is the Western (iso-8859-1) there?

Joachim Müller

Quote from: ff on November 20, 2006, 10:21:44 AM
I'm running a Linux computer with 'LANG=en_US.iso885915'.
That's completely irrelevant - it's just the user interaction on the shell that is affected by those encoding sections. You have to think more in webserver terms: the shell may well be in iso8859-1, while content of the pages your webserver delivers might be in any other encoding - could be chinese, could be hebrew, could be unicode (and in the case of coppermine, it should be unicode, because that's what Coppermine was designed to be used with).

Quote from: ff on November 20, 2006, 10:21:44 AM
I'm running a Linux computer with 'LANG=en_US.iso885915'.
phpinfo() returns : HTTP Response Headers text/html; charset=ISO-8859-15
PHPinfo is of course in iso8859-1 as well, as it basically is just an HTML page generated by your server - it can be in any encoding the coder has decided to use.

Quote from: ff on November 20, 2006, 10:21:44 AM
Why is the Western (iso-8859-1) there?
Western encoding is there for historical reasons, for users who have upgraded from cpg1.3.x. As you started with a fresh copy of cpg1.4.x, you shouldn't have modified the language file and the encoding, but you should have left the recommended default encoding (utf-8) as it was set to and keep your fingers off the language file. Now it can be a bit tricky to switch: basically, you just set the encoding in coppermine's config back to utf-8 (as suggested above: you shouldn't have changed it in the first place). This will work fine for content added from the moment you switch to utf-8, however you might have issues with textual content inside your database (file titles, captions, comments etc.). You might have to convert those db entries from iso8859-1 to utf-8, using coppermine charsetmgr.php tool (which will work if you have iconv available on your server).

ff

Replaced dutch.php and set the encoding to UTF-8.

Everything works fine, except one.
http://www.ff.fm/fotoalbum/displayimage.php?pid=1097&fullsize=1

As far as I can see, my browser Fx1.5 doesn't detect UTF-8. Character encoding is set to iso-8859-15.

From http://www.ff.fm/fotoalbum/displayimage.php?pid=1097&fullsize=1:

<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
<title>Daniëlle &amp; Jeroens fotoalbum: Klik op de foto om dit venster te sluiten</title>
...
</head>


From http://www.ff.fm/fotoalbum/displayimage.php?pid=1097&fullsize=1:

<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta http-equiv="Pragma" content="no-cache" />
<title>Daniëlle &amp; Jeroens fotoalbum - Laatste toevoegingen/100 0424</title>
...
</head>


File titles and other text contents within de site are allright. I almost don't use special characters in filenames and titles.
Just recently in the site-title.

Joachim Müller

Not sure how those settings are labelled in your FF localization, but try this: "View" - "Encoding" - "Detect automatically" - "universal". This should make Firefox respect the encoding set by the document and fall back to iso8859-1 if no particular encoding is forced by poorly-setup pages. This is default for Firefox afaik.