Re: [FUG-BR] OT: Re: RES: C/C++
Paulo Pires escreveu:
On 2/25/07, gethostbyname [EMAIL PROTECTED] wrote:
Apenas que a composição do texto na norma, tanto na construção da
frase como na apresentação visual, torna difícil a interpretação do
que quer dizer.
Compreendi. Foi um erro meu ter misturado o negrito no meio do código,
além de ter duplicado a mensagem.
Não falo nem do negrito. O próprio PDF da norma é confuso.
Ah, sim.
Até concordo com você, mas é porque nós estamos acostumados com
máquinas e sistemas que trabalham com números. Não precisaria ser o
caso. Eu não se um CP/M da vida tinha alguma coisa como exit status
de um programa, nem tenho muita dificuldade em imaginar um sistema em
que um processo retornasse, ao invés de um mero valor, algo que
pudesse ser interpretado como um comando/ação ou um objeto mais
complexo.
Esse objeto mais complexo ou comando poderia ser enviado ao OS por
outros modos, não? Chamar system, por exemplo. Seria mais prático e
simples, não? Imagine a main retornando algo que não seja o número, que
complicação isso geraria.
system() não devolve algo ao SO, mas requisita algo dele (se pensarmos
no UNIX, system(3) é uma composição de fork(2), execve(2) e
waitpid(2)/wait4(2)).
Eu pensei nisso porque você disse algo que pudesse ser interpretado
como um comando/ação.
Deixe-me dar um exemplo do que eu quis falar. Digamos que você fez um
programa chamado -- digamos -- beethoven, que utiliza alguma técnica
que você vai patentear para gerar uma sinfonia completa a partir de
uma seqüência incial de bits. Se esse programa existisse hoje num
sistema operacional corrente, o resultado ou seria gravado em arquivo
ou seria enviado a um outro processo através de um pipe ou socket,
como parte da própria execução do programa, e, somente após essa etapa
final de manualmente depositar a sinfonia em algum canto, o programa
devolveria 0 se fosse bem sucedido ou outro valor se falhasse. Se, ao
invés disso, você tivesse um SO que permitisse devolver um objeto
sinfonia ao término do programa, você não precisaria se preocupar com
manualmente gravar ou serializar sua sinfonia. Esse peso ficaria
com o sistema.
Claro que um SO assim teria que saber o que fazer com o objeto que
você lhe envia. Certamente seria um sistema mais complexo, mas não
sei se já não caminhamos para uma coisa assim, ainda mais nesses dias
de rede para todo mundo e processamento cada vez mais distribuído.
MIME types são uma abordagem já em uso para identificação de objetos
arbitrários, assim como são as extensões de arquivo ou as assinaturas
de arquivos executáveis (incluindo aquela linha começando com #! no
topo dos nossos scripts em shell, PERL, AWK etc.).
Compare as duas versões do programa acima mencionado (em C++).
// beethoven.cc -- SO de hoje
// stdout deve ser redirecionado para
// arquivo ou pipe.
#include iostream
#include beethoven.h
int main(int argc, char **argv){
try {
symphony S(argc, argv);
std::cout S;
}
catch(...){
return 1;
}
return 0;
}
// beethoven.cc -- SO viajante
#include beethoven.h
symphony main(argc, argv){
return symphony(argc, argv);
}
Você gostaria de mais ou menos um SO orientado a objetos que não
seguisse padrões rigorosos? Algo dinâmico como a API de JAVA, diferente
de C++?
gethostbyname
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] RES: FreeBSD6.2STABLE + MPD (VPN)
Cara, nem perde muito tempo com o MPD, vai no poptop que é melhor.. JD -Mensagem original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Em nome de Jeandre Uchoa Enviada em: domingo, 25 de fevereiro de 2007 02:23 Para: freebsd@fug.com.br Assunto: [FUG-BR] FreeBSD6.2STABLE + MPD (VPN) Caros, Estou com dificuldades no MPD, a configuração está abaixo e logs da conexão também. Estou usando o XP SP2 e recebo uma mensagem de que não foi possivel verificar a identidade no servidor. Alguém sabe como ajudar? [EMAIL PROTECTED]:/usr/local/etc/mpd4] # cat mpd.conf startup: # enable TCP-Wrapper (hosts_access(5)) to block unfriendly clients set global enable tcp-wrapper # configure the console set console port 5005 set console ip 0.0.0.0 set console user jeandre uchoa set console open default: load pptp0 load pptp1 pptp0: new -i ng0 pptp0 pptp0 set ipcp ranges 192.168.3.1/32 192.168.3.0/24 load client_standard pptp1: new -i ng1 pptp1 pptp1 set ipcp ranges 192.168.2.1/32 192.168.2.0/24 load client_standard client_standard: set iface disable on-demand set iface enable proxy-arp set iface idle 0 set iface enable tcpmssfix set bundle disable multilink set bundle enable compression set link yes acfcomp protocomp set link no pap chap set link enable chap set link mtu 1460 set link keep-alive 10 60 set ipcp yes vjcomp set ipcp dns 192.168.0.2 set ipcp nbns 192.168.0.2 set ccp yes mppc set ccp disable mpp-compress set ccp yes mpp-e56 set ccp yes mpp-e128 set ccp yes mpp-stateless set bundle enable crypt-reqd [EMAIL PROTECTED]:/usr/local/etc/mpd4] # cat mpd.links pptp0: set link type pptp set pptp self 192.168.0.2 set pptp enable incoming set pptp disable originate pptp1: set link type pptp set pptp self 192.168.0.2 set pptp enable incoming set pptp disable originate [EMAIL PROTECTED]:/usr/local/etc/mpd4] # cat mpd.secret usuariosenha 192.168.3.1 jeandresenha 192.168.2.1 [EMAIL PROTECTED]:/usr/local/etc/mpd4] # mpd4 -k Multi-link PPP for FreeBSD, by Archie L. Cobbs. Based on iij-ppp, by Toshiharu OHNO. mpd: pid 15533, version 4.0b5 ([EMAIL PROTECTED] 22:18 22-Fev-2007) CONSOLE: listening on 0.0.0.0 5005 [pptp0] ppp node is mpd15533-pptp0 tcpmss node is mpd15533-mss [pptp0] using interface ng0 [pptp1] ppp node is mpd15533-pptp1 [pptp1] using interface ng1 mpd: PPTP connection from 192.254.254.251 3467 pptp0: attached to connection with 192.254.254.251 3467 [pptp0] opening link pptp0... [pptp0] link: OPEN event [pptp0] LCP: Open event [pptp0] LCP: state change Initial -- Starting [pptp0] LCP: LayerStart [pptp0] attaching to peer's outgoing call [pptp0] link: UP event [pptp0] link: origination is remote [pptp0] LCP: Up event [pptp0] LCP: state change Starting -- Req-Sent [pptp0] LCP: SendConfigReq #1 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM 438ed756 AUTHPROTO CHAP MSOFTv2 pptp0-0: ignoring SetLinkInfo [pptp0] LCP: rec'd Configure Request #0 link 0 (Req-Sent) MRU 1400 MAGICNUM 638e6b48 PROTOCOMP ACFCOMP CALLBACK Not supported [pptp0] LCP: SendConfigRej #0 CALLBACK [pptp0] LCP: rec'd Configure Request #1 link 0 (Req-Sent) MRU 1400 MAGICNUM 638e6b48 PROTOCOMP ACFCOMP [pptp0] LCP: SendConfigAck #1 MRU 1400 MAGICNUM 638e6b48 PROTOCOMP ACFCOMP [pptp0] LCP: state change Req-Sent -- Ack-Sent [pptp0] LCP: SendConfigReq #2 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM 438ed756 AUTHPROTO CHAP MSOFTv2 [pptp0] LCP: rec'd Configure Ack #2 link 0 (Ack-Sent) ACFCOMP PROTOCOMP MRU 1500 MAGICNUM 438ed756 AUTHPROTO CHAP MSOFTv2 [pptp0] LCP: state change Ack-Sent -- Opened [pptp0] LCP: auth: peer wants nothing, I want CHAP [pptp0] CHAP: sending CHALLENGE len:17 [pptp0] LCP: LayerUp [pptp0] LCP: rec'd Ident #2 link 0 (Opened) MESG: MSRASV5.10 pptp0-0: ignoring SetLinkInfo [pptp0] LCP: rec'd Ident #3 link 0 (Opened) MESG: MSRAS-0-PCHOME [pptp0] CHAP: rec'd RESPONSE #1 Name: jeandre [pptp0] AUTH: Auth-Thread started [pptp0] AUTH: Trying secret file: mpd.secret Peer name: jeandre [pptp0] AUTH: Auth-Thread finished normally [pptp0] CHAP: ChapInputFinish: status undefined Response is valid [pptp0] CHAP: sending SUCCESS len:42 [pptp0] LCP: authorization successful [pptp0] Bundle up: 1 link, total bandwidth 64000 bps [pptp0] IPCP: Open event [pptp0] IPCP: state change Initial -- Starting [pptp0] IPCP: LayerStart [pptp0] CCP: Open event [pptp0] CCP: state change Initial -- Starting [pptp0] CCP: LayerStart [pptp0] IPCP: Up event [pptp0] IPCP: state change Starting -- Req-Sent [pptp0] IPCP: SendConfigReq #1 IPADDR 192.168.3.1 COMPPROTO VJCOMP, 16 comp. channels, no comp-cid [pptp0] CCP: Up event [pptp0] CCP: state change
Re: [FUG-BR] Persistencia de Dados no FreeBSD
Eder escreveu: R = Eu acho, que essa uma questão a ser avaliada, na Analise do Projeto, os próls e os contras devem serem pessados na balança. Em qualquer direção que se irá seguir, as vantagems aparecerão, e as limitações, támbem, isso é inevitável. A serialização aparece como um caminho diferente, todas as questões que você fez acima, podem ser implementadas, á memória, hoje em dia está barata. Att Eder. Não gosto muito desse pensamento não (acho que foi seguindo esse princípio de desperdício que o Windows foi desenvolvido hehehe). Achar que porque tem muita memória, desperdiça-la. gethostbyname - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Persistencia de Dados no FreeBSD
Qual é o seu nome, verdadeiro? Você não gosta do pensamento porque, por quê pode escolher, uma forma diferente de fazer o trabalho. Veja que interresante, o Windows também tem suas utilidades, tanto para o usúario final, quanto para a comunidade OpenSource. Não podemos esquecer que Microsoft alavancou muita coisa em sua história. Talvés se Windows não existi-se, não teriamos uma comunidade OpenSource, e o poder, para amor computacional. A palavra desperdício é inerente à muita coisa, e também muita relativa, e serve como há melhorá de algo, nós como desenvolderes temos que sempre melhorar, e desperdicios acabam ocorrendo, poste algum código grande seu, que posso apontar, vários disperdicios, que foram feitos, alguns podem ser comprovados outros é uma questão pessoal de simplemente gostar de fazer assim ou assado. No FreeBSD existem desperdício de coisas que não deveriam estar aonde estão, ou não funcionam corretamente, essa é a motivação para fazermos melhor. Esse tipo de discução pode render muitas threads, é igual a discutimos a utilização do goto alguem vai defender o uso, e outros não, se enquadra no nosso cenário de serialização. Os recusos existem e devem ser aplicados aonde há uma necessidade real, para o uso. Att Eder. On 2/25/07, gethostbyname [EMAIL PROTECTED] wrote: Eder escreveu: R = Eu acho, que essa uma questão a ser avaliada, na Analise do Projeto, os próls e os contras devem serem pessados na balança. Em qualquer direção que se irá seguir, as vantagems aparecerão, e as limitações, támbem, isso é inevitável. A serialização aparece como um caminho diferente, todas as questões que você fez acima, podem ser implementadas, á memória, hoje em dia está barata. Att Eder. Não gosto muito desse pensamento não (acho que foi seguindo esse princípio de desperdício que o Windows foi desenvolvido hehehe). Achar que porque tem muita memória, desperdiça-la. gethostbyname - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- Do not worry about your difficulties in mathematics; I can assure you that mine are still greater. Albert Einstein - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Mysql não aceita acentos.
Se você deixou o seu Apache2 com a configuração default, ele estará servindo todas as páginas com o charset UTF8. Você resolve mudando a configuração do charset do Apache2 para ISO8859-1. Alternativamente, você poderá adicionar ao cabeçalho das páginas geradas a partir do PHP uma declaração META informando que o conteúdo desta usa outro charset, da seguinte forma: meta http-equiv=Content-Type content=text/html; charset=iso-8859-1 Se você tiver acesso a configuração do Apache, prefira a primeira opção. []'s Márcio Luís Günther mailto:[EMAIL PROTECTED] http://www.MarcioGunther.com * Esta mensagem pode conter informações confidenciais e/ou privilegiadas. Se você não for o destinatário ou a pessoa autorizada a receber esta mensagem, não deve usar, copiar ou divulgar as informações nela contida ou tomar qualquer ação baseada nessas informações. O sistema de mensagens da Internet não é considerado seguro ou livre de erros. Esta empresa não se responsabiliza por opiniões ou declarações veiculadas através de e-mails. * The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Márcio Günther CS - Segurança da Informação -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eder Sent: Sunday, February 25, 2007 12:37 PM To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) Subject: Re: [FUG-BR] Mysql não aceita acentos. No meu caso, mudar estas configurações no servidor mysql não resolveu. O servidor mudou sim de charset usado nas conexões, mas o módulo do php não. E o módulo do php depende da biblioteca do mysql, que por sua vez tem em seu código pre-definido quando compilado qual o charset padrão. Eu não sei como mudar o padrão da biblioteca sem recompilar, se você souber me desculpe mas é que não encontrei outro meio mesmo. R = Como eu disse não entendo de PHP, mais creio que não é necessário recompilar nada, como sugere eu recompilar um C/C++? Basta alterar essas configurações no banco. ALTER DATABASE name_database DEFAULT CHARACTER SET latin1 COLLATE latin1_swedish_ci; Att, Eder. On 2/25/07, Rafael Fernandes [EMAIL PROTECTED] wrote: Oi de novo! :D Quando um cliente de mysql conecta ao banco, via o cliente padrão mysql ou biblioteca, existe a negociação de um charset para a interpretação do texto enviado entre ambos, independente dos dados do banco ou do texto da linguagem (em c++ ou no caso o php). Quer dizer, temos 1 camada de conversão de charsets internamente no servidor mysql quando ele lê/escreve nas tabelas, 1 camada de conversão de charsets quando os dados trafegam entre o servidor e o cliente/biblioteca mysql (esta camada tanto não segue locale, apenas uma negociação entre o servidor e o cliente/biblioteca, quanto é a causa do problema inicial), e + 1 camada quando o texto é trabalhado no programa do usuário. Por exemplo, uma string no php usaria a codificação iso por padrão. Mas, se você usa um módulo de php que conecta ao servidor em utf-8, você deve codificar esta string em uft-8 antes de enviar por um mysql_query. Como a diferença mesmo entre as 2 codificações são os acentos e outros caracteres acima de 127 (o que não afeta a sintaxe do mysql, e claro não estou falando de codificações com 2 bytes ou mais como a unicode), ocorre o problema que foi colocado, a não aceitação de acentos, com o mysql recebendo os códigos de caractere em codificação diferente da informada pela conexão do cliente (no caso, o próprio módulo do php). Ficar tomando cuidado com quando usar as funções utf8_encode e utf8_decode no PHP levaria às aleatoriedades que mencionei, principalmente quando você migra código e dados desenvolvidos com a espectativa de que estas funções não seriam necessárias. Usar o setlocale no php também não resolveria porque isto modificaria apenas o processamento interno do php em relação às strings (no caso do seu exemplo, mudaria a colagem: qual caractere com acentuação é ligado com qual caractere puro. O case insensitive é um tipo de colagem: cola minúsculas com maiúsculas, não diferenciando elas), horário, moeda e outras coisas, e não quando ele envia texto pelo módulo. Eu mesmo tive que arrumar muitas páginas php com as funções utf8 enquanto tentava descobrir esse detalhe da codificação da conexão. No meu caso, mudar estas configurações no servidor mysql não resolveu. O servidor mudou sim de charset usado nas conexões, mas o módulo do php não. E o módulo do php depende da biblioteca do mysql, que
Re: [FUG-BR] Mysql não aceita acentos.
Como te disse, no caso do que aconteceu comigo e com nosso colega de lista, mudar o charset da tabela não resolveria. Eu tentei explicar da melhor maneira possível mas se ainda assim não acredita no que estou explicando, espero que não venha a ter o problema que tivemos. Até, Rafael. On Sun, 25 Feb 2007 12:37:17 -0300, Eder [EMAIL PROTECTED] wrote: No meu caso, mudar estas configurações no servidor mysql não resolveu. O servidor mudou sim de charset usado nas conexões, mas o módulo do php não. E o módulo do php depende da biblioteca do mysql, que por sua vez tem em seu código pre-definido quando compilado qual o charset padrão. Eu não sei como mudar o padrão da biblioteca sem recompilar, se você souber me desculpe mas é que não encontrei outro meio mesmo. R = Como eu disse não entendo de PHP, mais creio que não é necessário recompilar nada, como sugere eu recompilar um C/C++? Basta alterar essas configurações no banco. ALTER DATABASE name_database DEFAULT CHARACTER SET latin1 COLLATE latin1_swedish_ci; Att, Eder. On 2/25/07, Rafael Fernandes [EMAIL PROTECTED] wrote: Oi de novo! :D Quando um cliente de mysql conecta ao banco, via o cliente padrão mysql ou biblioteca, existe a negociação de um charset para a interpretação do texto enviado entre ambos, independente dos dados do banco ou do texto da linguagem (em c++ ou no caso o php). Quer dizer, temos 1 camada de conversão de charsets internamente no servidor mysql quando ele lê/escreve nas tabelas, 1 camada de conversão de charsets quando os dados trafegam entre o servidor e o cliente/biblioteca mysql (esta camada tanto não segue locale, apenas uma negociação entre o servidor e o cliente/biblioteca, quanto é a causa do problema inicial), e + 1 camada quando o texto é trabalhado no programa do usuário. Por exemplo, uma string no php usaria a codificação iso por padrão. Mas, se você usa um módulo de php que conecta ao servidor em utf-8, você deve codificar esta string em uft-8 antes de enviar por um mysql_query. Como a diferença mesmo entre as 2 codificações são os acentos e outros caracteres acima de 127 (o que não afeta a sintaxe do mysql, e claro não estou falando de codificações com 2 bytes ou mais como a unicode), ocorre o problema que foi colocado, a não aceitação de acentos, com o mysql recebendo os códigos de caractere em codificação diferente da informada pela conexão do cliente (no caso, o próprio módulo do php). Ficar tomando cuidado com quando usar as funções utf8_encode e utf8_decode no PHP levaria às aleatoriedades que mencionei, principalmente quando você migra código e dados desenvolvidos com a espectativa de que estas funções não seriam necessárias. Usar o setlocale no php também não resolveria porque isto modificaria apenas o processamento interno do php em relação às strings (no caso do seu exemplo, mudaria a colagem: qual caractere com acentuação é ligado com qual caractere puro. O case insensitive é um tipo de colagem: cola minúsculas com maiúsculas, não diferenciando elas), horário, moeda e outras coisas, e não quando ele envia texto pelo módulo. Eu mesmo tive que arrumar muitas páginas php com as funções utf8 enquanto tentava descobrir esse detalhe da codificação da conexão. No meu caso, mudar estas configurações no servidor mysql não resolveu. O servidor mudou sim de charset usado nas conexões, mas o módulo do php não. E o módulo do php depende da biblioteca do mysql, que por sua vez tem em seu código pre-definido quando compilado qual o charset padrão. Eu não sei como mudar o padrão da biblioteca sem recompilar, se você souber me desculpe mas é que não encontrei outro meio mesmo. O que tinha sugerido para solução é justamente isto: recompilando o mysql-server, seria recompilada também a biblioteca, usando o mesmo charset para conexões por padrão, se o módulo do php dele fosse linkado dinamicamente isto já resolveria também o problema dentro do php (se o módulo for linkado estaticamente com a biblioteca mysql, seria necessário recompilá-lo também!), então ele não seria obrigado a usar as funções utf8 sempre que quisesse fazer uma query ao banco. Se ele não tiver um computador que seja antigo a ponto de isto ser proibitivo, é mais simples fazer o que sugeri ao invéz de tudo o que envolveria se fosse resolver de outro modo. Claro que eu estava me baseando no meu caso, num site onde existem vários sub-sites, cada um feito por um tipo de pessoa, com nível de conhecimento também variável, pior seria se eu me preocupasse em ajustar isto pelo php. E acreditei que isto também serviria para ele, até porque seria uma chamada de função a menos para cada query. O que eu tinha entendido, pela sua primeira mensagem, era que você esperava que o problema fosse solucionado com a mudança do charset da tabela, o que ele já havia tentado. Por isto, pensei que você não estivesse muito a par de outras
Re: [FUG-BR] Mysql não aceita acentos.
Em momento algum disse que não acreditava em suas explicações, tanto que não contestei o resto do email, porque o que falou está correto. Simplesmente procurei, e não encontrei nada que o justificase, inclusive compilei o PHP aqui na minha máquina, via ports, e modulo php para MySQL, mais não tive o problema, agora se eu alterar os caracteres no database do MySQL para outro tipo, os acentos não entram corretos, ou entram de forma errônea. Em Latin1 funciona corretamente. espero que não venha a ter o problema que tivemos. R = Eu espero ter sim, assim posso testar realmente se o que falou, se contesta, como posso simular o erro? Att Eder. On 2/25/07, Rafael Fernandes [EMAIL PROTECTED] wrote: Como te disse, no caso do que aconteceu comigo e com nosso colega de lista, mudar o charset da tabela não resolveria. Eu tentei explicar da melhor maneira possível mas se ainda assim não acredita no que estou explicando, espero que não venha a ter o problema que tivemos. Até, Rafael. On Sun, 25 Feb 2007 12:37:17 -0300, Eder [EMAIL PROTECTED] wrote: No meu caso, mudar estas configurações no servidor mysql não resolveu. O servidor mudou sim de charset usado nas conexões, mas o módulo do php não. E o módulo do php depende da biblioteca do mysql, que por sua vez tem em seu código pre-definido quando compilado qual o charset padrão. Eu não sei como mudar o padrão da biblioteca sem recompilar, se você souber me desculpe mas é que não encontrei outro meio mesmo. R = Como eu disse não entendo de PHP, mais creio que não é necessário recompilar nada, como sugere eu recompilar um C/C++? Basta alterar essas configurações no banco. ALTER DATABASE name_database DEFAULT CHARACTER SET latin1 COLLATE latin1_swedish_ci; Att, Eder. On 2/25/07, Rafael Fernandes [EMAIL PROTECTED] wrote: Oi de novo! :D Quando um cliente de mysql conecta ao banco, via o cliente padrão mysql ou biblioteca, existe a negociação de um charset para a interpretação do texto enviado entre ambos, independente dos dados do banco ou do texto da linguagem (em c++ ou no caso o php). Quer dizer, temos 1 camada de conversão de charsets internamente no servidor mysql quando ele lê/escreve nas tabelas, 1 camada de conversão de charsets quando os dados trafegam entre o servidor e o cliente/biblioteca mysql (esta camada tanto não segue locale, apenas uma negociação entre o servidor e o cliente/biblioteca, quanto é a causa do problema inicial), e + 1 camada quando o texto é trabalhado no programa do usuário. Por exemplo, uma string no php usaria a codificação iso por padrão. Mas, se você usa um módulo de php que conecta ao servidor em utf-8, você deve codificar esta string em uft-8 antes de enviar por um mysql_query. Como a diferença mesmo entre as 2 codificações são os acentos e outros caracteres acima de 127 (o que não afeta a sintaxe do mysql, e claro não estou falando de codificações com 2 bytes ou mais como a unicode), ocorre o problema que foi colocado, a não aceitação de acentos, com o mysql recebendo os códigos de caractere em codificação diferente da informada pela conexão do cliente (no caso, o próprio módulo do php). Ficar tomando cuidado com quando usar as funções utf8_encode e utf8_decode no PHP levaria às aleatoriedades que mencionei, principalmente quando você migra código e dados desenvolvidos com a espectativa de que estas funções não seriam necessárias. Usar o setlocale no php também não resolveria porque isto modificaria apenas o processamento interno do php em relação às strings (no caso do seu exemplo, mudaria a colagem: qual caractere com acentuação é ligado com qual caractere puro. O case insensitive é um tipo de colagem: cola minúsculas com maiúsculas, não diferenciando elas), horário, moeda e outras coisas, e não quando ele envia texto pelo módulo. Eu mesmo tive que arrumar muitas páginas php com as funções utf8 enquanto tentava descobrir esse detalhe da codificação da conexão. No meu caso, mudar estas configurações no servidor mysql não resolveu. O servidor mudou sim de charset usado nas conexões, mas o módulo do php não. E o módulo do php depende da biblioteca do mysql, que por sua vez tem em seu código pre-definido quando compilado qual o charset padrão. Eu não sei como mudar o padrão da biblioteca sem recompilar, se você souber me desculpe mas é que não encontrei outro meio mesmo. O que tinha sugerido para solução é justamente isto: recompilando o mysql-server, seria recompilada também a biblioteca, usando o mesmo charset para conexões por padrão, se o módulo do php dele fosse linkado dinamicamente isto já resolveria também o problema dentro do php (se o módulo for linkado estaticamente com a biblioteca mysql, seria necessário recompilá-lo também!), então ele não seria obrigado a usar as funções utf8 sempre que quisesse fazer uma query ao banco. Se ele não tiver
Re: [FUG-BR] Persistencia de Dados no FreeBSD
Eder escreveu: Qual é o seu nome, verdadeiro? Pedro Henrique. Você não gosta do pensamento porque, por quê pode escolher, uma forma diferente de fazer o trabalho. Veja que interresante, o Windows também tem suas utilidades, tanto para o usúario final, quanto para a comunidade OpenSource. É claro. Concordo plenamente que a rivalidade Windows x Unix(s) é fundamental para o desenvolvimento de ambos. E agora, quem irá rivalizar com o Google no futuro? Não podemos esquecer que Microsoft alavancou muita coisa em sua história. Talvés se Windows não existi-se, não teriamos uma comunidade OpenSource, e o poder, para amor computacional. A palavra desperdício é inerente à muita coisa, e também muita relativa, e serve como há melhorá de algo, nós como desenvolderes temos que sempre melhorar, e desperdicios acabam ocorrendo, poste algum código grande seu, que posso apontar, vários disperdicios, que foram feitos, alguns podem ser comprovados outros é uma questão pessoal de simplemente gostar de fazer assim ou assado. Uma questão é cometer desperdícios por engano, outra é querer desperdiçar. No FreeBSD existem desperdício de coisas que não deveriam estar aonde estão, ou não funcionam corretamente, essa é a motivação para fazermos melhor. Qual desperdício você poderia citar? Eu não sou nenhum cientista da computação, mas o código do kernel do FreeBSD me parece tão bem feito. Esse tipo de discução pode render muitas threads, é igual a discutimos a utilização do goto alguem vai defender o uso, e outros não, se enquadra no nosso cenário de serialização. Os recusos existem e devem ser aplicados aonde há uma necessidade real, para o uso. Acho que isso é semelhante a JAVA. Ela é boa para o programador, mas não tanto para o usuário. PH - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] OT: Re: RES: C/C++
Você gostaria de mais ou menos um SO orientado a objetos que não seguisse padrões rigorosos? Algo dinâmico como a API de JAVA, diferente de C++? Não sei se eu gostaria, mas, como disse, consigo vislumbrar algo para o qual um processo, ao terminar, possa devolver mais do que um simples valor inteiro. -- Um abraço. Paulo A. P. Pires ... Qui habet aurem audiat quid Spiritus dicat ecclesiis. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Persistencia de Dados no FreeBSD
Assim, bem melhor agora Pedro Henrique, muito mais simples do que eu chama-ló de gethostbyname. E agora, quem irá rivalizar com o Google no futuro? R = Pois é uma otima pergunta, mais nós estamos aqui firmes e fortes e daremos conta do recado. Uma questão é cometer desperdícios por engano, outra é querer desperdiçar. R = Sim Qual desperdício você poderia citar? R = Humm, isso é um assunto para uma nova thread, já estamos saindo um pouco fora da pergunta do nosso amigo lá em cima. Eu não sou nenhum cientista da computação, mas o código do kernel do FreeBSD me parece tão bem feito. R = Então somos ambos, também concordo sobre o Kernel do FreeBSD. Acho que isso é semelhante a JAVA. Ela é boa para o programador, mas não tanto para o usuário. R = Java é lento, isso não tem como negar, mais quem roda Java em um Sparc da Sun, saca a diferença. Qualquer linguagem é boa para o programador desde que ele saiba domina-lá. Para o usúario quase sempre as coisas são transparentes, ele não está preocupado com o que tem por trás, o que ele irá notar talvés sejá, que este Programa é mais lento do que o outro que tinhamos antes. Att, Eder. On 2/25/07, gethostbyname [EMAIL PROTECTED] wrote: Eder escreveu: Qual é o seu nome, verdadeiro? Pedro Henrique. Você não gosta do pensamento porque, por quê pode escolher, uma forma diferente de fazer o trabalho. Veja que interresante, o Windows também tem suas utilidades, tanto para o usúario final, quanto para a comunidade OpenSource. É claro. Concordo plenamente que a rivalidade Windows x Unix(s) é fundamental para o desenvolvimento de ambos. E agora, quem irá rivalizar com o Google no futuro? Não podemos esquecer que Microsoft alavancou muita coisa em sua história. Talvés se Windows não existi-se, não teriamos uma comunidade OpenSource, e o poder, para amor computacional. A palavra desperdício é inerente à muita coisa, e também muita relativa, e serve como há melhorá de algo, nós como desenvolderes temos que sempre melhorar, e desperdicios acabam ocorrendo, poste algum código grande seu, que posso apontar, vários disperdicios, que foram feitos, alguns podem ser comprovados outros é uma questão pessoal de simplemente gostar de fazer assim ou assado. Uma questão é cometer desperdícios por engano, outra é querer desperdiçar. No FreeBSD existem desperdício de coisas que não deveriam estar aonde estão, ou não funcionam corretamente, essa é a motivação para fazermos melhor. Qual desperdício você poderia citar? Eu não sou nenhum cientista da computação, mas o código do kernel do FreeBSD me parece tão bem feito. Esse tipo de discução pode render muitas threads, é igual a discutimos a utilização do goto alguem vai defender o uso, e outros não, se enquadra no nosso cenário de serialização. Os recusos existem e devem ser aplicados aonde há uma necessidade real, para o uso. Acho que isso é semelhante a JAVA. Ela é boa para o programador, mas não tanto para o usuário. PH - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- Do not worry about your difficulties in mathematics; I can assure you that mine are still greater. Albert Einstein - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Monitoramento de tráfego detalhado por serviço
Valeu galera, instalei o ntop e estou mechendo nele aqui. =] []s On 2/23/07, Matheus Cucoloto [EMAIL PROTECTED] wrote: Em 23/02/07, Welkson Renny de Medeiros[EMAIL PROTECTED] escreveu: NTOP já tenho... a idéia é gerar gráfico apartir de uma regra qualquer do firewall. Olá a todos... Eu uso ipfw+snmp e os graficos quem faz eh o mrtg apartir de regras especificas do ipfw. segue abaixo a dica: http://www.sat.t.u-tokyo.ac.jp/~hideyuki/ipfwsnmp.html -- Matheus Cucoloto System Admin. Net Admin. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] Network Simulator
All, Alguém por aqui usa o Network Simulator? Se sim, teria um script simples para simular roteamento entre 2 redes? Thanks -- Celso Vianna BSD User: 51318 http://www.bsdcounter.org 63 8404-8559 Palmas/TO - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Mysql não aceita acentos.
Não precisa de muito para fazer o teste não. Apenas rode o código a seguir:
- teste.php
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
head
meta http-equiv=Content-Type content=text/html; charset=iso-8859-1
/
titleCharacter-set de conexão com o mysql/title
/head
body
?php
// Ok, vamos brincar com um texto antes usando o que temos de charset
// de conexão padrão no servidor (deveria ser latin1, se não foi ajustado
// outra coisa ao compilar a biblioteca)
mysql_connect( localhost, root, leleafar );
// Vamos ver qual é o charset padrão usado na conexão.
$r = mysql_fetch_row(mysql_query(select charset('abc');));
echo pCharset Padrão desta conexão: $r[0]/p\n;
// Bom, vamos fazer uma tabelinha com o charset latin1 no banco test
// que o mysql cria por padrão
if (mysql_query(create table if not exists `test`.`chartest` (texto TEXT)
character set latin1;))
echo pTabela criada!/p;
else {
echo pErro ao criar a tabela./p;
exit(0);
}
// Beleza, vamos fazer um teste para guardar o texto com acentuação
$texto = áéíóçãõà;
echo pTexto para testes: $texto (deve estar aparecendo corretamente no
navegador!)/p\n;
mysql_query(insert into `test`.`chartest` set texto = '$texto';);
// Vamos ver o que ele guardou?
$r = mysql_fetch_row(mysql_query(select texto from `test`.`chartest`;));
if ($r[0] == $texto)
echo pO texto permanece igual!/p;
else
// isto não deveria acontecer se seu módulo mysql estiver em latin1
echo pOpa, o texto foi modificado! Texto retornado: $r[0]/p\n;
mysql_close();
// Ok, o legal é que o código acima tenha como resultado o texto
permanecer igual. Isto quer dizer que nossa conexão é latin1,
// Mas, qual seria o resultado se nossa conexão fosse, por padrão, em
utf-8? Vamos descobrir.
mysql_connect( localhost, root, leleafar );
// Vamos mudar o charset da conexão apenas (deve ser a primeira coisa a
ser feita, pelo o que está na documentação);
// Leia sobre isto onde indiquei anteriormente:
http://dev.mysql.com/doc/refman/5.0/en/charset-connection.html
mysql_query(set NAMES utf8;);
// Vamos fazer nosso teste de descobrir qual o charset padrão para
verificar se deu certo a query anterior.
$r = mysql_fetch_row(mysql_query(select charset('abc');));
// Deve mostrar utf8 como resultado.
echo pCharset Padrão desta conexão: $r[0]/p\n;
// Vamos ver o que ele retorna pra gente agora?
$r = mysql_fetch_row(mysql_query(select texto from `test`.`chartest`;));
if ($r[0] == $texto)
echo pO texto permanece igual!/p;
else
echo pOpa, o texto foi modificado! Texto retornado: $r[0]/p\n;
// Se o charset padrão desta conexão for utf-8, você já percebeu que o
texto foi alterado... mas nem tanto!
// Na verdade, seu texto foi retornado em utf-8, MESMO COM A TABELA
MARCADA COMO LATIN1
// Vamos conferir?
if ($texto == utf8_decode($r[0]))
echo pÉ o mesmo texto realmente, só que foi retornado em
UTF-8!/p\n;
/* Entendeu o problema? O problema não é na tabela, nem no locale, e sim
no charset usado pelo módulo php, que tem
o charset padrão dependente de como foi compilada antes a biblioteca do
mysql, pois não conheço arquivo de
configuração para esta biblioteca. */
// Vamos acabar com nossa tabela de testes
mysql_query(drop table `test`.`chartest`;);
mysql_close();
?
/body
- fim
Como te disse, no meu caso, é complicado ajustar os scripts para usar
uft8_decode ou a query de mudar o charset da conexão num site de mais de 8
anos (onde trabalhei apenas nos 2 últimos), que passou por várias pessoas
diferentes, e com vários setores desenvolvidos por pessoas diferentes,
quase sempre de maneira totalmente desorganizada.
A solução simples e eficiente no meu caso foi recompilar a biblioteca e o
módulo para usarem latin1 como padrão de conexão, pois estavam em utf-8.
Acho que agora estará satisfeito, vendo o resultado disto com os próprios
olhos.
Até,
Rafael.
On Sun, 25 Feb 2007 13:32:16 -0300, Eder [EMAIL PROTECTED] wrote:
Em momento algum disse que não acreditava em suas explicações,
tanto que não contestei o resto do email, porque o que falou está
correto.
Simplesmente procurei, e não encontrei nada que o justificase, inclusive
compilei o PHP aqui na minha máquina, via ports, e modulo php para MySQL,
mais não tive o problema, agora se eu alterar os caracteres no database
do MySQL
para outro tipo, os acentos não entram corretos, ou entram de forma
errônea.
Em Latin1 funciona corretamente.
espero que não venha a ter o problema que tivemos.
R = Eu espero ter sim, assim posso testar realmente se o que falou,
se contesta, como posso simular o erro?
Att Eder.
On 2/25/07, Rafael Fernandes [EMAIL PROTECTED] wrote:
Como te disse, no caso do que aconteceu comigo e com nosso colega de
lista, mudar o charset da tabela não resolveria.
Eu tentei explicar da melhor maneira possível mas se
Re: [FUG-BR] Mysql não aceita acentos.
Entendi,
Então isso pode ser alterado no arquivo php.ini, no default_charset, mais
mesmo assim é estranho.
Observe no código fonte do PHP em ext/mysql/php_mysql.c a função é bem
clara,
/* Returns the default character set for the current connection */
PHP_FUNCTION(mysql_client_encoding)
{...}
Att Eder.
On 2/25/07, Rafael Fernandes [EMAIL PROTECTED] wrote:
Não precisa de muito para fazer o teste não. Apenas rode o código a seguir:
- teste.php
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
head
meta http-equiv=Content-Type content=text/html;
charset=iso-8859-1 /
titleCharacter-set de conexão com o mysql/title
/head
body
?php
// Ok, vamos brincar com um texto antes usando o que temos de charset
// de conexão padrão no servidor (deveria ser latin1, se não foi ajustado
// outra coisa ao compilar a biblioteca)
mysql_connect( localhost, root, leleafar );
// Vamos ver qual é o charset padrão usado na conexão.
$r = mysql_fetch_row(mysql_query(select charset('abc');));
echo pCharset Padrão desta conexão: $r[0]/p\n;
// Bom, vamos fazer uma tabelinha com o charset latin1 no banco test
// que o mysql cria por padrão
if (mysql_query(create table if not exists `test`.`chartest` (texto TEXT)
character set latin1;))
echo pTabela criada!/p;
else {
echo pErro ao criar a tabela./p;
exit(0);
}
// Beleza, vamos fazer um teste para guardar o texto com acentuação
$texto = áéíóçãõà;
echo pTexto para testes: $texto (deve estar aparecendo corretamente no
navegador!)/p\n;
mysql_query(insert into `test`.`chartest` set texto = '$texto';);
// Vamos ver o que ele guardou?
$r = mysql_fetch_row(mysql_query(select texto from `test`.`chartest`;));
if ($r[0] == $texto)
echo pO texto permanece igual!/p;
else
// isto não deveria acontecer se seu módulo mysql estiver em latin1
echo pOpa, o texto foi modificado! Texto retornado: $r[0]/p\n;
mysql_close();
// Ok, o legal é que o código acima tenha como resultado o texto
permanecer igual. Isto quer dizer que nossa conexão é latin1,
// Mas, qual seria o resultado se nossa conexão fosse, por padrão, em
utf-8? Vamos descobrir.
mysql_connect( localhost, root, leleafar );
// Vamos mudar o charset da conexão apenas (deve ser a primeira coisa a
ser feita, pelo o que está na documentação);
// Leia sobre isto onde indiquei anteriormente:
http://dev.mysql.com/doc/refman/5.0/en/charset-connection.html
mysql_query(set NAMES utf8;);
// Vamos fazer nosso teste de descobrir qual o charset padrão para
verificar se deu certo a query anterior.
$r = mysql_fetch_row(mysql_query(select charset('abc');));
// Deve mostrar utf8 como resultado.
echo pCharset Padrão desta conexão: $r[0]/p\n;
// Vamos ver o que ele retorna pra gente agora?
$r = mysql_fetch_row(mysql_query(select texto from `test`.`chartest`;));
if ($r[0] == $texto)
echo pO texto permanece igual!/p;
else
echo pOpa, o texto foi modificado! Texto retornado: $r[0]/p\n;
// Se o charset padrão desta conexão for utf-8, você já percebeu que o
texto foi alterado... mas nem tanto!
// Na verdade, seu texto foi retornado em utf-8, MESMO COM A TABELA
MARCADA COMO LATIN1
// Vamos conferir?
if ($texto == utf8_decode($r[0]))
echo pÉ o mesmo texto realmente, só que foi retornado em
UTF-8!/p\n;
/* Entendeu o problema? O problema não é na tabela, nem no locale, e sim
no charset usado pelo módulo php, que tem
o charset padrão dependente de como foi compilada antes a biblioteca do
mysql, pois não conheço arquivo de
configuração para esta biblioteca. */
// Vamos acabar com nossa tabela de testes
mysql_query(drop table `test`.`chartest`;);
mysql_close();
?
/body
- fim
Como te disse, no meu caso, é complicado ajustar os scripts para usar
uft8_decode ou a query de mudar o charset da conexão num site de mais de 8
anos (onde trabalhei apenas nos 2 últimos), que passou por várias pessoas
diferentes, e com vários setores desenvolvidos por pessoas diferentes,
quase sempre de maneira totalmente desorganizada.
A solução simples e eficiente no meu caso foi recompilar a biblioteca e o
módulo para usarem latin1 como padrão de conexão, pois estavam em utf-8.
Acho que agora estará satisfeito, vendo o resultado disto com os próprios
olhos.
Até,
Rafael.
On Sun, 25 Feb 2007 13:32:16 -0300, Eder [EMAIL PROTECTED] wrote:
Em momento algum disse que não acreditava em suas explicações,
tanto que não contestei o resto do email, porque o que falou está
correto.
Simplesmente procurei, e não encontrei nada que o justificase, inclusive
compilei o PHP aqui na minha máquina, via ports, e modulo php para MySQL,
mais não tive o problema, agora se eu alterar os caracteres no database
do MySQL
para outro tipo, os acentos não entram corretos, ou entram de forma
errônea.
Em Latin1
