Closed Bug 65022 Opened 24 years ago Closed 24 years ago

Unable to copy combination of Japanese and English encoded text

Categories

(Core :: Internationalization, defect)

x86
Windows ME
defect
Not set
normal

Tracking

()

VERIFIED WONTFIX

People

(Reporter: locke, Assigned: nhottanscp)

References

()

Details

From Bugzilla Helper: User-Agent: Mozilla/4.75 [en] (Win95; U) BuildID: 2001010901 When using CTRL-C or a highlight-right-click-menu-access to copy passages of text encoded both in English and Japanese, only the English segments are properly copied; Japanese either comes out as question marks or simply vanishes when pasted into a Japanese-capable text editor. Attempts to copy direct Japanese encoding have failed as well, with the same results. Reproducible: Always Steps to Reproduce: 1. Make sure that character coding is set to Auto-detect (Japanese) or one of the three main types of Japanese encoding (listed page is in Microsoft Shift-JIS). 2. Load page, then simply copy by any possible means (CTRL-C, context menu, menu bar, etc.) 3. Paste into either a Japanese-capable text editor or if one isn't available, paste into an ASCII editor like Edit or Notepad. For the latter, you should get "garbage" ASCII (English Windows doesn't come with Japanese font support). Actual Results: The Japanese text was stripped from the document, leaving Arabic numerals, line breaks, and the occasional English word. The first paragraph of the "Ryouri" section on the listed example page, for instance, comes out as (enclosed in quotations): " Cooking (English translation coming soon) " As you can see, only the English and some line breaks were left in this case. Expected Results: Japanese text should have been preserved in the original encoding used by the page author and copied over with the "normal" ASCII material. The passage quoted in the above should have come out, for instance (copied from the source in Netscape 4.7; you may need a Shift-JIS viewer to see this correctly): —¿—? Cooking (English translation coming soon) ‚±‚ê‚Í‚©‚È‚è‹ê˜J‚µ‚Ü‚µ‚½?B‚½‚©‚ª?HŽ–?A‰p–ó‚·‚é‚Ì‚ÍŠÈ’P‚¾‚Æ’N‚Å‚àŽv‚¤‚©‚à‚µ‚ê‚Ü‚¹ ‚ñ‚ª?AˆÈŠO‚ÆŽžŠÔ‚ªŠ|‚© ‚è‚Ü‚·?B–â‘è‚͉pŒêŒ—‚É‚È‚¢—¿—?‚ª?o‚Ä‚«‚½Žž‚Å‚·?BŠm‚©‚É?lŠÔ‚Ì?H‚ׂé‚à‚Ì‚Å‚·‚©‚ç?A —¿—?‚Ì?Þ—¿‚Æ’²—??s’ö‚ð?à–¾ ‚·‚ê‚Î’N‚É‚Å‚à?à–¾‚Å‚«‚Ü‚·‚ª?A‚»‚ê‚ł͈ꕶ‹å‚¾‚Á‚½‚à‚Ì‚ª’·‚¢•¶?͂ɉ»‚¯‚Ä‚µ‚Ü‚¤‚Æ Œ¾‚¤‚±‚Æ‚Å‚·?B I would suspect that this would affect other double-byte/high-byte encodings (Korean, Chinese) as well, as they use a similar method of processing and display in theory.
Sending to i18n for further triage
Component: XP Toolkit/Widgets → Internationalization
reassigning to component owner, cc pinkerton. What product/version/build is this happening in? Just WinME, or other OS?
Assignee: trudelle → nhotta
QA Contact: jrgm → teruko
>User-Agent: Mozilla/4.75 [en] (Win95; U) Is this bug filed for 4.75?
No, it's for 0.7; build 2001010901. I used Netscape to post the bug becuase I'm having problems with bug 56581, which prevents multiple uses of Mozilla in ME, and Mozilla had crashed the first time I had submitted, so... In any case, I had already submitted build number with my first post.
Something else in response to the question about system - this problem seems to affect at least Win98 as well; I just tested it on my '98 box, and results are the same as in ME. If it helps, I'm running English (well, American) Windows on both systems.
We convert to system's charset (ACP) if unicode clipboard is not available. So this is an expected behavior under Win98 but it works under WinNT.
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → WONTFIX
Verified as wonfix.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.