Ferns
#0
I forbindelse med at det hostingfirma jeg benytter mig flytter til nye platforme, er mine nuværende hoteller opsagt pr. 31/8-13 og mine domæner skal derfor flyttes over på den nye platform/i deres nye hotel.
Det første domæne jeg flyttede er der ingen problemer med. Her tog jeg backup af databasen og en komplet backup af mappe- og filstrukturen, hvorefter jeg:
- Uploadede filerne til den nye FTP
- Ændrede attributter på de respektive mapper og filer.
- Uploadede SQL'en og oprettede en ny bruger til den
- Tilpassede config.php til de nye oplysninger
- Tjekkede at mit site var aktivt og fungerende.
Det hele virker - Intet problem.
Mit andet site, derimod, vises ikke korrekt ved samme fremgangsmåde:
Bogstavet Æ vises som - æ
Bogstavet Ø vises som - ø
Bogstavet Švises som - Ã¥
Dette gælder hele sitet - Men kun de importerede ting. Benytter jeg æ, ø eller å i nye indlæg, eller ændrer de gamle, vises bogstaverne korrekt.
Da jeg stadig har adgang til SQL'en, via phpadmin, på den udfasende platform, har jeg prøvet følgende:
- Tjekket at alle tabeller har det rette tegnsæt (utf8_danish_ci) Det har de.
- Eksporteret SQL'en som både UTF8 og ISO-8859-1, for derefter at uploade den til den nye platform. Ingen af dem vises korrekt.
- Åbnet den nedhentede database på min desktop med notepad++ hvor jeg har konstateret at æøå vises ukorrekt. For derefter at bruge "søg og erstat"-funktionen, så det så korrekt ud. Gemt og uploadet SQL-filen til den nye platform, men derved erfaret at filen så fylder 0kb og hjemmesiden naturligvis derfor ikke virker.
- Prøvet at sætte browserkodning til både Unicode og Vestlig, begge uden succes.
Jeg er ingen haj til SQL og er godt nok på bar bund ifht. hvad jeg skal gøre og håber derfor at der er en herinde på HWT der kan pege mig i den rigtige retning.
Det første domæne jeg flyttede er der ingen problemer med. Her tog jeg backup af databasen og en komplet backup af mappe- og filstrukturen, hvorefter jeg:
- Uploadede filerne til den nye FTP
- Ændrede attributter på de respektive mapper og filer.
- Uploadede SQL'en og oprettede en ny bruger til den
- Tilpassede config.php til de nye oplysninger
- Tjekkede at mit site var aktivt og fungerende.
Det hele virker - Intet problem.
Mit andet site, derimod, vises ikke korrekt ved samme fremgangsmåde:
Bogstavet Æ vises som - æ
Bogstavet Ø vises som - ø
Bogstavet Švises som - Ã¥
Dette gælder hele sitet - Men kun de importerede ting. Benytter jeg æ, ø eller å i nye indlæg, eller ændrer de gamle, vises bogstaverne korrekt.
Da jeg stadig har adgang til SQL'en, via phpadmin, på den udfasende platform, har jeg prøvet følgende:
- Tjekket at alle tabeller har det rette tegnsæt (utf8_danish_ci) Det har de.
- Eksporteret SQL'en som både UTF8 og ISO-8859-1, for derefter at uploade den til den nye platform. Ingen af dem vises korrekt.
- Åbnet den nedhentede database på min desktop med notepad++ hvor jeg har konstateret at æøå vises ukorrekt. For derefter at bruge "søg og erstat"-funktionen, så det så korrekt ud. Gemt og uploadet SQL-filen til den nye platform, men derved erfaret at filen så fylder 0kb og hjemmesiden naturligvis derfor ikke virker.
- Prøvet at sætte browserkodning til både Unicode og Vestlig, begge uden succes.
Jeg er ingen haj til SQL og er godt nok på bar bund ifht. hvad jeg skal gøre og håber derfor at der er en herinde på HWT der kan pege mig i den rigtige retning.
Jeg ved ikke præcis, hvad der er galt. Men kan du ikke løse det ved at lave et lille script med UPDATE statements; altså search-replace direkte i DBen med SQL?
Jeg ved godt, at det ikke er den forkromede løsning, men når det kun skal gøres én gang er der jo grænser for, hvor meget tid, der giver mening, at bruge på det.
Jeg ved godt, at det ikke er den forkromede løsning, men når det kun skal gøres én gang er der jo grænser for, hvor meget tid, der giver mening, at bruge på det.
#2
#1 Tak for svar. Det er tilsyneladende systemet der har skrevet et forkert charset ind i databasen.
Jeg har prøvet at google "repair charset sql"
Men kan, desværre, kun finde linuxkommando-løsninger og jeg har kun phpmyadmin til rådighed.
At lave en "søg-erstat" ville også være mit foretrukne valg, da det jo som du netop skriver kun er én gang det skal gøres. Den løsning har jeg også prøvet via notepad++ - Men af, for mig, uforklarelige grunde sker der det at når jeg uploader databasen igen, så fylder den 0kb og er derfor ubrugelig.
Fra #0 " - Åbnet den nedhentede database på min desktop med notepad++ hvor jeg har konstateret at æøå vises ukorrekt. For derefter at bruge "søg og erstat"-funktionen, så det så korrekt ud. Gemt og uploadet SQL-filen til den nye platform, men derved erfaret at filen så fylder 0kb og hjemmesiden naturligvis derfor ikke virker. "
Dette kan sagtens skylde min uerfarenhed med sql, så hvis du kan/har tid og lyst, vil du så lave en trin-for-trin for dummies?
Jeg har prøvet at google "repair charset sql"
Men kan, desværre, kun finde linuxkommando-løsninger og jeg har kun phpmyadmin til rådighed.
At lave en "søg-erstat" ville også være mit foretrukne valg, da det jo som du netop skriver kun er én gang det skal gøres. Den løsning har jeg også prøvet via notepad++ - Men af, for mig, uforklarelige grunde sker der det at når jeg uploader databasen igen, så fylder den 0kb og er derfor ubrugelig.
Fra #0 " - Åbnet den nedhentede database på min desktop med notepad++ hvor jeg har konstateret at æøå vises ukorrekt. For derefter at bruge "søg og erstat"-funktionen, så det så korrekt ud. Gemt og uploadet SQL-filen til den nye platform, men derved erfaret at filen så fylder 0kb og hjemmesiden naturligvis derfor ikke virker. "
Dette kan sagtens skylde min uerfarenhed med sql, så hvis du kan/har tid og lyst, vil du så lave en trin-for-trin for dummies?
#2 - Med søg-og-erstat mente jeg i SQL (som jeg også skrev 😛 ). Det er længe siden, jeg har leget i rå SQL, men jeg tænkte noget i retningen af:
UPDATE db_name.table_name
SET column_name = REPLACE(column_name,'æ','æ')
WHERE value LIKE '%æ%'
Du skal så naturligvis iterere gennem alle de berørte tabeller og kolonner (samt æ,ø,å). Syntaks kan være forskellig alt efter, hvilken SQL server, der er tale om; men idéen er den samme.
Svaret blev redigeret 1 gang, sidst af The_Dare_Devil d. 27-08-2013 15:22:16.
UPDATE db_name.table_name
SET column_name = REPLACE(column_name,'æ','æ')
WHERE value LIKE '%æ%'
Du skal så naturligvis iterere gennem alle de berørte tabeller og kolonner (samt æ,ø,å). Syntaks kan være forskellig alt efter, hvilken SQL server, der er tale om; men idéen er den samme.
Svaret blev redigeret 1 gang, sidst af The_Dare_Devil d. 27-08-2013 15:22:16.
#4
Jeg kan godt tyde hvad din kode gør og idéen er helt perfelt. Men, puha, det er jo samtlige tabeller og kolonner der er blevet berørt. Så vil det ikke tage meget lang tid? Eller er det blot én forespørgsel på hele db'en der skal laves?
#5
høkermetode..
eksporter hele databasen til CSV - søg og erstat i notepad++
slet tabellerne
importer hele skidtet igen..
eksporter hele databasen til CSV - søg og erstat i notepad++
slet tabellerne
importer hele skidtet igen..
#6
Det var også det jeg gjorde @ngler, men det virkede af en eller anden grund ikke at uploade db'en via cPanelet og det var ved at gøre mig godt tyndhudet.
MEN, men, men! Der kom en redningsmand "forbi" med løsningen.
- Eksporter db'en
- Slet db'en
- Søg og erstat i notepad++
- OG, her kom forskellen fra det jeg gjorde. Istedet for at bruge cPanelet til at uploade med, brugte han phpMyadmin's import-funktion. Det virkede dælme.
- Tilføj dbbruger og ret config.php
Simple as that 🙂 Men for dælen hvor kan det være svært at få øje på træerne, selvom man er faret vild i skoven.
MEN, men, men! Der kom en redningsmand "forbi" med løsningen.
- Eksporter db'en
- Slet db'en
- Søg og erstat i notepad++
- OG, her kom forskellen fra det jeg gjorde. Istedet for at bruge cPanelet til at uploade med, brugte han phpMyadmin's import-funktion. Det virkede dælme.
- Tilføj dbbruger og ret config.php
Simple as that 🙂 Men for dælen hvor kan det være svært at få øje på træerne, selvom man er faret vild i skoven.
#7
jeg bruger altid phpmyadmin, havde ikke lige tænkt at du brugte cpanel.. ;)
#8
Det er jo også totalt åndssvagt, for jeg bruger jo phpmyadmin til at eksportere med. Så hvorfor jeg havde fået ind i mit hovede at bruge cPanel til import - Det ved jeg virkelig ikke.
Hvorfor det så ikke virker med cPanel, det vil jeg ikke bekymre mig, da det ikke er noget jeg skal arbejde med dagligt. Men fremover vil jeg altid huske at bruge phpMyadmin til både eksport og import 🙂
Hvorfor det så ikke virker med cPanel, det vil jeg ikke bekymre mig, da det ikke er noget jeg skal arbejde med dagligt. Men fremover vil jeg altid huske at bruge phpMyadmin til både eksport og import 🙂