PHP - Strlen behaves very strange, the same things - different results, lol numbers?

Question

tresc and tresc_pelna

The same type, the same content

The same content. 876 characters in total.

Taken from db by ...AS data_dodania, p.data_modyfikacji, p.tresc, p.tresc_pelna, p.url, count(k.id)...

Echeon to website by <?= strlen($post['tresc_pelna']).'----'.strlen($post['tresc']) ?>

And guess what?

This is the output

876----3248

What the...?

I have completly no Idea what is happening here xD.

Please help guys :D

Both fields utf8_polish_ci and exactly same content

<?= mb_strlen($post['tresc_pelna'], 'utf-8').'----'.mb_strlen($post['tresc'], 'utf-8') ?>

Still bad result.

tresc over 3 thousands... what the... How? why?

@tkausl both are `utf8_polish_ci` And both have exactly the same content — Krystian Polska, Sep 22 '17 at 18:47
And the character sets aren't changed manually? I.e., they are both `utf8`? — tkausl, Sep 22 '17 at 18:48
Don't copy/paste data in and out of mySQL, especially that god-awful disaster that is phpMyAdmin. You're likely ruining the character encoding. You should also [read up on what UTF8 actually is](https://stackoverflow.com/questions/7048745/what-is-the-difference-between-utf-8-and-iso-8859-1/39109074#39109074). — Sammitch, Sep 22 '17 at 19:12

score 0 · Answer 1 · answered Sep 22 '17 at 19:29

MySQL has two built-in functions for determining the length of variable-length items. One, which counts distinct unicode characters, is called CHAR_LENGTH(). The other counts octets (bytes), and is called LENGTH().

In PHP, strlen() counts octets, like MySQL's LENGTH(). Many unicode strings, especially those encoded in utf8, have a variable number of octets per character. You can use grapheme_strlen() to count those.

I've found it's sometimes helpful to do SELECT HEX(unicode_column) to figure out what's stashed in MySQL. Just fetching the column data puts you at the mercy of the character rendering of the MySQL client you use, and can be very confusing.

It's also possible your database columns have entitized data in them (for example the string é rather than the Unicode character é. If that entity text gets sent to a web browser, it renders as the letter.

score 0 · Answer 2 · answered Sep 23 '17 at 14:58

The difference between LENGTH and CHAR_LENGTH could explain a ratio of under 1.2x for most European text. It won't explain 3248:876, which is nearly 4x.

Perhaps these are part of the answer:

Htmlentities, such as ó which is taking 8 bytes to represent a 2-byte utf8 character. We can't see whether one of them has < and the other has <.
Formatting tags, such as <p>. Again, possibly <p>

Still, that is not enough to explain nearly 4x. For example, a simple letter, such as a, will be one byte, regardless of how it is encoded. Please provide the HEX for a small sample.

PHP - Strlen behaves very strange, the same things - different results, lol numbers?

2 Answers2