What is the usefulness of mb_http_output() given that the output encoding is typically fixed by other means? -

all on internet, including in stackoverflow, suggested use mb_http_input('utf-8') have php works in utf-8 encoding. example, see php/mysql encoding problems. � instead of characters. on other hand, php manual says cannot fix input encoding within php script , mb_http_input way query is, not way set it. see http://www.php.net/manual/en/mbstring.http.php , http://php.net/manual/en/function.mb-httpetinput.php . ok, clarification of context before question. seems me there lot of redundant commands in apache + php + html control conversion input encoding internal encoding , output encoding. don't understand usefulness of this. example, if original input encoding external http client euc-jp , set internal encoding utf-8, php have make conversion. right? if right, why set input encoding in php.ini (instead of passing original one) given next converted utf-8 internal encoding anyway? similar question hold output. in htpp files, use meta tag charset=utf-8. so, output http encoding fixed. moreover, in php.ini, can set default_charset appear in http header utf-8. why bother use mb_http_output('uft-8') when final output encoding fixed. sum up, can give me practical concrete example mb_http_output('uft-8') necessary , cannot replaced more usual commands inserted default in editors such dreamweaver?

these 2 options worst idea php designers ever had, , had plenty of bad ideas when comes encodings.

to convert strings to specific encoding, 1 has know encoding 1 converting from. incoming data in undeclared encoding; server receives binary data, doesn't know encoding represents. should declare encoding expect browser send setting accept-charset attribute on forms; doing no guarantee browser , doesn't make php know encoding expect though.

the same goes output; php strings byte arrays, not have associated encoding. have no idea how php thinks knows how convert arbitrary strings specific encoding upon input or output.

you should handle manually, , it's easy anyway: declare clients encoding expect, check whether input in correct encoding using mb_check_encoding (not _detect encoding or such, check), reject invalid input, take care keep in same encoding within whole application flow. i.e., ideally have no conversion whatsoever in app.

if do need convert @ point, make unicode sandwich: convert input expected encoding utf-8 or unicode encoding on input, convert desired output encoding upon output. whenever need convert, make sure know you're converting from. cannot magically "make strings utf-8" 1 declaration.