[wp-trac] [WordPress Trac] #32190: mb_strlen doesn't account for encoding

[WordPress Trac]

#32190: mb_strlen doesn't account for encoding
--------------------------+-----------------------------
 Reporter:  kraftbj       |      Owner:
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  General       |    Version:  4.2
 Severity:  normal        |   Keywords:
  Focuses:                |
--------------------------+-----------------------------
 In [32114], a `mb_strlen` function was added that only accounts for UTF-8
 with a note that if you need other encoding to use regular `strlen`.

 Plugins may already been using mb_strlen primarily with a different
 encoding that results in unexpected behavior when the compat function
 fires.

 Case in point: WP Super Cache uses Gzip compression as an option to
 deliver cached files and uses `mb_strlen($data, '8bit')` when
 function_exists to determine the length for the headers. With 4.2, sites
 lacking native mb_strlen return 0, breaking delivery. With WPSC, if
 `mb_strlen` was not present, then defaulted back to `strlen`.

 Ideas: If an unsupported encoding is passed, return strlen instead?

 WPSC tracker: https://github.com/Automattic/wp-super-cache/issues/32

--
Ticket URL: <https://core.trac.wordpress.org/ticket/32190>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform