I've tried using the websockets addition to emacs-web-server and have observed some text appearing corrupted in the alert dialog. I have tested it with the 009-web-socket.el example file when I change the text from “foo”, and it happens there, too.
In addition, I've tried putting (message "%s" string) in the (lambda (proc string)… of the 009-web-socket.el example file to see what the server was doing with what it received.
If I change the text in the Javascript from “foo” to:
- The word résumé with acute accent e, the Safari dialog shows the text résum
- but the elisp message showed: résumé
- and the close connection link gives no dialog.
- The word ¡Hola! with reversed exclamation mark, the Safari dialog shows the text ¡Hol
- but the elisp message showed: ¡Hola!
- and the close connection link gives no dialog.
- The word Hawaiʻi with the ʻokina in it, the “connection closed” Safari dialog appears, no other reply
- but the elisp message showed: Hawaiʻi
In the first two cases the close connection link failed to give an immediate response, though it would with foo. The close connection dialog did appear immediately when the server was stopped, i.e. with (ws-stop-all). In the third case, the connection had already closed itself on its own as a response to receiving the text Hawaiʻi (with the ʻokina U+02BB) from the message link.
I've tried ensuring emacs opens the file 009-web-socket.el as UTF-8, and emacs indicates it is in the mode line with a “U” in the far left. This did not change the results.
Maybe this means Safari isn't sending the text correctly? I've tried changing the beginning of the HTML to:
<!DOCTYPE html><html><head><meta charset="utf-8">
That did not change the results. I looked into what Javascript does with the text, and it seems like it's suppose to handle everything as UTF-16. But the text received from the server seems like ASCII in the Safari dialog and in the elisp messages I gathered before it was sent back to Safari.
I've tried using string-as-multibyte, string-to-multibyte, and string-make-multibyte but none of that changed the results. I attempted to apply the function decode-coding-string instead of the function string in a copy of the function ws-web-socket-mask, but decode-coding-string wants a different type of argument (a string instead of chars) and I failed to figure out a way to use it.
I don't know what to think about this. Is it Safari, or emacs, or the example file 009-web-socket.el, or a function in web-server.el? Maybe a combination? I'm at several dead ends.
I've tried using the websockets addition to emacs-web-server and have observed some text appearing corrupted in the alert dialog. I have tested it with the 009-web-socket.el example file when I change the text from “foo”, and it happens there, too.
In addition, I've tried putting
(message "%s" string)in the(lambda (proc string)…of the 009-web-socket.el example file to see what the server was doing with what it received.If I change the text in the Javascript from “foo” to:
In the first two cases the close connection link failed to give an immediate response, though it would with foo. The close connection dialog did appear immediately when the server was stopped, i.e. with
(ws-stop-all). In the third case, the connection had already closed itself on its own as a response to receiving the text Hawaiʻi (with the ʻokina U+02BB) from the message link.I've tried ensuring emacs opens the file 009-web-socket.el as UTF-8, and emacs indicates it is in the mode line with a “U” in the far left. This did not change the results.
Maybe this means Safari isn't sending the text correctly? I've tried changing the beginning of the HTML to:
<!DOCTYPE html><html><head><meta charset="utf-8">That did not change the results. I looked into what Javascript does with the text, and it seems like it's suppose to handle everything as UTF-16. But the text received from the server seems like ASCII in the Safari dialog and in the elisp messages I gathered before it was sent back to Safari.
I've tried using
string-as-multibyte,string-to-multibyte, andstring-make-multibytebut none of that changed the results. I attempted toapplythe functiondecode-coding-stringinstead of the functionstringin a copy of the functionws-web-socket-mask, butdecode-coding-stringwants a different type of argument (a string instead of chars) and I failed to figure out a way to use it.I don't know what to think about this. Is it Safari, or emacs, or the example file 009-web-socket.el, or a function in web-server.el? Maybe a combination? I'm at several dead ends.