| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | | Quanto a mim tudo depende do locale(5) e do locale(7).
I.e. se tiveres o LANG=pt_PT vais ter tudo como era "normal" mesmo com uma glibc/locales que reconhece UTF8.
Claro que o mais conservador é ter o LANG=C e ter apenas o LC_CTYPE=pt_PT... Anyway, só tens problemas se quiseres. No pior dos casos tens que arrancar alguns programas com uma determinada env. <-- Porque nem toda a userland está bem programada e por isso não honra locales multibyte :|
Regards,
Nuno Silva aka RaTao |
| | | | | | Se nao tivesse participado na discussao, era este o comentario do "Esclarecedor".
Cheer.s
^S^ |
| | | | O utf já vem por defeito no mandrake 9.1, que por acaso até saiu antes do redhat, mas sinceramente o resultado não foi grande coisa, espero que no redhat as coisas corram melhor (não o experimentei). Acabei por voltar ao iso pq tinha problemas em coisas tão simples como o samba ou ver uma página do man. Maybe in 9.2....
|
| | | | | | O Unicode ja' vinha no RedHat 8.0.
Pelo que escreves, parece-me que estejas a presumir as versoes Mandrake 9.1 que saiu antes do RedHat 9.
Se assim for, entao deve ser tomada em comparacao a versao de Mandrake que saiu por volta de Set/2002 (quando saiu o RedHat 8.0).
Cheers.
^S^ |
| | | | Exacto, a minha comparação era mesmo mandrake9.1 vs redhat 9.
Provavelmente o mandrake 9 até tinha unicode (sinceramente nao testei), mas a diferença é que na versão 9.1 este vem activado por defeito.
|
| | | | Certo.
Mas ja' na versao 8.0 do Redhat que vinha com o UTF-8 por defeito.
//vd |
| | | | | Eu acho o UNICODE excelente como padrão de intercâmbio de informações. Mas como suporte nativo, eu acho que é desperdício de processamento... Não consigo aceitar que todas as minhas aplicações precisem ser reescritas (e ainda consumir mais memória ou processamento por string) para padronizar uma tarefa (escrever em mais de uma língua) que uma minoria precisa - e ainda por cima, sob circusntâncias controladas... Mesmo eu que trabalho no dia à dia com Português e Inglês (e começando à dar pulinhos em Deutsch)faço-o no email, no ICQ e no processador de textos... Nunca na linha de comando!!
[]s,
Pink@Manaus.Amazon.Brazil.America.Earth.SolarSystem.OrionArm.MilkyWay.Universe |
| | | | | | | Mas como suporte nativo, eu acho que é desperdício de processamento... Não consigo aceitar que todas as minhas aplicações precisem ser reescritas (e ainda consumir mais memória ou processamento por string) para padronizar uma tarefa (escrever em mais de uma língua) que uma minoria precisa - e ainda por cima, sob circusntâncias controladas... E depois o pessoal admira-se que a M$ ganha terreno...
"I triple guarantee you, there are no American soldiers in Baghdad.", Mohammed Saeed al-Sahaf, Iraqi Minister of Information
|
| | | | A Microsoft so suporta "algo" nos seus productos quando sente alguma ameaça, tal como aconteceu na Noruega, onde estava para perder umas quantas milhares de instalações e teve que suportar dois dialectos locais que pelos vistos um deles até é inventado...
"No comments"
|
| | | | Eu olho para o Unicode como a data cujo ano deve ter 4 digitos e não 2 digitos. O Unicode faz falta!
Dantes até podia fazer sentido, por todos os motivos e mais alguns que possam aparecer, que apenas se suportasse o ASCII e que quem quisesse usar algo mais tivesse de se aguentar à bronca.
Hoje em dia, é ridiculo virem dizer que uma string de 256 caracteres de uma qualquer mensagem que passa a usar 512 bytes em memória para suportar o Unicode é uma afronta.
Em devices específicos, em que existem limitações de memória ainda se entende agora num PC???
Voltando à questão da MS suportar Unicode, certamente é para não terem de se preocupar em fazer vários builds das aplicações para cada lingua pois supostamente o unicode dá suporte para todas as linguas (é o que dizem os tipos da Symbian que têm o SO a correr c/ limitações de memória e a suportar Unicode), o que na minha opinião, se é que vale de alguma coisa, faz todo o sentido.
Nada do que foi escrito deve ser levado em consideração... |
| | | | | Hoje em dia, é ridiculo virem dizer que uma string de 256 caracteres de uma qualquer mensagem que passa a usar 512 bytes em memória para suportar o Unicode é uma afronta. Para uma string, sem dúvida. Para dezenas de milhares (ei! quantas strings vc acha que existem armazenadas no seu computador?? filesystem, localization, etc?), IMHO, não. Eu não consigo enxergar a necessidade de UNICODE para nomes no filesystem, para dialogs e menus que, ao menos em teoria, deveriam estar na minha língua pátria.
[]s,
Pink@Manaus.Amazon.Brazil.America.Earth.SolarSystem.OrionArm.MilkyWay.Universe |
| | | | | A Microsoft so suporta "algo" nos seus productos quando sente alguma ameaça, tal como aconteceu na Noruega, onde estava para perder umas quantas milhares de instalações e teve que suportar dois dialectos locais que pelos vistos um deles até é inventado... E 95% dos homens apenas tomam banho e usam aftershave depois das namoradas ameacarem os deixar... your point being ?
"I triple guarantee you, there are no American soldiers in Baghdad.", Mohammed Saeed al-Sahaf, Iraqi Minister of Information
|
| | | | 95% dos homens apenas tomam banho e usam aftershave depois das namoradas ameacarem os deixar
Isso na inglaterra deve ser cá um cheiro...
------ EOFim. |
| | | | O nevoeiro esta' la' por alguma razao...
//vd |
| | | | Olha, se queres saber qual é o ponto de being, pergunta ao pessoal que escreve da direita para a esquerda :-).
"No comments"
|
| | | | | O Windows lá do trabalho dá suporte para Árabe e Hebreu sem usar UNICODE... 8-) Escrever da direita para esquerda, de baixo para cima ou no sentido anti-horário não tem absolutamente nada à ver com charsets, sejam eles UNICODE ou não... 8-P
[]s,
Pink@Manaus.Amazon.Brazil.America.Earth.SolarSystem.OrionArm.MilkyWay.Universe |
| | | | Diz isso ao pessoal que esvreve da direita para a esquerda em Árabe ou Hebreu no Office para Mac...
"No comments"
|
| | | | | Eu disse. E eles responderam que usam Windows com suporte para escrita da direita para a esquerda... SEM USAR UNICODE. 8-) Eles usam, respectivamente, codepage 10004 e 10005... Eu tenho MSDN, e instalei o Windows XP em Árabe. TODA a interface fica direcionada da direita para a esquerda... Botões "OK" e "Cancel", Menu "Iniciar" (que em árabe eu não sei nem pronunciar... heheh), TUDO. UNICODE não resolve tudo sozinho. Aliás, ele não resolve nada. Ele simplifica a solução. Ele é um charset imenso. Entrada e Saída de dados é outro problema. Charsets não são programas. São dados.
[]s,
Pink@Manaus.Amazon.Brazil.America.Earth.SolarSystem.OrionArm.MilkyWay.Universe |
| | | | E eu repito: Office para Mac...
"No comments"
|
| | | | | Hummm.... que ponto do meu post foi escrito em grego??? 8-P Suporte para escrita da direita para a esquerda nada tem à ver com UNICODE, que me parece ser o tópico desta thread. O Office terá suporte para isto (se é que já não tem, nós não trabalhamos com Mac aqui na empresa - uma lástima) quando alguém reescrever a interface para dar suporte à isto, não quando ele passar à exibir caracteres UNICODE.
[]s,
Pink@Manaus.Amazon.Brazil.America.Earth.SolarSystem.OrionArm.MilkyWay.Universe |
| | | | | "Hummm.... que ponto do meu post foi escrito em grego??? 8-P" Idem Ibidem...Respondi ào comentário sobre quando e como a Micro dá suporte se ja ao que for...
"No comments"
|
| | | | | E depois o pessoal admira-se que a M$ ganha terreno... Desperdiçando processamento... 8-)
[]s,
Pink@Manaus.Amazon.Brazil.America.Earth.SolarSystem.OrionArm.MilkyWay.Universe |
| | | | Rule of thumb:80% dos utilizadores usa apenas 20% das capacidades so software.. o problema é que não utilizam todos os mesmos 20%.
Para o caso: a maioria dos utilizadores não precisa de um charset que suporte todas as linguas, mas a maioria dos utilizadores não precisam todos do mesmo charset.
O impacto da utilização de Unicode como formato de intercâmbio de informação é relativamente limitada: a maioria dos protocolo vai permitindo a coexistência de múltiplos charsets.
Contudo, uma vez que Unicode é o superset de todos os charsets existentes (ou quase) é muito mais fácil escrever o software à volta de Unicode, mesmo que ele tenha de ser capaz de lidar com múltiplos charsets.
Depois há sempre as aplicações em que não é possivel fazer coexistir harmoniosamente vários charsets. E ai não te convém fazer uma escolha que se possa revelar uma limitação dificil de resolver no amanhã.
Por outro lado, o impacto na performance é completamente desprezável para a maioria dos casos. O processamento do texto propriamente dito ocupa uma parte extremamente diminuta dos recursos na maiorias das aplicações actuais. E, se não for, podes sempre optar por outro charset para essa aplicação.
Por exemplo, há até quem opte por manter DBs em ASCII em vez de um ISO8859, porque assim não é necessário ter de normalizar os caracteres acentuados nas comparações "case insensitive".
Remember to be the Killer, not the Victim! (Nuklear Girl) |
| | | | Escreves um ficheiros de texto com o gedit ou, para algo mais complexo, AbiWord. Ambos reteem os dados em UTF8. Queres encontrar qual dos muitos ficheiros tem algo, como fazes grep em condicoes?
|
| | | | | editor de texto, como gedit e AbiWord, são aplicações. Que elas suportem UNICODE se desejado for. E que este suporte esteja até no kernel, que alguém achar que deve ser assim. Mas continuo não vendo porque diabos TODAS as demais aplicações (como a kdevelop ou o lazarus) devam usar UNICODE também. Quanto ao problema do egrep, use um egrep unicode enable, ué. Reescrever o egrep, IMHO, é tarefa bem mais exequivel que resscrever o resto das aplicações que não precisam de UNICODE (GCC ???).
[]s,
Pink@Manaus.Amazon.Brazil.America.Earth.SolarSystem.OrionArm.MilkyWay.Universe |
| | | | Porque sim o gEdit e não kDevelop?
Adiante.. Os caracteres são representados como números. A correspondência entre números e caracteres é establecida por tabelas chamadas charsets. Existem muitos charsets, mas com excepção de Unicode nenhum tem o potencial de satisfazer as necessidades de todas as linguas do mundo. Torna-se então necessário utilizar charsets diferentes para representar o texto, conforme a lingua.
Contudo, uma vez que nem sempre é possivel determinar inequivocamente o charset do texto, torna-se dificil fazer coexistir múltiplos charsets a alguns niveis. Por outro lado, é possivel determinar inequivocamente o charset de algumas coisas: por exemplo, de um documento XML -- está lá escrito.
Torna-se então necessário definir um charset global para cada sistema, segundo o qual as aplicações vão interpretar todo o texto cujo charset é ambiguo. Por exemplo, se tiveres uma aplicação que interpreta os nomes dos ficheiros como ISO-8869-1 e outra que os interprete como ISO-2022-KR, vais ter resultados.. interessantes.
A questão do suporte para Unicode não é algo de novo em sistemas Unix. É apenas mais um charset, tal como ISO-8859-1.Com a particularidade de servir para toda a gente. E qualquer aplicação deve ser escrita de modo a funcionar bem utilizando qualquer charset para o qual o sistema possa estar configurado. E sim, o grep e o GCC suportam Unicode, desde que a libc suporta Unicode, tal como suportam outro charset qualquer.
Contudo, suportar charsets diferentes em sistemas diferentes representa trabalho extra, que muita gente pretende eliminar passando a utilizar Unicode.
Há aplicações e bibliotecas que internamente se baseiam em Unicode, convertendo de e para o charset do sistema apenas quando necessário, para simplificar o código.
Distribuições como a RedHat que escolheram adoptar Unicode como o charset por omissão do sistema.
Depois há, numa nota menos positiva, aplicações como o gEdit, que o Cyclops referiu, que ignoram as definições do sistema e assumem sempre Unicode. Isto não me incomodava se Unicode fosse o charset standard para Unix, mas não é nem existe tal coisa.
Remember to be the Killer, not the Victim! (Nuklear Girl) |
| | | | | E sim, o grep e o GCC suportam Unicode, desde que a libc suporta Unicode, tal como suportam outro charset qualquer Desde que ninguém use char var[] em lugar algum do código. ;-) Dar suporte ao GCC à UNICODE é muito, mas muito mais do que simplesmente ligá-lo à uma nova versão da LIBC. É necessário código para converter o UNICODE (UTF8, 16 ou 32) para Plain Text antes de passá-lo para o analisador léxico, ou então reescrever todo o analisador léxico para reconhecer UNICODE. IMHO, obrigar que toda aplicação UNIX dê suporte à UNICODE é similar à querer obrigar que toda aplicação use mouse ou que funcione numa janela no X. Não sou contra UNICODE na userland. Sou contra UNICODE indiscriminadamente por toda a userland. Mas sou contra UNICODE no filesystem, no console, nos menus e nas dialog-boxes. Unicode onde ele é necessário. Charsets ISO no resto. KISS'es. ;-)
[]s,
Pink@Manaus.Amazon.Brazil.America.Earth.SolarSystem.OrionArm.MilkyWay.Universe |
| | | | E o que é que defines como "plain text"?
Em Unix, as strings são habitualmente representadas como uma sequência de bytes terminadas por um byte 0, em que os valores 0-127 correspondem aos caracteres ASCII e o significado dos valores 128-255 dependem do charset. Isto é o máximo que consigo definir como plain text.
A regra para escrever programas é: podes assumir sobre o significado sobre os caracteres 0-127 mas não sobre os 128-255.
Obviamente, as representações directas de Unicode, UCS-2 e UCS-4 não encaixam aqui. Mas existe UTF-8, concebido especificamente para encaixar aqui.
O GCC na verdade não precisa de ajuda nenhuma para compilar código fonte codificado em UTF-8 ou outro charset qualquer. Isto porque o compilador de C não quer saber do significado dos bytes com valores 128-255 (a linguagem em si baseia-se em ASCII, o resto são dados) ele limita-se a copiar esses bytes do código fonte para o objecto. O que também significa que se escreves o código em UTF-8, vais acabar com strings em UTF-8 no programa. Mas isso é um problema do programador, e o compilador de C não quer saber. Por exemplo, se um strlen("Olá mundo\n") és capaz de dar um resultado inesperado.
Já fazer um grep que conviva com mais do que um charset tem que se lhe diga..
Correndo o risco de me repetir, o suporte para Unicode, na forma de UTF-8, é apenas uma vertente do suporte para múltiplos charsets que já vem de longe.
Outra coisa que tu pareces não perceber é: seja qual o charset que escolhes, tens de ser utilizado consistemente através do sistema. Os nomes no filesystem são apenas sequências de bytes como as que descrevi no principio. O que importa é a interpretação que as aplicações fazem dessas sequências de bytes.
Já agora, Unicode é a implementação oficial de um charset ISO. O ISO 10646. ;-) A familia ISO 8859 não é o único charset à guarda a iso.org nem é suficiente para muitos alfabetos deste mundo.
Remember to be the Killer, not the Victim! (Nuklear Girl) |
| | | | | E o que é que defines como "plain text"? Uma boa definição (ver 7.1.2): 7.1.2 The Text/plain subtype The primary subtype of text is "plain". This indicates plain (unformatted) text. The default Content-Type for Internet mail, "text/plain; charset=us-ascii", describes existing Internet practice, that is, it is the type of body defined by RFC 822. "text/xml" não é Plain Text, porque está "encodado" com tags. Como UTF-8 usa "tags" para compactar strings, não deveria, em tese, ser considerado "text/plain", mas sim "text/UTF8". Putz. Eu não acredito que vamos perder tempo discutindo um conceito primitivo, primordial, existente desde sei lá quando, que é um arquivo Plain Text! 8-P
Correndo o risco de me repetir, o suporte para Unicode, na forma de UTF-8, é apenas uma vertente do suporte para múltiplos charsets que já vem de longe.
Não, não é!! O suporte de charsets que já vem de longe não usa tags para encodar caracteres!!!, mas usa uma relação direta [valor 8 bits] <==> [caractere]. Como a especificação original UTF-8 dava pau em Unix, me veio a UTF-8, a transformation format of ISO 10646, que define ainda outro modo de encodar UTF-8. Do último link, me vem a pérola: NOTE -- actual implementations of the decoding algorithm above should protect against decoding invalid sequences. For instance, a naive implementation may (wrongly) decode the invalid UTF-8 sequence C0 80 into the character U+0000, which may have security consequences and/or cause other problems. See the Security Considerations section below. Qual deve ser o comportamento do grep, então, se ele encontrar uma seqüência ilegal na stream UTF-8? Como ele deve se recuperar da falha, quantos caracteres "futuros" devem ser ignorados, para poder continuar trabalhando? Alguns caracteres UNICODE são encodados numa seqüência de 9 bytes! UTF-8 não é charset!! É um padrão de codificação!!!
Já agora, Unicode é a implementação oficial de um charset ISO. O ISO 10646. ;-)
A definição do charset ISO 10646 é "Universal Multiple-Octet Coded Character Set". Você está afirmando que implementar um charset multi-octeto é trivial, enquanto eu afirmo que vai ser um inferno!! Durante décadas, trabalhamos com charsets de UM ÚNICO octeto...
A familia ISO 8859 não é o único charset à guarda a iso.org nem é suficiente para muitos alfabetos deste mundo.
Talvez seja por isto que a ISO tenha definido outros charsets... 8-P Veja, eu não estou criticando o uso do UNICODE como mecanismo de intercâmbio de dados (vamos definir intercâmbio de dados : troca de informações entre duas entidades distintas). Estou criticando UNICODE como forma nativa de representação de dados. Se realmente queremos charsets multi-octetos, devemos começar isto de baixo, à partir do kernel (e dos protocolos internet, pow!!!) e ir subindo. Outra solução seria que programas que realmente precisem de suporte multilingual DINÂMICO, que usem uma biblioteca específica para isto. Eu não troco a localização do meu Desktop Gnome todo dia, pow!
[]s,
Pink@Manaus.Amazon.Brazil.America.Earth.SolarSystem.OrionArm.MilkyWay.Universe |
| | | | | Enviei o post antes de corrigir uma asneira: "Como a especificação original UTF-8 dava pau em Unix". Não existe duas codificações UTF-8. A UTF-8 veio substituir a UCS2 e a UCS4, estas sim dando problemas em UNIX (o que por sinal já tava no post do raxx7)... Prometo melhorar... 8-)
[]s,
Pink@Manaus.Amazon.Brazil.America.Earth.SolarSystem.OrionArm.MilkyWay.Universe |
| | | | Nunca viste "type=text/plain; charset=utf-8" nos cabeçalhos do Email pois não?
Não, não é!! O suporte de charsets que já vem de longe não usa tags para encodar caracteres!!!, mas usa uma relação direta [valor 8 bits] [caractere]. ... Você está afirmando que implementar um charset multi-octeto é trivial, enquanto eu afirmo que vai ser um inferno!! Durante décadas, trabalhamos com charsets de UM ÚNICO octeto... Tens uma visão demasiado reduzida do mundo. Unicode/UTF-8 não são os únicos charsets multibyte suportados. man charsets..
Contudo, nunca pretendi dizer que fosse trivial. Houve probelamas com os charsets multibyte. Mas esse trabalho já vem de há bastante tempo. Não é uma coisa nova. E está suficientemente establecido para que a RH se atreva a utilizar UTF-8 por omissão.
Nota 1: o UTF-8 usa no máximo 6, não 9 bytes.
Nota 2: o grep, como a maioria do software em Unix, lida com as sequẽncias inválidas de UTF-8 byte a byte, ignorando o seu possivel significado.
Se realmente queremos charsets multi-octetos, devemos começar isto de baixo, à partir do kernel (e dos protocolos internet, pow!!!) e ir subindo. O kernel tem o suporte necessário para lidar com Unicode, na forma de UTF-8. Protocolos de Internet? Quais é que precisam de ser modificados?
Outra solução seria que programas que realmente precisem de suporte multilingual DINÂMICO Define dinâmico. Como é que lidas com a simples situação de estares a utilizar ISO-8859-15 por omissão mas depois queres lidar com texto em Hebreu? Como é que ficam os nomes dos ficheiros? O que acontece se fizeres um cat de um ficheiro em Hebreu no terminal? A resposta é: acontece merda.
Remember to be the Killer, not the Victim! (Nuklear Girl) |
| | | | | Nunca viste "type=text/plain; charset=utf-8" nos cabeçalhos do Email pois não? Já vi gambiarras piores... 8-)
Tens uma visão demasiado reduzida do mundo. Unicode/UTF-8 não são os únicos charsets multibyte suportados.
Ok, ok, ok. Isto aqui tá chegando perto de um Troll, mas vamos em frente. Por favor, liste os charsets multiOCTETOS que vc conhece, com ênfase naqueles cujos caracteres possuem tamanho variável, ou seja, tamanhos não homogêneos. Melhor ainda : caracteres cujos tamamhos possam ser 1, 2, 3, 4, 5 ou 6 octetos (se bem que minha documentação diz que pode chegar à 9).
man charsets...
Ok. Lendo man charsets: "Unicode (ISO 10646) is a standard which aims to unambiguously represent every known glyph in every human language. Unicode's native encoding is 32-bit (older versions used 16 bits)." "Linux represents Unicode using the 8-bit Unicode Transfer Format (UTF-8). UTF-8 is a variable length encoding of Unicode." "For ISO-8859-1 users this means that the characters with high bit set now are coded with two bytes."
Não é uma coisa nova. E está suficientemente establecido para que a RH se atreva a utilizar UTF-8 por omissão.
A tradição de estabilidade da Red Hat é conhecida desde o GCC 2.96... 8-D Mas não estou questionando a estabilidade da solução. Estou questionando a necessidade.
Nota 1: o UTF-8 usa no máximo 6, não 9 bytes.
As referências que enviei dizem o contrário. Por favor, indique links que suportem o que vc diz.
Nota 2: o grep, como a maioria do software em Unix, lida com as sequẽncias inválidas de UTF-8 byte a byte, ignorando o seu possivel significado.
Eu não sei se vc está trollando, ou realmente não entende o que eu digo... Se o UTF-8 possui tamanho variável de caracteres (em octetos) - podendo chegar à 6 bytes, de acordo com você; até 9, de acordo com a referência que forneci - como vc pode garantir que somente os bytes certos devem ser ignorados? Vale a pena reescrever todos os parsers para que possam lidar com várias formas diferentes de se escrever a mesma seqüêndcia de caracteres? Além do mais, de que me vale um programa que simplesmente ignora o significado dos dados? Se há um erro, eu quero que ele seja reportado!!!
O kernel tem o suporte necessário para lidar com Unicode, na forma de UTF-8.
E no que isto ajuda todos os programas que manipulam texto usando char var[]? Dar suporte simplesmente não metendo o bedelho não chega à ser suporte, IMHO...
Protocolos de Internet? Quais é que precisam de ser modificados?
Pra começar, o SMTP. Mas veja por você mesmo (granted, nem todos os links são à meu favor).... Caso vc não saiba, toda a infraestrutura de Internet foi construída em cima do ASCII 7 bits. Ainda hoje há SMTPs não transferem 8 bits (quase todos nos EUA), motivo pelo qual ainda se recomenda que se use MIME quoted printable nos emails. Granted, esta barbaridade toda precisa ser corrigida de qualquer jeito, não importa se eu tenho razão (chars de 8 bits) ou você (chars de 32 bits, encodados usando UTF-8).
Define dinâmico.
O que não é estático... 8-P Um exemplo suporte multi-lingual dinâmico (ou seja, aquele que pode mudar on the fly) é o do Windows, onde pode-se instalar suporte para mais de uma língua e comutar usando Alt+Shift. Um exemplo de suporte multi-lingual estático : A interface do Windows (menus, dialogs, etc), nas mesmas condições. O Menu "Iniciar" não vira "Start" quando ativo o suporte à língua inglesa, tampouco para "Anfang" quando estou estudando Alemão....
Como é que lidas com a simples situação de estares a utilizar ISO-8859-15 por omissão mas depois queres lidar com texto em Hebreu?
Ativo o suporte para Hebreu na aplicação que dê suporte para múltiplos charsets, ué. No Windows, funciona... ;-) Mas neste caso concordo que UNICODE é a melhor saída.
Como é que ficam os nomes dos ficheiros? O que acontece se fizeres um cat de um ficheiro em Hebreu no terminal? A resposta é: acontece merda.
Só acontece merda se o cara não configurar o charset dele para Hebreu Você define prioridades de forma interessante : para provar que um recurso é necessário para a maioria das pessoas, dá exemplos que são válidos para uma minoria. Pessoas que escrevem em Hebreu tendem à usar suporte em Hebreu em suas máquinas. Pessoas que escrevem em Alemão tendem à usar suporte em Alemão em suas máquinas. Granted, existe a possibilidade que algumas pessoas na Alemanha precisem escrever nomes de ficheiros em Hebreu. Façamos o seguinte : prove seu ponto de vista me dizendo quantas destas acima vc conhece, e depois compare com quantas vc conhece que não precisam. Se vc for honesto, você perceberá que não são muitas. Trate o caso comum de forma corriqueira, e as exceções como exceções. Onde foi que eu li isto mesmo??? Ahh.. sim... Filosofia Unix. ;-)
Teremos um papo mais produtivo se discutirmos minha opinião, ao invés de nos digladiarmos com tecnicismos. Que tal você reler meu post original e começarmos de novo? ;-)
[]s,
Pink@Manaus.Amazon.Brazil.America.Earth.SolarSystem.OrionArm.MilkyWay.Universe |
| | | | | Na verdade tens de pensar assim: se eu quero obter os ados do ficheiro "dá-lhe.gás", como é que eu o abro. E se o nome desse ficheiro vier de um campo de texto GTK+ (em UTF8), que conversões terei de fazer (e lá vem o iconv à baila). Se tudo estiver em UTF-8, não tens esse problema. Mas se su usar apenas caracteres não acentuados, o UTF-8 representa-os apenas em um byte. E aí reside a sua eficiência. No tempo em que as máquinas já adoptaram ou passam mesmo os 32 bit, excepto as máquinas embutidas, que razões tempos para ter ainda cadeias de texto a 8 bit, delegando para as calendas gregas a adaptabilidade do programa que escrevemos? Por isso, adopto já hoje o Unicode. Metade das minhas aplicações são anglófonas e nunca serão, provavelmente, traduzidas. Mas a infraestrutura está lá. Confesso que deixar de uma vez de usar o malvado iconv(3) é razão só por si. Francisco Colaço
|
| | | Nah (Pontos:3, Esclarecedor) |
| | Até agora acho que a mudança para unicode por defeito no Red Hat só veio fazer com que ficasse sem acentos na consola (já acontecia no 8 e acontece ainda no 9). Acredito que possa trazer vantagens mas ainda não funciona bem, mesmo em X tudo quanto não seja GTK2 e QT não vai lá muito à bola com unicode (experimentem usar a interface GTK do licq e vão saber o que estou a dizer).
Seria bom ter suporte generalizado para UTF-8, mas por enquanto só trás problemas, acho que é cedo para que seja o locale por defeito mas como é, só me resta mudá-lo eu para iso8859-15.
-- Carlos Rodrigues
|
| | | | | | Foi uma das razões porque abandonei o redhat já há alguns anos e passei para o mandrake, os gajos não se preocupam com o people em PT.
Quem ainda não experimentou o MDK 9.1, tá demais, tanto a nível de eye candy como a nível de definições para português,acentos, símbolo do Euro, etc, isto em kde,gnome,consola,openoffice,mozilla. pretty sweet. :)
experimentem o karamba.
|
| | | | | Sim, eu sou chato, eu sei! 8-) Para evitar mal entendidos, caso alguém leia esta thread no futuro, vou citar alguns trechos do Livro Unicode Demystified, de Richard Gillam, que para os que não sabem, trabalhou na IBM, Taligent e foi um dos designer do ICU e das classes Java para internacionalização (e também um Membro Especialista do Consórcio UNICODE). Espero que concordem comigo que o cara sabe do que fala. First, Unicode is a standard scheme for representing plain text in computers and data communications. Isto é óbvio. Interessante é a definição ("slippery", ele admite, mas consistente com o resto do livro) de Plain Text do cara : The basic rule is that plain text contains all of the information necessary to carry the semantic meaning of the text - the letters, spaces, digits, punctuation, and so forth. If removing it would make the text unintelligible, then it's plain text.. Por tabela, mas aqui eu falo por mim mesmo, se eu adiciono elementos que tornem o text "unintelligible", ele deixa de ser Plain Text. UTF-8 não é inteligível. a seqüência de caracteres UTF-8 "Maçã" definitivamente não se parece com o a seqüência de caracteres ISO-8859-15 "Maçã". Logo, UTF-8 não é Plain Text. Descubra por si mesmo. Mais uma coisa... A representação U+123456 (e sim, é aqui que pode ter de 4 a no máximo 6 octetos, RTFM raxx7!!!) é chamada "Standard Unicode Notation".
Unicode also ins't a complete solution for software internacionalization. Software internacionalization is a set of design practices that lead to software that can be adapted for various international markets ("localized") without having to modify the executable code. The Unicode standard in all of its details includes a lot of stuff, but it doesn't include everything necessary to produce internacionalized software. In fact, it's perfectly possible to write internacionalized software without using Unicode at all; conversely, it's perfectlyu possible to write completely non-internacionalizable software that uses Unicode Em resumo, UNICODE NÃO É INTERNACIONALIZAÇÃO. Seus programas não passarão automaticamente à escrever da direita para a esquerda quando usarem as rotinas de suporte ao UNICODE que, um dia, existirão na LIBC.
Finally, Unicode isn't a glyph registry. Esta é a mais importante na nossa discussão. Aqui afirma com todas as letras de que Unicode não é um charset. Sem glyphs, sem charsets - de que adianta um charset que não possui informações para visualizar nada? Enquanto nossos hardwares não suportarem caracteres de 16 ou mesmo 32 bits (as VGAs, no máximo, usam 9 através de um truque sacana, que usa um dos bits de cores como seletor de charset), suporte nativo pleno à Unicode no console é sonho. Uma vez que as boxes com placas VGA-like podem mostrar 512 glyphs (ou 2 charsets) simutâneos, mostrar textos multilinguais (i.e.: com mais de 2 charsets) é inviável. O que acontece se eu der um cat num arquivo com textos em mais de duas línguas no console? Dá merda. O que acontece se eu nomear ficheiros com caracterers de 3 línguas, ou listar no mesmo diretório 3 ficheiros, cada um com glyphs de uma língua diferente? Dá merda. Então de que me vale ter suporte nativo Unicode no kernel e no console? Até que o kernel dê suporte pleno para Unicode (32 bits), e se crie rotinas para que o console possa "traduzir" os caracteres UNICODE para os dois charset disponíveis em boxes com hardware VGA, isto pra não falar nos outros tipos de display disponíveois por aí, eu simplesmente não vejo vantagem nenhuma em "unicodizar" todas as strings do sistema!! E quem tiver coragem, que peça pro Linus tirar o suporte para console modo texto do kernel - que seria uma forma de adicionar suporte pleno ao Unicode no kernel sem os problemas que descrevo no parágrafo anterior. Há computadores sem modo texto por aí. Por fim : K.I.S.S. (Keep It Simple Stupid).
[]s,
Pink@Manaus.Amazon.Brazil.America.Earth.SolarSystem.OrionArm.MilkyWay.Universe |
| | | | | No uso quotidiano como workstation, quais as consequências na utilização de ficheiros de texto, LaTeX, sources, shell scripts, etc, anteriormente criados em ISO-8859-1? Deverá haver uma camada de conversão UTF-8 -> ISO-8859-1 ou seja lá o charset que será carregado para mostrar texto no console. Como o hardware disponível hoje só permite mostrar 256 ou 512 caracteres simultâneos, não vejo vantagem nenhuma, hoje, em adotar UTF-8 neste caso. Veríamos exatamente o que já vemos, com a agravante de termos uma camada extra de software entre o programa e o que é efetivamente visualizado no console. Por outro lado, se todo mundo adotar Unicode 32 bits (inclusive o kernel) para o que chamamos hoje de caractere, é uma questão de tempo até que uma solução adequada para o console seja implementada - talvez em software, talvez em hardware. Mas esta solução joga por terra qualquer compatibilidade reversa com o padrão VGA de modo texto que temos hoje.
Na vertente server, qual o impacto a nível de file-sharing com máquinas Windows [...] quer a nível de samba, quer através de FTP?
Se as aplicações servidoras adotarem Unicode 32 bits como unidade básica de informação (caractere para os íntimos), a adequação às características do cliente é trivial. É apenas um filtro, pouca coisa mais complicada que o que é feito hoje pelo Samba. Aliás, esta solução é recomendada pelo Richard Gillam (vcs conhecem??? ;-) Só adotar UTF-8 não vai resolver nada, pelo contrário. Serão filtros para converter o que vem do cliente para algo que o servidor entenda (UTF8 -> native charset), que por sua vez terá algoritmos de manipulação de strings extremamente complexos (já que manipular diretamente UTF-8 é o mesmo que tentar manipular uma BMP RLE sem descomprimi-la primeiro) para, depois, converter de volta para algo que o cliente entenda. UTF-8 não é uma solução nativa viável para este empreendimento. Mas UTF-8 é uma excelente solução para strings Unicode "platform independent". A RFC XDR deveria ser revisada, tornando UTF-8 um tipo de dados de rede.
O modo de transferência ASCII, ao tratar a questão CR-LF, tornava tranparente a transferência de ficheiros "texto" entre SOs com diferentes convenções. E com Unicode?
À menos que redefinamos o padrão ASCII, tudo o que acontecerá é que strings UTF-8 serão "achatadas" para ASCII-7 bits (ASCII-8 somente se for possível especificar para qual charset deve-se converter) no cliente e no servidor antes de trafegarem pela rede. Não vejo como resolver este imbróglio, exceto adotando o UTF8 na XDR, ou então definirmos um charset "padrão" na camada de rede - o que tornaria Unicode inútil .
Qual o impacto noutro tipo de serviços?
Serviços de dados binários não sofrerão nenhum impacto, obviamente... 8-P Mas serviços de dados textuais deverão ser reescritos para suportar caracteres Unicode de 32 bits. É muito, mas muito inviável lidar diretamente com dados compactados, mesmo usando um algoritmo simples como o Run Length Encoded.
[]s,
Pink@Manaus.Amazon.Brazil.America.Earth.SolarSystem.OrionArm.MilkyWay.Universe |
| |
|
