DIFERENCIA ENTRE =NULL E IS NULL MYSQL

Depende del gestor 

 https://dev.mysql.com/doc/refman/8.0/en/working-with-null.html

En mi caso la aplicación es en condicionales,  campo1 = campo2  & campo4 = campo5, 1 y uno de los campos era null y la condicional me devolvia null

2 implementaciones split

delimiter $$
create procedure sp_split(str varchar(40), del varchar(1))
begin

declare idx int; //olvido declara int y de frente inicializo
declare idxOld int;//olvido declara int y de frente inicializo
declare subs varchar(50);//olvido declarar subs y de frente inicializo


set idx := 1;
//set idxOld := idx;
set token:='';

set str := trim(str);
set idx := instr(str,del);
while(idx > 0) //error poner  0 porque las cadenas comienzan con 1 y devuelve 0 si no encuentra
begin
 //set token := substring(str,idxOld + 1,idx-idxOld); error
 set token := SUBSTRING(str,1,idx - 1);
 insert into tblTemp(token);
 //set idx := idx + 1;
 //set str := SUBSTRING(str,idx,LENGTH(str) - idx + 1);
 set str := SUBSTRING(str,idx + 1,LENGTH(str) - idx);

 //set idxOld :=  idx;
 set idx: = SUBSTR(str,idx);
end
IF(LENGTH(str) > 0)
BEGIN
  insert into tablTemp(str);
END
end
$$

delimiter $$
create procedure split(s varchar(100), del varchar(1))
begin
 declare start int;
 declare end int;
 set start = 1;
 set endp1 = locate(s,del,start) ;
 while(endp1 > 0)
  begin
   insert int tbl(substring(s,start,endp1 - 1))
   start = endp1 + 1;
   end1 := locate(s,del,start);
  end
  if(start <= length(s))
   begin
    substring(s,start,length(s) - start + 1)
   end
end

 while(endp1 > 0)
  begin
   insert int tbl(substring(s,start,endp1 - 1))
   start = endp1 + 1;
   end1 := locate(s,del,start);
  end
  if(start <= length(s))
   begin
    substring(s,start,length(s) - start + 1)
   end
$$

create temporary table temp_table(
    datasplit varchar(100)
);

Primer procedimiento almacenado respetable

delimiter $$
DROP PROCEDURE IF EXISTS sp_splitx$$
CREATE PROCEDURE sp_splitx(str nvarchar(6500), dilimiter varchar(15), tmp_name varchar(50))
BEGIN
declare end_index   int;
declare part        nvarchar(6500);
declare remain_len  int;

set end_index      = INSTR(str, dilimiter);

while(end_index   != 0) do


    /* Split a part */
    set part       = SUBSTRING(str, 1, end_index - 1);
    select concat('',part);

    /* insert record to temp table */
    #call `sp_split_insert`(tmp_name, part);

    set remain_len = length(str) - end_index;
    set str = substring(str, end_index + 1, remain_len);

    set end_index  = INSTR(str, dilimiter);

end while;

if(length(str) > 0) then
    select concat('',str);

    /* insert record to temp table */
    #call `sp_split_insert`(tmp_name, str);

end if;
END
$$

# probando con call  sp_splitx('c,d,f,g',',','x');

procedimiento almacenado

delimiter $$
DROP PROCEDURE IF EXISTS sp_split$$
CREATE PROCEDURE sp_split(str nvarchar(6500), dilimiter varchar(15), tmp_name varchar(50))
BEGIN
declare end_index   int;
declare part        nvarchar(6500);
declare remain_len  int;

set end_index      = INSTR(str, dilimiter);

while(end_index   != 0) do

    /* Split a part */
    set part       = SUBSTRING(str, 1, end_index - 1);

    /* insert record to temp table */
    call `sp_split_insert`(tmp_name, part);

    set remain_len = length(str) - end_index;
    set str = substring(str, end_index + 1, remain_len);

    set end_index  = INSTR(str, dilimiter);

end while;

if(length(str) > 0) then

    /* insert record to temp table */
    call `sp_split_insert`(tmp_name, str);

end if;
END
$$


DROP PROCEDURE IF EXISTS sp_split_insert$$
CREATE PROCEDURE sp_split_insert(tb_name varchar(255), tb_value nvarchar(6500))
BEGIN
 SET @sql = CONCAT('Insert Into ', tb_name,'(item) Values(?)');
 PREPARE s1 from @sql; SET @paramA = tb_value;
 EXECUTE s1 USING @paramA;
END
$$

DROP PROCEDURE IF EXISTS test_split$$
CREATE PROCEDURE test_split(test_text nvarchar(255))
BEGIN
    create temporary table if not exists tb_search
    (
        item nvarchar(6500)
    );

    call sp_split(test_split, ',', 'tb_search');

    select * from tb_search where length(trim(item)) > 0;

    drop table tb_search;
END
$$
#call test_split('Apple,Banana,Mengo');
#$$

devolver result set o select en mysql con funcion o procedimiento almacenado ademas sql server

2
 


In MySQL, a function cannot return a table. You would have to use a stored procedure for that. – Dmytro Shevchenko Nov 6 '12 at 13:11 


4
 


What do you mean with "In SQL it's working fine?". You are using SQL.... – a_horse_with_no_name Nov 6 '12 at 13:28

************************

CREATE FUNCTION myFunction(id INT) RETURNS TABLE  
BEGIN  
   RETURN SELECT * FROM board;  
END  

This query gives following error:

1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'TABLE  

*********************************

As per documentation on user defined functions in MySQL
you can only return values of type {STRING|INTEGER|REAL|DECIMAL}

CREATE [AGGREGATE] FUNCTION function_name RETURNS {STRING|INTEGER|REAL|DECIMAL}
    SONAME shared_library_name

If you want to read a select resultset you have to define a procedure but not function.

DELIMITER //

DROP PROCEDURE IF EXISTS myProcedure //

CREATE PROCEDURE 
  myProcedure( id INT )
BEGIN  
   SELECT * FROM board
     -- add where condition if required
    WHERE Col_name = id
   ;  
END 
//

DELIMITER ;

And you can call procedure like

call myProcedure( 6 )

That returns implicit objects based on the statements used in the procedure.

************

CREATE PROCEDURE myProcedure( id INT ) BEGIN SELECT * FROM board WHERE id = id ; END //check the manual that corresponds to your MySQL server version for the right syntax to use near '' at line 5– Ankit Aranya May 2 '14 at 6:36  CREATE PROCEDURE myProcedure( id INT ) BEGIN select * from board; END // check the manual that corresponds to your MySQL server version for the right syntax to use near '' at line 3 – Ankit Aranya May 2 '14 at 6:39 can you please see this error – Ankit Aranya May 2 '14 at 6:40 delimiter was not defined. Answer updated. Please check. – Ravinder Reddy May 2 '14 at 6:48 @AnkitAranya: Accepting Answers: How does it work? – Ravinder Reddy May 2 '14 at 7:25

*********

EN SQL SERVER

http://stackoverflow.com/questions/5604927/how-to-return-a-table-from-a-stored-procedure

mysql Delimiter

En mysql cuando encuentra un ; ejecuta la sentencia
En los procedimientos tenemos que utilizar los ;
Utilizando delimitadores lo que estamos haciendo es que mysql entiende el ; como un
caracter mas y no se ejecute hasta que se utilice el delimitador.


(OJO NO VAS HA PONER DELIMITER $$;  ya que el delimitardor seria $$;)
delimiter $$
create procedure helloworld3()
begin
 select "Hello Word" as Mensaje;
end
$$
delimiter ;
###################
delimiter $$
CREATE PROCEDURE hello (s CHAR(20))
 SELECT CONCAT('Hello, ',s,'!');$$

delimiter $$
CREATE FUNCTION hello2 (s CHAR(20))
 RETURNS CHAR(50) DETERMINISTIC
 RETURN CONCAT('Hello, ',s,'!');$$

#####################

DELIMITER $$

drop procedure if exists sp_DBR_show_valor$$

create procedure sp_DBR_show_valor( in_value int )

begin

select concat( 'value is ', invalue);

end

$$

DELIMETER, se refiere a un delimitador para nuestras consultas SQL,  permite decirle a MySQL que todo antes de un delimitador formará forma parte de un solo bloque de codigo, tu puedes elegir cualquier delimitador, pero entre los más comunes están:

DELIMETER //

     ....

//

O bien:

DELIMETER $$

    ....

$$

https://www.codejobs.biz/es/blog/2014/07/09/como-hacer-un-procedimiento-almacenado-en-mysql-sin-morir-en-el-intento

-----------------------------

Nota:

Segun video
No se puede usar phpmyadmin para EJECUTAR o llamar procedimientos almacenados, pero si crear/modificar.
No olvidar que un procedimiento esta asociado a una base de datos por que lo que hay  que seleccionar una base de datos antes de crear una base de datos

Ojo que me llego a funcionar:
CREATE PROCEDURE HelloWorld112()
  SELECT "Hello World!" as Mensaje;

https://www.youtube.com/watch?v=vD02d_wN97Y
----------------------------

Default MySQL character set and collation

escribir en español con eñes y tildes es muy fácil, pero para ello debes tener un CHARSET y una COLLATION que lo permitan. Yo uso charset utf8 y collation utf8_spanisch_ci, pero seguro que lo logras con el CHARSET latin1 y la collation latin1_spanisch_ci. No puedes aplicar a las tablas y a los campos una collation que no tenga nada que ver con el charset elegido.
Pero este no es el único problema. También tienes que hacer que se entiendan tu servidor web APACHE y tu base de datos. Por otra parte, los datos que muestras de tu base de datos, los muestras en un archivo PHP o HTML, todo lo cual te obliga a usar esa misma codificación en los archivos PHP y HTML, tanto para introducir datos como para mostrarlos. Además, si eliges UTF8, tu navegador debe tener seleccionado un tipo de letra utf8.
Quiero decir con esto que tu problema, si has elegido un charset de esos y su cotejamiento (collation) adecuado para el español, el problema ahora está probablemente en hacer que tu servidor se entere de eso, pues creo que trabaja por defecto con ISO-8859-1. Además con unos meta que indiquen el charset y guardando los archivos php y html como utf8, en caso de que sea ese el charset elegido, se resolverá parte del problema, si no todo él.
Te daré algunas indicaciones para hacerlo con utf8 (pido perdón al moderador por incluir recomendaciones sobre html y PHP (es el programa que yo uso), pero lo considero en este caso necesario, solicitándole que quite el código que no considere necesario [he reportado el post])

BASE DE DATOS
1) Cuando creo una base a través de PHPMyAdmin y quiero que contenga campos en utf-8, selecciono dicho charset, poniendo especial atención en que el cotejamiento de las conexiones MySQL sea en utf_unicode_ci, la tabla o tablas con cotejamiento utf_unicode_ci, los campos con cotejamiento utf_unicode_ci (son los que yo utilizo), aunque sólo aquellos en que voy a introducir utf-8. 
ARCHIVOS HTML Y PHP
2) Las páginas con terminación html y php deben ser guardadas con formato utf-8 (ojo, porque algunos editores no lo permiten). Yo uso NotePad++ que en formato te permite elegir el que quieres. Si se trabaja con sesiones, hay que guardar como ANSI y mostrar utf8 sin BOM, para evitar que haya algo antes de los header.
3) En el archivo con terminación html debes escribir este meta <meta http-equiv="Content-type" content="text/html; charset=utf-8" />

CONEXIÓN MYSQL MEDIANTE PHP
4) Cuando hagas la conexión a la base de datos MySQL, deberás escribir tras la conexión y justo después de seleccionar la base: mysql_query ("SET NAMES 'utf8'"), como en el ejemplo.
<?php 
$link = mysql_connect ('localhost', 'root', 'tuclave');
if (!$link){
echo 'error al conectar';
die;
}
$bd = mysql_select_db('mibase');
if (!$bd){
echo 'error al seleccionar la base d datos';
die;
}
mysql_query ("SET NAMES 'utf8'");
?>

NAVEGADOR
5) Y, finalmente, debemos tener al menos una fuente utf8 y ponerla como fuente para nuestro navegador. Puedes en la programación poner una lista de familias de letras utf8 para que vaya eligiendo entre ellas. Y creo que si no encuentra una de ellas, seleccionará la letra unicode con la que cuente.

Hay algunos truquillos más, como codificar como utf-8 un archivo de texto (guardándolo como con ese formato) cuando vaya a importarse a una base de datos con character set utf-8. Si no lo haces, observarás que las palabras son cortadas por donde hay caracteres con acento o eñes.

Pero todavía hay más: el modo en que el paso de la información de AJAX a través del navegador o navegadores (hay diferencias).

Otra situación extraña que me ha ocurrido es que se me entregue una base con una codificación que no es la adecuada a la naturaleza de los datos con los que quiero trabajar. Pondré un ejemplo: se me entregó una base codificada en ISO-8859-1, pero yo necesitaba codificación UTF-8. No me quisieron cambiar la codificación. Es verdad, como se me dijo, que puedo almacenar los datos en utf8 en las tablas y campos, y así lo hice, pero la collation no funcionaba. La solución tendría que haber sido exportar los datos y luego crear una base con la codificación utf8 e importarlos, pero al no permitírseme me vi obligado a crear campos de orden y consulta específicos, con programación.

*********

PORQUE EL COTEJAMIENTO latin1_swedish_ci  ES EL QUE ESTA POR DEFECTO

Por lo que yo puedo ver, latin1 fue el juego de caracteres predeterminado en los tiempos pre-multibyte  (MySQL 4.1 hacia atras)y su cotejamiento por defecto era latin1_swedish_ci y parece que ha sido continuado, probablemente por razones de compatibilidad hacia abajo (porejemplo, para antiguas sentencias CREATE en las que no especificaron una cotejamiento).

En cuanto a por qué sueco, sólo puedo suponer que es porque MySQL es de una compañía sueca. No puedo ver ninguna otra razón para elegir este cotejamiento

**************

OJO AL COLLATION LO TRADUCEN COMO COTEJAMIENTO O COLACION

***********

CREATE TABLE `visitas_tmp` (
  `id` int(11) default NULL,
  `user_agent` varchar(255) default NULL,
  `permalink` varchar(255) default NULL,
  `created_at` datetime default NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8  COLLATE=utf8_spanish_ci;

*******

Qué es eso de ASCII, ISO-8859-1 y UTF-8?

Los tres estándares representan el esfuerzo informático por brindar un sistema de codificación que permita representar los caracteres que se usan en todos los idiomas. El primer esfuerzo lo hizo ASCII y fue para el idioma inglés (128 caracteres), luego ante su insuficiencia para representar otros caracteres como los latinos por ejemplo, nace ISO-8859-1 (tambien llamado LATIN-1 ó ASCII extendido) pero debido a que no podía representar caracteres de otros idiomas aparece el estándar UNICODE (del cual es parte UTF-8).

Un buen detalle a saber es que mientras ISO-8859-1 usa un byte para representar un caracter, no pasa lo mismo con UTF-8 que puede usar hasta 4 bytes ya que es de longitud variable. Esto hace que una base de datos en UTF-8 sea un "poquito" mas pesada que una en ISO-8859-1. Esto sucede porque -por ejemplo- mientras ISO-8859-1 usa un byte para representar la letra ñ, UTF-8 usa dos bytes. Esto podríamos comprobarlo generando un documento con puras eñes en formato ISO-8859-1 y luego convirtiendolo a formato UTF-8, comprobarán que pesa... el doble!!!

Hay un tema más y es que muchas veces cuando vamos a migrar información nos encontramos con caracteres ISO-8859-1 (los correspondientes a los números 147, 148, 149, 150, 151 y 133) que no pueden verse en un editor UNIX pero si en un browser HTML. En ese caso si queremos reemplazar los caracteres podemos usar la siguiente instrucción

str_replace(array(chr(147), chr(148), chr(149), chr(150), chr(151), chr(133), '&quot;', '&#8226;'), array(chr(34),  chr(34),  chr(45),  chr(45),  chr(45),  '...', chr(34), chr(45)), $field);

donde 34, 45 son los equivalentes. Para más información se puede ver una tabla como

**************************************************************************************************

http://cambio.name/personal/content/%C2%BFqu%C3%A9-es-eso-de-ascii-iso-8859-1-y-utf-8

************************************************************************
Los charset de mysql, phpmyadmin y el html del browser son distintos, debes poner los tres por separado, a que sea iguales para que funcione.

************************************************************************

Si "Igualada", el hosting es de SERED.

"Skaparate", yo utilizo el editor HTML-Kit, por lo tanto puedo escoger la codificación.
Deduzco, según tu explicación que si uso "iso-8859-1":

1.- Cotejamiento para las conexiones al servidor y para las tablas: "latin1_general_ci"
2.- Cotejamiento de campo: "latin1_spanish_ci"
3.- Justa tras la conexión con el servidor, colocar esta sentencia: "mysql_query("SET NAMES 'latin1'")"
4.- Y el meta: "<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />"

I si uso "utf-8":

1.- Cotejamiento para las conexiones al servidor y para las tablas: "utf8_general_ci"
2.- Cotejamiento de campo: "utf8_spanish_ci"
3.- Justo tras la conexión con el servidor, colocar esta sentencia: "mysql_query("SET NAMES 'utf8'")"
4.- Y el meta: "<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">"

He leido en alguna parte que el cotejamiento para las conexiones al servidor y para las tabals tenia que usar: "utf8_unicode_ci".

Ayer al acabar el dia, los de "SERED" no se que hicieron, pero arreglaron el problema con el codigo HTML, pero volvieron a desarreglar el texto extraido de la base de datos con PHP.
Lo que no entiendo, es porque hasta hace una semana todo funcionava correctamente, y de golpe y porrazo todo queda liado ?

Podeis darme mas ideas, y si puede ser mas específicas, por favor ?
Gracias por vuestra ayuda.
*********
http://foros.cristalab.com/utf-8-y-cotejamiento-en-la-db-t24674/
ALTER DATABASE 'mi_tabla' DEFAULT CHARACTER SET utf8 COLLATE utf8_bin
********
********
http://blog.soporteti.net/programacion-2/mysql-charset-y-collation/

MySQL – Charset y Collation

En MySQL vienen definidos unos valores por defecto para charset y para collation que en ocasiones puede darnos sorpresas al importar archivos SQL apareciendo caracteres extraños en lugar de los que esperábamos ver.

Por charset se entiende el juego de caraceteres que utiliza el servidor MySQL, mientras que por collation se entiende las reglas de comparación para ordenar alfabéticamente ese juego de caracteres.

En mi servidor(YO SE REFERIRA POR DEFAULT) se han definido por defecto utf-8 para charset y latin1_swedish_ci para el collation (los autores de MySQL son suecos).

Nosotros definiremos latin1(iso-8859-1) para el charset y latin1_spanish_ci para collation.

Editamos el archivo de configuración de MySQL que se suele llamar my.ini o my.cnf dependiendo del sistema operativo y añadimos los siguientes valores después de la sección [mysqld]:

character-set-server=latin1
collation-server=latin1_spanish_ci
default-character-set=latin1
default-collation=latin_spanish_ci

A continuación reiniciamos el servidor y así se habrán establecido los nuevos valores por defecto.

Para asegurarnos, especificamos los charsets en la configuración de PHP y Apache.

Editamos php.ini y modificamos la línea:

default_charset="iso-8859-1"

Editamos httpd.conf y modificamos la línea. Si comentamos la línea tomará el charset por defecto del navegador:

AddDefaultCharset ISO-8859-1
***********

utf8_spanish_ci vs utf8_spanish2_ci

Las colaciones utf8_spanish_ci y utf8_spanish2_ci se corresponden con español moderno y español tradicional respectivamente. En ambas colaciones , 'ñ' es una letra independiente, entre 'n' y 'o'. Además, para español tradicional 'ch' es una letra, ordenada entre 'c' y d, y 'll' es una letra que se coloca entre 'l' y 'm'.

Recomendado: utf8_spanish_ci. 

**************

DIFERENCIA ENTRE  usar utf8_spanish_ci utf8_general_ci 

MEDIANTE EL SIGUIENTE PROBLEMA (Y EL PARRAFO ANTERIOR) QUEDARA BIEN CLARO LA DIFERENCIA DE USAR UNO O EL OTRO

Creo haber detectado un error en el orden por apellidos de los listados de los alumnos en la versión 1.9.x por ejemplo, "Cañizares" queda delante de "Cano" no sé si esto ocurre en otras plataformas y debo pasarlo al Tracker o se puede resolver de algún modo. Gracias.

RESPUESTA

Enrique,

seguramente estás usando MySQL con codificación utf8 y colación utf8_general_ci o utf8_unicode_ci.

En este caso, la 'ñ' se considera equivalente a la 'n' a efectos de ordenación. Si quieres que se distinga, tendrías que usar utf8_spanish_ci outf8_spanish_ci2 (más detalles sobre la diferencia entre ambos al final de la página http://dev.mysql.com/doc/refman/5.0/en/charset-unicode-sets.html)

Saludos. Iñaki.

https://moodle.org/mod/forum/discuss.php?d=170189

-------------

POR OTRO LADO:

Conclusiones

Aunque parece ser un tema menor, la verdad es que hay harto que pensar y decidir detrás de los CHARSETs y COLLATIONs. Por el lado del CHARSET, aunque parezca como mejor opción utilizar siempre UTF8, hay casos en que resulta totalmente inútil: si queremos guardar una cadena cuyo valor sabemos que no contendrá valores distintos del alfabeto, es mejor ocupar ASCII y de esa forma estar seguros que no se pueden ingresar caracteres inválidos. Por otro lado, si estamos seguros de que nuestra aplicación nunca jamás tendrá otro idioma que no sea español, también podemos utilizar latin1, aunque hay que tener cuidado en hacer los ajustes necesarios en todos aquellos lados donde podría haber una influencia de otro set de caracteres.

El tema del COLLATION sí es un poco más extenso ya que dependerá mucho del cómo se efectúen las búsquedas y también el idioma en que estemos trabajando. MySQL asigna utf8_general_ci como COLLATION predeterminado de UTF-8, pero éste presenta algunos problemas en hebreo y en algunas localizaciones de idiomas cirílicos; principalmente bielorruso, macedonio, serbio y ucraniano; así que para estos casos resulta mejor ocupar utf8_unicode_ci, la que tampoco está exenta de polémica ya que es más lento que utf8_general_ci.

Como gran conclusión: traten de usar UTF-8 como CHARSET donde sea posible, y si quieren tener velocidad vayan por utf8_general_ci como COLLATION pero si quieren tener certeza de que todo está bien ordenado y que sea compatible con (casi) todos los idiomas del mundo ocupen utf8_unicode_ci. (YO USARE utf8_spanish_ci 

EL ARCHIVO MY.INI CONTIENE ESTO

#collation_server=utf8_unicode_ci

#character_set_server=utf8

OJO OTRA COSA: Ojo que en MySQL, la codificación UTF-8 no existe! Sólo existe utf8 (en minúsculas sin raya) y por supuesto latin1, que sería el equivalente a ISO-8859-1.

http://blog.unreal4u.com/2012/08/sobre-collation-y-charset-en-mysql/

)

******************

Collations y encodes en MySQL

Ahora que empiezas un nuevo proyecto, hazte un favor y usa UTF-8 (YO COMO CHARSET) . Por cierto, desde 1994 la Asociación de Academias de la Lengua Española decidió que la CH y la LL no se tienen en cuenta como letras propias al ordenar el diccionario, por lo que la COLLATION adecuada en español es utf8_spanish_ci y NO utf8_spanish2_ci. Curiosamente, el Diccionario de la Real Academia ordenó la CH después de la C desde 1803 hasta 1994... unos poquitos años.

¿No sabes qué es una codificación de caracteres? ¿No sabes qué es una collation?
http://dev.mysql.com/doc/refman/5.0/en/charset.html

Aquí hay una buena lista de todas las collation y sus ordenaciones alfabéticas:
http://www.collation-charts.org/mysql60/by-charset.html

¿Problemas buscando cosas con eñes u ordinales (º, ª)...? Usa COLLATE utf8_bin. Si no lo usas, al buscar "º" te encontrará "º" y "o" y "ó" y "Ò"... Por ejemplo:

SELECT * FROM table 
   WHERE field COLLATE utf8_bin LIKE '%º%';

***************

http://www.rae.es/consultas/exclusion-de-ch-y-ll-del-abecedario

Exclusión de ch y ll del abecedario





Se excluyen definitivamente del abecedario los signos ch y ll, ya que, en realidad, no son letras, sino dígrafos, esto es, conjuntos de dos letras o grafemas que representan un solo fonema. El abecedario del español queda así reducido a las veintisiete letras siguientes: a, b, c, d, e, f, g, h, i, j, k, l, m, n, ñ, o, p, q, r, s, t, u, v, w, x, y, z.

El español se asimila con ello al resto de las lenguas de escritura alfabética, en las que solo se consideran letras del abecedario los signos simples, aunque en todas ellas existen combinaciones de grafemas para representar algunos de sus fonemas.

La eliminación de los dígrafos ch y ll del inventario de letras del abecedario no supone, en modo alguno, que desaparezcan del sistema gráfico del español. Estos signos dobles seguirán utilizándose como hasta ahora en la escritura de las palabras españolas: el dígrafo ch en representación del fonema /ch/ (chico [chíko]) y el dígrafo ll en representación del fonema /ll/ o, para hablantes yeístas, del fonema /y/ (calle [kálle, káye]). La novedad consiste, simplemente, en que dejan de contarse entre las letras del abecedario.

Al tratarse de combinaciones de dos letras, las palabras que comienzan por estos dígrafos o que los contienen no se alfabetizan aparte, sino en los lugares que les corresponden dentro de la c y de la l, respectivamente. La decisión de adoptar el orden alfabético latino universal se tomó en el X Congreso de la Asociación de Academias de la Lengua Española, celebrado en 1994, y viene aplicándose desde entonces en todas las obras académicas.






- See more at: http://www.rae.es/consultas/exclusion-de-ch-y-ll-del-abecedario#sthash.RqSNK4Kn.dpuf




***********
http://manuales.guebs.com/mysql-5.0/charset.html

Hay una convención para nombres de colaciones: empiezan con el nombre del conjunto de caracteres al que están asociados, normalmente incluyen el nombre del idioma, y acaban con _ci(no distingue entre mayúsculas y minúsculas), _cs (distingue entre mayúsculas y minúsculas), o _bin(binario).
*********
MySQL includes character set support that enables you to store data using a variety of character sets and perform comparisons according to a variety of collations. You can specify character sets at the server, database, table, and column level. MySQL supports the use of character sets for the MyISAM, MEMORY, NDBCLUSTER, andInnoDB storage engines.
***************
http://softwareyotrasdesvirtudes.com/2012/10/09/como-modificar-tablas-a-utf8-mysql/

Cómo modificar tablas a UTF8 MySQL

Imaginemos una aplicación con la base de datos de mysql. En ella editamos información por ejemplo, de usuarios.

Todo es bonito y precioso.

Hasta! que decides exportar información a csv, hacer un volcado de datos y exportarlo a otra base de datos… etc.

¿Por qué? ¡Se ven mal los acentos, ñññññ y muchos caracteres!

Si estás en este caso, es que tienes mezclados los charset. Familiarizate con COLLATION y CHARSET.

http://dev.mysql.com/doc/refman/5.0/es/charset-mysql.html

Es mejor que utilices por compatibilidad UTF8.

Mysql por defecto crea collation a ‘latin1_swedish_ci’. Para arreglar los datos deberás hacer lo siguiente:

Si lo haces desde consola:

1. Modificar la tabla

ALTER TABLE `caracteristicas_subtipos`
COLLATE=’utf8_general_ci';

2. Exportar los datos por medio de inserts Hacer truncate de la tabla.
   • Mediante volcado mysqldump -p –default-character-set=utf8  base_de_datos tabla_a_modificar > tabla_a_modificar.sql
3. Volcar los datos.
   • Mediante mysql -p base_de_datos < tabla_a_modificar.sql

Si lo haces desde una herramienta de mysql:

Cambia sólo la forma de obtener los datos. Exporta los datos a INSERTS. Haz un truncate de la tabla. Antes de volcar los inserts pon la sentencia:

set names utf8;

FAQ:

Se puede hacer aplicado a todo un esquema?: No, tendrás que hacerlo tabla por tabla. Si alguien lo ha conseguido que lo comente!! sería un gran descubrimiento!

Agradecimientos:

A @rcasas  que me enseñó estas cosas tan chulas.

**************

Problemas html acentos y eñes: charset UTF-8 / ISO-8859-1

La codificación de las páginas web (charset) es un problema recurrente para los webmasters, porque:

• Depende del editor en que se haya hecho la web, si en el trabajamos por defecto en UTF-8 o ISO-8859-1. Si el archivo original estaba escrito en ISO-8859-1 y lo editamos en UTF-8, veremos los caracteres especiales mal codificados. Si guardamos ese archivo tal cual, estaremos corrompiendo la codificación original (se guardará mal, con UTF-8). Y viceversa.
• Depende de la configuración del Apache.
• Depende de si hay un archivo oculto .htaccess en el directorio raíz que sirve nuestra web (httpdocs, public_html o similar)
• Depende de si se especifica en las etiquetas META de los HTML resultantes.
• Depende de si se especifica en la cabecera de un archivo PHP.
• Depende del charset elegido en la base de datos (si se usa una base de datos para mostrar contenidos con un CMS, tal como Joomla, Drupal, phpNuke, o una aplicación propia que sea dinámica).

Por lo general, si nunca tienen que aparecer acentos o eñes en nuestra web, nos es indiferente la codificación (aunque pueden haber otros símbolos que nos fastidien). Aunque si nuestra web está en español, lo más normal es que coloquemos acentos y eñes. Para ello, el estándar HTML está preparado para colocar todos los símbolos y acentos que nos sean necesarios, codificándolos. Así, para los acentos y eñes, deberíamos colocar:

á -> &aacute;
é -> &eacute;
í -> &iacute;
ó -> &oacute;
ú -> &uacute;
ñ -> &ntilde;
Variantes valenciano-catalán-balear para acentos abiertos:

à -> &agrave;
è -> &egrave;
ò -> &ograve;

De este modo, veremos todos caracteres correctamente, independientemente del charset.

Sin embargo, puede ser tedioso para ciertos contenidos tener que ir traduciendo nosotros manualmente los caracteres. Es en estos casos donde vale la pena perder un poco de tiempo para ajustar las distintas configuraciones.

---

Primero, habría que determinar en nuestra web con las etiquetas META que nuestra web debe servirse en la codificación que nosotros elijamos. O sea, dentro de :

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

o bien

<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />

---

Si seguimos con el problema, Segundo, ver si por defecto tiene el servidor (apache) algún charset predefinido. Si es así, se ignorarán las etiquetas META del html.
En un servidor Linux, el archivo charset está en:

/etc/apache2/conf.d/charset

también puede cambiarse en el archivo httpd.conf

Debería aparecer sólo "AddDefaultCharset off", para que haga caso de las etiquetas META (lo ideal). Podemos poner, por ejemplo, "AddDefaultCharset UTF-8", y así apache siempre emitirá las webs en UTF-8. El problema es que esto afecta a todo el servidor, y si luego tenemos alguna web que vaya a usar otra codificación tendremos un problema. Por eso, lo ideal es que esté a Off y que cada web defina cómo quiere mostrarse.

Pero puede darse el caso de que nosotros no seamos los administradores del servidor y sólo tengamos un Plesk, y no podamos acceder al archivo charset por encontrarse fuera de nuestro rango de permisos. Podemos, entonces, pedirle al administrador del servidor que coloque el parámetro anterior a Off, o bien...

---

Alternativa 1: Colocar un archivo .htaccess en el directorio raíz de la web
Los .htaccess son archivos de configuración que sobreescriben algunas configuraciones del apache sólo para determinados casos. Hay que tener en cuenta que estos archivos:

• Pueden funcionar total o parcialmente, dependiendo de la configuración del servidor (cuestión de seguridad).
• Son archivos ocultos, por lo que para verlos tenéis que tener habilitada la función "ver archivos ocultos" en vuestro programa que acceda por ftp.

Este archivo .htaccess debería tener al menos una línea de este tipo

AddDefaultCharset utf-8

---

Alternativa 2: Colocar una directiva en php que fuerce a mostrarse en la codificación deseada
Esto es, sólo sirve si el archivo tiene extensión ".php". Recordemos que el html y el php pueden convivir en el mismo fichero, con lo que si renombramos un ".html" a ".php", el resutlado es exactamente el mismo (si tenemos instalado el php en nuestro servidor, claro está).
En la primera línea del archivo que deseemos indicarle la codificación (o lo antes posible) deberíais colocar la siguiente cabecera:

<?php
header('Content-Type: text/html; charset=UTF-8'); ?>

---

Para todos los casos donde funcione el comando "AddCharset"
- Puede especificarse el charset según la extensión del archivo. Si, por ejemplo, queremos que los ".php" sean UTF-8 y los ".html" sean ISO, podemos colocar estas dos instrucciones seguidas:

AddCharset UTF-8 .php
AddCharset ISO-8859-1 .html

---

‹ Plesk 9: Logs de error y accesos del dominio: "remove_files failed"upCómo ajustar un diseño web html a explorer+firefox+opera+chrome ›
**************

Distinguir acentos, mayúsculas y minúsculas en MySQL

Publicado: 02/02/2011 en base de datos, MySQL
Etiquetas:acentos, base de datos, mayúsculas, minúsculas, MySQL, query, tilde

17

11 Votos

You can read the English version of this post in http://phpsblog.agustinvillalba.com/how-to-distinguish-upper-lowercase-and-utf8-characters-mysql/

En esta ocasión vamos a hablar sobre cómo generar una sencilla query de selección de datos en una base de datos MySQL, cuyo charset ha sido establecido como utf8_general_ci pero necesitamos distinguir entre datos con acentos y datos sin acentos, y yendo un poco más allá, si fuera posible, que no distinga entre palabras que empiecen con mayúsculas o minúsculas pero sí los acentos. Veamos cómo podríamos implementarlo.

Definición de nuestro problema

Expliquemos un poco mejor cuál es nuestro problema. Tenemos una base de datos MySQL en la que tenemos a su vez una tabla, por ejemplo, “usuarios”, con varios campos: id, nombre y apellido. Esta base de datos fue creada con un charset utf8_general_ci. Pero, ¿qué significa esto? Obviamente, utf8 es el charset que nuestra base de datos va a gestionar. En segundo lugar, “general” indica que no utilizaremos el juego de caracteres propio de un idioma en concreto, (podríamos tener “utf8_spanish_ci”, para el juego de carácteres propios del español), sino el utf8 de forma genérica. En último lugar, “ci” significa “Case Insensitive”, de forma que en nuestras búsquedas, el motor de MySQL no hará distinciones entre “MAYÚSCULA”, “Mayúscula” o “mayúscula”. Lo que no es tan conocido es que el ser Case Insensitive también implica que no distinga los acentos del español, de forma que tampoco hace distinciones entre “mayúscula” o “mayuscula”.

De forma que si tenemos 3 registros en nuestra tabla usuarios, en los cuales tenemos los siguientes valores para el campo nombre: “José”, “Jose” y “JOSÉ”, y ejecutamos la siguiente query:

SELECT * FROM `usuarios` WHERE `nombre` = 'jose'

Ésta nos devolverá los 3 registros de nuestra base de datos, sin distinciones.

Distinguir acentos, mayúsculas y minúsculas en MySQL

Para poder distinguir acentos, mayúsculas y minúsculas en nuestras búsquedas en una base de datos MySQL con charset utf8_general_ci necesitamos indicarle al motor MySQL que en ésta búsqueda en concreto no aplique el charset utf8_general_ci, sino que utilice otro, el conocido como utf8_bin, y para ello hemos de utilizar la palabra reservadaCOLLATE. Con este charset le estamos indicando a MySQL que la comparación en la búsqueda la haga a nivel binario, con lo cual ahora sí podrá distinguir entre palabras con acentos y sin acentos, mayúsculas y minúsculas dado que (obviamente) un carácter con acento es bianariamente distinto a uno sin acento así como las mayúsculas. De forma que nuestra query anterior, para que distinga acentos, sería algo así:

SELECT * FROM `usuarios` WHERE `nombre` = 'josé' COLLATE utf8_bin

Esta query nos devolvería un registro nulo, dado que no existe exactamente “josé” en nuestra base datos. Para poder obtener un valor deberíamos ejecutar la misma query pero comparando con el valor “José” o “JOSÉ”, dado que con el COLLATE utf8_bin “josé” <> “jose” <> “José” <> “JOSÉ” etc.

Pero resulta que necesitamos que distinga acentos pero que no tenga en cuenta mayúsculas o minúsculas. ¿Cómo podemos solucionarlo?

Distinguir acentos, sin distinguir mayúsculas o minúsculas en MySQL

Para que MySQL pueda distinguir los acentos pero no las mayúsculas o minúsculas, no tenemos que hacer nada especial. Simplemente lo que haremos será convertir a todos los caracteres en mayúscula del valor almacenado en el campo nombre y convertir a todos los caracteres en mayúsculas del valor del parámetro a comparar, de forma que internamente en el momento de la búsqueda no existan minúsculas y así poder comparar con seguridad. Para ello utilizaremos la palabra reservada UPPER de MySQL. De forma, que nuestra query anterior, para que no distinga mayúsculas y minúsculas pero sí acentos, sería la siguiente:

SELECT * FROM `usuarios` WHERE UPPER(`nombre`) = UPPER('josé) COLLATE utf8_bin

Esta query nos devolvería como resultado los nombres “José” y “JOSÉ”, dado que no hacemos distinciones de mayúsculas, tal y como queríamos conseguir.

You can read the English version of this post in http://phpsblog.agustinvillalba.com/how-to-distinguish-upper-lowercase-and-utf8-characters-mysql/