Dlaczego emoji takie jak 💩 pojawiają się, gdy korzystam z Safari, ale nie Chrome?

30

Dlaczego emoji takie jak 💩 pojawiają się, gdy korzystam z Safari, ale nie Chrome na tym samym MacBooku z Lionem? Obie przeglądarki używają WebKit i wyobrażam sobie, że obsługa czcionek pochodzi z systemu operacyjnego, a nie aplikacji.

Dla celów odniesienia jest to strona renderowana w Chrome 17.0.963.56:

Chrome 17.0.963.56

A to jest strona renderowana w Safari 5.1.3 (7534.53.10):

Safari 5.1.3 (7534.53.10)

— Daniel
źródło

9

Ja oglądania tego w Chrome, a ja nie widzę 💩 w pytaniu lub tytuł, ale zrobić go zobaczyć w tytule zakładki na szczycie okna.

— CajunLuke

Rzadko kiedy najeżdżam na zakładkę, by zobaczyć pełny tytuł strony, ale masz rację, rzeczywiście tak jest. To bardzo zaskakujące.

— Jason Salaz

Być może wtyczki Chrome mają własną paletę znaków, która może być wersją hybrydową między wersją natywną a zastrzeżoną. Muszą tylko zaktualizować go dla OS X. Ale wiem, że emoji nie są tylko kwestią rodzaju czcionki (nie można na przykład przenieść emoji do SL po prostu instalując odpowiednią czcionkę). Jest więc coś więcej niż tylko czytanie nowego rodzaju czcionki. Złożyłbym błąd w Google. Lub poproś o pełne wsparcie.

14

Ponieważ odwiedzający Chrome mają trudności z odczytaniem tytułu, głosuję za zmianą tytułu na „Jak produkować turd w Google Chrome?”

— Gerry

@cksum Odwróciłem tytuł, ponieważ stał się on istotną informacją w pytaniu.

— Jason Salaz

27

Różnica polega na silnikach renderujących dla okien przeglądarki.

Wiemy, że Safari renderuje zestaw znaków inaczej niż Chrome. Ale elementy interfejsu Windows (zakładki w Chrome) są w porządku. To nasza największa wskazówka.

Prawdopodobnie wszystkie elementy interfejsu użytkownika okna (nacisk na prawdopodobne, tutaj może się nie zgadzam) są renderowane przez system operacyjny. Dzięki temu otrzymują pełną ekspansję emoji na poziomie systemu operacyjnego.

Ale wszystko, co dzieje się w oknie przeglądarki, zależy od przeglądarki. Silniki renderujące stanowią dużą część tajnego sosu każdej przeglądarki.

Zarówno Safari, jak i Chrome używają WebKit, ale podobieństwa między instancjami WebKit, których używają, zatrzymują się gdzieś w pobliżu nazwy silnika. Obaj są rozwidleniami z głównej wersji i oba są mocno dostosowane, aby poprawić wydajność w sposób, który zdaniem każdego zespołu programistów przeglądarki ma znaczenie dla ich użytkowników końcowych.

@JasonSalaz znalazł świetny błąd w bazie danych błędów Chrome, który daje nam ostateczną wskazówkę, że sprowadza się to do rozwidleń WebKit: http://code.google.com/p/chromium/issues/detail?id=90177 - ten błąd jest mówiąc o różnicach między rozwidleniem w Chrome a główną linią WebKit z projektu open source. Istnieją różnice w renderowaniu w głównej linii, które nie zostały jeszcze wprowadzone do wersji używanej przez Chrome. I wygląda na to, że zamierzają połączyć zmiany w pewnym momencie.

Aktualizacja: Paul Irish ma świetny post na blogu o tym, czym różni się WebKit dla wszystkich przeglądarek, które go obecnie używają . Jeśli naprawdę chcesz zrozumieć, jak różnorodne jest środowisko WebKit, jest to świetna lektura.

— Ian C.
źródło

Argh. Powinienem zrobić kilka zrzutów ekranu. No cóż ...

— Ian C.

Obsługa Emoji do śledzenia zgłoszeń błędów Chromium jest następująca: crbug.com/62435 Ten, z którym się łączysz, jest duplikatem.

— Mathias Bynens,

Dla przypomnienia: W Chrome 20.0.1132.57 wciąż jest zepsuty.

Och, świetnie, zgodnie z komentarzem 17 w raporcie o błędzie ten problem został zamknięty. Jeśli ktoś chce ponownie złożyć skargę, musisz złożyć nowy raport o błędzie.

— gentmatt,

1

Działa teraz od Chrome 41! 🚀🚀🚀🚀🚀🚀🚀

— yincrash

12

Możesz użyć rozszerzenia Chrome Chromoji . Jest to obejście, które zastąpi emoji osadzonymi obrazami na stronach internetowych.

— Steffi
źródło

2

Całkowicie działa, przynajmniej na Twitterze, nie usuwaj odpowiedzi.

— MarcusJ 16.04.13

2

Problem polega na tym, że Twoja przeglądarka używa innego kodowania znaków niż kod dokumentu, który przeglądasz.

Skąd więc przeglądarka wie, jakiego kodowania znaków użyć?

Można go określić w HTTP za pomocą Content-Typenagłówka.
Można go określić dla dokumentu HTML za pomocą metaelementu.
Można go określić dla określonego elementu HTML za pomocą charsetatrybutu.

Jeśli nie określono żadnego z nich, różne przeglądarki używają różnych technik do odgadnięcia właściwego kodowania znaków. Niektórzy używają heurystyki. Niektóre pozwalają użytkownikowi określić kodowanie znaków. Niektóre wybierają domyślne kodowanie znaków w systemie operacyjnym.

Jeśli żadna z nich się nie pojawi, otrzymasz bełkot, znany również jako mojibake.

Aby odpowiedzieć bezpośrednio na twoje pytanie: Safari i Chrome próbują różnych rzeczy, aby znaleźć właściwe kodowanie znaków.

— james.garriss
źródło

3

Widok -> Kodowanie tekstu w Safari mówi „Domyślne”. Widok -> Kodowanie w Chrome mówi „UTF-8”. Prefektorzy Safari mówią, że domyślnym kodowaniem jest western (ISO Latin 1). Jeśli zmienię kodowanie w Chrome na Western (ISO-8859-1), Western (Windows-1252) lub Western (Macintosh), nadal nie widzę właściwego emoji, ale widzę bełkot zamiast pustej przestrzeni. Nie sądzę, żeby to było tak proste jak kodowanie znaków. Podejrzewam, że istnieją różnice w renderowaniu. (ciąg dalszy ...)

— Ian C.

1

(ciąg dalszy od góry) To wyjaśniałoby pasek tytułowy pokazujący emoji (tekst jest prawdopodobnie renderowany przez silnik renderujący OS X, ponieważ jest to element graficzny w oknie), a treść strony jest renderowana przez własny silnik renderujący Chrome.

— Ian C.

1

@IanC. To prawdopodobnie odpowie godne jeśli rozwinąć na niej tylko nieco więcej. Chrome używa WebKit, ale poza tym nie jest to jedna z klas ObjC / Cocoa, które natywnie obsługują emoji. Jest to w końcu cecha Chrome nr 1, niesamowicie szybka, którą niezmiennie osiąga się tylko dzięki niestandardowemu rozwiązaniu. Chrome musiałby więc albo napisać wsparcie dla emoji, albo przestać robić to, co sprawia, że ludzie wolą je od Safari i innych przeglądarek. (Zgadnij, który jest bardziej prawdopodobny?)

— Jason Salaz

1

Natknąłem się na to: code.google.com/p/chromium/issues/detail?id=90177

— Jason Salaz

@JasonSalaz ładnie złapał ten raport o błędzie. To ostatni kawałek. Pisanie odpowiedzi!

— Ian C.

0

Przejdź do paska menu Chrome, kliknij „Więcej narzędzi” → „Kodowanie” i wybierz nowy format kodowania. Używam „Unicode UTF-8”, wydaje mi się, że działa.

— Blake Edmunds
źródło

-1

https://code.google.com/p/chromium/issues/detail?id=62435 został ostatnio oznaczony jako naprawiony; od wersji 41 emoji powinno wyświetlać się poprawnie w Chrome.

— thakis
źródło

1

Chociaż jest to przydatne, nie jest to tak naprawdę odpowiedź. Nie wyjaśnia, dlaczego tak się dzieje. Lepiej zostaw to jako komentarz IMO.

— Ian C.

Stało się tak, ponieważ obsługa emoji nie została zaimplementowana. Pytanie nie będzie miało sensu, gdy m41 będzie stabilny.

— thakis

-9

Symbol jest postacią stworzoną przez Apple. Safari używa własnego zestawu znaków.

— Josh
źródło

5

W rzeczywistości „kupa kupy” to międzynarodowy standardowy znak w Unicode - symbol 1F4A9, a nawet nie specyficzny dla Apple, nie mówiąc już o czymś wyjątkowym dla Safari. Zobacz wpis Wikipedii na temat Emoji i tego pliku PDF, aby uzyskać szczegółowe informacje.

— bmike

2

Chociaż postać nie jest unikalna dla Apple, kolory są. Nie znam żadnej innej istniejącej czcionki kolorów i myślę, że Apple stworzyło własny standard do tego (własna tabela sbix). Różne aplikacje nie rozpoznają tej czcionki, ale wyświetlają się z normalnej czarno-białej czcionki Symbola.

— Tom Gewecke,

1

PS Ponieważ w tej czcionce jest coś „unikalnego dla Apple'a”, myślę, że ta odpowiedź nie jest tak odległa, jak sugeruje ocena minus.

— Tom Gewecke,

@ TomGewecke, „Safari używa własnego zestawu znaków” jest po prostu fałszywe. Myślę więc, że oceny ujemne są zasłużone.

— jbg