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)
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.
Comment 1•24 years ago
|
||
Sending to i18n for further triage
Component: XP Toolkit/Widgets → Internationalization
Comment 2•24 years ago
|
||
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
Assignee | ||
Comment 3•24 years ago
|
||
>User-Agent: Mozilla/4.75 [en] (Win95; U)
Is this bug filed for 4.75?
Reporter | ||
Comment 4•24 years ago
|
||
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.
Reporter | ||
Comment 5•24 years ago
|
||
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.
Assignee | ||
Comment 6•24 years ago
|
||
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
You need to log in
before you can comment on or make changes to this bug.
Description
•