Why does C:¥Users show a yen sign instead of a backslash?

It's still a backslash. Japanese Windows fonts draw the backslash as ¥ because JIS X 0201, the old Japanese version of ASCII, put the yen sign in that slot. So C:¥Users is the same path as C:\Users, and code that splits on the backslash still works. Problems start only when a converter swaps it for the real ¥, U+00A5, which breaks paths and escapes like \n.

Why do prices show Â¥ instead of ¥ in Excel?

Excel opened a UTF-8 CSV as Windows-1252, which splits ¥ into its two bytes and shows them as Â and, oddly, ¥ again. That's what happens on double-click when the file has no byte order mark. Have whatever generates the CSV write a UTF-8 BOM at the start, or load it with Data > From Text/CSV and pick UTF-8 as the file origin.

How do I tell whether ¥ means yen or yuan?

The symbol alone won't tell you, so the currency code or a prefix has to: 500 JPY or JP¥500 for yen, 500 CNY or CN¥500 for yuan. Formatters built on CLDR data handle this per locale. English shows yen as plain ¥ and yuan as CN¥, while Chinese flips it, with yuan as ¥ and yen as JP¥.

Should Japanese prices say ¥1,000 or 1,000円?

In Japanese text, 1,000円 with the kanji after the number is the everyday form, on menus and receipts alike. The ¥ prefix turns up in more formal or international settings, such as price tags aimed at visitors and English-language pages. Choose by audience: 円 for Japanese readers, ¥ for everyone else.

Why doesn't ¥ match ￥ in my data?

One is the regular yen sign, U+00A5, and the other is the fullwidth ￥, U+FFE5. Japanese input methods type the fullwidth one, and formatting with a ja-JP locale produces it too, while en-US gives the narrow ¥. NFKC normalization maps ￥ to ¥ and fullwidth digits to ASCII, so run `s.normalize('NFKC')` before comparing or parsing.

Why do names like MU¥OZ show up in my database?

They came out of a DOS program and were imported as Windows-1252, which reads the DOS Ñ as ¥. If you still have the export, import it again as code page 850. If the rows are already saved, replacing ¥ with Ñ (and ¤ with ñ) repairs the Spanish names, as long as no column you touch holds a real yen sign.

ASCII 165

Yen signUppercase N with tilde

ASCII 165 is ¥ on Windows and Ñ in old DOS.

¥ (Yen Sign) is byte 165 in Windows-1252, Unicode U+00A5. It's the sign for the Japanese yen and the Chinese yuan, and Japanese text also writes prices with the kanji 円 after the number, as in 1,000円. Scraped prices bring a lookalike with them. Japanese and Chinese input methods can produce the fullwidth ￥ (U+FFE5), which a regex looking for ¥ won't match. NFKC normalization folds ￥ into ¥, so normalize before you parse. Old DOS had the yen sign too, at 157. In UTF-8 it's C2 A5, and the HTML entity is ¥.

Ñ (Capital N with Tilde) is byte 165 in code page 437, the original IBM PC character set, and maps to Unicode U+00D1. Windows-1252 has the yen sign ¥ at 165, so capitalized Spanish from a DOS system read as Windows-1252 turns MUÑOZ into MU¥OZ and ESPAÑA into ESPA¥A. Code page 850 kept Ñ at 165 too. Small ñ is 164 in DOS.

CurrencyLatin Letter

Technical Details

Code Example

</>

#include <stdio.h>

int main(void) {
    /* On Windows (code page 1252) byte 165 is ¥.
       Modern terminals expect UTF-8, so print the code point, not the byte. */
    printf("\u00A5\n");   /* UTF-8: C2 A5 */

    unsigned char b = 165;         /* the raw Windows-1252 byte */
    printf("%d 0x%02X\n", b, b);    /* 165 0xA5 */
    return 0;
}

Code Example

</>

#include <stdio.h>

int main(void) {
    /* Byte 165 is Ñ only on a console using code page 437
       (chcp 437 on Windows, or DOSBox). On a UTF-8 terminal the
       lone byte 0xA5 is invalid and prints as garbage, often �. */
    putchar(165);

    /* char is signed on x86, so a plain char holding 0xA5 is -91.
       Use unsigned char when you compare or index by byte value. */
    char c = (char)165;
    unsigned char u = 165;
    printf("\n%d %d\n", c, u);   /* -91 165 */

    /* Portable: print the Unicode character as UTF-8 instead. */
    printf("\u00D1\n");          /* C3 91 */
    return 0;
}

How to Type It

Windows: Hold Alt and type 0165 on the numeric keypad, with Num Lock on. The leading zero picks the Windows code page. Alt+157, without the zero, types it too on US PCs. No numeric keypad? In Word, type 00A5 and press Alt+X.
Mac: Press Option+Y.
Linux: In GNOME, or any desktop running IBus, press Ctrl+Shift+U, type a5, then Space. With a Compose key set up, press Compose, y, equals.
Phone: iPhone: tap 123, then #+= and tap ¥. Android (Gboard): tap ?123, then =\< and tap ¥.

How to Type It

Windows: Hold Alt and type 165 on the numeric keypad, with no leading zero. Windows reads it as a DOS code and inserts Ñ.

Ñ is also ASCII 209 on Windows, which has the full guide.

Frequently Asked Questions

It's still a backslash. Japanese Windows fonts draw the backslash as ¥ because JIS X 0201, the old Japanese version of ASCII, put the yen sign in that slot. So C:¥Users is the same path as C:\Users, and code that splits on the backslash still works. Problems start only when a converter swaps it for the real ¥, U+00A5, which breaks paths and escapes like \n.
Excel opened a UTF-8 CSV as Windows-1252, which splits ¥ into its two bytes and shows them as Â and, oddly, ¥ again. That's what happens on double-click when the file has no byte order mark. Have whatever generates the CSV write a UTF-8 BOM at the start, or load it with Data > From Text/CSV and pick UTF-8 as the file origin.
The symbol alone won't tell you, so the currency code or a prefix has to: 500 JPY or JP¥500 for yen, 500 CNY or CN¥500 for yuan. Formatters built on CLDR data handle this per locale. English shows yen as plain ¥ and yuan as CN¥, while Chinese flips it, with yuan as ¥ and yen as JP¥.
In Japanese text, 1,000円 with the kanji after the number is the everyday form, on menus and receipts alike. The ¥ prefix turns up in more formal or international settings, such as price tags aimed at visitors and English-language pages. Choose by audience: 円 for Japanese readers, ¥ for everyone else.
One is the regular yen sign, U+00A5, and the other is the fullwidth ￥, U+FFE5. Japanese input methods type the fullwidth one, and formatting with a ja-JP locale produces it too, while en-US gives the narrow ¥. NFKC normalization maps ￥ to ¥ and fullwidth digits to ASCII, so run `s.normalize('NFKC')` before comparing or parsing.
They came out of a DOS program and were imported as Windows-1252, which reads the DOS Ñ as ¥. If you still have the export, import it again as code page 850. If the rows are already saved, replacing ¥ with Ñ (and ¤ with ñ) repairs the Spanish names, as long as no column you touch holds a real yen sign.

Frequently Asked Questions

They came out of a DOS program and were imported as Windows-1252, which reads the DOS Ñ as ¥. If you still have the export, import it again as code page 850. If the rows are already saved, replacing ¥ with Ñ (and ¤ with ñ) repairs the Spanish names, as long as no column you touch holds a real yen sign.

ASCII 165

Yen signUppercase N with tilde

ASCII 165 is ¥ on Windows and Ñ in old DOS.

Currency

Latin Letter

#include <stdio.h>

int main(void) {

/* On Windows (code page 1252) byte 165 is ¥.

Modern terminals expect UTF-8, so print the code point, not the byte. */

printf("\u00A5\n"); /* UTF-8: C2 A5 */

unsigned char b = 165; /* the raw Windows-1252 byte */

printf("%d 0x%02X\n", b, b); /* 165 0xA5 */

return 0;

}

#include <stdio.h>

int main(void) {

/* Byte 165 is Ñ only on a console using code page 437

(chcp 437 on Windows, or DOSBox). On a UTF-8 terminal the

lone byte 0xA5 is invalid and prints as garbage, often �. */

putchar(165);

/* char is signed on x86, so a plain char holding 0xA5 is -91.

Use unsigned char when you compare or index by byte value. */

char c = (char)165;

unsigned char u = 165;

printf("\n%d %d\n", c, u); /* -91 165 */

/* Portable: print the Unicode character as UTF-8 instead. */

printf("\u00D1\n"); /* C3 91 */

return 0;

}