The following Symbols prints well in an MS Excel spreadsheet when outputting using VBA:
Sub print_chrw_sub()
Dim a1
a1 = "&H27E6"
ActiveCell.Offset(1).Value = ChrW(a1)
Dim a2
a2 = "&H27E7"
ActiveCell.Offset(2).Value = ChrW(a2)
End Sub
Output:
⟦
⟧
However, when I am using the symbols in a PHP code, the sybols look like square blocks within the code as well as on a web browser - also in the current usage above. Example:
<?php
echo $str1 = "⟧"
?>
I am using UTF-8 encoding.
On the flip side the following sybols are printing correctly in PHP code as well as on a web browser:
chrW(&H22A4)
Output:
⊤
chrW(&H22A5)
Output:
⊥
Thanks for any help.
The character you refer as chrW(&H27E7) is known as the Mathematical right white square bracket (or U+27E7).
When it is displayed in Excel, the font displayed is probably Calibri or Arial, but these fonts actually don't support this character.
And that's where font substitution steps in: to provide a font wich will correctly handle the character.
If you look at this page, you will see which fonts on your system actually support U+27E7. On my system there is only two: Cambria Math and Segoe UI Symbol.
If you see a square symbol (□), it means that font substitution didn't work correctly. For the PHP source, it is not very important, because the correct character will actually be there (provided the encoding is set up correctly).
For the HTML code, you should consider setting a font which you know support this character, be keep in mind that local fonts (the ones installed) differ vastly between two systems. You may want to use the CSS font-face to provide a web font.
Related
I have this code (degree symbol encoded as HTML):
<a download="text.txt" href="data:text/plain,°">Download degree symbol</a>
What I do
Click the link
Save the file
Open it in TextPad
Problem: I see °, instead of the expected ° (When I do a hex dump I get b0c2)
How do I fix this?
My context is I have a PHP-encoded $string = "°". but for purposes of this example I stripped it down and inserted degree into HTML link directly. I tried using utf8_decode() with same results as above.
I need to open the resulting file in a legacy Windows application that seems to read ASCII only (aka displays ° like above and I need to only have it display the degree symbol).
Courtesy of ... cor-el of Mozilla Support, use this:
data:text/plain;charset=iso-8859-1,%b0
I'm using SimpleXML to read nodes, and I echo out the image file name. Using foreach, I print them out:
assets/project_Guide2Big1.jpg
assets/project_Guide2Big2.jpg
assets/project_Guide2Big3.jpg
assets/project_Guide2Big4.jpg
assets/project_Guide2Big5.jpg
I inserted these values into my img tags, but the images don't appear except for the first one.
I copy "assets/project_Guide2Big1.jpg" into the browser. I see the image, but when I copy "assets/project_Guide2Big2.jpg", the address changes to this
asset/%E2%80%8BprojectGuide2Big2.jpg.
It looks like some urlencoding(?). I tried to decode, but my images still aren't working. This is so wierd.
Were does the %E2%80%8B come from?
That looks suspiciously like a UTF-8 character sequence representing some Unicode character which you didn't expect to be there.
Using this online converter, we can see that the sequence of UTF-8 bytes E2 80 8B represent the Unicode codepoint U+200B, which is a "Zero Width Space".
So somehow, your source XML includes an invisible character after the slash. When echoed to the screen, it is completely invisible - even when viewing source, since the source is still just text. But when you try to load the URL, that character is outside the valid range for URLs, so gets automatically encoded by the browser.
You might be wondering what the point of a zero-width space is, but consider automatic word-wrap functions - they may look for a space to break on, but a URL contains no spaces. So inserting a zero-width space makes the text look the same, but allows it to wrap at that specific point. Another character useful for this is the "soft hyphen", which has the beautifully apt entity name of - as a friend of mine put it, "the soft hyphen is shy, and may not appear". :)
I have a government client that requires the legal 'section symbol' (§) in their documents. When creating the documents in a web page, this symbol is created with § or §.
I can not figure out how to get either of these to work in a pdf document created with FPDF. I have tried the iconv and utf8_decode methods, but neither have worked. Any ideas?
You're looking for html_entity_decode().
There is an easier approach to do this:
You can generate a section symbol using FPDF with using ascii code: chr(167).
It's good practice to make this a constant. At the top of your script, add:
define('SECTION',chr(167));
Now you can use SECTION in your script to print the euro symbol.
For example:
echo SECTION.'1.1';
Will output: §1.1
Note: This will also work for other symbols with chr(ascii), where ascii is the ascii code of the symbol. You can find an overview of ascii codes on this page: http://www.atwebresults.com/ascii-codes.php?type=2
Here's a link I found, which even has a character I need to play with for other projects of mine.
http://www.fileformat.info/info/unicode/char/2446/index.htm
There is a box with the Title of: "Encodings" on that page. And I am wondering about some of the rows.
I obviously need a course on this sort of thing, but I'm wondering what the difference is between "HTML Entity (decimal)" and "HTML Entity (hex)".
The funny thing is, which confuses me, I throw those characters on a web page, and they display fine. But I haven't specified any UTF-8 encoding in the php page.
<?php
$string1 = '⑆';
$string2 = '⑆';
echo $string1;
echo '<br>';
echo $string2;
?>
Does the browser know how to display both automatically?
And to make it weirder, I can only see those characters on my Mac, in Firefox.
But my windows box doesn't want to show them. I've tested it in chrome, and firefox. Do I need to tell the browsers to view them correctly? Or is it an operating system modification?
They're both valid numeric HTML entities, and the browser does indeed know how to decode them. The difference is the first is a hexadecimal number, while the latter is decimal.
0x2446 = 9286
Note that 0x means hexadecimal.
Also note that it is good practice to always have your server explicitly specify an encoding. The W3C explains how to do so. UTF-8 is a good choice.
If you use any Unicode encoding, you can always put the character right on your page, so you don't have to use entities.
To be exact, neither is an entity reference. & is an entity reference that refers to the entity named amp that is defined as:
<!ENTITY amp CDATA "&" -- ampersand, U+0026 ISOnum -->
Here you can see that the entity’s value is just another reference: &.
⑆ and ⑆ are “just” character references (numeric character references to be exact) and refers to characters by specifying the code position of a character in the Universal Character Set, i.e. the Unicode character set.
You can use any "HTML Entity" in any encoding and in practice, if You have installed appropriate fonts, every browser will work fine. Well, it was created for displaying characters that are not included in current encoding. In Your situations it looks You have to install some fonts on Your Windows box.
On the other hand, it has almost nothing to do with PHP.
i have tried to copy euro symbol from Wikipedia...and echo it (in my parent page),at that time it is working.but when i replace the same html content using jquery(used same symbol to echo in the other page).it is not displaying.why is it so..(or is der any way to display the same thing using html)?
In HTML you do this
€
And of course this works with jQuery, or any other web based language you are using
For more information look here
You need to ensure that your data is encoded using $X, that your server claims it is encoded using $X, and that any meta tags or xml prologs you may have also claim it is encoded using $X.
... where $X is a character encoding which includes the euro symbol. UTF-8 is recommended.
The W3C have an introduction to character encoding.
You can bypass this using HTML entities (€ in this case), which let you represent characters using ASCII (which is a subset of pretty much any character encoding you care to name). This has the advantage of being easy to type of a keyboard which doesn't have that character, but requires a tiny bit more bandwidth and will make it hard to read the source code of documents which include a lot of non-ASCII characters.
Note that HTML entities will only work when dealing with HTML. You'll find it breaking if you try things such as $(input).val('€').