Difference between revisions of "Talk:event"

Explain xkcd: It's 'cause you're dumb.
Jump to: navigation, search
(add a note on how the "UTF-16LE" claim is just wrong.)
(apologies for the blunders of interpreting the data)
 
Line 35: Line 35:
  
 
I'm sorry but what the hell are you talking about? > UTF-16LE with BOM file, for starters, the JPG does not contain BOM data (doesn't start with any of the BOM markings), and the JPG does not contain any coherent UTF-16LE text. What I assume you did was just cURL the request, and got back all the header data, and the raw http response that HTTP sends along. You can even see in the Content field the decimal array of the JPG. The actual data is a JPEG, not text. I also assume you ran a command to identify what type of file you got back from your cURL output (or whatever you used to make that request), which is why you said it was "UTF-16LE". [[User:Preloading|Preloading]] ([[User talk:Preloading|talk]]) 16:21, 13 September 2025 (UTC)
 
I'm sorry but what the hell are you talking about? > UTF-16LE with BOM file, for starters, the JPG does not contain BOM data (doesn't start with any of the BOM markings), and the JPG does not contain any coherent UTF-16LE text. What I assume you did was just cURL the request, and got back all the header data, and the raw http response that HTTP sends along. You can even see in the Content field the decimal array of the JPG. The actual data is a JPEG, not text. I also assume you ran a command to identify what type of file you got back from your cURL output (or whatever you used to make that request), which is why you said it was "UTF-16LE". [[User:Preloading|Preloading]] ([[User talk:Preloading|talk]]) 16:21, 13 September 2025 (UTC)
 +
 +
My apologies, I must have mistaken the header output for actual file content (since I have encountered similar issues so I assumed it was the same issue I've seen -- you cannot trust what URL have told you but I digress.). The actual <code>newest.jpg</code> is missing the <code>EOI</code> tag and is too short for an image of this dimension. There is no EXIF information. However, the dimensions itself are quite intriguing as they are both multiples of 8, which is the block size used by JPEG format. [[User:Dousha99|Dousha99]] ([[User talk:Dousha99|talk]]) 14:09, 22 September 2025 (UTC)

Latest revision as of 14:09, 22 September 2025

What does this mean? Caliban (talk) 21:41, 16 August 2025 (UTC)

It means the denizens of this wiki try to document everything that Randall puts on the website, even if it's apparently a mistake and/or a corrupted file. 70.29.243.228 17:08, 18 August 2025 (UTC)

Why does this page have the refresh every 60 seconds html attribute? Preloading (talk) 20:43, 25 August 2025 (UTC)

After loading the image into a hex editor, I found that it is not an image, but a UTF-16LE with BOM file. The data look like this:

UTF-16LE with BOM data. There are multiple new lines trailing in the original data. The content may vary.

StatusCode        : 200
StatusDescription : OK
Content           : {255, 216, 255, 224...}
RawContent        : HTTP/1.1 200 OK
                    Connection: keep-alive
                    Age: 22
                    X-Served-By: cache-nrt-rjtt7900070-NRT
                    X-Cache: HIT
                    X-Cache-Hits: 1
                    X-Timer: S1756704587.574873,VS0,VE1
                    Accept-Ranges: bytes
                    Content-Length: 1359...
Headers           : {[Connection, keep-alive], [Age, 22], [X-Served-By, cache-n
                    rt-rjtt7900070-NRT], [X-Cache, HIT]...}
RawContentLength  : 1359





The Content field does indicate a valid JPEG image. So maybe this is a misconfigured CDN edge? Dousha99 (talk) 06:13, 1 September 2025 (UTC)

I'm sorry but what the hell are you talking about? > UTF-16LE with BOM file, for starters, the JPG does not contain BOM data (doesn't start with any of the BOM markings), and the JPG does not contain any coherent UTF-16LE text. What I assume you did was just cURL the request, and got back all the header data, and the raw http response that HTTP sends along. You can even see in the Content field the decimal array of the JPG. The actual data is a JPEG, not text. I also assume you ran a command to identify what type of file you got back from your cURL output (or whatever you used to make that request), which is why you said it was "UTF-16LE". Preloading (talk) 16:21, 13 September 2025 (UTC)

My apologies, I must have mistaken the header output for actual file content (since I have encountered similar issues so I assumed it was the same issue I've seen -- you cannot trust what URL have told you but I digress.). The actual newest.jpg is missing the EOI tag and is too short for an image of this dimension. There is no EXIF information. However, the dimensions itself are quite intriguing as they are both multiples of 8, which is the block size used by JPEG format. Dousha99 (talk) 14:09, 22 September 2025 (UTC)