Cómo convertir el juego de caracteres y la colación de la base de datos de WordPress
Desde WordPress 2.2, WordPress apoya la característica que permite que el usuario defina el juego de caracteres y la colación de la base de datos de WordPress con valores de DB_CHARSET y de DB_COLLATE en archivo de wp-config.php. Con estos valores definidos, WordPress utilizará el juego de caracteres señalado de la base de datos (charset) y la colación de la base de datos (es decir orden de la clase de las letras, de los números, y de los símbolos de un juego de caracteres) cuando las tablas de una base de datos de conexión.
Sin embargo, en las instalaciones existentes de WordPress que se aumentan de la versión anterior de WordPress o fijan no explícitamente una colación del charset de Unicode UTF-8, el juego de caracteres de la base de datos del defecto se fija normalmente como Latin1 (defecto en casi toda la instalación de MySQL) con la colación de latin1_swedish_ci. Si usted funciona un blog bilingüe o multilingüe con WordPress, usted puede hacer frente a problema en la codificación del carácter cuando sus postes del blog se escriben en otros idiomas extranjeros, o cuando usted exporta y respaldo la base de datos y la tentativa posterior de reimportar la descarga de la base de datos en caso de falta de la base de datos o migración y mudanza del servidor. ¿El síntoma es obvio, sus postes de WordPress o las páginas quieren contienen los caracteres mutilados, extraños y divertidos, alguna vez apenas porciones de????? (signos de interrogación), haciendo la base de datos de WordPress con su trabajo duro inútil y la salida ilegible. (Causa de mayo también por la colación incorrecta del charset)
La mejor solución al problema de la codificación del carácter en WordPress es convertir el charset o la base de datos y la colación a UTF-8 o a Unicode. Sin embargo, usted NO PUEDE conectar simplemente con MySQL vía cáscara o el phpMyAdmin y esperar todas sus escrituras convertirán agradable. Como explican por la guía de la conversión de la base de datos de WordPress, los juegos de caracteres del convertido requieren usando el MySQL ALTERAN comando de la TABLA. ¡Al convertir los juegos de caracteres, todos los campos del TEXTO (y similar) se convierten a UTF-8, pero esa conversión ROMPERÁ EL TEXTO existente porque la conversión espera que los datos estén en latin1, pero WordPress pudo haber almacenado caracteres del unicode en una base de datos latin1, y consecuentemente, los datos podrían terminar para arriba como basura después de una conversión!
La guía proporciona una guía muy áspera y vaga como solución en cómo convertir realmente las tablas de base de datos de WordPress MySQL a partir de un juego de caracteres a otro, generalmente UTF-8. Sin embargo, la guía trabaja realmente, aunque el proceso pueda ser muy largo. Para convertir, los pasos implicados generalmente son alterar cada TEXTO y campos relacionados dentro de las tablas de cada WP al BLOB, después alteran el juego de caracteres de la base de datos y finalmente cambian los campos del BLOB de nuevo al TEXTO. ¿Parece fácil, pero cuánto tiempo él tomaría para convertir tan muchos campos en tan muchas tablas? Además, usted también necesitará recordar el tipo y la longitud o los valores originales de todos los campos.
el andersapt ha fijado una escritura de la conversión nombrada convert_to_utf8_sql_generator.txt que genera automáticamente una lista de declaraciones de SQL y los comandos necesitan convertir completamente su base de datos de WordPress a UTF8 basado en la guía. Sin embargo, parece haber un insecto de menor importancia con la escritura, aunque el autor la demandara lo trabajara, donde en mi caso, no genere simplemente la lista de comandos de SQL de funcionar debido error no recuperable del PHP del error : Llame a los get_results de una función del miembro () en un no-objeto en convert.php en la línea 37 . Una vez que está fijado, con esta escritura a disposición nosotros puede convertir fácilmente y rápidamente la base de datos, las tablas y los campos para utilizar la colación de utf8_general_ci.
Nota: He probado el convertidor de la base de datos UTF-8 enchufable, pero es una falta. Parecía como el cambio del autor al juego de caracteres directamente.
Guía para convertir el juego de caracteres de la base de datos de WordPress a UTF8 (Unicode)
- Tome el blog de WordPress fuera de línea colocando un aviso fuera de servicio o del mantenimiento.
- Base de datos de reserva - esto es muy importante, nada se garantiza para trabajar. Si usted está utilizando el cPanel o el otro panel de control, es el mejor realizar un respaldo del panel de control sí mismo de la base de datos, donde usted puede restaurar la base de datos en una sola pieza en vez por de declaraciones de SQL, en el caso de descarga normal.
- Transfiera la escritura fija de convert_to_utf8_sql_generator.txt y ahórrela con una extensión del PHP.
- Modifique la escritura para entrar el nombre de base de datos que su blog de WordPress está utilizando. Localice el texto siguiente:
Tables_in_DATABASENAME
El DATABASENAME en rojo es la única cosa que usted necesita cambiar para emparejar su nombre de base de datos de WordPress. Debe los parecer esto después de cambio, por ejemplo,
Tables_in_wp_mydigitallife
- Cargue el convert_to_utf8_sql_generator.php (o le puede retitular a un nombre más corto tal como convert.php) al directorio de instalación bajo de WordPress de la raíz, donde wp-config.php también se localiza.
- Ahora, la llamada y hojea la escritura de cualquier web browser. Para hacer esto, para agregar simplemente convert_to_utf8_sql_generator.php (o cualquie nombre que usted dé a la escritura) al extremo de su URL del blog (es decir http://www.mywebsite.com/convert_to_utf8_sql_generator.php) y presiona entra. Una lista larga de declaraciones de SQL será generada en el Web page.
- Asegúrese de que NO LO HAGAN sus campos post_content y del poste del título en la tabla de los wp_posts pertenezcan a ninguna índices o a índices CON TEXTO COMPLETO. El tipo de los campos no se puede convertir al BLOB con uno de la lista de errores abajo. Algunos enchufes, tales como postes relacionados tienden a agregar índices a estos campos. En este caso, caiga temporalmente los índices.
ERROR 1170 (42000): Post_content del `de la columna de BLOB/TEXT usado en la especificación dominante sin una longitud dominante
ERROR 1283 (HY000): El post_content del `de la columna no puede ser parte del índice CON TEXTO COMPLETO
- Ábrase una sesión a su cáscara del servidor por el telnet o SSH. Usted puede saltar esta parte de usar la cáscara de Unix si usted se prepone utilizar phpMyAdmin para hacer el trabajo sucio, pero no lo he intentado. Tan si usted hace, hacer la regeneración encendido si puede ser hecha.
- Conecte con el servidor de MySQL de la cáscara.
- Publique el comando siguiente primero en el aviso de MySQL:
utilice DATABASENAME;
Una vez más substituya DATABASENAME en rojo al nombre de base de datos real de WordPress.
- Entonces la copia y pega la lista entera de automóvil de las declaraciones de SQL generado por la escritura de la conversión, y los pega en el aviso de MySQL. Cada comando de SQL se debe ahora procesar y ejecutar por MySQL uno por uno. Usted puede necesitar presiona incorpora llave para acabar apagado el pasado.
- Durante el proceso, los mensajes de error similares relacionados con la longitud dominante como mencionado pueden aparecen. En mi caso, la conversión al BLOB falló con tal mensaje en los campos siguientes:
wp_categories.category_nicename
wp_comments.com ment_approved
wp_links.link_visible
wp_options.option_name
wp_postmeta.meta_key
wp_posts.post_status
wp_posts.post_name
wp_posts.post_type
wp_usermeta.meta_key
wp_users.user_loginTodos estos campos son inverosímiles contienen los caracteres no-ASCII. Y los campos tales como category_nicename (lingote de la categoría) y post_name (lingote del poste) han sido URL codificados (donde su URL con los caracteres no-alfanuméricos inseguros será substituido por una muestra del por ciento (%) seguida por dos dígitos y espacios del maleficio codificados como más (+) muestras). La codificación inicial de los códigos del octeto y de las asignaciones del carácter para UTF-8 es constante con el ASCII, así que la conversión directa de estos campos a UTF8 no debe traer demasiado problema.
- Corrija el archivo de wp-config.php para agregar en definiciones de DB_CHARSET y de DB_COLLATE. Agregue las dos líneas siguientes, preferiblemente bajo sección de los ajustes de MySQL:
defina (' del `utf8 de DB_CHARSET',);
defina ('DB_COLLATE', ");Según lo explicado en el códice de WordPress, DB_COLLATE se deja en blanco (falta de información) de modo que la colación de la base de datos sea asignada automáticamente por MySQL basado en el juego de caracteres de la base de datos.
- Reconstruya los índices y/o los índices CON TEXTO COMPLETO caído, si cualquiera.
- Active el blog nuevamente dentro de modo de producción.
- Compruebe su blog para ver si todo y cada los caracteres es aceptable.
- Suprima la escritura del PHP.
IMPORTANTE: La página es traducida por computador y con tal que como está sin garantía. La traducción automática puede ser difícil de entender. Refiera por favor al artículo inglés original siempre que sea posible.
Artículos relacionados
- IMP-00016 requirió error no apoyado de la conversión del juego de caracteres cuando importación a la base de datos de Oracle
- Cómo modificar para requisitos particulares, modifique o cambie la página del error de la conexión de base de datos de WordPress
- Problema de la codificación de WordPress Charset después de aumentar a la versión 2.2
- Compruebe y optimice la base de datos de MySQL automáticamente con Crontab/Cron
- Cómo mover el blog de WordPress al nuevo dominio o localización
- La base de datos de los trabajos de Microsoft del convertido (.wdb) a CSV o Excel sin trabajos instaló
- Error de Oracle EXP-00091 cuando base de datos de la exportación
- Error de la pregunta de WordPress MySQL SQL en clase de WPDB
- Poste o página de WordPress de la paginación o de la fractura con NextPage en WordPress que no trabaja
- Cómo enumerar y demostrar los postes de WordPress que comenta y los silbidos de bala de (no permitir)