Tag Info

Hot answers tagged

14

< and > are encoded as +ADw- and +AD4- in UTF-7. Now imagine the following: Someone sends +ADw-script+AD4-alert(+ACI-Hello+ACI-)+ADw-/script+AD4- as comment text. It will pass all validation unescaped. The database expects and treats all incoming data as UTF-8. Since all UTF-7 streams are valid UTF-8 too, this will never result in a SQL error, and ...


8

See the discussion for Taxonomy Short Description for a better way to shorten a string. I’m not aware of a WP function that is getting truncation right. Here is my code based on the linked discussion: /** * Shortens an UTF-8 encoded string without breaking words. * * @param string $string string to shorten * @param int $max_chars maximal ...


6

Interesting question. This could be a useful part of a specific language file. It cannot be done in CSS, because CSS is (mostly) character agnostic. But using a filter and PHP it is possible and on topic: add_filter( 'the_content', 't5_chinese_spacing' ); function t5_chinese_spacing( $content ) { return preg_replace( ...


4

After spending the entire day working on this, I finally found a guide that worked perfectly: http://www.blogsuccessjournal.com/blog-tips-and-advice/wordpress-tips-advice/seeing-weird-characters-on-blog-how-to-fix-wordpress-character-encoding-latin1-to-utf8/ Before that, I tried following @Rarst's information, tried exporting the database and manually ...


3

My guess is that you pasted something from a Windows environment and that's the CR (carriage return, I think) character. I'd go into the editor and just remove those line breaks. That should fix the problem. Also, you might look into standardizing the content type meta tag. You've got <meta charset="UTF-8" /> I could be wrong about this, but in ...


3

So after about a year (on and off!) I had managed to hopefully get a fix on encoding issue. Why it breaks What my experience boiled down to, is that encoding issue like this are mostly caused by miscommunication when moving data around. in best case this is read mismatch, when correct data is wrongly interpreted in worst case that is write mismatch, when ...


3

Your browser doesn’t send the copied text UTF-8 encoded to the server. On the first character that isn’t UTF-8 compatible, in your example the apostrophe – ’ –, the stream to the data base is broken and not recovered. That’s a browser issue. If I had to guess – well, I have because you didn’t mention it – I would say Internet Explorer. There are two ways to ...


3

According to this page, you can use the tiny_mce_before_init filter, make sure the entity encoding is set to named, and then add whichever special characters you want to the entities array.


3

It happens because when you save a post, WordPress calls sanitize_title function to sanitize your title. This function applies sanitize_title filter. One of core hooks for sanitize_title filter is sanitize_title_with_dashes function, which checks title on utf8 format by calling seems_utf8 function and if the title has utf8 format, the function call ...


3

This is typically caused when you are copying/pasting MS Word information into the WordPress content editor. WordPress uses something called "Smart Quotes", via a function named wptexturize(). Ideal Solution The ideal solution would be to go back through your content, and replace all single/double quotes using the keyboard. However, if you're working ...


2

This might be a limitation of JavaScript. 𪇆 is U+2A1C6 in Unicode, and codepoints above U+FFFF (which need four bytes) are coded via UTF-16 surrogates. And that … sucks. The canonical bug for that in WordPress is #13590 Inserting a 4-byte UTF-8 character truncates data. It was closed as maybe later, because fixing it would require a change in the database ...


2

UNIX line endings (\n) and UTF-8 are just common code standards. As far as I can see, they are not even mentioned in the Coding Standards. Most (all?) core PHP files are just plain US-ASCII. Try to follow that path to keep your files as compatible as possible. If you use UTF-8, add a line at the start of a PHP file with an Encoding Cookie or file variable: ...


2

Thanks, fdsa! For posterity, here's the actual code I used. It adds copyright, registered, trademark, service mark and euro to the array of allowed entities. I'm confused as to why some of these aren't in there by default, as they're really common. But in any case, this works: // Custom configuration for TinyMCE function wpsx_54398_configure_tiny_mce( ...


2

There are $wpdb->charset and $wpdb->collate. I am not sure if or when one of these values might be empty, so it is better to prepare for empty values … From my DB class: /** * Get table charset and collation. * * @since 2012.10.22 * @return string */ protected static function get_wp_charset_collate() { global $wpdb; $charset_collate = ...


2

The reason commenting out (see q ) didn't work is that the data was wrong in the database, so no encoding change could fix it. I restored the database by copy pasting the sql script into PHPMyAdmin, and the text box interpreted the text as having the wrong encoding. By using import in phpmyadmin and selecting the file, that data came in correctly.


2

To output JSON always the function json_encode( $string ). The function is not available on all hosts. Don't worry, WordPress offers a fallback in wp-includes/compat.php. That's a wrapper for class Services_JSON::encodeUnsafe() (see wp-includes/class-json.php). If you take a look at the source you'll see: It's not a trivial job to encode a string. :) There ...


2

Try this: $title = get_post_field('post_title', $post_id, 'raw'); However I'd get to the bottom of what encoding reddit code would prefer. Echoing raw stuff is poor idea for security.


2

Try this (not tested, I hope I am not short circuiting it into endless loop): add_filter('sanitize_user', 'non_strict_login', 10, 3); function non_strict_login( $username, $raw_username, $strict ) { if( !$strict ) return $username; return sanitize_user(stripslashes($raw_username), false); }


2

The problem is an invalid UTF-8 character in the excerpt <description>. The text is cut off in the middle of a multi-byte character, rendering your complete feed invalid. You get a slightly hint when you look at it in Opera. Do you filter 'bloginfo_rss' or 'get_bloginfo_rss'? Disable all plugins and look if the feed is still broken.


2

There's a big chance you can fix this by adding 1 line to your .htaccess file AddDefaultCharset off Alternatively replace "off" with the actual charset you want to use.


2

Omar, A good article about charsets can be found at http://codex.wordpress.org/Converting_Database_Character_Sets. Unless you have very specific requirements to the languages you are using, you will want to use charset utf8 with collation utf8_general_ci. The default WP settings are OK for this. I.e. charset definition in wp-config.php will be UTF-8. No ...


1

Take a look at my answer for Word press replacing unicode characters with "?"s. Amongst others you could take look at the mentioned Codex article Converting Database Character Sets. You should really stick to UTF8 unless there's a very good reason not to do so. If code and DB are all in sync using UTF-8, you shouldn't have any problems with German ...


1

You need to filter 'sanitize_title' and use the second argument, the raw title. See my plugin Germanix for an example.


1

Consider this function as a rough placeholder. It has more flaws than you might imagine … :) There are many plugins to improve the conversion for different languages and needs. You may take a look at my plugin Germanix to see how this could be done.


1

It's used by sanitize_text_field function to Sanitize a string from user input or from the db.


1

Maybe you should consider option C). Convert all accented characters to normal UTF-8 characters. So EXPRESSÃO.jpg -> EXPRESSAO.jpg I think this would help you a lot, not only when it come sto coding and file systems, but also storing names / references in databases. Update This is a function I use for removing accents. I found this solution somewhere on ...


1

The content you get is not utf-8 encoded or the encoding is damaged by the importer. Usually SimplePie – the feed reader WordPress uses – is quite good at handling such cases. I wonder what an importer you use … Anyway, I’ve written a function to enforce utf-8 output. You should implement this very early in the import process. The article is in German – let ...


1

It seems that the "convert_chars" filter is causing the trouble, try removing it by: remove_filter( 'the_content', 'convert_chars' ); Also try removing the richedit_pre hook (which formats the text for the rich text editor, also uses convert_chars function) by: remove_filter( 'the_editor_content', 'wp_richedit_pre' ); Hope that helps!


1

After doing a little searching on this problem, It's my understanding that the data is actually encoded in utf-8, but being handled like latin. You just need to trick it into reading it correctly with a little juggling. Try this: Export the db in its current state, copy the dump file for backup. Create a new database usng utf-8. Change the character set ...



Only top voted, non community-wiki answers of a minimum length are eligible