aika
-
Posts
296 -
Joined
-
Last visited
Posts posted by aika
-
-
$result_from = mysql_query("SELECT * FROM $table",$link_from);
while ($row = mysql_fetch_array($result_from)) {
while (list($k,$val) = each($row)) {
print "$val\n";
}
}
rezultātā tiek atgriezts mistisks cipars un katra tabulas kolonnas vertība 2vas reizes
kapēc? Kas ir nepareizi?
-
Sveicināti.
Ir izveidots logo ar paredzētām input text formām- userneimam un parolei. Bet jautājums, kā lai norāda iekš php input atrašanās vietu uz bildes, un kā pareizi to rakstīt.
Cerams, ka izteicos skaidri, šajā vēlajā vakara stundā.
Pievienoju nelielu skicīti
to dara cssā ar div tagiem vai tabulu (bilde bekgroundā, input fieldi caurspīdīgi)
pagūglē!
-
Es tak arī rakstīju 'cp1257' ;)
Nu, ja tev tie dati būtu utf8, tad problēmām nevajadzētu būt. Bez tam, pieredze rāda, ka iekš latin1 tauta parasti liek iekšā 1257 ;)
Tad kādā kodējumā lapiņa ir? vecā, domāju.
kā var uzzināt kodējumu? Visa lapa (php kods) ir UTF8. UTFs ir salikts visur kur vien varu salikt! Vēl lieta kuru nesaprotu - mainot tabulas lauka izkārtojumus nekas nemainās!!!
Sākotnēji tabulās kā izkārtojums visur figurēja latin1. Taču dati, php faili - viss ir UTF. Tur aukstāk taču ir dampa headeris!
-
un visvairāk mani besī šis: ja caur php iebaroju mēneši - tad php atgriež mēneši, bet Mysql tabulā stāv: mД“neЕЎi
BTW ir jautājums - kā var tikt klāt šim te Д“ . Godīgi sakot vispār nav skaidrs transports kā dati tiek nodoti no tabulas php parserim. Kurā brīdī notiek kodēšanās. Kas utf divus simbolus pārtaisa par vienu un otrādāk?
-
ja pareizi saprotu, tad tev tie dati bija iekš windows-1257 kodējuma? ja tā, tad dumpam kā pirmo rindiņu ieliec 'SET NAMES cp1257'.
!!! /*!40101 SET NAMES windows-1257 */ :)
MySQL teica:
#1115 - Unknown character set: 'windows'
:) pareizi ir cp1257
BET kapēc tu domā ka datiem ir windows-1257, ja šāds kodējums setingos vispar nekur neparādās!?
jebkurā gadījumā izmegināju arī šo gan vienā galā, gan otrā :(
PS.
dampa galvā stāv:
-- MySQL dump 10.11
--
-- Host: localhost Database: apache
-- ------------------------------------------------------
-- Server version 5.0.45-community-nt
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;
-
Vienīgias risinājums ko patlaban redzu ir vienam galam uzlikt remote access un uzģenerēt kodu kas selektē no vecās un inserto jaunajā visu pēc kārtas! :(
-
a ja tu dumpo uz utf8 ?
mysql ir uz win vai *nix ?
bet kas tev liedz pie hostera savai db likt citu kodeejumu ?
vai tu gribi paariet uz utf8?
viņs jau defaultā dampo uz utf.
vecais ir uz win, jaunais visdrīzākais uz nixa
neredzu iespēju mainīt pie hostera kodējumu, turklāt uz vecā MySQL ir tieši tāds pats kodējums
___________
pamanīju ka vecajām tabulām izkārtojums bija latin1. Pie tabulu operācijām uzliku ka utf8. Nekas nemainījās ne vecajā galā, ne exportējuot uz jauno.
Vnk turpinu hu..etj.
-
nu nee,
tev pie mysqldump ir iespeeja tikt uz bck servera?
kad importee ieksh mysql tev ir taada opcija: Character set of the file:
nu jā - es vaaru taisīt dampu! To jau arī darīju, norādot ka kodējums ir latin lai damps netaisītu konvertāciju! Tāpat tūtē :(
-
tabulaam tev vajag noraadiit latin1_general_ci un importeejot failu ar phpmyadmin noraadi faila kodeejumu.
2 variants: vecajaa db uztaisiit BACKUP un meeginaat tur paarkonverteet no latin uz utf8 un tad eksporteet
tabulām kodējums nāk līdzi exp. failā! Un tas neko nedod. Importējot arī neviens no kode'juma variantiem nepalīdz.
Šo te es experimentēju pēc viena gūgles ieteikuma: tjipa ka būtība ir sekojoša: UFT texts exp./ bekapa brīdī tiek konvertēts vēlreiz par UTF, jo tabula it latin kodā. UN šis dubultais kodējums taisnā ceļā dodad importā. Mēģināju bekapu exportēt ar kode'juma norādi latin1. tad bekapā vnk. pārsaukt latin1 par UTF, kā bija ieteikts. Nope - nepalīdz!
-
Ir pienācis man laiks migrēt uz reālu hosteri un esmu konkrēti ieberzies ar kodējumiem.
Lieki teikt ka vecajā vietā viss ok.
Noeksportēju savus datus, pārnesu uz hosteri un sākās ?? visur kur mīkstiešņācošie nāk no SQL .
Hosterim MySQL charset: UTF-8 Unicode (utf8)
PHP codings - UTF8
Vecajā db eksportā figurē: ENGINE=MyISAM DEFAULT CHARSET=latin1 COLLATE=latin1_general_ci;
un texts izskatās šādi: mÄ“neÅ¡i
php agriež m?�ne??i
Mēģināju tupa exp. failā pārsaukt latin1 par UFT8
tas nenostrādāja
ja exp. failā mainu mÄ“neÅ¡i uz mēneši - tad phpMyadmin tabulā redzu mēneši, bet PHP atgriež m?ne?i
ja caur php iebaroju mēneši - tad php atgriež mēneši, bet Mysql tabulā stāv: mД“neЕЎi
es vnk hu..eju
Ja ir kādam ideja kā apčakarēt kodējumus - lūdz izsakieties.
Mainīt MySQL charset es acīmredzot nevaru, bet laipni uzklausīšu kā pareizi uzsetapot charus MySQLam un tabulām!
Vēl dati:
phpMyadmins taisot sql updeitu vienmēr raksta: WHERE CONVERT USING utf8
tabulās avisur collation stāv: utf8_general_ci
-
Varbūt vienkārši "pareizas" vērtības padevi. Tb tādas uz kurām paveicās un viss nostrādāja.
arī tas tiesa! vakar jau pētīju - un tad jau skatījos ka tas nostrādāja tieši pie 2.55 < 2.45+0.1 :)
-
Lūdzu nevajag taisīt bezjēdzīgas QUOTEs
vo bļins fakstakāds! Moš tad man tieši tos par stringiem pārtaisīt!
enīvei tas neizskaidro kapēc tas viss nostrādāja 3 mēnešus :)
bet paldies par virzienu! nu domāsim kā apčakarēt!
-
Parādi taču kodu, kas tā dara.
Un tu 100% pārliecinājies (izdrukājot mainīgo saturu pirms pašas salīdzināšanas), ka mainīgie ir vienādi ?
Hmm.. Cik noprotu, tu floatus mēģini salīdzināt ? Varbūt tālakais ko rakstīšu būs pilnīgas muļķības, bet ar floatiem ir tā, ka tie nav precīzi. Tāpēc iespējams, ka izdrukājot viņi ir vienādi, bet salīdzināšanas operātors tomēr vienu no viņiem redz savādāk (neprecīzi, piemēram, 3 vietā 3.00000000000000003 vai ko tādu).
varbūtība itkā varētu pastāvēt, taču šoreiz tā nevare'tu būt:
$a tiek ievadīts inputfieldā un izskatās piem šādi 2.55
$b tiek iegūts no funkcijas kas pie vienas doubles pieskaita otru (piem $b = 2.45 + 0.1);
pats stulbākais ka tas kods nostrādāja 3 mēnešus, bet vakar sadirsās! (nav bijis pat PC restarts, vai tur tjip reg set maiņa)
-
Ieraksti kodu, kurā tas notiek. Ieskaitot tās vietas, kurās mainīgie dabū vērtības.
nu kāds tur kods!
ir mainīgais $a un mainīgais $b
$a tiek iegūts kā paramters, kas nodots no citas lapas
$b tiek iegūts no funkcijas
abi parametri tika apstrādāti:
$a = doubleval($a);
$b = doubleval($b);
salīdzināšana:
if ($a<$b) {}
-
Parādi taču kodu, kas tā dara.
Un tu 100% pārliecinājies (izdrukājot mainīgo saturu pirms pašas salīdzināšanas), ka mainīgie ir vienādi ?
jap! pat izķēru abus maniīgos ar javascriptu tieši pirms salīdzināšanas!
-
Ar parastiem polliem nav problēma! Man vēl līdz šim nav izdevies atrast pollu kurā būtu arī checkbox iespēja ! :(
-
Pēkšni mans kods sācis taisīt mistiku: salīdzinot divus variabļus melo! (pirms tam viss bija ok)
Salīdzināts tiek ar '<'
Ja abi mainīgie vienādi - nostrādā kā true!
Uzliku ka abi mainīgie pirmstam tiek apstrādāti ar doublval(); - nepalīdz!
Kas par lietu???!
-
Neesmu savā mūža nevienu rindu iekš flash uzrakstījis. So what !?
http://www.adobe.com/support/flash/action_...tionary162.html
TXS! :)
-
Nu tad neliec flasham lasīt http://kaut.kas/bļa.xml , bet gan http://kaut.kas/bļa.xml?13461461346 kur skaitlis ir 'unix time'.
:( zināšanas swf jomā man vēl švakākas! turklāt tas griežas zem win. ok - paskatīšos moš kautkāda rnd funkcija flašam būs ...
txxs
-
Problēma sekojoša - ir swf fails, kas ielasa xml failu. Mainot xml faila saturu, swf spītīgi neuztver jauninājumus! KO DARĪT? :)
darbs ar array
in PHP 5
Posted
pareizi! viss tagad štokos - txs!