laaczlv // Visnotaļ smilškaste. Privātīpašums. Te vairs nav, ko rakstīt. | 2025-08-13 18:19 EET here
 
 

laacz tagad klausās:
Radio NABA

 


Kārtot pēc pēdējā pļurkt

Autora domas ne vienmēr sakrīt ar autora domām. © spectator

Ir pagājuši 24 gadi un 7 mēneši un 12 dienas kopš mana mūža laimīgākās dienas

Papildus 3355 maniem pļurkšķiem ir sapļurkstēti 33189 sveši pļurkšķi.

ICQ: #58279153 (very rarely)
MSN:
E-mail:

Mazās pustizlās ikoniņas aiz linkiem (ne visiem) arī šo to nozīmē.
 

skābs ābols
roze.lv
~smejmoon
~aptieka (testing)
cietnis/blog
 
   
<br />
<br />
<br />
2004 23. novembris otrdiena
14:24

Ir giga problēma :) Tika uzlikts MySQL 4.1, pirms tam kātīgi izlemjot, ka vecās tabulas ar jaunajām netiks džoinotas. Bet tagad izrādās, ka tas ir nepieciešams. Un rodas dziļš dibuā tipa caurums.



Ir divas tabulas:



CREATE TABLE `a` {
`id` int(11) auto_increment primary key,
`a` varchar(254)
} DEFAULT CHARACTER SET=latin1

CREATE TABLE `b` {
`id` int(11) auto_increment primary key,
`a_id` int(11), –– Relācija uz tabulas `a` ierakstu
`b` varchar(254)
} DEFAULT CHARACTER SET=utf8


Pie kam, tabulā a lauks a, neskatoties uz to, ka tam ir norādīts čaraktersets latin1 satur tekstu iekš cp1257. Tā ir vecā tabula.



Tabulā b viss ir bumbās - saturs tieši, kā norādīts, ir utf8.



Un tagad man nekādi neizdodas izveikt sekojošu operāciju:



SELECT
`a`, `b`
FROM
`a`, `b`
WHERE
`a.id` = `b.a_id`


Nēnu, selekts izdodas, protams. Man pilnībā pietiktu, ja viss smuki rādītos utf8 kodējumā. Taču, tā kā viens lauks ir utf8, bet otrs MySQL'prāt ir latin1, tad nu nekādi neizdodas korekti iestāstīt MySQL'am, ka tas nebūt nav latin1, bet gan cp1257.



Itin vai īzī risinājums - varētu nomainīt tabulas character set. Bet nevar. Jo veco tabulu izmanto vecās aplikācijas. Attiecīgi, mainot čaraktersetu, jamās palidos pa pieskari. Viena pēc otras. Pie kam, alter'ējot tabulu MySQL's daiļi sajās saturu :)



Ko darīt? Duplicēt tabulu ar korektu čārsetu - tas nav risinājums.

 
Atoms (#25062)   14:39 @ 2004. gada 23. novembris, otrdiena
new a tev parastaa mysql vai mysqli ekstensija ?

ja mysqli tad tur vareeja smuki noraadiit kaadaa charsetaa veelaties datu charsetu outputaa... ja es pareizi saprotu ko vaiga....
 
laacz (#25063)   14:42 @ 2004. gada 23. novembris, otrdiena
new Atoms: arī ar mysql parasto ekstensiju to var izdarīt. Bet nejau tur ir problēma :) Problēma ir iekš tā, ka es nezinu, kā piespiest MySQL saprast, ka tas, kas viņaprāt ir latin1, patiesībā ir cp1257 :)
 
bubu (#25066)   15:09 @ 2004. gada 23. novembris, otrdiena
new Tiešām šis nelīdz: ALTER TABLE a MODIFY a varchar(254) cHARACTER SET utf8;

Un šis:
SELECT CONVERT(`a` USING cp1257), `b`
FROM `a`, `b`
WHERE `a.id` = `b.a_id`
 
laacz (#25068)   15:16 @ 2004. gada 23. novembris, otrdiena
new bubu: 1. nelīdz, jo rada problēmas jau minētajās pārējās aplikācijās, kurās VISUR jālabo būs selekti :)
2. arī, jo no MySQL uzskata, ka `a` ir iekš `latin1` un attiecīgi arī konvertē no `latin` uz `cp1257`.
 
Shiazo (#25069)   15:19 @ 2004. gada 23. novembris, otrdiena
new paurbinaaju degunu. laacz, programmatuuras arhitektuuras izstraades posms ir pirms realizeeshanas & implementeeshanas posma (resp. kodeeshanas) :D
da neko - gribeeju pavazat aiz deguna.
 
laacz (#25070)   15:21 @ 2004. gada 23. novembris, otrdiena
new Shiazo: Pateikt godīgi? Es par šiem posmiem dzirdējis esmu. Un pieturos pie jamajiem dikti minimāli. Tā nu tas ir. :)
 
Neonz (#25072)   15:34 @ 2004. gada 23. novembris, otrdiena
new A vaig tieši lai mysql ņemas ar tiem encodingiem? Nevar izmantot PHP iconv() pēc selekta?
 
laacz (#25073)   15:37 @ 2004. gada 23. novembris, otrdiena
new Neonz, padomā, kas ir ātrāk? :) Native MySQL iebūvētās konversijas, vai iconv(). Plus, kā tad man būs operēt ar laukiem, meklēt tajos, u.t.t.?
 
anonīmi (#25076)   16:00 @ 2004. gada 23. novembris, otrdiena
new Palīdzēt nemācēšu. Bet man ir jautājums. Vai tev php_mysqli extensions māk ņemties ar tabulām, kur ir UTF-8? Viņš man atgriež ķeburus. tāpēc joprojām esmu spiests lietot latin-8 un glabāt UTF-8!
 
Arturs (#25080)   16:17 @ 2004. gada 23. novembris, otrdiena
new Ar MySQL nestrādāju, bet tas netraucē man piedāvāt risinājumus :). Uztaisam, tajā **a** tabulā vēl vienu kolonu - //a2//. Pēc tam uzlaižam pa virsu kaut vai PHP skriptu, kas sadzen vērtības no lauka //a// laukāa //a2// nomainot encodingu. Pēc tam taisam selectus atsaucoties uz tabulas **a** lauku //a2//
 
Mr.Venom (#25081)   16:33 @ 2004. gada 23. novembris, otrdiena
new vāja cerība uz pārkonvertēšanu "lidojumā":
WHERE `a.id` = _utf8`b.a_id`
 
Mr.Venom (#25082)   16:34 @ 2004. gada 23. novembris, otrdiena
new vāja cerība uz pārkonvertēšanu "lidojumā":
WHERE _utf8`a.id` = `b.a_id`
 
Djuke (#25083)   16:51 @ 2004. gada 23. novembris, otrdiena
new moš var kaukādā veidā izveidot "pareizu" tabulu ('aa') "pareizajā" kodējumā, pārdzīt uz to no tabulas 'a' datus un tad uztaisīt skatu 'a' kas pēc būtības ir identisks tabulai 'a', bet veidojas no 'aa', kuras nu tad jau vairs nebūs....

par mysql gan neko nezinu... līdz ar to varbūt smagi kļūdos
 
ZeaLot (#25085)   17:03 @ 2004. gada 23. novembris, otrdiena
new A nevar to b.a_id konvertēt uz latin1/cp1257 un tādējādi salīdzināt...?
 
RuncZ (#25092)   19:39 @ 2004. gada 23. novembris, otrdiena
new nu un kā ar konekcijas čarseta un collation izvēli ??

tjipa laikam bij sekojoši:
set names 'your_favourite_encoding_here';
set character set 'your_favourite_encoding_here';

nu protams tur jāzin, kā mysql atpazīst kodējumus ar domu, ka utf-8 ir 'utf8', windows-1257 ir cp1257.. nu karoč konvertē uz nebēdu

tad pēc idejas pat konsolē viss izvadās kā prasīts.. at least man uz 4.1.3 tā iet

P.S. šitais online translita konvertors nerullē, jo līdzko teksts ir vairāk, kā ielien šinī textarea laukā un parādās scrolleris, tā jams spītīgi uz katras pogas piespiedienu stāv uzrullēts maksimāli uz augšu.. un rezultātā jāraksta ir pa tumšo :/ (Firefox/1.0 & w2k+SP4, ja tas kauko ietekmē)
 
RuncZ (#25093)   19:44 @ 2004. gada 23. novembris, otrdiena
new ar domu izvēlēties tajas vecajās aplikācijās to collation un charsetu un tomēr nokonvertēt tās tabulas .. (sorre par doublepostu, pauris liecas)
 
Roze (#25095)   22:03 @ 2004. gada 23. novembris, otrdiena
new **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.
 
juris (#25096)   22:07 @ 2004. gada 23. novembris, otrdiena
new kāpēc jauno tabulu nevarēji taisiit vienā kodējumā ar veco un izmatot latin1 un glabāt tur savus cp1257 datus? Es saprotu ka utf-8 skaitas stilīgi, taču esošā sistēma jācenšas strādāt vecās sistēmas stilā nevis dzejot uber konvertāciju.

Tašu reāli tavam risinājumam 15 koments varētu noderet un translita konvertētājs ir īpaši neērts
 
Roze (#25097)   22:33 @ 2004. gada 23. novembris, otrdiena
new Aiz kam mysql pēc dokumentācijas piedāvā arī šādu variantu (itkā ar ne nelatin čaracteri līdz ar to '?' nevaidzētu būt)
SELECT CONVERT(_latin1'Müller' USING utf8);

Tākā moš vari rakstīt..
.. WHERE CONVERT(_latin1`a.id` USING utf8) = `b.a_id`
 
karlis (#25098)   10:34 @ 2004. gada 24. novembris, trešdiena
new bija līdzīga problēma:
vecā tabula (utf-8) vairs negribēja ielikt īsto charsetu. Kā saprotu problēma bija iekš tā apstākļa, ka mysql pieņēma, ka ienākošie dati ir tipa latin un ņēmās šos konvertēt uz utf-8, līdz ar ko galarezultātā sanāca kaut kādas kakas, jo konvertēt neko vairs nevajadzēja.

atrisināju sākumā izveidojot tabulu struktūru bez datiem un visiem laukiem, kuri saturēja tekstus norādot kodejumu binary. pēc tam savukārt tikai importēju datus (bez create table).
 
jozhix (#25107)   06:13 @ 2004. gada 25. novembris, ceturtdiena
new karlis, tikai laacz gadijumaa buutu jaataisa vjuuvs(i)
 
Didulis (#25135)   18:32 @ 2004. gada 25. novembris, ceturtdiena
new Pirmkārt jau laacz nav problēmu ar selektēšanu, ko te lielākā daļa cenšas izskaidrot.
Otrkārt pie pašas problēmas. Vai neder exports uz XML? Exportējam visus datus uz XML, manuāli nomainam kodējumu un iebarojam datus jaunā tabulā ar pareizu kodējumu. It kā stabilāks variants par vienkāršu Alter table.
 
Kā tu saucies:  
Īmeils:  

Mazliet komentāru kultūras, jeb laacziquette

  • Ja tu gribi pateikt tikai ':)', tad saki to sev un pie spoguļa. Pašam prieks un es esmu mierīgs.
  • Neaizraujies ar enteriem savā komentārā. Pavisam nav obligāti likt divus vai trīs enterus pēc katras uzrakstātās rindiņas.
  • Offtopiks (komentāri ne pa tēmu) nav no gaidītākajām lietām.
  • Galu galā, ja tev ir verbāla caureja, ej uz delfiem vai arī taisi pats savu lapu.
  • Pirms spiest pogu, padomā. Varbūt tu vēl neesi visu pateicis? Lai nebūtu pēc tam vēl 26 pēc kārtas esošu komentāru jāraksta.
  • Vēlies runāt ar kādu cilvēku, uzraksti viņam vēstuli. Ir daži izņēmumi. Agressor, tu neesi izņēmums.
  • Un, galu galā, paturu tiesības jebkuru sev neimponējošu komentāru izmēzt.
     
  • Par izņēmumu kādā no šiem punktiem, vai arī visos noteikumos var kļūt, uzrakstot iesniegumu un iedodot man to rokā. Iesnieguma vēlamais apjoms - 0.7 laba viskija.
     
  • Gan jau kaut ko vēl izdomāšu.
 
 
© 1996 - 2025 laacz | Visas tiesības, nu jūs jau zināt..
Spēcināts ar SPP v1.0 public beta