Yasuo Ohgaki wrote:
>
> Then you may be feeding messages with encoding other
> than internal encoding to mb_send_mail?
If that's the case, the question is how?
Nothing has changed in my code, except for the need to substitute mail()
for mb_send_mail(). Under 4.2.2, mb_send_mail() was needed to send
exactly the same output that now requires mail().
Here are the relevant sections of my php.ini (I am running on an English
version of Red Hat Linux 6.2 - without canna or any other Japanese
language software):
output_buffering = On
;output_handler = mb_output_handler
default_mimetype = "text/html"
default_charset = "Shift_JIS"
[mbstring]
; language for internal character representation.
mbstring.language = Japanese
; internal/script encoding.
mbstring.internal_encoding = EUC-JP
; http input encoding.
mbstring.http_input = auto
; http output encoding. mb_output_handler must be
; registered as output buffer to function
mbstring.http_output = SJIS
mbstring.encoding_translation = Off
; automatic encoding detection order.
; auto means
mbstring.detect_order = auto
; substitute_character used when character cannot be converted
; one from another
mbstring.substitute_character = none;
; overload(replace) single byte functions by mbstring functions.
;mbstring.func_overload = 0
As you will see, both output_handler and mbstring.func_overload are
commented out. The PHP documentation states that SJIS users should set
output_handler to mb_output_handler, but that produces mojibake.
Moreover, Moriyoshi-san commented about my php.ini on 5 January, "I see
no problem in this". This point needs clarification. If there is no
problem, why does the documentation say the exact opposite? The problem
may, of course, be with my understanding of what the documentation
means, but if that's so, I'm sure others are likely to encounter similar
difficulties.
The only thing I can think of is that, during configuration, I
included --enable-mbstr-enc-trans, which I have subsquently seen is no
longer used. The compilation process produced no error messages in this
regard, so I presumed its inclusion would have caused no harm. Is this a
likely cause of the unexpected behaviour?
David Powers
--
PHP Internationalization Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
