WN - Databas med MySQL, men med ISO som output?

WN (https://www.wn.se/forum/index.php)

- Serversidans teknologier (https://www.wn.se/forum/forumdisplay.php?f=4)

- - Databas med MySQL, men med ISO som output? (https://www.wn.se/forum/showthread.php?t=33879)

Har MySQL-databas med UTF-8 som teckenkodning. Hela webbplatsen är i UTF-8, så det funkar finfint, men nu är det så att jag behöver kunna generera en produktfeed från webbshopen, och denna ska levereras med ISO-8859-1. Tydligen klarar inte den andra parten av att avkoda en UTF-8-fil.

Klassisk asp är det som gäller. Förslag på hur lösa?

Har testat följande, men den tar bara bort alla "fula" tecken istället för att byta ut dem mot de rätta.

Kod:

s = Replace(s,"Ã¥","å")

Edit: i rubriken för tråden skulle det ju förstås stå att det är UTF-8 som gäller i databasen, men det går inte ändra nu... Men det står åtminstone i första raden i inlägget nu.

Har du testat Google med orden VB UTF8 ISO8859? Till exempel den här träffen? :rolleyes:

Kräver ju iofs att man har en komponent installerad på servern... Annars var tanken god.

Finns det ingen motsvarighet till php's utf8_decode()?

Edit: Kan ingen asp men kan inte detta vara något? http://www.example-code.com/asp/asp-charse...rt-tutorial.asp

select convert(utf8_kolumn using latin1)

MySQL:s konverteringsfunktioner (som Magnus_A nämnde) är vida överlägsna de inbyddga funktionerna i de flesta skriptspråk och är enklare att implementera. Låt MySQL göra det det är bra på.

Borde för övrigt även fungera att SET NAMES latin1 istället för att konvertera varje fält i tabellen.

Citat:

Originally posted by martine@Dec 11 2008, 11:18

...
Borde för övrigt även fungera att SET NAMES latin1 istället för att konvertera varje fält i tabellen.

Smart, då är det bara att skicka en extra sträng till mysql istället för att skriva om hela frågan.

Detta tycker jag också verkar vara en väldigt bra lösning. Problemet är att jag inte får den att funka...

När jag kör "set names latin1" precis raden före jag kör min select så spottar den fortfarande ur sig utf8. Testade även samma kommandon i MySQL-Front som jag använder som editor, samma sak där, ingenting händer. Dock inga felmeddelanden.

Och vad händer om du sänder set names utf8?
Kolla upp hur anslutningen ser ut, finns risk att du kört in utf8 i en tabell med names satt till latin1, då är du lika illa ute som jag var.. du kan köra in och ut och få tillbaka det du lade in men aldrig använda dig av mysqls inbyggda funktioner för kodning.

Alla tabeller är satta med utf8, dubbelkollade nu. Fast om det var fel borde jag väl få problem på hemsidan i övrigt? Är noga att på varje html-sida lägga med charset både i headern och i meta-taggen, så jag är ganska säker på att all data i databasen har rätt teckenkodning eftersom den visas korrekt.

Backup-plan: Webhotellet stöder php och asp.net, testade php nu och använde utf8_decode-funktionen, men den ersätter bara med frågetecken... Det går inte så bra för mig...

Den kan visas korrekt även om det är fel i förhållande till vad inställningarna är.
Blev inte klar på om du får samma resultat även om du sänder frågan
set names utf8;
innan?

Vad skriver du i för språk? asp.net? (vb.net eller c# isf?) Leta efter charset eller liknande på response-objektet

Intressant, med "set names utf8" blir ordet "ingå" istället "ingÃƒÂ¥", kör jag latin1 blir det "ingÃ¥" (när webbläsaren är inställd på iso vill säga, ändrar jag webbläsarinställningarna till utf8 blir det "ingÃ¥")

Använder som sagt klassisk asp (tyvärr, mycket jobb att koda om allting)

Citat:

Originally posted by Lindahl@Dec 11 2008, 23:59
Intressant, med set names utf8 blir ordet ingå istället ingÃƒÂ¥, kör jag latin1 blir det ingÃ¥ (när webbläsaren är inställd på iso vill säga, ändrar jag webbläsarinställningarna till utf8 blir det ingÃ¥)

Det var som jag befarade. Dit innehåll i databaserna är det inget fel på, Mysql lagrar bara tecken och tar fram dem igen och det fungerar på din burk.
Det är bara det att i tidernas gryning lade du in utf8-material fast anslutningen var satt till latin1 (set names latin1, vilket av nån konstig anledning är/var standard i mysql). Därmed kan du aldrig få tillbaka det som läsbar text annat än om du kombinerar en anslutning i latin1 med att du i webbläsaren tolkar det som utf8. Alla andra kombinationer ger oönskade resultat.

Men eftersom databaserna inte innehåller det som mysql tror att de innehåller så kan du inte använda mysql:s inbyggda funktioner för konvertering. Du måste dumpa ut innehållet, inte via mysqldump (eftersom det kommer att ge dig ingÃƒÂ¥ istället för ingå - pröva), utan genom en egen dump som bygger på frågor när du har ditt anslutning satt till latin1, Sen får du köra in allt igen fast då med ändrat anslutning till utf8.
Hårt jobb men det lönar sig att ligga rätt positionerad i teckendjungeln.

Det behöver inte alls vara så komplicerat som Magnus_A säger. Återigen låt MySQL göra det som det kan bäst.

Om fälten är i utf8 men deklarerade som latin1 så räcker:
ALTER TABLE x MODIFY y [TEXT el. VARCHAR(n)] CHARACTER SET utf8

Om det måste konverteras: (verkar inte vara fallet för din del)
ALTER TABLE x CONVERT TO CHARACTER SET utf8

Annars om den faktiska teckenkodningen är i någon feldeklarerad form så får du först konvertera innehållet till BINARY (då har du den råa teckenkoden som du sedan kan applicera teckenuppsättningar eller konverteringar på):
ALTER TABLE x MODIFY y BLOB osv.
ALTER TABLE x MODIFY y TEXT osv. CHARACTER SET utf8

Klona en tabell och prova tills du fått fram rätt tabell (glöm som alltid inte att ta en backup när du gör större förändringar i databasen).

Det hela finns detaljerat beskrivet i MySQL:s dokumentation:
http://dev.mysql.com/doc/refman/5.0/en/alt...lter-table.html
se någonstans mitt på sidan .

Jag har haft nästan hur tokiga tabeller som helst med blandat latin1, latin2, utf8 som latin1, latin2 som latin1, osv. utan att det har varit särskilt svårt att låta MySQL konvertera det hela till rätt teckenuppsättning. Den bästa vägen brukar vara att gå via BINARY.

PS För att se vad du har för deklarerad teckenuppsättning så kör SHOW FULL COLUMNS FROM x, har jag för mig.

Får bli till att experimentera lite med detta i helgen. Ska ta backuper också, blev lite nervös igår när MySQL-Front helt plötsligt tog bort innehållet i alla fält som innehöll specialtecken, men som tur var räckte det att starta om programmet, databasen var intakt (vilket vore konstigt annars, hade ju bara kört med SELECT).

Citat:

Det är bara det att i tidernas gryning lade du in utf8-material fast anslutningen var satt till latin1 (set names latin1, vilket av nån konstig anledning är/var standard i mysql).

Innebär detta att jag fortsättningsvis alltid måste köra med set names utf8 före jag gör en databasfråga, eller går det ändra så att det alltid är standard?

Citat:

Originally posted by Lindahl@Dec 12 2008, 12:07
Innebär detta att jag fortsättningsvis alltid måste köra med set names utf8 före jag gör en databasfråga, eller går det ändra så att det alltid är standard?

Säkrast är att alltid SET NAMES vid varje uppkoppling (inte före varje fråga).

Konvertera latin1 till utf8 går bra med martines metod, men jag har inte fått det att fungera på kolumner där jag fått in utf8 i latin1-kolumner.
Ingen skulle vara gladare än jag om jag får binary-metoden att fungera, så hjälp mig gärna att hitta rätt.
Jag har dock använt för många timmar på att försöka konvertera fält och databaser utan att nå önskade resultat, så jag använder numer andra genvägar.

Citat:

Originally posted by Magnus_A@Dec 12 2008, 12:45
Konvertera latin1 till utf8 går bra med martines metod, men jag har inte fått det att fungera på kolumner där jag fått in utf8 i latin1-kolumner.
Ingen skulle vara gladare än jag om jag får binary-metoden att fungera, så hjälp mig gärna att hitta rätt.
Jag har dock använt för många timmar på att försöka konvertera fält och databaser utan att nå önskade resultat, så jag använder numer andra genvägar.

Genvägar? Omvägar menar du? (Förresten gjorde du en utmärkt analys av vad problemet var så jag hoppas att du inte bara tycker jag gnäller.)

Jag kan bara bekräfta att jag ett flertal gånger har konverterat (via BINARY) utf8-kolumner som varit deklarerade som latin1 så att de blir korrekta (precis som du säger uppstår problemet på genom att MySQL innan version 5 (egentligen 4.1 för att vara exakt) inte hade något stöd för unicode vilket gjorde att man var tvungen att spara utf-8 i latin1-deklarerade kolumner).

Dokumentationen för MySQL förklarar som sagt hur man gör (länkad i inlägget ovan):

Citat:

If you want to change the table default character set and all character columns (CHAR, VARCHAR, TEXT) to a new character set, use a statement like this:

ALTER TABLE tbl_name CONVERT TO CHARACTER SET charset_name;
For a column that has a data type of VARCHAR or one of the TEXT types, CONVERT TO CHARACTER SET will change the data type as necessary to ensure that the new column is long enough to store as many characters as the original column. For example, a TEXT column has two length bytes, which store the byte-length of values in the column, up to a maximum of 65,535. For a latin1 TEXT column, each character requires a single byte, so the column can store up to 65,535 characters. If the column is converted to utf8, each character might require up to 3 bytes, for a maximum possible length of 3 × 65,535 = 196,605 bytes. That length will not fit in a TEXT column's length bytes, so MySQL will convert the data type to MEDIUMTEXT, which is the smallest string type for which the length bytes can record a value of 196,605. Similarly, a VARCHAR column might be converted to MEDIUMTEXT.

To avoid data type changes of the type just described, do not use CONVERT TO CHARACTER SET. Instead, use MODIFY to change individual columns. For example:

ALTER TABLE t MODIFY latin1_text_col TEXT CHARACTER SET utf8;
ALTER TABLE t MODIFY latin1_varchar_col VARCHAR(M) CHARACTER SET utf8;
If you specify CONVERT TO CHARACTER SET binary, the CHAR, VARCHAR, and TEXT columns are converted to their corresponding binary string types (BINARY, VARBINARY, BLOB). This means that the columns no longer will have a character set and a subsequent CONVERT TO operation will not apply to them.

If charset_name is DEFAULT, the database character set is used.

Warning
The CONVERT TO operation converts column values between the character sets. This is not what you want if you have a column in one character set (like latin1) but the stored values actually use some other, incompatible character set (like utf8). In this case, you have to do the following for each such column:

ALTER TABLE t1 CHANGE c1 c1 BLOB;
ALTER TABLE t1 CHANGE c1 c1 TEXT CHARACTER SET utf8;
The reason this works is that there is no conversion when you convert to or from BLOB columns.

To change only the default character set for a table, use this statement:

ALTER TABLE tbl_name DEFAULT CHARACTER SET charset_name;
The word DEFAULT is optional. The default character set is the character set that is used if you do not specify the character set for columns that you add to a table later (for example, with ALTER TABLE ... ADD column).

Tyvärr har jag ingen tabell som jag kan testa på just nu och orkar inte heller göra en test. Men det ska inte vara särskilt svårt (det brukar vara steget med BINARY som de flesta missar). Jag hoppas glädjen infinner sig… ;)

Edit: Relevant mening i dokumentationen nu röd.

Det som hänt här är att kodningen blivit skruvad ett steg för långt. När tecknet för å i utf8 matades in i tabellen första gången, via anslutningen latin1 (set names latin1), blev det tvåbytes som bildar å tolkade som två separata tecken, vart och ett representerat av två bytes När man kallar fram det med samma anslutning altin1, så returnerar mysql två bytes som tillsammans "råkar" bilda bokstaven å.
Ändrar man sedan anslutningen till utf8 (set names utf8) så levererar mysql helt korrekt två bytes som behövs för att rendera de två tecken som tidigare bildade bokstaven å.
Vi får alltså ut fyra bytes där vi istället bara skulle haft två, dessa kombinationer bildar inga vettiga tecken och där för ser vi vad Lindahl ser :

Citat:

Intressant, med "set names utf8" blir ordet "ingå" istället "ingÃƒÂ¥",

Det är varje fall min tolkning av vad som händer, jag tar gärna emot förslag på förbättringar :)

för den som vill pula lite i mysql kan roa sig med följade terminalövning:

Citat:

SET NAMES latin1;
drop table people;
CREATE TABLE people ( id int(11) unsigned NOT NULL auto_increment, name varchar(64) default NULL, PRIMARY KEY (`id`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1;
INSERT INTO people VALUES
(1,'user_a'), (2,'user_å'),
(3,'user_ä');
select * from people;
SET NAMES utf8;
INSERT INTO people VALUES
(4,'user_a'),
(5,'user_å'),
(6,'user_ä');
select * from people;
alter table people engine=MyISAM default character set utf8;
ALTER TABLE people CHANGE name name BLOB;
ALTER TABLE people CHANGE name name varchar(64) CHARACTER SET utf8;
select * from people;
SET NAMES latin1;
select * from people;

Citat:

Originally posted by Magnus_A@Dec 12 2008, 17:47
Det är varje fall min tolkning av vad som händer, jag tar gärna emot förslag på förbättringar :)

Att vi bara orkar! :lol: Detta börjar bli lite utdraget (typiskt att man alltid låter dra sig in i sånt här…)

Okej. Som förtydligande och bevis på att det fungerar gjorde jag lite knappande och kommenterade det hela:

Kod:

CREATE TABLE t (f TEXT CHARSET latin1);

SET NAMES 'latin1';

INSERT INTO t VALUES ("åsa");

SET NAMES 'utf8';

SELECT * FROM t;



-- Ger Ã¥sa visat som utf-8, ger ÃƒÂ¥sa visat som iso-8859-1

-- Den "dubbla" konverteringen sker med SET NAMES och ligger inte i databasen



DROP TABLE t;

CREATE TABLE t (f TEXT CHARSET latin1);

SET NAMES 'latin1';

INSERT INTO t VALUES ("åsa");

ALTER TABLE t MODIFY f BLOB;

ALTER TABLE t MODIFY f TEXT CHARACTER SET utf8;

SET NAMES 'utf8';

SELECT * FROM t;



-- åtger korrekt åsa visat som utf-8, ger Ã¥sa visat som iso-8859-1

-- (dvs är korrekt om filen tolkas som utf-8)



-- Samma sak med fältet som BLOB och konverteringen inte inlagd i databasen, bra för testning innan

DROP TABLE t;

CREATE TABLE t (f TEXT CHARSET latin1);

SET NAMES 'latin1';

INSERT INTO t VALUES ("åsa");

ALTER TABLE t MODIFY f BLOB;

SET NAMES 'utf8';

SELECT CONVERT(f USING utf8) FROM t;



-- Vad vi vill åstadkomma:

DROP TABLE t;

CREATE TABLE t (f TEXT CHARSET latin1);

SET NAMES 'latin1';

INSERT INTO t VALUES ("åsa");

ALTER TABLE t MODIFY f BLOB;

ALTER TABLE t MODIFY f TEXT CHARACTER SET utf8;

-- Tabellen är ändrad som ovan allt borde fungera.



-- Innan vi nu SELECT:ar så sätter NAMES till latin1 för vi vill ha ut data i iso-teckenkodning:

SET NAMES 'latin1';

SELECT * FROM t;

-- Ger Xsa (X ogiltigt unicodetecken) visat som utf-8, ger åsa visat som iso-8859-1

(Notera att de tre-fyra första raderna i exemplen bara raderar testtabellen och sedan återskapar den enligt "stoppa in uft-8 i latin1-fält"-metoden. All input var utf-8.)

Aningen oöversiktiligt men i grunden rätt enkelt:

1. Har man en tabell som egentligen är i utf8 men är deklarerad som latin1 i tabellen (gammalt rävknep för att spara utf8-data i databaser som bara kan hantera iso) så beböver man konvertera fälten enligt följande enkla kommando för varje fält (MySQL tillåter för övrigt att ändra flera kolumner i en tabell med en ALTER-sats):

Kod:

ALTER TABLE exempelfält MODIFY f BLOB;

ALTER TABLE t MODIFY exempelfält TEXT CHARACTER SET utf8;

I fall det handlar om en VARCHAR/ENUM/SET istället för TEXT så anpassas frågan för detta.

2. För att det sedan inte ska bli fel när man hämtar data så är det viktigt att man även sätter överföringsteckenkodningen (vilken är det teckensnitt man deklarerat på t.ex. hemsidan, i normalfallet utf-8) antingen i sin .ini-fil eller med sql:

Kod:

SET NAMES 'utf8'

3. För att lösa Lindahls ursprungliga problem behöver han alltså först göra ovan så att fälten är korrekt deklarerade och sedan bara använda:

Kod:

SET NAMES 'latin1';

följt av select-frågan för att få ut sin feed i iso-8859-1-form.