Atualmente, é promovido e desenvolvido pela Unicode Consortium, uma organização sem fins lucrativos que coordena o padrão, e que possui o objetivo de um dia substituir esquemas de codificação de caractere existentes pelo Unicode e pelos esquemas padronizados de transformação Unicode (chamado Unicode Transformation Format, ou UTF). Seu desenvolvimento é feito em conjunto com a Organização Internacional para Padronização (ISO) e compartilha o repertório de caracteres com o ISO/IEC 10646: o Conjunto Universal de Caracteres (UCS). Ambos funcionam equivalentemente como codificadores de caracteres, mas o padrão Unicode fornece muito mais informação para implementadores, cobrindo em detalhes tópicos como ordenação alfabética e visualização.
O Unicode possui o objetivo explícito de transcender as limitações de codificações de carácter tradicionais, como as definidas pelo padrão ISO 8859, que possuem grande uso em vários países mas que permanecem em sua maioria incompatíveis umas com as outras. Várias codificações de carácter tradicionais compartilham um problema comum, ao permitirem processamento bilíngue (geralmente usando caracteres romanos e a língua local), mas não processamento multilíngue (processamento de línguas arbitrárias misturadas umas com as outras).
O Unicode codifica os caracteres em si - grafemas e unidades tais como grafemas - em vez de codificar glifos variantes para tais caracteres. No caso de caracteres chineses, essa estratégia geralmente leva a controvérsias quanto à distinção entre um caractere e seus glifos variantes.
Na área de processamento de texto, o Unicode possui o papel de fornecer um único código - um número e não um glifo - para cada carácter. Em outras palavras, o Unicode representa um carácter em uma forma abstrata e deixa questões sobre renderização (como tamanho, forma, fonte ou estilo) para outro software, como um navegador ou um editor de texto. Esse simples objetivo torna-se complicado pelas concessões feitas pelos desenvolvedores do padrão a fim de encorajar uma adoção mais rápida.
Os 256 primeiros códigos Unicode são idênticos aos do padrão ISO 8859-1, de forma que é trivial converter texto ocidental existente. Diversos caracteres idênticos foram codificados múltiplas vezes em diferentes códigos para preservar distinções usadas por codificações legadas, permitindo assim a conversão de tais codificações para Unicode e vice versa, sem perder qualquer informação. Da mesma forma, enquanto o Unicode permite combinar caracteres, ele também codifica versões pré-compostas da maioria das combinações mais comuns de letra/diacrítico. Por exemplo, o carácter "é" pode ser representado por U+0065 (letra latina "e" minúsculo) combinado com U+0301 (diacrítico "acento agudo"), mas também pode ser representado como U+00E9 (letra latina "e" com diacrítico "acento agudo").
O padrão ainda inclui outros itens relacionados, como propriedades de caracteres, formas de normalização de texto e ordem bidirecional de visualização (para a correta visualização de texto lido da direita à esquerda, como em língua árabe ou hebraica).
Quando se escreve sobre um carácter Unicode, normalmente se usa-se "U+" seguido de um número hexadecimal que indica o código do carácter.
Origem e desenvolvimento
Entre 1986 e 1987, iniciou-se na Xerox o trabalho de construção de um banco de dados para mapear o relacionamento entre caracteres idênticos dos alfabetos japonês, chinês tradicional e chinês simplificado, a fim de construir uma fonte tipográfica para caracteres chineses estendidos. O grupo de funcionários envolvidos incluía Huan-mei Liao, Nelson Ng, Dave Opstad e Lee Collins. Até então, os utilizadores da Xerox usavam JIS para estender o conjunto original de caracteres chineses. Na mesma época, na Apple Inc. se iniciou a discussão sobre um conjunto universal de caracteres. O grupo da Xerox começa uma discussão sobre questões multilíngues com Mark Davis, da Apple. Já em dezembro de 1987 é registrado o primeiro uso documentado do termo "Unicode".
A partir de 1988 começam discussões sobre uma largura fixa ou variável de bytes para a representação dos códigos, e uma das primeiras propostas é o sistema de Davis com uma largura fixa de 16 bits com o nome "High Text", em oposição a "Low Text" para o padrão ASCII. Nos estudos são levados em conta comparações entre o acesso de texto em largura fixa e variável, investigações sobre os requisitos para se utilizar 16 bits em sistemas computacionais e uma estimativa inicial de contagem de todos os caracteres existentes, para definir se 16 bits seriam mesmo o suficiente.[4]
Em abril, os primeiros protótipos começaram a ser construídos na Apple, decidindo-se incorporar suporte ao padrão no TrueType, o padrão de fontes tipográficas da empresa.
Em janeiro de 1989 a Metaphor decide implementar uma codificação 16-bit para suportar internacionalização em seu conjunto de software. Nos meses seguintes, as freqüentes reuniões do grupo Unicode contam com a presença de representantes de empresas como Metaphor, Sun, Adobe, HP e NeXT. Tais reuniões evoluíram até o comitê técnico do Unicode, com a formação da Unicode Consortium dois anos após.
Em setembro, o grupo decide usar padrões ISO já existentes para ordenações de sistemas de escrita e nomeação de esquemas. No mês seguinte, o padrão é apresentado para a Microsoft e a IBM, em conjunto com a cooperação entre Apple e Microsoft com o TrueType. O padrão também foi apresentado ao grupo de internacionalização do Unix.
A partir do início de 1990, a Microsoft começa a participar das reuniões do Unicode. Em junho é a vez da IBM começar a participar mais ativamente. No mesmo ano é iniciado o trabalho para a formação de um consórcio ao padrão. Em 3 de janeiro de 1991 a Unicode Consortium é fundada, como Unicode, Inc. na Califórnia, Estados Unidos. No dia 25 é realizada a primeira reunião dos membros, e ainda em janeiro é formado o comitê técnico Unicode. No mês seguinte, um dos primeiros artigos sobre o Unicode aparece no New York Times.[5] Atualmente, qualquer empresa ou pessoa disposta a pagar os custos de associação pode se tornar membro da organização; os membros incluem, virtualmente, todas as principais empresas de software e hardware interessadas em padrões de processamento de texto, tais como Adobe Systems, Apple, Google, HP, IBM, Microsoft e Xerox. Outras instituições incluem a Universidade de Berkeley, o governo da Índia e o governo do Paquistão.[6]
Sistemas de escrita suportados
O Unicode cobre quase todos os sistemas de escritas em uso atualmente, incluindo:
Apesar de mais de trinta sistemas de escrita serem incluídos no Unicode, ainda restam outros por codificar. Novas adições de caracteres para sistemas já codificados também ocorrem, tais como símbolos matemáticos e musicais. Michael Everson, Rick McGowan e Ken Whistler mantêm uma lista de tais sistemas e um rascunho de codificação na página oficial do Unicode Consortium.[7] Para alguns sistemas já adicionados ao rascunho de desenvolvimento, propostas de codificação são feitas até que se encontre um consenso que leve à aprovação. Para outros sistemas, não são feitas propostas até que comunidades acadêmicas envolvidas aprovem o repertório de caracteres e outros detalhes.
Entre os sistemas de escrita esperando codificação, estão os hieróglifos egípcios, fenícios, e maias, além do alfabeto babilônico e outros de caráter cuneiforme.
Outros sistemas de escrita
O padrão adicionou outros sistemas de escrita e cobrirá mais, incluindo sistemas históricos ou extintos usados primordialmente pela academia, tais como:
O armazenamento dos códigos Unicode no processamento de texto apresenta o desafio de a maioria dos programas de computador escritos no mundo ocidental utilizar somente codificações de 8 bits — 1 byte — (como o padrão ASCII), já que o suporte ao Unicode começou somente nos últimos anos. Similarmente, na representação de sistemas de escrita asiáticos, o modelo baseado em ASCII de caracteres de 2 bytes não pode mesmo em teoria codificar mais que 32 768[8] caracteres e, na prática, as arquiteturas impõem limites ainda menores. Tais limites são insuficientes mesmo só tendo em conta as necessidade de acadêmicos da língua chinesa.
A lógica interna de muitos programas legados tipicamente permite somente 8 bits para cada caractere, tornando impossível o uso de mais de 256 códigos[9] sem processamento especial. Programas 16-bit suportam somente dezenas de milhares de caracteres. Por outro lado, o Unicode já definiu pouco mais de 107 mil caracteres codificados. Desenvolvedores de sistemas já sugeriram diversos mecanismos para implementar o padrão; a escolha de cada um depende do espaço de armazenamento disponível, compatibilidade de código fonte e interoperabilidade com outros sistemas.
O Unicode define dois métodos de mapeamento de códigos Unicode em códigos de implementação, UTF (Formato de Transformação Unicode, do inglês Unicode Transformation Format) e UCS (Conjunto Universal de Caracteres, do inglêsUniversal Character Set). Os números associados aos nomes dos mapeamentos indicam o número de bits por código (no caso de UTF) ou o número de bytes por código (no caso de UCS). UTF-8 e UTF-16 são possivelmente as mais usadas.
A UTF-7 é uma codificação não tão popular usada para a codificação em 7 bits, e é normalmente considerada obsoleta. Pode ser usada quando há restrições a caracteres com o oitavo bit ligado; por exemplo, quando só se podem usar caracteres ASCII válidos. Não faz parte do padrão, sendo apresentada apenas como uma recomendação. Já a UTF-EBCDIC possui largura variável e maximiza a compatibilidade com EBCDIC, mas também não faz parte do padrão.
Por outro lado, a UTF-8 é uma codificação bastante utilizada, e que maximiza a compatibilidade com ASCII. Utiliza entre um e quatro bytes por código e, sendo compacta para o sistemas latino e compatível com ASCII nos códigos até 127, fornece um padrão de facto de codificação para a conversão de textos para o formato Unicode. É usada pelas mais recentes distribuições Linux como uma substituta para codificações legadas na manipulação de texto. A UTF-8 representa uma forma de otimizar o espaço alocado para textos Unicode. Considerando por exemplo um texto escrito em língua inglesa, percebe-se que raramente são utilizados caracteres fora do escopo do ASCII, isto é, os primeiros 127 códigos Unicode. Isso significa que se for utilizada uma codificação de largura fixa de 16 bits, o segundo byte de cada carácter muito provavelmente estará vazio, nulo, inutilizado. Para arquivos grandes a sobrecarga desse espaço inútil alocado passa a ser relevante. Tendo uma largura variada, o UTF-8 define que caracteres ASCII são representados com somente um byte. Além de otimizar o espaço alocado no caso de caracteres ASCII, isso garante a paridade entre ASCII e UTF-8, facilitando a tradução de texto ASCII legado para o Unicode. Uma propriedade adicional do UTF-8 diz respeito ao truncamento de cadeias de caracteres Unicode. Alguns códigos (predominantemente legados) de processamento de cadeias de caracteres definem que um único byte nulo (0x00) representa o fim da cadeia. Como visto anteriormente, num texto Unicode de largura fixa de 16 bits, o segundo byte de cada carácter é frequentemente nulo em textos latinos. Isso é interpretado incorretamente como o final da cadeia de texto, problema que não acontece com o UTF-8 devido a otimização do espaço eliminando-se os tais caracteres nulos.
No campo de codificações 16-bit, a UCS-2 é uma codificação de largura fixa que suporta somente o plano básico de línguas, considerado obsoleto. Não faz parte do padrão. Já a UTF-16 é uma codificação 16-bit de largura variável. Ela pode incluir uma ou duas palavras 16-bit para suportar outros caracteres. É usada por várias API, freqüentemente por compatibilidade com códigos desenvolvidos quando o Unicode era baseado em UCS-2. A UTF-16 é o padrão de codificação para a API do sistema operacionalMicrosoft Windows, da linguagem de programaçãoJava (J2SE, desde a versão 1.5) e dos ambientes .NET. Para caracteres do plano básico de línguas do Unicode, a UCS-2 e a UTF-16 são idênticas. Tanto UCS-2 quanto UTF-16 especificam a marca de ordem de byte (BOM) para ser usada no começo dos arquivos de texto, uma técnica que pode ser usada para a detecção do endianamento de acordo com a arquitetura. Alguns desenvolvedores adotaram a técnica em outras codificações; como no UTF-8, que apesar de não precisar da indicação da ordem do byte, usa a técnica para marcar o texto como sendo Unicode. O BOM é representado pelo código Unicode U+FEFF, e possui a propriedade de desambiguar a ordenação de bytes, independente da codificação Unicode usada. O resultado da má interpretação do endianamento é U+FFFE, um código ilegal. Portanto, o sistema que ler o texto Unicode saberá que deve permutar os bytes se o BOM assim indicar. O código U+FEFF em outros locais do texto senão o início é convertido num símbolo sem aparência nem efeito no texto senão o de prevenir ligaduras tipográficas. Também, as unidadesFE eFF nunca aparecem em UTF-8. O mesmo carácter convertido para UTF-8 torna-se a sequênciaEF BB BF. Entretanto, nem todo texto Unicode possui o BOM.
A UTF-32 é uma codificação 32-bit de largura fixa amplamente usada na representação interna de texto em programas (não durante armazenamento ou transmissão), já que todo sistema operacional Unix que utiliza os compiladoresGCC para gerar executáveis utiliza UTF-32 como o padrão de codificação wide character. Versões recentes da linguagem de programação Python (desde 2.2) também podem ser configuradas para usar UTF-32 como a representação de Unicode para cadeias de caracteres. A UCS-4 fornece funcionalidade equivalente ao UTF-32, ainda que não faça parte do padrão. Codificações de 32 bits garantem a representação de todos os códigos Unicode sem qualquer tipo de transformação, mas ocupam bastante espaço de armazenamento.
Há também diversas outras codificações disponíveis, algumas delas que representam somente partes de todo o padrão Unicode, como o Windows-1252 (europeu ocidental) e o ISO-8859-1 (Latin-1). Por outro lado, os UTF possuem a capacidade de armazenar todos os códigos Unicode. Para outros subconjuntos do padrão, ver a seção "Subconjuntos padronizados" abaixo.
Caracteres pré-compostos e caracteres combinados
O Unicode inclui um mecanismo para modificar o formato de caracteres, estendendo o repositório de glifos suportados. Isso cobre o uso de combinação de marcas diacríticas, o que permite que uma letra seja combinada com um acento, por exemplo. Entretanto, por questões de compatibilidade, o padrão também inclui uma quantidade considerável de caracteres pré-compostos, associando o símbolo de uma letra combinada com um acento em um código distinto ao código da letra e ao código do acento. Para vários casos, o utilizador possui várias maneiras de codificar o mesmo caractere. Para padronizar essas opções, o padrão ainda fornece um mecanismo de equivalência canônica.
Um exemplo é o Hangul, o alfabeto coreano. O Unicode fornece um mecanismo para compor sílabas Hangul com seus subcomponentes individuais, conhecidos como Hangul Jamo. Entretanto, o padrão também fornece todas as 11 172 combinações de sílabas Hangul pré-compostas.
Os ideogramas chineses, japoneses e coreanos possuem atualmente códigos apenas para suas formas pré-compostas. Entretanto, a maioria dos ideogramas possuem e combinam elementos mais simples, radicais, que o Unicode poderia decompor, tal como acontece com o Hangul. Tentativas para decompor ideogramas não foram bem sucedidas pois o processo não é tão simples e regular como se esperava.
Ligaduras
Como em árabe e o devanagari, vários sistemas de escrita possuem regras ortográficas especiais que requerem que certas combinações de letras sejam feitas por ligaduras tipográficas. As regras de formação de ligaduras podem ser complexas, requerendo tecnologias especiais de formatação de texto como o OpenType (da Adobe e Microsoft), Graphite (da SIL International) ou AAT (da Apple Inc.). Instruções também são embarcadas em fontes para informar o sistema operacional quanto à impressão correta de diferentes sequências de caracteres.
Uso em diversos sistemas
Sistemas operacionais
O Unicode tornou-se o esquema predominante para o processamento interno de texto, e por vezes também para o armazenamento (apesar de muitos textos ainda estarem armazenados em codificações legadas). As primeiras implementações usavam predominantemente UCS-2, mudando posteriormente para UTF-16 (já que esta codificação é a mais compatível para suportar caracteres fora do plano básico). O sistema mais conhecido nessa situação foi o Windows NT (e seus descendentes Windows 2000 e Windows XP). Os ambientes de bytecode das plataformas Java e.NET, o sistema operacional Mac OS X e o ambiente gráfico KDE também usam o UTF-16 para a representação interna.
O UTF-8 (originalmente desenvolvido para o Plan 9) tornou-se a principal codificação para a maioria dos sistemas operacionais Unix-like por ser um substituto simples dos conjuntos de caracteres estendidos do ASCII.
Correio eletrônico
Definido como o padrão da Internet para a extensão do correio eletrônico, o MIME define dois mecanismos diferentes para a codificação de caracteres não ASCII em e-mails, dependendo de como os caracteres estão no cabeçalhos das mensagens, como no campo "assunto", ou no corpo da mensagem. Em ambos os casos, o conjunto original de caracteres é identificado assim como uma codificação de transferência. Para a transmissão de e-mail Unicode, a codificação de caracteres UTF-8 e a codificação de transferência Base64 são recomendadas. O Base64 garante uma transmissão segura mesmo para servidores de e-mail legados de 7-bit ainda em operação. Caso a mensagem esteja codificada em UTF-7, a codificação de transmissão não é necessária para servidores 7-bit.
Vários aplicativos clientes de correio eletrônico possuem suporte a Unicode no corpo das mensagens. Entretanto, a maioria não envia a mensagem em Unicode por padrão, e poucos sistemas são configurados para exibir todo o repertório do padrão.
O suporte Unicode para o cabeçalho de e-mails é mais problemático, pois diversos padrões devem ser usados para lidar com dados que não sejam ASCII. O RFC 2047 fornece suporte para a codificação não ASCII dos campos "assunto" e "nome real". O RFC 3490 fornece suporte para a codificação do domínio do endereço de e-mail (a parte posterior ao "@"). O nome da caixa de e-mail (a parte anterior ao "@") é limitado a um sub-conjunto de caracteres ASCII visíveis, assim como definido pelo RFC 2822.
No suporte Unicode para o corpo de e-mails, mensagens HTML podem usar entidades HTML para usar qualquer caractere Unicode mesmo que a codificação do e-mail está num padrão legado. Para mensagens em texto puro, deve-se usar MIME para especificar uma codificação.
World Wide Web
Os navegadores já suportam diversas sub-codificações UTF há vários anos, especialmente UTF-8. Os problemas de visualização derivam principalmente de questões relacionadas a fontes tipográficas. Num caso particular, o Internet Explorer não imprime na tela diversos códigos Unicode exceto quando é indicado explicitamente qual a fonte que contém os símbolos.
Todas as recomendações W3C (a organização que padroniza a WWW) usam o Unicode como o conjunto de caracteres de documentos desde o HTML 4.0, sem um método de mapeamento específico; anteriormente utilizava-se o conjunto ASCII 6-bit ISO-8859-1.
Apesar de regras sintáticas poderem afetar a ordem em que os caracteres podem aparecer, por definição tanto documentos HTML quanto XML (incluindo o XHTML) suportam caracteres da maioria dos códigos Unicode, exceto pela maioria dos códigos de controle C0 e C1, o bloco de código D800-DFFF e qualquer código que termine em FFFE ou FFFF.
Os caracteres são armazenados em XML e HTML na forma binária do código Unicode (desde que a codificação em uso suporte o código). Alternativamente, pode-se armazená-los como referências numéricas baseadas no seu respectivo código, seguindo o formato &#valor; (no qual "valor" é o código em notação decimal) ou &#xvalor; (código em notação hexadecimal; note o "x" antes do valor);
Por exemplo, as referênciasΔ,Й,ק,م,๗,あ,叶,葉 e냻 são visualizadas nos navegadores respectivamente como Δ, Й, ק, م, ๗, あ, 叶, 葉 e 냻. Se as fontes apropriadas existem, tais símbolos aparecem respectivamente como a letra maiúscula grega "delta", a letra maiúscula cirílica "I curta", a letra árabe "Meem", a letra hebraica "Qof", o numeral tailandês 7, o hiragana japonês "A", a letra do chinês simplificado "folha", a letra do chinês tradicional "folha" e a sílaba hangul "Nyaelh".
Outro formato para representar caracteres Unicode são as entidades de caractere, um texto que "apelida" um determinado código do padrão. Por exemplo,—, assim como— ou—, representa o código U+2014, o caractere "—".
Em requisições HTTP, as URL são codificadas obrigatoriamente usando o prefixo "%", geralmente em UTF-8 para representar Unicode.
Fontes tipográficas
Tanto os padrões TrueType quanto OpenType suportam Unicode, tornando comum a existência de fontes baseadas nessa codificação. Tais formatos de fontes mapeiam códigos Unicode em glifos. Diversas fontes existem no mercado, mas muito poucas suportam a maioria dos códigos Unicode. Fontes Unicode geralmente focam o suporte a ASCII (o básico) e um conjunto particular de códigos, isto é, um conjunto particular de sistema de escrita. O motivo para tal é a falta de uma aplicação para a visualização de um grande conjunto de códigos (um programa de computador que contém diversos sistemas de escrita juntos), a quantidade de recursos que as fontes usam do sistema computacional e o fato de os sistemas operacionais e aplicações possuírem inteligência suficiente para obter informação de um glifo a partir de um arquivo diferente se necessário (por exemplo, usando substituição de fontes). A tarefa de desenvolver um conjunto consistente de instruções de visualização para dezenas de milhares de glifos é árdua.
Subconjuntos padronizados
Diversos subconjuntos do Unicode são padronizados: o Microsoft Windows suporta desde a versão NT 4.0 o WGL-4 com 652 caracteres, que representa todas as línguas européias contemporâneas usando os sistemas de escrita latino, grego ou cirílico. Outros conjuntos padronizados incluem os subconjuntos multilinguais europeus: MES-1 (sistemas latinos somente, 335 caracteres), MES-2 (sistemas latinos, grego e cirílico, 1063 caracteres)[10] e MES-3A & MES-3B. Note que o MES-2 inclui todo o MES-1, que por sua vez contém todo o WGL-4.
Quando o programa de computador de visualização não puder visualizar e processar o código Unicode corretamente, geralmente, imprime somente um retângulo, uma área em aberto ou o caractere Unicode de substituição (U+FFFD, �), para indicar que o caractere não é reconhecido. Alguns sistemas tentam retornar mais informações sobre os caracteres não reconhecidos. A fonte LastResort da Apple imprime um glifo substituto indicando o bloco Unicode do caractere. Já a fonte Unidode da SIL imprime uma caixa com o valor hexadecimal do caractere.
Métodos de entrada
Por questões evidentes, um teclado de computador não pode ter uma tecla distinta para cada caractere Unicode existente: sua superfície teria que ser muito grande, tornando-o inutilizável. Por isso, diversos sistemas operacionais fornecem alternativas para digitar qualquer código do repertório Unicode.
No Microsoft Windows (desde a versão 2000), o utilitário "Mapa de Caracteres" fornece controles de edição para toda tabela até U+FFFF. Programas de processamento de texto como o Microsoft Word possuem um controle similar embarcado, através de inserção de símbolo. Quando se sabe o código desejado, pode-se simular a digitação de um caractere Unicode através da combinação Alt+++#, no qual # representa o código hexadecimal até FFFF. Por exemplo, Alt+++F+1 produzirá o caractere "ñ". Esse método também funciona em vários outros aplicativos Windows, mas não em aplicações que usam o controle de caixa de edição padrão do sistema.
Utilizadores do Apple Macintosh possuem uma funcionalidade similar, no Mac OS X e no Mac OS 8.5 ou superior: Option+#, no qual # é o código Unicode em hexadecimal de quatro dígitos.
O ambiente gráfico GNOME fornece um utilitário tal qual o "Mapa de Caracteres" que mostra os caracteres ordenados pelo bloco Unicode ou pelo sistema de escrita. Quando sabe-se o código desejado, a produção do caractere pode ser feita de acordo com a norma ISO 14755: Ctrl+Shift+#, no qual # é o código Unicode em hexadecimal. Deve-se adicionar ao código o caractere "U" caso se esteja usando a versão 2.15 ou superior.
O interpretador de comandos do Linux permite que caracteres Unicode sejam produzidos pela combinação Alt+#, em que # é o código Unicode em decimal digitado no teclado numérico. Para funcionar, o modo Unicode deve ser ativado e uma fonte suportada deve ser usada. A norma ISO 14755 (descrita acima) também é implementada.
A partir da versão 7.5 do navegador Opera, é permitido produzir caracteres Unicode diretamente do campo de texto através da combinação Alt+#.
No editor de textoVim a produção pode ser feita com a combinação Ctrl+V+u+#.
Ver também
O Commons possui uma categoria com imagens e outros ficheiros sobre Unicode
Deportivo MirandaDatos generalesNombre Deportivo Miranda Fútbol ClubApodo(s) Rojiazules ParroquialesFundación 18 de agosto de 1948 (75 años) (como Deportivo Italia Fútbol Club)Presidente Hugo SavareseEntrenador Edward AgustínInstalacionesEstadio Estadio Brígido IriarteCapacidad 9800Ubicación Parroquia El Paraíso Caracas, VenezuelaInauguración 1 de enero de 1936 (87 años)Uniforme Titular Alternativo Tercero Última temporadaLiga Segunda División de VenezuelaCopa Copa Venez...
Portuguese footballer For other people named André Santos, see André Santos (disambiguation). André Santos Santos at his Deportivo presentationPersonal informationFull name André Filipe Bernardes Santos[1]Date of birth (1989-03-02) 2 March 1989 (age 34)[1]Place of birth Sobreiro Curvo, Portugal[1]Height 1.81 m (5 ft 11 in)[1]Position(s) Defensive midfielderTeam informationCurrent team OliveirenseNumber 8Youth career1998–2000 Lourinhane...
1966 romantic adventure drama movie directed by Sidney Hayers The TrapFilm poster by Arnaldo PutzuDirected bySidney HayersScreenplay byDavid D. OsbornStory byDavid D. OsbornProduced byGeorge H. BrownStarringRita TushinghamOliver ReedCinematographyRobert KraskerEdited byTristam ConesMusic byRon GoodwinColor processColourProductioncompanyGeorge H. Brown ProductionsDistributed byRank Film DistributorsRelease date 15 September 1966 (1966-09-15) [1]Running time106 minutesCou...
LocalizaciónPaís EspañaUbicación Olmedilla de AlarcónCoordenadas 39°37′31″N 2°07′00″O / 39.625222222222, -2.1167777777778[editar datos en Wikidata] La torre de telegrafía óptica de Olmedilla de Alarcón, también llamada de Atajollano o de las Carrasquillas es una de las que formaba parte de la línea de Barcelona, que había de comunicar Madrid con aquella ciudad vía Valencia. La telegrafía óptica en España La telegrafía óptica es un invento q...
For other uses, see Balsam. Turpentine made from the resin of the balsam fir tree The balsam fir tree from which Canada Balsam is obtained is so-named because it is found almost entirely within Canada in the boreal forest regionCanada balsam, also called Canada turpentine or balsam of fir, is the oleoresin of the balsam fir tree (Abies balsamea) of boreal North America. The resin, dissolved in essential oils, is a viscous, sticky, colourless or yellowish liquid that turns to a transparent yel...
لمعانٍ أخرى، طالع بات براون (توضيح). بات براون (بالإنجليزية: Pat Crawford Brown) معلومات شخصية الميلاد 29 يونيو 1929 نيويورك الوفاة 2 يوليو 2019 (90 سنة) [1] كورونا، ريفيرسيدي، كاليفورنيا مواطنة الولايات المتحدة عدد الأولاد 1 الحياة العملية المهنة ممثلة ت...
Selo da Comunidade de Inteligência dos Estados Unidos Comunidade de Inteligência dos Estados Unidos (CI) é uma federação de 17 agências governamentais independentes dos Estados Unidos que trabalham separadamente e em conjunto para realizar atividades de inteligência consideradas necessárias para a condução das relações externas e da segurança nacional do país. As organizações membros da CI incluem agências de inteligência, inteligência militar e inteligência civil e escrit...
Maurice Piat (November 2016) Kardinalswappen von Maurice Piat Maurice Evenor Kardinal Piat CSSp (* 19. Juli 1941 in Moka) ist ein mauritischer Ordensgeistlicher und emeritierter römisch-katholischer Bischof von Port-Louis. Leben Maurice Piat trat nach seiner Schulzeit in die Ordensgemeinschaft der Spiritaner ein und empfing am 2. August 1970 das Sakrament der Priesterweihe. Am 21. Januar 1991 ernannte ihn Papst Johannes Paul II. zum Koadjutorbischof von Port-Louis. Jean Kardinal Margéot spe...
Town in Vermont, United StatesThetford, VermontTownUnited Church of ThetfordLocated in Orange County, VermontLocation of Vermont with the U.S.A.Coordinates: 43°49′36″N 72°14′44″W / 43.82667°N 72.24556°W / 43.82667; -72.24556CountryUnited StatesStateVermontCountyOrangeChartered1761CommunitiesEast ThetfordNorth ThetfordPost MillsThetford CenterThetford HillUnion VillageArea • Total44.2 sq mi (114.4 km2) • Land43.6 s...
منغوليا Бүгд Найрамдах Монгол Ард Улс بوغد نايرامداخ مونغول أرد أولس الجمهورية الشعبية المنغولية ماركسية لينينية نظام الحزب الواحد 1924 – 1992 الجمهورية الشعبية المنغوليةعلم الجمهورية الشعبية المنغوليةشعار يا عمال العالم اتحدوا خريطة الجمهورية الشعبية المنغولية ع
Japanese professional wrestler Black BuffaloBuffalo in April 2011Birth nameKeisuke Yamada[1]Born (1974-07-06) July 6, 1974 (age 49)[1][2]Tottori Prefecture[1][2][3]Professional wrestling careerRing name(s)Black Buffalo[4]Black Búfalo[5]Black Vampire Buffalo[6]Buffalo[2]Inaba no Buffalo[2]Keisuke Yamada[7]Mōgyūma[8]Mōgyūma Aratame Tawara Tōda[9]Orix Buffalo[10]Rojo...
American writer and academic (1860–1951) For people with similar names, see Jeannette Lee (disambiguation). Jennette LeeJennette Lee circa 1905BornNovember 10, 1860 Bristol DiedOctober 16, 1951 (aged 90)Northampton Alma materSmith College OccupationWriter, academicSpouse(s)Gerald Stanley Lee Jennette Barbour Perry Lee (November 10, 1860 – October 10, 1951) was an American writer and academic. Born in Connecticut, she began to teach at...
Japanese fighting game player DaigoDaigo Umehara in 2018Current teamTeamTeam BeastGameStreet Fighter VIPersonal informationNameDaigo UmeharaNickname(s)The BeastBorn (1981-05-19) 19 May 1981 (age 42)Hirosaki, Aomori, Japan[1]NationalityJapaneseCareer informationGamesSuper Street Fighter II TurboStreet Fighter III 3rd StrikeUltra Street Fighter IVStreet Fighter VStreet Fighter Alpha 3DarkstalkersCapcom vs. SNK 2Guilty GearCapcom Fighting EvolutionPlaying career1997–presentCareer ...
Munisipalitas Puconci Občina PuconciMunisipalitasNegara SloveniaLuas • Total107,7 km2 (416 sq mi)Populasi (2013) • Total6.098 • Kepadatan5,7/km2 (15/sq mi)Kode ISO 3166-2SI-097 Munisipalitas Puconci adalah salah satu dari 212 munisipalitas di Slovenia. Kode ISO 3166-2 munisipalitas ini adalah SI-097. Menurut sensus 2013, jumlah penduduk munisipalitas yang luasnya 107,7 kilometer persegi ini adalah 6.098 jiwa. Referensi Tabela:...
Coordenadas: 16° 23' 58.02 S 48° 54' 26.54 O Grupo Caoa Grupo CaoaLogotipo do Grupo Caoa Razão social Caoa Motor do Brasil Ltda. Tipo empresa de capital fechado Atividade indústria automobilística Fundação 1979 (44 anos) Fundador(es) Carlos Alberto de Oliveira Andrade Sede São Paulo[1] Presidente Carlos Alberto de Oliveira Andrade Filho Produtos automóveis Subsidiárias Caoa Montadora Caoa Seminovos Website oficial caoa.com.br O Grupo Caoa é o distribuidor d...
В Википедии есть статьи о других людях с такой фамилией, см. Биберган. Давид Абрамович Биберган Дата рождения 6 ноября 1902(1902-11-06) Место рождения село Кривое Озеро, Балтский уезд, Подольская губерния, Российская империя Дата смерти 25 августа 1973(1973-08-25) (70 лет) Место смерт...
HMP Low MossLocation in ScotlandLocationBishopbriggs, East DunbartonshireCoordinates55°54′22″N 4°13′12″W / 55.906°N 4.220°W / 55.906; -4.220StatusIn ServiceCapacity784 (884 revised safe operating capacity)Opened1968 (Redeveloped 2012)Managed byScottish Prison ServiceGovernorScott Watson (Acting) HMP Low Moss is located on the outskirts of Bishopbriggs, East Dunbartonshire; near Glasgow, Scotland. It has been operated by the Scottish Prison Service as a pris...
Pour les articles homonymes, voir Royaume d'Italie. Cet article présente la liste des Rois d'Italie de 787 à 1946 et les actuels prétendants. Roi d'ItalieRe d'Italia Armoiries royales d'Italie Dernier roi d'ItalieHumbert II(1946) Création 15 avril 787 (premier roi d'Italie) Abrogation 13 juin 1946 Premier titulaire Pépin Ier (roi d'Italie) Dernier titulaire Humbert II (roi d'Italie) modifier Historique Le concept de royaume d'Italie renvoie à des réalités historiques différente...
Cream-filled pastry ProfiteroleA plate of cream puffsAlternative namesCream puff (US)Place of originFranceMain ingredientsChoux pastryFilling: whipped cream, custard, or ice creamOther informationWater based, milk based Media: Profiterole Chou with chocolate ganache A profiterole (French: [pʁɔfitʁɔl]), cream puff (US), or chou à la crème (French: [ʃu a la kʁɛm]) is a filled French choux pastry ball with a typically sweet and moist filling of whipped cream, c...
National Wind InstituteEstablished1970Academic staff35Postgraduates40LocationLubbock, Texas, U.S.Websitewww.nwi.ttu.edu The National Wind Institute (NWI) at Texas Tech University (TTU) was established in December 2012, and is intended to serve as Texas Tech University's intellectual hub for interdisciplinary and transdisciplinary research, commercialization and education related to wind science, wind energy, wind engineering and wind hazard mitigation and serves faculty affiliates, students, ...