Ce n'est pas une communication en champ proche, c'est une composition canonique sous forme de normalisation.
Normalisation Unicode @ Wikipedia
En Unicode, Å et Å sont des caractères différents.
Ce dernier a l'odeur du Latin-1 en termes de chiffres. En fait, cela semble être vrai.
Lorsque NFC est normalisé, le ongstrom devient A avec un anneau supérieur. Vérifions cela avec Python.
>>> import unicodedata
>>> ord(unicodedata.normalize('NFC', '\N{ANGSTROM SIGN}'))
197
>>> unicodedata.name(unicodedata.normalize('NFC', '\N{ANGSTROM SIGN}'))
'LATIN CAPITAL LETTER A WITH RING ABOVE'
unicodedata est un module de bibliothèque standard. C'est un bonus, mais la normalisation NFD, dont on parle parfois sous macOS, comporte 2 caractères.
>>> len(unicodedata.normalize('NFD', '\N{ANGSTROM SIGN}'))
2
>>> [ord(ch) for ch in unicodedata.normalize('NFD', '\N{ANGSTROM SIGN}')]
[65, 778]
>>> [unicodedata.name(ch) for ch in unicodedata.normalize('NFD', '\N{ANGSTROM SIGN}')]
['LATIN CAPITAL LETTER A', 'COMBINING RING ABOVE']
En théorie, cette conversion peut poser problème. Par exemple, Shift_JIS peut exprimer "Angstrom" mais pas "A avec anneau supérieur". Si vous lisez des caractères à partir d'un fichier texte enregistré au format Shift_JIS, puis essayez à nouveau d'enregistrer au format Shift_JIS après la normalisation NFC, des problèmes peuvent survenir.
>>> with open('from.txt', encoding='shift_jis') as fr:
... with open('to.txt', 'w', encoding='shift_jis') as fw:
... fw.write(unicodedata.normalize('NFC', fr.read()))
Traceback (most recent call last):
File "<stdin>", line 3, in <module>
UnicodeEncodeError: 'shift_jis' codec can't encode character '\xc5' in position 0: illegal multibyte sequence
Si vous omettez de lire les fichiers non essentiels
>>> '\N{ANGSTROM SIGN}'.encode('shift_jis')
b'\x81\xf0'
>>> unicodedata.normalize('NFC', '\N{ANGSTROM SIGN}').encode('shift_jis')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'shift_jis' codec can't encode character '\xc5' in position 0: illegal multibyte sequence
Plus franchement:
>>> '\N{LATIN CAPITAL LETTER A WITH RING ABOVE}'.encode('shift_jis')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'shift_jis' codec can't encode character '\xc5' in position 0: illegal multibyte sequence
J'ai appris cet exemple dans "Introduction à la technologie de code de caractère pour les programmeurs", mais la raison est inconnue dans le même livre ("Pour une raison quelconque, ce n'est pas" p353).
Donc, il m'est arrivé de voir la description suivante sur Wikipedia.
Le symbole d'unité d'Ongstrom est ce caractère, mais Unicode et JIS X 0213 le définissent comme un caractère différent du caractère d'origine. Cependant, le symbole Unicode ongstrom U + 212B est un caractère compatible qui ne peut être utilisé que pour maintenir la compatibilité descendante avec les anciennes normes et dont l'utilisation n'est pas recommandée. (Sur Wikipedia)
Je comprends qu'il y a une raison pour laquelle il ne peut être utilisé que pour la compatibilité descendante.
Cependant, toutes les normalisations Unicode sont assez inquiétantes. Les lettres sont difficiles.
En prime, si vous recherchez avec l'un ou l'autre dans le navigateur, les deux seront capturés. Je pense que je cherche après avoir normalisé l'un des quatre types. Je ne sais pas si l'opération de recherche a des spécifications communes à tous les navigateurs.
Lorsqu'une simple plainte d'un utilisateur final selon laquelle "ce caractère est brouillé" apparaît ici, elle devient "salut". Ce n'est pas l'affaire de quelqu'un d'autre, car je suis associé à un système où CP932, shift_jis et UTF-8 sont mélangés sous Windows.
Recommended Posts