• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 432
  • Last Modified:

character causes line break

From a form Japanese text for an ad is input into a flat database. Before it is added the content is displayed for confirmation.
Everything is right except that I have a problem with one specific character (input at $type), which is to be repeated in each ad at the beginning.
It can be input, the confirmation script displays it properly, and it is also correct in the flatfile. However, as soon as it is displayed in a table on a page where all ads are listed, that specific character gets garbled (disappears) and the rest of the word jumps to the next line. Other characters do not cause this problem.
I assume that the script takes part of the character code of this specific character as a part of the script for some reason. Is there a way to prevent this?
0
ppblue
Asked:
ppblue
  • 4
  • 2
  • 2
  • +1
1 Solution
 
lexxwernCommented:
well it seems that the variable contains <br>  or  <p>; these are the linebreak/parabreak tags in html which maybe causing the problem; please try to avoid these;


lexxwern
0
 
ppblueAuthor Commented:
The variable = $type ?
There are no breaks. What I meant is that the character itself contains some code that is mistaken by the script to be a part of it. The script code for this input is:

     {$type="$field[0]";}
and

With other characters the display is normal and the table shows the word as characters (1)(2), on the same line, where (1)(2) is one word.
If that specific problem character is used it is:
.          <-- line 1
(2)        <-- line 2

Which means that not only appears a "." instead of the character, but a break is entered. My question is, is there a way to tell the script that "(1)(2)" must be rendered intact as a unit?  To me it seems that some underlying character code related to Far Eastern encoding may be affecting the display script, not that the script itself is the problem. Actually, I tested with two different scripts, and the problem is the same with both.
0
 
PeeweeCommented:
ppblue,
i am having problems fully understanding your problem, and hence even more providing a uselfull solution.

can you paste the oofending text here with your current code, you will receieve a solution much quicker this way.

regards
Peewee
0
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

 
ppblueAuthor Commented:
I have put the simpler script at www.trans-direct.net/testing/display.txt

The problem occurs when the Japanese for "Translation" is input where $type is. Actually, it is only the first character that causes the problem (see above).
0
 
PeeweeCommented:
ppblue,
can you provide an example txt file and an example parameters to which this script is called.

many thanks
Peewee
0
 
ppblueAuthor Commented:
Please clarify what you meant with txt file.
If you mean a database file, you can put " –|–ó " at the beginning of a line and then add pipes for each field (on the same line). The other fields are irrelevant as there are no required fields set, and they do not seem to cause problems. " –|–ó "  is the input in the first field.  " –| " is the character causing the problem. If you use " ’Ê–ó " instead, for example, everything is all right.
0
 
BigRatCommented:
I personally would do :-

print "Content-type: text/html; charset=Shift_JIS", "\n\n";

to ensure that the browser accepts the stream in Shift_JIS. The actual default is ISO-8898-1 and the META tag should override this, BUT I have had problems here.

What exactly is the Japanese JIS byte code (in hex) for "translation"? (For example the first table element contains 95 E5 8F 57 90 45 8E ED)
0
 
ppblueAuthor Commented:
Hi BigRat,
>What exactly is the Japanese JIS byte code (in hex) >for "translation"? (For example the first table
>element contains 95 E5 8F 57 90 45 8E ED)
If I knew where to check.  My CJK input program shows a Shift JIS code of 967C for the first and 96F3 for the second character, but no hex code is mentioned.

>to ensure that the browser accepts the stream in >Shift_JIS. The actual default is ISO-8898-1 and the
>META tag should override this, BUT I have had problems >here.
I assure you that the Japanese displays perfect otherwise, on my English Windows. It's just that character.
Is it not possible to prevent a script from touching a certain character string, but having it write it to the field as is? As the input is done by selection via a drop down box, there is no unpredictable input in this field.
0
 
BigRatCommented:
I take it that the Japanese for "translation" is two characters represented (as a hex sequence) by 96 7C 96 F3.
I note that the second character is 7C which is the pipe symbol "|". Obviously when Perl "substitutes" the $type it interprets the contents and finds a 7C and all goes wrong!

I'm not a Perl man, but I know for a fact that it is NOT JIS enabled. Ie: it does NOT know that the sequence of bytes is actually a MBCS.

The obvious way out if to output the text in a manner which does not involve this substitution. Perhaps a non-pipied print statement?

A long way round is to use HTML entities, but that involves converting JIS to Unicode and that to &#x1234; sequences. There is a Windows API function to do the first, but I've no idea if it is callable from Perl.

Larry Wall calls Perl a PRACTICAL Extraction and Reporting Language, but I find it all a bit too cryptic!

HTH
0

Featured Post

Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

  • 4
  • 2
  • 2
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now